gluUnProject() and gluUnProject4() in ProjectFloat.java and ProjectDouble.java multiply the model and projection matrices in the wrong order. This seems to be because calls to gluMultMatricesf() and __gluMultMatricesd() (which multiply in column-row order) were replaced by calls to FloatUtil.multMatrixf() and FloatUtil.multMatrixd() (which multiply in row-column order). This problem appeared in RC6, and was first reported by user "lukej" on the forum at http://forum.jogamp.org/Problems-with-gluUnProject-td3954975.html.
<http://jogamp.org/git/?p=jogl.git;a=commit;h=cbc77718f01a8190e1a8aa0e9afdc2a3a3403358> Fix regression of commit <http://jogamp.org/git/?p=jogl.git;a=commit;h=de2b129a56335262a44a05541a3ab2e35668cc6e>: ProjectFloat Matrix Multiplication of gluUnProject(..) impl. ProjectFloat's previous gluMultMatricesf(..) used row-major order, but the replacement multMatrixf(..) uses column-major order (like OpenGL, ..). Note: The replaced 'gluMultMatrixVecf' by multMatrixVecf() already used column-major order. Fix: Reverse the arguments of matrix multiplication m1 x m2 -> m2 x m1
<http://jogamp.org/git/?p=jogl.git;a=commit;h=7f85501bd448afc9ba52f6abbe5f049d673d824d> Added further unit test w/ actual gluUnProject(..) usage. Remark: FloatUtil's multMatrixf(..) does column-major multiplication, i.e. expect the linear matrix layout to be in column order. In case the implementation does not follow the above statement (you find a bug), pls re-open this bug report.