New Ardor3D Animation Features - Part 1

Recently added to Ardor3D's animation project are several new features to give you more options and ease of use with your animated characters.

First it might be helpful to look at what we already had in our first feature set.  The first cut of animation system had an animation manager that held a blend tree and a skeleton pose to apply it to.  You would set a manager up per unique animated model and the blend tree allowed you to put together complex animations using one or more animation clips.

This arrangement gives you a lot of control over animation, but quickly becomes tedious in a real system.  As Jason Gregory puts it in his excellent book on Game Engine Architecture, such a system is similar to working directly in OpenGL or DirectX - powerful, but verbose and clunky.  Controlling what animation is playing and when... or adding multiple animations together (transitions, IK, computed animations, etc.) based on the current activities in the game/application means tracking and managing that blend tree at a very low level.  You can quickly lose control.

What you need instead is a system that already knows the possible "states" your animated character can be in, and understands how to transition between them.  That's the concept behind a "finite state machine" (FSM), which is at its core a set of possible states and logic describing how to move from one to the next.

The recently released additions to Ardor3D's animation system add these states under the abstract class, AbstractFiniteState and broken into two basic categories: steady states and transition states.  SteadyState objects describe the list of base states for the animation FSM.  If you had a character with a walk animation and a run animation, walk and run might each exist as separate SteadyState instances.  Transition states do exactly what they sound like - they transition from one state to another (or sometimes the beginning of the same state).  A transition for walk->run might take both steady states and linearly interpolate between the two until we were fully in "run", and thereupon transition to the run state directly.

In Ardor3D, steady states have a map of possible transitions accessed by a String key.  The keys can be anything you like, but often work best if you use uniform values across states.  For example, if the user indicates they would like to start running, it would be nice if, regardless of the current state, we could transition by simply saying .doTransition("run").  Steady states also have an optional "end transition" field, allowing you to dictate what action will be taken when the steady state reaches its end.

Ardor3D currently has four types of state transitions available, including fade, synchronized fade, frozen and immediate.  Fade and Synchronized fade are similar in that they play the start and end state during the transition and change over time, from 0 to 100% how much of each clip is included.  Fade will simply start the end state from the beginning at the start of the transition.  Sync fade will synchronize the start times of the two clips and then do the transition.  This is helpful for matching up clips that have similar phases.  Frozen transitions also work similarly, but freeze the start state at the beginning of the transition and blend in the end state over time.  Freeze transitions are often most useful for blending between two dissimilar poses.  All three of these types can use linear blending, a cubic s-curve or a quintic s-curve to blend between the two states during the transition.  The final transition type is very simple and just immediately cuts from one state to the next.  It is often useful as an end transition, acting as a "repeat" command.

Transitions have one more common trait that can be useful - time windows.  By default, if you ask for a state to do a particular transition, it will happen.  But lets say that you have a transition that just doesn't make sense at certain points in the animation.  For example, you may be throwing a punch and be asked to animate as if you yourself took a punch.  It might look okay to do so as you wind up for the punch or perhaps after the punch landed and your hand is coming back, but not as your punch is landing.  In such a case you could set up a time window, stating that this transition should only happen when the state is in a certain part of its life cycle.

There's a lot more to go over, but this is already getting long enough, so let's call it Part 1.  In the next part we'll go over animation layering and the JSON based input you can use for creating your layers and FSM.  For the impatient, check out AnimationDemoExample and its related js file and get your hands dirty now. :)