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

[Allen B. <al...@vr...>]

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


-- 
-- Allen Bierbaum                         al...@vr...
-- Research Assistant and PhD Candidate
-- VR Juggler Team                              www.vrjuggler.org
-- Virtual Reality Applications Center       www.vrac.iastate.edu