In the reference editor change the Namespace field to bird.

Once the bird geometry is brought in you can see the icon in the outliner is very different: it has a blue dot next to it indicating that this is a reference object.

If you look in the reference editor, by opening File>Reference Editor, there is something very important to know. First off, you can see the link to where the geometry is being found. This can be updated as you change the geometry file. Why would you adjust the geometry file? Maybe to add edgeloops, blendshapes etc., or maybe the art director has made a change to the look of the overall model? When you select the geometry file in the reference editor there is a field titled Name Space. It is important to change that name to a short name that does not have a version number. This way the namespace is changed and will not update automatically when you load in new versions. What is Name Space? It is basically the name of the reference itself, the pointer to the model file. Why is it important to change the name? If you create constraints or place animation on any of the geometry itself (I know you wouldn’t do that, I told you not to), but if you did, when the geometry was updated the Name Space could change and the constraints would be lost. I saw a lot of animation lost that way in a group project once; very sad.

Why do we do it like this? As stated previously, we like this because it generally isn’t one person modeling, rigging, and animating. So, instead, this pipeline mimics production where multiple people will be doing the individual parts. This allows for a low-res model to be rigged for base movement and moved on into animation while the high-res model and higher detail rig are being developed in parallel. Time savings? Yes. However, good communication, naming conventions, and pipelines need to be established for it to work.

To do it another way—to wait for the model to be done, then wait for the rig to be done then animate—you sadly set yourself up to run out of time when animating. Also, you might find that by the time you get through with this waterfall process, something might have changed and you’ve rigged something that wasn’t needed, since most changes will start to take place once the animation starts getting roughed in and the story is seen together in a work reel.

Here is a chart to help consider what are the most important rig features to implement, what to focus on most, and what to put off until last. The horizontal line of the grid is for how important the feature is to the story. The vertical line is how much time or risk is involved in implementing the feature. (This is a game development concept I’ve seen in use and repurposed here.) So, let’s take a couple of sample features: hair, automatic blendshapes for neck waddles, and phoneme blendshapes.

Hair could rate very high on the time/risk line but may be super-important to your story. For example, Rapunzel is all about the hair, so it would need to go into preliminary tests and rigging first.

If the story wasn’t all about the hair and the character wore a hat all the time anyway, it wouldn’t rate as highly on the important to story scale. Automatic blendshapes for neck waddles are low on the time/risk line and moderately support the story. Phoneme blendshapes are moderate on the time/risk line; they do take a lot of time to sculpt but are safe features to implement—you know how to do it. If the story has any dialogue then the phonemes are incredibly important on the scale.

When you step back and look at the quadrants that you find there are four. Neck waddles fall into the “Low Hanging Fruit” quadrant. These are things that can be implemented and help give nuance to the story. Things in the upper right quadrant: phonemes, for example, are “story breakers.” If you can’t get those features, you can’t support the story. Imagine a bald Rapunzel! You will want to put those into development quickly to make sure that you can do it or hire the right consultant to get it done. If the story wasn’t about hair and the character wore a hat the hair would fall in the upper left quadrant— and this area is “avoid like the plague.” It tends to hold those whizz-bang features that took a lot of time to implement, were a lot of fun to figure out, but really add no value to your story. Usually something story-critical was sacrificed for the time spent on the dynamic hair or the “shiny” feature that wasn’t useful. The bottom left quadrant is left for things that are very easy to do—but are useless. It is coined, “why bother?” Those are complete wastes of time—though, they can be funny and useful in other ways. For example, there was a rig that Brian Jeff coat had made for the 2D animators on Brother Bear. It was a 3D version of the moose and antlers. The animators used this to aid in perspective. The rigs had a shelf of tools and one was titled “make funny.” Indeed, when pressed, the moose were adorned with Groucho Marx glasses and mustaches. Definitely a “why bother” that gave the animators a tickle. It was their first time animating in 3D and the levity was appreciated.

Another thing to consider when rigging a character for a quick moving pipeline is to make sure the animator has the main movement and rotation controls first so that they can block in the movement of the character. A thing to consider when rigging multiple versions of a rig and giving it to the animator is if the animation controls’ hierarchy changes, the animation will look different and could potentially be lost. The more you rig the more you’ll develop a style for which controls go first and which controls go next without messing with the hierarchy. Having a strong methodology (like we do in this book) certainly helps maintain order when trying to rig in passes for production. A gentle reminder, always test your rigs (by animating them) before sending your rigs into production. If you can, have an animator test them for you and give you feedback. In a perfect world, you can do that … then there is the production world. I wish you the best of luck.

Figure 7.5 Rigging features applied to a risks vs. support of the story chart.

Reminder: In these next chapters our tutorial will have both a rig file AND a geometry file. When

sending this file to your friends to show off, send both files.

A note on the geometry file : Make sure there is no key frame information on the geometry, or in

the rig file. A misplaced keyframe on a CNTRL or the geometry in a reference file will not be able to be changed accept in the original file itself. That can make it difficult to diagnose as well. Make sure the history is deleted in the geometry file else the rig file will start to slow down. Make sure that the blend-shapes are created in the geometry file. Everyone has their notes? Save the file you have created (which points to the referenced geometry): chpt7_Marv_bird_RIG_v1.mb.

We will create a typical skeleton. There are few types of joints that I require my students to have, the rest you can add as you think is needed for animateability. As you place your joints, remember the things to consider: what movement is needed, joint placement within the edgeloops, joint hierarchy, and joint orientation. Whew, that’s a lot it seems at first. After a few characters, it starts to become more natural.

First off, there are a few types of movement that I like to have in a character, no matter what type of character it is. To take care of the upper body movement, the lower body movement and the overall movement of the character I like to have three separate joints. I learned this from the Bond Girls’ rigs at EA. The joints end up being: Upper_Body_JNT, Lower_Body_JNT, and Root_JNT.

Upper body will manage the spine, the shoulders, the arms, and the head. When you rotate the upper body, all of the upper body should go with it. The lower body, I call the cha-cha. It is often forgotten by students new to character setup. You can’t do a walk without the cha-cha. The root joint will move both the upper body and lower body. Eventually, when we get it rigged, you will be able to squat the character down by grabbing the root joint, since the IK hands and feet do not move with the root joint.

Figure 7.6 Three joints make up the upper body, lower body, and root joint.

1. Using Skeleton>Joint Tool, create three separate joints.