Reasons to not use Root Motion

Question

Engine: Unity

3D tool: Blender

Since the start of my game dev endeavour, I can't seem to decide on the type of animation system I want to use.

Can someone please give me reasons why you would NOT use root motion and maybe a real world example, because currently I see no reason to not use root motion. I understand the loss of control when using root motion, but from my understanding, the amount of control is "enough".

Treadmill motion(stationary animations) seems like it wont look good enough because you have to perfectly match your move speed to animations. I just need either a resource or proper answer on the specifics about why you would use one over the other or a blend(treadmill for walking, root for jumping etc).

Appreciate any help provided.

Answer 1

This is coming from the perspective of Unreal 4. I am not too familiar with Unity's root motion system, so forgive me if this isn't 100% relevant.

The primary benefit of root motion is your character follows the movement curve of the animation. This means if your animation has variable movement speed, the character SHOULD adjust their speed accordingly. This allows the animator to have full control of the movement speed. An example of this would be a single animation that has the character running forward, stopping, and then starting to run backwards. When using root motion, the feet of the character should plant at the proper time, without any modification. This is obviously the desired behavior, and it saves the programming team the time of having to procedurally re-create the variable speed of the character to keep the feet planted.

The primary downside to root motion is the game engine needs to support it in all of it's systems. In the case of Unreal 4, Root Motion is NOT supported on the Navmesh out of the box, so any root motion done will not check the Navmesh to see if the position being moved to is valid. Root Motion is also limited in multiplayer in Unreal 4. This is because the default movement replication system works best with a more constant movement speed. It is easier to predict movement in multiplayer when the movement speed isn't fluctuating all the time.

So at the end of the day, the choice is dependent on a few key factors:

1. Does your engine fully support root motion out of the box? If it does not, would it be easier to modify the engine to support it, or would it be easier to do it with stationary animations?

2. Who needs to control the speed of the character, the animator, or the programmer? In the case of a single player only game, designed to be as realistic as possible, it is probably fine to use root motion (unless there is a lack of support for something single player related, such as naviation). In a multiplayer game, it is most likely better for the programmer to control the movement speed (for movement prediction), and thus you should not use root motion.

Answer 2

It's a bit of a necro but since I came here looking for answers to a problem:

Root motion is the best visually, but it badly interacts with the other systems. I'm debugging a glitching-through-walls issue right now and I strongly suspect that root motion is the culprit. The whole interaction with things such as physics and navigation is more difficult when using root motion. Your animation tells the agent to move forward at this speed, but the navmesh agent wants to rotate, etc.

It also means you need to have your finished animations early on. When I control my AI agents with code (Transform.translate or NavMesh agent) I can use placeholders until fairly late in the game. And I can model their behaviour exactly without worrying about animation details.

Root motion is easier for the animator, but more difficult for the coder. Not using root motion is the other way around, then the animations need to handle different scenarious, and you need to set up your animator component properly.