Bug 483

Summary:	ProjectFloat.gluInvertMatrixf() improperly claims some matrices are non-invertible
Product:	[JogAmp] Jogl	Reporter:	Wade Walker <wwalker3>
Component:	opengl	Assignee:	Wade Walker <wwalker3>
Status:	CONFIRMED ---
Severity:	enhancement	CC:	gouessej, sgothel
Priority:	P5
Version:	2
Hardware:	All
OS:	all
Type:	---	SCM Refs:
Workaround:	---

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.