Space Switching Madness
It seems that there are always unwritten, esoteric rules to Maya commands.
After my success with the space switching capabilities on the hands, I decided to add synchronizing scripts to the feet, tail and head, so when switching to isolation modes in those, they wouldn't jump. Or in the case of the feet, going from complete isolation to moving with the body.
Now, the isolation mechanism is similar, but sufficiently different on each of these, that I had some difficulty with every single one. That's because "xform -q -ws -a -t " doesn't actually give you the value you think you should be getting. If you read the docs, and just about everything out there on the command, you should be getting a full, world value for the location of the object, regardless of what's going on in the hierarchy above that object.
No dice. This is a horribly behaved command when, it turns out, the objects in the hierarchy above the one you seek a value on, have their transforms zeroed out. Especially if the object you're trying to get the information on also has the transforms zeroed.
But there's more. If the object you're trying to get information on is not zeroed, it won't work right either when you try to put the xform you were caching, back onto the the object so it doesn't move when you throw the switch.
Like everything else, things get easy once you know what you're doing. It took hours of detective work to figure out what was different between the head and the feet and the arms. Turned out, it was having a zeroed out parent. I arrived at this conclusion after trying every "xform" flag permutation. Absolutely nothing other than "-rp" would return a reasonable value. And "-rp" is useless if you want to transform the whole object. So I manually cut and pasted the values derived, and found the values were relative to the parent object's zeroed out transforms. Even though I demanded "world space" values with the "-ws" flag. Go figure.
So after hours of noodling with this, I completely reset the parent object to no offsets. The value in the translation box would be the exact ones that would come up on a "-rp" query.
And what do you know? With a real world value for the parent object, suddenly the script worked the way it was supposed to. The transforms were read, cached, and dumped back into the head, and the head didn't jump when the isolation mode changed. Amazing. Hopefully things will go smoother with my last two isolation controls tomorrow, on the clavicle.
It took awhile to find the pattern that had made things (IMO, unnecessarily) difficult, and turned each attempt at a self compensating space switching control into a cloak and dagger, sleuthing ordeal. And I don't think I've got all the answers. The clavicle controls are nested deep in a complex hierarchy, and I'm expecting to run into additional "gotchas" that may require some complicated vector math to solve. Or maybe the rigging gods will smile kindly on me, and things will work predictably instead of idiosyncratically.
The most amazing thing about this was that not one person I talked to on the Internet knew this. Usually you use "xform" for moving stuff like particles around a scene, or relating objects to other objects at the same hierarchy level, I suppose. At least, based on the tutes and books I have, that seems to be the case. It appears that I'm using this command to do something for which it was not intended.
But there's really good news. In getting this to work properly now, I've eliminated the "autokey" problem entirely. I no longer get keys arbitrarily added when scrubbing or paging frame to frame. I've also eliminated delays that occurred with the prior scripts which used locators and constraints to synchronize the elements. The "attribute" change is no longer detected at unwanted times, and objects no longer select and deselect themselves.
I'll have to ask some riggers if running all these scriptJobs has some drawback I don't know about. I'm sure it's wasting cycle time, but I haven't detected an overhead hit with the increased number of scripts. I've also combined them all into one "uber script" so I can easily change the object names when Maya adds the "namespace" prefix to everything when referencing. It's all good so far.
So now, I have a head isolation control that not only compensates for rotation, but if I translate the head for some reason, it still works. The feet work stunningly well, and I can see using this a lot more than I thought I would, especially for the walk I have in mind for KrazyCat, where he does a lot of swiveling with his foot out. In playing with the hands, I've found that the space switching is useful for something I hadn't anticipated: smoothing out bumps in arcs that occur from higher hierarchical movement. I can go to world space for a few frames, then switch to hierarchical mode, and now I have a compensated arc that works beautifully. I wish I had this tool on Tripping the Rift. I don't know how the tail is going to work yet, but I found that on the turnaround test, a little isolation at the beginning of the turn really alleviated the need to manually counteranimate (well, it was counteranimating itself really). So far, I'm really pleased with the way this is working.
Speaking of the tail, I'm going to have to re-do the architecture on it. More bones and probably a slightly different hierarchy.
Scripts
leftHandSwitch
rightHandSwitch - both of these are the finished space switching scripts
HandSelect - This selects both the hand control and the rotate x control I added to eliminate gimbal lock.
handSwitchOn - This was the script I used to lock out channels so they wouldn't automatically add undesired keys. However, now it's no longer needed.
lFootSync
rFootSync - These are the scripts that stop the feet from jumping when I switch from world space to body space.
tailSync - The script that stops the tail from jumping when switching from hierarchical to isolated modes.
headSync - The script that stops the head from jumping when switching from hierarchical rotation to isolated rotation.
Planned improvements:
I need to clean up the scripts to eliminate all the commented out features that are no longer used or needed, and delete scripts that aren't being used anymore, as well as their related, commented out, scriptJobs.
After my success with the space switching capabilities on the hands, I decided to add synchronizing scripts to the feet, tail and head, so when switching to isolation modes in those, they wouldn't jump. Or in the case of the feet, going from complete isolation to moving with the body.
Now, the isolation mechanism is similar, but sufficiently different on each of these, that I had some difficulty with every single one. That's because "xform -q -ws -a -t " doesn't actually give you the value you think you should be getting. If you read the docs, and just about everything out there on the command, you should be getting a full, world value for the location of the object, regardless of what's going on in the hierarchy above that object.
No dice. This is a horribly behaved command when, it turns out, the objects in the hierarchy above the one you seek a value on, have their transforms zeroed out. Especially if the object you're trying to get the information on also has the transforms zeroed.
But there's more. If the object you're trying to get information on is not zeroed, it won't work right either when you try to put the xform you were caching, back onto the the object so it doesn't move when you throw the switch.
Like everything else, things get easy once you know what you're doing. It took hours of detective work to figure out what was different between the head and the feet and the arms. Turned out, it was having a zeroed out parent. I arrived at this conclusion after trying every "xform" flag permutation. Absolutely nothing other than "-rp" would return a reasonable value. And "-rp" is useless if you want to transform the whole object. So I manually cut and pasted the values derived, and found the values were relative to the parent object's zeroed out transforms. Even though I demanded "world space" values with the "-ws" flag. Go figure.
So after hours of noodling with this, I completely reset the parent object to no offsets. The value in the translation box would be the exact ones that would come up on a "-rp" query.
And what do you know? With a real world value for the parent object, suddenly the script worked the way it was supposed to. The transforms were read, cached, and dumped back into the head, and the head didn't jump when the isolation mode changed. Amazing. Hopefully things will go smoother with my last two isolation controls tomorrow, on the clavicle.
It took awhile to find the pattern that had made things (IMO, unnecessarily) difficult, and turned each attempt at a self compensating space switching control into a cloak and dagger, sleuthing ordeal. And I don't think I've got all the answers. The clavicle controls are nested deep in a complex hierarchy, and I'm expecting to run into additional "gotchas" that may require some complicated vector math to solve. Or maybe the rigging gods will smile kindly on me, and things will work predictably instead of idiosyncratically.
The most amazing thing about this was that not one person I talked to on the Internet knew this. Usually you use "xform" for moving stuff like particles around a scene, or relating objects to other objects at the same hierarchy level, I suppose. At least, based on the tutes and books I have, that seems to be the case. It appears that I'm using this command to do something for which it was not intended.
But there's really good news. In getting this to work properly now, I've eliminated the "autokey" problem entirely. I no longer get keys arbitrarily added when scrubbing or paging frame to frame. I've also eliminated delays that occurred with the prior scripts which used locators and constraints to synchronize the elements. The "attribute" change is no longer detected at unwanted times, and objects no longer select and deselect themselves.
I'll have to ask some riggers if running all these scriptJobs has some drawback I don't know about. I'm sure it's wasting cycle time, but I haven't detected an overhead hit with the increased number of scripts. I've also combined them all into one "uber script" so I can easily change the object names when Maya adds the "namespace" prefix to everything when referencing. It's all good so far.
So now, I have a head isolation control that not only compensates for rotation, but if I translate the head for some reason, it still works. The feet work stunningly well, and I can see using this a lot more than I thought I would, especially for the walk I have in mind for KrazyCat, where he does a lot of swiveling with his foot out. In playing with the hands, I've found that the space switching is useful for something I hadn't anticipated: smoothing out bumps in arcs that occur from higher hierarchical movement. I can go to world space for a few frames, then switch to hierarchical mode, and now I have a compensated arc that works beautifully. I wish I had this tool on Tripping the Rift. I don't know how the tail is going to work yet, but I found that on the turnaround test, a little isolation at the beginning of the turn really alleviated the need to manually counteranimate (well, it was counteranimating itself really). So far, I'm really pleased with the way this is working.
Speaking of the tail, I'm going to have to re-do the architecture on it. More bones and probably a slightly different hierarchy.
Scripts
leftHandSwitch
rightHandSwitch - both of these are the finished space switching scripts
HandSelect - This selects both the hand control and the rotate x control I added to eliminate gimbal lock.
handSwitchOn - This was the script I used to lock out channels so they wouldn't automatically add undesired keys. However, now it's no longer needed.
lFootSync
rFootSync - These are the scripts that stop the feet from jumping when I switch from world space to body space.
tailSync - The script that stops the tail from jumping when switching from hierarchical to isolated modes.
headSync - The script that stops the head from jumping when switching from hierarchical rotation to isolated rotation.
Planned improvements:
I need to clean up the scripts to eliminate all the commented out features that are no longer used or needed, and delete scripts that aren't being used anymore, as well as their related, commented out, scriptJobs.
posted by Stephen Greenberg at 9:35 PM
1 Comments:
I've been working on a space switching system myself, and am at the point that I can have the control object switch spaces without moving in space. My issue comes with the keying of said attribute. My whole process of doing the switch may be wrong, and causing my issue. But if you move the keyframe for the space switch on your hand control, let's say, does everything else update accordingly? Does it still play through smoothly? If so, could you possibly give any more description about how your switch is actually working? I'd really appreciate it.
Post a Comment
<< Home