How can you avoid gimbal locks using quaternions?

[Mel]

Pretty straight forward question. HOW THE FRICK do you avoid gimbal locks with quaternions. I've always tried to figure this out, and in the end i've always resorted to just grabbing my previous frame of reference and updating from that on, one way to avoid locks if you don't move right into the forbidden positions, but i always wondered how quaternions solved this issue.

[MartinVee]

I stumbled upon that article that explains how to add quaternion support to Irrlicht, and it talks a bit about the gimbal lock problem :

http://staraban.com/en/adding-quaternio ... ht-engine/

[Mel]

Nice reading on the subject, and indeed, it would be nice to have a direct quaternion interface in Irr for rotations directly with quats, yet they're not intuitive at all. As for what i've read as well, seems that gimbal lock is avoided simply by keeping the reference frame normalized. Wouldn't it be simpler to update the up, right and front vectors each time you do a transformation and transform using increases, not absolute values? Of course, you have the loss of precission issue, but simply i keep stumbling upon answers about this problem that give no answer at all, which is "use quaternions" Thus my question: How?

[AReichl]

As i understand it, you begin with an ABSOLUTE orientation, then you apply a RELATIVE rotation to it with a quaternion and then you calculate "back" the NEW ABSOLUTE orientation.

Irrlicht is doing it internally with the animated meshes ( think of all those connected bones with different positions and orientations! ).

In flight dynamics they have ( or had ) the same problem with the gyroscopes ( three rings for X,Y,Z ). Under certain conditions they just "stuck", for example a plane going straight up.
You can solve it by adding a fourth ring around the inner three ones. This outer ring "shifts" the coordinate system of the inner ones and avoids gimbal lock. To get your "real" orientation back, you somehow have to "subtract" this shift again.

Quaternions are doing mathematically what this fourth ring is doing mechanically.

According to an article i read a long time ago, the best solution for game engines is to store all orientations as usual ( meaning euler angles ) and only use quaternions for intermediate calculations. What Irrlicht could need are some helper functions for rotations so not every user has to invent them again and again.

[thanhle]

You would use Matrix calculation or Quaternion with axis angle.