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

We have a class we did a couple of years ago that goes into this in much more detail which you can find here. However some basis of knowledge is important for you to understand how things work. I’m going to cover a portion of that here but if you want deeper knowledge you should check out that class.

People define metadata differently. For our purposes metadata is our means of storing and retrieving data. This is core to how rigBlocks function as the calls change their processes based on the data stored on a given block.

First of all a few bits about how we have implemented meta

  • We built our foundation on Mark Jackson’s fantastic red9 toolset and specifically his MetaClass. Most of our metaclass nodes are subclassed to his. We’ve been working with him for years and push bugs/fixes/optimizations to him that get put into his main branch and pull his fixes to our core. red9’s base package is included with the cgmToolbox.
  • This setup is very object oriented and allows for a number of useful items
    • mClass instance wiring – This means that nodes that are wired and tagged with a specific attribute return instances rather than strings when coding
    • Caching – several years ago he implemented node caching which improved speed a great deal.
    • Json support – He’s got json built in with string attributes

We use this data to do things like:

  • Store node relationships one to another
  • Store other information via index managed methods
  • Set toggles that are picked up by our build process

What ways do we store our data:

  • Json – String dictionary setup for complex data
  • Multimessage – Standard maya method for wiring lots of nodes
  • Message – Single message connection attribute
  • msgList/datList – 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
  • Bool – Simple flag for yes/no setup options | hasBallJoint
  • Enum – Multiple option setup attribute | ikSetup type, segment type, etc
  • Int– Whole number value options | joint counts, roll counts, etc
  • Float – Floating point value options | shape offset for example

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.

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.