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

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

I was thinking of the re-orthonormalization too, and wondering if the guy 
just needs to do that.  I don't know enough about what he's doing though 
to say much more...

I'm guessing it is going out of affine, because the 3x3 isn't orthonormal 
and with drift quickly gets crappy because the invert affine somehow 
doesn't account for it.

it would be good to get some sample data and try to run it through to see 
where it falls apart.  (i.e. is it a bad scale, is it truely error drift, 
something else?)


kevin


On Mon, 8 Sep 2003, Allen Bierbaum wrote:

> Kevin Meinert wrote:
> > 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).
> 
> Does GMTL provide facilities for either of these things: accomodating 
> for drift or even checking if the matrix is affine?
> 
> Another helpful method may be something to correct a slightly drifted 
> matrix to "re-affine" it.  I know I have seen libraries that implement 
> re-orthogonalization, but I am not sure about affine.
> 
> -Allen
> 
> > 
> > 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           \/  __    \/
                                                   \__     
                                            \_\