jsOrientJoint wierdness

[seasterling]

I got into this by digging around in the jsOrientJoint script. Thought about adding a control to the script to manually position the up vector. Anyway, after digging some more I'm still a bit confused, but needed to edit my original post. If anyone can help me out with this, tia.

[dwalden74]

what is the -os flag in rotate -r -os

"object space". It's in the docs under "rotate".

I hear folks say to try to avoid having more than one translate value on a joint be non zero

If this is the case then you preceding joint probably won't be aligned correctly with the current joint (this is why some use joint -e -oj xyz, for example). This can cause rotation anomalies.

:beer:
David

[seasterling]

"object space". It's in the docs under "rotate".

duh! thanks David, sometimes my brain is so dumb.

If this is the case then you preceding joint probably won't be aligned correctly with the current joint

Sometimes you don't want them aligned, ie root to hip. I was just curious. You can make it happen by placing the joint with the JointOrient attr and translating along that axis. Just didn't know if it was something really worth worrying about.

[dwalden74]

Sometimes you don't want them aligned, ie root to hip

Yes, this is obvious. But many places you do want this to be aligned correctly, and when people talk about this I think they are referring to these other cases (and hip->leg or spine->clavicle).

You can make it happen by placing the joint with the JointOrient attr and translating along that axis

Don't understand this one. Could you explain a little better?

:beer:
David

[seasterling]

You can place a joint's child by rotating that joint's JointOrient attr. I don't normally do it this way, I've just been screwing around trying to understand exactly how Maya's joints work.

Normally to fix something like this I would feeze transforms to zero out rotations, align the root joint down the bone to the hip, orient the hip, then pull the value out of the JointOrient attr and reorient the root's with rotate -r -os . . . This keeps the hip from picking up the extra translate. Although, now I'm back to my original post about the Rotate Axis being non zero :)

[dwalden74]

You can place a joint's child by rotating that joint's JointOrient attr

ok, I think see what you mean now.

now I'm back to my original post about the Rotate Axis being non zero

A joint´s attributes are inherited from the transform node. From my understanding the Rotate Axis is simply an extra "rotation offset" applied to any transform node before the rotation is calculated. But the joint node already has this offset, in the jointOrient attribute, so I don´t think there´s really much reason to use Rotate Axis. I guess in theory it shouldn't really cause a problem if U modifiy it, but why can´t you use the jointOrient attr instead???

:beer:
David

[seasterling]

A joint´s attributes are inherited from the transform node. From my understanding the Rotate Axis is simply an extra "rotation offset" applied to any transform node before the rotation is calculated.

The RotateAxis attr rotates the bone relative to the LRA of the joint, so yes I guess it is an offset applied before the rotation.

But the joint node already has this offset, in the jointOrient attribute, so I don´t think there´s really much reason to use Rotate Axis. I guess in theory it shouldn't really cause a problem if U modifiy it, but why can´t you use the jointOrient attr instead???

No, I don't think so (if I follow you) because the jointOrient attr rotates the LRA of the joint in God knows what space. That is part of what I am trying to figure out. If you use the JointOrient attr your child joint will pick up a translate value in another axis. Using rotate -r -os . . . prevents this from happening.

Also, entering the same values in the Rotate Axis or JointOrient attr directly that Maya enters when you run either the rotate -r -os . . . or the
joint -e -oj . . . command will not produce the same results. I don't know if Maya does something else under the hood, or if the different results are the product of Maya editing these attrs in a different space.

So I guess now my questions are:
What does the jointOrient attr rotate the LRA relative to? (If you mess around with a joint's orientation and the jointOrient attr you'll see sometimes it appears to be in ws and sometimes in local space)

Why the commands produce different results than entering the values directly?

Why do I torture myself like this?

[seasterling]

Also, which of the joint's attributes is the line $pos = `xform -q -ws -rp $joint`; from the jsOrientJoint script querying?

[dwalden74]

hey hey, one thing at a time here... :p

jointOrient attr rotates the LRA of the joint in God knows what spac

jointOrient (the "Joint Orient" attr) rotates the entire joint orientation, not only the LRA (if you rotate LRA alone in component mode you see the joint orient and rotate axis compensating each other).


If you use the JointOrient attr your child joint will pick up a translate value in another axis

No..or maybe I'm not understanding you entirely. If you modify only the Joint Orient attr the child joint's attr do NOT change (I'm testing all of this as I write to be sure...)

rotate -r -os

This is just the rotation command. If you execute it with a joint selected it modifies the joint's rotation attrs.

$pos = `xform -q -ws -rp $joint`

This does not query a joint's attr. It queries the world space position of any transform node (luckily with joints it will NOT return zero if the transforms are frozen, like it does with other transform nodes). You can do the same thing with `joint -q -position`.


What does the jointOrient attr rotate the LRA relative to?

It reorients the joint and is relative the its parent joint's orientation.

Why the commands produce different results than entering the values directly?

`joint -e -oj` changes more than just the joint orient attr. Be careful about this and don't let it drive you bonkers :surprised

You should read thoroughly the docs on the "joint" command and "joint" node, and therefore also read through the "transform" node docs as well... I'm gonna' do it again this weekend!

:beer:
David

[seasterling]

If you modify only the Joint Orient attr the child joint's attr do NOT change

Their translates will, however if you reorient the parent with rotate -r -os or with the JointOrient attr + the Rotate Axis attr to compensate you can keep the translates at zero. So, why does Maya "remember" the parents LRA orientation with the latter?



What does the jointOrient attr rotate the LRA relative to?

It reorients the joint and is relative the its parent joint's orientation.

Try this. Create a single joint with orientation to none. Scrub the JointOrient attr values. They all rotate relative to world space. Now, enter 45 in the JointOrientY attr. Now scrub. Y and Z are still rotating in world space, but X is now rotating in local space! And I'm confused. :argh:

BTW, thanks for you time on this David.

[dwalden74]

Their translates will, however if you reorient the parent with rotate -r -os

I´m not finding this. Are you executing the `rotate -r -os` command with the LRA selected or the joint selected? Actually, this doesn´t even matter because in neither case do the translate values of the child joint change. Could you explain the steps you are doing to produce this effect?

Now, enter 45 in the JointOrientY attr. Now scrub. Y and Z are still rotating in world space, but X is now rotating in local space

hehe! Interesting... Apparently Joint Orient has a default rotation order of xyz. You can see what happens more clearly if you simply rotate a joint in Gimbal mode, and experiment with different Rotation Order values. You see that the same xyz rotation values can actually produce different world space orientations (this causes gimbal flipping mayhem in animation).... With a Rotation Order of "xyz" (the default value), you can change the Y and Z, and X will still be rotation "locally", but Y and Z will just be spinning in a seemingly "random" way. In "YZX" mode, the Y will be "correct" but X and Z will now be spinning wildly.... All this just has to do with the order in which Maya is evaluating the rotations. Unfortunately there seems to be no way to change the rotation order of the Joint Orient attr, which is in default xyz mode, but I´ll double check the docs just to be sure. Anyway, I think the best way to understand this (and it is indeed important) is just by playing around with different values and observing the results (and trying to make some logical conclusions based on what you see).


Create a single joint with orientation to none. Scrub the JointOrient attr values. They all rotate relative to world space

Just to make sure you understand this, if you scrub values individually (and reset them to zero when you finished scrubbing), yes the rotations will be in world space (assuming your rotations are set to zero and its not parented). This is because you are changing the values separately and not relative to each other. You only see clearly the "strange" results when you´re rotating 2-3 values together. Again Maya uses a rotation order to determine the order in which the 3 rotation attributes are evaluated, and "XYZ" will not evaluate the same as "ZYX". In XYZ mode, Z is evaluated first is not affected by the other roations, then Y is evaluated (affected by the Z), then X is evaluated (affected by both Z and Y). This is why, in this case, X will always rotate along the local x-axis, and Z will rotate globally.

Anyway, I hope we´re making progress here. In orienting joints, I don´t pay much attention to the "extra" Rotate Axis attr (BTW every transform node has this attr). I find everything can be done with Joint Orient. And all these attr values will be relative to the parent joint or to the world when the joint has no parent.

BTW, thanks for you time on this.

No problem. I enjoy talking about this stuff and also learn myself in the process. If you´re still not clear on things, or have examples that you can´t really explain, let me know and we can discuss further. I´m a bit sad no one else is contributing to this thread ´cause I´m sure there are about a million Maya users out there who don´t understand this stuff very well. I guess Jason is too busy working, otherwise he´d have some interesting things to say...

:beer:
David

[seasterling]

I´m not finding this. . . . Could you explain the steps you are doing to produce this effect?

Lay down a joint in the front view, then a second one so they are not aligned with a world axis. XYZ joint orientation is fine. Your child joint will only have a translate value in X. Now use rotate -r -os or swap out the jointOrient attr values with the Rotate Axis attr values to get the parent joint's LRA back in line with the world. Your child joint still only has a translate value in X! Undo and try to reoreint the parent joint with joint -e -oj none. Now your child joint has picked up a value in Y. So, with the first method of reorienting the parent's LRA, why is the child not picking up the value in its Y translate? Are the child joint's translates not actually relative to its parent's LRA?

Unfortunately there seems to be no way to change the rotation order of the Joint Orient attr, which is in default xyz mode

Aha! I was suspicious about this. I tried changing the rotation order of the joint assuming that it controlled the jointOrient attr as well. Guess not. Thanks! That explains a lot.

I guess Jason is too busy working

Yeah, I thought I might be able to get his attention with the subject of the thread. Figured if anybody on the boards knew this stuff he would. Actually, I really did get into all this trying to figure out how he placed the locator in the jsOrientJoint script to control the up vector. I'm trying to learn Mel. Need more hours in the day.

Thanks again for your help. And yeah, I think we're making progress.

:airguitar

[dwalden74]

Now use rotate -r -os or swap out the jointOrient attr values with the Rotate Axis attr values to get the parent joint's LRA back in line with the world. Your child joint still only has a translate value in X!

Yes because the parent is still "rotated" with its X pointing toward the child (result of modifying the Rotate Axis). The Rotate Axis rotates the joint in space although has no effect on the LRA.
Therefore if the child moves in its parent´s local space (the normal behavior in a hierarchy of transform nodes), the child will still only have a translate X value, and when you modifiy this, the joint will move along the vector described by parent->child (ie, the same as if the parent is oriented toward the child joint). The parent´s LRA is unaffected however, and will still rotate in global space (unlike if you had oriented the joint with `joint -e oj`).

I still don´t understand how you´re using `rotate -r -os`command. This is only a rotate command, and will work on anything that is "rotatable", ie transform nodes, LRA´s, CV´s, whatever. `joint -e -oj` is an entirely different command.


Undo and try to reoreint the parent joint with joint -e -oj none. Now your child joint has picked up a value in Y

Yes, now neither joint is oriented/rotated toward the other; both are oriented to the world, and the translate of the child is relative to the parent, and the translate of the parent is relative to global space (like you would expect with a simple hierarchy of transform nodes). The parent in this case is NOT rotated toward the child as in the previous case, although it does "look like" it`s rotated in the same way in the viewport. Both joints will rotate "globally" (both LRA´s are oriented to the world). BTW, you can also do this by simply unparenting the joints and resetting all rotate attrs etc to zero and reparenting.

... I think I´m using way too many words to describe these things. I hope I´m not making it sound overcomplicated....

:beer:
David

[seasterling]

Got it now. :applause:
What had me confused was the jointOrient attr always being in xyz rotation order. It also finally sunk in that the jointOrient attr is orienting the joint AND the LRAs, so when I reoriented the LRA in component mode I wasn't reorienting the actual orientation of the joint.

If you change the LRAs orientation on a regular transform node, the orientation of the object changes with it, however you will still always rotate in world space regardless of the LRAs orientation.

I guess this is what the jointOrient attr does. It allows a joint to rotate relative to its LRA. I'm still not real clear on what the jointOrient attr is doing though. Does it just create an offset between what we see as the joint rotating relative to its LRA and the joint actually rotating in world space?

Also, why do local transform handles align all funky sometimes?

Now for the really big one. :airguitar
Maya's rotation orders seem backwards. I mean XYZ actually evaluates Z, then Y, then X, correct? When the rotation order is XYZ and you rotate in Y, Z is not affected because it has already been evaluated, correct? If so, what's up with that?

[dwalden74]

It also finally sunk in that the jointOrient attr is orienting the joint AND the LRAs

yes, kind of...I think changing the joint orient means changing the LRA, however when you rotate the LRA in component mode, you are actually changing the orientation of the joint, however the Rotate Axis automatically compensates for this change by rotating the joint in the opposite direction (opposite to the joint orient values, that is)...


If you change the LRAs orientation on a regular transform node, the orientation of the object changes with it, however you will still always rotate in world space regardless of the LRAs orientation.

I don't think so. The object will always rotate according to the orientation of the LRA (sometimes the LRA is aligned to the world, sometimes its oriented to the next joint etc...)


I guess this is what the jointOrient attr does. It allows a joint to rotate relative to its LRA.

But the joint will always rotate according to its LRA, regardless of joint orient values.

I'm still not real clear on what the jointOrient attr is doing though

I think it's simply rotating the LRA, which implies that it rotates or "orients" the joint. The "bone" that we see in the viewport is simply an indication of the direction of the joint (Joint Orient + Rotate Axis).

Does it just create an offset between what we see as the joint rotating relative to its LRA and the joint actually rotating in world space

Again, the joint will always rotate according to the orientation of the LRA. There is no "offset" between the rotation-axis of the joint and the LRA orientation.

Also, why do local transform handles align all funky sometimes?

Don't understand this one. Could you explain a little better?

Maya's rotation orders seem backwards

Yeah, I know what you mean. I don't have an explanation for this one. I think it just has to do with the way Maya defines rotation order and how normal humans do, although I could be wrong....

:beer:
David

[seasterling]

I don't think so. The object will always rotate according to the orientation of the LRA (sometimes the LRA is aligned to the world, sometimes its oriented to the next joint etc...)

I'm talking about on another type of object. Create a poly cube, change its LRA in component mode, the cube will always rotate in world space regardless of the LRA.

I was guessing that the additional jointOrient attr on a joint node is what allows it to rotate relative to its LRA. I never realized that other object don't behave this way. Or am I missing something?

Don't understand this one. Could you explain a little better?

Create 2 joints in default xyz orientation. Grab the move tool and put it into local mode. Check the orientation of the child joint's move handle relative to the parents LRA. It is what you would expect. Now change the parent's orientation to yzx and check the child's move handle in local mode. Although they work correctly, the handles orientation is all funky.

[dwalden74]

It is what you would expect. Now change the parent's orientation to yzx and check the child's move handle in local mode. Although they work correctly, the handles orientation is all funky.

For me it looks fine. I assume you mean "...change the the parent's rotation order" and not "...orientation". The child should stay in the same local space regardless of the rotation order (of course, the parent's orientation can change, but this shouldn't affect the child's local space).

:beer:
David

[rebo]

Does anyone have a way of rotating the LRAs numerically without using rotate in component mode and dragging.

I guess it can be done with some sort of script that updates the rotateaxis and orientjoint components.

[seasterling]

For me it looks fine. I assume you mean "...change the the parent's rotation order" and not "...orientation".

No, change the parent joint's orientation with joint -e -oj yzx and then check out the child's move handle in local mode.


rebo:
Yeah, just use the rotate command in component mode.

rotate -r -os x y z (x,y and z are your values for each axis of course)

[dwalden74]

No, change the parent joint's orientation with joint -e -oj yzx and then check out the child's move handle in local mode.

Hey, hey, wait a minute here- I told you before this command is doing more than meets the eye. The docs will explain (most of) it (although last time I checked there didn't seem to be anything written about modifying the child's orientation). BTW, this command has nothing to do with rotation order (you probably knew this though).

:bounce:
David

[CGTalk Moderation]

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.