Pros and cons to root motion animation

Replies

• 
  Offline / Send Message

  Eric Chadwick admin

  Apr 2023

  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.

  1 · Share on FacebookShare on Twitter
• 
  Offline / Send Message

  Alex_J grand marshal polycounter

  Apr 2023

  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?

  0 · Share on FacebookShare on Twitter
• 
  Offline / Send Message

  Eric Chadwick admin

  Apr 2023

  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.

  1 · Share on FacebookShare on Twitter
• 
  Offline / Send Message

  sprunghunt polycounter

  Apr 2023

  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.
  

  1 · Share on FacebookShare on Twitter
• 
  Offline / Send Message

  Alex_J grand marshal polycounter

  Apr 2023

  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.
  

  
  

  0 · Share on FacebookShare on Twitter