Bug 483 - ProjectFloat.gluInvertMatrixf() improperly claims some matrices are non-invertible
Summary: ProjectFloat.gluInvertMatrixf() improperly claims some matrices are non-inver...
Alias: None
Product: Jogl
Classification: JogAmp
Component: opengl (show other bugs)
Version: 2
Hardware: All all
: P5 enhancement
Assignee: Wade Walker
Depends on:
Reported: 2011-03-19 00:11 CET by Wade Walker
Modified: 2013-03-27 14:37 CET (History)
2 users (show)

See Also:
Type: ---
SCM Refs:
Workaround: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Wade Walker 2011-03-19 00:11:55 CET
Original post from kolkoo at http://forum.jogamp.org/gluInvertMatrixf-problems-started-with-gluUnproject-td2698279.html:

Well we have been struggling with gluUnproject returning false for totally valid passed arguments for a few days now, we also noticed that by taking the code from http://www.opengl.org/wiki/GluProject_and_gluUnProject_code and converting it to java it works flawlessly, so we dug deep and saw that for some matrices your gluInvertMatrixf function returns false stating that the given matrix is not invertible but it in fact is. I am attaching example matrices for you to check out, hopefully this is of some help to you :) 

For example your invert function fails on the following matrix: 
[-0.8184068703526464, -0.7313346429703671, 0.8265999715430894, 0.8265727758407593, 
 0.0, 2.266778784171848, 0.3441178170910746, 0.3441064953804016, 
 1.5188486310796492, -0.3940677440777307, 0.44539996103581814, 0.44538530707359314, 
 -29.837189131809282, 7.880600278695056, 31788.731450702064, 31789.685546875] 

and this matrix has an inverse of approximately 

[-0.2749384784384102, -8.508771838660298E-9, 0.5102473310792097, 0.0, 
 -0.12547721590338706, 0.3889178409085109, -0.06761135604083059, 0.0, 
 13141.636777184758, 5470.961521026936, 7071.334994947186, -0.49999177469301814, 
 -13141.24258735293, -5470.797418788947, -7071.122269004663, 0.5000082253043491] 

Have a nice day :)
Comment 1 Wade Walker 2011-03-19 23:43:22 CET
I've duplicated this failure. Now researching why it occurs.
Comment 2 Sven Gothel 2011-07-23 02:33:33 CEST
any progress on this ?
Comment 3 Wade Walker 2011-07-23 02:56:48 CEST
I looked at it, and it seems like the supplied matrix is ill-conditioned (note the 14 orders of magnitude difference between the smallest and largest numbers in the inverse matrix). Any matrix inversion algorithm will fail on some matrix or another, though the algorithm we're using is not the most robust one mentioned in "Numerical Recipes in C".

I didn't want to replace the whole algorithm without first creating a big set of regression tests, which didn't seem like a good use of my time right now unfortunately.

So I'd classify this as "nice to have" rather than a bug, since it's just a matter of us not being as robust as we might be.