Dynamic Finger Controls – Maya

General / 17 April 2019

I created a dynamic finger control setup in 2018, it’s pretty useful and stable so far, so I figured I’d share how it works.

Dynamic finger controls are when the animator can move the fingers manually, over the top of preset shapes. E.g. The rigger sets up a slider to make a fist, and then the animator can use that plus the manual controls to tweak the shape.

Example of what they are ^

Pros –

  • It allows for quicker animating
  • Can have more variety
  • You feel good
  • Uses fundamental parenting and hierarchy tricks – lower chance of it breaking between maya versions

Cons:

  • Time consuming

For ease of understanding, when I say “larger joints” or “orient joints” I’m referring to the images below – the larger joints are the orients/set driven key joints (SDK joint/control).

The larger joints are not the joints you bind to the skin

Making the skeleton:

Firstly, you’ll need to double up (duplicate them) on your knuckle joints and the bends in the fingers, like this:

So, the larger joints are the duplicates that will control the fingers in the main hand control – pointing or making fist shapes, will be using these joints.
Label them something different from your bind joints to indicate that they’re not to be bound/skinned.

I have labelled these joints orient instead of bind.

(hope this picture helps. Testing maya’s labelling system)

Outside of that, the hand skeleton is set up as you normally would. There’s many tutorials out there on how to set up a hand rig. The most basic being a joint for the wrist, and then a joint for each bone joint down the fingers (you can look at your own hand for reference ). All you need is your joints, no constraints or splines yet, just hand skeleton with duplicated knuckle joints

Here is how I’ve set up my skeleton and the naming conventions as well as hierarchy.

(more info below)

Controls:

Quick clarification –
Constrain vs Hierarchy: essentially it’s the same thing, though a proper constrain can overwrite hierarchy set up. As well, it can allow more more flexibility in what can control what, whereas hierarchy can be limited.
An easier way to think about this would be that if you parent a sphere to a cube, the sphere follows the cube as well as having freedom to do whatever it wants. If you were to constrain the sphere in any way, e.g. orient constrain the sphere to the cube, the cube determines what the orient of the sphere will be, and the sphere will lose its freedom/flexibility to do so.

I originally thought this was going to be simple. You have two sets of joints overlapped, so that one will control all your SDKs, then the other one to be your manual controls for the animators. These can all be accessed in the hand’s master control.

When you set up your skeleton the orient joints should rotate the chain of joints underneath. You can then constrain a curve to the orient joint, and another curve to control the bind joint that will be the manual control.

But you’ll find that once the controls are hooked up/constrained to the joints, the orient control no longer moves the manual control’s curve — easy fix, parent the curves in the hierarchy right?

That will work. Only catch is if you wanted your orient controls to be invisible like in my case, (I was using them to control shapes in the main hand control) then they will make the manual controls that the animator needs invisible too. I say that now because I don’t know what you’re after.

Solution?  Hide the shape nodes of the set driven key controls once you’re done (make *sure* you’re done)

Or

You can constrain them

Either way works. If you have a tendency to get lost with too many constraints like myself, parenting the groups and their curves in the hierarchy and hiding the SDK’s shape node later will probably work better.

There are some important things when making controls you need to keep in mind. If you’re trying to align the orientation of your control’s pivot point to your thumb joints for example, freezing transforms on your curve will reset your pivot orientation to world. To account for this,

  • Every control you make needs to be in its own group
  • Make sure you name them properly in a manner you understand

Hierarchy:

Naming breakdown – 
ORI = controls the pivot point orient of the curve parented underneath
Do not freeze orient transforms on this group – they are the offset groups that allows for correct pivot orientation on your curve

SDK = master ctrl/jnt – the controls that the Set Driven Key will be going off

-GRPctrls_L_Fingers

  • GRP_rigCTRLS_L_fingers_01
    • GRPctrls_L_thumb_01
      • GRP_CTRLS_L_thumb_a01
        • ORI_SDK_ctrl_L_thumb_a01
          • SDK_ctrl_L_thumb_a01
            • ORIctrl_L_thumb_a01
              • ctrl_L_thumb_a01
      • GRP_CTRLs_L_thumb_b01
        • ORI_SDK_ctrl_L_thumb_b01
          • SDK_ctrl_L_thumb_b01
            • ORIctrl_L_thumb_b01
              • ctrl_L_thumb_b01
      • GRP_CTRLs_L_thumb_c01
        • ORI_SDK_ctrl_L_thumb_c01
          • SDK_ctrl_L_thumb_c01
            • ORIctrl_L_thumb_c01
              • ctrl_L_thumb_c01
    • GRPctrls_L_index_01
      • GRP_CTRLS_L_index_a01
        • ORI_SDK_ctrl_L_index_a01
          • SDK_ctrl_L_index_a01
            • ORIctrl_L_index_a01
              • ctrl_L_index_a01

Etc.

^ hierarchy for groups and controls

— useful script for renaming – wp Rename (created by william petruccelli)–

Last steps for control setup:

Blue means curves, purple means joints (that’s their icon colour in the hierarchy)

  • Parent or orient constrain the SDK controls to the orient/large joints respectively (e.g. SDK_ctrl_L_thumb_a01 -> orient_L_thumb_a01).
  • Parent or orient constrain the manual controls that the animator will use (you can add the prefix anim to them quickly using that wp rename script if this is getting too confusing) to the bind joints respectively (e.g. ctrl_L_thumb_b01 -> bind_L_thumb_b01)
  • Parent constrain the last curve in each section to the first group in the next section:

ctrl_L_thumb_a01 -> GRP_CTRLS_L_thumb_b01

Repeat this for every section. So a01 will control b01 through a parent constraint, and b01 will control c01

Then repeat that for each finger

What now?

So now you have your controls working, you can move around your SDK controls, and then move the manual ones on top of those