DEV Community

Discussion on: My Journey into the Fundamentals of Computer Graphics - Part 3: Return of the Rotational Issues

Collapse
 
tandrieu profile image
Thibaut Andrieu

Hey Eric, nice article !

I invite you to tell me if you already knew about the gimbal lock and if it has caused you any problems!

Ohhhhh yesss, but not in the way you imagine ! I'll tell you my story 😁

I was working on aeronautical domain, on a UAV camera control. Camera were attached under the UAV and was controlled with azimuth/site parameters. As expected, camera get stuck when looking vertically.

One of the dev noticed that I had implemented all the rotations using matrices, and saw in this wikipedia article (french version) that "The solution of the gimbals lock problem is to use quaternions". So he undertook to reimplement all the computations using quaternions... Yep, changing the code won't change the fact that the mechanical device IS a gimbal...

I regularly had this discussion that matrices don't cause gimbals lock all along my career. It's the way you structure your rotations that cause it. I ended up having an argument with the Wikipedia article author to rephrase its article in 2012, but the common misconception that matrices cause gimbal lock, and quaternion don't, is still widspread in developpers mind 🙁

Collapse
 
ericbl3 profile image
Eric Buitrón López • Edited

Hi Thibaut, thanks for sharing your story! Just as you say I think it's important to understand the device that you're using (or trying to recreate in a 3D virtual world) before trying to implement solutions for gimbal lock. I agree with you that quaternions have this misconception of being the solution to gimbal lock and it's probably caused by not understanding completely how they work.

I have to admit that at the moment of writing this reply, I'm guilty of having such a misconception. Even though the books I'm reading have just mentioned at the moment that quaternions are another approach and are a possible solution and not necessarily the only solution! If I were to stop my learning journey right now (and I hadn't read your comment), I would stay with this misconception and just go right away to implementing quaternions thinking that they will always fix the problem. Thanks a lot for making the clarification that this won't be the case! Hopefully, the chapters that I'll be reading this week about quaternions will also mention this.

Collapse
 
tandrieu profile image
Thibaut Andrieu

The thing to keep in mind is that, from a mathematical point of view, quaternions are "strict subset" of matrices. Everything a quaternion does, matrix can do. But matrices can do thing that are not possible with quaternions (like scaling, squishing, projection, ...).

Knowing this, I have to admit I was never that much interested in quaternions. I just don't like them and prefer using matrices for everything 😁

However, quaternions have 2 advantage compared to matrices:

  • Performances. Multipliying 2 quaternions require less operation than multiplying 2 matrices. But in practice, matrices multiplications are rarely the bottleneck in render engines nowadays, and matrices multiplication is so well optimized on hardware that I'm wondering which one is actually faster.

  • Numerical stabilities. Ok, one point for quaternions. Accumulating several rotations create less imprecision with quaternions than with matrix. That's why in robotics for ex., when lots of rotations are involved, it is preferable to use quaternions. In 3D, quaternions are translated to matrices anyway by the render engine.

Thread Thread
 
ericbl3 profile image
Eric Buitrón López

This definitely helps! Thanks a lot for your comments!