Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
Animation Blending: Achieving Inverse Kinematics and More
View All     RSS
June 23, 2021
arrowPress Releases
June 23, 2021
Games Press
View All     RSS

If you enjoy reading this site, you might also want to check out these UBM Tech sites:


Animation Blending: Achieving Inverse Kinematics and More

July 4, 2003 Article Start Page 1 of 3 Next

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.

Article Start Page 1 of 3 Next

Related Jobs

Treyarch / Activision
Treyarch / Activision — Santa Monica, California, United States

UI Engineer
Health Scholars
Health Scholars — Westminster, Colorado, United States

Unity Software Engineer
SideFX — Toronto, Ontario, Canada

3D Software Developer: Game Tools and Pipeline
Genvid Technologies
Genvid Technologies — CA/WA/NY, California, United States

Team Lead (Partner Services)

Loading Comments

loader image