Between my first and second semester at school this year I had a full month off, and I used that time do the prep work for my second term where I’m going to do a sort of dry run for my thesis in fourth year.  Since most of my projects at school thus far have offered only two or three weeks work time I haven’t done any major projects.  My intention this term was to start with rigged characters and a script and spend the whole term doing little bits for the larger project which will be a short 3D character animation.  I guess I’m a little behind then, but moving the whole project forward is an enormous amount of effort.  I’m going to try to stick to the purpose of this blog and explain what I’m doing as I go along, this post will pertain to rigging.

So this is my rig right now, and it’s the template that I’m going to use for the rest of the characters in the story.  It’s just a matter of scaling the bones to fit the different sizes of characters.  Once everything is programmed the skeletons can be dropped into a scene and with a few hours of skinning it’s all ready to go.  In the short there is a scene in a grade three classroom full of students, in the interest of time I’ll be using the auto weight function of the weight tag to quickly make each student poseable.  Since they don’t need to move that much the auto weight should suffice to pose them in their desks, and morph tags will be my solve to get those characters working quickly.

INDEX

Click any of these links to jump down to a specific part of the post.

PREPARING THE SCENE: HyperNurb Controller
RIGGING JOINTS: Sloppy Constraints
RIGGING ANATOMY: Collar Bone
SKINNING: Mesh Details
SKINNING: Clothes
SKINNING: Mittens & Hands
PREPARING TO ANIMATE: Alerts
PREPARING TO ANIMATE: Constraint Aim, Anchor & Default State
PREPARING TO ANIMATE: Controllers & User Data
USERDATA: XPRESSO “Databurst”
USERDATA: Ways to control from the HUD
THE FINAL RESULT: XPRESSO
THE FINAL RESULT: ACTION POSES

PREPARING THE SCENE: HyperNurb Controller

By no means am I an expert at character rigging, but I know enough about how time consuming it can be and I’m always looking for ways to optimize my workflow.  A big time saver for me is making my own buttons and sliders, the most effective one is a HUD pulldown that changes the HyperNurb subdivisions of the character mesh.  I like to have maximum control over my surfaces, the geometry is made from as few polygons as possible and then is subdivided.  Too few polygons can be dangerous for rigging, however, so I bumped up my model geometry one subdivision and used that as my core mesh.  This switch lets me go from no subdivision to a low, medium, and high mesh resolution.  When rigging, especially while skinning, I’m constantly turning HyperNurbs off and on, checking for collisions, so having this on the HUD was a huge help.  On my permanent HUD I also had a mesh toggle which hid all of the geometry, and anchor and alert toggles which I’ll explain later.

RIGGING JOINTS: Sloppy Constraints

I’m not going to go into huge detail here on how I rigged the joints, I used very common techniques.  Basically I made a skeleton and jointed it with a mix of IK and FK.  So the elbow and shoulder joints for example, are IK aimed at the wrist; when the wrist moves the arm bends at the elbow and shoulder depending on where it is in 3D space.  The hands feet and head however are FK, so I can grab one of the bones early in the chain and moving it will move everything under it, an example would be moving the ankle joint also moves the heel, foot ball, and toes.  Something that proved really difficult was prioritizing the constraints and XPRESSO that help keep the bones moving how they’re supposed to.  Cinema calculates from top to bottom of the object viewer list, so if an object at the top of the list was aimed at an object lower on the list it would make that calculation before repositioning.  This results in objects that drift as they’re moved around, they are constantly pointing to the positions of the previous frame or iteration.  So all you have to do is click on the tag and set the priority to a higher number, this way the calculations will run through all of the 0 priority nodes first, and 1 priority nodes after running through the whole list first.

RIGGING ANATOMY: Collar Bone

Once the joints were made and the constraints sorted out I had to start thinking about automating the rig as much as possible.  My approach to rigging is that if I spend a bit more time programming and organizing the mechanics of the rig, I will save huge amounts of time struggling when I’m trying to pose and animate it during the project.   So I aimed for as few controllers as possible, and opted to put buttons on those controllers to reveal more for fine tuning.  A good example of this is the movement of the shoulder when the arm is raised above 90º.  The ball and socket joint of the shoulder can rotate in any direction, but only to a certain point.  When the arm is lifted above 90º the collar bone steps in and lifts the whole shoulder.  Lucas Martell did a great little podcast on this here.  So to solve this on my rig I created an expression that calculates the global height of the shoulder and elbow, then subtracts the elbow from the shoulder.  This gives me an integer that represents the height of the elbow relative to the shoulder, so when the number is positive the elbow is below the shoulder, negative means it’s above.  The expression takes this value and uses it to control the pitch of the collar bone, which raises the shoulder and arm with it.  I did the same thing for when the character reaches forward, but to a lesser degree.

The automation is done, but does not take care of every possible arm position, so I made a button that turns off the shoulder mechanics, when clicked a controller appears on the shoulder that lets it be posed anywhere.  The idea is to make the process as simple as possible, but if need be also to have the potential to tweak very fine details to get the movements just right.

SKINNING: Mesh Details

Skinning is always where the project bottlenecks for me, but lots of the trouble I’ve had in the past has taught me to plan better while modelling.  You don’t want too many polygons because the gradients will take forever to even out, but you don’t want too few because polygons don’t fold very well.  So I took my original mesh geometry which was too efficient to be rigged as it was and put it under a HyperNurb with a renderer subdivision of 1 and made it editable.  So now my “low” setting on the mesh resolution button was my off state.  I had to reprogram my toggle again but now I had the perfect number of polygons.

SKINNING: Clothes

In an earlier post I mentioned briefly that I was trying to decide wether to simulate the clothes or not.  This is the first character I’ve done that had overlapping meshes and details like this one.  The first breakthrough I had was deciding to use Cloth Nurbs in conjunction with HyperNurbs; the hypernurbs did the rounding and shaping, and the cloth (which I set to zero subdivisions) was responsible for creationg thicknesses after the HyperNurbs.  Since the thickness was being generated after the mesh was being deformed I got a bit of flexibility before meshes would punch through other ones.  This was especially hard with the straps of the overalls, but ended up looking great because the overalls have an independent weight from the shirt, so they can move different amounts at different places, they end up sliding around a bit.

A real challenge with this rig was the multiple meshes that would be using the same bones to move.  I tried to plan so that the ends of the T-shirt and pants landed on or near the middle of bones, so that they could have full weights and would be consistent.  I’d never really done multiple meshes this way, but it started to make sense really quickly.  It was worth that bit of struggle because now that I’ve got it figured out I’m not going to let mesh complexity keep me from making more and more elaborate characters in the future.

SKINNING: Mittens & Hands

The hands involved a lot of head scratching, they proved to be much more complex than I had though when planning, and like any good problem the solution was painfully easy, sort of a “duh” moment for me.  I was really sold on mittens for Isaac, in the drawings Mike gave me the hands weren’t really defined, so I opted for mitten hands because I thought they’d suit the character.  I figured I’d rig them like real mittens, three fingers inside that could move about and deform the hands.  What I didn’t foresee was that I was creating a matrix of influence on the hand.  I had the high subdivision required for smooth posing mixed with four joints per finger.  For each bone there has to be an area painted on the mesh called a weight map, this tells the rig which points will move with the bone, and how much.  Each colour here represents a different bone, and they have to blend together in order to deform smoothly.

It was a nightmare, I was fed up with the mittens, so I used a hand that I was modelling for another character and began setting up the bones on the Isaac rig.  Thats when I realized that the solution had been staring me in the face the whole time, I had to start using the bones in ways no finger could bend.  I went back to the mittens mesh and deleted the pinky and pointer finger, then I let the middle finger influence everything, now I could work with edge loops for the hand and get really simple feedback to correct the mesh.  The reason I didn’t think of it sooner was that I wanted the mittens to have as much possible movement as they could, not just curling into a fist but twisting and banking the way it would with independent fingers.  I achieved this with the single finger by giving it another axis of rotation, our fingers and curl up and move side to side a little but they cant roll.  Since the bones of the middle finger now go right to the sides of the mittens I could just use an rotation parameter with an exponential increase in influence for each subsequent joint.  The whole hand is now controlled with three sliders and gives me exactly what I want.

PREPARING TO ANIMATE: Alerts

As I mentioned before, part of my permanent HUD for this rig is a toggle for alerts.  Alerts are a handy bit of XPRESSO I cooked up to measure the length of the certain bones and turn on bits of geometry when they’re too long.  I designed the hands, feet, torso and neck to extend out past their physical limits for flexibility when animating.  If it’s a cartoony movement it would be fine, but if I need finite movements the alerts let me know when the bones would be ripped apart.  I put alerts at the ankles, wrists, and torso.

The torso can be pulled around when the character is stretching or bending so this one has two levels of alerts, when the torso is stretched or squashed more than usual a yellow constraint pops up, when it’s gone too far that alert turns red.  Alerts have already given me a lot of data to keep my project organized and scaled properly.  Definitely going to continue doing them in the future.  Here’s a look at the XPRESSO for turning on an alert (click on the image to view full size):

PREPARING TO ANIMATE: Constraint Aim, Anchor & Default State

Another part of the automation process is controlling the orientation of the hands and feet, I set up three ways for them to operate.  By default the joint can be dragged around and the hand (or foot) will stay pointed in the same direction as its handle, this is what I use for animating all of the bending actions, it is the most common:

Next I added a constraint mechanism that references the position of the elbow or knee relative to the wrist or ankle and aligns it, this means that when dragged around the appendage will always be pointed straight out (perpendicular to the plane that the connecting bone travels through), this is great for waving or kicking:

The last option for the wrists is to use a set of anchors, this attaches the hands or feet to a null that is outside of the mesh hierarchy.  So if the body is dragged away, the hand will stay put where the anchor is located.  The anchor can also be put as a child of another object or part of the body, this will make the body part stay put and it will move with the object it is anchored to.  Anchors are great for holding props and bodyparts, they can also be children of objects or nulls that have set animations (here the arm is being controlled by the position of the pencil, which in turn is being aligned to the spline on the desk):

The magic for the anchor and aim conditions are that they are animatable.  I with the use of a slider I can blend between any of the three states, this is done by animating the strength of two separate constraints in conjunction with the other.  Blending between states lets me switch from and anchored state to an aligned state in the middle of a sequence with proper interpolation and no position keyframes:

PREPARING TO ANIMATE: Controllers & User Data

When the model is finished I try to clean up the scene and get down to business.  So the fist thing to do is sort out all the layers, splitting up the bones, nulls, helpers, controllers, and meshes.  In the layer browser you can hide the objects from the manager or viewport.  I hide everything but what I need to animate with.  With the scene like this you don’t need the object manager that much and it can be hidden in exchange for more screen space or room for the curve editor.  I use splines, nulls and geometry to create floating rings and shapes around the major control points of the character, this lets me select them by clicking on them in the viewport.  These controllers receive the keyframes that control the bulk of positioning the rig.  User data is another way to control your rig in a predictable way without much fuss.  I find sliders infinitely useful for repetitive tasks.  I’ll talk a bit more about different HUD elements later on in the post.

USERDATA: XPRESSO “Databurst”

I duno what to call this little action, but it’s basically a way to send a burst of data to set a variable, so for now I’ll call it a databurst.  I know this isn’t the most efficient piece of code, I’m sure it’s way easier to do with COFFEE script, but my COFFEE is horrible.  Either way I think it’s an important function, a real time-saver.  It works like this, when a userdata boolean is clicked a condition node is triggered and two things happen, first the state of the boolean is set back to zero (which turns it off), and second a value is changed from it’s existing value to another input source, this can be either a constant variable or another set of data all together.  Since the condition node is triggered by the boolean, and the new value is triggered by the condition node, when the boolean reverts back to zero (which happens instantly) the condition node reverts to it’s zero state, which is whatever the current value is of the data you are triggering the change to.  This means you can set a whole bunch of positions, or orientations and then make little tick boxes that trigger them.  On my rig I’ve used this to quickly shoot preset data at multiple nodes simultaneously, to reset the rotation and position of the hips and spine tip.  The beauty of this button is you press it once and the data is reset but not fixed to the reset state, right away sliders can be changed and you’re never locked out of a userdata element.

USERDATA: Ways to control from the HUD

There are lots of useful ways to use the Heads Up Display (HUD) to control your scene and characters.  It usually requires a bit of XPRESSO but is well worth learning to do.  When I set up my HUD system I have certain controls that are always visible, and ones that appear only when the controller is selected, for example the head controller.  I group all my data into one panel, and then hide the widget and name and set it to auto fold, then drag the collapsed panel to the bottom or top of the window.  This gets it out of the way when you’re working, but when you mouse over the thin black strip the element will pop open and give you your controls, it’s sort of like the Mac OSX dock.

There are lots of kinds of userdata, some work better with the HUD than others, I’m partial to sliders, 2D vector scopes and booleans.  For the Isaac rig I used float sliders for most of my controls, booleans for toggles and “databursts”, and 2D vector scopes for a graphical representation of settings that have, for example, X and Y latitudes, like the position of the eyes, or the orientation of the hat.

Another way that the HUD can be used is to create a more dynamic visual selector.  I spent some time making one for the Isaac rig that ended up being too bulky to use, but it was a cool experiment.  I built this with bitmap tiles that represented various nulls and selectors and slid them over a template of the overall graphic, it folds up to the top of the viewer out of sight, but unfolds to take up much of the screen.  It works by clicking on the circles to select parts of the body.  Hopefully in a future release of Cinema 4D they will make the visual selector a little more dynamic.

THE FINAL RESULT: XPRESSO

ESPRESSO was my main tool after constraints and MOCCA tags.  Here are all my nodes in one window, click to view full size.

THE FINAL RESULT: Action Poses

So all this work, lots of problem solving, and the rig is finished.  Here are a few example poses that I used to test out the rig while I was skinning it, notice there are some intersections and issues with some jointing.  This is an important part of the process, putting the character into realistic poses as well as extreme poses shows me the limits of my rig, so if I tame the extreme poses the more natural ones tend to behave perfectly.

So that’s the rigging post, hope it was informative.  As always any questions are welcome in the comment box, I will do my best to provide the correct answers.  My next post will describe my research into a 2K 32bit multi-pass OpenEXR workflow.  I’ll also try to post up some of the sets and props as they’re built, as well as my progress on a new character that Mike has just sent me the drawings for.