   quaternion - matrix snap
  Hi,I'm suspecting that my quaternion to matrix conversion sometimes causes the rotation to 'snap', much like gimbal lock albeit less noticeable and occurs rarely. I'm not sure why exactly.I use quaternions currently to integrate the dynamics state of objects as well as to store key-framed animation data. In all other cases transforms are stored in a 4x4 matrix for convenience (using OpenGL here). I'm considering directly integrating rotation matrices without the conversion process to solve the dynamics issue, but for the animations I'm not sure.This is the code:void matrix4::SetRotation(const quat &q){ data[0]  = (1.0f - (2.0f * ((q.y * q.y) + (q.z * q.z)))); data[1]  =    (2.0f * ((q.x * q.y) + (q.z * q.w))); data[2]  =    (2.0f * ((q.x * q.z) - (q.y * q.w))); data[3]  = 0.0f; data[4]  =    (2.0f * ((q.x * q.y) - (q.z * q.w))); data[5]  = (1.0f - (2.0f * ((q.x * q.x) + (q.z * q.z)))); data[6]  =    (2.0f * ((q.y * q.z) + (q.x * q.w))); data[7]  = 0.0f; data[8]  =    (2.0f * ((q.x * q.z) + (q.y * q.w))); data[9]  =    (2.0f * ((q.y * q.z) - (q.x * q.w))); data[10] = (1.0f - (2.0f * ((q.x * q.x) + (q.y * q.y)))); data[11] = 0.0f;}Is this correct? Is there an alternative method?   
  Your conversion looks fine. It's hard to know without seeing, but what you could be seeing is the effect of not always using the shortest arc when interpolating between 2 quaternions, possibly higher up in your animation system before the conversion takes place.To always interpolate along the shortest arc, do a quaternion dot product between the two end quaternions and if it is negative, negate one of the quaternions before interpolating.Hope that helps!   ;  That's interesting, I'll have a look into that. I figured it could have to do with Slerp.As far as the dynamics integration thing, it could be a seperate problem since I'm converting matrices to quaternions there as well (which I believe may introduce some accuracy problems).   ;  I did a quick test and removed the slerp code. Problems are now much more severe, resulting in scaling by the resulting matrix, which leads me to believe the exported quaternion data is corrupted (i.e not normalized). It seems as if the slerp routine reduced these problems through it's normalization.Sigh. This is of course no surprise, considering the key frame data comes straight from 3dsmax (which is riddled with *literally* hundreds bugs like these).I did some further investigation into this, and it seems 3dsmax screws up because the affected bone nodes are mirrored.Thanks for the hint!*Edit: My diagnosis was correct, it is in fact yet another bug in 3dsmax. I fixed it by re-normalizing the quaternion in my export script, which undoes the mirroring of the bone system nodes.[Edited by - remdul on September 12, 2007 10:25:34 AM]