@pspeed now that you have me converted to your zone based 64 bit network layer the natural next step is for me to re-visit my server side physics. I can see two possible options here. You probably have already tested both so … which is better from your experience?
Option #1: Now that I have relatively small zones I could just stick with JBullet and create a physics space per zone on the server.
Option #2: Now that my entities have 64 bit precision for translation and rotation, I create a 64 bit physics engine based on octrees since the network layer pretty much is an octree and I don’t have to worry about rebuilding it since it’s already being done by the network code anyways. The parent child tree structure is not in the network layer but the zone management and zone keys deal with 80% of what I would need for an octree anyways.
Thoughts?
People say octree a lot but I don’t think they really mean it. In dynamic 3D worlds, I’ve never found a use for it. After you add in the limitations necessary to make it functional, you’re better off just having a sparse fixed size grid. Basically, as soon as you answer the question “Will you split infinitely or only down to a certain zone-sized quantum?” then the main difference is that sparse grids have O(1) lookup time and octree’s have O(logn) lookup time or whatever. In one case you can identify the grid cell with a formula and in the other you must do X number of split checks. Possible *2 for neighbor checks that must ascend to the root and back.
Anyway, my universe is not so big that I can’t just have one “physics space” that’s just optimized to only check for collisions in local zones. Someone on the forum has recompiled bullet to use double but I don’t know how he manages his broad phase.
…but that might be one path. Fork bullet to use doubles and then make sure the broadphase is smart with respect to zones. Once objects are potentially colliding from the broad phase you can do more expensive checks.
But honestly I haven’t thought of this on the scale of a giant space shooter so maybe there is some place it falls down… but there are also few places to go from there.
Edit: and note, while it’s flattering on some level to have my name right in the subject of a post, you are also potentially turning away folks who might have more specific experience with this ‘galaxy space physics’ problem than I do. 
Points taken. I called you out by name mostly because I know you implemented 64 bit physics married to your network layer. I agree about no need for octrees if I just make small enough zones. I wonder if I just had a root node for each zone in bullet and used floats for the entities in each physics zone if I should even care about precision? That might be the easiest route. I can even scale that solution across a cluster of servers each servicing 1-n zones.