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?
Hi,
Unity engine itself ( transforms, physics, editor ) doesn’t support double precision. So basically our recommendation about max world size is around 50km ( ie 50.000 units )
However DOTS mathlib & Burst compiler are supporting it (ie 64bits floating numbers).
Also please note that HDRP shaders are working in “relative camera” position to minimize graphics glitches when dealing with objects far from the origin.
Double precision has a steep performance penalty so we’re unlikely to switch component width. But the DOTS team has some early ideas for supporting large, open worlds without requiring 64-bit width translation and it’s something we intend to explore over the coming year.
With the revisions to the Transform System in entities 1.0, it’s feasible for users to replace the entire Entity transform stack. So folks who want to weigh the tradeoffs between precision/performance can do so themselves.
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.
Native origin shifting could solve that and also make it work for multiplayer etc.
Indeed 
Sorry about that. What renderer pipeline are you using for your VR game? ( builtin, URP, HDRP? ). My 50.000 units assumption is in HDRP context. ( HDRP have native origin shift for rendering ). So 50.000 units should be fine in editor, when using HDRP. But this is for rendering only. You may have accuracy issues with Physics or other systems at 50.000 units
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
yes HDRP is just solving rendering issues. All other systems (including physics) will jitter much more earlier than 50km, as you mention 
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.
I’ll caveat that I haven’t profiled this change in Transform V2. This opinion is based on anecdotal (but I consider reliable) information as well as my experience doing performance programming.
While the compute latency is about the same for single vs double precision, the memory bandwidth is not, and efficiently amortizing memory costs is a cornerstone of performance programming.
I’ve heard this too, but honestly I’m inclined to believe it only after seeing some rigorous proof. I’m not in a position to test UE personally obviously.
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
Ironic is one word for 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.
Maybe, but I’m not convinced this would be predictive of the performance implication for doubling the size of Translation.
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