[In a visual arts-specific article republished on Intel's Visual Computing microsite and originally published in Game Developer magazine, Bungie's Steve Theodore discusses skeletal construction and animation for game characters, looking at "strategies for taming the skeletal hordes without ending up in the graveyard."]
You hear the eerie rustle of dry bones as they close in around you, the hideous clacking as they shimmy through your pipeline. They are the remorseless bearers of doom. Neither fully alive nor safely dead, they will not rest -- nor will you! For they are...
And they're here to make you miserable!
The animation skeleton, like the biological one, is absolutely necessary. We're pretty much stuck with the skeletons we were born with, but for many of our digital creations, the right set of bones takes a long time to develop. The process is often slow and iterative, and if it's handled incorrectly, it can also be very painful.
If you want to exorcise (or exercise) the restless bones in your own characters, you need to start by repeating to yourself this important, but frequently forgotten fact: The skeleton is, bar none, the most important component of any animated character.
The fact that it's invisible doesn't make it some kind of afterthought that can be elbowed off the schedule in favor of more graphically satisfying tasks, like creating concept art or modeling. You must get the skeleton right if the character is going to succeed aesthetically. And just as importantly, you have to get the skeleton assembled safely if the character is to come in on time.
Let's look at some strategies for taming the skeletal hordes without ending up in the graveyard.
If bitter experience hasn't left you convinced that the skeleton is critical, stop and do a little math.
A high quality character mesh represents several weeks of an artist's time. A skeleton, of course, can be assembled in a couple of days. Although the cost of laying down bones may be trivial, the problems that arise when the skeleton has to be changed mid-stream are truly epic.
When you change a character's skeleton, you've invalidated every bit of existing data that depends on the skeleton. This means you may have to reweight its mesh and rebuild every one of its animations. This can be nearly as expensive as redoing them from scratch.
It might require weeks or months of work by a whole team of animators, supported by a character rigger. And if the alteration in the skeleton involves a change in the overall proportions of the model, you may need to rework the game mesh as well, which can also result in creating new UVs and thus new textures.
Most teams recognize the costs of skeleton changes and treat them with the kind of enthusiasm usually reserved for a dinner invitation at Castle Dracula. Locking down your skeletons as early as possible is a natural and sensible precaution, given the time costs and potential for chaos that comes with changing them.
Locking down that skeleton is easier said than done, however. The key to making it stick is planning early. Sending out emails about "discipline" isn't going to cut it. Ensure that your concept process includes the design of the core animations and the skeleton as well as the mesh and textures (we devoted an entire column to this very topic; see "Raw Crude," Game Developer magazine, May 2008). At the very least, you'll need to devise a tough set of standard test animations that a character needs to perform successfully before his skeleton is released to animators and riggers.
Even with planning and tests, you're bound to miss something. For this reason it's good practice to push to the front of the production queue the moves that typically reveal the flaws in a skeleton. That way any changes that become necessary can be caught when only a few animations are in the can.
The worst offenders are often crouching or kneeling poses, which expose poor placement of knee and ankle joints ruthlessly (see "Anatomy for Animators: A Leg to Stand On," Game Developer magazine, November 2005). Gun aiming poses are another good candidate for early testing, as they reveal flaws in the neck and shoulder anatomy as well as the tricky matter of clavicle placement.
Once you've got a skeleton you can believe in, it's still important to distribute it to the animators and communicate that it has been distributed. If you crave ghoulish thrills, watch the eyes of an animator as she realizes she's spent a week perfecting a move on an out-of-date version of the character that won't export anymore. Sending emails or leaving sticky notes on the monitors of harried production folks isn't enough. The tools in your pipeline must make it so that starting new animations is as simple and error-proof as possible.
Opinions are split on how to ensure your animators are always working with the authorized skeleton. Some teams like file referencing, while others recoil from it as if it were a necklace of garlic. Referencing proponents point out (correctly) that using references provides free automatic updates and keeps the animation staff current with no extra effort.
Detractors counter that referencing breaks too many animation features, makes it hard to apply special-purpose rigs, and has a tendency to break animations when changes do come through. Since referencing tends to arouse a lot of theological passion (see "Clone Wars," Game Developer magazine, October 2008) it's important to focus on the animators' needs rather than fixed ideas about the technology.
Unfortunately, no amount of discipline and planning can keep those restless skeletons locked in the boneyard forever. A good process limits your liability, but it's almost certain that some accident of production or technical glitch will eventually force you to go for a root and branch rework of a character that already has dozens, or even hundreds of completed animations.
When that dark day dawns, you're in for some serious pain. However, a little planning and some tools can transform the experience from one of soul-crushing despair into nothing worse than a bad case of indigestion.
The first and most important line of defense is simply to know when things have gone wrong. It's a great idea to check every animation against the "skeleton of record" when you export it. That's a good way to keep people from walking down blind alleys for too long, and it means that minor problems (like bones that accidentally get renamed) can be fixed right when they occur, instead of showing up as subtle bugs or mysteriously failed imports.