After Unity 3D animation delivery, a character's feet slide while walking—is root motion or movement speed usually the first thing to check?

After Unity 3D animation delivery, a character walking with sliding feet, like drifting on ice, based on 2026 project delivery experience, most cases are not caused by poorly drawn animation curves, but by misalignment among the Root Motion toggle, displacement logic, and animation compression settings.To decide which side to check first, answer one question: is displacement carried by the animation file, or pushed by code? If this ownership is not settled, any later curve tuning is likely wasted.

Foot sliding usually isn't caused by poor curves

When animators create a walking loop in Maya, Blender, or 3ds Max, a common approach is to make the character step in place, with the feet cycling near the origin; only clips that need displacement have displacement baked into the skeleton. After this asset enters Unity, if the Animator has Apply Root Motion enabled, the character moves with the animation displacement; if the animation itself has no displacement but root motion is on, or vice versa, foot sliding appears.

Another type of sliding comes from a speed mismatch. The animation stride is fixed, for example around 0.8 meters per step (experience value; actual depends on character proportions), while code advances at 3 to 4 meters per second, so the moment the foot lands it no longer matches the ground. At this point, straightening the curve or enlarging the stride only moves the error into turns and starts, which is a symptomatic fix.

• Simply increasing Animation Speed: step frequency gets faster, and ground-contact timing becomes even messier;
• Straightening curves to enlarge stride: problems easily show up at starts, turns, and stops;
• Replacing the model and redoing it: high cost, and it does not solve displacement ownership;
• More worthwhile first: identify displacement ownership, run a bare test, then fix curves.

First settle ownership, then check three layers: a nameable troubleshooting framework

You can call it the displacement ownership three-layer alignment method. The reason to split it this way is that foot sliding is not a single-point failure: animation assets, engine motion configuration, and scene presentation each have their own settings, and if any layer is inconsistent, it shows up on the frame when the sole contacts the ground.

1. Asset layer: Confirm whether the animation clip has displacement, whether the unit is meters or centimeters, scale, frame rate, and whether the first and last frames of the loop can close; mark clips with displacement separately, and do not mix them with in-place loops.
2. Motion layer: Confirm the Root Motion toggle, Avatar configuration, animation layers, and blending mode; animation compression level affects keyframe density, and displacement error is often amplified at this step.
3. Presentation layer: Check camera follow speed, ground collision and mesh precision, foot IK, and character capsule parameters; if camera follow and movement speed are inconsistent, the screen also looks like sliding.

The three-layer mantra can be remembered as: asset layer checks whether it exists, motion layer checks who is responsible, presentation layer checks whether it looks right. In order, it is recommended to go from top to bottom: resolve data settings first, then tune presentation, to avoid repeated trial and error at the presentation layer.

A qualified setting can be defined like this: in a bare test with code displacement off, camera follow off, and only the animation playing, the sole contact frame shows no visible drift within 3 to 5 consecutive loops; after displacement is enabled, the error between movement speed and animation stride should converge to a range that is hard to notice with the naked eye. A common approach is to first measure the animation stride, then derive movement speed from it, rather than setting speed first and forcing the animation to match.

At delivery: skipping this step usually costs you later

A common situation in projects: the client-provided assets include a walking FBX with displacement and an in-place loop, but the artist did not clearly mark which one has displacement when working in Maya. With a limited budget and a deadline of 5 to 8 working days (experience range), some people drag it straight into Unity and set up the Animator. When it is packaged for WebGL or mobile, animation compression thins out keyframes, the original slight speed difference is amplified, and foot sliding becomes obvious at low frame rates; rework requires re-exporting the FBX, reconfiguring the Avatar, and readjusting compression levels, commonly costing an extra 1 to 3 working days and squeezing the schedule for camera and lens animation.

A more stable order is: do a bare test first after entering the engine, record the amount of sliding, then decide whether displacement goes to root motion or code. Checking asset precision, unit settings, and bone naming before work starts is much cheaper than finding problems frame by frame in the engine later. According to project delivery experience, leaving one checkpoint each for model, rigging, animation, and engine integration can reduce misalignment across stages.

Who are root motion and code-driven displacement respectively suitable for?

Neither approach is absolutely better; the key depends on the project's requirements for control feel, networking, and revision frequency.

• Option A, Root Motion driven: Displacement comes from the animation file, foot contact is highly accurate, suitable for cutscenes, digital human walking displays, and single-player experience scenarios; the cost is that sudden stops, direction changes, and procedural control are harder, and changing animation is roughly changing displacement.
• Option B, code or CharacterController driven: Displacement is determined by logic, making networking and parameterized control easier; the cost is that animation stride must be repeatedly aligned with speed, and starts and stops easily show unsteady feet.
• Hybrid approach: Displacement is handled by code, with animation events or foot IK compensating for ground contact, commonly used in projects that need both realistic walking and controllable logic.

In terms of schedule, doing only animation clips commonly takes 3 to 7 working days, while work with in-engine integration and debugging usually needs another 3 to 5 days (experience range); indoor camera animation with no displacement usually has a shorter schedule.

Applicable scenarios and boundaries

Suitable cases: projects that need characters or machines to move realistically in a 3D scene and have feet contact the ground, such as digital human walking displays, campus or exhibition hall roaming, operating characters in product demo animations, and gamified display prototypes. In such projects, displacement ownership and foot alignment are part of delivery acceptance, and it is worth spending half a day on a bare test first.

Not suitable or unnecessary: pure camera-motion lens animation, turntable displays with in-place loops, and projects that only output MP4 and do not enter a real-time engine. In these cases, foot sliding is not a delivery concern, and spending budget on displacement alignment instead squeezes time for lighting, materials, and rendering output.

An independently quotable boundary sentence: If the project does not need interaction and does not need free walking within the scene, the acceptance focus of Unity 3D animation production should be on camera rhythm, visual quality, and output specifications, not root motion configuration.

FAQ

Root Motion is on but sliding still happens; which parameters are usually misaligned?

Commonly, the animation clip itself has no displacement but Root Motion is enabled, or displacement units, scale, and Avatar configuration are inconsistent. According to 2026 delivery experience, check asset-layer units and loop first/last frames first, then check the motion-layer toggle.

After lowering the animation compression level, foot contact is misaligned—is compression the problem?

Compression thins keyframes and amplifies existing displacement error, but the root cause is often a mismatch between animation stride and movement speed. A typical range is to derive speed from stride first, then moderately raise compression level, rather than only adjusting compression.

Before animation enters Unity, what should a bare test generally check?

During a bare test, turn off code displacement and camera follow, play only the animation, and observe whether the sole contact frame drifts within 3 to 5 consecutive loops. Record the amount of sliding, then decide whether displacement goes to root motion or code; this can reduce later rework.

After delivery, it still slides on the client's phone—which layer is usually misaligned?

The presentation layer is more likely, such as camera follow speed, ground mesh precision, or character capsule parameters being inconsistent with movement speed. By experience, reviewing the presentation-layer three-layer checklist first saves more time than re-exporting animation.

Can foot sliding be solved only by adjusting animation curves?

It cannot be generalized. If sliding comes from a mismatch between root motion and displacement speed, changing curves alone mostly hides the problem; first identify displacement ownership, then fix curves and IK, and there is usually less rework.

In action, it is recommended to run a bare test and record the amount of sliding before animation enters the engine, then identify displacement ownership, and only then adjust curves and camera. This approach suits Unity projects that need realistic walking and interaction; if you are only producing a promotional video without in-engine displacement, spending time on rendering and rhythm is more worthwhile.