• FEATURED

View more

View more

View more

Image of the Day Submit

IOTD | Top Screenshots

The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.

Quaternion rotation VS Euler angles based rotation

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

4 replies to this topic

#1gluontronic  Members

Posted 23 June 2012 - 01:50 AM

Hi there,

If I use quaternion to rotate an object in my 3d space, I won't have any gimbal lock right?

I know about the efficiency around calculation (multiplications only and no trigo, less memory for storage etc) but wanted to be sure about the lock.

Especially, I'm calculating azimuth and elevation using the coordinates X & Z of the resulting vector of translation+rotation to camera space.
The atan2 have singularities and I wanted to know if I used quaternion I would "override" these singularities.

My maths seem rusty..
Any help would be appreciate
julien
> my project

Posted 23 June 2012 - 05:53 AM

I'm not a real expert when it comes to quaternions, but I can say that they do avoid the gimbal lock problem

I gets all your texture budgets!

#3gluontronic  Members

Posted 23 June 2012 - 06:16 AM

I understood it like that too.
It is the way to avoid it..

In the Demo Avoiding Gimbal Lock section, I read this:

he main point you should take note (in the while loop) is

• The orientation of the camera is a quaternion.
• There are 3 angles corresponding to the keypress. Note the angles are meant to be an on/off switch (not accumulative). I reset them inside the while loop. Of course this is not the best way to do it but as I said, it is a quick job.
• I convert the 3 angles to a temporary quaternion.
• I multiply the temporary quaternion to the camera quaternion to obtain the combined orientation. Note the order of multiplication.
• The camera rotation is then converted to the Axis Angle representation for transforming the final matrix.

When a key is pressed, I generate a temporary quaternion corresponding to the key for a small rotation in that particular axis. I then multiply the temporary quaternion into the camera quaternion. This concatenation of rotations in 4D space will avoid gimbal lock. Try it and see for yourself.

In my system (based on OpenGL in Max6 framework), I'm grabbing the cam quaternion and this is that one I convert to matrix and I apply it to all my objects coordinates.
This is that resulting vector I'm taking for my atan2 based azimuth calculation.

I don't use the temporary vector at all. Maybe my problem comes from here.
I don't use it because my system provides me directly the quaternion from the cam.

still stuck ?!
julien
> my project

#4Álvaro  Members

Posted 23 June 2012 - 07:16 AM

I multiply the temporary quaternion to the camera quaternion to obtain the combined orientation.

That's the key to avoiding gimbal lock. You need to have some representation of the current attitude and modify it with incremental rotations around the axes. Whether you use quaternions or some other representation is secondary.

If you keep track of a cumulative roll, pitch and yaw and then compose them into an overall rotation, you'll run into gimbal lock regardless of what representation you use.

#5gluontronic  Members

Posted 23 June 2012 - 10:37 AM

Alvaro,
I got it.
and this is directly related to my mistake!

I'm using Max6 and I have to implement that.
I guess all objects required already exist but I'm a bit confuse with these incremental rotations
(reference post to Max6 forum in order to excite search engines a bit http://cycling74.com/forums/topic.php?id=40633&replies=12#post-197452 )
julien
> my project

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.