Rotation wierdness

[Simonrazer]

If you print out an objects rotation that is being rotated on update on the Z axis, you see that its Z rotation is also determined by the X and Y rotation, since they switch from 0 to pi or -pi if it turns 90/180/270 degrees. This is super annoying, for example is it way harder(if not impossible, haven't tried yet) to set an objects Z rotation to Time than setting it to its Y rotation. Would be supernice if you did something about that.

[Gedankenexper1ment]

This issue is very problematic. It seems Z rotation does not go from 3.14 to -3.14 like the other axes. 'Set rotation' and 'rotate object' work around this issue in some way, accurately updating the Z axis (3.14 = 180 degrees), however get rotation pulls different values. See attached .blend (the Suzanne is saying no to all bugs :smile:).

test (2).zip

[Defaultsound]

Getting the same issue as well it seems. http://forums.armory3d.org/t/return-axis-rotation-between-0-and-360/2788/3

[Bugsbane]

Yet another forum post that looks like it is probably related to this bug.

[N8n5h]

This is a know problem with euler angles and not really a problem of implementation I think, paraphrasing the answer: to perform a rotation with euler angles there is a conversion from quaternion to euler and back to quaternions, and the problem is that basically:

• there is two ways to represent a rotation with euler angles.
• Quaternions have the so-called double covering property: Two unit quaternions correspond to every rotation.

So when you convert back you get a rotation and maybe it's not the expected values for the angles, so for example inputting (0,0,92) may get converted to (-180,-180,88) in the case of Armory implementation. You can hack around this problem for a bit and obtain the desired rotation with one axis, but eventually it will show up again somewhere else anyway. I think the best thing is to try to avoid euler angles completely and just use quaternions.