Do we really need quaternions? In UE4 I rotate without them

Question

I want to experience gimbal lock to be able to understand how it happens. In lots of videos it shows that when you rotate along one axis, other axis is also being rotated and you obtain gimbal lock. For example, as you can see in this video, https://www.youtube.com/watch?v=zc8b2Jo7mno the axis are hierarchical. But I don't see the same in UE4. When you rotate in Editor it always rotates around world coordinate system and you cannot obtain a lock. If I can rotate around world (fixed) coordinate system, why shouldn't we always use that and instead use quaternions? Or I miss something? See all the videos that explain gimbal lock. They always rotate around one axis, while rotating other axis with it too. Why? And at this point, as I cannot obtain the lock, I think quaternions are useless if you rotate around world coordinate system and have 0 problem.

Answer 1

Rotating around euler-angles in world-space makes sense as long as you have a concept of a fixed horizon and a fixed "up" and "down" direction (like in a first person shooter).

But in some other contexts, like a first person flight simulator (atmospheric or space), this way of handling rotations falls apart.

Imagine a plane in level flight. What do you do when the player moves their stick to the left? You would rotate the plane around the z-axis. Pitch and roll stay the same and the yaw changes. So far, so good.

But now imagine what happens if the plane isn't level but actually in a steep ascending flight. When the player moves the stick to the left, you would not just expect the heading to change, you would expect the ascending angle to get lower and the plane to bank to the side. But that's not what will happen if you rotate around the world z-axis. Only the direction will change, pitch and roll will stay the same.

This behavior might be OK in a very arcade-like and simplified aeroplane simulation. But when you do the same in a space simulation where the horizon is usually merely implied by your level arrangement (if at all) and the player stops being aware of it when they get into a dogfight, it becomes quite annoying.

But if you use quaternions for handling rotation, you won't have that problem, because quaternions allow you to handle rotations in a way which is completely agnostic to the directions in which your axis' point.

Answer 2

I think you have one key misunderstanding in your question which is causing all this confusion.

You've asked "why shouldn't I just rotate objects using Unreal Engine 4's world rotations instead of using quaternions?"

But those aren't actually different choices; UE4 performs its world rotations by using quaternions; you can't pick just one or the other -- they're both the same thing! And that's why you have been unable to see gimbal lock in UE4's editor.

Gimbal lock is only a problem when an object's orientation is represented internally using euler angles, which no modern game engine does. (And no major game engine has done for probably approaching two decades, now)

So.. this isn't really something you typically need to worry about, these days, unless you're writing your own engine from scratch!

無

Answer 3

I'm quite late here but maybe this helps someone...

You can't get the gimbal lock this way. How it works is that the editor keeps current object orientation (as a quaternion) and when you drag-rotate your object it creates a new, relative rotation around selected axis (also as quaternion). Then it concatenates both rotations to compute the result. This way the math works just fine so you won't see any problems.

To get the issue you're after you need an app, that allows you to set the rotation using 3 Euler angles, then computes 3 separate rotations - around each axis, and concatenates them, to get the result. That's probably every app with some kind of "Object Inspector" where you set 3 floats as an X, Y and Z rotation, like 3D MAX, Unity or UE4.

I've tested it with Unity but you can do the same in UE4:

• Create a 3D object and select it
• Click and slightly drag every rotation value in object inspector - you should notice that dragging X value rotates object around X axis and so on...
• Now type 90deg into X, Y and Z.
• Click and slightly drag every rotation value again - this time you should notice that despite having 3 controls for rotation you can rotate the object only around 2 axes. In other words - two of your X,Y,Z controls rotate around the same axis - you've got the gimbal lock!

It doesn't seem so bad, right? But imagine you're the operator of some robotic arm, that can freely rotate around each axis and you have 3 levers to steer rotation - one lever for each axis. There're some orientations in which you just can't rotate around some axis.

This applies also in virtual 3D - if you 'steer' you orientation using Euler angles then there are situations where you just can't do what you want and it results in erroneous movements.

We can also look at this from another way:

You have some initial orientation, given with 3 Euler angles and you want to rotate to your final orientation. The final one is very similar to initial, but slightly rotated around the axis that you don't control because of the gimbal lock. Despite the fact that both orientations are visually similar, their Euler values may differ a lot, so if you're interpolating them, from initial to final then you object can rotate semi randomly at some point.

Answer 4

You can avoid gimbal lock by using matrices to store the rotation and iteratively ad rotations to it. Once in a while you'll need to re-orthonormalize the matrix to avoid developing odd skews.

However you can't easily interpolate between 2 matrix orientations. If you do, you need to re-orthonormalize it each time, while you can very easily interpolate between quaternions.

Quaternions are handy because they easily support a near-perfect super-set of the operations you typically want to perform on orientations (concatenating, interpolating, inversion). The only one of the top of my head that they don't is the lookat.