This week I wanted to talk about the idea behind puppet elements, which are meant to be the building blocks of this rig setup. At the most basic, an element is just what I’m calling the group of nodes that control a discreet part of the puppet. Since each part of the puppet (arm, leg, spine, etc) will have similar requirements (such as space switching), it makes sense to come up with a consistent structure to organize the nodes. The result is sort of a mini-puppet, where controls and settings are localized in way that is consistent with other parts of the puppet. It’s easier on the rigger because it’s organized for easy troubleshooting, and because on the scripting side of things all the element classes can use the same methods inherited from the parent PuppetElement class. It’s easier on the animator, because once they’re familiar with the basic structure of an element, they can figure out how to use any element.
In addition to being a group for the element, the top node becomes the perfect place to put attributes to control many aspects of the element:
- Local scale (scale independently from the rest of the puppet)
- Visibility (hide elements that aren’t being used, to speed up the puppet)
- Space switching (change what the element is constrained to)
- Any other settings depending on the element, such as FK/IK switching
Currently, the element hierarchy looks something like this:
- Element Top Node
- Local Space Group
- FK controls
- Local Rig Group
- Un-animatable local space nodes
- World Space Group
- IK controls
- World Rig Group
- Un-animatable world space nodes
- No Transform Group (inherit tranforms off)
- Deformed nodes, such as splineIK curves
- Local Space Group
The child groups are only created as they’re required by the element, but there’s potentially 3: The local group is oriented to the root joint of the element (for example, the shoulder of an arm) and holds controls that should be in local space such as FK chains. The world group is oriented to the the main transform of the puppet. It holds world space nodes, such as IK controls. Additionally, both of those groups would have an optional “rig” group under them, which would hold nodes that aren’t meant to be touched by the animators, such as the driven joints in an FK/IK setup. Finally, some elements will require nodes that are deformed and will therefore be double-transformed if they’re grouped in the element, so there’s a third group that has inherit transforms turned off to hold those types of nodes.
All the element top nodes are siblings, parented directly under the base transform for the puppet. Since they’re near the top of the hierarchy under one node, they’re easy for animators to find in the outliner.
This structure may need some revision as the library of elements grows. The one last thing I want to experiment with are Maya’s containers, as a way to bundle up all the underworld nodes associated with the element. I had mixed results in the past.