In this guide
Agree which system owns character displacement before diagnosing foot sliding. A clip can carry forward motion in its root while gameplay code also moves the character, or it can animate in place while the controller supplies a mismatched speed. Both situations can make convincing source animation fail in the game.
Record the clip, rig revision, importer, controller state and receiving engine. Keep animation acceptance separate from a file merely containing a skeleton and animation tracks.
Define displacement ownership
For each locomotion state, identify whether displacement comes from the animation or the controller. Include transitions, turns and exceptional movement. A general project preference does not explain a state that intentionally behaves differently.
Unity’s root-motion explanation describes how animation motion relates to movement of the character object.1 Use the receiver’s actual root-motion and import settings when reviewing the handoff; settings from a source preview do not automatically transfer.
| Observation | Inspect | Evidence to save |
|---|---|---|
| Character moves too far | Root displacement plus controller movement | State and movement settings |
| Feet slide during steady travel | Clip cadence versus actual speed | Fixed-camera playback |
| Jump at loop boundary | Root curve and loop conditions | First and last state comparison |
| Problem only during blending | Transition timing and blend behavior | Reproducible state sequence |
Begin with one clip and a visible ground reference
Use a simple test scene, a clear ground grid and a fixed camera. Play the clip without the full gameplay stack where possible. Observe foot contact, root displacement and loop closure. Then add the controller’s movement according to the intended design.
For a proposed test, measure the intended travel during one loop and compare it with the controller’s travel over the same duration. Distance divided by time gives the implied average speed. This does not validate every contact frame, but it reveals gross speed disagreement before fine adjustment.
Diagnose contact and retargeting separately
If the isolated clip already slides, inspect the authored contacts and root curve. If it works on the source rig but not the receiver, inspect retargeting, scale and pose differences. If it only fails in transitions, inspect blending rather than resaving the same source clip repeatedly.
Keep foot locking, inverse kinematics and ground adaptation identified as additional systems. They may improve contact, but should not conceal an unresolved displacement contract. Document which systems were active in the acceptance recording.
Include transitions in the receiving test
Review idle-to-walk, speed changes, turns and stop conditions used by the game. A loop that works alone can still jump when its first pose disagrees with the preceding state. Specify the states required for acceptance, not an unrestricted promise of animation readiness.
Download the locomotion handoff sheet. Pair it with the scale diagnosis and game-ready checklist. The Rendora game workflow can package supplied rig sources and traceable evidence; successful gameplay playback must come from the receiving project.
Animation questions
Is root motion better than in-place animation?
Choose according to control, networking and movement requirements. The receiving team needs a clear contract and state-specific tests, not a universal winner.
Can a rigged GLB prove the character is game-ready?
It can carry relevant source data. Retargeting, controller behavior, contact and gameplay transitions still need their own review.
References
- Unity, Root motion, checked October 26, 2026.
About this guide
Rendora publishes practical guides for teams working with configurable 3D assets and traceable production handoffs. Updated October 26, 2026.