Traditional
Inverse Kinematics (IK) systems attempt to solve a fundamental artistic
problem with math. While the math may technically bring a character's
leg to the correct position, it rarely imparts a sense of weight
or timing. This article presents a technique for creating IK effects
without these problems. The method uses only artist-created animation
that is blended to perform IK. By using animation only, the artist
retains control of the entire process. The character can now struggle
as he runs uphill while shifting his weight and speed, all without
losing accuracy of the foot positions which match the grade of the
ground. This article illustrates the practical applications of multi-axis
blending, blend hierarchies and priority blend trees as well as
the pitfalls of using such a system in the real world.
The
fundamental technique of blending animations together is not new.
The traditional blending approach consists of transitioning from
one animation to another seamlessly. Creating transitions exercises
only a small amount of what can be achieved with blending. Blending
can provide robust IK solutions, complicated dynamics, as well as
other feedback effects, and all of these can be accomplished simultaneously.
Using blending to perform IK effects allows a much more stable solution
than using traditional math-based IK solutions. A traditional IK
system will simply solve a chain of joints to a specific goal position.
The IK systems completely overlook the weight and dynamics of the
object. This can result in uninteresting animation that is technically
accurate but lifeless and twitchy.
The
basic concept of single-axis continuous blending is widely used
in games. The techniques presented here extend this concept with
the introduction of multi-axis blending, blend trees and priority
blend trees. This combination of techniques permits complex layered
animations. Multi-axis blending simultaneously allows the developer
to maintain IK accuracy and the animator to create the motion. When
the artist is in charge, the resulting character-motions embody
a sense of weight and timing that are unobtainable through pure
mathematic formulas. Beyond IK, the developer can determine all
manners of feedback systems, such as taking damage and performing
fight moves. A priority blend tree allows for layering of blend
effects with more traditional transition animations and procedural
animation.
To
successfully implement a blending engine requires much more than
the blending formulas and techniques. Great care and planning is
essential when designing the source animation. The interactions
of each animation must be carefully analyzed for continuity since
animations that are not designed to blend together often provide
undesirable effects. The overall data size of dozens of animations
can be problematic for developers dealing with performance and memory
constraints. Animators' schedules can become even more burdened
as well. Subtle pitfalls and obstacles that the Fasa Studio team
has encountered are exposed as well as strategies to overcome them.
Fortunately, with good planning and tool support, all of these difficulties
can be overcome.
The Blending
Decision
Why
chose blending? IK solutions often suffer from unpredictable results.
When IK solutions are either under- or over-constrained, the resulting
solution can produce strange behavior. Many animators are familiar
with having to move an IK handle around when suddenly the chain
rotates 180 degrees and bends backward unpredictably. Even high-end
3D packages suffer from these issues. This problem worsens the longer
and more complicated the chain becomes. In addition to generating
IK effects, it is also desirable to have other feedback effects
as well, such as blended transitions. Having the core animation
engine written specifically to handle large scale multilayer blending
makes these tasks easier. The animation system being presented is
art driven and artist controlled. These are the major reason why
the Fasa Studio MechWarrior team uses a blended system. The
MechWarrior team's goal is to impart the enormous size and
weight of the giant walking robots (referred to as "'Mechs")
at all times. 'Mechs weigh 100 tons and are as tall as buildings.
The player needs to feel this size and power every time they see
a 'Mech.
Blending
systems are not without cost. There are significant downsides to
large scale blending. Data size, large content requirements, CPU
performance and memory requirements all make this method challenging.
Blending systems can require very large data sets. To obtain high-quality
results, multiple base animations are necessary. Each 'Mech is comprised
of 152 animations. At any time, each 'Mech can be playing up to
15 simultaneous animations. In a 24-player game, the working set
of animations adds up quickly. CPU and memory performance can also
contribute to poor performance, so a close watch needs to be applied
to both.
It
is important to remember that blended IK solutions are only approximate
blended solutions. This is the exact opposite problem posed by traditional
IK. Hen using IK, the character's feet will touch the ground, but
can experience minor sliding, foot penetration or even floating.
These effects are only minor and can be improved in a number of
ways. A blending system can be augmented with procedural animation,
traditional IK and physics. With blending, one can interlace procedural
animation before, during and after the blend. The MechWarrior
engine procedurally animates torso rotations, foot rotations and
even dampens out joints.
Given
two animations that represent two positions in a given space, interpolating
from one animation to the other will represent any position between
those animations. This is the basic theory of performing IK and
other feedback effects with blending. These animations can be static
poses or motions over time. Each animation represents a target motion
or pose. For blended IK, the animations can represent walking uphill
and downhill, or grabbing a cup at 2 meters and grabbing a cup at
3 meters. Other feedback effects could represent turning on a snowboard
or damage taken to a character. Each animation helps define the
available target space. It is possible to add any number of additional
axes to the blend space. It is also possible to add more animation
to different points within the existing space to help define that
space more accurately. For instance, combining an animation of a
character walking uphill and downhill may not necessarily result
in an animation of the character walking on flat ground. In this
case, one would further define the space with an animation of walking
on flat ground. With these three animations, the blending space
is now fully defined.
Overview
Of The MechWarrior engine
The
MechWarrior engine is comprised of two main systems: the
animation playback system and the blender system. Animation playback
is a generic animation loader and player. The blend manager handles
the hierarchical blending using blender nodes which each represents
a hierarchical layer of the blend tree.
Figure
1 is a snapshot of a MechWarrior blend tree. Each frame in
the blend tree is adjusted and the weights are calculated. This
diagram depicts blender nodes that determine the position of the
IK. The IK blender nodes calculate the target IK position. The result
of the IK node feeds into the forward motion blender. By blending
a walking animation and a running animation, the forward motion
blender can represent any speed between the two source animations.
The resulting jog animation is then feed into a transition engine
that is altering the movement state of the `Mech from a jog to falling
over animation. Each of these blender nodes will be covered in detail
starting with a quick overview of the lowest level animation player
and working up to the blender algorithms and blender nodes. Then
the presentation will cover how to put all the pieces together into
a final system. Other topics include performance a discussion of
the implications that this system has on art staff and tools that
can be written to improve their processes.
Animation
Player
The
MechWarrior engine uses quaternions for rotations. The basics
of interpolation will not be addressed in this presentation. The
following are some good references on Quaternion math. It is recommended
that an optimized spherical lerp be used, as a traditional spherical
lerp can get quite expensive.
The
lowest level of the animation system handles generic animation playback.
The player does not know anything about blending, only animation
loading, iterating and key frame interpolating. A single static
pose can represent an animation just as motion over time. All the
blending techniques work equally as well with a simple pose, so
it is important to consider this alternative for memory and CPU
consumption. The animation format supports vertex, velocity, position
and rotation. The interpolator supports linear, spherical, optimized
spherical and snap interpolations.
Animation
time can be advanced, decremented and set by frame, percent and
seconds. Time advance of the animations happens independently of
the interpolation. This is a performance and memory optimization.
The blend manager has the ability to cull out the interpolation
of animations that may be insignificant but does not know this until
the final blend tree is created.
The
velocity of the character is encoded into the animation from the
art package. By encoding the velocity into the animation, the blend
manager can also blend velocities. This important technique allows
the animator more freedom in how he animates. For example, the animator
can animate in an arbitrary space for each animation but is not
required to keep a constant speed during an animation. When the
simulation is notified of the final joint positions, it is also
notified of the velocities. It is up to the simulation to either
ignore or apply this velocity.
The Blend
Manager
The
blend manager is comprised of a tree of blender nodes. Each blender
node holds some number of other blender nodes. A transition blender
node, for example, holds two other blender nodes; the blend node
it uses for the start animation and the blend node for the end animation.
Base animations are also represented by a blender node. Abstracting
the blend into a hierarchical list affords the programmer some luxuries
in code. It becomes very complex to generate meaningful blend weights
when dealing with more than a few blend values in a flat list. When
using a hierarchy the code makes localized decisions about the appropriate
weight. The code, for instance, will only determine the necessary
weight for the walk and the run, as well as the transition weights
for the forward and fall motions. The blend manager then flattens
the list and normalizes the weights for final interpolation. The
blend manager can also remove duplicates and cull insignificant
branches of the blend tree to improve the performance of the final
interpolation.
Figure
2 represents a character that is moving forward, which is a combination
of a walk and run in a continuous blend. The character may be at
a jog speed in this diagram. But, the character is also in the process
of falling down. The jogging animation is still being calculated
during the course of the transition blend so that the result remains
smooth. The falling down animation could further be the result of
a blend, as could the walk and run. This illustrates a straightforward
us of the blending engine. Later, different encapsulations of blend
layers will be discussed that further simplify use.
The
process of blending includes four steps. The first step is to build
the tree, which the simulation does based on the movement states
of the character. The next step is to advance the time on each animation
in the tree. Third, the list is flattened and all the weights are
unified. The last step is to interpolate the current position of
each source animation and then blend that value into the final result
buffer. At this point one can further blend with procedural animation.
This can be as simple as pointing a head or complex IK chains. It
is also possible to add a blender node with procedural data if the
desire is to have it blend with the rest of the system.
The
basic algorithm for unitizing the weights in the blend tree is presented
in Figure 3. The algorithm recursively steps through each layer
of the blend tree. This builds a flat list of the animations in
the tree while unitizing the weights. Each animation will now have
its own percentage relative to all of the other animations. All
there is left to do is the actual blending.
The
blend algorithm that the MechWarrior engine is pretty straightforward.
See Figure 4. The algorithm interpolates between each animation
based on the running percentage. For linear translation, this method
will provide exact results. For rotations, this method is only approximate.
While there are other methods for adding quaternion rotations together,
this method is the simplest in preserving the spherical nature of
the rotations being blended. The first part of the algorithm calculates
the current interpolation value to be used. Then it calls down to
the animation player to actually calculate each animation channel.
Each channel will interpolate between the appropriate key-frames
based on time, and then, the outcome will be interpolated into the
result buffer by the unitized blend percentage.