Resolved Large world coordinates - double precision data

Will Unity - and especially dots part of it - have support for large world coordinates(meaning support for double precision data) - like your main competitor game engines already have?

 

I just want to highlight that 50km is not practible with single precision floats. I notice jitter only 2km away from origin in our first person VR game.

Native origin shifting could solve that and also make it work for multiplayer etc.

 

I'm on built in. But, tried a POC on HDRP because we want to go open world for next title. It's a little better but not alot still jitter i guess from physics. I'm on Physx though.

Edit: still far from 50k though. I could observe jitter at around 2k

 

Can you please elaborate more on this penalty? Unreal passes two single precision vectors instead of one, and they assert that performance impact across CPU/GPU is minimal.

 

Ironic how mono JITed code typecasts every float to a double before operating on it and then typecast back to float and loses that precision. So it roundstrip over double without gaining and benefit from it

 

In a microbenchmark test specific to Transform.Position I can certainly understand memory bandwidth doubling when comparing a single Vector3 to double Vector3s...

But in a real-world test with a scene containing 2500 transforms, is GPU bandwidth *meaningfully* impacted by passing an additional Vector3 parameter to the default shader for each batched call?

I wonder if the impact was sufficiently small that Epic felt it was a worthwhile change. I'm not a performance programmer. I'm trying to better understand Unity's thinking.

I am tempted to build a prototype of Unreal's implementation and measure a scene with thousands of game objects passing an additional Vector3 to the default shader. I'm willing to wager that impact to FPS is negligible, or at minimum not meaningful.

 

Why not? At the place I used to work in, our R&D team always consistently investigate and benchmark with all of the competitor's product, not just our biggest one.

 

I don't know, they have data from Fortnite (In house by Epic), FF15, FF16 (Square Enix), new Witcher, new Cyberpunk (CDPR), all confirmed to use Unreal Engine 5, and they are all large scale open world games.

But hey I still don't think its enough evidence to say they have done their homework, considered development cost, time, nor done any performance impact comparison between all implementations to arrive at the final decision.

 

I wouldn't call Fortnite a large scale open world game, I once read about only 2.6 km x 2.6 km

 

The point being made is that Unreal has, as a matter of fact, shipped titles with large world coordinate support (the topic of this thread) and it runs fine on consoles.

 

FF15 has a map size of 1800km2 that is about 42km x 42km. That would still be within the max recommended size of HDRP. (see post above). The point is that many large open world games still basically don't need origin shifting or 64bit coordinates.
Unreal uses cm as a unit, but I don't know if that's only in the editor or also under the hood, so Unreal would reach the limit much faster than Unity.

 

UE4 WORLD_MAX is 21km. UE 5.1 WORLD_MAX is 88,000,000 km. LWC is enabled by default in UE 5.1.
Large World Coordinates in Unreal Engine 5 | Unreal Engine 5.1 Documentation

 

1000,001 1000 meters and one millimeter in meters
100000,1 1000 meters and one millimeter with same number of digits in centimeters.

 

Still way too small for KSP

UE5 uses a tiling system, I don't know exactly how it's implemented, but on the GPU side UE5 still works with single precision.

 

FF15 uses luminous engine.
FF16 started with unreal, then they moved to a modified version of FF14 engine.

 

If Minecraft can do it Unity should be able to do it too. I'm using ArcGIS in Unity that shows the whole world in scale. The precision jitter is definitely a problem. Luckily ArcGIS does provide a Rebasing component that updates the origin to the Camera every now and then to avoid the issue (like floating origin).