::the importance of rig encapsulation::

August 16th, 2011 by hamish download the zooToolBox

Being able to write good animation tools relies on being able to easily make queries about a rig. Animation tools often need a high level understanding about how a rig works for many reasons. But obviously you want to maintain a loose coupling between the two. You want rigging to have the freedom to be able to change the way the rigs work without having to worry about breaking animation tools. Conversely you don’t want animation tools to be hamstrung by the lack of ability to encapsulate the complexity of the rig.

For example, is there a way to query the FK controls from a given IK control and vice-versa? What about pole vector controls? Is there a way to ask which controls have space switching? If so can you query what the spaces are? What about which controls are affected by a given space switch? Given a joint can you get a list of the rig controls that drive it? You get the idea.

Animation tools are basically a layer that build on top of the rig layer. If the rig layer isn’t rock solid, then animation tools will be unstable or feature restricted or both.

Having some sort of programmatic interface to encapsulate the implementation details of your rig features is incredibly important if you want to be able to write useful and robust animation tools. Without this sort of high level rig API you’ll most likely make it difficult or impossible to write the sort of tools that will enable your animators to be more productive.

So if you’re writing a rigging system, try taking a break from it and building some animation tools. Exercise that rigging API you’ve been spending so much time on. Better yet, use all the animation tools you write as part of your unit testing to validate changes made to your rigging API. Remember, as a rigger your customers are both your animators and anyone who might write animation tools.


This post is public domain

This entry was posted on Tuesday, August 16th, 2011 at 13:34 and is filed under main. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

  • Josh Burton

    Great post Hamish. Been working on a rigger for a while now and this is just the kind of stuff we’ve been putting in it. I’ve been using message nodes a lot for storing info to get around the “what if someone changes the name of x” and that’s been working well. You found anything that works better?

    Hope all is well up in your neck of the woods. Send some rain down to Texas:)

  • Anonymous

    Awesome to hear Josh!  Message attributes are just the ticket.  Thats generally what I use as well.  My approach with Skeleton Builder has been to use sets as general containers – I stuff rig part members into the set, but I also create message attribute connections to preserve ordering.  I also use the set to store other meta data about the rig part as well.  So basically the set node becomes the storage mechanism for the python RigPart instance.  Works really well and makes for a nice, simple interface to the rigging code.

    One thing I haven’t done very well with Skeleton Builder yet though, is to abstract hierarchy information.  Sometimes a rig control will be constrained to something in the rig hierarchy, but won’t actually be parented to that thing.  Which means if you need to do something in hierarchical order its very difficult to do.

    So something to keep in mind!

  • Caleb Bell

    I know exactly what you mean Hamish. Rigging is way more than just the controls or the skeleton or the deformers. Its about how the tools that an artist uses to make great animation. I’ve seen first hand what problems an API as an afterthought can cause, and I know you have too. ; )