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

[Kevin M. <ke...@vr...>]

using matrices to accumulate might be error prone, make sure the guy is 
accomodating for drift...  make sure he is actually inverting an affine 
matrix (if he's setting values manually, he'll need to set the state to 
full manually).

what part of the matrix is going to crap?  and what is the matrix being 
used for?  i.e. what sort of accumulative operation is being done...

kevin

On Sun, 7 Sep 2003, Patrick Hartling wrote:

> 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
> > 
> > 
> 
> 
> 

-- 
*--*---*---*----*-----*------*------*-----*----*---*---*--*
Kevin Meinert                         /_/                  
home - http://www.vrsource.org/~kevin           \        / 
music - http://www.subatomicglue.com           \/  __    \/
                                                   \__     
                                            \_\