Solving gimbal lock

Quote:

Original post by jyk I didn't quite follow all that, but maybe it's a multiplication order problem - did you try 'newQuat = Q*newQuat' instead of 'newQuat = newQuat*Q'? Coordinate system handedness should not matter for what you're doing. Beyond that I can't give much in the way of advice, as I'm not quite clear on what sort of motion you're trying to achieve. If the multiplication order suggestion doesn't help, maybe you could provide some more details (such as what the object represents, how the user interface works, and exactly what sort of motion you want the object to undergo).

Quote:

Original post by jyk Question: if it's your engine, why not just revise the interface so that it accepts orientations in quaternion or matrix form? Then you could bypass the Euler-angle conversion(s) entirely.

Quote:

Original post by altra4u Issue:Solve gimbal lock for a Left hand coordinate system with first y, then x and then z order of rotation.So I want the rotations to be always around the global axis.i.e not the local axis of the object.

Quote:

Original post by clb Quote: Original post by altra4u Issue:Solve gimbal lock for a Left hand coordinate system with first y, then x and then z order of rotation.So I want the rotations to be always around the global axis.i.e not the local axis of the object. What you're describing is not possible without changing the logic of how you do rotations. Gimbal lock is a problem about logic of combining several rotations, and not about the way you represent those rotations. So, your question is effectively "How can I use Euler's method for expressing and combining rotations that suffers from gimbal locking so that it doesn't exhibit gimbal locking?" You ask to use the method v'=R*v, where R=Rz(a)*Rx(b)*Ry(c) and Rx, Ry and Rz rotate around the three world coordinate axes. Unfortunately you cannot escape gimbal locking if you just use three fixed world axes, no matter whether Rx, Ry and Rz are rotation matrices or quaternions. You can see this for example by setting b=pi/2 and computing R. It always happens (no matter whether you use Euler xyz, zyz, xyx, etc.) that in the resulting transformation matrix R, the scalars a and c adjust the rotation about the same axis, i.e. you have lost that one degree of freedom (see Euler Rotations Explained, or Wikipedia derivation of the R matrix during gimbal lock). One solution that allows you to combine three successive rotations is to use the local object axes. I.e. do R=Ry(yaw)*Rp(pitch)*Rr(roll). This requires that you change the axis around which Ry and Rp rotate according to pitch and roll (i.e. the axis around which Ry rotates depends on pitch and roll, and the axis around which Rp rotates depends on roll). This maps nicely for example to keyboard/mouse input from player: mouse horizontal alters yaw, mouse vertical alters pitch and so on. Note that here the problem was solved by changing the logic of how you combine rotations, not by changing the representation of these rotations. I know you mentioned you did not want to use local axes, but that's really the only way I know of that allows you to do this kind of simplistic R=R1*R2*R3 scheme. Hope that was helpful,

Quote:

Original post by altra4u I believed that multiplication of two quaternions would solve the gimbal lock problem as they lie on sphere.At least that is what the explanation goes on this tutorial http://www.gamedev.net/reference/articles/article1095.asp

Finally, we've reached what you all been waiting for: "How can quaternions avoid gimbal lock.?"The basic idea is1. Use a quaternion to represent the rotation. 2. Generate a temporary quaternion for the change from the current orientation to the new orientation. 3. PostMultiply the temp quaternion with the original quaternion. This results in a new orientation that combines both rotations. 4. Convert the quaternion to a matrix and use matrix multiplication as normal.

Finally, we've reached what you all been waiting for: "How can 3x3 rotation matrices avoid gimbal lock.?"The basic idea is1. Use a 3x3 rotation matrix to represent the rotation. 2. Generate a temporary 3x3 rotation matrix for the change from the current orientation to the new orientation. (This matrix will not in general rotate just about one fixed world axis,    but it has to be generated using a formula for arbitrary angle-axis rotation matrix).3. PostMultiply the temp matrix with the original matrix. This results in a new orientation that combines both rotations. 4. <strike>Convert the matrix to a matrix and</strike> use matrix multiplication as normal.

/** Sets the top-left 3x3 area of the matrix to the rotation matrix about an arbitrary axis. Elements outside the top-left 3x3 area are ignored. Apply the rotation matrix in the order v'=M*v.	@param m The matrix to store the result.	@param a The axis to rotate about. The axis must be normalized.	@param angle The rotation angle. */template<typename M, typename V, int Rows, int Cols, MatrixPackingOrder Pack>void SetRotationAxis3x3(Matrix<M, Rows, Cols, Pack> &m, const Vector<V, 3> &a, angle_t angle){//	assert(axis is normalized);	const typename M::elem_t c = Cos(angle);	const typename M::elem_t c1 = (typename M::elem_t(1)-c);	const typename M::elem_t s = Sin(angle);	m[0][0] = c+c1*a.x*a.x;	m[1][0] = c1*a.x*a.y+s*a.z;	m[2][0] = c1*a.x*a.z-s*a.y;	m[0][1] = c1*a.x*a.y-s*a.z;	m[1][1] = c+c1*a.y*a.y;	m[2][1] = c1*a.y*a.z+s*a.x;	m[0][2] = c1*a.x*a.z+s*a.y;	m[1][2] = c1*a.y*a.z-s*a.x;	m[2][2] = c+c1*a.z*a.z;}

input: float yaw,pitch,roll;Rroll = RotationMatrix(axis(0,0,1), angle(roll));axis pitchAxis = Rroll * vec(1,0,0);Rpitch = RotationMatrix(pitchAxis, angle(pitch));axis yawAxis = Rpitch * Rroll * vec(0,1,0);Ryaw = RotationMatrix(yawAxis, angle(yaw));R = Ryaw*Rpitch*Rroll;

input: float x,y,z;Rx = RotationMatrix(axis(1,0,0), angle(x));Ry = RotationMatrix(axis(0,1,0), angle(y));Rz = RotationMatrix(axis(0,0,1), angle(z));R = Rx*Ry*Rz

Quote:

Original post by clb Quote: Original post by altra4u I believed that multiplication of two quaternions would solve the gimbal lock problem as they lie on sphere.At least that is what the explanation goes on this tutorial http://www.gamedev.net/reference/articles/article1095.asp Multiplication of two quaternions has exactly the same effect than multiplying two matrices that represent the equivalent rotations. The article is good in will, but that example is unfortunately rather poor. From the article: Finally, we've reached what you all been waiting for: "How can quaternions avoid gimbal lock.?"The basic idea is1. Use a quaternion to represent the rotation. 2. Generate a temporary quaternion for the change from the current orientation to the new orientation. 3. PostMultiply the temp quaternion with the original quaternion. This results in a new orientation that combines both rotations. 4. Convert the quaternion to a matrix and use matrix multiplication as normal. Well, the article is correct here. There's no gimbal lock in here. But the fact that there is none is nothing to do with quaternions, but that he got rid of the problematic logic of combining rotations. In fact, I can substitute the word 'matrix' wherever the word quaternion occurs and things are still true: Finally, we've reached what you all been waiting for: "How can 3x3 rotation matrices avoid gimbal lock.?"The basic idea is1. Use a 3x3 rotation matrix to represent the rotation. 2. Generate a temporary 3x3 rotation matrix for the change from the current orientation to the new orientation. (This matrix will not in general rotate just about one fixed world axis, but it has to be generated using a formula for arbitrary angle-axis rotation matrix).3. PostMultiply the temp matrix with the original matrix. This results in a new orientation that combines both rotations. 4. <strike>Convert the matrix to a matrix and</strike> use matrix multiplication as normal. That's totally sound & sane, and it is so because of the logic of what we're doing. We're not performing rotations about fixed world axes like you would be when combining rotations using the Euler scheme. But you don't need quaternions to avoid that! Google: Rotation arbitrary axis will show the way. I couldn't find a page quickly that would show the final formula, so I'll just paste the appropriate code from my library: *** Source Snippet Removed *** To rotate about local axes you utilize this function that generates rotations about arbitrary axes. The pseudo for yaw-pitch-roll goes something like this: (roll is applied first, then pitch, then yaw) input: float yaw,pitch,roll;Rroll = RotationMatrix(axis(0,0,1), angle(roll));axis pitchAxis = Rroll * vec(1,0,0);Rpitch = RotationMatrix(pitchAxis, angle(pitch));axis yawAxis = Rpitch * Rroll * vec(0,1,0);Ryaw = RotationMatrix(yawAxis, angle(yaw));R = Ryaw*Rpitch*Rroll; For comparison, the method of combining Euler XYZ angles would be something like input: float x,y,z;Rx = RotationMatrix(axis(1,0,0), angle(x));Ry = RotationMatrix(axis(0,1,0), angle(y));Rz = RotationMatrix(axis(0,0,1), angle(z));R = Rx*Ry*Rz When rotating about local axes, we just follow the directions our axes are pointing at after each rotation that we've applied, and the next rotations will be done about these rotated axes and not some global fixed axes. One of the reasons why people often favor the use of quaternions is that rotations about arbitrary axes are somewhat easier (and possibly faster) to generate than these matrices that rotate about an arbitrary axis. But then you have the conversion and other stuff going on, so it depends. The usual disclaimer with correctness.. I just wrote that pseudo from the spot, so double-checking it is in order.

Quote:

Original post by clb Quote: Original post by altra4u I believed that multiplication of two quaternions would solve the gimbal lock problem as they lie on sphere.At least that is what the explanation goes on this tutorial http://www.gamedev.net/reference/articles/article1095.asp Multiplication of two quaternions has exactly the same effect than multiplying two matrices that represent the equivalent rotations. The article is good in will, but that example is unfortunately rather poor. From the article: Finally, we've reached what you all been waiting for: "How can quaternions avoid gimbal lock.?"The basic idea is1. Use a quaternion to represent the rotation. 2. Generate a temporary quaternion for the change from the current orientation to the new orientation. 3. PostMultiply the temp quaternion with the original quaternion. This results in a new orientation that combines both rotations. 4. Convert the quaternion to a matrix and use matrix multiplication as normal. Well, the article is correct here. There's no gimbal lock in here. But the fact that there is none is nothing to do with quaternions, but that he got rid of the problematic logic of combining rotations. In fact, I can substitute the word 'matrix' wherever the word quaternion occurs and things are still true: Finally, we've reached what you all been waiting for: "How can 3x3 rotation matrices avoid gimbal lock.?"The basic idea is1. Use a 3x3 rotation matrix to represent the rotation. 2. Generate a temporary 3x3 rotation matrix for the change from the current orientation to the new orientation. (This matrix will not in general rotate just about one fixed world axis, but it has to be generated using a formula for arbitrary angle-axis rotation matrix).3. PostMultiply the temp matrix with the original matrix. This results in a new orientation that combines both rotations. 4. <strike>Convert the matrix to a matrix and</strike> use matrix multiplication as normal. That's totally sound & sane, and it is so because of the logic of what we're doing. We're not performing rotations about fixed world axes like you would be when combining rotations using the Euler scheme. But you don't need quaternions to avoid that! Google: Rotation arbitrary axis will show the way. I couldn't find a page quickly that would show the final formula, so I'll just paste the appropriate code from my library: *** Source Snippet Removed *** To rotate about local axes you utilize this function that generates rotations about arbitrary axes. The pseudo for yaw-pitch-roll goes something like this: (roll is applied first, then pitch, then yaw) input: float yaw,pitch,roll;Rroll = RotationMatrix(axis(0,0,1), angle(roll));axis pitchAxis = Rroll * vec(1,0,0);Rpitch = RotationMatrix(pitchAxis, angle(pitch));axis yawAxis = Rpitch * Rroll * vec(0,1,0);Ryaw = RotationMatrix(yawAxis, angle(yaw));R = Ryaw*Rpitch*Rroll; For comparison, the method of combining Euler XYZ angles would be something like input: float x,y,z;Rx = RotationMatrix(axis(1,0,0), angle(x));Ry = RotationMatrix(axis(0,1,0), angle(y));Rz = RotationMatrix(axis(0,0,1), angle(z));R = Rx*Ry*Rz When rotating about local axes, we just follow the directions our axes are pointing at after each rotation that we've applied, and the next rotations will be done about these rotated axes and not some global fixed axes. One of the reasons why people often favor the use of quaternions is that rotations about arbitrary axes are somewhat easier (and possibly faster) to generate than these matrices that rotate about an arbitrary axis. But then you have the conversion and other stuff going on, so it depends. The usual disclaimer with correctness.. I just wrote that pseudo from the spot, so double-checking it is in order.

Quote:

Original post by bzroom This question gets asked often. http://www.gamedev.net/community/forums/ViewReply.asp?id=3478352