RigBlock States

MRS : Landing | Members | Queue | Forum | DocsLibrary | How

The Morpheus Rig System is designed to push rigBlocks through states as we call them.

There are five states:

  • Define  | Size, vectors, points in space
  • Template | Shaping the form of our proxy
  • Prerig | Points of articulation, shapes for rigging, more
  • Skeleton | Build our joints
  • Rig | Rig it, rig it!

Define

The define state is the barest of information for the block. What you will see will depend on the block type but you usually at least have a handle for the block root. You might see a number of visualizers:

  • Bounding Box – An open cube shape driven size wize by the baseSize attr on the rigBlock
  • Vector helpers – global up for the block module
  • Plane – visual plane for the block to see the center line

Main call

This is by far the easiest one. At most the define state should be a dag node and is the core node of our rigBlock.

Examples of things you might do here:

  • Reset transform data if desirable (like a master block)
  • Verify attribute alias, min/max, lock and hide

Results

  • A rigBlock node

Template

The template state is about shaping our proxy to give the rest of our processes the best picture of what it is we’re working with and be able to generate appropriate shapes and proxy meshes later on.

Requirements

  • d_wiring_template – dictionary of data the state check calls look for to see if the state requirements are met
  • msgLinks – Message attributes to check for data
  • msgLists – cgm msgList attrs to check
  • Template call

Optional

  • templateDelete – There is a general shared call that works for most purposes but that call checks the rigBlocks module for this call for special case needs.

Main call

The template call pushes a block from define to template state

  • templateNull – A null to go under our rigBlock under which most of our template state items are parented for easy cleanup
  • noTransformNull – For those things that can’t be transformed. Lofts for example
  • Template handles – These are our proxy shaping handles and they are loosely connected to the subsequent prerig handles.
  • prerigLoftMesh – This is the result of lofting our shapers and is important to the rest of our calls

Results

  • Template null
  • noTransform null(sometimes)
  • Template handles
  • Template proxy mesh (usually)

Prerig

The prerig state is about joints, controls and prep for moving on to rig creation..

Requirements

  • d_wiring_prerig – dictionary of data the state check calls look for to see if the state requirements are met
  • msgLinks – Message attributes to check for data
  • msgLists – cgm msgList attrs to check
  • Prerig call

Optional

  • prerigDelete – There is a general shared call that works for most purposes but that call checks the rigBlocks module for this call for special case needs.

For example, turning back on overrides for the template state

Main call

The prerig call pushes a block from template to prerig state

  • Prerig Null– A null to go under our rigBlock under which most of our prerig state items are parented for easy cleanup
  • Prerig handles – These are our control handles which then have…
  • Joint Handles – These are the handles which will layout the joint chains for the given module
  • Joint loft mesh – This is the result of lofting our joint handles. It is for visualizing the joint chain position relative to the proxy without regard to the template handles

Results

  • Prerig null
  • Prerig handles
  • Joint loft mesh (usually)

Skeleton

The skeleton state is simply the joint creation state where our bind joints are created, oriented, named and connected.

Requirements

  • Skeleton_build call
    • It needs to use the BLOCKUTILS.skeleton_connectToParent

Main call

The skeleton call pushes a block from prerig to skeleton state

  • Bind skeleton – Oriented, named and wired bind skeleton

Results

  • Joint chain

Rig

This is where we take all the information and bits we’ve laid out and make an actual rig. It’s a multi call process.

Requirements

  • __l_rigBuildOrder__-  List of string calls for the rigFactory calls in the module for a successful rig build. For example, in a segment the

Main calls

The rig call pushes a block from skeleton to rig state. It’s bit more complicated than what we’ve looked at before. First of all self for our calls is not our rig block but a rigFactory instance .

Instead of one call we break up or steps into separate calls as it makes troubleshooting much more easy than one behemoth call.

In general we still go through a series of specific actions regardless of the block type.

Things to remember

In order for a block to go to a given state, it’s parent blocks must be at least that state. For example if you want to take an arm to rig, the spine must be rigged

Josh Burton

[MRS Project Lead | CG Monks] Josh is an animator turned TD who hails from Oklahoma, pre-undergrad in the Marine Corps, animation basics at Savannah College of Art and Design, cut his teeth in gaming and commercials before co-founding CG Monks and more recently the CG Monastery. The Morpheus Rigging System is a culmination of years of R&D and he is now thrilled to see what users can create, collaborate and expand on with this open source MRS platform.