In the past, animations on videogame characters have played sequentially. When one ends, another begins, regardless of whether the action is fire-and-forget or cyclic, as the cycle ends before playing through again.
Seen abstractly, 3D animation is just a series of numbers or values applied to virtual bones within the characters we see on-screen, (actually just 3D co-ordinates around which solid objects or skinned vertices pivot). For years, videogames required the realtime manipulation of numbers in order to simulate lighting, AI, rulesets and other procedural elements within our games, but until now the numbers that comprise animations have remained relatively untouched.
The Past – Transitioning
The first and most basic use of animation number-crunching was the introduction of linearly interpolating (‘Lerping’) transition between the position/roation values in the last frame of one animation and the first of the next. This overcame to a degree the popping that occurs when the transitions between animationsare player-controlled and/or unpredictable by the animator, (i.e. a character can break from and idle at any point during that animation).
While this simple solution has been improved with the introduction of curved interpolation, (again championed foremost by fighting games, such is their reliance on smooth movement), this only smooths out the transition between the same old method of sequentially played animations.
This essay, however, intends to promote the use of blending (rather than transitioning) animation, that is to say, combining two or more animations simulataneously to produce entirely new animations in realtime.
The Future – Realtime Blending
This method has been used most commonly as a speed-based blend, by playing a walk and run animation on player characters and blending between the two based on how far forward the player is pushing the thumbstick. There are two golden rules that must be adhered to in order to successfuly blend between cycles such as these.
The cycles must be of equal length.
The actions themselves must not be too dissimilar.
In the example of a walk and run, both actions must sync up so that, for example, the half-way point of the walk is always blended with its equivelant frame in the run.
The simplest way to do this is to scale up the run animation before export, (as the run will naturally be faster and therefore shorter). This is, however, an added step in the animator’s pipeline and is not memory-efficient.
A better yet more complicated method has been pioneered by Ph.D. Graduate (now ILM) Lucas Kovar, involving the use of a time-warp curve stored within each animation, that not only scales the playback rate depending upon the blend-weight between the animations, but also allows the realtime syncing of specific key frames that would not otherwise match up with a more general playback rate scale applied to the entire animation.
Kovar’s parameterised walking, punching and kicking motions. Red cubes show target loactions of captured motions and grey cubes show the range of variation accessible through blending.
I was fortunate enough to talk with Mr. Kovar after a conference in San Francisco in late 2004, but disagrees with his stric limitation on the extent to which differing actions can be blended together, in particular regarding successful blends with strafing actions.
As mentioned earlier, for a blend to be successful the actions must be somewhat similar. A kick blended with a punch will produce nothing of use, however a high kick blended with a low kick will produce a medium kick if the actions are edited to sync correctly.
In the earlier example, the walk will blend with the run only if both actions begin with the same pose, (I always use the right-foot-up passing pose), however you may wish to use the right foot extended forward if your walks/runs always start with a basic transition from idle, allowing for the trans-time to take the equi-distant foot to the extended pose.
With the run scaled out to sync with the walk, a general playback rate increase will be required in order to play the run at its original pre-scaled rate. Below is an example of a blend between 3 seperate animations, walk, run and sprint, along with a playback rate increase dependant upon the weight of each animation.
This example could be improved with the addition of a jog cycle between the walk and run, however blending between walks and jogs causes the character to plane along without a bounce midway between the blend due to the passing pose of a walk being the highest point whereas the equivelant pose is the lowest or weight-taking frame on a jog. Try slowly building up to a jog and you’ll find a speed that is difficult to maintain.
The walk/run blend is the most basic and common use of blending, and I am using many more instances extensively on his current project. So be imaginative – this is the first step toward truly procedural movement in videogames, where the animator is providing the raw data to be manipulated by the player and AI to produce a more organic look and avoid the repetetiveness of seeing the same identical animations over and over again.