Floating-point problem in quaternion::operator=

[luthyr]

Code: Select all

inline quaternion& quaternion::operator=(const matrix4& m)
{
    const f32 diag = m(0,0) + m(1,1) + m(2,2) + 1;
 
   if( diag > 0.0f && !irr::core::equals(diag, 0.0f))  

Occasionally there will be floating point error with .X animated meshes resulting in incorrect rotations and I pinpointed the issue to be floating point error in the quaternion class when converting from a matrix.

I used irr::core::equals to make sure it's not too close to 0 and that seemed to fix the issue.

[CuteAlien]

@luthyr: Thanks. Do you have by any chance the matrix for which it goes wrong so we can test it? And is this a new bug which got added in svn or did you just test with svn and this could be an old bug (just asking as this thread is usually for recent bugs)?

[luthyr]

I'd guess it's probably a pretty old bug, but wasn't sure if I should make a new thread for it.

The problem matrix (pulling from the .X file) should be either
-1.000000;-0.000000; 0.000000; 0.000000;-0.000000;-0.142244;-0.989832; 0.000000; 0.000000;-0.989832; 0.142244; 0.000000; 0.000000;-5.170858;-93.710489; 1.000000;
or
-1.000000;-0.000000; 0.000000; 0.000000;-0.000000;-0.154326;-0.988020; 0.000000; 0.000000;-0.988020; 0.154326; 0.000000; 0.000000;-5.036783;-92.351505; 1.000000;

The diag would end up being very close to 0 and return an identity transform instead of the correct rotation, causing a one-frame graphical glitch.

[CuteAlien]

Thanks. I've split the topic... but have a hard time figuring out if checking diag > some_epsilon is the correct solution as quaternion math isn't really something I know much about. So if anyone who know about that stuff could give some feedback, that would be great ...

[hybrid]

Yes, the test should make sure that the value is != 0 and large enough to avoid loss of precision. So I guess it's ok to solve it as shown.
http://www.euclideanspace.com/maths/geo ... /index.htm