#### Archived

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

# What exactly is Gimble Lock and is it all that bad?

This topic is 5963 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

From the example I saw of Gimble Lock, I saw something like: If you rotate, say, 90 degrees(down) on the x axis, and then try to rotate on the y axis, since the x axis will be aligned with the y axis, it wont rotate or something along those lines... Firstly, this was around a section on matrices so if it only applies to vectors, tell me before I start a big rant against nothing. Then, though the forward(z) axis of the matrix wont rotate, the xy plane will, which is proberbly the desired effect(like in FPS games, look straight up and rotate, it doesn''t move the pixel your looking at but the rest of the screen rotates) The proposed solution was use rotation something like this: a [x 0 0] matrix multiplied by a [0 y 0] matrix multiplied by a [0 0 z] matrix Isn''t this exactly how euler angles are generated, except with 24 less bytes(6 floats that = 0)? Also, whats all this gluLookAt crap? What happened to making your own matrix? Its necessary anyway if your going to use models with inter-limb polygons.

##### Share on other sites
quote:
Original post by dreddlox
From the example I saw of Gimble Lock, I saw something like:

If you rotate, say, 90 degrees(down) on the x axis, and then try to rotate on the y axis, since the x axis will be aligned with the y axis, it wont rotate

or something along those lines...
Firstly, this was around a section on matrices so if it only applies to vectors, tell me before I start a big rant against nothing.

Gimbal lock applies to any rotation with Euler angles. Axis and angle, Rotation matrices and quaternion rotations don''t have this problem. (Just to name a few)

quote:

Then, though the forward(z) axis of the matrix wont rotate, the xy plane will, which is proberbly the desired effect(like in FPS games, look straight up and rotate, it doesn''t move the pixel your looking at but the rest of the screen rotates)

Say you turn 90 degrees to the right, then try to look up. If you''re gimbal locked, you might not be looking up. It''s a real problem.

quote:

The proposed solution was use rotation something like this:
a [x 0 0] matrix
multiplied by
a [0 y 0] matrix
multiplied by
a [0 0 z] matrix

Isn''t this exactly how euler angles are generated, except with 24 less bytes(6 floats that = 0)?

No, you''re generating one rotation matrix from the euler angles, and applying it all at once to your vertices. If you''re doing an Euler angle approach, you rotate by x, then by y, then by z. That''s three small rotations to one large one. Since each of the 3 rotations is also rotating the further axes of rotation, you can get gimbal lock when one axis rotates to line up with one of the other axes. Since they all move at once with a composite rotation matrix, they axes will stay orthogonal throughout the rotation.

quote:

Also, whats all this gluLookAt crap? What happened to making your own matrix? Its necessary anyway if your going to use models with inter-limb polygons.

Many people still make their own matrix. gluLookAt is just a shorthand way of setting up a very common type of view matrix. And I don''t believe ''inter-limb'' polygons would affect the camera transform. Can you expound on the problem with gluLookAt in that circumstance?

1. 1
2. 2
Rutin
21
3. 3
JoeJ
18
4. 4
5. 5

• 14
• 39
• 23
• 13
• 13
• ### Forum Statistics

• Total Topics
631717
• Total Posts
3001878
×