Pros and cons to root motion animation

Alex_J

Does anybody have some experience using root motion animation in games?

I want to test if a few of my assumptions are correct. I am using UE5 and multiplayer is not a consideration here. I have tested root motion for a third person player controller and decided that it was better to use in-place animation for that.

The reason for that decision were mostly because I'll be making many fine adjustments to player speed / agility. Easier to just change numbers compared to retime animations.

But for AI characters, it seems like there could be a few key benefits.

• If I wanted an enemy to make a lurching side to side motion, that is just one step if it is baked into the animation. Whereas with in place, I'd need to break the animation into parts (like is typical for a jump) and then get the actual side to side locomotion through code. Much more work.
• Authoring root motion animations is simpler, and most animations in game are AI, not player.
• can have locomotion that doesn't have to be perfectly cyclical. For instance, take a slow sneaking step, pause, take another. Whereas in place animation needs to be cyclical (I guess you could code it to match an non-cyclical animation, but who has time for that)

But what you lose is similar with the player controller. That is, lets say I want to globally adjust enemies speed. If they all use root motion animations, that simply is not possible, right? I'd have to retime every animation manually?

If that is true then root motion is pretty much a no-go. I prefer to have data entry such that AI speed is set as a percentage of player speed. So if I decide that player should move faster and change that, all AI speed matches it. That wouldn't work if I have to adjust speed per animation.

So, major considerations in order of priority:

• ease to adjust locomotion speed for game balance
• ease of authoring
• foot sliding, visual quality are tertiary concerns (its fast paced shooting and not AAA game, nobody is going to notice or care)

Of course this is testable, but I didn't have a ton of confidence that I was doing things exactly correct when working with root motion previously, so figure I'd poll the audience to get an idea if I'm at least in right ballpark or not.

Eric Chadwick

Why not both? I'd recommend most animation to be done as in-place. Calculating offsets with baked-in motion of the root gets really complex.

If you need a lurch animation with in-place, you could calculate the animation offset of the new ground position and reverse-transform to get the new root position for the next animation. Keeping it essentially in-place motion.

Alex_J

Thanks for the reply @Eric Chadwick ,

I am not sure I understand exactly.

Do you mean that the animation is authored with root motion, meaning any forward/backward or left/right locomotion comes from that root bone. An example is like this:

If I remove keys from the root bone for this animation, the jump will no long make the model actually move forward. It becomes in-place animation.

So if I understand correctly, the animations could still be authored with root motion, but in unreal the root motion could be disabled, and then through code we can identify the difference between where the root is compared to the center of the character… actually now that I type this out, it's not making sense so I must be completely lost.

I guess it might be better to ask, what do you mean by "animation offset" and "new ground position"? If the animation arrives to the engine as in place, the engine has no way of knowing what the intended locomotion is meant to be? In other words, if I want the jump to go five feet, or five thousand, there is no way to determine that programmatically, right? It would just have to be hard-coded in per animation?

Eric Chadwick

Ask yourself: How will your satyr character play its next animation, after finishing the jump?

If the offset is baked into the jump animation, the root is still where it started, back at the launching point. Which means the next animation will snap the satyr back.

In-place animation is probably the better way. It would not move forward in the animation. Your root node would need to be moved to where you want the character to land, so the next animation starts from there.

sprunghunt

One advantage of root motion is that the capsule collision will move around with the root of the character.

If you make a jump animation like the satyr you have there with root motion then the player, or other AI, will be able to collide correctly with the model while the jump is happening. If you do it without root motion it'll be possible to clip with the character during the animation.

In the case of an animation that is intended to dodge weapon fire, like the 'lurch' animation you mention, it may be more important to have the capsule move.

Alex_J

Thanks @sprunghunt

After more testing things out I've learned a few things - some of it probably just caveats of unreal.

So unreal is by default creating a physics asset for skeletal mesh characters. You might not always need it, however in my case I use it both for ragdoll physics plus I also use it for body part hit detection. It's just simplified shapes that act like children of the major skeletal bones, so it moves along with animations.

Becuase I am already using that for hit detection, I don't actually need the basic capsule for anything (although its still used by unreal for AI navigation, and I also use it for simple queries).

So for locomotion animations, say like the side to side lurch or something I've actually implemented is a bounding jump, I was able to forego root motion and instead just move the hips, hands, feet such that the skeleton moves up down, side to side, but the root joint can stay in place. I still get the desired motion that makes it difficult to hit the enemy, but I also get the flexibility of being able to adjust the enemies speed without having to adjust any animations.

It's not perfect, like animations still have to roughly match to the speed, but it offers a lot more flexibility compared to deriving all velocity from the animation itself. Unreal also throws a little caveat at you in that root motion won't override the up axis velocity unless you set the characters movement mode to flying... this introduces a few weird issues but it can be worked around just by putting the up motion into the hips, hands, feet, rather than the root joint.

This seems to work out pretty well for my purposes. Here's an example of what I've done so far with a dive animation:

The top arc is the hips motion, and the bottom is the root. So the root drives forward/side to side velocity in the engine, but to get up/down I have to add that to the other joints (again, that might just be an unreal specific caveat)

I also tried doing the dive as in place but for something like this, it's just a lot more simple to animate the motion with the animation, rather than trying to match it in code. But this is just a one-off edge case type of thing.

Same thing here for a leaping animation:

This one I did before learning about the up axis deal in unreal. So the root actually has Y axis movement on it. But instead of doing that, I just just move the rest of the skeleton up, and then in unreal it is interpreted as an inplace animation. This works at least in my case because these characters only leap like this while in big outdoor environments, so clipping through a ceiling doesn't become an issue, and like I said we test bullet hits against their physics asset.

Like you mentioned @sprunghunt, for something like lurch side to side while running, if I went too far with it and say the character is moving down a narrow corridor, the skeletal mesh could end up clipping through walls. But so long as we are not going beyond the radius of the capsule collider (or we are just out in the open without stuff to collide with), it seems like it won't be deal breaker. Compared to the complexity of either having to code really complex movement and then having tons of animations to blend between, it seems like this should be the simplest approach and work in most scenarios.