That’s not true. It becomes more difficult, but it certainly still works. I believe lots of open-world titles do this exact thing, and don’t have too much trouble with networking. It gets more complex, but at this point it’s your best bet.
Can you provide some evidence or deeper explanation of this? Most games such as MMOs are in fact are ‘hard-zoned’ where players must pass through loading checkpoints to pass from one zone to another. Games like DayZ use double coordinates.
The biggest problem would be rendering. You could do it within the camera’s reference frame (subtracting its 64 bit position from the physics body’s 64 bit position). The only objects that would have precision problems would be ones too far away to even see. As for Z fighting and other Z buffering issues, you could have the camera use logarithmic Z instead, giving you a lot more precision in your Z Buffer.
Other than that, you’d probably have to convert all of the actor’s transforms to either use doubles or calculate their world positions based on the current camera’s viewpoint using the method described above. Not easy at all.
And then you could end up making something of this scale.
i just said that in my previous post (except i called ‘world positions’ “world coordinates”). wouldn’t it be possible for someone to make a fork and use visual studio to assist in going through all of the code and manually as well in some places, to convert the world coordinates system to double precision? without that happening, if someone wanted to do a huge huge world, they wouldn’t be able to have it be multiplayer. so double precision is necessary for certain users.
im sure it is not trivial to make the change, but it would be doable by outside parties not too hard, right? just tedious to convert the position system to double precision?
I think there are a few more elements to it:
- You will need to rewrite all the math libraries and functions to support double calc. Not hard at all but probably fairly tedious.
- From Epic’s point of view they will effectively need to manage and maintain two different codebases across features, bugfixes, etc - Its not so easy to simply write some C++ macros to compile for float/double. I can understand why they might not want to officially support it right now. Though that said the simulation market can be fairly lucrative and I’m a little surprised they aren’t actively targeting it. I suppose they want to focus for now.
I have run into the big problem in other engines when using single floats. Objects start to jitter around and geometry curves get stepped, or legoed as we call it. Im interested in possible work arounds or double precision code.
our lead coder alerted me yesterday that there is already double precision support for depth buffers in the engine…
I’m very interested in this. I want to do a huge open world (multiplayer) driving simulator, as well as a huge open world (multiplayer) RPG, both with UE4 graphics. So I do need this. Though I don’t know if I would be of much help…
So, if I replace the physics engine with Bullet, set for double precision, I also need to change all floats in UE4 to doubles? Is that all? Or I misunderstood?
The real way to do this is origin rebasing, as mentioned. It may seem like a hack, but unless you’re interested in essentially rewriting the engine as mentioned so that everything uses double precision, it’s useless to use double precision in PhysX. Precision issues would just creep up in the rendering anyway.
Origin rebasing can work just fine with multiplayer, though its more complex. Typically what you do is make it so that each grid cell is run by a zone server, and players are handed off between them (or maybe a collection of grid cells to one zone server). That way you don’t have 10 areas loaded on the server because 10 players are each in a separate one.
That sounds like work, but it’s still less than rewriting the engine to use double everywhere (which IMO would still have issues).
Regarding Infinity, I believe they too use origin rebasing, and don’t use double precision for rendering either, so that scale is possible quite without an engine rewrite.
One way to do it would be to express the positions of each actor relative to the given chunk.
Say one actor walks out of the chunk it is currently in, and into another chunk. You allow everything to behave as per normal UE4 behavior - but then at some point in the next frame you relocate the actor’s position to expressed relative to the new chunk. This ensures there are no per-actor hickups over multiplayer.
It gets tricky. I think there might be no way to do this without modding the engine a good amount. You’d have to modify functions that do things such as find nearby actors to account for the different chunks, amongst other things. Then the physics would have to be modified to work with it as well.
Client-side using floats with origin rebasing is actually superior, because double support on video hardware is pretty dodgy. Those gpu registers are 128 bit for a reason (though newer hardware uses 256 bit registers, and efficiently support doubles.)
@Thalvik - that’s origin rebasing 
There’s support for it in the engine.
I can’t imagine it working with origin rebassing. After the world bounds move with the player, what happens to stuff that leaves the world bounds? It stops working? It becomes inaccurate? It disappears with no trace? How would it work in a multiplayer, especially in multiplayer with many players at once, each in a different part of the map?
That’s not really how it works… Say you are in the main grid area, and go to the one directly north of the main one. Without rebasing, the edge of the new area is at say XY = 2000m, 2000m (assuming a 4km area for the main area). With rebasing, when the player moves into the new area, his origin is changed, so that instead of being relative to the origina; area’s origin, and now being at +2000m, +2000m, he’s relative to the new area’s origin, and so is at -2000m, -2000m.
It would work the same way as in single player, but you might need to split off processing of individual areas to separate server instances. If not, then the server just has all the areas with players present loaded. But for a big game and/or lots of people, making it so each area is run by a separate server instance is a good idea.
Doing that will require extra engine work, of course. Probably mainly in terms of making the server pass off the player and connect to the new one on a zoning request.
But origin rebasing does work quite well for multiplayer open world games. As far as I know, basically every mutliplayer game with open world areas like that uses it. By the same token, I don’t know of any game, single or multiplayer, that just tries to process everything at double precision.
The problems associated with origin rebasing in multiplayer are similar to the problems normally faced by mutli-area multiplayer games anyway.
I see, that is useful info. But, what about, making a realistic car racing simulator, one that will also have pretty big maps, for example a 200km point-to-point course? Multiplayer of course. With 30+ cars on the track at once.
BTW, I’d like to have a single dedicated server application, that players can launch their own, instead of providing official servers. How hard would it be to rework the engine to use double precision? I’m guessing simply replacing all floats with doubles (which I guess can be done pretty quickly) is not all there is to it?
You might as well just forget about the whole double precision idea.
You can make the car racing thing work with origin rebasing, you just need to pick your setup carefully and fix any problems that arise. If it’s a racing car game, you can probably skip having it use zone servers for separate areas entirely and just use the basic World Browser type stuff. Even if the server has to have 3-4 areas loaded, it’s not going to be that intensive because generally the only thing it’s simulating are the cars and terrain (you’ll have to actually test and see what the limits are).
So in that case, it works just the same as single player except the server has multiple areas/tiles loaded up at once, depending on where the players are.
For 30+ cars in a race that size, my guess is you’ll run into bandwidth issues first.
(200km is also huge I think you’ll find the other problem is just filling all that space up with stuff to make it look neat)
Thanks, I guess I’ll do that then. But I’d still try to at least replace the physics engine to something a bit more suitable like Bullet for example, or to whatever Rigs of Rods uses perhaps.
Can you give me examples of games that use origin rebasing, and games that use double precision? What do games like TES2: Daggerfall, TES5: Skyrim, ArmA 3, rFactor, Just Cause 2 and Test Drive Unlimited use, to name a few out of the top of my head that I know handle huge maps nicely?
I guess I’ll have to modify the netcode as well. UDK had 64 player limit, but it was already lagging quite a bit long before a full server. rFactor, which was one of the best racing simulators until recently, can handle both huge tracks and up to 100 cars on track without much sweat. The dedicated server even has a setting for the bandwidth:
I also know there are ArmA 2 servers with 200 players and 2000 bots…
There is a mod for Skyrim in the works that aims to have the whole Tamriel as a single seamless playable area, in the moding team’s blog they said that they were running into accuracy issues but changed some stuff in the configs and it’s all good now. I’m pretty sure Tamriel is bigger than UDK’s limit of 10.5km x 10.5km. Actually there are similar mods for Morrowind and Oblivion as well.
Unless things have changed, implementing Bullet is going to be a lot of work for not much gain - PhysX from what I recall is actually a good bit faster (talking CPU implementations for both).
What you probably want to do is get it set up and test it first (using origin rebasing) and see where the bottlenecks lie.
As far as I know PhysX doesn’t support soft body physics, it also only has CUDA for GPU acceleration, Bullet has soft body physics, and supports CUDA as well as OpenCL, and is open source so I can modify it. But yeat, I will not hurry up too much with that, I’m first gonna experiment around a bit.
PhysX does indeed support soft body physics - though I don’t know if UE4 has it integrated.
As for GPU acceleration - that’s only useful for misc non-gameplay-affecting objects like debris and stuff anyway - you’re not going to be able to use it to accelerate your car physics, if that’s what you’re getting at (CPU sim to GPU back to CPU for results is way too slow for main game simulation). Your mileage may vary though.
CPU physics should be plenty fast enough for 30+ cars.