Root Motion vs. No Root Motion

Unity Engine
1

Today I’m playing around with combining character components (CharacterController, CharacterMotor, and FPSInput) with Mecanim locomotion animation. I’ve run into a fundamental choice, and I’m a bit torn as to which will result in more long-term happiness:

Should I have the animator apply root motion, or not?

My first instinct is “not” because the CharacterMotor and CharacterController already do a great job of moving the character around. Indeed, if I switch to using Animator root motion, I think CharacterMotor at least will no longer be usable. It also means that the motion of my character in the world is very much tied to the model and animations — I can’t easily tweak the speed or turn rate a little bit to fine-tune the gameplay, for example.

So I started down that path, blending walking and running animations according to speed, and simply rotating the whole shebang for turning. It looks and feels great! …But then I came to turning in place (i.e. while standing still), and this is driving me nuts.

Without root motion, it’s very hard to match the actual rotation of the character to that implied by the animation. Unlike walking and running, which are fairly steady, turning in place is very much NOT a steady rotation, and the best I can do still looks like the character’s standing on ice while wearing banana-peel shoes.

I know that with Pro, I could define curves on the animations, and drive the turn that way… but I’d prefer not to rely on Pro features if possible.

So. What’s considered current best practice these days for making a Mecanim character walk, run, and jump around a level?

Thanks,

  • Joe
2

Mecanim is new enough that I don’t think there are any best practices yet. A couple developers posted their experiences with early versions of Mecanim on Gamasutra, but Mecanim is changing so fast that their articles are terribly outdated now.

Root motion certainly has its advantages – you don’t need to fiddle with movement values, it more accurately reflects frame-by-frame movement, etc. If you want a run/walk cycle to speed up, just increase the speed of the state.

Here’s what I’ve come up with so far.

The Mecanim Example Scenes project does in-place rotation using a blend of several root motion in-place clips varying from 0-degrees to 180-degrees to allow characters to turn to any arbitrary angle.

My locomotion state machines, on the other hand, have usually supported in-place rotation procedurally, without root motion, while all the other animations (walking, running, etc.) in the state machine use root motion. This is because I’m working on a third-person shooter. When the player moves the mouse horizontally, I want the character to immediately rotate in response, since responsiveness is paramount in a shooter.

The state machine has a huge blend tree that works on three parameters: Central Speed (moving forward and back), Lateral Speed (side-stepping left and right), and Rotational Speed (rotating left and right). When the character is idling in place and rotation speed is non-zero, it blends some non-root motion rotation clips with the idle clip. I got those clips from Mixamo.

This has also worked well with NavMeshAgent. I just let NavMeshAgent handle rotation instead of Mecanim, and it looks pretty convincing.

This has all worked just fine, but I’m thinking of switching to the root motion rotation method used by the Mecanim example scenes. In this case, I’ll have to detach the player’s camera from the model. When the player moves the mouse horizontally, the camera will move immediately in response, although the model may lag behind a little while playing the rotation blend animation. I use an upper body blend tree to aim, and that will have to update immediately in response to mouse movement so the model is always aiming exactly where the camera is pointing, even if the lower body’s rotation hasn’t caught up yet.

The guys at Naughty Dog very generously publish a lot of information about how they do character animation and AI. Check out this slideshow on character animation: http://www.naughtydog.com/docs/Naughty-Dog-GDC08-Creating-a-Character-in-Drakes-Fortune.pdf

Jason Gregory at Naughty Dog also wrote a, excellent book called Game Engine Architecture in which he discusses animation in great detail. (I don’t have any personal stake in the book, but I’m always happy to share a link to it.)

2 Likes
3

Thanks for the insight, Tony! Your posts are always thoughtful and full of good info.

It’s encouraging to hear that you can mix root motion with procedural motion. I tried that only briefly, ran into some trouble, and believed that path leads to a world of hurt; but it sounds like it leads (after perhaps a few initial brambles) to a fairly pleasant place. So maybe I’ll give that another try.

Thanks for the references, too — I’ll check them out!

4

Happy to share what I’m come across so far. No guarantee that they’re anywhere close to optimal solutions, though. :slight_smile: I haven’t had much luck with procedural control of bones that Mecanim controls; I leave that to Mecanim’s built-in IK (using Pro). It’s easy enough to procedurally control the entire object’s rotation as I described above, and I’ve found that you can mix legacy animation with Mecanim so long as they control different bones. For example, in my current project, the Mecanim Animator component controls the character’s body, and the legacy Animation component controls his facial muscles. I had to unmap the Jaw bone from the Mecanim avatar to the legacy system could control it, but otherwise it works just fine.

1 Like