Scott Spencer's Super Utility Node Thingy

Figure 1.1 Super Clever Utility Node Thingy

When using expressions to automate various aspects of your rig what begins as a convenience can quickly become a nuisance later on down the animation pipeline. The center pelvis expression for instance will invariably create an unnatural sense of weight in your character. It is however useful for blocking in animation and is a valuable option to have available to the animator especially if they are given the functionality to turn the expression on or off at will. The problem arises when the expression is driving the translations of a portion of the rig but not passing transformation data to it. Take for example the following expression used to center the pelvis during transformations on the foot controllers. The expression is from Maya Character Creation: Modeling and Animation Controls by Chris Maraffi.

UpBodAuto1.translateX = (LtLeg.translateX + RtLeg.translateX) / 2;
UpBodAuto1.translateZ = (LtLeg.translateZ + RtLeg.translateZ) / 2;
UpBodAuto1.rotateY = (LtLeg.rotateY + RtLeg.rotateY) / 2;

When adding spline IK backbones and further tweaking the rotations of the upper body with set driven keys we find that even if the above expression is disabled the driven keys will continue to "correct" rotations creating unpredictable and undesirable results. The solution we need is a way to feed the expression and the driven keys into a conditional node and switch the output based on a set conditional test. The answer is close at hand but not where you might expect. It is in the Hypershade.

The Hypershade is most commonly used for shading but it also gives you graphical access to many of Maya's powerful utility nodes. These nodes can be created and connected with MEL but it is much easier to manipulate them in the Hypershade where connections can be established and broken in a quick and intuitive manner. The node we will be using is called Condition. Using the Maraffi rig select the foot controller and open the Hypershade.

In the Hypershade simplify your view by clicking the lower work area mask icon in the upper right corner. See the diagram below. This will hide the textures and show just the workspace. To get the original layout back just click the two bars next to the icon we just used.

Now with your foot controller selected click Graph >> Input and Output Connections.

Your window will now look like this:

From left to right we have the curve shape node in the upper left of the screen. This is the node that describes the "shape" of the foot controller box and is not really important for our purposes. The first node connected to the network is the curve translate node. This stores the transformations in XYZ of the foot controller. This connects to the next row of 5 nodes. From the top down we have the 3 driven keys we set up to correct the torso rotations when the foot twists. The bottom two nodes on the second row are our expressions we wrote for dip and averages. Notice that connections flow from both expression nodes to the UpBodyAuto1 node while the driven key connections flow directly to the IK handles. From this graph you can see no mater if we turn off the expressions the driven keys will continue to affect the rig. Continuing across the graph are three BlendWeighted nodes that blend the values from the driven keys and ultimately feed them into the inputs of the last three nodes the IK handles for Back Neck and Hips.

To solve this problem we need a way to conditionally test to see if the averages expression is on and if so feed the driven key info to the IK handle nodes. Inversely if the expression node is off we need to not only not pass those values from the driven keys to the IK handles but make sure that the IK handles retain the last values they were fed to prevent the rig from snapping back to origin as is a common issue with conditional switches on expression driven rigs. The solution is a utility node called Condition.

From the Maya docs:

Condition is a utility node that allows you to switch between two colors or textures, depending on a simple mathematical relationship between two input values. If the relationship (Greater Than, Less Than, Equals, Is Not Equal To, etc) is true, then the first color or texture is output. If the relationship is false, then the second color or texture is output.

Even though the documentation says it is for changing color what they mean is that it passes vectors based on a condition. Vectors in the simplest terms are groups of three related numbers. RGB values are vectors but so are XYZ coordinates or sets of roll values for three IK handles! So you can see how with very little effort we can hack the node for our own purposes. To add the condition node scroll down the left side of the Hypershade to the Utility Node section and MMB drag condition over to the work area.

Your network will now look like this:

Now with Condition selected open the attribute editor for a better understanding of how this node functions.

The node consists of two terms fittingly named "first term" and "second term." The node looks at these two values and performs the operation selected in the drop down box. The operations available are Equal, Not Equal, Greater Than, Less than, Less or Equal. All of these operations evaluate as either True or False, yes or no, black and white.

Based on the output of that operation the node then passes the values below "Color if true" or "Color if false" out as the "Out Color."

Note again that the "colors" are represented by a set of three numbers. These three colors R G and B will represent the three IK roll values for our network.

Back in the Hypershade MMB drag the Averages script node onto the Condition node and release. A popup window appears asking which connection to make, select "other." The connection editor will now open. On the left you have the Averages Expression node outputs and on the right you have the condition node inputs. Connect Node State from the averages node to First Term on the Condition node.

Now when we switch the node state on the expression from normal to have no effect it was pass a 0 or 1 to the condition node as the first term. Node State is accessible from the channel box under outputs when the foot controller is selected.

The graph now looks something like this.

Now that we have a value being fed into the first term of the condition we can start giving it values to manipulate. Break the connections between the BlendWeighted nodes and the IK handles by click dragging over them and hitting the delete key.

Now MMB drag the first blendWeighted node over the condition node and release. Again select "other" and enter the connection editor. In the connection editor we will connect the OUTPUT value from blendeighted to the color "If True R" input value on the condition node. See below:

Repeat the same procedure for the next two blend Weighted nodes connecting their outputs to "color If True G" and "color if true B" respectively. Now if we look at the graph this is what we have:

See now we have the driven key values feeding into the true section of the condition and the nodeState of the Expression feeding into the first term. Now we much connect the outputs to the IK handles and make the whole shebang fizzle... Wow... its late... but I digress...

MMB drag the condition node onto the first IK handle. Remember that we are transferring over the value from the first blend weighted which we input as "color if True R" so in the connection editor connect "Output Color R" from condition to the Roll input on the IK handle. Not that the output we are using is "Out Color R" NOT "Color if True R"

Continue to connect the inputs of the other two IK handles to the Out Colors from the Condition node. Make sure you work in the same order you connected the original outputs though or you will map the wrong driven key to the wrong IK handle. Once R G and B are connected to Head Neck and Waist IK your graph will look like this:

At this point open the Condition node in the Attribute editor or channel box and make sure the second term is set to 0 and the operation is set to Equal.

Note that now the Color if True values are yellow telling us they are governed by an incoming connection... cool....

You may want to save your work before this next step. Take this moment to rotate the leg controller on your rig. Now turn off the node state on the Averages expression by setting it to hasNoEffect. You will see that the rig jumps back to 0 causing it to become a total mess. The reason this happens is that when we turn off node state the value passed to condition is now 1 instead of 0. This evaluates as not equal and therefore false. Looking at the image above we see that in that case values of 1 are being passed to roll on the IK handles. This is very simple to correct. We simply need to recursively connect the IK handle roll outputs back into the condition node. This has the effect that as the roll is changed by the driven keys it passes this value back into the condition node as the "Color if False" value. Then if we happen to switch off the expression the last value passed is maintained on the IK handle keeping in "locked" where we had it until we move it again or turn the expression back on. To connect the IK handles MMB drag them one at a time back over the Condition node. Open the connection editor for each one and connect the Roll output on the IK to the "Color if False" R G and B values that correspond to the IK handle you are connecting. Your graph will then look like this:

I hope this tutorial helped. As you can see the same network can be modified to correct for any number of expression switches that may cause the rig to behave unpredictably. If you have any questions, corrections, or anything else email me at

scott@doppelgangerdesign.com

AIM eindoppelganger

back