Master [rigBlock]

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

 master | handlesegment | limb | handhead | eye | muzzle | brow

  • The root rigBlock of our system.
  • Not having one works for some setups but designed to be the root parent of any other rigBlock setup

Block Profiles




Float. This is a master only setting. This is a very important setting. This is our puppet’s offset value for all of it’s rigBlock shapes. It is used at many points during rig creation. The main effect is how far off of the proxy surface your control shapes will cast themselves for this master block controls as well as all sub modules.


Bool. This designates if our master will have a motion joint which is an extra root joint to move an animated skeleton around in game engine.


See shared attributes.

  • numSpacePivots

Special Calls



  • rigBlock [1]  – The darker yellow interior curve is our master rigBlock’s shape. Select it to get the dag.
  • Bounding Box Visualization [2] – This represents the bounding box as our rigBlock understands it’s own space
  • Curve Offset Visualization  [3] – This is to see how far off of our asset control curves will be set



  • motionJoint Helper [1] – Arrow pointing down. The joint would be created at the dag of this prerig helpers.
    • Optional – Only builds when the addMotionJoint setting is True




The master control [1]  is the large square/rectangle with lighter offset curve and curve text of our character name


  • visControl [bool]  — visibility of the vis control
  • settingsControl [bool] — visibility of the settings control
  • pivot_0…  [enum] — visibility for each pivot as created by the setup
  • space [enum] — dynParent space toggle (when optioned)


Gear shape [2] at the base of our master. This is where we have some settings for our puppet. We plug in more items as we add sub modules.


  • skeleton [enum] — off:lock:on
  • geo [enum] — off:lock:on
  • proxy [enum] — off:lock:on


Eye shape [3] at the base of our master. Not really using this much now but it’s a place to plug stuff.


  • rootMotionControl [bool] — visibility for the root motion control


Our same down arrow [4] as before. Used to move that joint.

Dag Structure

This will be more important to some of you than others. But our structure for a rigged asset begins with our master. Our master rigBlock creates a lot of nodes which you should have some understanding of in order to amend and modify your setups. All our subsequent rigBlocks will put their guts in this structure.

I’ll lay them out and then discuss them briefly.

  • NAME_puppetNetwork (network – cgmRigPuppet[LINK THIS WHEN DONE])
  • master(dag)
    • rig(dag)
      • noTransform(dag)
      • parts(dag)
      • worldSpaceObjects(dag)
    • geo(dag
    • skeleton(dag)
    • NAME_masterGroup(dag)
      • NAME_anim(dag – cgmRigMaster[LINK THIS WHEN DONE])
  • control_displayLayer(display layer)
  • main_displayLayer(display layer)
  • all_animSet(objectSet)


The puppetNetwork is a tagged mClass node of type cgmRigPuppet[LINK THIS WHEN DONE]. It is our core puppet wire source and target and has a large number of calls associated with it. We’ll get more into that in the MRS Workshop on making your own module.


The Main dag group in the outliner. This is our master null for the given puppet. We’ve named it ‘master’ assuming any referencing will ‘tag’ it such as ‘horse:master’.


Let’s talk through our groups and what they’re used for.

  • rig – general group for the groups below it to keep that first level of children smaller
  • noTransform – General noTransform group to stuff stuff when needed
    parts – each sub module added will add their own structure here. So for example, adding a spine that is rigged would add a spine null here and other dags at build time.
  • worldSpaceObjects – collector for our dynamic parent group system to add it’s dag targets to
  • geo – Watch group for various calls where they’ll be looking for geo.
    This is wired to the geo off/lock/on toggle so any children will get those settings
  • skeleton – Null to put our bind skeleton.
    This is wired to the geo off/lock/on toggle so any children will get those settings
  • masterGroup – Our master control’s master group under which our rig structure will be that will be transformed by the main control.

Display Layers

Currently we build two display layers per asset.

  • Control – this should pretty much only affect controls so you can hide them on playback
  • Main – this is for the whole rig

Object Sets

There are a number of objects sets supported by MRS. Some are created initially. Some by post processes.

  • all_animSet – Master anim set for puppet controls. Sub modules have their own sets added to this one
  • bake_tdSet
  • delete_tdSet

Our object sets are created as cgmObjectSet[LINK THIS WHEN DONE] mClassed nodes which extends their usability in code.

Road Map


See about culling extra attributes we’re not using

Change Log

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.