::skeleton builder 101: part2::

November 22nd, 2010 by hamish download the zooToolBox

Following on from the first post introducing Skeleton Builder for end users, this post is more about what the Skeleton Builder framework offers to more technical users who want to extend the tool: altering existing rigs, adding new rig types or skeleton part types.

So I’m assuming with this post that a) you’re familiar enough with rigging in maya and b) you’re comfortable enough with python to write your own classes and at least know what decorators are.

There are two main sets of functionality in Skeleton Builder – skeleton creation and rig creation and they’re both highly extensible.  You can easily remove existing skeleton/rig parts, you can easily add your own skeleton/rig parts and you can easily mix and match new parts with existing parts.

So the general idea is that these skeleton parts are kinda like legos.  By breaking up the skeleton into these high level parts, you can mix and match them in any way to build a creature.  Skeleton parts know what they are and they know how to rig themselves – and even can provide useful information to other tools such as skinning tools or animation remapping tools or even the animation system of a game engine.

For example, if you wanted to write a tool to remap animation you could write code to remap motion on arms differently to legs because the skeleton knows what parts it is made up of.  You don’t have to tediously label joints, you don’t need to rely on naming conventions and you don’t even have anatomical restrictions.  For example you can have multiple spines, legs, arms, hands etc…  You could reasonably easily write a tool to remap motion from a human, to a spider.  You could take the motion of the two human legs and remap it across the 8 spider legs.

When Skeleton Builder is asked to create a new part, it generates a unique ID for that part.  So for a typical human skeleton, you have two arms and two legs.  The left arm has ID=0 and the right arm has ID=1.  Similarly for the legs, the left has ID=0 and the right ID=1.  Part ID’s are unique across parts of that type.  So in the case above you could take the left leg motion and map it to all the left spider legs and similarly for the right legs.  A part knows its ID and knows whether its a left or a right sided part (or not sided at all).

Each part is a class that derives from the SkeletonPart class.  This class defines a bunch of variables and methods for things like aligning, creating visualization cues, storing and querying part attributes, rigging itself etc…  In general your subclass need only implement a “_build” method.  This method (it actually needs to be a class method) gets called when Skeleton Builder is asked to build a part of that type.  So you write your build code there – and this is just normal maya code.  Take a look here for the spine part’s build method – its pretty simple.  Create some joints, place them etc…  The build method gets handed a bunch of information that was passed in from the user, usually via the UI but it could be from script too – its fully scriptable.  And then you can use this information in whatever way you want to build the actual part.  Just make sure to return the list of joints for the part.

Then the build function simply needs to return the joints it should contain, and the tool takes care of everything else.  It registers the parts appropriately, stores the metadata for the part and will even make sure all the joints conform to a simple naming convention (you can tell it not to if you want to precisely control joint naming).

The other method that you may want to override is the “_align” method.  So the align method handles aligning the part properly.  Now Skeleton Builder assumes the author of the skeleton hasn’t concerned themselves with joint alignment – because in my experience they don’t.  Which is fine because its not easy to do.  I’m intimately aware of alignment and even I screw it up on a regular basis.  So the tool assumes the author hasn’t paid any attention to alignment and will try to make sure alignment is “right” either when asked, or before the part is rigged.  Of course “right” isn’t always easy to define.  A head part needs to be aligned in a different way to an arm which is in turn different to a leg etc…

Because the tool deals with aligning, creating the skeleton is much easier.  The user can move joints or rotate them however they want.  In fact, I’m so used to just grabbing a knee/elbow joint, hitting insert and just moving it to where it needs to be that I can barely remember how to do it “properly” anymore.  This is pretty liberating – and makes authoring a “clean” skeleton easy even for fairly non technical users.

Each part can define precisely how it needs to be aligned.  There are a bunch of really useful alignment functions in the tool to make writing this function a snap.  Functions such as autoAlignItem, alignAimAtItem, alignItemToWorld and alignItemToLocal.  These guys all take a bunch of args that can make it super easy to write alignment code.  These functions take care of all the details like making sure attributes are unlocked, children are unparented and re-parented, names are preserved (because un-parenting can cause a node name to change) and just about anything else you can think of.  You can also pretty easily write your own alignment functions if the above aren’t enough for you – there is a function decorator that will do the attr unlocking/child un/re-parenting etc…

There are obviously a bunch of examples in Skeleton Builder for writing alignment methods, so take a look if you want to try writing your own skeleton part.

Another useful thing to customize is the visualization method.  This method gets called for each part when the user turns on visualization.  Visualization is basically a way for the user to visualize something useful about the part.  For the head part for example, a flat triangle polygon is added to the head joint so users can see how the joint is aligned.  So again, you can write your own should you need to by implementing a “visualize” method.

So thats about it for the SkeletonPart class.  There are a bunch of other useful methods on the class – but they’re not terribly interesting to talk about – but take a look at the method doc strings.  There is a bunch of useful information in the actual code.

Now I was going to get into how the RigPart class works, but this post is getting pretty long – and I haven’t even gotten into any code.  So I might save the RigPart overview for a future post, and hopefully get into a simple example part as well.


This post is public domain

This entry was posted on Monday, November 22nd, 2010 at 20:57 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.

  • Pingback: Tweets that mention :: m a c a r o n i K a z o o :: » Blog Archive » skeleton builder 101: part2 -- Topsy.com

  • http://www.varomix.net varomix

    wow, this looks really interesting, I was thinking of writing something more modular for rigging and I’m gonna take a look at this because this can jump start what I need or even totally solve it

    thanks for sharing

  • hamish

    yeah definitely take a look – and feel free to ask questions if things are unclear. you can leave a comment or email me. I still have another post to do on the rig parts, but I’m using it as both a tool for building animator puppet rigs, deformation rigs and facial animation rigs. And the plan is to have it write out a description for runtime remapping rigs as well, which I’ve already done in theory. So its pretty versatile.