13
\$\begingroup\$

I've just posted this at the Blender artists' forums before realising I would probably get a better response from a more game development-specific audience, so apologies for cross-posting! It's for the right reasons :)

I'm a programmer trying to animate a character walking for a game project, using Ogre. I've made a very simple walk cycle in Blender and exported it to Ogre, and it plays just fine. By fine, I mean it works, but there's terrible foot sliding. This is because I just animated the walk in-place (at the origin) in Blender, and of course I don't know what "speed of walk" that corresponds to, so when I move the character in-game the motion doesn't necessarily match up with the movement of the feet in the animation.

So my question is: what's the normal approach for this kind of thing? At work we use Maya, and the animators either animate a special 'moveTrans' node that represents the "position" of the character (or have the exporter generate it for them from the movement of the root node), then the game can read this to know how fast the animation moves the character. So in the Maya file, the character will walk forward for one cycle and this extra node will follow along with them by their feet. I've not seen anything like this in open-source land, and there's certainly no provision for that in the Ogre Exporter script. What do you chaps normally do for this?

Improve this question
\$\endgroup\$
1

1 Answer 1

Reset to default
10
\$\begingroup\$

There are two ways of doing it: root motion or "in code".

With root motion you have basically exactly what you're suggesting with the "moveTrans" node. You use the motion of that object to determine how quickly to play back the walk cycles. You might be able to do a reverse lookup of sorts to figure out that if you want to be at position X what frame you need to be at. But the real advantage of root motion is that to get truly realistic animations you need to account for the fact that movement isn't a true linear path. Real people move at a variable speed over time, or maybe they're shuffling left and right a bit, or whatever.

Mixamo did a good example with root motion control using Unity. There's a video of it here: http://vimeo.com/12052874

Now root motion does have its drawbacks. It can get tricky with things like trying to get the "walk" animation to work on stairs (ideally you'd have a separate stair/ladder climbing anim and do all the movement for that in the animation as well). I'm also not really sure how IK really plays into it, if at all.

Now doing it "in code" is a lot easier from the programming side of things. What I suggest doing is first making sure all your units are consistent. For example, 1 unit in Maya and your game is 1 meter. Then you get your artists to animate a character walking (complete with forward movement). Use that to figure out the speed of the animation, and export the animation without the forward velocity. Use that to figure out how fast to play back the animation. So if the walk animation at 1x speed is 5 m/s, and you want to have the player run at 7 m/s, you simply play back at 7/5 = 1.4x speed. If your model is scaled up or down multiply the animation playback rate by the inverse of the scale. A half height dude will have to walk twice as fast to move the same rate as a 1x scale guy.

Improve this answer
\$\endgroup\$
6
  • \$\begingroup\$ I'd not seen the Root Motion Computer from Mixamo, nor have I heard it called that, so thanks for the link and explanation! So basically it's as I thought, either animate it explicitly or auto-generate it, and either at build-time or at runtime. I guess I'll have to code this up myself in the exporter script. One thing I'm now mega confused about is motion that changes over the course of one cycle - how on earth would you drive that from gameplay? "Move at 5m/s" now means something else... And direction changes will be a nightmare for AI! Perhaps it's best to use agerage motion? \$\endgroup\$
    – Ben Hymers
    Jan 12, 2011 at 15:52
  • \$\begingroup\$ Ran out of characters; I'll wait a bit before marking this as accepted to get some more opinions. Thanks for your answer! \$\endgroup\$
    – Ben Hymers
    Jan 12, 2011 at 15:55
  • \$\begingroup\$ For root motion you don't control the speed of the player directly. You only have control, really, of the playback of the animation rate and then you let the animation be in direct control of the forward z value. The 5m/s example I gave was for the traditional way of solving foot sliding, which is to try to just match up playback rate with how fast you're moving and assuming a constant speed. \$\endgroup\$
    – Tetrad
    Jan 12, 2011 at 16:46
  • \$\begingroup\$ As a gameplay programmer, that sounds like a complete nightmare :) Putting animators in control of something as important as movement speeds of anything animated? No thanks! I much prefer to extract the information so I can invert it and set the animation play speed based on the movement speed, rather than the other way round. That's why nonlinear motion confuses the hell out of me though, and perhaps that's a good reason to do it the other way round. \$\endgroup\$
    – Ben Hymers
    Jan 19, 2011 at 19:43
  • \$\begingroup\$ Gah, curse Stack Exchange for entering the comment on trying to start a new line... I was about to say, even if you let the animation drive the motion, it'll still be a problem for e.g. AI characters. What if they're trying to get to a point but their movement animation lurches from side to side (say, it's a drunken stagger animation)? How can they know which direction to face? \$\endgroup\$
    – Ben Hymers
    Jan 19, 2011 at 19:44

You must log in to answer this question.

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