Class WalkGaitParameters.SlopeGroup
- Namespace
- CodeSmile.AnyMotion.AnimateYourself.Gait /
- Assembly
- ApiSource.dll
L08 (slope adaptation): the authored half. Extends L05 (foot planting on uneven ground) — the
ground normals it tilts the pelvis towards and the reach deficit it draws step-shortening from
both come from L05's existing raycast, so there is no separate authored slope input; only how
much of that already-measured slope shows up in the pelvis and the stride is authored here.
The raycast, blend and pelvis-rotation math are runtime behaviour in
IkTargetSpaceDriver, not authored data, so they are not here — see roadmap.md §1a.
[Serializable]
public sealed class WalkGaitParameters.SlopeGroupExpand Details ...
- Inheritance
-
objectWalkGaitParameters.SlopeGroup
Remarks
PelvisTiltPitchWeight and PelvisTiltRollWeight are reserved schema with no consumer. No code reads either field, so no value of either changes what a character does. They exist so that separating the pelvis tilt into a fore/aft share and a sideways share can be added later without changing the preset format. A climb and a descent lean the hips along the direction of travel; crossing a slope banks them across it. One measured surface normal produces both, so expressing that difference needs a weight for each direction.
They multiply PelvisTiltAmount, they do not replace it. PelvisTiltAmount keeps its own meaning and its own authored value: it is how much of the measured slope reaches the hips at all, and these two weights decide what share of it goes to each direction. Adding two weights beside it rather than replacing it with two fields is what lets a preset written before they existed keep the amount it authored — a renamed field is dropped on load and its value is lost, an added one is not.
Why the shipped values cannot change anything, even once the separation exists.
Both are 1, and amount × 1 is amount in each direction. The tilt is one
rotation about a horizontal axis, so writing it as two components along any two
perpendicular horizontal axes and scaling each by 1 recomposes the same rotation, whichever
two axes the separation is resolved along. Every other pair of values does depend on which
two axes those are, and which two axes a separation would use is not decided yet.
Version is deliberately not raised for these two fields. A preset written before they existed deserializes with these initialisers intact, which is the behaviour that preset already described, so a load-time upgrade pass would have nothing to do.
Fields
PelvisTiltAmount
[Tooltip("How much the hips tilt to match the slope under the feet, from 0 (hips stay level whatever the ground does) to 1 (hips match the measured slope exactly). The character leans into the slope, the way a person does to keep their balance. Only feet that are actually on the ground are taken into account.")]
[Range(0, 1)]
public float PelvisTiltAmountField Value
- float
PelvisTiltPitchWeight
[Tooltip("Reserved: what share of Pelvis Tilt Amount applies to the slope's fore/aft direction — the lean into a climb or a descent. Has no effect yet.")]
[Range(0, 1)]
public float PelvisTiltPitchWeightField Value
- float
PelvisTiltRollWeight
[Tooltip("Reserved: what share of Pelvis Tilt Amount applies to the slope's sideways direction — the lean into a bank when crossing a slope rather than climbing it. Has no effect yet.")]
[Range(0, 1)]
public float PelvisTiltRollWeightField Value
- float
StepShortenRatio
[Tooltip("On a slope, how much of a leg's shortfall in reach is dealt with by taking a shorter step rather than by lowering the hips, from 0 to 1. 0 lowers the hips for all of it. Raise it to keep the hips higher on slopes, at the cost of a shorter stride. It cannot remove room the hips genuinely need: a shortfall while standing on a slope is mostly downward, and a shorter step only helps with the forward part.")]
[Range(0, 1)]
public float StepShortenRatioField Value
- float