The most common practice that I read about for overcoming floating point precision in video games with large worlds is by dividing the world into cells and load it with player's position and shift origin of objects with respect to player.

However this seems to be only valid for single-player games. As soon as you change to multiplayer with authoritative server scenario a lot of anomalies arises.

Since a authoritative server has to keep track of all of the world its not possible to base the origin off a single player

For a object that is halfway through two or more cell's co-ordinate system. which cell's part should it be ? and how should it react to it?

There seems to be extremely little to no information about supporting such worlds for multiplayer which are larger than what a common origin can support with enough precision.

I am working on UE4 so the common bottlenecks I see are physX being single precision and modern GPUs being feasibly performant only on single precision vertex data.

Can anyone shed some light on the topic ? I am all in to learn it if its possible on current technology

Why not use a 64 bit integer for coordinates.

You could measure the game world in millimetres and still have a game world light years across in real terms, without overflowing the variables.

I really don't see why there would be issues segregating the world into blocks though.

What theoretical issues do you envisage? the physx thing is a non starter as you wouldn't run full physics on anything so far away you couldn't see it anyway, similarly a server wouldn't need full physx on everything, right?

in case you missed it I limited by the following:

I am working on UE4 so the common bottlenecks I see are physX being single precision and modern GPUs being feasibly performant only on single precision vertex data.

As such changing the number systems raises two large problems:

1. Engine code needs to be changed extensively

2. Code performance would degrade due to larger bandwidth usage and in translating double to float for GPU

There would be issues segregating the world into blocks because of the following :

1. Unlike single-player games you do not have a single player reference you can have for origin shifting,Two players might be in completely different blocks at the same time , this would mean both blocks should be processed in the same level tick now without changing precision how would you keep one block away from the other without losing it's positional data (float would become in comprehensible after a limit)

2. Since block origins cannot move, when an object is crossing over from one cell to another how would you determine which cell's origin should be used for processing its position,physics and rendering ?

If you really want to use relative coordinates in a continious world, you could look at how Dungeon Siege did it in the early 2000's:

http:/gamedevs.org/uploads/the-continuous-world-of-dungeon-siege.pdf

http://scottbilas.com/files/2003/gdc_san_jose/continuous_world_paper.pdf

But that's kind of an unusual situation. Most multiplayer games with big maps get by just fine by dividing the world into regions and handling boundary issues. (One way: do the calculations based on the coordinates of the originating object's region. If the regions are small enough to fit two into the valid space, and no effect can cross more than a region-width distance, it'll work just fine.)

Or, if you really want to include both small rocks and massive stars in the same coordinate system, you can go 64-bit, like braindigitalis suggested. Elite: Dangerous switched to 64-bit only when they added planet landing, as an example.

I think, though, that you might be under the misperception that everything in a video game needs to be simulated at full fidelity all the time. Especially when it comes to graphics, that's seldom attempted. For example, you'll probably never need to use more precision on the GPU for distance, because once you get past a certain distance it's probably cheaper to just render a sky sphere. Elite: Dangerous does this with its galaxy: the backgrounds are created from a model of the galaxy in a different coordinate system. This is pretty standard in FPS engines, too.

Nope I'm not about the visual effects here, My game is a space sim where I want the player to be able to fly at actual tremendous speeds of a jet aircraft (~1000 Kmph) at this speed the world space re-presentable by floats would run out in a few seconds.

Most multiplayer games with big maps get by just fine by dividing the world into regions and handling boundary issues.

Cant find any details on any specific implementation of that when the situation is multiplayer , so far 100% of search results have pointed to how to handle that in single player which is comparatively way easier. (unity MMO fanboys posts, you know that's frustating)

only now am I got the dungeon siege details about multiplayer so this might be the first on point result I got , but you say that's an unusual case, so can you please direct me to a resource or research paper on the usual case?.

the physx thing is a non starter as you wouldn't run full physics on anything so far away you couldn't see it anyway, similarly a server wouldn't need full physx on everything, right?

Its not about what you can see or not , its about what exists on server, physics is not just decorative but say vehicle physics .

Like I said everyone misses the point , ITS MULTIPLAYER not single player, so even if one player cannot see it server still need to keep track of it since physics is part of gameplay and not decoration

The same basic logic applies to both Singleplayer and multiplayer, the game engine also doesn't matter much in the logic.

You need to create an asset loader/unloader, split the map into chunks, create a way for servers to talk about near chunks, and allow players to pass through different chunks.

Chunks with no players can be unloaded.

Like I said everyone misses the point , ITS MULTIPLAYER not single player, so even if one player cannot see it server still need to keep track of it

The things that exist on the server are different than the things that exist on the client.

There is nothing preventing you from using fixed point math in one representation --- as discussed with the world as a fixed point 64-bit integer --- and also having a floating point representation used for your client game engine.

The most common practice that I read about for overcoming floating point precision in video games with large worlds is by dividing the world into cells and load it with player's position and shift origin of objects with respect to player.

Note that this is extremely common because it is very effective.

Floating point works well for most games, assuming a meter scale, up to about a 4 km value from center. That's +/- 4km in x and in y, or about 64 square kilometers, or about 25 square miles. That's an enormous area.

Occasionally, perhaps after you've traveled a kilometer or two, or a mile or so, you update the world so you're in a new center location.

Even for large worlds it is rare for RPG-style games to cover more distance than that in a single region. WoW is currently on the order of 60 square miles of actual content. Most of the older areas are vacant ghost-towns. Skyrim and Dragon Age Inquisition are both on the order of 20 square miles of content. GTA 5 covered about 100 square miles, but the vast majority of it was fake/duplicate buildings. It was probably around 2-3 square miles of actual modeled stuff plus about 10 miles of modeled roadway segments.

The same basic logic applies to both Singleplayer and multiplayer, the game engine also doesn't matter much in the logic.

You need to create an asset loader/unloader, split the map into chunks, create a way for servers to talk about near chunks, and allow players to pass through different chunks.

Chunks with no players can be unloaded.

Please no , you are completely missing the point . its not about loading unloading things , its about overcoming the location issues with multiple users on the server.

There is nothing preventing you from using fixed point math in one representation --- as discussed with the world as a fixed point 64-bit integer --- and also having a floating point representation used for your client game engine.

As discussed earlier it still means a major rewrite of the game engine and the physics engine add to that the loss of performance for using a different number system than the code was optimised for initially

Finally I repeat again , I have no issues with understanding how cell division and origin shifting works in single player, but the moment you add two players on the server all hell breaks loose. please read the question again for exact problems that would appear when applying this cell division logic on server

Please no , you are completely missing the point . its not about loading unloading things , its about overcoming the location issues with multiple users on the server.

Each chunk has it's own centered coordinate that's used to do calculations, so that becomes a non-issue.