Double Point Precision Questions (Large open world games)

  1. Since apparently it is to difficult even for Epic to implement double point precision in the engine to support very large open world games, I figure I wouldn’t be able to do so either, therefore is there a reasonable alternative solution I could implement instead? If so, are there any in depth tutorials anywhere on how to do this?

For those with knowledge of programming & or hiring a programmer:
2. How much as an estimate, will it cost to hire someone to implement double point precision or alternate solution (so a very large seamless game world can be utilized(We’re talking multiple planets) for an MMO?
3. How long would it take as an estimate, to implement double point precision or alternate solution (so a very large seamless game world can be utilized(We’re talking multiple planets) for an MMO?

Unfortunately, this is a ‘how long is a piece of string?’ question - there’s no real answer to it. I expect that it could involve a fair bit of work, since you’d need to adapt the PhysX implementation to make use of double-precision, and from there you’d want to implement some basic types into the gameplay / scripting layer. You’re probably looking at a few months of work for an experienced engineer.

Some of the answers can be found in threads like this one. If Rareden shares his code, you’ll have it!
The problem with that overall is, its going to be fixed / hardwired to a single version of the engine etc…
Anyway start reading back through past threads. Search on Large-Worlds / Origin-Shifting in the title.
Single player is easy. Multiplayer without Dedicated-Server tile-option requires a custom solution etc…

Thank you for your guess on it. :slight_smile:

Thank you for sharing that information.
From what I read, they do plan to share it I’m assuming after it is finished, but apparently are currently having trouble with…version-errors
So if anyone could assist them I’d be grateful. I’m not knowledgeable enough to help with it yet.

I know this is a few months old but I wanted to reply to this. First of all, it’s easy to aquire and compile PhysX with double precision. Second of all, it makes much more sense in my opinion to comine origin rebasing with double precision on the CPU side, just keep the physics and the rendering as floats. I did this with a custom engine and can render very distant objects very easily, I’m sure it would be just as easy to do with Unreal. The tricky part for me was dealing with shadows casted from large distant objects, such as large capital ships in orbit, I ended up using a sort of sparse octree and raymarching their signed distance fields… I have no idea if it’s going to be easier or harder to do the same in Unreal but that’s my next task anyway, as I’ve decided to move back to unreal from a custom engine.

Oh and as a side note, when dealing with MMO type games, you also make the task of tackling zoning potentially much easier with a world that can rebase properly and can save on bandwidth.

IMO you want to run physics in double precision but run the rendering in floats (which is what warvstar suggested too). But I wouldn’t go modding UE4 for it.

In ideal case you’d have everything rendering camera relative but with UE4 your best bet is to just run physics and your physics math in doubles and let everything on ue4 side use the old float based system, just rebase the origin for the clients and and update the physics transforms manually from your own sim.

The reason why I wouldn’t even try to mod unreal itself for this is because it’s way easier to just either integrate bullet with double precision setting into ue4 plugin or make your own physics solver and double precision math lib and put them into plugin/directly in the project. If you start modding the actual ue4 codebase, it will take you forever to get the changes done due to the horrible compile times + it would make it harder to maintain the engine as you are stuck with your custom engine version as it’s not easy to update it anymore after you’ve changed almost every class in the core. With project/plugin side approach, it’s really trivial to update unreal itself and very little things would break from engine version to another.