Cummulative node rotation bug

[robmar]

There is something strange going on with rotating rotated nodes, which may well be the gimbal lock problem.

Video trying to explain gimbal lock, which still doesn´t seem to explain "why" it occurs (or does it?):- http://www.ogre3d.org/tikiwiki/-Gimbal+Lock

I´ll post an update to this, or maybe it should be deleted as it seems its not a bug.

Steps to reproduce this issue:-

1. Create a cube node.
2. Set rotation to 0, -90, 0.
3. Now rotate 45 degrees on the X axis SetRotation( 45, -90, 0) - object rotates correctly.
4. Now rotate 45 degrees on the Y axis SetRotation( 0, -90 + 45, 0) - object rotates correctly.
5. Now rotate 45 degrees on the Z axis SetRotation( 0, -90, 45) - object does NOT rotate correctly, instead it rotates backwards on the X axis! I.e. it makes the same axis rotation as step 3 but reversed!

Only rotation of the Z axis works as expected with subsequent additive rotations.
Calling UpdateAbsolutePosition does not resolve this.

This must be a known issue with workaround, but couldn´t fine it.

[CuteAlien]

I'm not really getting your descriptions. First problem is that one of your rotation vectors has 4 numbers. The next is that you write you rotate 45 degrees, but you set 2 rotation directions at once so what you mean is you rotate 45 degrees in one direction plus another -90° in y at the same time?

But sounds like you might run into gimbal lock, google that please (in short - you can't just continuosly rotate with euler angles or you will lose one dimension sooner or later, if you need that it's usually easier working with quaternions).

[robmar]

You mean the line SetRotation( 0, -90 + 45, 0)? Its the same as (0, -45, 0). I just wrote it that way to show the cummulative (additive) rotation, as the issue is about additive rotations to nodes that have a "base" rotation to set their meshes upright. On the web there are many readily available models but many have rotations that need to be corrected before use in games.

What I´ve found is that if a node has a base rotation applied, further rotations don´t add correctly.

Logically and mathematically its quite simple. Rotating a node -90 on the X-axis, rotates the Z-axis to the vertical position, hence from that point, to spin the object, which would use the Y-axis of an unrotated object, the object´s Z is used, as the node has been rotated.

I mean thats logical right? :S

I´ll google the gimbal lock...

[robmar]

I think my brain is completely stuck, I don´t understand why a node, when rotated -90 on the x-axis, can then not be rotated 90 degrees to the right, on any axis to spin it! Its like the -90 on the x just stops any other rotation over the floor from working, but why?

I took a look at quaternions, set two of them with the node rotation, and the desired rotation, then added them, also tried multiplication, but I get a -57 degree rotation on the x.axis, given the node rotation quaternion set to -1,0,0 and the desired rotation to apply being 0,1,0, w not set... the w (weight) value, should that be the vector length of the rotations? So 90 degrees would be what w value?

Really frustrating not understanding when this should be simple...

[robmar]

Oh no, I´ve been chasing my tail!

So the xyz rotation value for an object represent the rotation in the world coordinates, but once a node is rotated on one axis, the 2 other axis values are still in the same world space, i.e. not rotated, right? Hence the possibility of gimble lock.

Is that right?

[robmar]

No but thats not it either, I tested with a node rotated 0,0,-90, and any value set on the Y-axis then causes a rotation on its X-axis!

What the heck is going on?!

[mongoose7]

There are two principles.

1. The rotations are applied in the order Z, X, Y.
2. The axes do *not* follow the rotation.

A corollary worth stating is
3. You're going to get yourself into trouble whenever the X or Y rotation is 90 degrees.

BTW There is no bug, so you can stop spamming the forums.

[robmar]

Anyone know if this applies to Irrlicht´s node rotation code?

Gimbal Lock:

As rotations in the Euler representation are done with respect to the global axis, a rotation in one axis could 'override' a rotation in another, making you lose a degree of freedom. This is gimbal lock.

Say, if the rotation in the Y axis rotates a vector (parallel to the x axis) so that the vector is parallel to the z axis. Then, any rotations in the z axis would have no effect on the vector.

[CuteAlien]

This applies to _any_ code using Euler angles. And yes - you're not the first person getting a headache when learning about this, every 3D programmers runs into it sooner and later and starts realizing life is hard ;-) (the next shock is usually that those quaternions everyone recommends to use instead are some contruct involving 4 dimensions and are an extension to complex numbers, don't worry about it too much - just find out how to use them and postpone understandanding them to another life).

[robmar]

Yes now I see the wisdom in what you write, and ouch, my head hurts! Quaternion x,y,z is the rotation vector, and w is the weight, or magnitude, 4 dimensions.

I guess if this topic helps others newbees it will have been worthwhile.

So would this the solution:-

1. Use a quaternion to represent the node´s current rotation.

2. Generate a temporary quaternion for the change from the current orientation to the new orientation.

3. Multiply the temporary quaternion by the original quaternion. This results in a new orientation that combines both rotations.

4. Extract the Euler angles and setposition.

[mongoose7]

I believe so.