Did you ever consider to use double instead of float in jme-core classes like Vector3f and Matrix3f for providing more precision? That would be helpful in large scaled scenes like vehicles moving on the earth surface. I know there should be other solutions to avoid precision issues in those situations and also OpenGL, GPUs and vertex buffer only use float, but at least in my special use case (GitHub - thomass171/tcp-flightgear: Migration of some parts of FlightGear to Java.) it really helps. The effort will be quite low and I wouldn’t expect any negative side effect.
Currently I use a custom JME build that uses double instead of float. If my proposal sounds acceptable, I could create a pull request for it.
This is the root of the reason. JME is just a thin wrapper around OpenGL. That’s a good thing because it lets the application developer decide how best to optimize instead of having every game be hit by the performance problem of constantly converting double to float.
It’s also why it’s strongly recommended to treat the scene graph like a visualization instead of using it as the “game data model”. For example, building a local “things that are scene” visualization around the ‘player’ instead of trying to represent the whole world or all of outer space or whatever.
Your situation might be somewhat unique because you are trying to port someone’s existing code. But for me, I’m kind of glad not to take the conversion hit.
(Though I really do wish the physics solution was using double instead of float.)
Edit: and to be clear, I’m a huge double-lover. I use it exclusively everywhere else.
I have in my project double precision versions of the jmonkeyEngine Vector3f etc that I use for physics etc (that I call a Vector3dJME because it follows all of JME’s conventions and the Vector3d name is already taken by Java’s much worse Vector3d class). At the graphics card layer it is all floats as you say so there has to be an offset done before these things are given to the graphics card. Usually I have a physics → graphics sync and at that point I do a Vector3dJME → Vector3f conversion at that point (which usually involves subtracting a big offset from the Vector3dJME)
Thank you for your feedback. So I think for now I will keep my custom JME build (I think it is similar to what ‘richtea’ mentioned). And in the long term I will try to find a better solution, maybe one like ‘pspeed’ proposed.