Explicit Versus Implicit Methods

A first distinction divides animation algorithms into two broad categories: explicit and implicit methods. Explicit methods store the sequence of animated vertices from our geometry every few frames, like snapshots from a movie. Once stored, a variety of techniques can be used to reconvert the original data, ensuring smooth animation. As a characterization, explicit animation methods are easy to code and understand, and often involve very simple math. On the other hand, storing animated vertices is memory intensive. Many poses are needed to convey the true sense of motion, and that means storing lots of data. A typical MD3 file (the popular explicit animation format used by Quake 3) is about 10MB, and that is only for one character. See Figure 15.1 for an example of an animation loop created using one of the explicit methods explained in this chapter.

Figure 15.1. Explicit animation. We store the full mesh animated for each frame.

On the other end of the spectrum, we have implicit animation systems. These methods do not store the animation data, but instead store a higher level description of the motion. Skeletal animation systems, for example, store the configuration (in terms of its rotation angles) for each joint, like the elbow, knee, and so on in our virtual character. Then, in real time, this description is mapped to an unanimated character mesh, so the animation is computed. This computation usually involves complex math with trigonometry and matrices. Thus, these methods are all fairly intensive for the CPU.

On the other hand, memory footprint is minimal. Implicit methods only need small data structures to convey the description of the motion. You can see skeletal animation depicted in Figure 15.2.

Figure 15.2. Left: animated character; right: skeleton that generates the animation.

Explicit methods were very popular in older 3D games because the hardware did not have CPU power to spare. Those games did not use many animation cycles anyway, so the relatively high memory footprint was fairly acceptable. More recently, explicit methods have successfully been used in games depicting groups of people, because animating them using implicit (hence, CPU-intensive) methods would be prohibitive. On the other hand, implicit animation is becoming more and more popular. It is the way to go as character animation becomes more detailed, triangle counts skyrocket, and games try to provide a broad variety of interactions. In these scenarios, you simply can't have all the animations precomputed. It would be memory suicide.

An added advantage of implicit methods is that they can be adapted to the scenario. Imagine a character who walks in an outdoors scenario full of hills and slopes. If explicit animation is used, all the possible animation cycles must be preprocessed. Thus, if the character can walk on different sloped terrain, you need to have cycles readily computed for each one. With an implicit method, it is easier to modify the animation on the fly so the feet adapt to the irregular ground. Using inverse kinematics, the animation can be recomputed, so the terminal elements (hands, feet, and so on) are in specific configurations. The same applies to characters grabbing objects, dropping them, climbing, or any other situation in which the character interacts with external elements.