Intro to MRS Workflow – Fall 2018

MRS Learning

Talk about this post on the forum

Welcome to a rough initial workflow demonstration using MRS. This will be a big picture look at things as a roadmap for us to figure out what docs we need for this team.

What came first the chicken or the rig?

The age old question. In our case it’s going to begin with a model. In this case I downloaded a free model from Turbosquid.

Now, there’s few things we need to always check on new models we want to rig.

Plan

Whenever we start a new project with a client and we get our first asset we’re going to have a lot of questions.

  • Target medium – Is this for render only or for games
    • Games
      • What engine – each engine has it’s own quirks and things to bear in mind as you work forward like joint orientations, rig structure and skin cluster
      • Are there special deformers or systems to support – wrinkle tech, corrective blends available, etc
  • Range of action
    • We always ask for an idea of what this asset will be doing. Boards are great.

Geo

We take a look at the geo looking for:

  • Draw over or mentally look at the points of articulation we’re going to want and see if the geo has edgeloops to make that work.
  • Keep in mind the project target – is it for games, is this a throw away background asset or a hero one that needs to perform
  • Extra points of articulation to ask if they want those things to move or not.

Orientation

So our model is pointing z- which in our case isn’t what we want as we set our rigs up z forward, y up. So we’ll flip it around

Size

When we get models to rig for clients we always want to check the size to make sure it’s right. Sure our rigs scale but you want to rig at scale unless there’s a compelling reason not to.

We can check that a couple of ways. Create some distance measures or in our case we’re just gonna select the mesh and throw a master rigBlock on it which will auto size to the geo.

Selecting our masterBlock we see the base size data is 67.8 x 95.9 x 87.3 units. Our preferences are in cm so for us americans that means our chick is….

26.69 x 37.75 x 34.37 inches.

That seems rather large for a chick.

So I’m gonna size my baseSize setting down to 15cm.

And then size my chick geo down to match.


Now we’re ready to move to defining things a bit better.

Define

The define state is where we add the various rigblocks to roughly lay out the parts of our chick. We’re concerned about:

  • Start and end points for blocks
  • The rough proportions of the block
  • General orientation

These are changed via the few controls during this state:

  • Master offset value – There is an attribute on the master rigBlock that sets the curve offset value. This is a key setting for our rig as it says how far we want our control curves to be offset from the proxy surfaces and lots of other calculations.  It is visualized by the outer circle on the master rigBlock.
  • rigBlock handle – This is the white locator form curves you see in scene. This is the root of the rigblock and lets you move the whole block and change settings manually if you prefer that to the ui. Though the UI affords a myriad of extra options we’ll get into later.
  • Define handles
    • end – This handle controls where the block is aiming and maybe scaled to change the proportions. There are distance measures available per block on an attribute called visMeasure
    • up – This is the up for the block and is important to place correctly
    • rp – this doesn’t do much until we want to snap our handles to a plane for better rotation
    • lever(optional) – this only shows up when the block has that option toggled and designates the lever position – like a clavicle

Template

The template state is about roughly shaping our surface to match our chick. We’re concerned about:

  • Geo roughly approximating the geo – this is because the surfaces we’re setting up will be used for both control curve creation as well as our proxy geo creation after we rig
  • Head geo – when we have a head we want to turn off the drawing overrides on our selected head and manually shape it to match our chick. Also, any geo thrown in the head proxy geo group will be picked up during proxy creation. As such, I added a rough beak in there.

These are changed via the few controls during this state:

  • Template Handles – These are the yellow rounded squares. They used to be sphere by they got in the way of selecting things so for now at least we’re trying squares.
  • Shapers – These handles are on the surface. You can move, rotate and scale them. You can even move the cv’s (note, cvs that have moved don’t currently mirror)

Prerig

The prerig state is about pivots and joint chains. Note, at this point I don’t do all the fingers or toes or mirror the other side until I’ve done some test builds with the settings.

We’re concerned about:

  • Pivots – We’re looking at bank pivots, control pivots and joint ones as well
  • Cog –  Need to ensure that it’s where you want it.

These are changed via the few controls during this state:

  • Prerig handles – The axis looking controls are our control pivots. One of which on most chains will be colored blue,green,red for normal axis and have a black sphere around it. This is the ik handle and it’s orientation will affect our rig’s ik handle
  • Bank pivots – When you have a bank of foot end to a limb setup you’ll be offered pivot helpers to designate the boundaries of the foot or shoe as well as the center point. These will be used as the pivots during the rig phase for the bank setup. Make sure you rotate the main handle to match how you want the bank orientation to be.
  • Joint handles– Coupled with the pivot handles are sphere ball helpers that the joint loft runs through. These are to specifically position the joint chain and see it’s representation with that inner loft.
  • Cog – A two in one helper with the dag and the shape being separate. The dag is represented by the curve text ‘COG’ and the shape by the pyramid arrows around the block.

Skeleton

The skeleton state is our review state to be able to cleanly pull a rig off and retain skinning.

We’re concerned about:

  • Names – Check the joint names are processing correctly as those names will be pushed through our rig
  • Counts – Make sure our roll joint counts are correct
  • Orientations – Ensure joints are oriented as you expect

If things are wrong:

  • Change settings or prerig handles and rebuild

Rig

The rig state is the rig. We’re usually going to iterate several times while checking things. In this case, I started building with just one leg and one toe to test things. Iterating through I found:

  • Controls pivots weren’t where I want them
  • My bank control I’d forgotten to rotate
  • Realized my left blocks were tagged right (hence they were red) so fixed that.

We’re concerned about:

  • Controls – Check the joint names are processing correctly as those names will be pushed through our rig
  • Errors – We ensure  everything builds making sure we don’t have have  errors in the script editor or just grab things and make sure they move as expected

If things are wrong:

  • Change settings or prerig handles and rebuild

Once I’m happy. I build the other toes or other bits, review. Then mirror my side blocks and build those.

Post

After we rig, we’re done. Right? Right?!

  • After we think we have everything how we want it, we should check our controls again.
  • When we think we have it all, then it’s best to do a little test animation or throw it to an animator to get some notes for the inevitable next iteration.

What might we want to do after rigging via the UI:

  • Gather rig blocks – Use the post call to group all the rig blocks we’ve got laying around in our scene under an easily hidable group. You’d want to delete these for any production rigs
  • Mirror Verify – This call walks our rig and maps our mirror setup following Red9’s mirror setup
  • Gather space drivers – Grabs and space driver objects that aren’t where we want them and puts them in the hierarchy. This is for our dynParent setup. Target objects don’t know where to go at creation and need to be collected at the end.
  • Qss – 
    • Bake set – makes a bake set (currently targetting Unity workflow)
    • Delete set – Same but for deleting stuff
  • Connect/Disconnect Rig  – Because we have a separate rig structure from the bind one, this connects and disconnects that setup
  • Verify Proxy – Creates the proxy mesh you’ve seen. It also replaces the direct control shapes of the rig with transparent proxy mesh shapes for easy selection
  • Puppetmesh – An idea we’re playing with. It generates an part-based or unified mesh to use for modeling ref or a skinning frame

And after that?

  • We’d skin in a final mesh if we had one
  • Throw it to some animators for testing and iterate
  • Generate a proxy mesh for a modeler to work from and tweak our template when we got the final mesh and rebuild.

 

We hope you’ve enjoyed this little overview of the workflow. If you’d like to find out more about using MRS in your own work, check out the MRS Collaborative.

Until next time!

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.