Last Updated: 12.29.2018
DOC IN ACTIVE DEVELOPMENT
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.
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 - ContextualSection – There is a button
To Activethat 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.
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
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.
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.