This is similar to the Far Lands[0] in old versions of Minecraft. Woof![1]
Emulating double precision on the GPU to render large worlds
31–40 of 66 posts
Re: Emulating double precision on the GPU to render large worlds
#32Also see the twofloat crate in Rust, which uses a pair of f64's to give double the number of significant digits as a standard f64. The linked docs point to a number of academic papers on the subject. [2f]: https://docs.rs/twofloat/latest/twofloat/
For general computational applications (i.e. not for special graphics cases), implementing double-precision operations using single-precision operations is considerably more complicated than implementing quadruple-precision operations using double-precision operations. The reason is that it is not enough to extend the precision of the 32-bit FP numbers. The exponent range must also be extended. The standard double-pr…
It's interesting that you find the idea of "only" being able to represent numbers as small as 10^-38 and as large as 10^38 as having "very small exponent."
In deep learning, this is huge! If you have numbers this big, then something is definitely already wrong. If you have numbers that small, then you definitely don't care.
I wonder if deep learning will save us from poorly conditioned linear algebra too.
Re: Emulating double precision on the GPU to render large worlds
#33I’ve always wanted to see a game that used nanometer scale int64 positions. That’d give 11.5 million miles of nanometer scale precision. I imagine there are terrible problems with this. But I’ve never tried it so I don’t know what they are.
Back to Godot, I thought the answer would be to precompute the ModelView matrix on the CPU. Object -> World -> Camera is a “large” transformation. But the final Object -> Camera transform is “small”. I’m sure there’s a reason this doesn’t work, but I forget it.
Unreal 5 changes to doubles everywhere for large world coordinates. I wonder what fun issues they had to solve?
Re: Emulating double precision on the GPU to render large worlds
#34"Then, when doing the model to camera space transformation instead of calculating the MODELVIEW_MATRIX, we separate the transformation into individual components and do the rotation/scale separately from the translation." That's the core idea here. A bit more detail would help. Is that done in the GPU? Is that extra work for every vertex? Does it slow down rendering because the GPU's 4x4 matrix multiplication hardwar…
This looks like the PR: https://github.com/godotengine/godot/pull/66178
Ah. Thanks.
This is overkill for what I'm doing. They want to zoom way out and see planet-sized objects. I just have a big flat world a few hundred km across. So the usual "offset the render origin" approach will work. I don't have to update on every frame, only when the viewpoint moves a few hundred meters.
Re: Emulating double precision on the GPU to render large worlds
#35A better way to solve this problem is to move the world around the origin instead. Just like you had to with OpenGL 1! Really half-floats are more interesting, saving 50% memory on the GPU for mesh data. You could imagine using half-floats for animations too! Then we could have the debate about fixed point vs. floating. Why we choose to use a precision that deteriorates with distance is descriptive of our short sight…
Minecraft works like this. The camera is the world origin when rendering.
Re: Emulating double precision on the GPU to render large worlds
#36This is similar to the solution we used in Vega Strike https://www.vega-strike.org/ detailed here https://graphics.stanford.edu/~danielh//classes/VegaStrikeBl...
How old is Vega Strike! The Portability page is talking about TNT2 and 3DFX Voodoo!
Re: Emulating double precision on the GPU to render large worlds
#37This is neat, but it's often a lot simpler to just render each object relative to the camera instead. Which can be as simple as subtracting the camera's position from the world position right before rendering.
Re: Emulating double precision on the GPU to render large worlds
#38Feels kinda weird to be using a data type that gets less precise, the further you move out from the center. Unless the world is infinite (which it sometimes is), isn't it a bit of a waste of precision? I kinda doubt you need nanometer precision, but only within 1 meter from the center. I get that gpus have existing floating point hardware to accelerate stuff. But with more open worlds being a thing. Wouldn't it make…
Integer definitely seems like the right fit here. The precision is translationally invariant, which is the property you want for a Cartesian coordinate system.
Re: Emulating double precision on the GPU to render large worlds
#39A better way to solve this problem is to move the world around the origin instead. Just like you had to with OpenGL 1! Really half-floats are more interesting, saving 50% memory on the GPU for mesh data. You could imagine using half-floats for animations too! Then we could have the debate about fixed point vs. floating. Why we choose to use a precision that deteriorates with distance is descriptive of our short sight…
Minecraft works like this. The camera is the world origin when rendering.
It's easy when you have chunks.
But really all large worlds need chunking.
The real reason AAA never got into user generated content, is they have staff to create linear worlds.
After this economic crisis, linear content will more or less disappear.
Why listen to a hardcoded story when you can make your own just like in real life?
Scarcity is the key, one UGC networked world will make time valuable.
Re: Emulating double precision on the GPU to render large worlds
#40Since to-scale solar systems are mentioned in the article, it may be worth talking briefly about Outer Wilds. Outer Wilds is a wonderful game built in Unity and comes with its own solar system. Things are quite a bit smaller than in the real world, but I suppose everything is still large enough for floating point precision to be a potential issue. The developers have solved this by making the player the origin instead. Everything else is constantly shifted around to accommodate for the fact that the player is at the center. This works perfectly in normal gameplay, and is only noticeable when flying away a great distance from the game's solar system (nothing's stopping you), at which point you will see the planets and other astral bodies jiggling around on the map.