What should be the anatomy of your rig? Hierarchy is important because it serves two purposes. Certain decisions are made for the sake of organisation, other decisions have effects on function and performance. Some decisions can serve both purposes and could be argued to have a correct answer, but other times you can only serve one of these purposes at a time. And a decision will need to be made whether a little performance is worth sacrificing for better organisation, or vice versa.
Organisation doesn't necessarily just mean easier to look at and sort through. It could also be a matter of putting components of your rig in a place in the hierarchy which will accommodate scripts you know will be run on the rig in future.
If you know that your animators have a script they run to expose or hide all the joints, and you know that script works by finding the joints group and hiding/unhiding it then obviously there needs to be such a group and all the joints need to be within it.
If you wanted to reform that aspect of the hierarchy within a pipeline, they would need to change their script to identify the joints some other way.
So how you arrange your rig hierarchy is often about the needs of people further down the pipeline.
You might have heard people arguing online about the merits of broken or unbroken hierarchies. But this is misleading. All hierarchies are broken. It's a question of how much.
A rare example of a completely unbroken hierarchy is perhaps the driven skeleton that gets exported into videogame engines. But I don't know if that even counts as a "Rig" if there's nothing driving the skeleton.
Most rigs make a point of breaking the rig up into the following body sections:
Spine
Neck/head
Left arm
Right Arm
Left leg
Right leg
Some might also choose to separate out each hand into its own section since they can be dense pieces of riggery. Some would just keep them as part of the arm sections.
You see? You have option.
Why separate out the different parts like this? Why not parent the top of the leg hierarchy to the pelvis in the spine hierarchy so its all part of one larger hierarchy? That's where the leg goes does it not?
Sure. But there are some reasons you might want to break the rig up.
If you build your rigs using automated scripts, perhaps you'd like the option of singling out a specific part of the body, like if you were ever called upon to rig a disembodied arm, you could run the arm script.
And when you do need to rig the whole body, the script would really consist of a spine rig script, and neck rig script, an arm rig script, and a leg rig script.
This is how I work. My arm script for instance is written in such a way that it can rig an arm all by its lonesome, or it can detect the presence of a spine rig and make the necessary connections so the arm rig and the spine rig work together as part of a larger system.
Or what if I was called upon to rig a character with a third arm? It's waaaaaaaay easier if I don't have to go looking for all the arm components and instead have them all neatly kept together in a box, then I can just duplicate that box and boom, third arm! (Although new connections would have to be made)
It's about keeping things modular and keeping things self-contained, and where you have decisions to make is with the question: How modular should it be?
Should every finger have its own self contained rig system?
I mean... I think that's overkill, but I bet somebody's done it.
But you can break up a hierarchy in ways other than by body part. At work we have a separate group for all the controls, and another for all the joints:
There are some benefits to this. It makes hiding and unhiding the entire skeleton at once easy-breezy. And it makes it easier when scripting functions for controls or for joints when there's an obvious place where they're already hanging out, ready for you.
But make no mistake, there is definitely a trade off with these sorts of decisions.
That's how we do at work, because it's important to be consistent within a pipeline. But in my own time I much prefer a slightly less broken hierarchy.
It's more common to - rather than keep the joint hierarchy and control hierarchy in adjacent groups - to just have one rig group that contains controls and joints intermingling.
The benefits of this is that a lot of relationships between controls and joints can be achieved simply through transform inheritance. If the controls and joints were kept in separate hierarchies additional nodes and connections would be necessary to make the joints follow the controls. So the unified rig group is more computationally efficient.
But you do take a hit to organisation. I won't tell you which is more important, because context is everything. I don't know your rig and I don't know your pipeline.
An example is that it's no longer such a simple thing to hide and unhide the entire skeleton. You can't just switch off a single group's visibility, because the joints and controls are mixed in with eachother.
Not that there aren't solutions, it's a relatively simple script to write that identifies all the joints via naming scheme or by node type and edits their draw style so they're visible/invisible. But that is an extra step in the pipeline to make sure anyone has that script and remembers to put things back the way they found it once they're done.
One way in which basically every rig's hierarchy is broken is concerning the character geometry. The geo is usually tied to the rig via skinCluster deformers, and any transforms the geo inherits will combine with the effect of those deformers to result in the dreaded double transform. So it's extremely common to keep geo in its own group, away from the joints and the controls, all in one group so its simpler to preclude from transform inheritance.
In addition, the model file is often kept as a separate file, incorporated into the rig file. So the contents of that model file are kept self contained within the rig hierarchy then it becomes so much easier to slot model files in and out.
While we're on the subject of transform inheritance though, there may be other components in a rig that need to not inherit transforms.
And did you know...
Every node that has its transform inheritance switched off actually adds to the computational requirements of the rig. In this kind of spatial mathematics, inheriting transforms from its parent is an object's natural state. It requires more math - not less - to have it ignore what its parent is doing. We're talking about tiny decrements in evaluation speed but the little things can add up.
So I ask you: what's better? Finding every component that needs not to inherit transforms and switch off its inheritance? Or putting them all under a single group and turning off just that one group's inheritance?
For this reason often the earliest fork in the road of a rig hierarchy is to categorise the rig components into those who need to inherit transforms and those who do not.
In an average rig there are plenty of components within the rig that need to be precluded from inheriting transforms just like the character model. Local rigs, nurbs curves that are part of spline IK setups, rivet geos, etc. Typically things that need to be moved via deforermers and only deformers, ie. no transformation.
No comments:
Post a Comment