# Making a parent system with euler angles (gimbal lock problem)

I have a system where objects can be connected to each other - as the parent rotates the child objects will rotate too and child objects themself can rotate too. The system is already working, however, I am doing it with rotation matrices. I want to dynamically simulate angular physics and for that, I would need the angular velocity for which I thought the direct and easiest way would be to get the difference of the euler angles. I am still a beginner with those rotation maths like matrices, quaternions etc. The problem is that the rotation of the children would be local and currently I am just adding the euler angle values (which works fine if I only rotate around one axis). So when I rotate a child on the x axis by 90 degrees and then rotate the parent on the y or z axis the system breaks (y and z should be swapped in this scenario with 90 degrees x rotation)

As far as I have understood it the problem could be explained with "gimbal lock". Is there a way to calculate the local euler angles? Or is there in general a better way to achieve what I am trying to do here? I have heard that quaternions also don't save 360+ degrees, so that would be also a problem for angular velocity.

I thought the direct and easiest way would be to get the difference of the Euler angles

No, this is definitely not a direct or easy way. This road leads only to suffering.

Euler angles are good for presenting an orientation to a human reader/editor, or for serializing an orientation to disc, or for a few special cases like camera control. But they are an absolute nightmare to use for general orientation computations or compositions. A combination of two Euler angle rotations is not the sum or any simple expression of the angles of the inputs, nor is there a simple expression for inverting them.

Just use quaternions. They don't have the axis bias or gimbal lock problems you've observed. You can compose two rotations in a chain (like a parent and child) as simply as doing a multiplication. And inverting a quaternion (eg. to undo a parent rotation and get into local space) is as easy as negating the x, y, and z components.

I have heard that quaternions also don't save 360+ degrees, so that would be also a problem for angular velocity.

It's not a problem because you use quaternions to store orientations, not angular velocity.

Angular velocity can be stored as an axis and an angular speed, or as a single 3-component vector along the axis of rotation, whose length is the speed of rotation along that axis.

When you want to step forward your orientation by your angular velocity, you integrate your angular speed over the timestep to get a total angle of travel. Then you can construct a quaternion that rotates by that angle about the axis vector, and compose your previous orientation quaternion with this one.

• Thanks for giving a brief overview of quaternions. However my objects are not rotating USING an angular velocity, I want to calculate the angular velocity from the CHANGE of rotation. And I am not sure how I would do that with quaternions. Mar 10, 2021 at 16:32
• Then that should be something you ask in your question. 😉 But it's easy: Invert your "before" orientation, and compose it with your "after" orientation. Now you have the quaternion difference between the two orientations. Convert to angle-axis form, and divide the angle by the timestep to get the angular speed. Mar 10, 2021 at 16:44
• But shouldn't this have conflicts when my rotation changes from e.g. 0 to 500 degrees because quaternion doesn't save angles above 360? The angular speed would then be 140 degrees/dt instead of the actual change of 500 degrees? Mar 10, 2021 at 16:54
• If you can change 500 degrees in a single frame, then the code that rotates 500 degrees should be responsible for storing that 500 degree delta somewhere you can use, rather than erasing that information and forcing a later part of your game to try to reconstruct the delta from an orientation. Euler angles also destroy this information, just in more complex ways, so they do not solve that problem. I'd advise not making your orientation responsible for storing angular movement — store that elsewhere, like in a rigid body structure. Mar 10, 2021 at 17:00
• Thanks, I will look into that. That helped :) ! Mar 10, 2021 at 18:34