RigBlocks

Last Updated: 08.18.2020

General

Profiles

Block profiles may have their settings changed at will. Profiles are simply presets.

General notes:

  • Profiles are initially loaded at creation but they should be able to be safely loaded at define state
  • Distances are stored in cm (maya's base unit)
  • Some settings are overridden by the buildProfile settings. For example some game buildProfiles will have endJoints off.

MASTER

Last Updated: 04.18.2019

_images/master_rig.png

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

Profiles

None

Settings

controlOffset

_images/ui_controlOffset.gif

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.

addMotionJoint

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.

Shared

See shared settings

  • numSpacePivots

Define

The Master block skips the define state by default. The proper method for scaling the master block is to use the baseSize attribute to frame the object. Then rebuild the form state.

Form

_images/master_template.png
  • 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

Prerig

_images/master_prerig.png
  • motionJoint Helper [1] | Arrow pointing down. The joint would be created at the dag of this prerig helpers.

Tip

Only builds when the addMotionJoint setting is True

Rig

_images/master_rig.png

master

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

Attributes

  • 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)

settingsControl

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.

Attributes

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

visControl

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

Attributes

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

rootMotion

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.

_images/master_dagStructure.png

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)

PuppetNetwork

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.

Master

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".

Groups/Nulls

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

HANDLE

Last Updated: 04.18.2019

_images/handle_profiles.png

HANDLE | rigBlock for simple points of articulation

Profiles

Block profiles may have their settings changed at will. These are simply presets.

General notes:

  • Profiles are initially loaded at creation but they should be able to be safely loaded at define state
  • Distances are stored in cm (maya's base unit)
  • Some settings are overridden by the buildProfile settings. For example some game buildProfiles will have endJoints off.

Cube

  • basicShape | cube
  • proxyShape | cube

Sphere

  • basicShape | sphere
  • proxyShape | sphere

Cone

  • basicShape | pyramid
  • proxyShape | cube

shapers4

  • proxyShape | shapers
  • loftShape | square
  • numShapers | 4
  • numSubShapers | 0
  • shapersAim | toEnd
  • loftSetup | default

shaperList

  • proxyShape | shapers
  • loftShape | square
  • numShapers | 4
  • numSubShapers | 0
  • shapersAim | toEnd
  • loftSetup | shaperList
  • loftList | ['circle','square','wideDown','wideUp']

snapPoint

Snap points are special handles for prop joints for game work.

Note

After you build, this control's visiblity on the parent module's setting control. So if you add a snap point to the wrist you'll find an attribute on the arm's setting

Settings

Almost always located on our rigBlock dag

rotPivotPlace

enum | Where we want the rot pivot to generate from

  • handle
  • jointHelper
  • cog

Special Calls

proxyGeo_getGroup

Makes sure we have a geo group. Can select it.

proxyGeo_add

Add proxy geo to the setup by duplication so as to leave the original in tact. Wiring it as needed.

proxyGeo_replace

Add proxy geo to the setup by duplication so as to leave the original in tact. Wiring it as needed. Remove what's there. What is removed will be parented to world and tagged with _REMOVED

UI

Has right click menu via mrsBuilder.

  • Report Group | Print the name of the group
  • Add Selected | Add selected geo to the proxy geo setup
  • Replace with Selected | Replace existing geo with selected
  • Remove Selected | Remove the selected
  • Select Group | Select the geo group

Define

Shared attributes

shapeDirection

enum | Sets the initial cast direction of our block

Shapes

What are we looking for at this state?

  • Do you see a rigBlock handle for it? All good

Form

_images/handle_template.png

Shapes

Control Shape

In our case here it's the yellow cube. You can change that option but you'll need to retemplate to see it

ProxyShape

The geo cube is the proxy shape. You can change that option as well.

Attributes

On the rig block you'll find a proxy enum attr that will let you unlock the geo to manipulate it.

What are we looking for at this state?
  • Shape | You want your template to generally match the look you're going for. If you're not working from a mesh and just an image plane really pay attention to your various angles.

basicShape

enum | Kind of loft shape you want for the control.

circle:square:pyramid:semiSphere:sphere:cube

proxyShape

enum | Kind of loft shape you want for the proxy geo.

cube:sphere:cylinder:cone:torus:shapers

Shapers option give you our template setup to shape.

shapeDirection

enum | Which direction you want your basic and proxy shapes facing relative to your rigBlock dag

addScalePivot

bool | NOT IMPLEMENTED

loftSetup

enum | default:loftList

  • default | Single loft shape for each handle
  • loftList | Specify each handle's loftShape via the loftList enum datList

loftList

_images/loftList_01.png

loftList example

enum datList | Special datList verified at template state or loaded from initial profile

shapersAim

enum | toEnd:chain

  • toEnd | Each handle aims to the end
  • chain | Each handle aims to the next handle

Prerig

_images/handle_prerig.png

What are we looking for at this state?

  • Joint Handle | Place and orient the joint helper [1] where you want it
  • Pivot Helper | OPTIONAL. When you have an addPivot setup you'll get this. You can use the main [2] to move them all and each pivot handle[3] to precisely place the points of banking

Skeleton

What are we looking for at this state?

  • Joint orient | make sure they look like we expect
  • Joint parent | make sure the root of your chain is going where you expect. When we get to the head for example, we wouldn't want that root of our neck to go to the pelvis unless we had a pretty atypical design.

hasJoint

bool | Do you want a joint

Rig

addAim

bool | Setup aim similar to the head setup

rotPivotPlace

enum | Define where you want the rotate pivot placement for your rig control.

Post

Change Log

2019

February
  • Documentation - UI, Special Calls
  • Added loft setup to shape a handle item.
  • Amended proxy mesh setup with this new option
  • Added loftList setup. First block to receive
  • Added ability to add custom geo
  • UI for geo adding | add/replace/remove
January
  • Docs | Initial pass
  • Retool | Bringing this original prototype rigBlock up to snuff
    • Added rigBlock handle
    • Added new necessary dicts/attributes
    • Initial testing

LIMB

Last Updated: 05.16.2019

_images/limb_profiles.png

LIMB | rigBlock targeted for hinged rig portions

Profiles

Block profiles may have their settings changed at will. These are simply presets.

General notes:

  • Profiles are initially loaded at creation but they should be able to be safely loaded at define state
  • Distances are stored in cm (maya's base unit)
  • Some settings are overridden by the buildProfile settings. For example some game buildProfiles will have endJoints off.

arm

finger

thumb

leg crab

leg plantigrade rear

leg digitgrade front

leg digitgrade rear

leg ungulate front

leg ungulate rear

leg unigrade

nub

Define

_images/limb_define_02282019.png

Shapes

The locator form shape [1]. Select it to get the dag.

End Define Handle [2] | Defines the end point of our block. You can scale this and the bounding box scale visualization which change shape.

Attributes

  • length
  • width
  • height

RP Define Handle [3] | Defines the rp vector for the block. This controls the rp Plane [6] visualization helper

Up Define Handle [4] | Defines up for our aim to the end.

Lever Define Handle [5] | Defines where the lever base position will be and the up vector for that setup. The up arrow helper on this control matters. If you form builds funky, check this.

Bounding Box Visualization [7] | bounding box representation of the baseSize

Form

When we form rigBlocks. Sometimes they have very different looks.How you decide you want your shaping control dictates what you do. As we talked about with `SEGMENT<#segment>`_ ).

See guide shape helpers for a breakdown on what the specific handles do.

There are a number of settings that affect our form.

buildLeverBase

enum | The lever is what we call our base hinge setup with a clavicle for the first joint of a finger for example.

  • dag | Turn on for structure to be created
  • joint | If you want a joint there

The lever loft mesh will be extended when on.

_images/limb_leverOnOff.gif

buildBall

enum | Whether to add the ball. Adds a handle to our count.

buildToe

enum | Whether you want a toe or not. Adds a handle to our count.

Form Loft Mesh

This surface is imporant. It is used for proxy mesh creation and control curve casting. You can affect its shape via the loft handles and the settings to some degree.

Prerig

See guide shape helpers for a breakdown on what the specific handles do.

Workflow

  1. Place the prehandles at the points of articulation you want.

  2. Use builder tools:

    1. Visualize | Rp Pos - See where the system things your knee or elbow are. If they're wrong check your rp vector handle.
    2. Snap to RP - Ensure the handle chain is on the same rotate plane

Skeleton

numRoll

int | A main value for how many roll joints per segment of joints.

rollCount

int/datList | A datList chain of attributes to set the roll count per segment of our LIMB. Currently set during the template state call.

Rig

segmentMidIKControl

bool | This to setup an extra midIK control on the segment from one point of articulation to the other when you have roll joints.

ikEnd

enum | This makes it so the ball is setup as a reverse hinge to the ankle. It'll make more sense as we get into the material

ikRPAim

enum | This controls how our rp setup follows our chain. Note you can always change the space of the rp handle. This affects our main space driver.

default | Uses an up vector for the aim free | Vectorless aim following. We use this on the arm as we don't want the elbow to follow the wrist around as much as the knee generally.

buildLeverEnd

_images/limb_hasQuad.gif

leg digigrade rear

bool | This makes it so the last section is setup as a reverse hinge to the ankle. We use this on our quad setups.

mainAxis

enum | This helps us counter flipping as it lets us figure out the twist axis by specifying the main. For example the main axis on a leg is out because it folds over the knee. Our arms because we usually orient them to be y going up through the shoulder would be up setup because that is the main axis of rotation to collapse the plane.

out | up |

Controls

The kinds of controls you see will depend on your rig options for the rigBlock. In our case we start with something like this.

Settings
_images/leg_controls_01.png

leg digigrade rear

The settings [1] we've talked about on the spine. The gear is our standard settings shape when no cog is present

Note

Many of these attributes would not be on this control should we have a separate settings control

Attributes

  • FKIK | float | Blend between fk/ik mode. It controls that blend as well as the visibility of those controls.
  • visSub | bool | Whether or not the subcontrols of this rig section are visible. In our case, we only have one. If we had used more joints than controls, we'd have more of these.
  • visRoot | bool | Toggle visibility of the root control for the se
  • visDirect | bool | Whether or not the per joint controls of this rig section are visible. By default they are cube curves. When the build option of proxyDirect is checked. The proxy mesh replaces those curves.
  • blendParam | float | Determines how the joints follow the ribbon surface. Floating evenly or fixed to their attach point
IK End

Our main IK control [2-bottom]. The options and setup for our limb IK can be very different based on rigging options.

Attributes

  • axisAim/Up | enum | Settings for our aiming system. If you use raycast aiming or other systems these settings will be used per control. If no settings are found, the global defaults will be used.
  • pivot_0/pivot_1... | enum | Same as discussed for master.
  • autoStretch | enum | Stretch on our rp chain
  • lockMid | enum | lock the mid to the rp handle
  • spinMid | enum | twist the plane which guides the base follow for the rp handle
  • extendIK | enum | When we have endLever on we get this attribute which controls how our ballRotation control orients
  • space | enum | Setup by the dynParent System. orientTo would denote a point/Orient setup with orientTo setting the orient target and follow the position target
_images/limb_footNoToe.gif

Attribute foot setup

Pivot Attributes - when we have a pivot helper we get extra options

  • roll | float | front to back edge
  • centerBank | float | ...
  • centerRoll | float | ...
  • spinFront | float | ...
  • spinOuter | float | ...
  • spinInner | float | ...
  • spinBall | float | ...
  • spinBack | float | ...
  • bank | float | Side to side edge
IK Base

This control IK Base [2-top] is for the start of the ik chain

Attributes

  • axisAim/Up | enum | Settings for our aiming system. If you use raycast aiming or other systems these settings will be used per control. If no settings are found, the global defaults will be used.
  • orientTo | enum | Setup by the dynParent System. orientTo would denote a point/Orient setup with orientTo setting the orient target and follow the position target
  • follow | enum | ...
RP Control

This rp control [3] controls our poleVector for our rp plane

Attributes

  • axisAim/Up | enum | Settings for our aiming system. If you use raycast aiming or other systems these settings will be used per control. If no settings are found, the global defaults will be used.
  • pivot_0/pivot_1... | enum | Same as discussed for master.
  • follow | enum | Setup by the dynParent System. Only follow would denote a point only setup
Segment Handles

The segment handles [4] control the ribbon for the segment joints. The number you see will be determined by our build options.

Attributes

  • followRoot | float | What the control follows. Be it the root or the blend frame.
Ball Rotation Control

The handle [5] acts as a reverse hinge for the foot. The buildLeverEnd is what makes this setup.

_images/limb_hasQuad.gif

leg digigrade rear

Attributes

  • axisAim/Up | enum | Settings for our aiming system. If you use raycast aiming or other systems these settings will be used per control. If no settings are found, the global defaults will be used.

Note

The orient of this control is controlled by the extendIK attribute on the main ik control

Pivot Handles

Each of our pivots has a handle [6] for direct manipulation.

Note

Their visibility is controlled by settings.visSub.

FK Head

The FK head [3] is the default on head setups currently so it's what we see.

Attributes

  • axisAim/Up | enum | Settings for our aiming system. If you use raycast aiming or other systems these settings will be used per control. If no settings are found, the global defaults will be used.
Root Control
_images/leg_controls_02.png

leg digigrade rear

The root control's [2] visibility is controlled by the settings. As we turned it on we can see it. It is a dag under which the rig is parented and as such legs you move the whole section of the rig when necessary.

Attributes

  • axisAim/Up | enum | Settings for our aiming system. If you use raycast aiming or other systems these settings will be used per control. If no settings are found, the global defaults will be used
  • space | enum | OPTIONAL | Added when the spaceSwitch_direct option is on. Setup by the dynParent System. Space would denote a parent setup.
FK Controls

FK controls [1] are for direct rotation and movement

Attributes

  • axisAim/Up | enum | Settings for our aiming system. If you use raycast aiming or other systems these settings will be used per control. If no settings are found, the global defaults will be used
Direct Controls

We need to toggle an option to see some more:

  • Settings
    • visDirect | True

The direct controls' [1] visibility is controlled by the attribute we just changed. These are per joint controls for when the animator needs the highest fidelity of control.

On the neck we saw cubes. Because I already verified proxy on the leg. The cube shapes have been replaced by the proxy shape.

Attributes

  • space | enum | OPTIONAL | Added when the spaceSwitch_direct option is on. Setup by the dynParent System. Space would denote a parent setup.
visControl

On master. Remeber back on the master. The master settings has a new attribute registered with every module that builds that lets us see/interact with our rig guts.

Attributes

  • R_FRNT_leg_limb_rig | enum | toggle to hide/see but not touch/touch the rig guts

Post

Settings

proxyLoft

enum | What the control follows. Be it the root or the blend frame.

  • default | do whatever the profile wants
  • toEnd | force it to extend the loft to the end
  • ``toStart``| force to extend to the start
  • ``toBoth``| force to extend both directions

Road Map

Known Issues

  • Zero roll joint and multi roll joint on same limb | This causes some weirdness I'll resolve in the next sprint for unity mobile

Change Log

2019

April
  • End rework | buildEnd replaced hasEndJoint. Major rework to make more consistent
  • Form handle Seperation | rework so that the control/handle count is no longer tied to the form handles. This let users change their handle counts without having to reshape things.
  • FK only building now
February
  • Better define vectors
  • Docs
    • Updated some profiles
    • Few image updates
January
  • hadQuadSetup | This naming was confusing. Changed to buildLeverEnd as it's more useful than just quad setups and sometimes you don't want this on quads. Depreciating tipCombo out to use this instead.
  • Docs | Initial pass
  • Lever template | Worked on how lever template is setup to make it the sub loft curve setup more consistent
  • FK cast dags | Added a dag cast setup for the fk shapes. A user was having a bug because we'd been using prerig handles and their end prerig handle was rotated very unexpectedly. May need to revisit to deal with more cases.

SEGMENT

Last Updated: 04.17.2019

_images/segment_profiles.png

SEGMENT | rigBlock targeted for flowing segments of joints

Profiles

Block profiles may have their settings changed at will. These are simply presets.

General notes:

  • Profiles are initially loaded at creation but they should be able to be safely loaded at define state
  • Distances are stored in cm (maya's base unit)
  • Some settings are overridden by the buildProfile settings. For example some game buildProfiles will have endJoints off.

Simple

_images/segment_simple_01.png

Simple segment

  • attachPoint | end
  • baseVector | 0,1,0
  • baseSize | 30,15,76
  • ikBase | cube
  • ikEnd | cube
  • ikSetup | ribbon
  • mainRotAxis | up
  • numControls | 4
  • numShapers | 6
  • numSubShapers | 3
  • nameList | "start","end"
  • segmentMidControl | True
  • settingsPlace | start

Spine Up/Fwd

Our standard spine

  • attachPoint | base
  • base Vector | [up | 0,1,0 | fwd | 0,0,1]
  • base Size | 30,15,76
  • ikBase | hips
  • ikEnd | tipMid
  • ikSetup | ribbon
  • mainRotAxis | up
  • nameIter| "spine"
  • nameList | "pelvis","chest"
  • numControls | 4
  • numShapers | 2
  • numSubShapers | 3
  • segmentMidControl | True
  • settingsPlace | cog

Tail

_images/segment_tail_01.png

attachPoint | base base Vector | 0,0,-1 base Size | 14,9,76 ikBase | simple ikEnd | tipBase ikSetup | ribbon nameIter| 'tail' nameList | 'tailBase','tailTip' numControls | 6 numShapers | 5 segmentMidControl | True settingsPlace | end

Tentacle

  • attachPoint | base
  • baseVector | 0,0,1
  • baseSize | 14,9,76
  • ikBase | simple
  • ikEnd | tipBase
  • ikSetup | spline
  • loftList | 'wideDown','squircleDiamond','squircleDiamond','circle'
  • mainRotAxis | up
  • nameIter | 'tentacle'
  • nameList | 'base','tip'
  • numControls | 6
  • numShapers | 4
  • segmentMidControl | True
  • settingsPlace | end
_images/segMid_issue_fix_01.gif

EarUp

In Testing

  • attachPoint | end
  • base Vector | 0,0,-1
  • base Size | 10,10,20
  • ikBase | simple
  • ikEnd | tipBase
  • ikSetup | ribbon
  • nameIter| 'ear'
  • nameList | 'earBase','earTip'
  • numControls | 4
  • numShapers | 2
  • numSubShapers | 3
  • segmentMidControl | True
  • settingsPlace | end

Define

_images/segment_define.png

Shapes

The locator form shape [1]. Select it to get the dag.

Up Define Handle [2] | Defines up for our aim to the end.

End Define Handle [3] | Defines the end point of our block. You can scale this and the bounding box scale visualization which change shape.

Attributes

  • length
  • width
  • height

Form

Attributes

These attributes change what our template looks like.

Shapes

When we template rigBlocks. Sometimes they have very different looks.How you decide you want your shaping control dictates what you do.

For example if you have a straight segment like a spine you'd probably just want something like this to have two major scale points and no need for mid articulation.

_images/segment_template_2handle.png

2 Shapers, 7 sub shapers = 9 loft handles

If you're doing a tail or something with breaks you probably want to have more handles and fewer sub shapers. The second setup ends with the same number of loft shapers but has a place to hinge things.

_images/segment_template_3handle.png

3 Shapers, 3 subshapers = 9 loft handles

Form Handles

The dark rounded corner handles[1] (color will vary by side). They are used for big movements and scaling. Sub shaper handles are controlled by these.

Loft Handles

These are the actual curve handles [2] that our template loft runs through

You can change the cvs on these however that data isn't currently stored in our blockDat so rebuilding will wipe it

Orient Helper

This arrow shape [3] controls the 'up' of our segment root for rigBlock aiming and joint aiming.

Form Loft Mesh

This surface is imporant. It is used for proxy mesh creation and control curve casting. You can affect its shape via the loft handles and the settings to some degree.

Prerig

Attributes

  • numShapers
  • numSubshapers

segmentMidIKControl

bool. Whether to setup an extra midIK control on the segment

Shapes

_images/segment_prerig.png
Prerig Handles

Axis shapes [1].

  • These represent our points of articulation
  • One per numControl count will be created
  • The each have a joint handle with them
  • The last one is colored by axis colors to differentiate as it is important. The IK handle during rigging will take the orientation of this handle. Pay attention to how it is rotated.
Joint Handles

These sphere shapes [2] are our handles to control our joint loft.

  • The joint loft represents what our joint chain will be at the skeleton state
Joint Loft

The lofted surface running within our proxy loft is our joint loft. It represents what our joint chain will be.

  • It is controlled by the joint handles

Note

We've toyed with the idea of per joint handles to exactly place roll joints but that would mean you'd have to rebuild the prerig every time you wanted to change the roll count. For now you can move them manually at skeleton state.

Cog Helper

See Shape Helpers | Cog Helper

This shape [3] is our Cog Helper.

Rig

There's a lot of things happening when we rig.

  • rigBlock | Our rigBlock has its .template attribute turned on so that it's easier to not inadvertently select it post rigging
  • Dag structure | created and setup for all our rig setup for both this block as well as others
  • Shapes | Different nurbs control shapes are generated
  • Rig wiring | The rig is wired so that we can get all the information we need once the rigBlock is removed from the scene. Remember it is a frame to build the rig and designed to be removed once we have our asset completed
  • Dynparent setup | Based on our settings, the master will have our dynParent setup added as well as spacePivots for that system

Controls

The kinds of controls you see will depend on your rig options for the rigBlock. In our case we start with something like this.

_images/spine_rig_handles.png
Cog/Settings

The cog [1] we looked at previously. During the rig process our cog dag helper has a transform created at it, then the cog shape helper is shape parented to that new transform to make the control.

Because of our options, our cog is our settings control. This is an option. If you had had it off, you might see a gear instead.

Note

Many of these attributes would not be on this control should we have a separate settings control

Attributes

  • FKIK | float | Blend between fk/ik mode. It controls that blend as well as the visibility of those controls.
  • visSub | bool | Whether or not the subcontrols of this rig section are visible. In our case, we only have one. If we had used more joints than controls, we'd have more of these.
  • visDirect | bool | Whether or not the per joint controls of this rig section are visible. By default they are cube curves. When the build option of proxyDirect is checked. The proxy mesh replaces those curves.
  • axisAim/Up | enum | Settings for our aiming system. If you use raycast aiming or other systems these settings will be used per control. If no settings are found, the global defaults will be used.
  • pivot_0/1 | enum | Same as discussed for master.
  • blendParam | float | Determines how the joints follow the ribbon surface. Floating evenly or fixed to their attach point
  • space | enum | Setup by the dynParent System. Space would denote a parent setup.
Base/Mid/End IK

We are seeing the ik controls because we are in ik mode

  • Base IK | Hip shape [2] at the base of our spine
  • End IK | chest shape [3]
  • Mid IK | [4]

Attributes

  • axisAim/Up | enum | Settings for our aiming system. If you use raycast aiming or other systems these settings will be used per control. If no settings are found, the global defaults will be used.
  • pivot_0/1 | enum | Same as discussed for master.
  • blendParam | float | Determines how the joints follow the ribbon surface. Floating evenly or fixed to their attach point
  • space | enum | Setup by the dynParent System. Space would denote a parent setup.
Segment Handles

We only see one [5] but as we mentioned. The number you see will be determined by our build options. When our control count matches our joint count we don't need an extra ribbon as we can use the main. When we have extra joints we have a separate ribbon which these controls would influence.

Attributes

  • followRoot | float | What the control follows. Be it the root or the blend frame.
FK Controls

If we turn on fk mode we'll see the fk controls.

_images/spine_rig_fk.png

Note the shapes hug our proxy we shaped during the template state.

Attributes

  • axisAim/Up | enum | Settings for our aiming system. If you use raycast aiming or other systems these settings will be used per control. If no settings are found, the global defaults will be used.
visControl (ON MASTER)

Remember back on the master. The master settings has a new attribute registered with every module that builds that lets us see/interact with our rig guts.

Attributes

  • spineSegmentRig | bool | toggle to hide/see but not touch/touch the rig guts
Dag Structure

For those that care about the rig structure

_images/spine_rig_outliner.png

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

  • spine_segment(dag- cgmRigModule)
    • spine_rigNull(dag)
  • spine_segment_deform_grp(dag)
  • spine_segment_animSet(objectSet)
Module Dag/RigNull

The spine segment dag is a tagged mClass node of type cgmRigModule[LINK THIS WHEN DONE]. This is a special kind of dag that holds most pertinent information for the rig wiring.

  • Non transforming dag | this dag is for non-transforming dags/nodes
Deform Group

We have a deform group that is placed under the master control deform group.

  • Deforming nodes for the rig go here.
  • Sometimes I have a separate constrain group under this
  • Typically rig controls end up in here
Object Sets

Each rig Module gets its own animation objectSet to which all rig controls are registered

  • spine_segment_animSet | Master anim set for puppet controls. Sub modules have their own sets added to this one

Change Log

2019

February
  • Documentation
  • Added loftList setup. First block to receive

HAND

Last Updated: 04.18.2019

_images/hand_progress_0226_01.png

HAND - blockFrame for digits

This block is in very alpha state. This is our first blockFrame rigBlock . It's our digit handler or HAND for short.

Profiles

Block profiles may have their settings changed at will. These are simply presets.

General notes:

  • Profiles are initially loaded at creation but they should be able to be safely loaded at define state
  • Distances are stored in cm (maya's base unit)
  • Some settings are overridden by the buildProfile settings. For example some game buildProfiles will have endJoints off.

Human

  • numFinger | 4
  • numThumbInner | 1
  • numThumbOuter | 0
  • fingerProfile | finger3
  • definePose | relax

Toon

  • numFinger | 3
  • numThumbInner | 1
  • numThumbOuter | 0
  • fingerProfile | finger3
  • definePose | relax
_images/hand_toonTest.gif

HAND - blockFrame for digits

Paw

  • numFinger | 4
  • numThumbInner | 0
  • numThumbOuter | 0
  • fingerProfile | finger1
  • definePose | wide

Workflow

Roughly how hands are intended to be used.

  1. Place your arm or leg or whatever how you want it. When you're ready for your hand...
  2. Add a hand and set the blockParent to the thing it should follow and set the attachPoint
  3. Snap it to the end handle of the thing it should follow
  4. Size it using the base size and the handles
  5. Set your finger count and other options
  6. Verify your drivers
  7. Tweak those settings to shape and position
  8. Verify your subBlocks
  9. Push those subBlocks to template state
  10. Snap/Shape align those blocks
  11. Build and iterate to find a setup you like best
  12. When you're happy, mirror those subBlocks to the other side with or without a hand

Special Calls

verify_drivers

Builds the drivers from our eventual rigBlocks to be driven by the system

verify_subBlocks

Checks and/or rebuilds the rigBlocks driven by this rigBlock. Typically LIMB block fingers or thumbs.

subBlock_align

Call to snap/shape rig blocks to the blockFrame.

mBlockArg

str/mNode | What we want to process. If none, it does them all. If a rigBlock passed that has this as it's blockFrame, will use that one.

templateScale

enum | Whether to scale the template loft curves or not

UI

_images/hand_ui_02272019.png

Has right click menu via mrsBuilder.

  • Verify Drivers | Rebuilds the drivers. If you change the finger count for example you'd want to do this
  • Sub
    • Verify | Make sure we have the driven rigBlocks we expect
    • Rebuild | Force a rebuild on the sub blocks
    • Snap | Position and orient relevant handles
    • Shape | Cast shape the loft curves as well as position and orient relevant handles

Define

_images/hand_define.gif

Shapes

Bounding box

The size of this object is defined by the baseSize attr. When you define the block the define handles are spaced within this volume. So roughly sizing this to your hand will aid you in more quickly getting to what you want.

Define Handles

The little balls you see are to be used to roughly approximate the boundaries of the hand. The thumbs are more direct than the fingers which will sub split based on finger count.

Vector Handles

The Thumbs have vector handles which will be more clear once we have our drivers verified.

Settings

baseSize

float3 | We've used this before. The important thing here is that you change the size and the redefine to have the define handles lay themselves out in the volume represented.

definePose

enum | What positional layout do we want our initial define handles in our volume. The base vector for the thumbs are changed by this setting.

  • wide | Layed out on a plane as much as possible
  • relax | Slightly rounded layout.
fingerProfile

enum | What LIMB profile do we want our sub blocks to use.

  • finger1 | Single section finger
  • finger2 | Two section finger
  • finger3 | Three section finger. DEFAULT.
  • thumb | Single section finger

State Goals

What are we looking for at this state?

  • Position and orientation of the rigBlock
  • Size using the base size
  • Shape the general shape of the hand with the define handles

Drivers

_images/hand_drivers_base.png

This block as a special sub state when the drivers are. When you verify the drivers you'll see something like this (note, default material on)

Settings

There are a number of settings that affect our drivers.

numFinger

int | How many fingers do you want spread on our frame

numThumbInner

int | How many inner thumbs do you want. Inner thumb is what we have as humans. Only one supported for now.

thumbInner_0_scaleX/Y_X and finger_X_scaleX/Y_X

float datList | Current iteration on shaping the hand at this state. You have x/y scale control per driver per finger/thumb

_images/hand_drivers_change.gif
paramFingerStart_X / paramFingerEnd_X

float datList | How you can slide the digits across the curves for more finese in placement

paramSplit_X

float datList | Where you want the breaks in the digits. Currently setup for 2 but plan on expanding in future.

_images/hand_paraSplit.gif

SubBlocks

The idea of the blockFrame is it eventually creates the fingers/thumbs we need to make the actual hand work.

Using the ui, you can:

  • Verify or rebuild subblocks
  • Snap align them
  • Shape align them
  • Mirror to the other side
  • Self mirror (why you would want to we're not sure but the tech was there from the facial stuff so).

Known Issues

  • Param split setup for 2 and doesn't honor extra splits though it will still build fine
  • You need to push mirror a couple of times when mirroring HAND rigBlocks.

Change Log

2019

April
  • FK build | build with no ik now
February
  • Docs
  • First Implementation

BROW

Last Updated: 08.20.2020

_images/brow_rigged.gif

Still ironing these out...

Define

Workflow

  1. Place the block root between the brows

  2. Use the boundingBox attr to kinda frame in the brow.

    • The bottom line should be under the typical brow line just above the ye
    • The second line just frame in the eyebrow ridge
    • The top should be the top of the forehead

  3. Redefine it to push that new size to the define handles

Note

You can snap state handles to a selected mesh with the right click pop up in Builder

Shapes

_images/brow_define.gif
Bounding box

Open Cube shape that changes with the boundingBox frame for the brow. Subsequent rebuilding of define after changing this will reposition the define handles within that volume.

Define Handles

The little balls you see are to be used to roughly frame in the brow.

  • You can use the ui to snap handles to selected mesh
  • Making your geo a live surface is also a good way to handle this
  • Raycast handles is yet another option

Note

Size of define handles dictated by jointRadius

Settings

boundingBox

float3 | This controls the bounding box volume

jointRadius

float | At this point, this affects define handle size. It also affects some handle sizes later on

Form

Workflow

  1. See if you have enough handles to get the general shape before getting too far. If not, up the formBrowNum or formForeheadNum
  2. Place the form handles to conform the brow surface to your character

Note

You can snap state handles to a selected mesh with the right click pop up in Builder

Shapes

_images/brow_form.gif
Surface

Just like most of our blocks, this one has a surface to help convey what the shape is we'll be deforming.

Form Handles

The little balls you see are to be used to control our surface.

  • formForeheadNum | int | Controls the number of form handle rows from brow ridge to peak
  • formBrowNum | int | Controls the number of form handle rows from brow bottom to ridge

Note

Changing either of these options requires a form rebuild

Settings

numSplitU/V

int | Splits for the u/v of the surface to get more or less detail on the

_images/brow_uv.gif

Prerig

Workflow

  1. Check the prerig handle counts (joint and handles) to make sure you have as many as you want. If not, change and rebuild.
  2. Place anchors where you want them as these move the other controls
  3. Orient and tweak the control dag handles how you want your brow controls oriented
  4. Check the joint specfic control placement
  5. Check your depths with conDirectOffset, controlOffset and jointDepth

Note

You can aim prerig handles along the brow chains with the right click pop up in Builder

Shapes

_images/brow_prerig.gif

The brow uses general face handles which you can find more about here:

Settings

browType

enum | The ribbon for the brow. Whether you want that split or continuous

  • full | No center setup
  • split | Control only
  • side | NOT IMPLEMENTED
buildCenter

enum | What kind of center control do we want

  • none | No center setup
  • dag | Control only
  • joint | Control and joint
conDirectOffset

float | Distance direct controls offset from surface

controlOffset

float | Distance main control shapes offset from surface

numBrowControls

int | Number of brow controls on each side. You want at least 2, otherwise just use a Handle

numBrowJoints

int | Number of brow joints on each side. We usually do between 3 and 5 depending on character and project needs

jointDepth

float | Distance joint dags and shapes inset from surface

Joint

_images/brow_joint.gif

Workflow

  1. Check where the joints are connected to on their parent especially if on a segment head to follow where you want.
  2. Make sure you have the joint count you want

Settings

Special Calls

uiFunc_snapStateHandles

Snap the state handles to a selected mesh

uiFunc_aimPreHandles Handles

Aim the brow pre handles along the chain

UI

Has right click menu via mrsBuilder.

  • Snap State Handles | Snap the state handles to a selected mesh
  • Aim Pre Handles | Aim the brow pre handles along the chain

Change Log

2020

Summer
  • Docs | first pass
  • Initial scale work

2019

  • First Implementation

MUZZLE

Last Updated: 09.02.2020

_images/muzzle_rigged.gif

Profiles

Still ironing these out...

Define

Workflow

  1. Place the block root at the chin

  2. Use the boundingBox attr to kinda frame in the muzzle.

    • The bottom line should be at the chin going back to about the ear
    • The sides should frame in the jaw
    • Depth shokd be to around the ear on a human face
    • The top should be bridge of the nose

  3. Redefine it to push that new size to the define handles

Note

You can snap state handles to a selected mesh with the right click pop up in Builder

Shapes

_images/muzzle_define.gif
Bounding box

Open Cube shape that changes with the boundingBox frame for the muzzle. Subsequent rebuilding of define after changing this will reposition the define handles within that volume.

Define Handles

The little balls you see are to be used to roughly frame in the brow.

  • You can use the ui to snap handles to selected mesh
  • Making your geo a live surface is also a good way to handle this
  • Raycast handles is yet another option

Note

Size of define handles dictated by jointRadius

Settings

boundingBox

float3 | This controls the bounding box volume

faceType

enum | What face profile for initial define setup. Still working through this one

  • default | Human
  • muzzle | Canine/feline
  • beak | Noseless
jointRadius

float | At this point, this affects define handle size. It also affects some handle sizes later on

Form

Workflow

  1. See if you have enough handles to get the general shape before getting too far. If not, up the formBrowNum or formForeheadNum
  2. Place the form handles to conform the brow surface to your character

Note

You can snap state handles to a selected mesh with the right click pop up in Builder

Shapes

_images/muzzle_form.gif
Surface

Just like most of our blocks, this one has a surface to help convey what the shape is we'll be deforming.

Form Handles

The little balls you see are to be used to control our surface.

Note

Changing options requires a form rebuild

Settings

numBridgeSplit

int | The number of handles rows that connect our bridges

numLipOverSplit

int | The number of handles rows for the lip bridge lofts

numLipUnderSplit

int | The number of handles rows for the lip bridge lofts

numLipShapersLwr

int | The number of handles for the various curves

numLipShapersUpr

int | The number of handles for the various curves

_images/muzzle_splits.gif
numLoftBagU

int | U split

numLoftBridgeU

int | U split

numLoftBridgeV

int | V split

numLoftJawU

int | U split

numLoftJawV

int | V split

numLoftLipOverU

int | U split

numLoftLipUnderU

int | U split

numLoftLipU

int | U split

numLoftLipV

int | V split

numLoftNoseU

int | U split

numLoftNoseV

int | V split

Prerig

Workflow

  1. Check the prerig handle counts (joint and handles) to make sure you have as many as you want. If not, change and rebuild.
  2. Place anchors where you want them as these move the other controls
  3. Orient and tweak the control dag handles how you want your brow controls oriented
  4. Check the joint specfic control placement
  5. Check your depths with conDirectOffset, controlOffset and jointDepth

Note

Pay attention to orients of your dag handles. They matter. The jaw and muzzle for example are vital.

Size Size of controls is calcultated off of the base value which in this case is dictated by jointRadius.

  • anchor | base / 1.5
  • achor lips | base / 2.0
  • direct | base * .75

Shapes

_images/muzzle_prerig.gif

The brow uses general face handles which you can find more about here:

Settings

The muzzle has the most build option by far in terms of what's possible. We're trying to cover a wide range of setups and as such it's a long list. It's important to note:

Note

Many of these setup options must be on during prerig build and require a rebuild

bridgeSetup

enum | Not implemented yet

cheekSetup

enum | Cheek setup option

  • none | No setup
  • single | Single joint setup
cheekUprSetup

enum | Upper Cheek setup option

  • none | No setup
  • single | Single joint setup
chinSetup

enum | Shin setup option

  • none | No setup
  • single | Single joint setup
jawSetup

enum | Jaw setup option

  • none | No jaw setup
  • simple | Single joint jaw
  • slide | Not implemented yet
lipSetup

enum | Lip setup option.

Warning

This should always be default for now

  • none | No lip setup
  • default | Regular lips
muzzleSetup

enum | Muzzle setup option

  • none | No setup
  • dag | Dag only setup
  • joint | Setup with joint
noseSetup

enum | Nose setup option

  • none | No setup
  • simple | Single joint setup
nostrilSetup

enum | Nostril setup option

  • none | No setup
  • default | Single joint setup
numConLips

int | Number of handles across the lips from corner to corner

numJointsLipLwr

int | Number of joints across the lips from corner to corner

numJointsLipUpr

int | Number of joints across the lips from corner to corner

numJointsNoseTip

int | Number of joints in the nose tip. (Currently only support 1)

numJointsNostril

int | Number of joints in the nostril

numJointsTongue

int | Number of joints in the tongue. (Currently only support 1)

smileSetup

bool | Smile setup option

  • off | No setup
  • on | Single joint setup
sneerSetup

enum | Setup option

  • none | No setup
  • single | Single joint setup
teethLwrSetup

enum | Setup option

  • none | No setup
  • single | Single joint setup
teethUprSetup

enum | Setup option

  • none | No setup
  • single | Single joint setup
tongueSetup

enum | Setup option

  • none | No setup
  • single | Single joint setup
uprJawSetup

enum | Setup option

Warning

Not implemented yet

  • none | No setup
  • single | Single joint setup
jointDepthLip

float | Separate offset for just the lip

Joint

_images/muzzle_skeleton.PNG

Workflow

  1. Check where the joints are connected to on their parent especially if on a segment head to follow where you want.
  2. Make sure you have the joint count you want and controls everywhere

Settings

Rig

Settings

UI

Has right click menu via mrsBuilder.

  • Get define scale space dat | Dev tool for gettind data for profiles
  • Snap State Handles to selected | Snap the state handles to a selected mesh
  • Seal Fix | Method to train the lip seal.

Change Log

2020

Summer
  • Docs | first pass
  • Initial scale work

2019

  • First Implementation

EYE

Last Updated: 09.05.2020

_images/eye_rigged.gif

Profiles

simpleEye

Just a ball no lids.

_images/eye_rigged_simple.gif

clam

Single joint eye setup currently used on LBS Morphy kid.

ballLid

Ball and full lid

_images/eye_rigged.gif

nonSphereLid

Initially tackled non sphere setup in the summer of 2020. It works well enough for what we needed but needs more iteration. Currently you need to use surfaceSlide pupil or iris and as a joint to make this work.

_images/eye_rigged_nonsphere.gif

Define

Workflow

  1. Place the block root at the peak of the eye.

  2. Change the base size to wrap the eye as best as possible. With nonspherical eyes you need to be especially careful.

  3. When that is good, redefine the eye to get the lid handles to better positions.

  4. Place the ends at the outer orb of the eye line and the starts at the inner corners. At the next step we get many more handles

  5. Change the jointRadius to that the handles are nicely sized against the mesh

  6. Change the lidDepth to closely approximate the depht of the lids. This will be used at the next state to get better initial form.

  7. If you need to move the iris/pupil you can do it two ways:

    1. There is a little sphere control in from of the eye that the iris and pupil will follow
    2. Manually scale and move the pupil/iris

Note

You can snap state handles to a the eye orb with the right click pop up in Builder. Additionally making a face mesh live makes placing these handles much easier.

Shapes

_images/eye_define.gif
Eye Orb

The eye orb is meant to match your eye geo no matter the shape.

Define Handles

The little balls you see are to be used to roughly frame in the lids. You won't see these if you don't have a lid setup eye.

  • You can use the ui to snap handles to the eye orb
  • Making your geo a live surface is also a good way to handle this
  • Raycast handles is yet another option

The start handles are shaped as cylinders which will scale with the lidDepth attribute.

Note

Size of define handles is connected to jointRadius

Iris/Pipil

Note

These only build if you have iris/pupil

  • Sphere in front of eye | This has a closest point setup connection to the iris/pupil shapes that follow below the surface of the eyeOrb
  • Iris/Pupil | Conditional shapes that let you scale and shape the pupil/eye control shape. irisDepth will let you offset the follow on the surface together.

Settings

buildEyeOrb

bool | If we want an eye orb joint. A dag is assumed but we don't always want a skinning joint. If we do, turn it on.

eyeType

enum | What kind of eye do we have?

  • sphere | ...
  • nonsphere | ...
irisBuild

enum | What kind of iris do we want

  • none | ...
  • shape | ...visual shape for the proxy
  • joint | When we want an iris this is what we use
  • blendshape | Not implemented but plan for a blendshape controlling the iris
irisDepth

float | How deep we want our template iris and pupil to ride under the orb surface

lidBuild

enum | Do we want a lid and if so what type.

  • none | Works great for spherical eyes.
  • clam | Single joint setup. We're working on a new version of this. This may mean something different this fall
  • full | Full lid setup. Assumes more than one upr/lwr lid

Note

This must be on to get lid handles.

lidDepth

float | How far the lid is offset from the surface of the eye. Most important for the form build.

pupilBuild

enum | What kind of pupil do we want

  • none | ...
  • shape | ...visual shape for the proxy
  • joint | When we want an pupil this is what we use
  • blendshape | Not implemented but plan for a blendshape controlling the pupil

Form

Workflow

  1. If you don't have lids you can pretty much skip this step
  2. See if you have enough handles to get the general shape before getting too far. If not, up the numLidLwr/UprShapers and rebuild
  3. Place the form handles to conform the lid surface to your character

Note

If you have a mesh to work with. Just make the mesh live and snap. Remember the interior line of handles on the the lid already track the eyeball define surface

Shapes

_images/eye_form.gif
Form Handles

The little balls you see are to be used to control our surface. numLidLwr/UprShapers controls how many data points you have.

Settings

numLidLwr/UprShapers

int | How many shapers at the form state we want across the surface

Note

Changing either of these options requires a form rebuild

numLidSplitU/V

int | How many splits on the form surface for u or v

Prerig

Workflow

  1. Check the prerig handle counts (joint and handles) to make sure you have as many as you want. If not, change and rebuild.
  2. Place anchors where you want them as these move the other controls
  3. Orient and tweak the control dag handles how you want your eye controls oriented
  4. Check the joint specfic control placement
  5. Move the scale pivot (if you have one)
  6. Check your depths with conDirectOffset, controlOffset and lidJointDepth

Note

Pay attention to orients of your dag handles.

Shapes

_images/eye_prerig.gif

The brow uses general face handles which you can find more about here:

Settings

The muzzle has the most build option by far in terms of what's possible. We're trying to cover a wide range of setups and as such it's a long list. It's important to note:

Note

Many of these setup options must be on during prerig build and require a rebuild

lidFanLwr/Upr

enum | If we want a fan joint setup

  • none | ...
  • single | Single joint setup. This is something we're still working through.
lidJointDepth

float | How deep to sink the lid joints

numConLids

int | How many controls. 3 is the least you want for most full lids. With a non single joint setup. 3 is actually 5 with the corners automatically included.

numLidUpr/LwrJoints

int | How many joints per curve

paramMidLwr/Upr

float | Where to initially place single joint setups on their respective curves

prerigJointOrient

bool | Where

Joint

_images/eye_skeleton.gif

Workflow

  1. Check where the joints are connected to on their parent especially if on a segment head to follow where you want.
  2. Make sure you have the joint count you want and controls everywhere

Settings

Rig

Settings

highlightSetup

enum | Do we want a eye highlight control

  • none | ...
  • simple | direct follow
  • sdk | sdk drivers
  • surfaceSlide | highlight slides over the orb
ikSetup

bool | Do we want ik setup? Sometimes just a direct fk control is all we want.

irisAttach

enum | How we want the iris follow

  • parent | Works great for spherical eyes.
  • surfaceAttach | First attempt for non spherical eyes. Attaches to the rig eye surface
pupilAttach

enum | How we want the pupil follow

  • parent | Works great for spherical eyes.
  • surfaceAttach | First attempt for non spherical eyes. Attaches to the rig eye surface
lidAttach

enum | How we want the iris follow

  • aimJoint | Works great for spherical eyes.
  • surfaceAttach | First attempt for non spherical eyes. Attaches to the rig eye surface

UI

Has right click menu via mrsBuilder.

  • Snap state handles | Dev tool for gettind data for profiles
  • Snap selected | Snap the state handles to a selected mesh
  • Aim Pre Handles | Aim the pre handles along the lid chains

Change Log

2020

Summer
  • Docs | first pass
  • Initial scale work
  • First non spherical eye

2019

  • First Implementation