Nicholas ButzkeandClaude Opus 5
08ae85b286
The weapon lab could tune how a character HOLDS a gun. It could not tune where
the gun sits in the hand, and that is a different question with a different
scope: a hold is per character and weapon, an anchor is a fact about the hand.
RigAnchors adds it. A hand bone's origin is the WRIST, not the palm, and how far
down the palm a grip should sit — and how the gun rolls in the fingers — depends
on how big that character's hand is and how the artist posed the thumb. It
cannot be derived, it differs per character, and it is small. So it is an offset
that defaults to identity, and identity means exactly what the code derived
before anchors existed: an untuned character is bit-for-bit unchanged.
Deliberately NOT a fixed rotation on the mount. There used to be one, and a bone
attachment is expressed in the BONE's axes, which no two rigs agree on — that
constant is why the hand mount points were wrong on every character. The derived
mount stays derived; the anchor is a nudge on top of it, and nothing here spells
a bone name.
The layering, the JSON round trip and the res://-then-user:// write are now
TuningStore, because none of that was ever specific to weapons and two copies of
it would mean two places for "an exported build's tuning pass is silently
discarded" to come back. WeaponHoldTuning is built on it with its file format
unchanged.
The lab is a rig lab now, and it grew three things:
ANCHORS a second knob group. It cost a spec table — everything in the lab is
written against "which specs, which file, keyed on what" rather than
twice against the two groups, so anchors got sliders, live preview,
reset, save and clipboard for free. A third group is a third row in
GROUPS.
CLIP audition one animation on its own. The four pose buttons are the
states the game drives; watching a whole clip end to end is how you
see where a retarget went wrong, and there was no way to do it.
SURFACES what the importer decided each surface IS, and a click to isolate a
class. Isolating is how the decision gets CHECKED: click `hair` and
anything else still standing was misclassified. Hidden by swapping
in a transparent material rather than hiding the node, because a
mesh is not one class — Miku's body, face and hair are three
surfaces of one mesh.
And it takes the game's theme, applied to its own panel rather than only to the
Window, for the same reason the pause menu needed it: a CanvasLayer is not a
Control, so theme inheritance stops at one.
debug/rig_anchor_check.gd asserts the physical consequence rather than the
plumbing — an anchor system is easy to build so that the sliders move, the file
saves, the JSON round-trips and the gun does not budge. All six characters move
their weapon by exactly the offset asked for, measured in the attachment's frame
because a world-space delta on an animating skeleton is mostly the idle
animation, and all six return exactly to the derived mount when it is cleared.
Also fixes BoltRule, whose zigzag was self-intersecting: draw_colored_polygon
triangulates, and a crossing outline fails triangulation and draws nothing at
all except a console full of "Invalid polygon data". Same silhouette, walked as
a closed loop, with the ink edge as a polyline rather than a grown polygon —
growing a concave shape from its centroid reintroduces the crossing.
Co-Authored-By: Claude Opus 5 <[email protected]>
91 lines
4.0 KiB
GDScript
91 lines
4.0 KiB
GDScript
extends Object
|
|
class_name RigAnchors
|
|
|
|
## Named attachment points on a character's skeleton, adjustable per character.
|
|
##
|
|
## An anchor is a bone ROLE plus an offset: "the grip sits here, relative to the
|
|
## right hand". The role is resolved from the rig sidecar, so nothing here ever
|
|
## spells a bone name — that rule is what let four characters hold a gun at all.
|
|
## The offset is the part a human has to decide.
|
|
##
|
|
## Why an offset is needed even though the code derives a mount:
|
|
##
|
|
## The third-person weapon is seated at the hand bone's ORIGIN with no
|
|
## hand-relative rotation, and the pose layer then aims it by rotating the wrist
|
|
## until the gun's forward axis lies on the aim line. That is deliberate and it
|
|
## is right — a constant rotation there is expressed in the BONE's axes, no two
|
|
## rigs agree on those, and a fixed `(0, 90, -90)` is exactly why the hand mount
|
|
## points used to be wrong on every character.
|
|
##
|
|
## But a hand bone's origin is the WRIST, not the palm. How far down the palm a
|
|
## grip should sit, and how the gun should roll in the fingers, is a judgement
|
|
## about that character's hand — how big it is, how the fingers were modelled,
|
|
## how the artist posed the thumb. It cannot be derived, it differs per
|
|
## character, and it is small. So it is an offset, it defaults to zero, and zero
|
|
## means "exactly what the code derives" — which is what every character gets
|
|
## until someone opens the rig lab and decides otherwise.
|
|
|
|
const PATH := "res://assets/characters/rig_anchors.json"
|
|
## Written to the project when running from source; falls back to user:// for an
|
|
## exported build, where res:// is read-only.
|
|
const USER_PATH := "user://rig_anchors.json"
|
|
|
|
## The one subject key. Anchors are per CHARACTER, not per weapon — where a grip
|
|
## sits in a palm is a fact about the hand, and re-tuning it for every gun would
|
|
## be re-answering the same question. TuningStore is keyed by subject, so this
|
|
## names the only one there is.
|
|
const SUBJECT := "anchors"
|
|
|
|
## key -> [label, minimum, maximum, is_vector, default]
|
|
##
|
|
## The lab builds its whole anchor UI from this, so adding an anchor here is all
|
|
## it takes to expose one. Ranges are what a plausible answer lives inside, not
|
|
## what the value can technically be: a grip more than 12 cm from the wrist is
|
|
## not a grip, it is a mistake, and a slider that can express it only makes the
|
|
## useful range harder to hit.
|
|
##
|
|
## Every default is ZERO, and that is load-bearing — see the note above. A knob
|
|
## whose slider sits at 0 next to a code default of something else means the
|
|
## first touch of that slider silently changes behaviour.
|
|
const KNOBS := [
|
|
["grip_offset", "Grip position in the palm (m)", -0.12, 0.12, true, Vector3.ZERO],
|
|
["grip_rotation", "Grip roll/pitch/yaw (rad)", -1.6, 1.6, true, Vector3.ZERO],
|
|
]
|
|
|
|
## Which bone role each anchor hangs off. Roles, not names — resolved through
|
|
## the sidecar the pipeline writes.
|
|
const ANCHOR_BONE := {
|
|
"grip_offset": "hand.R",
|
|
"grip_rotation": "hand.R",
|
|
}
|
|
|
|
|
|
static func default_for(key: String):
|
|
return TuningStore.default_for(KNOBS, key)
|
|
|
|
|
|
static func load_all() -> Dictionary:
|
|
return TuningStore.read(PATH, USER_PATH)
|
|
|
|
|
|
## The resolved anchor table for one character.
|
|
static func resolve(all: Dictionary, skin_id: String) -> Dictionary:
|
|
return TuningStore.resolve(all, skin_id, SUBJECT)
|
|
|
|
|
|
static func save(all: Dictionary, skin_id: String, table: Dictionary) -> String:
|
|
return TuningStore.write(all, skin_id, SUBJECT, table, PATH, USER_PATH)
|
|
|
|
|
|
## The grip anchor as a transform to seat a weapon with, in hand-bone space.
|
|
##
|
|
## Identity when nothing is tuned, which is what the code did before anchors
|
|
## existed — so a character nobody has opened the lab for is bit-for-bit
|
|
## unchanged.
|
|
static func grip_transform(table: Dictionary) -> Transform3D:
|
|
var pos: Vector3 = table.get("grip_offset", Vector3.ZERO)
|
|
var rot: Vector3 = table.get("grip_rotation", Vector3.ZERO)
|
|
if pos == Vector3.ZERO and rot == Vector3.ZERO:
|
|
return Transform3D.IDENTITY
|
|
return Transform3D(Basis.from_euler(rot), pos)
|