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).

 

maybe you're interested in this:
https://web.mit.edu/tabbott/Public/quaddouble-debian/qd-2.3.4-old/docs/qd.pdf
I'v impled double-double on Burst in Unity, for full visible universe size(46 billion light year diameter) of continuous high precision coordinate, and there's no obvious performace impact on desktop CPUs. This algorighm works for single precision either(for GPU), but in my opinion, that's not necessory, because we can upload camera-relative position of meshes to GPU just for rendering-single precision position is really enough.

 

Just a friendly reminder that Unreal has supported double precision transforms (enabled by default) since April 2022. It was introduced with Unreal 5.0.

Unity, how are your plans coming along to remain technically competitive?

 

Does this refer to the 'point of return on investment'? It seems that less than 0.01% of PC games, in contrast to Android offerings, might only reach this point by the third decade, if at all.

Oh, and the gap in awaiting the 'point of return on investment' is likely to increasingly widen the divide with other 3D engines.

Edit:
And for those who don't quite grasp the concept of extended distances, the command buffers and shaders also have to go through the whole litany of 64-bit calculations. It wouldn't be pleasant to see if the textures on the objects and the vertices themselves start to swim.

 

Unreal's large world coordinate support is fantastic. It just works. How are the steady and methodical plans coming along on the Unity side? Any progress to share?

Thanks,
Shaun

 

There are ways to pack doubles as 2 floats so to calculate more precisely height(on gpu so creating procedural worlds) where distances are far away from camera keeping camera all the time at origin position(hdrp does this already(move camera to origin), also it uses a kind of logarithmic function for depth buffer which is also helpful for creating Earth size planets) - but it will require more memory on gpu side also the code will be slower.

 

Thanks, bb8. To remain relevant as an engine product, it is time for Unity to support double-precision coordinates in transforms and rendering pipelines.

 

It does seem a little crazy. Is there any doc on the design motivations behind this?

 

There is more crazy stuff going on in mono than sane stuff
Meanwhile .NET 8 is faster than ever. Jitted code is often on par with native code.

 

Jitted code is actually always native (machine) code, but the quality is far better than mono. A large part of the performance in modern .NET also comes from optimizations in the .NET library.

 

I ment handwritten native code. .NET 8 outperformance alot of handwritten native code

 

ok, thanks for clarifying.

 

To be fair, I can think of one case where there would be some benefit: if you are going to multiply two or more large numbers and then reduce them, such as in the square root of sum of squares distance formula, then converting to double beforehand will reduce the additional error from the squared floats "overflowing" the 32bit limits. Then, after the double square root put the result back into float.

I would still like to see Unitiy's design reasoning - if it is documented, implementation details and some measurements.

My alternate preference is to minimise the size of the numbers, for the most important calculations (around the observer/player), by keeping the observer at the origin (no periodic shifting) and doing everything in floats. No need to incur the casting costs of upcast-calculate-downcast and the extra memory allocation costs for the doubles.

 

HDRP does exactly that (camera relative-rendering), but positions in the scene are stored as floats and physics is also calculated in floats in worldspace.
https://docs.unity3d.com/Packages/c...on@17.0/manual/Camera-Relative-Rendering.html

 

Well mono does it for two floats so if you for example multiply two floats it will cast both to doubles multiply them and cast the result back to float. Zero gained.

 

So I am told. And the description is the same as my floating origin algorithm. However, they do not provide details of the implementation and have not acknowledged my prior work in this area. Pretty shabby really.

 

In general, yes, unless it saves on extra accuracy loss from overflow of the mantissa as I described. My example is only an isolated case of where there is some potential benefit (because you take the square root before casting the result back). As a general approach, I agree with you. So I would like to see the justification.

 

That resolution gain is so small so it's not worth it., MS JIT code have never done it what I know about, not even back in full framework times.

 

And you may be right - that it is not worth it. I would not do it either. I see it as a bandaid over a fundamentally flawed foundational design.