Change Local Rotation Axis And Preserve Transforms

[haikai]

This is a difficult problem to describe. Here's the scenario: I'm trying to rig a character model that has the arms halfway down, 45 degrees from the typical da Vinci pose that most people work with. I need the control object I've created for handling wrist animation to be aligned with the wrist joint for obvious reasons (a single wrist control that handles both moving the arm via IK and rotation of the forearm and wrist joints). How do I get the local rotation axis for this object to match that of the wrist joint, but still have zeroed out transforms in the channel box to easily return to the original pose?

One thing I tried that almost worked: I parented the wrist control object to a "dummy" group that was orient constrained to the wrist joint, and then froze the inherited transformation values introduced by being a child of the dummy group. This works as advertised giving me the rotation behavior I wanted with zeroed out transformations... BUT: perhaps I am missing something, but translation animation now gets recorded in local values so that a simple move in one axis actually shows up as a move on two or all three axes. This can be worked with, but is very unintuitive.

Any suggestions? Perhaps I am barking up the wrong tree and there is a simple solution that I'm not seeing.
-hai

[drblacksnake]

I guess that's main disadvantage of 45deg placed arms. Also I guess You won't be able to create same control for global translate and local rotate.
Well.. You can do two things - raise arms until they are 90deg and then create rig.
For quick re-assuming thad 45deg pose, You can collect attributes from all controls and put under single MELbutton. If You use Character node, then You may create default poses for both 45deg and 90deg.

[haikai]

that's actually a pretty good idea. for now, i've already completed the rig using the solution i've always relied on in the past (two separate controls for manipulating the wrist, one for rotation, the other for moving the arm ik), but i'll keep your suggestion in mind for the next time around. this problem has always been frustrating just because it seems like there should be a very simple solution to it (and maybe there still is), but workarounds come with the territory, i suppose.

[bastardloud]

Hi,

I was wondering if you might try following your previous steps but in a different order. First just position your
Ctrl.-Obj. where it needs to be then freeze the transForms. After that group it to itself and then rotate the group 45 degrees for the desired offset. After that don't freeze the transforms instead parent the group under either your local or global Ctrl.-Obj.

I don't quite understand your issue with Local and Global space since your going to have to put your Ctrl. Objs. under either a global Ctrl. Obj. or a Group Higher up in the Hierarchy.

Plz explain, curious to learn more? Will there be difficulty navigating animation curves?

Good Luck

[haikai]

QUOTE(BastardLoud @ 03/28/06, 07:32 AM) [snapback]232534[/snapback]
After that don't freeze the transforms instead parent the group under either your local or global Ctrl.-Obj.
I don't quite understand your issue with Local and Global space since your going to have to put your Ctrl. Objs. under either a global Ctrl. Obj. or a Group Higher up in the Hierarchy.

The only thing I have above the arm controls in the hierarchy is the main node used to move the entire rig around. I can certainly parent the new group under there, but we seem to have arrived back in the same place. It's true that parenting the control object to something else and relying on the parent for the offset will enable the correct orientation of the child control object with zeroed transforms, but translation animation of the child control object will still be recorded according to the parent's local space (which was offset to provide the correct rotation orientation). I'd like to have the child control object's translation animation to be consistent with that of the world coordinates. whew, this is giving me a headache!

I understand that animating a global control object above my arm control will throw things off anyway, but my main rig node is never really animated except to maybe offset finished animation. Until then, it would be nice if a simple move up in Y was recorded as such rather than as something moving in X and Y.

... but I may be misinterpreting your solution. If you have a small example file of a working solution then I would love to see it if you are willing to share. I'm sorry if I'm overlooking the solution that you are proposing. This could all very well be a result of something fundamentally wrong with my rigging theory.

-hai

[bastardloud]

Ok,

I have 2 solutions I think for your problem.

1: Position the Ctrl. Obj. freeze the transforms. Then go into component mode and select all the cv's for you Ctrl Obj. and rotate them manually. Going back to Obj. Mode you'll see the rotation values are untouched.

1. Position the Ctrl. Obj. freeze the transforms. Then open up the attribute editor and adjust the rotation axis values of the Ctrl. Obj. (attr. found on the translate node)So that the geo/curve/etc. is rotated with the desired offset.

Did this help?

[joojaa]

1 is computationaly less expensive if you counter rotate first then freeze and rotate back. Also it works on suff you cant manipulate, such as locators.

[haikai]

sorry for the late reply!

QUOTE(BastardLoud @ 04/01/06, 01:10 AM) [snapback]233006[/snapback]
1: Position the Ctrl. Obj. freeze the transforms. Then go into component mode and select all the cv's for you Ctrl Obj. and rotate them manually. Going back to Obj. Mode you'll see the rotation values are untouched.

if i'm following as intended there would still be a problem with this: i need the rotation axis to remain oriented in addition to having the values zeroed. rotating the cv's would get it to look like it was oriented, but the axis of rotation wouldn't have been offset with the adjustment of cv's... or maybe you mean something different.

QUOTE(BastardLoud @ 04/01/06, 01:10 AM) [snapback]233006[/snapback]
2. Position the Ctrl. Obj. freeze the transforms. Then open up the attribute editor and adjust the rotation axis values of the Ctrl. Obj. (attr. found on the translate node)So that the geo/curve/etc. is rotated with the desired offset.
Did this help?

i actually had tried playing with the rotation axis values before, but they don't seem to do what i'd like them to. it does indeed offset the control object without affecting the rotation values, but when i go to actually rotate the object, the gizmo/manipulator still is oriented to the world (no matter if i'm rotating according to global, local, or whatever).

i use mostly groups (with handles) and locators rather than curves/geometry (things with components) for my animation controls, but perhaps i'm missing something by doing so as suggested in your first solution? i personally find that seeing tons of fancy controls to be distracting, but perhaps there is a reason why professional riggers/animators seem to like them so much.

-hai