MRS Terminology

Last Updated: 12.29.2018




People use language differently. This is our attempt to shed light on what we mean with the language we use in helping users make the most use our tools.

We also have a general site terminology article if you don’t find what you need here.

Active Block

The active block is the rigBlock that is loaded to the mrsBuilder ui. Several calls require an active block or it can be a point of context via the Push menu. Also the active block blockDat section works off the active block and has no function without it.

You can set the active block a couple of ways.

  • Top bar of setup – There is a button << which when pressed with a selected block will set that block as the active block
  • Right click menu – right clicking a selected rigBlock in the scroll list will provide an option To Active which will make that block the active block
  • Utilites - Contextual Section – There is a button To Active that does the same.


BlockDat is the what we call the core data set of a rigblock. It comprises everything necessary for the replication of a given rigblock.


A rigBlock may have a single blockMirror rigblock connected to it. This sets up a relationship for block mirroring functions as well as rig mirroring after build.


The rigblock that would be seen like a hierarchical parent to another block. However it’s more of a controller block rather than a parent as it can be connected to that parent rigblock in multiple ways at rig.


The given state of a rigblock. Check the post more more info.


We use the term context in several places in our tools. Simply but it is those things which will be affected by any given action.

With mrsAnimate based on a given control selection you could be working in a context of control,part,puppet, with our without siblings/children/mirror.

Adding time to that paradigm is in the plans


A string datList we use for having connectable and indexable string attributes to plug into multiple things – wrist being pushed to  joints, dags, controls etc for naming.

Name Tags

We use a naming system in our tools and setups that allows an object to know what it should be named. It does this by getting it’s name dictionary. Then that name dictionary is compiled to a given name based on core setting that can be changed.

We’ll flesh this more out later.


This was our answer to having index managed message lists. It is a managed system for handling message connections and other data lists (strings,floats,etc) in connectable indexed lists. It does this as a series of single message attributes sharing a base name and treated as a single list by our system. You’ll see these calls all over our code base.

Why was it necessary to do msgLists?

Maya has a bug that comes up not infrequently in versions where multimessage connected objects duplicate their wiring even when you have index matters or other options set. When you need very specific data lists – say a joint chain and you don’t want that list if joints getting messed up you need a solution. This was ours.

It seemed a better answer than accounting for the bug creeping up in different iterations of maya.

Last year we added the datList support mainly for name work but it’s expanded some. For our MRS joint naming we use something called name tagging so that a given node is tagged in a way that when you mNode.doName() for example it is able to detect it’s appropriate name by how it’s tagged. Name’s are inherited hierarchically and via connections.

This may be unwieldy at times but it’s served it’s purposes over the years. We’ll go into more detail on these concepts when we get to a Workshop on making your own rigBlocks.


Our rigs utilize red9’s mirroring paradigm for their setup which involves a series of attribute and mirror index values to determine how and in what order things are mirrored.

We use some language in our tools that would be helpful to understand:

  • Push | Push my values to whatever would be in my mirrorable context
  • Pull | Pull values from my mirror to me
  • Symmetry Left/Right | Make me symmetrical with the given side being the prime axis to make that symmetry happen.

Proxy Mesh\prioximus animaximus

The mesh that is generated from our rigblock lofts to create approximated versions of a given asset. Check the post for more info.


A rigblock is our rigging guide. They are setup and controlled by mrsBuilder. You can find more information at the post for the concept.

Rotate Plane

A plane as defined by the rotate plane handle to the rigblock root, then aimed at the end handle.

Used for snapping the prerig/joint handles to a consistent plane.


A collection of connected rigblocks usually saved as a file in order to generate an asset rig.

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.