The Eyes Have It…

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

Discuss on the forum
(Public Discussion)

Current Focus

  • FACE! – Working on mDrake’s face.
    • Branch – features/faceModules
  • Griffin bugs – compiling notes on issues with Rael to push to next build


  • Rael – Prep proxy for public release. Probably going to do a optimzation pass before wider release to get more fps. Seeing ~23fps after parallel is going but wanna dig in.
  • LBS



As we initially go into this, the first thing we want to do is look at what we need. As a unityMed asset we really only need simple eyes and lids.

Will a clam lid setup work?

When I was doing the alpha workup on Morpheus 2’s head a few months ago a single clam lid was going to work. For a game setup it’s ideal to have just one and it’s relatively fast to setup.  I’m not sure that’s going to work with the new mesh and so that’s the first question to tackle. So I’m gonna test it…

  • Setup a scene with latest Drake mesh
  • Dup the head and blendshape it back to our testing head so we can tweak  the geo to see if base changes will help close the lid
  • Add a simple joint structure


  • Then we open up the ever amazing ngSkin tools and go to town on some simple poses with skinning masks and some blendshape tweaking

Goatee for effect

Other things we’re looking for

It’s difficult for  to always place everything in a way that’s best for deformation when modeling. So this is a part of the iteration process and we’re looking at things like…

  • Eye orb
    • Does the eye ball fit the socket well?
    • Do the lids hug the eyes in a way that make sense
  • Lids
    • When we get the eyes open,closed, etc are we happy with the look? If not it’s easy to use the blendshape we have setup to tweak the lid shape and surrounding area to test if something slightly different would work better
  • Iris
    • Is the iris a good size? With a game asset we’re not going to do scalable iris/pupil unless the project needs it so we want the asset to look as good as possible with the least amount of setup
  • Pivots
    • If we find a good lid pivot when testing, we wanna mark that bad boy and use it for final setup

Simply taking a screen grab to photoshop to test iris/pupil sizes and ratios

Or simply throw a ramp shader on the ball to test

Through all of this we take notes for things to address in the final model that need to be addressed.

Eye Block


Successful simple eye build.

Quick pass on making sure stuff still builds with all the changes to the code base

  • Scene with just an eye and master block
    • eyeLook create failing
      • Account for a puppet blockParent
  • rig_cleanUp
    • Add new standard close out calls


Since we established that the single joint lid setup will suit our purposes, it’s a relatively simple setup we’ll go ahead and add to our rig block and then do the rest by hand till we know we like our setup.

First we look at what we have and then ask what new points of data do we need to build our clam lid.

  • Custom lid root because we found in in testing that using the eye pivot wasn’t giving us
  • 4 points of data for our lids – inner/outer, upr/lower


Starting with our base, we sketch out what we wanna do.

Awesome. So we need to look at what we’re doing in the other modules and see if we can flesh that out quickly. So, we try it out.

Where I ended up.

  • Data points at the start and ends of the lid frame.
  • Included vector helpers because it helped visualize the avenue of main motion and I’m thinking this will be great for the lower face when I get there as well
  • Initially I had the lid curve created but it makes more sense to have that at template state as that is our shaping state


This state is about making sure we have the shapes we need to generate proxy geo later and know what we’re looking at. To do this first pass I’m going to just give some generated curves the user would move rather than attempting to setup  a fancy cluster setup. I did a quick test with skinning the curve but it needs more time than I want to give to this effort at present. But something to come back to.

For later

  • Add a span specification to the lid curves
  • Try cluster setup
  • Add pulling the new data back to the define handles when deleting template


For this state we need several items:

  • Eye joint handle
  • Lid Root Handle
  • Lid Handles – upr/lwr
  • Aim handle for eye forward
  • Playing with a couple of things on this pass. The lid control shape helpers are driving a closest point track on the lid curves to help position them faster.
  • Trying a visual connection Idea I’ve been thinking about for other modules. In this case from the lid root to the lid joint helpers.
    • To me – when you loop back, try something like this for setting block parents to track to the parents attach point for better visualization. Could be active at template state or above in most cases.


This is a simple setup where we just want to place our joints and make sure they’re oriented. In our case here it’ll be just making sure we wired things so we can find them in our previous step. My guess is I missed something with the new stuff.

  • Had to fix wiring on the new handles
  • Brought new radius settings in from newer rigBlocks
  • Resolve tagging the joints to easily find in our list what’s what.
    • Thought about adding a specific tag attribute to find them in the module joint list
    • Trying direct mapping for the clam setup to the prerigNull


The rig process covers multiple states so I’m gonna walk through them one by one as I make my build. First think through what we want the setup to do. Clam is relatively simple setup

  • Have a base ik/aim chain for the clam eye that aims at the control.
  • Have a simple seal via blending between to track targets
    • Make a dag target per lid joint and parent that track to the opposite root
  • Try using the up vector of the lid control to have some build in twist
  • Add blend attribute and others to the eye settings control
  • Add the eye root setup by default
  • Added completed lid setup options to the builder bails on other ones
Data Buffer

Our initial data/logic checks to see what we need going forward so we don’t have to to if/then as much

  • EyeOrb – This is the logic we settled on
    • If you have a lid setup, regardless of if you have a eyeOrb setup option, it gives you the dag so you can move the lid and joint together
Rig Skeleton
  • Lid Joints
    • Lid root,rig,blend- oriented, named
    • Store usefully to the rig handler – self. d_lidData
  • Add new eye orb maker from new logic
  • New lid controls
  • Direct lid controls
Shapes in

Instead of appending to the existing frame I added a new sub call rig_lidSetup which calls  after the eye frame is complete. To do that we just nee d to make the module and register it to our __l_rigBuildOrder__ in our module.

Fleshing out what I need here.

  • Setup the main aim via the lid root joints aiming at their respective handles.
    • Using the handle up vectors as the up of the aim to enable simple twisting on that handle
  • Blink – for a single joint setup we’re not doing a full curve blend setup as it’s unnecessary. Instead what we need to start is:
    • Regular track target which is following our aim
    • Close track target where we tell it what’s closed. This may need to be ‘trained’ if I can’t find a simple offset value. I think we could potentially do that down the road with the template more fleshed out but doing this fast for now
    • Connect the blend of those two to the blink attribute
  • Changeable blink link – For this setup I’ll need a another series of dags to blend where the seal line is. Again this is much more visually straight forward with a full lid setup but I think we can pull something together. Prboably will just pull some code from my lip sealing r&d a few months back.
  • Lid Follow – Sometimes we want our lids to follow our eyes joints

Post notes:

  • In the end, just using Morpheus 2’s lid setup was the fastest option even with a single joint
Clean Up

Just defaults on the auto lid follow for now. Maybe more later.

Quick Relook

After getting a new module building, if I have time, I like to knock out a quick punch list of things I want to address and put down some ideas for what is currently out of scope


  • Ensure a mirrored rigBlock builds through each state


  • Rework joint helper tracking – My first iteration used a closest point on curve setup for placing the joint helper using the lid handle shape helpers to drive that. While nice to have the joint tracking with it I ended up having to tweak it anyway. Instead I’m going to use a simple u value driver for that track


  • Quick proxy geo setup – Want to be able to quickly evaluate lid setups without having to skin anything so going to setup a simple proxy
  • Seal isn’t quite even on the clam 
    • Need to use percentage to place curve right
    • Needed to rebuild the curve and not use the template one in case joints changed



And  done for now…

Drake to fix list

  • Eyes
    • Ball scale/position slightly off
    • Iris texture – scale down 10% in size keeping pupil size ratio to iris
  • Lids
    • Going to need to retopo some to get better deformation

This kinda works…

Constraining Light Group

I usually like to have a set of base lights in scene when I’m working on stuff so it looks kind of pretty. One helpful thing I’ve been doing lately is just grouping that light set and then orient constraining that group to the perspective camera or whatever camera I’m moving around. When just doing td/modeling work this works really well.

ZBrush to Maya issues

It’s been a regular issue coming from zbrush to Maya and so trying to find a consistent workflow for this has been a thing we’ve been working through.

So in the image above…

  • The tiny character at the bottom is a sized asset in maya to about 6′ tall (though we use cm usually)
  • #4 was our original asset (fbx) from zbrush we setup a scaling group for the original export to match. We’d through assets in that group to scale them down or up depending if they were going to zBrush or coming back.
  • #8 was our latest update (fbx) which wasn’t matching at all.
  • In the end obj’s are a much more consistent transfer format.

For the next asset, we’ll see about trying out zbrush’s scale master plugin  on a td pal’s recommendation.

Updating Geo Shaders

Transfer shading sets works pretty slick. Well done, Autodesk.


Changes to making stuff to make building more intuitive.

  • Hierarchical state changes wasn’t working as intended. For example you could take a master from rig to skeleton or lower which would orphan the states of those children rig blocks
    • Part null wasn’t being unparented from master so when master was unrigged, it was getting deleted
    • Some nodes are getting deleted that shouldn’t be.
      • Added a filter for a few of them
      • Had to make sure to add shapes to the filter as well.
    • Added checks on changeState to make sure parent blocks when going down state were at the targeted state and for below that were at the necessary state
    • Changes to ui to account for this. Not 100% on the solution yet, will take some play. changeState calls don’t work as the others via the ui.
    • Added confirmation dialogues for dependency driven changeState calls

  • BlockList
    • Showing the full blockstate name take a lot of space. Truncated that in the list to 3 characters.
  • Confirmation dialogs
    • When context is not set to self, add a confirmation box on the state changes
      • Initial implementation in
    • See above image for another example

New Calls

    • create_pointOnInfoNode – simple call for making a point on curve info node on a given shape
  • MATH
    • get_normalized_parameter – needed a call to work to convert curve u values to percentage
      • (value-minV) / (maxV – minV)


  • Naming
    • Name dicts were sometimes getting duplicate names in them for various reasons
      • Added a dup name check on the name combiners to account for this.
    • Segment setup not getting the mirror fk from LIMB.
      • Refactored attach joint setup
      • rig_skeleton – add attach joint adder
        if self.d_module['mirrorDirection'] == 'Left':
  "|{0}| >> Mirror direction ...".format(_str_func))
            ml_fkAttachJoints = BUILDUTILS.joints_mirrorChainAndConnect(self, ml_fkJoints)
      • rig_shapes – add a check to get the fk cast joints if the mirror joints exist
        ml_fkCastTargets = self.mRigNull.msgList_get('fkAttachJoints')
        if not ml_fkCastTargets:
            ml_fkCastTargets = copy.copy(ml_fkJoints)
      • rig_frame/rig_blend – make sure it’s gathering the
        ml_fkAttachJoints = []
        for mObj in ml_fkJoints:
            mAttach = mObj.getMessageAsMeta('fkAttach')
            ml_fkAttachJoints.append(mAttach or mObj)

To Come back to…

  • Optimization
    • rigNode connection is pretty slow. Look at way to fix that
  • LIMB – end twist skin joint. Look at an option to have a twist only wrist
    • Reverseable spine would be great for flying/swimming stuff
    • Template
      • Add a span specification to the lid curves
      • Try cluster setup
      • Add pulling the new data back to the define handles when deleting template
    • Add full lid setup
  •  HEAD
    • Aim head
      • subs blocks aren’t attaching to the aim head
      • Head aim not driving twist
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.