Handling complex animation states (Thoughts?)

Started by
12 comments, last by Kylotan 6 years, 10 months ago

One annoying thing with humanoid animation blends is that they can look terrible if you don't take knowledge of foot-falls into account. You (almost) always want a left foot-fall to follow a right foot-fall, but arbitrary blending doesn't account for this. This results in the character sliding and shuffling their feet around during blends, instead of taking believable steps.

So, you need all the foot-falls in your animation data to be annotated so you can categorise the animation frames into the left/right foot phases. When blending out of an animation that's, say, 75% of the way from a left foot-fall to a right foot-fall, you should start the new animation at the same phase (after the first left foot-fall, and 75% of the way to the next right foot-fall).

You might also be blending in some IK to make sure that feet actually rest on the ground properly, and some animations may delegate some parts of the skeleton to IK completely. e.g. the turn-right-after-left-step animation might ask the IK system to keep the left foot glued to the floor while animating the rest of the character... 

Advertisement

I'd like to add that making visual tools for this can really help give a clear understanding of the conditions and transitions involved. State machines are fairly simple, my implementation is less than 100 loc. It's setting up all the transitions and conditions where most of the complexity lies, it's hard to reason about what's going on if you have a web of states laid out in code. A visual representation makes it much easier to grasp what's going on. I'm not aware of existing tools that you could use, but I'm sure there are some out there. If there aren't any (that satisfy your needs), making it yourself could be worth your time. For example, this only took me about 2 days.

To follow on from what Hodgman said, it can be useful for the 'enter' phase of a new animation state to be able to query the animation state that it is replacing, so that it can set itself up better. For example, when you go from a run to a stopping state, the stopping state could ask the run state which foot hit the ground last and how far through the cycle it is, allowing the stopping state to pick a frame that most closely matches that position.  Another way to handle this is to allow transitions to 'push' data into the new states. But some sort of generic and simple communication during transitions is useful.

This topic is closed to new replies.

Advertisement