Class WalkGaitParameters.ClipLayeringGroup
- Namespace
- CodeSmile.AnyMotion.AnimateYourself.Gait /
- Assembly
- ApiSource.dll
Reserved schema, no consumer. Nothing in this group is read by any code, and its defaults
describe exactly what AnyMotion does today. It exists so that the upper-body clip-layering
mode — an animation clip supplies the base pose, AnyMotion composes the upper body on top of
it — can be added later without a preset-schema break. For the mode itself see
Assets/Plan/future/redesign-decision-tree/02-fixed-pose-restore-point/pose-3-real-clip-escape-hatch.md;
and locomotion-catalog.md §5 (what this list changes about the P7
schema freeze) for the reservation rule it follows: "an unused field costs nothing, a missing
one costs a schema break". P7 (JSON preset schema freeze) is the deadline that makes the
reservation worth making now rather than when the mode is built.
[Serializable]
public sealed class WalkGaitParameters.ClipLayeringGroupExpand Details ...
- Inheritance
-
objectWalkGaitParameters.ClipLayeringGroup
Remarks
Two concepts across five fields, because the mode needs two decisions that today's code never has to make: one for the whole body, and one per upper-body channel.
Where the base pose comes from. Every driver space restores a fixed reference pose
each frame (IkTargetSpaceDriver.Apply → m_Bones.RestoreBindPose()), which is
only correct while nothing else writes the rig. Layering a clip requires that restore point
to become the Animator's output for that frame instead — the deferred work item recorded in
CLAUDE.md → Current state. BasePose is where that choice is stated.
What an authored angle means against a moving base. HumanoidBoneSet.RotateAboutRootAxes
conjugates every authored angle onto the measured rest rotation, so today an angle is
always a delta from rest. Once a clip supplies the base, some parameters still read
correctly as a delta against it (lean, look-at, noise) and some do not, so the answer is
per channel rather than one switch for the whole body. locomotion-catalog.md §5
lists this as "per-channel blend mode and damping time constant"; only the blend mode half
is reserved here, since the damping half belongs to the transition entries that need it —
L13 (start / stop with settle step), L14 (landing compression + recovery step), L20
(ragdoll handoff), L21 (turn in place), L23 (hit-react stumble without losing the gait) —
and would be sized by them, not by this mode.
Why only four channels, and why no legs. The mode is scoped to the upper body:
a clip that also drives the legs brings its own contact schedule with it, which would have
to be extracted at design time before procedural legs could compose against it. Masking the
clip to the upper body needs none of that, and it covers the demand that survived review —
interactions, emotes and weapon handling happening while the character walks. The pelvis is
deliberately absent for the same reason: it derives from leg state (CLAUDE.md →
Load-bearing decisions), so it belongs to the contact-carrying half of the body.
Why the defaults cannot change anything. At BindPose the base pose is the rest pose that the authored angles are already measured from, so "replace the base" and "add to the base" resolve to the same bone rotation and no value of a blend mode is observable. Replace is still the correct default rather than an arbitrary one: it is what the existing behaviour becomes once a moving base exists, so a preset written today keeps its current look if the mode is ever switched on.
Version is deliberately not bumped. Its purpose is to
branch a load-time upgrade pass (serialization-format-decision.md § Migration
strategy) and there is nothing to upgrade: a preset written before this group existed
deserializes with these initialisers intact, which is the shipped behaviour it already
described.
Fields
ArmsBlendMode
[Tooltip("Reserved: how the Arms settings would combine with a base pose supplied by an animation clip. Replace drives the arms procedurally and ignores what the clip does with them. Additive keeps the clip's arm motion, such as a carry or weapon pose, and adds the arm swing on top. Has no effect while Base Pose is Bind Pose.")]
public WalkGaitParameters.ClipLayeringGroup.ChannelBlendMode ArmsBlendModeField Value
BasePose
[Tooltip("Where the pose comes from that everything else is measured against. Bind Pose is this character's own rest pose and is the only value that does anything today. Animator Output is reserved for a planned mode in which an animation clip supplies that pose and AnyMotion drives the upper body on top of it; selecting it currently changes nothing.")]
public WalkGaitParameters.ClipLayeringGroup.BasePoseSource BasePoseField Value
HeadBlendMode
[Tooltip("Reserved: how the Head settings would combine with a base pose supplied by an animation clip. Replace drives the head procedurally and ignores what the clip does with it. Additive keeps the clip's head motion and adds the bob, yaw and roll on top. Has no effect while Base Pose is Bind Pose.")]
public WalkGaitParameters.ClipLayeringGroup.ChannelBlendMode HeadBlendModeField Value
LookAtBlendMode
[Tooltip("Reserved: how the Look At settings would combine with a base pose supplied by an animation clip. Replace aims the head, neck and chest at the target and ignores what the clip does with them. Additive keeps the clip's motion and turns towards the target on top of it. Has no effect while Base Pose is Bind Pose.")]
public WalkGaitParameters.ClipLayeringGroup.ChannelBlendMode LookAtBlendModeField Value
TorsoBlendMode
[Tooltip("Reserved: how the Torso settings would combine with a base pose supplied by an animation clip. Replace drives the spine and chest procedurally and ignores what the clip does with them. Additive keeps the clip's motion and adds the procedural lean and twist on top. Has no effect while Base Pose is Bind Pose.")]
public WalkGaitParameters.ClipLayeringGroup.ChannelBlendMode TorsoBlendMode