Hey everyone, this is the start of a new blog series centered around explaining some of the higher level concepts and best practices that I have learned being a professional Technical Animator. This idea came up from a talk over at Reddit’s gamedev section (you should check it out!). There was a question about more complex animation systems (read it here), so I felt the best way to answer some of the questions would be a blog series.

The Beginning:

Everything in an animation system starts with a rig. Depending on your engine, dialect, personal preference, it may also be called a skeleton, a skelMesh, a Bone System, Joint Hierarchy,  Skinned Mesh, Deforming Mesh , etc.. you get the idea. For the sake of simplicity, when I refer to terms that have many names, I will pick one and stick with it. I call it the rig. The rig is vital to get correct, as all your animations will be based on it, if it has an error it will cascade into all your animations. Updating an error in the rig is not bad if you only have 5 animations. It can be quite the ordeal when you have 5,000.

Disclaimer: This is an advice series, not a how to. You will have to adapt this information for your own systems.

UNDERSTANDING THE HIERARCHY:

The hierarchy will depend heavily on what type of game you want to make. However, for your standard 1st person/ 3rd person games there are some fairly good practices you can follow.

1. Your first bone should be called ‘Root’ and be at the origin of the scene.
2. Any bones you want to use for tracking IK targets, need to be children of the ‘Root’
3. Any bone you want to use to move counter to your animation (say an attach point for a gun that gets dropped to the ground) needs to be a direct child of the root, otherwise it will jitter do to floating point inaccuracies.

Everything else should follow the logical order of the ‘anatomical’ bone structure.

One more thing. Never use your direct animation rig (the controls that the animator animates) as an in-game rig. There are things that really make sense from an Animator control standpoint that really don’t work in-game. Also, if you do need to change the in-game hierarchy having the two systems separated allow you to make sweeping changes without fear of destroying any of the work animators have done.

Here is an example hierarchy:

HOW MANY BONES?

A common question you run across with every rig is ‘How many bones can I use?’ . This is a VERY dynamic question and is HIGHLY dependent on the engine you are using. What I want to point out are the simple guidelines to keep an eye on when establishing your own budgets.

1. A bone that is not skinned is cheap CPU wise.
2. A bone that does not move much is cheap memory wise.
3. A skinned bone that moves all the time is expensive in both CPU and Memory.

If you are worried about memory, remember each bone gets more expensive for each animation. Also, watch out for engines that automatically ‘chunk’ your rig into pieces if you exceed a bone limit. Not only does this increase your draw calls, but it has other performance considerations as well. Other than that, use the number of bones you need to achieve the quality you want.  As frame of reference, my average FPS rig will have ~65 bones, but I have gone as low as ~40 and as high as ~120. It really depends on your goals.

That is bare basics, please feel free to ask any more specific questions in the comments. For next week, I will start getting into actual animation authoring, making sure your animations will work, and setting up the foundation of talking about blending systems.

If you have an suggestions on topics you would like me to cover, please leave a comment and I will add it into the list.