I've downloaded a bunch of (free) 3d warriors with animations. I've noticed for about 25% of them, the 'run' animation physically moves the character forward in the z direction. For the other 75%, the animation just loops with the characters feet moving etc., but does so in place, without changing the character's physical location.

I could fix this by:
1.) Manually updating the transform in code for this 75%, to physically move the character
2.) Alter the animation by re-recording it, with a positive z value at the end (when I did this it caused the character to shift really far away the rest of the units, probably something to do with local space vs world space I haven't figured out yet).

But before I go too far down this rabbit hole, I wonder if there is any kind of standard? In the general case, are 'run' / 'walk' animations supposed to move the character themselves, or is it up to the coder to manually update the transform while the legs move and arms swing in place? Is one approach objectively better than the other, or maybe it depends on the use case? If so, what are the drawbacks of each? I know nothing about animation, so I don't want to break convention (if there is one).

  • 3
    \$\begingroup\$ The reason that you see both conventions in use is because both conventions are in use. So there's not one universal way games are "supposed" to do it. Different games make different choices here. \$\endgroup\$
    – DMGregory
    Jan 21, 2021 at 16:42

1 Answer 1


Animations in which the character translates away from the origin are said to contain "Root Motion" - because the root bone moves.

This allows the animator to directly author subtle non-uniformities in the movement speed, in a "what you see is what you get" fashion. Say the character slows down slightly as their foot makes contact with the ground, then speeds back up as they push off again. Incorporating this via the movement script would be messy and error-prone.

By allowing this root motion to drive the movement of the game entity, we get a very close match between what the animator authored and what the player sees - minimizing mismatch errors like foot sliding.

But it can also make it more difficult to change and direct that motion at runtime. Your animations might cover a walk of 1.4 m/s and a run of 2.2 m/s, but if the player's input maps to a movement of 1.7 m/s the two might not blend cleanly to make this intermediate speed. Or if the only turning animations you have are 45 degree turns, then the player character ends up walking in a half-circle in order to turn around.

That makes root motion useful for naturalistic motion and performance capture, where you want all the little inconsistencies of a real creature's movements incorporated in the final result, and you're willing to sacrifice some amount of runtime control to make it happen. Cutscenes or special actions that happen with some fixed alignment (like interactions with cover) will often use this style extensively.

Animations where the character does not translate away are called "In-Place" - because the character stays in one place, like walking on a treadmill.

This makes it easier to blend and transition the animation with other animations the character can do, because they're all aligned at the same position/orientation.

The way the character moves through the scene is entirely up to the movement scripts, giving the programmer and game designer a lot of freedom to control the movement, pivoting to just the right angle or dialing the speed up and down. This can also make it easier to layer the animation with procedural motions like a jump that snaps to a target point, a rail/ledge to follow, or a moving object to ride.

The downside is that the scripted motion layered on top can look mechanical, and disconnected from the movement of the character's limbs. Seeing feet that appear to slide or swim across the ground, rather than making stationary contact and convincingly propelling the character, is a common artifact of this approach.

Some of this can be ameliorated by using IK (Inverse Kinematics) to nudge limbs to match their intended contact points. Or it might not be a big deal at all if you're animating something non-naturalistic, like a stylized cartoon character or a hovering sci-fi object or otherworldly alien creature. Or if your viewpoint is far enough away that those little misalignments don't really show, like in a city builder/god game/RTS.

So both approaches have their benefits and drawbacks, and as a result they're both used - often even in the same game, for different actions or at different stages of production.

Fortunately, Unity gives you powerful tools to decide how you want to use root motion, allowing you to use it to drive a body's movement through the scene, or bake it out if you want to work with it as an in-place animation. So you can change your mind easily as you iterate on your project and find what works best for getting you the results you need, and the way your team likes to work.

  • \$\begingroup\$ Are the modeled animations different, in practice, based on whether they're intended to be used with root motion or in-place? \$\endgroup\$ Feb 10, 2021 at 16:49
  • \$\begingroup\$ A modelled animation that's intended to be used with root motion will contain root motion. \$\endgroup\$
    – DMGregory
    Feb 10, 2021 at 16:52
  • \$\begingroup\$ Sorry – I meant does the way that animations are originally created when modeled differ based on whether it's intended to be used with root motion or not? I was thinking that, if an animation was intended to be used in-place, one might not want the same kinds of 'naturalistic inconsistencies' were it to be used with root motion. \$\endgroup\$ Feb 10, 2021 at 16:57
  • 1
    \$\begingroup\$ Sounds like you've reasoned an answer to your question. \$\endgroup\$
    – DMGregory
    Feb 10, 2021 at 17:01
  • \$\begingroup\$ Seems you like you've cryptically confirmed my query! \$\endgroup\$ Feb 11, 2021 at 16:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .