Bug 1452 - Decouple math functionality to 'com.jogamp.math' to be toolkit agnostic (PMVMatrix, Matrix4f, Vec4f, ..)

Posting Bug 1452 here to be noticed .. and discussion, if applicable.

FYI, see
- https://jogamp.org/bugzilla//show_bug.cgi?id=1452
- https://jogamp.org/cgit/jogl.git/commit/?id=5d6e8a367c03644740187e500c6de5d3ac039d5e

Math functionality (PMVMatrix, Matrix4f, Vec4f, ..)
- shall be used toolkit agnostic, e.g. independent from OpenGL
- shall be reused within our upcoming Vulkan implementation
- may also move outside of JOGL, i.e. GlueGen or within its own package to be reused for other purposed.
   
The 'com.jogamp.opengl.util.PMVMatrix' currently also used to feed in GLUniformData
via the toolkit agnostic SyncAction and SyncBuffer
shall also be split to a toolkit agnostic variant.
   
An OpenGL PMVMatrix specialization implementing GLMatrixFunc can still exist,
being derived from the toolkit agnostic base implementation.

It could become an excellent candidate to replace 3D math libraries in some frameworks or engines, couldn't it?

Maybe I should try to determine which pieces are missing to replace ardor3d-math.

A whole lot of this looks the same or substantially the same as what we had to invent in Jaamsim, I'll try to find some time to compare the two and see what might be missing to allow us to move directly to this one.

com.jaamsim.math package.

At the end of the day, I'm not sure if the jogamp package would be better off just providing what works to interact with jogamp libraries, or try to be a fuller implementation like the java3d vecmath package was trying to be.

Harvey

com.jogamp.math alone wouldn't be enough to replace vecmath and ardor3d-math because some methods have to deal with OpenGL or at least with NIO buffers but com.jogamp.math + the OpenGL specific part would be a better candidate for this purpose. Moreover, other APIs would benefit of something potentially very well tested and a strong separation between the toolkit agnostic part and the toolkit specific part.

Julien, a few months ago I removed the whole hardcoded NIO stuff from ole PMVMatrix in favor of a more flexible data binding - see the SyncBuffer (SyncMatrix4f, ...) and its SyncAction.
This is now part of the agnostic PMVMatrix4f

See PMVMatrix4f's 'SyncMatrices4f getSyncPMv()'
which feeds right into a shader via GLUniformData, e.g. RedSquareES2:

pmvMatrixUniform = new GLUniformData("mgl_PMVMatrix", 4, 4, pmvMatrix.getSyncPMv()); // P, Mv

GLUniformData then picks the SyncAction, allowing to synchronize matrices if required
and then using the SyncBuffer to copy the data to the GPU.

So all this is rather universal to the backend .. only needs the SyncBuffer/Action receiver on
the toolkit side to use the data (OpenGL in above example).

(Yeah, still having ole GL'sh PMVMatrix (now a specialization of PMVMatrix4f in tests and demos),
doesn't matter that much - but in new code or toolkits I only use PMVMatrix4f.
The data binding is the very same.

Addendum: The new design was required as I dropped the float and NIO buffers in favor of Matrix4f generic math for usability. Performance tests showed that they are even faster than the checked array access.