Large world coordinates - double precision data

[Max-om]

@runner78

Unreal would reach the limit much faster than Unity.

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

[runner78]

@stonstad

UE4 WORLD_MAX is 21km. UE 5.1 WORLD_MAX is 88,000,000 km. LWC is enabled by default in UE 5.1.

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.

[rawna]

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

[KnewK]

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

[Velctor]

@jivalenzuela

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.

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.

[jivalenzuela]

@Velctor

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.

You used a similar approach to the linked library then? Do you mean there’s no performance impact vs double, or vs single precision?

[stonstad]

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?

[jivalenzuela]

@stonstad

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

Steadily and methodically

[Quatum1000]

@jivalenzuela

Steadily and methodically

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.

[stonstad]

@jivalenzuela

Steadily and methodically

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

[bb8_1]

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.

[stonstad]

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

[cosmochristo]

@Max-om

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

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

[Max-om]

@cosmochristo

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.

[runner78]

@Max-om

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.

[Max-om]

@runner78

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

[cosmochristo]

@Max-om

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

ok, thanks for clarifying.

[cosmochristo]

@Max-om

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.

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.

[runner78]

@cosmochristo

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)

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/com.unity.render-pipelines.high-definition@17.0/manual/Camera-Relative-Rendering.html

[Max-om]

@cosmochristo

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.

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.