Just for the record and also for anyone willing to make a huge world (not related to BEPU at all for now), this is what I found.
As I'm just a beginner in this field, I may be wrong, so to anyone, don't hesitate to fix any mistake or wrong statement
.
The big "mind leap" is to figure out 3D world is ONLY seen through the lens(es) of the camera(s), so the only thing really matter is distance between the camera and the objects, no matter how these objects and camera(s) are located relative to the world origin. And it may be very close to the classic 2D big world trick of the scrolling (which I didn't really get trough it, unfortunately, I'm sure it would have been a good stuff to learn).
Basically, objects and camera coordinates are expressed relative to the "absolute" world origin: (0,0,0), so for example camera is at (10,50,-20) and the player is at (10,40,10) (for a camera following "behind" and above).
When player moves, it goes farer to the origin, farer, farer, like (10, 40, 1000) then (10, 40, 6000) ... but why keeping using absolute world coordinates so far away ?
The game don't care at all about everything located maybe 1000 units away from the player on Z axis (even less), so the idea is to have two sets of coordinates: absolute and relative.
Absolutes coords. will not be expressed as relative ones, as it doesn't help (FP precision issue will be there too), instead, they are expressed in "tile" coordinates.
For a tile size defined at TxTxT (which can be different values or equals, depending of the game needs), these coords will be like (0, 0, 0) for the 1st player coordinates above, then something like (0, 0, 6) for T=1000.
Inside this 1000 units wide "cube", relative coordinates could be (10, 50, 0) as world z=6000 = tile z=0
With Tiles coordinates inside [ -500, +500 ] interval, 6000 is in the 6th tiles on the Z axis (0=-500,500 1=500,1500 2=1500,2500 3=2500,3500 4=3500,4500 5=4500,5500 6=5500 6500), at the relative origin.
(In order to simplify, one unit is always duplicated, it should be more strictly [ -500, 500 ] [ 501, 1501 ] [ 1502, 2502 ] ...)
The camera will be at (10,40,-20). So both player & camera can be rendered in the world space with coordinates that does not suffer from FP precision issue.
With the tile coordinates, it is easy to calculate distance, for example ETA to a destination, as distance = tile coord difference * tilesize + relative coordinates difference .
Without forgetting tiles are centered on origin, so distances are -500,500 making all remaining coordinates inside a tile expressed minus 500.
Example:
player at (0, 0, 50) willing to go to (1578, 50, 89658), full coords are P( t(0,0,0) 0, 0, 50 ) Dest( t(2, 0, 90) -422, 50, -342) (the game will only know the last two sets)
422 = -500 + 178
342 = -500 + 158
tile 90 on Z because tile N hold absolute coords ( N * 1000 - 500, N * 1000 + 500) => tile 89 stand for [ 88500, 89500 ], tile 90 for [ 89500, 90500 ]
2 on X because Tile 0 = [ -500, 500 ] 1 = [ 500, 1500 ] 2 = [ 1500, 2500 ], with each tile always centered on world origin
The key point to remember is display doesn't care about physics at all, object have coordinates, period. They can moves accurately or more in an alleged UFO style, violating any or all of the Newton's laws. And it doesn't matter if they are near origin or 10^22 units away or even farer than that. But screen/camera cannot dsplay everything and anything that's not visible is not drawn for performance reason.
There is only the boundaries issues which need to be fully handled to avoid some issues (like camera in the "opposite side" of the tile, especially when direct conversion from game coordinates to world coordinates occurred, like on respawn or teleportation).
A similar concept could be use for BEPU Space itself, re-centering the space, using an array of spaces or anything that make your game as you need it to be. This will be the topic of another post
.