Re: [ggt-devel] Bug in matrix state code

[Patrick H. <pa...@13...>]

Well, unsurprisingly, I misdiagnosed this problem.  The data flow is 
rather difficult to explain.  There are a lot of matrices in this code, 
and I got confused tracing through how they all work together.  The 
matrix I mentioned in the previous message is not the one causing the 
problem, though it is being used every frame in the calculation of the 
matrix that is causing problems.

After further testing, I am convinced that there is a problem of some 
form in gmtl::invertAffine() that causes an error to accumulate over 
time.  If I comment out the use of gmtl::invertAffine() in 
gmtl::invert() (lines 564-566 in MatrixOps.h), the bug goes away.  This 
behavior is repeatable in a super simple test case, but the epsilon 
value used for an equality test has to be quite small.  The values in 
the matrices also have to be floating point--the current tests use integers.

I'm still not sure why the error accumulates so quickly in my code 
(within 30 frames, the matrices turn to junk), though it could be the 
cumulative effect of many matrix operations per frame.  A more 
complicated test case may cause the problem to be exhibited more 
effectively.

For the time being, I am inclined to comment out the use of 
gmtl::invertAffine().  This seems like a pretty serious problem since 
gmtl::invert() is a common operation.

  -Patrick

Patrick Hartling wrote:
> I think that there is a bug in the code that does optimizations for 
> matrix operations based on the matrix state.  Unfortunately, I don't 
> know the GMTL code (or math in general) well enough to track down the 
> bug.  I can describe the symptoms, however, with the hope that someone 
> can give me a suggestion on how to do further debugging.
> 
> Basically, what happens is the values of an affine matrix approach zero 
> after it is inverted.  Eventually, they reach zero, and my application 
> crashes.  (The application was not written by me, and the math in it is 
> way beyond me.)  What is particularly vexing is that the single 
> inversion appears to be the only place in the code where the matrix is 
> modified, but somehow its values change constantly after that point.  I 
> must be missing something--I just haven't figured out what.
> 
> In any event, if I back out the only changes to Generate.h, Matrix.h, 
> and MatrixOps.h to remove the state tracking optimizations, the code 
> starts working again without any problems.  I'm guessing that the 
> problem is in gmtl::invertAffine() since it was added as part of the 
> optimization code.  Perhaps there is something in that function that 
> causes additive round-off errors?
> 
> The specific revisions in question are the following:
> 
>    Generate.h: 1.73
>    Matrix.h: 1.28
>    MatrixOps.h: 1.31
> 
> I would appreciate any suggestions on how to track down this problem or 
> any suggested fixes (short of backing out the optimizations altogether).
> 
>  -Patrick
> 
> 


-- 
Patrick L. Hartling                     | Research Assistant, VRAC
pa...@13...                         | 2274 Howe Hall Room 2624
PGP: http://www.137.org/patrick/pgp.txt | T: +1.515.294.4916
http://www.137.org/patrick/             | http://www.vrac.iastate.edu/