Skip to content

modularity in rigging.

March 6, 2007


I read a paper recently on ILM/R&H’s rigging pipeline – it sounded stunning and at its heart was ‘modular’ rigging. That taking several key ‘rigging’ blocks one could build, iterate and change on the fly a rig. Modular ‘blocks’ of rigging setup would be linked through a simple text entry, for example:

modular rigging block hand would link to arm via ‘wrist’ and so on and so forth. It made me think about what the future holds for rigging. First of the current situation in rigging is majorily hindered in my opinion with the locked state of skeleton to rig. And so these two systems along with twist need to be abstracted – if iterating on a rig, that didnt change or break the skin was a simple as modularly switching different setups on the fly per scene/shot things would be a lot easier.

So what essentially is a rig – its a skeleton which is driven by a setup, and controlled by puppets.  This skeleton is primarily a tool for skinning to, and also referencing animation, mocap, building other rigs off. If the skeleton was just a layer essentially that looks at a setup, itself built modularly on the fly, then itself could be changed, added to, even animated in FK off a setup.

 Abstracting two systems is complex though, and made worse by the sheer amount of referencing that goes onto a rig, twist for example needs bones, transform, relative parents and nodes – so to tear a system like spine, arm twisting etc you’d need the essential nodes to make it work. So with this twist is a system unto itself, that needs a system in place – therefore its a final layer of setup after the primary rig’s been built ontop of a changed skeleton or a skeleton thats driven off a modular rig.

What is ‘modularity’ can it be broken down into systems? – Interms of rigging automation out there, systems still rely heavily on other systems existing, an arm system needs a shoulder/hand etc; a leg needs a foot but can this like ILMs tool be abstracted even further to pure body parts: spine/head/arm/leg/hand/foot I think it can. Whats needed for consistency with modularity that makes joining systems together work?

Well for one thing its puppets, without puppets to there respective ‘block’ the system doesnt work – take for example an arm. To build it you need a shoulder position (not the shoulder) an elbow position and a wrist position. Ontop you need the controls at the shoulder, wrist and hand – even if the wrist controller isnt controlling anything, it will do once it knows what to link to: hand. And because hand is now pointing to arm via wrist it just finds its respective controller – this could be as simple as just parenting it or typing in the ctrl it needs to link too.

Ontop of this modularity combinations of rig become far easier, like as the paper discussed building a centaur was a case of linking a horse lower torso to a human upper one. The system needs essentially three layers: skeleton > setup (with puppets)>twist (in theory the skeletons bones needed for twist could use this)

Issues arise with this approach too though, namely orientation of joints, can for instance an arm be attached to a neck? and if so how is its orientation, its initial setup posed? Can modularity co-exist with a skeleton do they both need to be present, can a modular rigging system only work on an already existing skeleton? to me a skeleton is a layer what the skin needs and also it bridges the gap between model and rig, most importantly with twist and stretching…



Post a comment
  1. March 12, 2007

    Heya Charles – at the moment since i’m working in a mainly XSI based house this is quite relevant – the crosswalk system is a bit of a lie in terms of how well things move from XSI into max and I’m thinking only a simple rotation based rig would go across without any kind of joint flipping and so on so it’d be a case of a control rig with all of the XSI features, layered constraints and so on to make animation easy. Then a simpler rig sitting on top that will have its animation baked and fbx’d or crosswalked out. the layered system definitely looks like more work but as you say far easier to swap in or out different setups.

  2. Charles #
    March 12, 2007

    Modularity is the key, im trying a few things out here that basically abstract the process. The biggest pipeline block is iteration, changing a rig halfway down a project, having to break the skin etc Ive got a few ideas but its pretty complex.

  3. noodles #
    April 28, 2007

    Hey, Aaron (noodles) here… I just saw your post on CG Talk so I thought I’d hop over here and check out your site.

    Yeah like you said, the trick is finding a consistent representation of a character pose that’s flexible enough to work lots of different rig elements. Joint chains are one option, but I think they’re ultimately too limiting. I like the idea of using NURBS surface strips to represent limbs and torsos/necks, having that be your deformation system, and then building the control structures based off of that. But that’s got limits too. I think ultimately you just need to specify in your rig element (arm/foot/spine) what kind of input it needs to build on, and then use the data in the scene to feed that input (almost like your rig element is a procedure call). Because there’s always wierd ones out there that don’t fit the paradigm. The minute you say “all my rig elements are going to install on a NURBS surface” you’ll need one that’s based on a volume.

    Also, you mention the whole level of abstraction thing too… like you have a leg rig, that also contains a foot rig, but you have to ask the question: in terms of swapping out is it a leg and a foot, or is it one rig that’s all together? I think the best way to handle this is a heirarchal system, where the leg rig contains a foot rig as one of its own elements. Like the most abstract element layer is the entire rig itself. That has all these other elements, say a spine and some legs… but just like the rig contains a spine and legs, the spine and legs are built out of their own constituent parts (like basic IK limbs, and feet, which then contain toes, etc) which are semi-swappable.

    But there’s a dark and ugly underbelly to all this talk of layers of rigs and swapping and abstraction, and its the potential for a speed hit. The components must work together and be as optimized as possible in order to avoid big evaluation times caused by all the layers driving each other. It’s the old functionality/performance ballancing act that always seems to come up.

    Sorry that was long… but you bring up a topic that I’m very interested in.

  4. Charles #
    April 28, 2007

    Yes, seperating rig elements, and abstracting the rig from the skeleton is hard. But its the aproach the big studios (ILM, R&H) seem to be tackling. Im coming from the idea of binding a rigging module in a way to a skeleton. This skeleton can be anything, boxes, shapes etc. What R&H are also doing is that there modula rigging is an input based aproach – that for it to work you have to build essentially systems. For example leg and foot. The input for the foot would be “ankle”, basically this is the glue of association. You would still have the controls part of the leg i think even if they dont control anything, until an input is provided.

    As to speed, i currently work in max, but am abstracting my functions to work in any app, apart from a few c++ fns that are to slow. I hope to abstract everything into c# or python eventually. Im building data driven functions i.e only relying on values than object and transforms. So slowly extrapolating modularity.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: