Game Rigs: Controls vs Bones Hierarchy Abstraction

This might be blatantly obvious for experienced game TAs but since I had a hard time figuring this out when I started, I’ll leave this right here…

In most current engines, for a given animated entity, an animation is ‘played’ on a base rig. The base rig is the rigged mesh file with no animation data. In the engine, the animations are applied onto the base rig and what you see in game, will be an instance of this base rig. This base rig should ideally contain only the most essential objects required for it to run in game. These are just the bones and the skinned mesh. On the other hand, a rig that is handed over to animators would contain several control curves and dummy objects with complex relations to each other which drive the bone hierarchy through constraints( and not through parenting ). It is important to keep the hierarchy of these drivers completely separate from the bone hierarchy to observe somewhat of an ‘abstraction’.

So ideally, this is how the hierarchy in your rig should look like (3Ds Max schematic view for a simple Turret rig). When the rig is exported to engine, it should be stripped of all control curves (an animator level abstraction)

hierarchy

This kind of abstraction provides various advantages:

  • Simpler hierarchies for game objects, easy parsing at engine side
  • Art can go overboard on the amount of complication of the rig
  • Rig iterations can be performed at two separate levels depending on the need. The engine might demand a different bone hierarchy than the animator

Leave a Reply

Your email address will not be published. Required fields are marked *