This page compares two ways of making a humanoid character walk, run, turn and stop in Unity:
Animate Yourself — the procedural layer in this asset. No animation clips. Every pose is
computed each frame from a set of numbers.
The Animator pipeline — Unity’s standard humanoid workflow: AnimationClips authored or
captured per motion, connected into an Animator Controller state machine, blended by BlendTrees,
played through the Animator component.
How far the Animate Yourself column has been verified. Most of this asset's
locomotion features are verified numerically — unit tests, compile checks, analytic derivations and
measured probes. They have not been confirmed by watching them run in the Unity Editor.
Two kinds of row are marked not fully verified in the table:
a row whose claim has not been confirmed by watching it run, and a row where the investigation could
not settle the question. Each marked row's own detail states exactly what evidence does exist.
An unmarked row is one of three things: a problem that cannot occur because the mechanism causing
it is absent, which is provable from the code; a measurement of something other than how the
character moves, where the measured number is the whole claim; or a row stating that this asset has
the problem too, which carries no claim to confirm.
Where the list of problems came from
The rows are not a feature list. They are a list of problems people report with humanoid
locomotion — 32 distinct complaints, collected from a body of written material about what goes wrong
and then checked one by one against this asset’s own source code, unit tests, measured probes and
planning documents.
Four of those 32 are split across two rows each: two because the two halves of the complaint get
different answers, and two because checking the complaint turned up a separate defect worth stating
on its own. That makes 36. Seven further rows are questions that could not be answered from the
available evidence, for 43 in total.
The rows are grouped by the outcome of that check, in the order the investigation produced them.
They are deliberately not ordered as an argument: the group where this asset has the same
problem, and the group where nothing was established, are in the same table as the rest.
How each column was established
Animate Yourself. Every cell is backed by the asset’s own code, a unit test, a measurement, or a
recorded decision. Where a claim is bounded, the bound is in the row’s detail text — a number, a
test, or the specific condition it holds under.
The not fully verified mark described at the top of this page is what carries the
numeric-versus-visual qualification into the table itself. In full: the project records “not yet
visually confirmed” against look-at, run, slope adaptation, arm layering, starting and stopping, the
settling step and the restart work, and it has no test fixture that runs a complete pose against a
real skinned character. A marked row that says a problem is handled therefore means the mechanism
exists, is reachable, and produces the right numbers. It does not mean somebody has watched it and
it looks right. That distinction is itself a row, near the bottom of the table.
Animator. Each cell describes the standard Unity humanoid workflow named above. Where no basis
was established for a statement about it, the cell says “Not established here.” rather than
being filled in for symmetry. In particular, no performance comparison is claimed: this asset’s
per-character cost was measured and the Animator pipeline’s was not.
Reading the table
Each Animate Yourself and Animator cell holds a compact symbol instead of a full sentence.
Activating a symbol — click it, or Tab to it and press Enter or Space — opens a panel with the full
explanation for that row: what the cell claims, what the other column claims, and whatever
additional detail this page used to keep in a legend below the table. The legend itself is gone;
its content moved into these panels rather than being removed.
The symbols:
✓ (Animate Yourself) — handled: the problem cannot occur, is handled automatically, or is
fully within your control via a setting.
✓† (Animate Yourself) — the same, but not yet confirmed by watching it run in the Unity
Editor. See the disclaimer above.
~ (Animate Yourself) — reduced, not removed: a real mitigation exists and a residual gap is
recorded.
✗ (Animate Yourself) — this asset has the same problem.
? (Animate Yourself) — open question: the investigation could not settle it either way.
• (Animator) — a documented mechanism is described for this row.
— (Animator) — not established here, or not measured. See “How each column was established”
above.
Problem
Animate Yourself
Animator
Cannot occur by construction — the mechanism that causes it is absent (8)
Blending two speeds
Animate Yourself
There are no clips to blend. Cadence is computed from speed, so every speed produces a gait generated for that speed.
Animator
A blend tree interpolates between recorded clips, so a parameter value between two of them produces a weighted mix of two recordings.
Additional detail
The complaint is that a speed value between two clips in a blend tree produces motion matching neither of them.
Animate Yourself contains no AnimationClip reference anywhere, tests included, and no Animator Controller, blend tree or cross-fade call. Steps per second is computed as move speed divided by step length in metres, so an intermediate speed is not a lookup between two recorded performances — it is a gait generated for that speed. The one blend that does exist, walk to run, interpolates three numbers — duty factor, step length and torso lean — rather than two recordings, and its weight functions are covered by unit tests.
T-pose from a missing clip
Animate Yourself
There is no clip that can be missing and no transition that can fail to be found. The pose is recomputed from the current settings every frame.
Animator
A state with no Motion assigned, a missing clip asset and an Any State transition that fires unexpectedly are each a separate thing that resolves at runtime, and a character with no clip driving its bones shows the pose it was imported in.
Additional detail
This was the most frequently repeated complaint in the source material, appearing in 13 of 20 texts. Its three named causes are a missing clip file, a state machine that finds no transition to take, and an Any State transition that fires when it was not expected.
None of the three exists in Animate Yourself: there are no clips, no Animator Controller, and no layers or transitions. The pose is recomputed from the current settings every LateUpdate.
One honest qualification. The internal rest-pose reference does fall back to Unity's own humanoid T-pose when a character has no skinned mesh to read a bind pose from, and it logs a warning when even that fails. That is a calibration reference the gait is generated on top of, not an output pose — but a screenshot of a wrongly set-up character could be mistaken for the original complaint.
Root motion vs in place
Animate Yourself
Neither exists. The animation layer never writes the character's root transform; movement stays entirely with your own controller.
Animator
Root motion is the Animator component's own applyRootMotion setting plus each clip's Root Transform import settings; there is no per-state root-motion toggle. In-place clips and root-motion clips need different movement code.
Additional detail
The complaint is the mismatch between animation that moves the character and a controller that also moves it.
Animate Yourself has no root motion in either direction. The animation layer writes bones and never the character's own transform: in the shipping driver the only transform writes are the hips' local position and rotation, the feet's rotation, and the two limb rotations the IK solver produces. There is no in-place-versus-root-motion choice to get wrong, because there is only one mode.
Building a clip library
Animate Yourself
A gait is a set of numbers that saves as a small JSON file. Seven presets ship; there is no capture, import or retarget step.
Animator
Each motion is an authored or captured clip that is imported and referenced from a state. Retargeting onto another humanoid is automatic once each model has an Avatar; acquiring and maintaining the clips is not.
Additional detail
The complaint is the cost of acquiring and maintaining a clip library — one clip per motion, per character type, captured or authored and then kept in sync.
In Animate Yourself a gait is a settings value that saves as a small JSON file, which can be shared and version-controlled. Seven presets ship. Five have a button in the Inspector: Neutral, Cartoon, Horror, Limp and Robot. The other two are reached another way — Blank is what every Reset button writes, and Run is applied from a script. Nothing is recorded, imported or retargeted.
Responsiveness cost
Animate Yourself
The feet never feed back into the controller, so adding the component does not change input latency.
Animator
Where movement is driven by root motion, travel comes from the clip, so animation timing and control response are coupled. OnAnimatorMove is where a project takes that delta back and decides what to do with it. Not measured here.
Additional detail
The complaint is that adding real foot planting makes movement feel heavier and less responsive than it was before.
In Animate Yourself the capsule collider is authoritative for where the body goes and the feet are visual only — a scope decision settled 2026-08-02 and recorded with its reasoning. Nothing in the layer can delay, damp or veto a movement input, because the layer writes bone transforms and nothing else. Input latency is exactly what it was before the component was added.
The cost of that decision has its own row: a foot that misses a ledge edge floats rather than causing the character to trip or fall.
Wobble at a stop
Animate Yourself
There is no inertialization and no blend into a standing clip. Each leg stops where it stands. The upper body does still cross-fade. not fully verified
Animator
A stop is a transition into a standing clip, so overshoot is shaped by that transition's duration and exit time. Mecanim has no inertialization of its own; smoothing beyond the transition is something the project adds.
Additional detail
The complaint is a torso that oscillates and then snaps still when the character stops, which is overshoot in a blend.
Animate Yourself stops by parking each leg where it stands, once there is nothing left to step for and that foot is down. The reason it is not a cross-fade is written into the code: standing has both feet planted at once, and no walking or running gait has both feet planted for a whole cycle, so there is no instant of the walk that the standing pose is a blend towards.
The upper body — pelvis, torso, head, arms, breathing — does still cross-fade, over the idle blend duration.
T-pose vs A-pose rigs
Animate Yourself
There is no source pose to transfer from. The rest pose is read from the mesh's own bind poses, and arm rest direction is measured per character.
Animator
Each rig carries its own Avatar, and the bone mapping and the rest pose it is measured against are set in the Avatar's Configure view, which offers Enforce T-Pose for a model authored in another pose. Retargeting is correct only if both Avatars are.
Additional detail
The complaint is a motion authored on a T-posed body applied to an A-posed one, or the reverse.
Animate Yourself transfers nothing, so there is no pair of poses to mismatch. The bind pose is read once from the skinned mesh's own bind poses — asset data, not live scene state — and handed to every driver. Arm rest posture is measured rather than assumed: the system records each character's own bind-pose arm direction and the minimal rotation that brings it to hanging, and applies that innermost, before any authored angle. A character that ships in an A-pose and one that ships in a T-pose both reach the same hanging rest.
Clipping through doors
Animate Yourself
Not this layer. It writes bone transforms only; environment collision belongs to the character controller.
Animator
Same. Environment collision belongs to the character controller in either pipeline.
Additional detail
The complaint is a character intersecting doorframes, crates and other characters.
This row is listed so the comparison is complete, not as a claim for either column. Animate Yourself neither causes nor fixes it: environment collision belongs to the character controller in both pipelines.
Handled with no setup (11)
Foot sliding
Animate Yourself
Cadence is derived from the character's own measured displacement, so a planted foot travels backward at exactly the speed the body travels forward. Measured on flat ground at 0.00–0.01 mm through constant, accelerating, braking and oscillating speed. Slopes and the walk-to-run blend are not covered. not fully verified
Animator
A clip's stride comes from the recorded performance and the rate it is played back at, not from the controller. Matching the two is manual, and a mismatch is visible as sliding.
Additional detail
This was the most frequent technical complaint in the source material, in 16 of 20 texts.
Steps per second is computed from move speed and step length rather than authored, and move speed itself is measured from the character's own position change each frame rather than typed in — on by default. The stance sweep is a rate rather than a pair of endpoints, which is what makes it correct at a changing speed and not only a constant one.
Four independent measurements. A five-character run with one identical preset measured foot slide at 0.0000 to 0.0090 leg lengths against a 0.02 threshold. A committed test bounds worst planted-foot travel through a stop and a restart at under 0.1 stance reach, which is 29 mm, over 120 stop phases. The same test measures the shipping mechanism against the one it replaced, whose own record is a 566.9 mm to 18.0 mm improvement in the median. A probe written for this investigation drove the real sweep code through constant walk, constant run, gradual and hard acceleration, gradual and hard braking, and a 1 Hz oscillating speed, and measured 0.00 to 0.01 mm of planted-foot world travel in every case.
That probe detects sliding when sliding exists: with speed-derived cadence switched off it measures 363 mm at a steady walk and 1728 mm through an acceleration ramp.
What this does not cover. Flat ground only — a residual slide on slopes is documented and has never been given a number. The walk-to-run blend's own planted-foot geometry is untested. And speed-derived cadence is a setting that can be switched off, which reintroduces the problem at the two numbers above.
Hand-typed move speed
Animate Yourself
Speed is measured from the character's own displacement. Changing the controller's speed cannot desynchronise the gait, because the gait reads the result rather than a second number. not fully verified
Animator
The value fed to the blend tree is a number game code supplies. Unity can compute a 1D blend tree's thresholds from each clip's own root-motion speed, but keeping the value supplied at runtime consistent with them is manual.
Additional detail
The complaint is that the speed number driving the animation and the speed the character actually travels at are two separate values, kept in agreement by hand and broken by any later edit to either one.
Animate Yourself measures the character's transform displacement over the frame's delta time, on by default, so a character moved by a Character Controller, a Rigidbody or anything else feeds the animation with no extra code. Changing the controller's move speed cannot desynchronise the gait, because the gait reads the result rather than a parallel number.
Moonwalking at low speed
Animate Yourself
Cadence cannot disagree with speed. At zero speed there is no cycle to run, and below the threshold the legs park rather than keep stepping. not fully verified
Animator
A clip plays at the cadence it was recorded at, scaled by its playback rate, so the artifact appears when the body travels slower than the stride that rate produces. The standard remedy is to scale playback speed from the blend tree, and keeping that scale matched to travel speed is manual.
Additional detail
The complaint is feet that move backward relative to the ground at low speeds.
Moving backward relative to the ground is cadence disagreeing with speed, which the derivation in the foot-sliding row prevents: at zero speed, steps per second is zero and there is no cycle to run. Below the idle threshold the legs additionally stop cycling and park. The idle decision carries a plus-or-minus 25 % hysteresis band so that noise on the speed measurement cannot make it alternate. Covered by unit tests for idle and for starting and stopping.
Knee bending backward
Animate Yourself
Three separate guards, one of which makes it structurally impossible: the bend angle comes from an arc cosine, so the joint cannot pass straight. not fully verified
Animator
Clip playback reproduces recorded joint angles, so a flip comes from an IK pass on top — Unity's per-state Foot IK, or a solver the project adds. Which of those is present is project-specific and is not evaluated here.
Additional detail
The complaint is a knee that solves to the anatomically wrong side.
Three guards. First, the sign is removed from the problem: the IK solver places the middle joint on the pole side by construction rather than rotating by a signed angle about a derived axis. Its own comment records why — an axis taken from a cross product has a sign that depends on the handedness of that product, and getting it wrong bends the knee backward.
Second, the bend angle comes from an arc cosine, whose range is 0 to 180 degrees, so the joint cannot pass straight.
Third, the case where the pole direction becomes collinear with the aim direction — which would reach a fallback that does not know which leg it is solving and would bend both knees the same way — is prevented rather than caught: a floor holds the pole-to-aim angle at 30 degrees or more, smoothed so that it does nothing at all for every shipped preset. Covered by unit tests.
IK pop at full reach
Animate Yourself
The specific discontinuity that is visible as a pop was measured and removed, and two further pop sources are closed. One residual case remains, on stairs. not fully verified
Animator
Foot pinning is an IK pass over clip playback — Unity's per-state Foot IK, or a solver the project adds — and behaviour at full extension is a property of that solver.
Additional detail
The complaint is a one-frame snap at the ankle when the feet are pinned to the ground with IK.
The hard clamp at full leg reach was replaced with a curve that approaches full reach without ever arriving at it. The measurement is recorded in the code: the hard clamp's sensitivity steps from 5.74 degrees per 1 % of leg length to exactly zero at full reach, and that step in the derivative, not the peak sensitivity, is what is visible as a pop. Softening starts at 94 % of full reach by default and is exposed as a setting.
Two further sources are closed. A swing-phase ground correction fades in as its prediction converges, instead of applying at full strength on the first frame of the swing. Every height correction is exponentially smoothed.
A residual case remains, in the stairs-and-step-edges row.
Other body proportions
Animate Yourself
There is no transfer. Motion is generated from ratios measured on the target body itself. One preset on five characters from 1.28 m to 1.87 m gave a step-length spread of 0.9 % coefficient of variation against a 10 % threshold. not fully verified
Animator
Humanoid retargeting normalises a clip through a proportion-normalized muscle space, so joint rotations do adapt across proportions. What it does not preserve is world-space contact points, so a clip authored for one body can still show sliding or foot penetration on a differently proportioned one. The standard partial remedy is the per-state Foot IK option rather than re-authoring the clip.
Additional detail
The complaint is motion authored for one body applied to a much taller, wider or shorter one.
Animate Yourself measures leg chain length, hip width, hip joint height, arm chain length and shoulder joint height on each character, and every amplitude in the settings is a fraction of one of those — step length as a fraction of leg length, stance width as a fraction of hip width.
Measured: one identical preset on five characters spanning 1.28 m to 1.87 m produced a step-length spread of 0.9 % coefficient of variation and 2.4 % range, against a 10 % portability threshold; swing clearance was identical to four decimal places on all five; hip yaw was 14.26, 14.26, 14.26, 14.26 and 14.27 degrees.
One qualification on that portability, in the torso-twist-across-rigs row.
Bone axes and naming
Animate Yourself
Hinge axes are measured per character and their sign fixed by observation. Bones are identified through Unity's humanoid roles, so there is no name string to misspell. not fully verified
Animator
The Avatar's bone mapping is configured per character at import. Unity's Avatar Configuration inspector validates that mapping and reports a structurally invalid one at import time; what is visible only at playback is a mapping that is valid but assigns the wrong bone. Names also appear in code as state and parameter strings, which fail only at runtime.
Additional detail
The complaint is a rig whose bone axes, rotation order or bone names differ from what the motion assumed, producing reversed or wrong-axis movement.
Animate Yourself derives each hinge axis from the limb's own geometry and fixes its sign empirically — it rotates the joint and observes which way the end of the limb actually moved. Authored rotations are expressed in the character's own frame and converted into whatever arbitrary local axes the bone happens to have. Bone identity comes from Unity's HumanBodyBones enumeration through the Humanoid Avatar, so there is no name string to misspell and no clip reference to keep in sync.
Feet floating above ground
Animate Yourself
Ankle height is measured per character, and a ground probe raises or lowers the foot target. The ankle meets its ground target on all five test characters, with no penetration. The drawn sole is a separate measurement, taken at Soft Reach Start 0.95 with Bone Stretch on: it sits 14.3 mm off the surface on average with Sole Grounding off, and turning Sole Grounding on takes that to 0.53 mm. not fully verified
Animator
Retargeting adapts a clip's joint rotations to the target's proportions, but does not preserve the world-space position of a foot contact, so a different ankle height or ground level is visible as floating or penetration unless a foot IK pass corrects it.
Additional detail
The complaint is soles that hover above the floor, or sink below it.
Three mechanisms. Ankle height is measured on the character and subtracted from the ground reference, so a character whose foot bone sits at a different height than the source does not float. Ground conformance raycasts at the position the foot is predicted to land at and raises or lowers the IK target to meet it. Sole Grounding, which is off by default and whose controls are not drawn in the Inspector as it ships, measures the lowest point of the drawn foot and moves the foot target until that point reaches the surface.
The first two are measured at the ankle, and the five-character measurement run recorded the ankle meeting its ground target on all five, with no penetration. The drawn sole is a different quantity, measured separately on three characters walking over flat ground at Soft Reach Start 0.95 with Bone Stretch on: 14.3 mm off the surface on average with Sole Grounding off, and 0.53 mm with it on. Sole Grounding is off by default because posing that character each frame costs 193 to 526 microseconds with it on against 51 to 74 microseconds with it off, which is roughly 3 to 9 times depending on the character, comparing each character against its own cost with the setting off, and because it bends the standing knee further.
Turning on the spot
Animate Yourself
A stationary turn is a step in place: the cycle is floored so it cannot freeze part-way through a stride, and the stance sweep produces zero forward or backward foot travel. not fully verified
Animator
A stationary turn is its own clip or blend tree, usually driven by an angular-velocity parameter. Without one, the character rotates as a rigid body while another clip plays.
Additional detail
The complaint is a character that rotates as one rigid piece instead of stepping around.
Animate Yourself treats a turn as something a step can serve even at zero speed, and floors the gait clock while a turn continues, so the cycle cannot freeze part-way through a stride and rotate as a static pose. The stance sweep tracks actual body travel at both ends of a step, so a stationary turn produces zero forward or backward foot travel — a step in place rather than a foot sliding backward at every pivot.
Covered by unit tests, including a steady-state pivot and a turn beginning part-way through a stop. A residual case is in the head-and-spine-in-a-turn row.
Cost per character
Animate Yourself
Measured at 22 microseconds per character with 150 characters in the scene, against a 50 microsecond per character budget.
Animator
Not established. The Animator pipeline's own per-character cost was not isolated in that measurement, so no comparison is claimed.
Additional detail
The complaint is the cost of animating a crowd.
The 2026-07-31 measurement recorded Animate Yourself at 22 microseconds per character across 150 characters, which is inside a budget set for 50 characters, at three times that count. Rendering was not a factor in that run: disabling every renderer moved the frame time from 36 ms to 35 ms.
This is a measurement of Animate Yourself only. No head-to-head comparison against the Animator pipeline exists, and this row must not be read as one.
Idle that looks alive
Animate Yourself
Breathing and weight shift ship on by default, and the weight shift's period is varied so it does not repeat at a fixed interval. not fully verified
Animator
An idle is one or more authored clips, so keeping a standing character in motion means authoring and looping that motion.
Additional detail
The complaint is that a character held perfectly still appears to be a stopped application, so idle motion has to be authored — and then the repetition in it becomes noticeable.
Animate Yourself ships breathing as a periodic motion and a weight shift whose period is modulated by a noise sample, so it does not land on a fixed interval. Exposed as breathing rate, breathing bob, breathing lean, weight shift period, weight shift period jitter and weight shift sway.
Exposed as a setting (4)
Directional blend gaps
Animate Yourself
The direction of travel is one continuous setting in degrees, and the step sweep is decomposed by the cosine and sine of that heading. There is no authored set of directions for a heading to fall between.
Animator
Each authored direction is its own clip, and a heading between two of them is a weighted blend of the neighbouring recordings. A heading outside the authored set is clamped to the edge of that set.
Additional detail
The complaint is a directional blend space with a gap in it — a heading that falls between the authored directions.
Animate Yourself has a single move-direction field in degrees, from −180 to 180, where 0 is straight ahead, 90 is sideways to the right, −90 sideways to the left and 180 is walking backward. The step sweep is decomposed by the cosine and sine of that heading, so there is no authored set of directions for a heading to fall between.
Feet crossing over each other during a sideways step are handled jointly rather than per leg, bounded by a minimum lateral separation setting. Covered by unit tests.
The fix cascade
Animate Yourself
Partly. The surface is settings rather than states, so there is no transition condition and no timeout to fire at the wrong moment. The remaining half is the state-per-fix row below.
Animator
Each fix adds a state, a parameter, a transition condition or a layer to the controller. Sub-state machines and layers are what Unity provides to organise them; keeping their interactions correct is manual.
Additional detail
The complaint is a chain in which each fix creates the next problem: sliding feet lead to root motion, root motion desynchronises and leads to IK, the IK pops and leads to a smoothing curve, the curve removes the turn and leads to a pivot state, the pivot state deadlocks and leads to a timeout.
Animate Yourself removes the state-machine half of that chain: the user-facing surface is settings, so there is no transition condition, no layer and no timeout.
The honest half is that the layer has no notion of a discrete state at all, which is a recorded architectural limitation rather than an oversight. See the state-per-fix row.
Head and spine in a turn
Animate Yourself
Authored directly as settings: Spine Twist, Chest Twist, Shoulder Twist, and the head's Counter Twist Weight and Lag, plus per-bone look-at weights and angular limits. not fully verified
Animator
Upper-body decoupling is a layer with an avatar mask and its own clips, or a constraint from the Animation Rigging package.
Additional detail
The complaint is an upper body that decouples from the lower body during a turn and ends up facing the wrong way.
In Animate Yourself the relationship is authored rather than emergent: Spine Twist, Chest Twist and Shoulder Twist under Torso, and Counter Twist Weight and Lag under Head, are settings, as are the head, neck and chest shares of a look-at and its Yaw Limit and Pitch Limit.
One defect remains here, in the target-passing-behind row.
The loop seam
Animate Yourself
There is no clip boundary to join. The gait runs on a continuous fixed-step phase accumulator, and per-cycle variation is exposed as noise and jitter settings.
Animator
A looping clip's last frame has to match its first. Loop Pose in the humanoid clip importer is the standard remedy for the pose match; matching velocity and foot phase across the seam remains an authoring concern.
Additional detail
The complaint is the visible join where a looping clip's last frame meets its first.
Animate Yourself has no clip and therefore no boundary: the gait phase accumulates continuously at a fixed internal step. Per-cycle variation is exposed as noise amount, noise frequency, jitter amount, jitter frequency and a seed value, the last of which keeps a crowd of otherwise identical characters from moving in unison.
What this does not solve is in the separate loop-repetition row.
Reduced, not removed (6)
Stairs and step edges
Animate Yourself
Vertical ground conformance ships: a probe at the predicted landing position, foot tilt onto the ground normal, smoothing, and a two-leg hip compromise. Four cases remain open, including a one-frame snap when turning near a step edge. not fully verified
Animator
A clip carries no knowledge of the ground under the character. The per-state Foot IK option applies the clip's own foot goals; matching real ground means setting IK goals from the project's own raycasts.
Additional detail
The complaint is IK that breaks on stairs — an ankle straightening on contact, a leg folding, a character passing through the steps.
What ships: a raycast at the predicted landing position with a forward lookahead during the swing; foot rotation onto the ground normal; a fade-in of the correction as the prediction converges; a hip drop that measures only the increment the ground correction itself adds, so flat ground produces no drop at all; a continuously differentiable compromise between the two legs' demands rather than taking the larger of the two; a rule that stops a foot hanging over a ledge from pulling the other leg's knee; and an adjustable smoothing time. Slope handling adds hip tilt and step shortening.
What remains, all of it written down. Turning near a step edge can still snap a foot or bend a knee for one frame, because a single ray crosses a discontinuity and a large or fast enough turn outruns the smoothing. Teleporting a character without reattaching it leaves the smoothing catching up. A dedicated feature for discrete step heights is not built. And slope adaptation has never been tested on the one test character whose leg reach is already clamped.
Coming to a stop
Animate Yourself
Each leg parks on its own schedule, the last step is shortened, a settling step ships on by default, and restarts are deterministic. Planted-foot travel through a stop and restart went from 567 mm to under 29 mm. Two residuals remain, and none of it is visually confirmed. not fully verified
Animator
A stop is a transition from a locomotion clip to a standing clip, so where the feet end up is a property of that blend rather than a chosen footstep.
Additional detail
The complaint is a stop that slides past its mark, or freezes part-way through a stride with one foot in the air.
Animate Yourself decouples the two legs' cycles so each parks and unparks on its own schedule; shortens the final step so it does not land a full stride ahead of a body that has stopped; brings the trailing foot alongside with a settling step that ships on by default; and makes a restart deterministic by choosing which leg leads, bounding the swing so it cannot outlive the partner's remaining stance, and correcting the shared cycle onto the legs rather than the legs onto the cycle.
Measured: both feet airborne during a restart went from 0.417 s to 0.000 s; the longest restart swing went from 0.967 s to 0.450 s, against an ordinary swing of 0.444 s, over 120 stop phases; planted-foot travel through a stop and a restart went from 567 mm to under 29 mm.
What remains: the last step of a stop lands slightly further forward than the ideal — the median resting distance between the feet went from 116.7 mm to 192.3 mm, accepted deliberately in exchange for removing a 288.7 mm single-frame jump — and the upper body still cross-fades rather than parking. None of this has been confirmed visually in the Unity Editor.
Each new movement mode
Animate Yourself
Partly. A new mode is code plus settings rather than a clip set, and eleven features ship. Ten named modes, including jump, crouch walk and swimming, are not built. not fully verified
Animator
A new mode is a new clip or clip set, plus its state, its parameter and its transition.
Additional detail
The complaint is that every additional movement mode is a fresh authoring project.
Eleven features ship: look-at, run, walk, idle, uneven ground, strafe, slope, arm layering, leg parking with a settling step, limp, and shake and noise.
Not built: jump; turning while moving with a banked lean; aim and point IK; crouch walk; walking backward as its own mode, although a move direction of 180 degrees covers the heading; falling and airborne; landing compression; ragdoll handoff; stairs; and swimming.
Nothing here removes the need to build a mode. It removes the need to author, capture, import and retarget one.
A state per fix
Animate Yourself
No user-facing state machine, so nothing to deadlock and no timeout to fire mid-blend. The recorded limitation is the opposite one: no notion of a discrete state at all. not fully verified
Animator
The controller is the state machine, so every added state, condition and timeout is another interaction to get right.
Additional detail
The complaint is a state machine that grows a state for every fix, until the states interact in ways nobody planned.
Animate Yourself has no user-facing state machine, so there is nothing to deadlock and no timeout to fire part-way through a blend.
The recorded architectural limitation is the reverse one: the layer is a single continuous set of settings evaluated every frame, with no notion of a discrete state, and whether to adopt a state model at all is an open project question. There is an internal leg-cycle state machine — parking, unparking, settling, in sync — which is not exposed, and which the project tracks as a candidate for extraction.
Loop repetition
Animate Yourself
Not solved, and the project's own standing decision forbids claiming it is. There is no seam and there is per-cycle noise, but noise cannot produce a variation someone chose. not fully verified
Animator
The same clip replays identically each cycle, so variation means authoring more clips or selecting randomly between them.
Additional detail
This is separate from the loop-seam row: the complaint here is not the join, it is that the walk never varies from one cycle to the next.
Animate Yourself has no seam, and has per-cycle noise. The project's own recorded decision is that noise is not the answer to repetition: noise varies every cycle and cannot produce a deviation a designer chose, which is what stops a repeating cycle from being noticed as one. The feature that would — override sequences — is catalogued and not built.
The decision is written as a prohibition: do not treat repetition as solved.
Capsule vs body
Animate Yourself
The two cannot disagree about speed, because the animation is derived from the capsule's own measured displacement. They can still disagree about the ground: the feet are visual only, so a foot that misses a ledge edge floats. not fully verified
Animator
With root motion off, the clip's stride and the capsule's speed are two separate numbers kept in agreement by hand. With it on, travel comes from the clip and the controller has to accept that.
Additional detail
The complaint is a collision capsule that moves through the world while the visible legs produce a different motion.
The speed half is closed: the animation is derived from the capsule's own measured displacement, so the two cannot disagree about how fast the character is travelling.
The remaining half is deliberate and recorded. The capsule is authoritative for where the body goes, and the feet are visual only. A foot that misses a ledge edge floats; it does not cause the character to trip, become unbalanced or fall.
Animate Yourself has this problem too (7)
Arms clipping the body
Animate Yourself
Present, for arms. The three reach limits constrain the shoulder's reach direction only, so a hand target near the chest can still let the forearm pass through the torso. A real fix is specified for a later version.
Animator
Clip playback performs no self-collision either, and a hand driven by an IK layer can reach into the body the same way.
Additional detail
The complaint is a limb passing through the character's own body.
In Animate Yourself this is a recorded known issue for arms: the reach-up, reach-across and reach-behind limits are one shared window applied to the shoulder's reach direction, not to each arm segment, and they constrain direction rather than distance. So a hand target near the chest can still let the forearm pass through the torso.
A real fix is specified for a later version — collision against a capsule approximation of the torso, with the solver pushing the elbow out of it — and is explicitly not a clamp on a target point, which is what was tried and which constrains the wrong body part.
Legs are separated by a minimum lateral separation rule. Leg intersection during a hard turn is recorded as rare, brief and accepted.
Do not read this row as a claim that self-clipping is solved.
Frame-order latency
Animate Yourself
A live, undiagnosed instance. The component that measures speed carries no explicit execution order, so whether it samples the position change before or after the controller has moved is unspecified.
Animator
Parameter changes take effect on the Animator's next evaluation. Script Execution Order and the Animator's update mode are what a project sets to make that order deterministic.
Additional detail
The complaint is a one-frame delay between an event and the animation responding to it.
Animate Yourself has an open, undiagnosed instance. The driver that writes bones carries an explicit late execution order; the component that measures speed does not. So whether it samples the character's position change before or after the controller has moved that frame is unspecified, which modulates the measured speed by the ratio of consecutive frame durations.
A one-setting test that would decide it — switching off speed measurement from displacement — is written down and has not been run. Tracked in the project backlog.
Non-humanoid rigs
Animate Yourself
Not supported. A Humanoid Avatar with hips, head and both complete leg and arm chains is required; without them the component reports the character as unmeasurable.
Animator
Generic rigs are supported by playing clips authored for that specific skeleton. Humanoid retargeting itself also requires a Humanoid Avatar.
Additional detail
The complaint is a character that is not a two-armed, two-legged human: a quadruped, a spider, a character with a tail.
Animate Yourself requires a Humanoid Avatar with hips, head and both complete leg and arm chains, and reports the character as unmeasurable without them. Multi-legged gaits and secondary appendage motion such as a tail or a ponytail are both catalogued and not built.
This is a hard scope boundary, not a gap a setting can close.
Finger mapping
Animate Yourself
Neither caused nor fixed. No finger bone is written anywhere in the product, so a character with a broken finger mapping still has one.
Animator
Retargeting maps fingers through the Avatar's own finger configuration, so a character mapped wrongly plays back wrongly.
Additional detail
The complaint is finger chains that map badly between rigs.
Animate Yourself writes no finger bone at all, so a character whose finger mapping is broken still has a broken finger mapping. Hand and finger IK is catalogued and not built.
Wrist twist and skinning
Animate Yourself
Neither caused nor fixed. These are skin deformation and twist-bone setup, which belong to the character's rig.
Animator
Same. Deformation belongs to the rig's skinning, whatever produces the bone rotations.
Additional detail
The complaint covers forearm twist collapsing the mesh, twist bones, and weight painting. It was the most frequent complaint in the rig-retargeting part of the source material.
These are skinning and deformation problems, not motion generation problems. Animate Yourself writes bone rotations and inherits whatever deformation the character's rig produces from them: a rotation this system produces will show an existing wrist twist problem exactly as any other rotation would. Twist bone distribution is catalogued and not built.
Do not read this row as a claim for either column.
Torso twist across rigs
Animate Yourself
A recorded inconsistency: a character that maps one of the two chest bones and not the other twists less than one that maps both. It is not corrected, because no character measured here has either of those two mappings.
Animator
Not established here.
Additional detail
This was not one of the original complaints. It was found while checking the body-proportions row, and it is listed because it qualifies that row.
The known issue reads: the chest's turn is split between the Chest bone and the UpperChest bone, so a character that maps one of the two and not the other receives only that bone's share and twists less than a character that maps both. Portability across characters is the property the whole normalisation design exists to protect, so this is a real inconsistency rather than a cosmetic one. It is left as it is, because no character measured here has either of those two mappings: the ones that were checked map both chest bones or neither.
A character that maps neither chest bone is a separate case and was fixed 2026-09-11. Its chest turn used to reach no bone at all, so Chest Twist moved nothing on it; that turn now goes to the neck, or to the head when the character maps no neck, and to both collarbones. The chest's own mesh deformation is the one part that cannot be recovered on a character with no chest bone.
No comparable measurement was made for the Animator pipeline, so that column states nothing.
Target passing behind
Animate Yourself
A recorded defect: the upper body snaps to the other side when a look-at target crosses directly behind the character. A likely cause is identified, not investigated in code and not fixed.
Animator
A look-at is Unity's own humanoid look-at IK or an added constraint, and behaviour at that wrap point is a property of whichever is used. Not evaluated here.
Additional detail
The source material's image of a head turning backward has a real counterpart here.
The known issue reads: the upper body snaps to the other side when the look-at target crosses directly behind the character. A likely cause is identified — the yaw computation wraps at ±180 degrees, and the angular limit is applied to that already-discontinuous raw value before the tracking step sees it — but it has not been investigated in code, is not fixed, and needs a Play-mode reproduction. Tracked in the project backlog.
Open questions, not settled either way (7)
Whether it looks right
Animate Yourself
Not established. The features are verified numerically and recorded as not visually confirmed, and no test fixture runs a complete pose against a real skinned character. not fully verified
Animator
A clip is a recorded performance and can be watched before it ships. Whether it still looks right after retargeting onto another character is the separate question in the body-proportions row.
Additional detail
This is the largest open question, and it applies to most of the rows above it.
The project records look-at, run, slope adaptation, arm layering, starting and stopping, the settling step and the restart work as not visually confirmed. It has no test fixture that binds a real character, so a complete pose evaluation, the arm IK application and a parked leg's settle ramp have never run against a real skinned character.
A verdict of "handled with no setup" on this page therefore means the mechanism exists, is reachable, and produces the right numbers. It does not mean somebody has watched it and it looks right.
The Animator column states the one thing that is structurally different rather than better: a clip is a recorded performance, so its appearance is fixed and can be watched before it ships. Whether it still looks right after retargeting onto another character is a separate question, and it is the body-proportions row.
Reported jitter
Animate Yourself
Open, not reproduced and not measured. One setting decides it and has not been switched. not fully verified
Animator
Not established here.
Additional detail
A report of leg motion appearing to update below the frame rate is recorded as an open, undiagnosed issue.
The fixed-step internal loop is excluded by construction, because the phase handed to the evaluation is accumulated real time multiplied by the rate, at any frame rate. The remaining candidate is the unsmoothed, execution-order-dependent speed measurement in the frame-order-latency row.
The one-setting test that decides it — switching off speed measurement from displacement — is written down and has not been run. Nothing has been reproduced or measured, so no verdict is given for either column.
Slope on a clamped rig
Animate Yourself
Not established. Slope adaptation has never been tested on the one test character whose leg reach is already clamped, which is the character flagged for it. not fully verified
Animator
Not established here.
Additional detail
The project's own roadmap flagged one specific test character — the only one in the five-character measurement run whose leg reach is clamped — as the character to test slope adaptation on, and the project records that as still owed.
The slope part of the stairs-and-step-edges row is therefore unconfirmed on the character most likely to break it.
Whether a stop reads right
Animate Yourself
Not established. The numbers are inside their bounds; nobody has judged how the stop appears on the short-legged test character named for it. not fully verified
Animator
Not established here.
Additional detail
The known issue for stopping names one specific test character — 1.28 m, short legs — as the one to judge the resting distance between the feet on. That has never been done.
This is the difference between the numbers being inside their bounds and the stop appearing as a stop.
Cost compared to Animator
Animate Yourself
22 microseconds per character, measured. No comparison is claimed. The mark on this row is the could-not-settle kind: the measurement stands, and the comparison against the Animator pipeline was never made. not fully verified
Animator
Not measured. No head-to-head number exists.
Additional detail
The per-character cost of Animate Yourself was measured at 22 microseconds. The Animator pipeline's own per-character cost was not isolated in the same run.
The project's own competitive analysis states this explicitly and declines to claim a performance advantage. This row exists to record that the comparison has not been made — not to imply either direction.
Foot through the run blend
Animate Yourself
Not established. The drift measurements vary speed; they do not vary the two settings the walk-to-run blend interpolates. not fully verified
Animator
Not established here.
Additional detail
The foot-sliding measurements vary speed, which is what drives cadence. They do not vary the two settings the walk-to-run blend interpolates — duty factor and step length — and stance reach, the unit the whole sweep is expressed in, is the product of those two.
The shipped tests for the run blend cover its weight functions, not planted-foot geometry through the blend. Untested and unmeasured.
Foot slide on a slope
Animate Yourself
Not established as a number. A residual slide on slopes is documented and unquantified: the horizontal sweep is shorter than the surface distance travelled. not fully verified
Animator
Not established here.
Additional detail
The project's own roadmap records a known residual: on a slope, the horizontal step sweep is shorter than the distance actually travelled along the surface, so a small slide remains.
"Small" is not a number, and no measurement exists. The foot-sliding row's figures are flat-ground figures and do not cover this case.