Makes it easier to identify 'ins' and 'outs' and where animation should be exported / imported / baked eventually. Any input (animation, mocap) should go on the animation rig (controls) and deformation rig should be driven by the animation rig. One important thing I think is to clearly separate deformation rig and animation rig. Loading animation data on controls rather than the rig itselfĪgree totally here. Too lazy to go and quote all over the place so as I remember :Ībility to update and change the source, whilst content has already been madeįast, simple semantic traversal of the hierarchyĪbility to mirror any part against any axis Lots of interesting things have been said already. It's a simple concept that make a world of difference. I have already written a VERY generic python message system inspired from the work of Justin Leach for Lucasfilm. And I mean ALL it's nodes (every single DG node associated with a module is connected to the module parent node). that way, a component can truly own all it's nodes by linking with them directly. Use a message connection system to create explicit connections between the components of the rig. Then the IKHand has a clearly defined interface to plug into a limb (like an arm, tentacle whatever). For example, an 'IKHand' module would have 5 children modules (1 for each finger). That way, they can be aggregated into larger modules. I would opt for atomic modules with generic functionality. The granularity of the 'modules' is a HUGE design decision. In order to really get serious about this, we're going to have to extend Maya with new nodes types through C++ (not scripted plug-ins). There should be a collection of pre-requisite plugins to accompany the python scripts. Python only, no MEL for reasons already discussed. For those who don't know me, I was the author of The Art of Rigging series and since the publication of those books I've spent a lot of time thinking about modular rigging systems. Some Autorig Theory (An open source autorig?)Īpologies for not having time to read all the messages ( I skimmed through) but I wanted to throw in my two cents. Switch/Align enabled by semantic traversal (what does this mean?) This enables you to have 'math-node driven switch mechanism between FK/IK'įK/IK switch attr instanced onto all rig controls Ik Joints - all the joints in the ik chain MetaChilden (perhaps if it's an arm chain, you'd have a metahand?) On the metaNode, you have attributes for: Utility Scripts -> Rig Component Scripts -> Rig Template ScriptsĬreat a document with explanations of scripts.Ĭommon general purpose functions- scene traversal, namespaces, strings, import/export etc.įK/IK chain, Stretchy Spline IK, Multi-constraint, Procedural FixupĮxample-create a 'Simple IK Rig Component'

Brick rigs angle controls