Animation Blending: Achieving Inverse Kinematics and More

When the MechWarrior 4 team needed to convey the enormous size and weight of the giant walking robots, traditional IK systems didn't cut it. This article presents a technique that uses artist-created animation, blended to perform IK that gives a sense of weight and timing.

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

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

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.

Figure 3

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.

Figure 4

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.

Cross Fade, Continuous Blend and Feather Blending

Cross fades and continuous blends are basic ways of using the blender engine. Figure 5 represents the flow of a simple cross fade transition. The upper blue box represents animation 1, and the beige box is animation 2. The arrows represent the blend weight of each animation. In this example, the two animations are cross faded with linear weights to form a transition. When the game decides to transition from one animation to another it simply increases the weight of animation 2 while simultaneously decreasing the weight of animation 1. The end result is, hopefully, a seamless transition.

Figure 6 illustrates a continuous blend. Both animation 1 and 2 are cycling indefinitely. In this case, animation 1 represents an undamaged walk, and animation 2 is a damaged walk. At some point, the game decides that the walk should now be damaged to some degree. The simulation increases the blend weight of the damaged walk, and the outcome will be a mixture of the two animations.

The purpose of feather blending is to overlay an animation without having all the joints blend into the detestation at a unified weight. Feather blending is just an extension to the overall blend weight of transitions and continuous blends. An example would be an animation of a character running and a separate animation of the character standing still while firing a weapon. By putting modifiers on the blend weight at each joint level, you can blend the two together to have the character run and shoot. Each joint would specify how much of the overall blend weight it would inherit. This allows the shooting animation to not affect the running animation. Without the feather blend, the animation would perform a strange stand/walk mixture that would look incorrect. Each channel adds a modifier to the overall blend weight of the animation.

Figure 5

Creating well-blended transitions is not as easy as placing two animations into a blending engine. A bit of care is required to make satisfactory transitions and continuous blends. When transitioning from animations that are not similar, such as a character walking and a character swimming, the resulting animation will very likely look erroneous. Animations that are not similar tend to have strange continuous blends. Clearly, the closer the animations are to each other, the more seamless and natural the blend will appear.

Figure 6

For radical blends, the minimum requirement is at least one point in each animation that is similar. The transition can be performed at this similar point. This issue is most prevalent with leg cadence, which is the speed in time that legs repeat their cycle. The animator will need to precisely pick transition times to match leg cadence. If the cadence is not aligned, the resulting motion is legs that cease their pendulum motion. The legs may pause, stutter or travel backwards. These timings may need to be per transition, as each transition destination could have a differing leg cadence. This is where there was a lot of trouble with MechWarrior. In the end, the artists needed to look at every transition to make sure that the leg cadence was consistent.

While an animation may be similar, its playback rate may not be, such as a walk or a run. Both animations can start on the left foot and complete a full cycle of walking motion, but each animation has a different run length. The walk could be completed in one second, while the run could be twice as fast. When blending these animations together continuously, strange results will occur as the run will be played twice for each cycle of the walk. This time, the cadence is not the same rate, even though the cadence has the same start point. The result of this problem will likely be an interesting skipping animation, but probably not the desired result. To combat this problem, simply scale the playback time of the animations in proportion to the weight. Now, when the animations are played, each animation will cycle at the same playback speed. For the walk/run example, when the walk is being played at full speed the run would be played at half speed, so the cycle rate is the same. As the walk transitions to the run animation, the walk playback rate will increase to double speed at the end of the transition. To prevent abrupt changes in momentum, it is essential to alter the play back rate based on the blend value. Matching playback rate is less of an issue for transitional blends, but the problem could still arise if the transition is of significant length.

Animation transitions that are simple cuts should still have some overlap. This was a tragic mistake made in 'Mech that resulted in countless hours of tracking down pops and glitches in the animation by both the art staff and programming staff. The hand-animated transitions had matching edges on the animations with no overlap. This cut technique was same as was done with previous games, but proved to be ineffective for a blending system. The blending invariably results in mismatched animations with pops that are not fixable. A tiny amount of space before and after each animation would have fixed this, providing the necessary space to blend out. The newest revision of the animation system utilizes one second of header and trailer on each transitional animation which allows ample space for blends. From an artist's perspective, it is significantly easier to have this data in the file upfront rather than having to add the data later.

Blender Nodes

Figure 7


Latest Jobs

Sucker Punch Productions

Bellevue, Washington
Combat Designer

Xbox Graphics

Redmond, Washington
Senior Software Engineer: GPU Compilers

Insomniac Games

Burbank, California
Systems Designer

Deep Silver Volition

Champaign, Illinois
Senior Environment Artist
More Jobs   


Register for a
Subscribe to
Follow us

Game Developer Account

Game Developer Newsletter


Register for a

Game Developer Account

Gain full access to resources (events, white paper, webinars, reports, etc)
Single sign-on to all Informa products

Subscribe to

Game Developer Newsletter

Get daily Game Developer top stories every morning straight into your inbox

Follow us


Follow us @gamedevdotcom to stay up-to-date with the latest news & insider information about events & more