Running In Circles

So I've spent the past month rigging and it's been nothing short of a nightmare.I guess in Maya you have to assume that the first time you do anything you're not going to get it right because that's pretty much what happened with this. I can't even count how many times I've rigged this thing but I'm sure if I kept count with tallies on the wall this room would look like a prison cell.

Legs
There's a super duper tutorial on youtube under Maya Learning channel that walked me through 75% of my rig. Sadly I did not have enough time to complete automatic snapping between FK/IK joint switching but I did get a lot of other awesome things done. I pretty much built 3 leg joint hierarchies, one for FK, one for IK and the last one for result. I used blender nodes to create a switch between IK and FK that drive the result leg joints. On the IK foot, the Maya Learning Channel had a tutorial on a smart foot rig that has a customizable roll angle for use in walk cycles. Instead of using joints to create a foot roll, locators are used instead. The IK knee posed an interesting solution as well. Two kinds of knees were created (driven by a switch between the two), a manual knee pole vector, and a no flip knee pole vector. The locator for the no flip knee was translated in the position X axis so that no matter what position the leg is in, the knee will never flip. To control the direction of the knee, a knee rotation value in the channel box is used.

Dumb ol' me completed all this only to realize I did not orient the hip joint correctly. So I had to scrap everything and start over from the base skeleton. I really learned my lesson to double check in the orthographic views to make sure joint rotation is correct.

Arms
Naively, I believed the arms would be a breeze since it's pretty much the legs repeated, right? No....in addition to IK/FK/Result joints, theres also an arm twist joint chain. This cause so much havoc especially later on in the reflection process because the inherit transform of the curves the drive the twist joint chain must be DISABLED, or else you get weirdo double transformations when you move the model by the root joint. Also, you cannot reflect the arm twist chain along the x scale for the opposite side of the skeleton because the inherit transforms of the reflected curve must be disabled. This means the curve cannot be reflected across the x axis. If you try to construct the curve for the reflected twist joint chain, the chain will snap to the curve but move to the opposite side of the skeleton. Thus, to avoid all of this, the entire twist chain must be constructed from scratch when reflecting onto the other side. This isn't much of an issue since you can reflect a dummy chain, use point snap to draw the twist chain, then simply delete the dummy chain. Figuring this out and testing it was frustrating as hell.

The entire concept of how the twist chain works and is connected did not sink in until I had to figure out how the hand is connected to the arm. In simple terms, the FK/IK drive the result which drives the arm twist chain. This becomes uber important when working on the palm controls.

Hands
Doing the actual finger controls was more tedious than difficult. A lot of set driven keys to set up. The tutorial offered another innovative process in which there is an FK joint chain that enables the set driven finger movements to be modified.

The palm controls were pretty much IK handles in the fingers to keep them from moving in the palm movements. In the process a new hand joint is created. The new hand joint is grouped into it's own group. The finger IK handles are parented to the new hand joint group.

The challenge was figuring out how to connect the new hand joint correctly. The finger IKs were parented to the new hand joint group which was connected to both the hand control (for the IK arm) and the FK hand control (for the FK arm). This would have been very simple if I didn't have to deter from the tutorial, which does not connect the joints into one hierarchy (which is essential for weight painting). The tutorial instead opts for a section based joint chain, which I never understood why because then weight painting is made extremely difficult. But I guess that rig was for tutorial purposes rather than be practical.

Spine
Easy as pie. Took only a couple hours to figure out. The tutorial has a really cool spine which is a combination of FK and IK controlled. It's a little confusing at first, but ultimately is a lot more user friendly than the pure FK spine in the Norman rig.

Mirroring
From this point onward, I deterred from the Maya Learning Channel tutorials and had to work out which parts of the skeleton could be duplicated with the x scale, and which joints had to be mirrored (thus breaking the connections). The overall pattern was the IK and FK joints could be duplicates. The result joints had to be mirrored so the IK/FK blend had to be reconnected to the result arm and leg joint chains. The arm twist chains (as I stated before) could not be mirrored or duplicated, but had to be constructed from scratch. The hands I was able to duplicate and then reconnect to the arm.

Face
I opted for another tutorial which uses joints on the face. I tried using wire deformers but found there was no easy way to mirror the wire deformer and still retain the cluster handles. I also found it much more difficult to weight paint. Maya is very fickle about weight painting and likes it best when weight painting a hierarchy of joints that are parented directly to each other. I heard wire deformers are calculated by the program faster but opting for the mirror joints and mirror weight paint options seemed much more efficient.

The mouth I chose to bypass the hassle of rigs and opted for a Pocoyo, stop animation style of replaceable mouths. This is done using animated textures. The one catch with this tutorial, is I'm guessing due to program changes, the image sequence must be enabled before setting the set driven keys. The channel box of the frame extension much be left clicked and select delete expression in order to prevent the program from overriding the set driven keys. In theory, there is an attribute that has a list of your mouths. You save your head color maps labeled as a series of images that are imported as an image series. Using set driven keys, the mouth controller is linked to the correct frame extension (each number is the next frame within the image sequence).

Fun, Fun, Fun. Did the uv unwrapping in Z brush which saved a TON of time, then made up the color maps in Photoshop. Could have done it in Z brush but I prefer to have all the brushes, layers, opacity control etc. that comes with Photoshop. Plan on incorporating the mouth into the color maps. I will be testing that next. In addition, I also have to test out how the color maps hold up when I use blend shapes to create the controls for the different facial expressions.

This is most likely how I will be rendering the entire film. Switched over to real time rendering in viewport which will again, save me a lot of time. The shader is a combination of the color map connected to the ambient color node and a ramp shader that has only 3 or 4 values, some which have no interpolation, others which have spline, thus you see some hard edges and some soft edges. For the outline I used the toon outline with the mesh offset. I will most likely be using the outline for the characters only.

That was a lot of CG rambling, if you didn't catch any of that just look at the pretty pictures below.

This is the UV layout for the head. The program pretty much takes the 3d object and uses seams to flatten it out into a pattern exactly like ones used in sewing stuffed animals.