Rotation ist not behaving as expected


I’m trying to write a CAD-Software with JME for he Company i’m working at.

The complete geometric data is stored outside of JME in an database. JME ist only used to visualize the current state of the database. Every geometrical object has identifiers to store the orientation of the objects e.g.

angleX=90; angleY=0; angleZ=90;

when i want to rotate an object i just add something to the angles, e.g. angleX = angleX+5.

Then i create the graphics with jme and use node.rotate((float)Math.toRadians(box.angleX),(float)Math.toRadians(box.angleY),(float)Math.toRadians(box.angleZ));

for the rotation. The problem is that the result isn’t always what i expected.

E.g. when Z is 0 or 180, then everything works fine. But when Z is 90 or 270 then every change oft the x or y value results in a rotation of the object around the y-axis.

I would expect that the rotation axes always stay the same, but they are changing depending on the values the different axes have. Can please sombody explain to me what is going wrong here?

It’s hard to know without seeing reproducible code. Can you show any?

Gimbal lock, I suppose: Euler (gimbal lock) Explained - YouTube

This is why we use Quaternions instead of Euler Angles for rotation because they don’t suffer from this limitation.

Take the original angles and turn them into a Quaternion (Quaternion.fromAngles()). For relative rotations then take another Q. which describes the desired rotational offset, and then multiply them together in the right order.

This might help you: 3-D Rotation :: jMonkeyEngine Docs

Or simply use the Spatial.rotate(float xAngle, float yAngle, float zAngle) method which does exactly that.
Oh you’re already using that… It’s relative. Try using the value 5 instead of “currentValue + 5”.

1 Like

It sounds like from your description you have problems with Euler angles. Because of the way you are handling it, you are likely to have gimbal lock problems. There are ways to fix this while still maintaining your Euler angles representation, but it gets difficult: you could change the order, XYZ, YZX, etc, depending on the quadrant. But, most of the time storing the representation in quaternions and modifying the quaternion instead of translating from a Euler representation every frame will fix gimbal lock. You can also still have gimbal lock with quaternions, it’s all about how you apply the rotation.

Here’s a recent article that says it better than me (you should read about quaternions separately if you don’t already know about them):

A video of your problem might be helpful.