Inevitable Gimbal Lock with Interpolation...

Started by
2 comments, last by Sneftel 14 years, 10 months ago
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?
Advertisement
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?
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.

Quote:Original post by datahead8888
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?

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. :-)

This topic is closed to new replies.

Advertisement