Sunday, September 25, 2011

Dealing with Double Transforms

Double transforms are probably the single most frustrating thing to deal with when you're first learning rigging. What can be even more frustrating is when these issues pop up after it seems like you've got a perfectly working rig and you just want to clean it up in the outliner!
Fortunately, the issues are almost always in one of a couple of relatively simple categories and you get accustomed to dealing with them fairly quickly. This is a video talking about some of those basic scenarios and some ways to address them. Hopefully enough to help get you started in solving some of the more complex issues you may run into down the line.

Maya/Rigging: Dealing with Double Transforms from zeth willie on Vimeo.

Using the Point on Curve Info node

I always think this kind of stuff is pretty cool. . . a) this node is semi-secret/hidden and you'll feel pretty cool showing it to someone who's not aware of it (though don't be too smug. No one likes that asshole) b) you get to create some stuff using the command line, which again is pretty sweet and nerdy and c) the pointOnCurveInfo node is exactly the kind of node that riggers like. It just does what it's sposed to do with no extra fussing around or additional junk.
Anyways here's a video talking about how to access this node and some basic ways to use it (namely for sticking stuff onto a user-defined point on a curve).
A quick tip, which is in the video and which is a reiteration of info I've posted before. . .
Rather than using:
createNode pointOnCurveInfo -n "name";
which will give you node, but leave it hidden from view in the hypershade, I prefer:
shadingNode -asUtility pointOnCurveInfo -n "name";
which does basically the same thing, but flags the node as a "utility" and thus puts it under the Utility tab in the hypershade. Just thought I'd point that out again.

Maya/Rigging: Attaching objects to a curve (using pointOnCurveInfo node) from zeth willie on Vimeo.

Friday, September 02, 2011

Why so many groups?

Been asked by a few people (in my rigging class and elsewhere) about why there are so many groups in my rigs. So thought I'd post a quick video talking about some ways to use groups (kind of like nulls in After Effects) as part of the functionality of my rigs.

Maya - Using groups in your rigs from zeth willie on Vimeo.

Swapping out rotation orders under an animation

Not an everyday thing to use, but useful when something like this crops up. . . 
Rotation orders are always kind of important, but on certain animations it can be pretty necessary to manage them correctly (I'll try to do a separate post on rotation orders in general later).
I was just on a commercial recently where I was tasked with animating a couple of leaves fluttering into position. Somehow I got something sideways in one of the leaves and already had a fairly decent animation base down before I realized it. One leaf was correctly oriented in the rig to point in X and the other got perpendicular in Z. I built the entire rig for both as though they were pointing in X with the default rotate order (XYZ) and thus had two slightly different behaviors. I couldn't get a clean rotation down the axis of the leaf that was oriented in Z because the rotation order was incorrect (should have been ZYX, if I remember correctly). The general rule of thumb is that you usually want any channel that you'd like clean to be FIRST in the rotate order (though technically, that means it rotates last). Anyways, that's a fairly easy fix in the rig, just had to go back to my working version and change the rotate orders of the control structure elements, publish it back to the master version and done.
BUT, since I'd already animated a bunch of stuff, swapping the rotation orders under the published version of the rig would mess all the rotations up. Didn't want to have to match each keyframe by eye, but there seemed to be no numerical way to match stuff up. I was banging my head against the wall when I asked Brad Friedman, who's a really smart pipeline TD at Method and he told me unequivocally, "nope. Can't be done mathematically".  My next thought was to try to go to a key, orient constrain the object, delete the constraint, key it and repeat. The evil trick, though, is that this isn't even doable by hand (except to go through and key by eye), because even if you were to try and constrain then delete the constraint, then key the value, it would blow away any keys you previously had. So you can do that once, but not multiple times over the length of the animation. Ugh.

So I came up with a quick little script (with a python assist from Brendon, who's another smart pipeline TD there).
Basically the idea is this, you have a scene with your incorrect rotate orders already animated. Import your new rig with the correct rotation orders. Select the animated original, then the new rig, then run the script. It will find any keyframes for rotation and translation. For each keyframe, it will point and orient constrain the new rig to the old rig and store the translate and rotate values of the NEW rig (which are the numbers, at least rotation, that aren't derivable from the orig data) and then, once it's stored them all, go back and key those stored values at the correct frame for your new object. Finally, it will run an Euler filter on the lot of the new curves (I noticed some rotations can get a bit weird without it).
Not perfect but serviceable and fast. Which is good cuz it was my mess up in building the rig that started the whole problem!

So here's the script: (rt-click,save as)

To use this, drop it in your version/scripts folder (or wherever else you stash your python scripts) and then in Maya, select the original object, then the new rotation order rig and type:
import zbw_swapRotateOrder

Once you've imported the script, you just need the second line to run the function thereafter, I believe. (I can write the python scripts fairly simply, but using them in Maya still seems like a pain to me)