Well, here we come to a point at which we need to think about how the neck works and the use of an IK Spline. If we put in the ability to translate the IK spline at the very base, it will stretch the joint away from the non IK-ed joint and look unrealistic. To see this, translate Neck_Cluster_1 and watch the bone between neck1_JNT and spine2_JNT. We’re going to create a controller that is point constrained to the cluster anyway, this way the cluster will move with the rest of the rig when it is moved, but we will not let the animator have the ability to move it.
Create a controller that sits in front of the neck. I will use a triangle. Name the controller Neck_Twist_CNTRL. Freeze and delete history. Since this controller isn’t meant to directly
correlate to a joint’s rotation, there is no need to do an offset on it. Select the Neck_ Twist_CNTRL and the Neck_Cluster_1. Create a point constraint (with offset on). Then promptly lock the
translate attributes for the Neck_Twist_CNTRL. That constraint is only so the cluster will move
with the rig and is not for the animator.
While we’re working on this control, let’s hook it up to an attribute you may not be aware of. Take a look at the Twist attribute on the Neck_ IK. When adjusted, the Spline IK handle twists. Remember that ease in attribute we set when we created the IK handle? You can still adjust that, if desired, in the attribute editor. While you are there, turn on root twist mode to see how the twist looks slightly
different. I’ll turn it on for my rig. We could take the controller’s rotation in X value and hook it directly to the IK handle’s twist value. That is a one-to-one connection. How do we do that? Do you remember? Somewhere close to Chapter 3. Correct. We can use the connection editor or the Hypergraph: Connections window; you remember now. Select the Neck_Twist_CNTRL and the
Neck_IK and open the Window>Hypergraph: Connections window. Using the right mouse button
connect the Neck_Twist_CNTRL’s rotate X to the Neck_IK’s twist. Lock all attributes for the
Neck_Twist_CNTRL except for the rotate X. Rotate the controller in X and the neck should twist
back and forth. Oh my! It rotates backwards from the controller. Goodness. Guess you’ll need to use a multiply divide node. Review Chapter 4 to remember how.
Figure 11.9 Creating a controller to move the bottom cluster and twist the neck.
Hierarchy
Your gut instinct should be to take all of the offset groups for the neck controllers and make them a child of the Spine2_CNTRL. Better save your file first. If you try that the neck will become all twisted. It works for all of the controllers except for the twist neck controller. So, to give a level of offset, take all of the neck controllers and group them. Label that group Neck_GRP. Make the
Neck_GRP a child of the Spine2_CNTRL.
We aren’t out of the woods yet. Rotate the Spine2_CNTRL to see what you get. Oh goodness, a double transformation. What? Something is telling the neck to rotate twice as far as it should. This is the part that gets everyone messed up when they deal with Spline IK handles—because we automatically trust where Maya put the curve in the hierarchy and are afraid to move it. Move it, we must. Many books will tell you when making the IK Spline to turn off the option for auto parent. We didn’t— I’m evil that way. We’ll learn how to get out of this very common mistake. Locate the
Neck_Curve in the outliner. If you switch to wireframe mode, you can see the curve is being rotated
forward by the joint. Select nothing and create a group node; name it DoNotTouch. Make the
Neck_Curve a child of the DoNotTouch node. Make the DoNotTouch group node a child of the
main character node named Marv. Test your rig by rotating the Spine2_CNTRL to see that the neck rotates correctly now. What could have went wrong there? Make sure you have the Spine2_CNTRL zeroed out before you move the Neck_Curve, else your neck will be stuck in the double transform position.
Figure 11.10 Placing the controllers in a hierarchy and putting the clusters, Iks, and curves out of harm’s way (chpt11_Marv_bird_RIG_v8_Spline_Back.mb).
The last little bits of clean up are to group the clusters together and name that group
Neck_Cluster_GRP. Make that group a child of the DoNotTouch group. Lastly, place the Neck_IK
under the Marv_ SKEL group. Go ahead and select the DoNotTouch group node and change the
visibility to 0. We don’t want to see what we shouldn’t touch.
Extra Effort: Just to see how it would behave, I selected a neck joint and then the neck control
and created an orient constraint. I repeated this for the three inner neck controls and the top neck control. The top neck control, the pyramid, is the one that visually needs that extra constraint so that it rotates well for the animator. There is no functionality in this constraint except aesthetics. In animation tests you can decide whether you like the constraint or not. Lock the rotation attributes on the neck controls. In animation tests, you might determine that the box controllers don’t look right when they are animated. They feel cluttered. Perhaps a simple ball at the back of the neck would have done better. Change as needed before putting your rig into production.
Head
There should, at minimum, be a head control that rotates the head. Since we have already rigged the neck as an extended part of the back, rotating the head joint is about all the functionality that is left to add a controller to. Create a controller for the animator to rotate the head with. I will use rig101WireControllers’ Arrows on Ball icon. Move the control to be on top of the head; rename
Head_ CNTRL; freeze transformations and delete history. With the controller so far away from
the joint, you have a choice. Keep the pivot away from the joint or place it at the same place as the head joint? It feels a little weird to the animator, in my opinion, to have the pivot point far away from the controller. So, I will keep my pivot point centered on the controller. If the pivot points are in separate places, what constraint can we not use? The constraint we cannot use is the parent constraint. That is fine, because the parent constraint won’t work for the trick we’re about to do anyway. If you try to use the parent constraint on this next bit, you’ll get a cycle warning. Remember that; that one will give you a headache at 3 am in the morning.
Select the Head_CNTRL and Head_JNT and create an orient constraint with maintain offset on. This will cause the head to rotate when you rotate the head controller, but the head controller stays behind. Do you remember how to make it follow the head? Select the head_feather1_JNT, or whatever you called that joint that is right at the top of the bird head, and then select the head
controller. Make sure you selected the joint first. Create a point constraint with maintain offset on.
Now when you select the head controller and rotate it, it rotates the head but also translates in space to match the top of the head. Just as a reminder, a parent constraint won’t do correctly with the pivot points and will throw a cycle check warning. Lock the translate and scale attributes on the head controller.
A note on a human neck with only two joints : I mentioned, back when we were creating the bird
neck, that a human neck should have at least two bones to help approximate how we bend our neck. Here’s a neat setup for that type of neck and its controllers. You would create a Neck1_CNTRL and place at the bottommost neck joint and do the typical orient constraint between Neck1_CNTRL and Neck1_JNT. To get a nice blend for the second neck joint you could create an orient constraint from the Neck1_CNTRL to the Neck2_JNT and then also create an orient constraint from the Head_CNTRL to the Neck2_ JNT. What this does is the Neck2 joint will follow both the head and
the neck1 and live somewhere in-between. This gives a nice blend between the head and the neck. I don’t know when we came up with that one in class. Students in animation tests didn’t like having multiple neck controls and this was a good solution.
Hierarchy
Where to put the head controller? When you bend over your neck does not necessarily rotate with your body. It is separate in rotation. (Hold a chicken and move it back and forth to see this in action; a live chicken—it doesn’t work the same with a dead chicken.)
To make the head rotate with the body you would make the head control a child of the top neck FK controller or the top spine controller if you had a Spline spine. We don’t really move this way; our neck and head is not tied to our backs, unless you have a rod up your spine. The way we have the controller already point constrained to the joint means there isn’t much we have to do to the controller. It already goes with the rig. Simply make it a child of the Marv_CNTRL group.
Test. When you rotate the upper body, the neck, and head controllers move along with the joints.
The head does not rotate with the upper body; I call this the chicken head movement. I spent a lot of time with chickens as a child.
Figure 11.11 Adding in the head controller.
For those advanced in the group. What if you did want the head to have the option of rotating with the body or not? You can turn constraints on and off and set up an animateable switch. With that switch the animator could have the head rotate with the body and then turn off so they can have it animating not rotating with the body. Hmm. Sounds like a fun setup. Go look at some rigs on
creativecrash.com and see if you see something like that out there. There is also a hint of how to do just that thing in Chapter 19.
For the rest of us mere beginning rigging mortals—we’ll keep this setup. In the chapter materials, you will find a completed bird up to this point with an FK spine, a set driven key spine and a Spline IK spine. I will continue rigging the Spline IK spine for the rest of the chapters. A current version of the rig can be found in a file named: chpt11_Marv_bird_RIG_v9.mb.