Friday, September 02, 2011

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)

No comments:

Post a Comment