Matrix help: Trying for continuous Euler conversion

[eek]

I need a way to connect two transforms' rotations so that their local Euler values are continuous, but the two transforms will always have different Euler rotation orders.

Ok questions:

1.Do you want the two transforms when rotating to 'look' the same in the viewport or 'have' the same rotation values relative to there axis?

2. Do they have the same axis i.e Y points up etc? or just the rotation order difference?

Matrix multiplication, using inverse or decomposition is always going to return a transform in world space the key is the reference coordinate system you multiply it against.

E.g. A * inverse B will return the difference in world space like 10 + -20 = -10. That difference can be multiplied against any other coordinate space. I do stuff like what you showed in your last to last 'baked' image at work:

Get one transform relative to another, and transform it about the others transform over time, i.e relative transform constraint. It tends to yeild results like the same picture.

Why?

This is because a transform being relative to another will only return rotations of -180 - +180. Im not sure if this is due to internal quaternions reaching there hemispherical edge or something to do with matrices.

What you have to do is decompose the matrix and put it through its own 'euler' filter or so some heft math sin/cos stuff to do it on the fly. I'll have to have a think.

[PEN]

I'm guessing it is kind of both Eek, a transform matrix vector moving from one extreme to another takes the shortest root and doesn't wind up like an Euler. Same goes for the quat value as you already know.

I to am not sure of what the result will look like based on what you are telling us Dr Dardis. Can you provide scene grabs of the result just hand keyed so we know what you are after?

[theflash]

This is quite normal. (I don't know how XSI is solving). And the reason is mainly the rotation order. Using all the three methods you mentioned, I believe you will end up with pretty much the same results.

Since they have different rotation orders their calculation for each axis is going to be very different (between driver and driven. because there is no one-one axis mapping). So orient constraint will try to calculate the correct orientation of driven object by finding the right rotation value in XYZ order based on driver's YZX order rotation. Logically idea is to find values of x, y and z rotation which if multiplied in given order yields the right orietnation. Now due to nature of calculations (not really an expert in this yet) in euler angle when the values approach near 180, either in negative or positve direction, then the calculation flips the angles and hence the jump.

So for example,
Have two locators, constraint locator1 to locator2 (driver).
locator2= RO (YZX)
locator1= RO (XYZ)
rotate locator2 -91 in y-axis
and you will see that locator1 is 269.
So as soon as driver corsses -90 the driven obj flips. And the reason is the different rotation order.

But your poses are right. i.e. orientation of your driven object.

I dont have thorough understanding of the calculations so I cant completely visualize it in my head and describe the problem in detail. But I am giving you the clue.

Welcome to Maya! :)

[Buexe]

I suspect pursuing a matrix-based solution might yield results, but I am but a baby in that world.

I doubt that diving into matrices will yield your result in a simple manner. The thing with matrices ( not only in maya I believe) is that they store rotations actually as normalized vectors. These vectors are insensitive towards spins of your object, so a rotation of 10 degrees is the same as a rotation of 730 degrees ( 2x 360+10 ). So the resulting matrix will have the correct orientation in space, but the outputs you can see in the channel box ( or even in the graph editor like you showed) are different when the matrix is decomposed to show values that are more human-readable( Euler angles ).

[Dr Dardis]

Just the talented folk I was hoping to hear from, thanks for the replies guys! I new I just had to put the word "matrix" in my post and I would get a nibble from EEK at least ;)

The more I think about it and read your answers, the more I realize it is a more mathematical conversion (as suggested), and less matrix based solution that I may need.

I guess the way to reply would be to answer questions;

Ok questions:

1.Do you want the two transforms when rotating to 'look' the same in the viewport or 'have' the same rotation values relative to there axis?

2. Do they have the same axis i.e Y points up etc? or just the rotation order difference?



1. I want them to 'Have' the same rotation.
2. They are identical (i.e. y is up), only their rotation order is different.

What I am trying to accomplish is a twist system, with the added complexity being that I need the rotation in this twist system to be continuous. The main reason for this is games-relevant.

We animate and export animations to our in-game renderer at 30fps, but the renderer/console refreshes at 60hz (60fps). This is causing some schizophrenic glitches on characters (1 in particular) with long, stretchable, twistable, detachable tentacles (I know, don't ask ;) damn art directors!). The error is then multiplied and magnified when animation compression is brought to bear (or should that be bare?). This could be negated somewhat if each export joint was independent (i.e. not stacked in a dependent hierarchy), but that would cause unacceptable RAM usage as each joint would also need 3 translation floats exported as well.

Now, the control at the end of the detachable tentacle (lets call it the "DRIVER") drives the twist of the whole chain. It's rotation order is yzx, for the animators. Under the same parent as this control, I have another object "DRIVEN". It has to mimic "DRIVER" exactly, except that its dominant Euler axis is X (rot. order = xyz). It is this X axis that drives the twist of the chain. The export joints that follow this chain are "connected" rather than "constrained", to ensure that their local rotations are continuous.

Now, all this was fixed by just baking "DRIVEN" and applying the Euler filter prior to export. This ensured that rotation were continuous. This was a very inelegant solution, and didn't lend itself to iterative animation very well. Now we are in the post-mortem/ R&D phase, I thought I would try to address this.

Which brings me to the purpose of the post. How to convert continuous local rotation between objects with the same parent space and orientation, but differing rotation orders?

Am I barking up the wrong (and very, very tall) tree, as I fear i might be?

Thanks for the replies and thoughts guys!

Chris

[eek]

Just the talented folk I was hoping to hear from, thanks for the replies guys! I new I just had to put the word "matrix" in my post and I would get a nibble from EEK at least ;)

The more I think about it and read your answers, the more I realize it is a more mathematical conversion (as suggested), and less matrix based solution that I may need.

I guess the way to reply would be to answer questions;



1. I want them to 'Have' the same rotation.
2. They are identical (i.e. y is up), only their rotation order is different.

What I am trying to accomplish is a twist system, with the added complexity being that I need the rotation in this twist system to be continuous. The main reason for this is games-relevant.

We animate and export animations to our in-game renderer at 30fps, but the renderer/console refreshes at 60hz (60fps). This is causing some schizophrenic glitches on characters (1 in particular) with long, stretchable, twistable, detachable tentacles (I know, don't ask ;) damn art directors!). The error is then multiplied and magnified when animation compression is brought to bear (or should that be bare?). This could be negated somewhat if each export joint was independent (i.e. not stacked in a dependent hierarchy), but that would cause unacceptable RAM usage as each joint would also need 3 translation floats exported as well.

Now, the control at the end of the detachable tentacle (lets call it the "DRIVER") drives the twist of the whole chain. It's rotation order is yzx, for the animators. Under the same parent as this control, I have another object "DRIVEN". It has to mimic "DRIVER" exactly, except that its dominant Euler axis is X (rot. order = xyz). It is this X axis that drives the twist of the chain. The export joints that follow this chain are "connected" rather than "constrained", to ensure that their local rotations are continuous.

Now, all this was fixed by just baking "DRIVEN" and applying the Euler filter prior to export. This ensured that rotation were continuous. This was a very inelegant solution, and didn't lend itself to iterative animation very well. Now we are in the post-mortem/ R&D phase, I thought I would try to address this.

Which brings me to the purpose of the post. How to convert continuous local rotation between objects with the same parent space and orientation, but differing rotation orders?

Am I barking up the wrong (and very, very tall) tree, as I fear i might be?

Thanks for the replies and thoughts guys!

Chris

Ok first thanks :) Matrices are one of my favorite studies, and I get a kick out of teaching people and getting them to understand stuff. I was for instance explaining conic sections today :).

Secondly I'd ask about the jittering you were getting, was animation data exported as quaternions? over tick of the engine or as actual key data? And if so was your compression just compressing the data or doing some analytical process, removing 0 value keys etc?

Now you i'm assuming you couldnt just directly wire one rotation into another, oblivious of axis order? Nope thinking about this gimbal would creep up after the second order.

You could be clever and build a matrix transform im thinking, but this decomposing one matrix to spit out the correct order for the second would i think be hard. You'd have to:

a) get its transform relative to its parent
b) multiply this or transpose it by an offset transform or ordered transform
c) get this difference about its parent
d) multiple this by the new ordered axis transform.

Just trying this with using my hands as axis' im thinking this would be really tricky (not impossible) but I need to spend a chunk of time mulling over it.

Your basically decomposing an yzx into a xyz, you'd have to do some sin and cosine summation for the angles too. Neat challenge - have to get my thinking cap on!.


Also i think you'd have to go backards in getting the transform xzy.. to xyz

Ok you'd have to do this:

You'd have to decompose the first matrix, into the order of the second - and essentially find the 'weight' or 'strength' of each axis makes on the new order. Its a bit like fourier transform - infact thats one way of doing it.

Charles

[Xeash]

Hi Chris,
If I understand you correctly, you already implement this in XSI, right? if yes, tell us how you done it)
P.S. I think you are talking about the thing which really suprise me when I was trying to work with rotations in XSI after Maya.

[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.