Archived

This topic is now archived and is closed to further replies.

FERNANDO-BRASIL

Please... someone help me!

Recommended Posts

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

Share this post


Link to post
Share on other sites
browny    139
guess u made a mistake in the matrix !!
for X:
the matrix should be

mat[0] = 1; // this is the mistake u made. this element should be 1

mat[5] = c;
mat[6] = s;
mat[9] = -s;
mat[10] = c;

the rule of the thumb is
when u rotate about some axis , say X, the X row, and X colum of the matrix should always be 1. Hence , when u rotate about Z, the Z row and Z column should be 1 ( i.e mat[14] = 1 )

i hope this will solve your problem


Share this post


Link to post
Share on other sites
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!!

Share this post


Link to post
Share on other sites
Eber Kain    130
Even though a single matrix can represent rotations around all 3 angles, you can use 3 glRotates to do this. glRotate is nothing more than applying an uler angle to the current matrix stack.

The only solution to rotate on 3 angles is with quanternions, all they do is create a matrix that represents the 3 different rotations. Then you inturn feed this into opengl via gLoadMatrix or glMultMatrix

If you dont want to get into quanterions then i reccomend that you only rotate around 2 angles. You would be supprised to know how many games only use 2.

Share this post


Link to post
Share on other sites
browny    139
well... the oder of transformation is the most vital thing. Mathematically "Rotate_about_x" then "Rotate_about_y" is DEFINITELY NOT same as "Rotate_about_y" and then "Rotate_about_x"

Hence whatever u do, u must maintain the oder of rotation. U just can''t rotate figures in random oder and expect the same result. That''s mathematically incorrect and got nothing to do with programming.

Did this solve ur problem.... or am i misreading/misinterpreting u ?

Share this post


Link to post
Share on other sites
Eber Kain    130
When useing a matrix, if you rotate around only two axi then the order should not matter.

If however you rotate around 3, then the order can make a serious difference.

Share this post


Link to post
Share on other sites
miles vignol    122
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?

Share this post


Link to post
Share on other sites
Sneftel    1788
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.

Share this post


Link to post
Share on other sites