     |
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
Animation Blending: Achieving Inverse Kinematics and More
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. 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. 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
A single axis blender allows you to define multiple animations that will be continuously blended. A range is defined for each animation in the blender node, which specifies the location on the axis where the animation will have a blend weight. As the axis is moved by the simulation input, the blender calculates the weight of the animations. In the case of Figure 7, the input comes from speed. The weight of the overlapping animation is linear, based on the current position in the overlap. In the illustration, the blend weight is linear inside the overlapping area of the animations. The blender node in Figure 8, given a point in the defined space, will output blend weights that are appropriate. The combination of multiple animations active in the same axis blend are simplified by using blend layers to resolve the weight (See Figure 9). This makes the solution much easier, since the animation ranges are arbitrarily complex. The only limitation to the layer solution is the need to keep each successive animation starting at or above the last animation axis start position.
Multi-axis blenders allow users to blend any number of axis (See Figure 10). This is the cornerstone of producing IK effects. Each animation is given a sphere to represent its weight in the space, and each sphere has a center point and a radius. The center point of each circle represents the animation at full weight all the way to the edge of the circle, which is zero weight. When the blender node calculates the weight it steps thru each animation, calculating the weight by its distance to the input. The calculation caps the weight at the range of the sphere. For IK effects, each animation represents a target IK position, be it a ground angle to walk on, or a point in space to grab. Notice that the defined space in Figure 10 has some gaps. If those gaps are left in, the blender node will not assign weight to anything and the animation will not appear correctly. This illustrates the biggest challenge of using this type of blender. The easiest way to deal with this issue is to increase the radius of effect for specific animation (See Figure 11).
Input values feed into the blender may not always be smooth because they come from the simulation. They may be damage, speed or hill grade, which may or may not consistent from frame to frame. The MechWarrior engine handles this by adding a set of generic smoother classes to filter input with. How the number is smoothed varies depending on what the animation is driving. Currently, support for acceleration drag models, springs and simple averages over time are used. All are useful methods for preventing unsightly pops. Trees and Lists There are a few generic tree and list structures that will assist in further abstracting the blend hierarchy. Trees and lists are still blender nodes, and as such, can be children and have children. They each represent different generic ways of calculating blend weights of their respective children. Lists assist in maintaining important animations visible while also keeping the blending engine from blending too much data. If too many animations are blended at once, not only will the performance drop, but the resulting animation will become muddled. Priority trees guarantee that certain animations are played regardless of other animations blend weights. Starting with the top level, each blender node gets as much weight as is currently available and requested by the blender node. The next layer of blender nodes receive the remaining weight and so on. The following example illustrates this point. In a priority tree of three animations, the first two request seventy 70% of the weight each. The third request 100%. The first animation is granted the full weight of 70%. 30% of the weight remains to be disbursed. The second animation receives 70% of the remaining 30%, or 21%. The 9% remaining is then granted to the third animation. So, if the second animation had requested 100%, there would have been no weight remaining to disburse to animation three. Overlay lists combine animations that are feather blended. These are very similar to single-axis blenders, except overlay lists do not unitize the weight of their children. The weight calculation and blend algorithm need to be extended to support overlays. Without extending the algorithms they would incorrectly unitize the base weights of the feather blends. A FIFO priority tree allows animations to gain and lose priority based on when they are queued. This could include a selection of hit effects or special move animations. No particular move is more important than the last, but it is desirable to have each animation interrupt the last. This is where a transition engine would be placed to have specific transition events and information. A FIFO tree can calculate weight the same as the priority tree, or it can have a more complex transitional engine built on it to calculate weights more specifically. The MechWarrior engine uses a complex FIFO tree that manages specific transitions from each animation. It manages all in-out time marks for each animation as well as motion state information for the simulation.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Designer's
Notebook 
|
|
|