64bits calculcations precision for JME

jme uses Float for almost everything right?
is there some benchmark related to Double usage?
and why not use Long and and consider the unit as 1000 (like 1.0 in float would mean 1000 in long), in a sense of absolute precision (could even be 1000000), to the world’s objects’ positioning at least.

also, the libs dependencies all use float right? could that be a problem? (perf loss at float casting/converting)

so main concerns could be:

  • lowered performance
  • higher memory usage
  • dependencies adaptation (requiring changes on the dep code or the dep func calls)

And the main advantage would be… precision.
Not that it is so imprecise that we need it to be Double or Long, I just mean it would be interesting to have more precision, worlds wouldnt be endless, just a lot huger, and may be make it more ready to the future? (not that I am an oracle or something like that…, I just think it is obvious, tho aiming for 128bits doesnt seem adequate yet)

And no, I dont have a test case to say it really needs to be 64bitted as soon as possible… no, I dont have even a test case to show any problems on it as it is now.
And no, I am not saying jme is bad… I love it, cuz of that I wonder if it could be 64bitted, may be at JME 4.0?
And yes, I would like to know your thoughts on the subject, may be I should consider things differently? may be I shouldnt care so much about it, if so why? only u may know :slight_smile:

PS.: should I just sed replace all float/Float with double/Double (and casts where/if needed) to benchmark by myself?

I am by far no expert but I guess having to rework everything would be a main hinderance.
It’s also to check what Bullet uses.

I guess the main reason for floats is historically grown with 32bit processors unable of natively handling 64 bits as well as performance (back then a 64bit int multiplication had to be emulated by multiple (thousands?) of 32bit mults.

Now with dedicated 64bit ALUs my guess would be that the biggest Performance difference could be bandwidth which Doubles (both for the game logic and the Shader params).

A Key Point would be the question why you’d need Doubles though since big worlds are paged (you cant have the whole World in memory/gpu), and paging would be a bit like said combination of float and long (namely the zone id)

1 Like

OpenGL uses float. JME is an OpenGL scene graph.

If you make the huge horrible outlandishly terrible apocalyptic stupid crazy nonsensical choice to use spatials as your game objects then you will also be limited to float. That’s just the way it has to be.

Because converting to float every frame for every vertex, position, etc. for OpenGL would be super-crazy (see all adjectives above).

You are free to move your game objects in whatever precision you like. I recommend double. That’s what I use.


You crack me up paul. I think your’e going crazy over answering the same questions countless times.

Opengl is the visual representation of your game objects. It uses floats. But its just the visual representation. Your calculations can be done in tally scratches is thats what floats your boat. But when you put them onscreen, the imprecision is only visual. Your calculations will be correct because they dont pull data from the scene. You already have it. The scene just represents its state… And it just represents it in less precise yet extremely fast form. A.k.a floats.

1 Like

Also Bullet uses float so if you have a scene that has its state manipulated by it, then you’re limited to float as well.

And graphics cards themselves love floats over any other type. Ints, booleans, etc… are all a no-no really. Everything wants to be a float. They are heavily dependent on and optimized for floats.


True. But there are a bunch of types of games that don’t need bullet at all.

Physics is easy. It’s the collision detection/resolution that’s hard… and only if you need to be mesh accurate. Games like 2D shooters, minecraft, tower defense games, etc., etc. don’t really need anything like bullet.

But they would all need a scene graph or some visualization.

I get it now, despite I already knew it, it was not clear to what point it could/should be, so in short:
game logic can/must be independent of its representation, therefore not limited by the representation, so we can work with any precision we want and just adapt it to the engine.
thx u all :slight_smile: