This is part one of “Anatomy of a Skeletal Animation System”
There is quite a bit of information out there on the basics of skeletal animation, including how to export and read animation and model data, how to animate bones and thus transform a mesh, how to blend bone data together and other related animation topics.
However, there is a lot less information out there about how to set up a system to use these techniques in a realistic way, such as you might find in your average modern 3d video game.
I myself have been an animation programmer on a few games including an open world unreal engine game called “This is Vegas” (unfortunately cancelled due to Midway going bankrupt) and also a multiplayer only first person shooter called “Gotham City Impostors” which was released earlier this year for PC, 360 and PS3. The info I’m presenting is based on experience developing those games, as well as info i gathered from other developers or read about in books or online.
In this article I’m going to assume you already know how to get animation bone data into memory, how to use that animation data to animate models (meshes), and also how to blend animation bone data together. I’m going to start off with the most simple animation system possible and slowly introduce features until we end up at something that would be fully featured for a typical modern game.
The “next generation” of skeletal animation seems like it’s going to be heavily based on parametric animation, and while we will TOUCH on the basics of parametric animation, we won’t dig into it very much beyond that. If you are making a next gen AAA title, parametric animation may possibly be for you (and maybe not), but with the rise of 3d in flash, the rise of mobile games, and also indie game development, I think traditional pose driven skeletal animation is here to stay at least for a while.
Depending on the needs of your project, and how high a quality bar you want vs how much CPU time you want to spend on animation, some of these features may not be appropriate. Feel free to take what is useful to you, and leave what isn’t. Every game is different.
Animation Controller v1 – Super Simple
The simplest point we will start out is that if you have a mesh with an animation controller on it (to control what animations should play on it and such), it has these features:
- If you tell it to play a looping animation, it will continue playing that looping animation forever.
- If you tell it to play a non looping animation, it will play the animation and have some way of notifying you when the animation is done. This is either by having it call a callback when it’s done, or by setting some flag on itself saying that the animation is done (won’t ever get set on a looping animation)
- You should be able to tell it a playback multiplier to play the animation at, such as if you tell it to play at 3.0, it will play 3 times as fast, or if you tell it to play at 0.5, it will play half as fast and look like slow motion.
- If you tell it to play an animation while another animation is playing, it will instantly stop the animation it’s playing and start playing the new animation.
With this simple animation system, we could conceivably make a game that has animated characters.
That being said, the animation system is lacking in a few ways:
- You can only play full body animations, meaning if you want the lower body to look like it’s jumping, and the upper body to look like it’s firing a rifle, you have to make an animation that looks like that. If you want the same thing, but you want the lower body to look like it’s standing around while the upper body is firing a rifle, you have to make an entirely different animation that looks like that! The permutations of actions can get quite large and you have to decide in advance which animation you want to use. That is, when the player is jumping, they cant change their mind that they suddenly want to start shooting.
- When you switch animations, there is visible “popping”. Popping is when a bone goes from doing one thing to doing something else instantly. It looks like the bone teleported and is very visible to players. It looks buggy and unpolished.
- If you are doing something like having the player throw a grenade, you have no way of knowing when to actually spawn the grenade model, and where to spawn it. You could “hard code” it to spawn at the same place relative to the player each time, when the animation stops playing, but that is pretty hackish and not very maintainable.
Lets start off by working on solving problem #3 of not being able to specify where to spawn a grenade or when to spawn it.
To solve the problem of WHEN to spawn it, a feature common to nearly all animation systems is the ability to put game engine events on animation key frames.
This way, when the arm is at the correct position in the throw animation, someone would be able to put an event like “throw grenade” on that animation key. When the animation reaches that animation frame, it sends the message to the game engine, which can then create a grenade (with any specified parameters to the event).
Often times I’ve seen this implemented as an actual string that is associated with an animation key frame. The strings might be things like:
Playsound Laugh.wav (to play a sound to go along with the animation)
SpawnPhysicsProjectile Grenade.mdl 0 0 5 (to spawn a projectile with the specified mesh and velocity vector)
FootFallSound (This would tell the engine to play a footstep sound, based on the material the player was standing on, such as a metalic sound if on metal, or a duller thud if walking on dirt)
You could also use it to hide and show attachments or a myriad of other things. Basically you can use it for anything that you want to be tied to an animation.
Usually you’ll want some kind of editor for animators and other content creators to be able to associate these key strings with specific key frames. If they have to work with a text file where they have to hand enter times and key strings associated with those times, it’s going to be really tedious and they are going to be sad. Also, it will be very error prone which makes everyone sad when it generates more bugs than it needs to, slowing down dev time.
On the topic of creating unnecessary bugs, while i’ve often seen keystrings implemented as actual strings, it’s actually a lot less error prone if you have some kind of structured input system in your key string editor.
For instance, instead of them typing a command name and supplying any required parameters, it would be a lot better for them to have to choose a key string command from a drop down list. When they choose one, it should display any parameters that might be needed, and have some way of validating that their input is valid.
This editor should be tightly coupled with your game engine. Example ways for doing this including having a shared header file that defines all key string commands and what parameters they require, or having the key string editor load a game dll to get at the data that way.
If you have to manually maintain the tool to match game code, it will often get out of sync and cause you pain you don’t need. Avoiding that pain means you can work on developing more features instead of fighting reoccurring bugs, and means QA can focus on finding harder to find bugs. In the end it means a better product which is great for the company, your continued paycheck, and the player’s experience.
Some other potential bugs can come up with key frames that I don’t have a good answer for, it’s just something you have to mindful of.
One of these bugs is that when an animation is interrupted, a key frame might not get hit when you expect a key frame to get hit. For instance if an animation attaches something to a players hand, and at the end of the animation hides that attached object, if you interrupt the animation midway through, it won’t get hidden and the attachment will be stuck to the hand as the player does other things – which looks very weird. Your best bet is to design things in such a way that if key strings are missed, it isn’t a problem. Not always possible with all features unfortunately though…
Another problem that comes up when you have more advanced anim systems is that you may be blending out an animation which is no longer relevant, but while it is blending out, it hits a key frame. For instance if you a player is holstering a weapon, but blending out a fire animation that got interupted, you may get a “firegun” key string command, when you really don’t want it because it’s not relevant anymore. Sometimes you would want a key string to fire in that case though, so there is no real global solution to the problem that I’m aware of.
Now that we have a way of knowing WHEN to spawn a grenade in a grenade throw animation, we don’t know WHERE to spawn it. This is where sockets come in – no I’m not talking about TCP/IP or UDP sockets!
A seemingly obvious solution is probably to say which bone to spawn the grenade on in the “throw grenade” animation key string. An issue here though is that maybe if you spawn it right on the “rhand” bone, it might clip through the hand (inter-penetrate the hand) and look sloppy. Also, for other use cases, you might want to attach something where there isn’t a bone nearby.
Another seemingly obvious solution might be to add extra bones to the animation data that aren’t tied to any real geometry. This way, you can use the bones to attach things to, or spawn things at, but they aren’t tied to any real model geometry so you can make them move however you want.
The problem with this solution is that you are paying the cost of animating those bones even if you aren’t using them for anything. Enter sockets!
Sockets are a transformation (translation and rotation) away from a specified bone. They are usually only calculated on demand so that when you aren’t using them, you don’t pay a price for having them.
This way, sockets act as very cheap attachment / reference points on a model during animations to attach other models to (such as capes, helmets, guns, grenades).
When a key string command takes a socket or bone as a parameter, you should have it accept either a bone or a socket. They should be usable interchangeably, because sometimes you really do want to attach something to a bone, and you shouldn’t make an animator make an extra socket just to make it match a bone.
We now have a way of specifying WHEN to spawn a grenade (via a key string), and also WHERE to spawn it (specifying a socket to spawn it at as a parameter to the key string command).
Animation Controller v2 – Blending
I mentioned popping earlier and said it was caused by a bone changing where it is or how it’s moving by a drastic amount in a single frame. If you’ve read my DIY Synth articles, you probably remember how important in audio programming it is to make sure that your sound data stays continuous. The same is true of animation data, you have to make sure that bone motion / position stays continuous always, or else you’ll get popping.
Just like in audio programming, you use envelopes to help keep things continuous when you add a new animation into the mix, or remove an old animation.
For instance, If a model is playing one animation and you tell it to play another, the new animation should start at a blend weight of 0.0 and slowly increase while the old animation decreases from a blend weight of 1.0 down to 0.0. This gives you a nice smooth blend between two animations and works for MOST animations (more on that in a second).
Typically, when crossfading from one animation to another, the magic number is to blend over 0.2 seconds, but certain uses may warrant a longer or shorter blend time. You might also blend out the old animation at a different rate than you blend in the new animation. Give your animators the option to choose so they can do whatever they need. They will be happy that they have the control, and you will be happy that you don’t have to one off program things all the time for them. Everyone wins!
What happens if you want to play an animation while an animation blend is in progress already? 0.2 seconds of blend time sounds like a short amount of time, but this actually comes up ALL THE TIME.
There are two ways to deal with this issue that I’m going to talk about.
The first way to deal with this problem is to keep a list of all the animations that are currently playing, so that if you tell the animation controller to play a bunch of different animations really quickly, it will end up sampling a bunch of different animations as various ones blend out, and the final one is blending in. This can result in A LOT of animation sampling which can take a serious toll on your game’s performance. I encountered a bug on a game I worked on once that caused around 100 animations to be getting sampled on a single model for several frames due to this problem and it made the game tank HARD.
The second way to deal with this, and how I like to implement it usually, is to make it so only two animations can play at once (a main animation and a blend animation) and you have another field on the animation controller which says what the next animation to blend in is.
Going this route, when you say to play a new animation while a blend is in progress, it goes into the “next animation” field. When the current blend is done, that next animation will blend in and the last one will blend out.
If there is already another animation in the “next animation field”, it’s replaced and it’s never seen.
This way, only two animations will be sampled / blended at a time maximum, yet you will get a perfectly smooth blending between animations, and the controls will still feel fairly snappy, although there may be a noticeable delay in control response if animations change a lot really often. You’ll have to make a judgement call about the needs of your game.
Lastly, I said blending works nicely for most animations but not all. One exception to this rule is when you try to blend different lower body animations together, such as trying to blend a walk animation and a run animation together. Often times, the feet will be in different places and when you blend them, it makes the feet look like they are doing a little stuttering dance and it looks ugly. I’ll talk about getting around this specific problem in the next part, but as a preview, the short version of the solution is to make sure the feet are in the same positions at the same time for the two animations.
End of Part 1
At this point we have a fairly nice animation system but it isn’t quite ready yet. The most glaring problem we have is that we can only play full body animations still, which is not acceptable. A real animation system NEEDS to be able to play different animations on different sets of bones independently.
We’ll tackle that problem, and others, in part 2.