# Inevitable Gimbal Lock with Interpolation...

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

## Recommended Posts

I was reading along in "3D Math Primer for Graphics and Game Development" For Euler Angles, the author says that gimbal lock doesn't pose much of a problem when you're just trying to represent an orientation. He says that where problems really start to show themselves is when you're interpolating between two orientations (ie animation). He says that "the basic problem is that angular velocity is not constant during the interpolation". What exactly is he referring to with angular velocity here? I've watched a video visually demonstating what happens to the axes during gimbal lock. It's very helpful for understanding the phenomeon:
He also seems to make a reference as to how gimbal lock really comes into play during animation. What is it about interpoloating between orientations that makes gimbal lock manifest itself the way it does? It is because when simply representing an orientation, with no intention of changing it, that you don't have to care what happened to the other axes afterwards?

##### Share on other sites
Gimbal lock is a defect of Euler Angles only. There are others rotation representation doesn't have gimbal lock problem, e.g. Axis-angle and quaternion. Why bother?

##### Share on other sites
I created a video tutorials to show how to get around this problem by using Quaternions: http://www.marek-knows.com/downloadSection.php?Topic=Math&pg=1#Math8

When you are doing animation, you can get yourself into trouble if your orientation is represented with Euler angles and you end up (by accident) aligning two of your axis together. At this point you have lost the ability to rotate in a specific direction.

##### Share on other sites
Quote:
 Original post by datahead8888He says that where problems really start to show themselves is when you're interpolating between two orientations (ie animation). He says that "the basic problem is that angular velocity is not constant during the interpolation".What exactly is he referring to with angular velocity here?

The problem is not so much gimbal-lock as near-gimbal-lock. Gimbal lock is manifested mathematically as a singular Jacobian, which is to say one of the axes of global rotation ceases to be affected by any of the input angles. Near-gimbal-lock, then, happens when one of the axes of global rotation is only affected a little bit -- that is, it moves very slowly in response to changes in the input euler angles. Of course, each of the axes has to get where it's going at the end of the interpolation. So when you interpolate between two orientations by linearly interpolating the euler angles, where you'd expect a constant-velocity rotation between the two orientations, what you get instead is a strange soup of fast-slow-fast or slow-fast-slow rotations in certain directions, with interpolated orientations not necessarily pointing anywhere near the extrema orientations.

The easiest way to visualize this, though, is just to try it. Make a quick OpenGL program that interpolates a teapot's orientation between two sets of euler angles. If you're feeling really really proactive, post the code back here. :-)

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

• 14
• 10
• 25
• 9
• 57
• ### Forum Statistics

• Total Topics
632642
• Total Posts
3007620
• ### Who's Online (See full list)

There are no registered users currently online

×

## Important Information

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!