Hi everybody... My message is about a topic that appears be endless... A lot of people have written this and sorry for writing it again.... It''s about GIMBAL LOCK! I''m very tired in searching for information about that... Every page that I try to find asnwers gives me only "idiot" informations about that.. (or the idiot is me, that can''t undestand what it says)... Well, but instead of asking ideas about QUATERNIONs, I''ll bag, for someone who can tell what the next phrase say: "You can avoid the Gimbal Lock using Matrix or Quarten..." My question in this phrase is about Matrix... My actual engine is coded with matrix of [16] elements... I translate the objects with this matrix, and do rotations with this matrix too... Then, why I''m still getting Gimbal Lock fu**ing problem?? I''m rotating the objects this way: c = cos(angle) s = sin(angle) X: matrix[5] = c; matrix[6] = s; matrix[9] = -s; matrix[10] = c; Y: matrix[0] = c; matrix[2] = -s; matrix[8] = s; matrix[10] = c; Z: matrix[0] = c; matrix[1] = s; matrix[4] = -s; matrix[5] = c; I don''t know if it''s correct, but I would like to know, what everybody means when they say that I can avoid Gimbal Lock problem by using Matrix... Thank you guys... and sorry for the long text

Thank you very mutch browny, but unfortunately, the problem ins''t the rotation...

My problem is the ''Gimbal Lock'', that happen with Euler angles...

I occurs when you try to do rotations...

Example:

try do this three rotations:

glRotate(30, 1.0f, 0.0f, 0.0f);
glRotate(90, 0.0f, 1.0f, 0.0f);
glRotate(10, 0.0f, 0.0f, 1.0f);

That''s right, the object that you rotate, won a new position...
But now, invert the order of the three commands, and try to rotate it again...

glRotate(10, 0.0f, 0.0f, 1.0f);
glRotate(90, 0.0f, 1.0f, 0.0f);
glRotate(30, 1.0f, 0.0f, 0.0f);

Well, you''ll see that the object, rotated and stoped in a different way...

All that I want to do, is to avoid this problem...

Thank you guys!!

What do you mean by "avoid that problem"? What are you expecting to happen, exactly? If you rotate in a different order, you''re gonna get a different result. Are you thinking one result is more correct than the other, or is neither one correct?

Gimbal Lock (as I understand it) is when your rotation priority (XYZ, ZYX, YXZ, etc) is set up in such a way that one of your rotations ends up "switching" to mimic another axis (like you rotate 90 degrees in Y and suddenly X rots mimic Z rots). The solution would be to not try to represent an object''s orientation in terms of 3 rotational values. Generally, the 3 Rotation scheme sounds great cuz it matches up so well with 3 Scales and 3 Translates, but it''s pretty arbitrary.

I guess the question I would ask is where are you getting your XYZ Rotation values from?

Yeah... "gimbal lock" is so often used to scare beginning game programmers into using quaternions, a complex and (relatively) computationally intensive solution to a problem that may in fact not exist.

Unless you have some object whose orientation (that means the direction it has been rotated to) is completely arbitrary, you can easily get away with Euler angles.

Let''s take the example of your standard FPS. You need one Euler angle, in the y axis, to allow the camera to look right or left in a full 360 degree circle. If you want the player to be able to look up and down, add the x axis of rotation. Euler angles can encompass this perfectly.

If you''re programming something like a flight simulator, there is where quaternions can come into play. Almost all other situations, however, can be quite easily accomplished with Euler angles. If you''re unsure about which to use, go with Euler angles to start; it shouldn''t be too hard to switch over if you aren''t too far down the line (and you won''t be, if you need it), and it''s a lot simpler to code.

Hope this helps.

When I said avoid, I wanted to say ''To Solve''.