No laser beams actually (that would be silly at beyond-float distances), but probes.
In fact detection will be part of the game mechanics. Scan a large sky area and get less range and/or details; scan just where you know the enemy fleet is approaching and get more details from a larger distance.
Floats are simply too cramped. I really tried, but I couldn’t make them work without segmenting the universe. Segmentation has been ruled out for this project because of coding overhead and because it’s constraining game mechanics in ways that don’t fit well with the game logic.
Doubles allow mm granularity at distances of up to 4.6 billion km from the origin. This is still far smaller than a real-life star system, but good enough for a game.
Reality-sized galactic coordinates would require 80 bits, which is beyond the 52 bits of a double or the 64 bits of a long. This would require two longs to deal with that, and I’m not crazy enough to try reimplementing shape intersection with broadphase optimzation with two longs per coordinate.
Streaming from disk isn’t present, the simulation is supposed to run entirely in RAM. The simulation state will be streamed out to disk on a regular basis (once per minute or so) to allow a restart in case of crashes.
This eliminates disk I/O and the overhead of shoehorning a object data model to a relational database.
I’d still do coordinate transforms when building the world.
Using strings for coordinates doesn’t help BTW. Those strings will ultimately have to be converted to floats to go into the jme3-bullet routines, and you’re back at the same precision loss.
Maintaining millimeter accuracy beyond 17 km from the origin means you need to use relative coordinates. I.e. the local transform I was talking about.
You’re right that I wouldn’t be able to put quadrillions of space objects into RAM. I won’t be doing that anyway.
However, with a server with 10 gigs of free RAM and 1 KB per object, I could still deal with 10 million objects. Updating all of them in every 60Hz cycle would put some serious pressure on the L1 cache, and such a scheme will break down at the first O(N²) algorithm that’s anywhere in bullet, jme, or my own code.
If everything is at O(N log N), this should be fine though.
Besides, I don’t plan to really manage 10 million objects; it’s more like 10,000 to 100,000, maybe up to half a million if things scale better than I expect today.
The real issue that I have is:
I need a large universe, and I need some efficient geometric operations: vicinity search, intersecting a really narrow and really deep frustum with whatever is in the geometric space.
I could code that up myself, and spend several man-months on that.
Or I could leverage existing code.
jme3’s octree might have worked but is using floats -> too coarse.
bullet with doubles is just enough; I need to scale down the universe somewhat, but it’s manageable.
longs have even more significant bits, and they’s somewhat easier to deal with, but well, I haven’t found any library that does geometry using longs.
P.S.: Just made sure what the relevant options for cmake are (it’s just one), so modifying the build process should be simple.
Performance tests first though.