Hello, i got an problem with my spacecraft project and i am on a big problem point that stopped the whole project. the problem is not new... but hard to understand and much harder to get to work in OPENGL. first i try with euler angles and was getting the gridlock problem.. ...Java with OPENGL(jogl) public void setCamera(int camera,GL gl,GLU glu) { gl.glMatrixMode(GL.GL_MODELVIEW); gl.glLoadIdentity(); gl.glTranslatef(0.0f,0.0f,0.0f); gl.glRotatef(vr3, 0, 0, 1); //roll gl.glRotatef(vr2, 1, 0, 0); //pitch gl.glRotatef(vr1, 0, 1, 0); //yaw if (camera==1) gl.glTranslatef(eye_x,eye_y,eye_z); } that work for nearly all my projects..but this is the first time i get in airplane/spacecraft thing. i know i need querterinions but there are some big questions about it : - i know i can grab the matrix of the camera with: gl.glGetFloatv(GL.GL_MODELVIEW_MATRIX, mvm, 0); there i got 3 vectors (front,up,left)..can i use this for quater. rotation..and if yes: how can i put it back into the Modelview_Matrix. something like gl.glSETFloatv(GL.GL_MODELVIEW_MATRIX, mvm, 0);??? did i need any other roation code than glrotatef for camera/objects?! i google and ask a lot of times..but i was not succsesful to find something i understand. a lot of formulas ... a lot of Codefragments without any explanaition for newbees. can anybody help me?

Quote:i know i need querterinions...

Why do you say that? What makes you think that what you want to do requires the use of quaternions?

Anyway, this sort of thing is much easier to do if you manage the transformations yourself using your own or a third-party math library. Then when it's time to render, simply upload the transform to OpenGL via e.g. glMultMatrix*().

i am not a big math. expert.
i was looking for the problem and everything i see
was about quaterinion to avaoid the gridlock.

if there are other thing to do the same..ok :)

one question is answerd: glMultMatrix

but back to the problem:

how to implement something that does the
"spacecraft in space that want to rotate thing"?

Gimbal lock is a problem of Euler angle only. As long as you are using Euler angle, you have gimbal lock problem.

If you are using quaternions correctly, you can avoid gimbal lock problem. However, it is not the whole story. Indeed, as long as you are not using Euler angle, you can avoid gimbal lock.

Check this out.
http://www.gamedev.net/community/forums/topic.asp?topic_id=463800

And also, check this out too. The last reply I posted is a rotation interface using axis-angle.
http://www.gamedev.net/community/forums/topic.asp?topic_id=493530

Quote:Probably because there are many places online (and in books) that claim that quaternions don't suffer from gimbal lock...

Yeah, I know :) My question was really intended to be a leading one.

Quote:What do you mean "correctly"? Can you please demonstrate a correct and an incorrect usage of quaternions and explain the difference? (i.e., explain why one is correct and the other is not)

It's not so much an issue of 'correct' usage as it is an issue of what sort of behavior you want. If you're working with Euler angles and don't care about gimbal lock or other artifacts of that particular representation, then building the Euler-angle rotation using quaternions is entirely correct (if perhaps a bit pointless). If you want free 6DOF rotation and/or wish to avoid gimbal lock, then Euler angles will probably be the wrong choice regardless of whether quaternions or matrices are used as an intermediary.

In any case, I imagine what ma_hty meant by 'correctly' was 'in a way that avoids gimbal lock'.

As ma_hty and jyk have said, gimbal lock is an issue when using Euler angles to describe rotations. That is, when you describe your rotations as three angles around the three axes (or less angles/axes, if you simply don't want rotations about a specific axis). So quaternions or not, you risk getting into gimbal lock by describing your rotations using Euler angles, and avoid gimbal lock by staying away from describing your rotations as Euler angles.