::Skeleton Builder Retrospective::

October 15th, 2011 by hamish download the zooToolBox

A recent g+ post from Christopher Evans prompted me to revisit the shortcomings of Skeleton Builder – my most recent public attempt at writing a rigging framework. I’d link to the g+ post, but sadly, its not public. I think in general Skeleton Builder is a really useful framework – it has certainly made me a more productive rigger in every single way. But its far from perfect, and often analyzing a project’s failures is the best way to learn so here we go.

Of course to look at failure we need to understand the initial goals first. Skeleton Builder (SB) is my second attempt at writing a rigging framework. Not an auto-rigger, although it is an auto-rigger.  But the part of the code I’m most interested in analyzing is the framework part. I’ll go into the difference in a bit. With SB I wanted to solve a bunch of problems.

  1. Skeleton construction and joint alignment. I wanted to make it easy to construct arbitrary skeletons without burdening the user or the riggerwith joint alignment problems. I wanted consequent rigging code to be able to make guaranteed assumptions about joint alignment.
  2. I wanted every skeleton part and every rig part to be introspectible from code. I wanted this so that rig parts could ask questions of other existing parts. This would allow them to be easily re-purposed and extended. It would also allow richer animation tools to be built upon them.
  3. I wanted to be able to write a bunch of common code for a “limb” and have it re-used by biped arms, biped legs, quadruped legs, arachnid legs etc…  If not done via inheritance, then at least provide the same interfaces.
  4. I wanted very little overhead to actually use the framework. I wanted to make it really easy to port existing rigging code over to use the SB framework.
  5. And lastly I wanted to write a procedural UI to the framework so that non-technical users could use it and so rig coders didn’t need to write UI.

So those were the major goals.

The first was was a mixed success. While the tool makes it really easy to build skeletons without having to worry about alignment for most things, its not immediately obvious to users that this is the case. Ideally the alignment would change in real-time as they’re making skeletal adjustments. Also joints like wrist joints still needed to be oriented manually. This wasn’t terribly obvious to users either, which is fair enough. As an end user when you see everything being automated, you don’t really stop to think whether there is anything you might need to pay attention to. So the tool should have made more of an effort to point out user intervention is required in this case.

The second point was also a mixed success.  SB has a bunch of helper functions in it to make coding space switching super easy.  Setting it up was generally a single line of code per control, or if you weren’t picky you could even use the  “auto space switching”. Space switching is amazingly useful and in fact, usually when I forget to put it on a control, I eventually hear back from an animator – “hey, can I get space switching on control X please?”.

Anyway the problem with space switching is that it is a confounding factor when you need to sort rig controls hierarchically. Space switching provides a way to effectively change the hierarchy. So without some way of taking this into account when you need to sort controls hierarchically, this can be a problem for a tool writer. So that in my opinion is a failure and I’m not even quite sure what the best solution is.  I mean its easy enough to write a function that takes space switching into account when doing a hierarchical sort, but how does a tool writer KNOW that they need to do this?

So lets go back to the bit about rigging frameworks vs auto-riggers.  Well the difference is basically architecture vs construction.  The framework is the environment the rigging code is written within.  When I started writing SB, I focused only on the framework side.  I had a pretty good idea what sort of functionality would be required, so I wrote that first.  Once I was happy with that, I took it out for a test drive by trying to write some actual rigging code using it.  This in turn pointed out some missing features in the framework which in turn caused me to re-write the actual rigging code etc…  This iteration cycle went on for a little bit and eventually out came the current incarnation of SB.

Basically a good auto-rigger should be built upon a good rigging framework.

Thats my brief analysis on the shortcomings of SB.  In general, like I said at the top, I think it has been very successful.  Its made me personally enormously more productive than I would been and it has been an amazingly enabling force for users of the tool as well.  But like I said, analyzing the failures is usually more instructive than analyzing the successes.


This post is public domain

This entry was posted on Saturday, October 15th, 2011 at 15:54 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.