Converting rotation order from XYZ to XZY

OK, my math skills in this area are more than a bit lacking....

I believe the euler rotation order for SL is XYZ, correct? (When internally it converts to and from quaternion)

How can I convert that to XZY order?

I'm trying to *properly* convert SL euler rotation order to the default order used in .bvh files, which is XZY. I can't quite wrap my head around the math to convert between the two.

Any help appreciated!

pretty sure sl is ZYX, not XYZ

That is what I am not sure of...

If the internal conversion order is ZYX, then I would need to convert that to XZY.

I can't remember the order applied, but if you have a reason to want to swap the order (even aside from that) it's not too hard

vector fVecReorder( vector vVecIn ){
  return <vVecIn.x, vVecIn.z, vVecIn.y>;
}

or whatever works for you.
I think Lee is right though, essentially z is modified by x and y, and y is modified by x in that order, so it makes logical sense (not that SL is all about logic), but the above is easy to modify to that.

to test you could use Eulers to rotate the object in order, and compare it to the rot to make sure it matches (suggest ~30deg ?)

Void, I'm not trying to re-arrange the XYZ rotation values, that is all I do now. What I want to do is to recalculate their values such that if they are applied in a different order, yield the same result in a program that will apply them in a different order.

Rotating on the Z axis, and then the Y axis, then finally the X axis doesn't always yield the same orientation as rotating in a different order, given the same values for X, Y and Z... or so my limited understanding of this goes.

Googling for "convert euler rotation order zyx xzy" yields a ton of results.... much of which I don't grasp as well as I might have... say... 20 years ago

what I'm saying is that if you apply them in the correct order fro whatever your app the only thing that should change is how they're ordered... you get the same effective results... the axis values just change to represent the order of application.

and IIRC that SHOULD work. if not then using the inverse which would be the other logical choice, which could be gotten with rot to fwd might work

not really Void.

Put a book on the table face up, as if you were about to open it.
Rotate it 90 CCW, so that now the title of the book is closest to your left hand and the spine is facing you.
Now flip the book away from you so it is face down. Note how the book looks to you.

Now, lets do the exact same thing, but in the reverse order.
Put the book on table face up as if you were going to open it.
Flip the book away from you so it is now face down, spine still toward your left hand.
Now rotate it 90 CCW.

Notice that it isn't in the same orientation as the first time, because we have applied the rotations in a different order.

To get the same results on the second test, you would have to use different values.... and that is what I am trying to calculate. Given euler values X, Y and Z, applied in the order Z, Y, X, how do I calulate the values such that when applied in the order X, Z, Y will yeild the same orientation. Yick!

I believe you can change how the BVH orders it's Eulers by changing how it is setup in the hierarchy.

If you put a book on the table face up like you were going to read it, it's already on it's back, spine toward your left hand, isn't it?

Yes, and when you flip it end over end, as stated, it still is.... just upside down.

That was my first try.... however, apparently SL doesn't honor re-ordering the X, Y and Z in the BVH hierarchy. For example, I changed it from

CHANNELS 6 Xposition Yposition Zposition Xrotation Zrotation Yrotation

to

CHANNELS 6 Xposition Yposition Zposition Zrotation Yrotation Xrotation

and re-ordered my export to put the XYZ rotation values in that (ZYX) order, and SL borks it on import... It appears it ignores the stated order, and expects them in XZY order.

I know this involves converting to a matrix... and matrix transform, etc... as my MIT math genious buddy has told me.

When I start out with the book closed, backside down and frontside up, spine on left, and grab the book by the sides and turn it over, the back is now facing up. It's not on its back after it's flipped, it's on its front.

AHA! Yes.... I did goof the explanation... I should have said face down instead of "on its back" Oops. Corrected.

Thanks SuezanneC!

no i understand that the order of application matters, but if you trade the axis you should get the same result.

example

30x, 60y, 90z
lets assume for a sec SL applies x, y, then z. and bvh applies z, y, then x

if you relabel a SL degree rot, by swappin the x, and z values, and apply it in the bvh, you should get the same final rotation, because they are now being applide in the same order, just on differnt axis'

similarly if you do the same action of trading the axis' from the bvh, then you should get the same rotation within SL.

so <30x, 60y, 90z>SL becomes <90x, 60y, 30z> bvh
and <30x, 60y, 90z>bvh becomes <90x, 60y, 30z>SL

assuming I have the right order of application for both programs. but the idea should be right in the finish.

Void, I am not too proud to be proven wrong.... I'll give it a shot and see how it goes.

So your saying that although I will be exporting the X Y and Z values, in the order that is expected by the BVH format (XZY), I will actually be transposing values such that...

for X=30, Y=60, Z=90

and a BVH that expects them in X-Z-Y order

I will NOT be exporting them in the logical order of 30,90,60....

But instead, may be giving them in some other order, like 90,30,60 or some such.

Such that the original XYZ values are potentially operating on totally different XYZ axis?

I'll give it a shot... I'll feel really dumb if simply exporting them in traditional X Y Z order is the ticket.

My brain says that can't be right because if I think of a single value X of 90 getting applied to a different axis, and the other 2 are both 0.... ahhg... my brain hurts.

I'm pretty sure the refrence order is really all that counts for the result, not what the axis is... it does seem odd the completely replace one axis with anothers value. and I don't actually know the order of application for either, but it you're applying them values in the same order then the axis shouldn't actually matter as long as you complete the sequence for both. if it turns out I'm wrong, you have my sincerest groveling apology and and a free gibbs shot at the back of my head

pffft

Well you can cheat of course:

vector llRot2EulerYZX(rotation a){
    vector b = llRot2Euler(<a.y, a.z, a.x, a.s>);
    return <b.z, b.x, b.y>;
}

That should give you an XYZ Euler that you load in YZX order. Should be enough info that you can construct any type of Euler you want.

Something just feels right about that Strife... next time I have a chance to have "programmer hours" I'll test all this out. I have one other possible solution, basically displaying the object (avatar) inworld in the same orientation as Poser by applying the rotations one at a time by mutiplying a zero rotation by each axis in the order that Poser applies them (expanded, not tested at all, no clue if it would work)...

Given an input in degrees that will be exported to the .BVH

rotation rot = ZERO_ROTATION;
rot = rot * llEuler2Rot(<input.x,0,0> * DEG_TO_RAD);
rot = rot * llEuler2Rot(<0,0,input.z> * DEG_TO_RAD);
rot = rot * llEuler2Rot(<0,input.y,0> * DEG_TO_RAD);

(Apply rot to avatar hip.)

Ok, I have to thank all that helped with this. I did end up using the solution that I came up with. The reasoning is that I display the XYZ values, and I wanted them to match what you would see in Poser, so it is better that the inword display matches what Poser would show, rather than convert the rotation order from SL to Poser/BVH and have different values displayed inworld HUD vs. Poser.

Ended up using this:

input *= DEG_TO_RAD;
rotation hip_rot = llEuler2Rot(<input.x,0,0> * llEuler2Rot(<0,0,input.z> * llEuler2Rot(<0,input.y,0>;
(Rotate Avatar to hip_rot)

Which is probably just an expanded variation on what you stated Strife, but going in the other direction.

Ok, it turns out that using quaternions for conversion of rotation order appears to work quite well...

// Convert ZYX (SL Native) rotation order to XZY (BVH/Poser native)
vector ZYXtoXZY(vector v);
{
rotation r = llEuler2Rot(v * DEG_TO_RAD);
v = llRot2Euler(<r.x,r.z,r.y,r.s>;
return <v.x,v.z,v.y> * RAD_TO_DEG;
}

// Convert XZY (BVH/Poser native) rotation order to ZYX (SL Native)
vector XZYtoZYX(vector v);
{
rotation r = llEuler2Rot(<v.x,v.z,v.y> * DEG_TO_RAD);
return llRot2Euler(<r.x,r.z,r.y,r.s> * RAD_TO_DEG;
}

Thanks Strife... and if I boogered it up, let me know. Thanks.