Morgue Setups

Morgue Setups

Modifying Rigging Solutions to Fit Different Characters

I don’t even think I have a good name for this workflow still.  The lead that taught it to me referred to it as a morgue once, so I’ve gone with that ever since.

His first words to me when he started to describe the setup was that Maya’s very good at referencing and duplicating networks, why build things more than once, and everything twice?  Or spend all the time trying to automate things that the Interface is really good at doing that code isn’t?

I was pretty baffled by what he said, but as he dove into these intuitive hand animated rig solutions which had an efficiency of control beyond anything I had seen before, and a minuscule repeat setup cost, and I completely abandoned my auto rig library I had been working on for the previous two years in favor of this method.

What he introduced me to was a hybrid procedural and Maya scene component library with an exposed interface system that allowed all of these setup body parts be configured to fit a character.  Below is an example of a full digitigrade leg component, or a L3J for short.

A three jointed limb interface node behind adjustable setup parameters at default values. L3J_v07

The concept is the mindset: Build a limb just thinking about the limb and its functions, and not a limb inside of a posed character.  Use zero, one, and ninety as core values, to explore complex interactions instead of some values outside of your control, like those dictated by a production engine scale, or different modelers idea of a bind poses.  Then expose the parts of the setup that need to be unique in driven values, well documented and organized into Interface nodes.

IK’s don’t care when the values under the hood change, why should you?

For assembly: reference needed components into a scene with the character, and using a combination of the animation controls and interface nodes pose the solution to the bind pose.

“NAME YOUR NODES” – Pete Bandstra

Nodes are treated like variables that you will poke in an auto rig, call them out and track nodes via sets for quick access and organization.

Naming conventions emerged into things like; gameJoints(bind joints), inputs, QS(quick select), outputs, and solution proper names like stretch, rotationSplitter, etc.

Challenges of not knowing where a limb was going to be use required some trial and errors to generic terms like limbA instead of Thigh.  Explicit call outs of goals instead of hand or foot.  Renaming goals is often accomplished with prefixes added at time of reference, or import.  (Do ensure unique names for all nodes in a scene, or Maya will fatally error when importing references)

For us, building out these control components just once, and not trying to automate every node for full procedural system saved precious time on tight production schedules.  This time then allowed for additional component complexity that cut down animation costs on.

In mid production an alternative workflow of new components started as they were needed on a character.  When a character required something custom; a unique assembly of previous components would be exported out of a rig in its new arrangement awaiting to be turned into a cleaned up component.  Many simple appendages like tails, complex ears, facial, cape and cloth rigs came about from this alternative.

Additional benefits of the 0,1,90 relative pose math under the hood appeared through additional productions.  Units could be adjusted on the fly if new models came out with different proportions, or bind poses, and still retain most of the accuracy of their previous animation libraries.  A rig could be man-handled also with minimal teaching by anyone with the awareness of the interface nodes to another unit saving the need to have full setup scripts available to everyone on a production.  Man-handling a rig into a new unit is a easy, fairly safe corner to cut when crunches hit.  By keeping the skin attached from a previous unit, and stretching the unit out to fit the next unit, one could often copy some of the bind data over as well.  (The advent of geodesic skinning methods though has replaced this benefit to one rarely used anymore)

Not zeroing out animation controls to a bind pose evolved from this process as well.  I use the term Relative Zero, more on that in another post.  In short though with uses of scale values in interfaces to drive course world space style control locations, like IK goals, and all FK values being relative between rigs, animation transfer and sharing between rigs was as simple as replacing a reference in an animation file to a different rig offering stubbing of other units before animators could get to them as options for sussing out game play.

And at some point in time, Maya fixed its manipulator acting backwards on an inverse scaled transform.  To mirror a limb referencing in another version, give it a namespace denoting its on the right side, and inverting the top node’s scale to give yourself the opposite facing side.

Pending your bravery and forward planning one can keep referenced components for quite some time down a pipeline, however we found writing flattening scripts to import things and cleanup names to be a common good practice.

If I ever get back around to converting stable components into being full procedural, I’d still use the 0,1,90 setup methods and exposing the interfaces, then moving the rig to its bind pose, instead of constructing it at the final pose.  As the exposed interfaces have proven their flexibility again and again for the last ten years of productions.