Emulating double precision on the GPU to render large worlds
godotengine.org
Emulating double precision on the GPU to render large worlds
1–10 of 66 posts
Re: Emulating double precision on the GPU to render large worlds
#2I wonder if there isn’t another solution here. It seems like the issue is due to large translations? Presumably your view frustrum is small enough that single precision floats are sufficient for the entire range, so couldn’t you just add subtract some offset when calculating the translation matrix for both your view and the model translation? I suppose this may result in instances where you need to recalculate the translation matrix for some visible meshes, but that seems less complicated that trying to increase the on-GPU precision?
Re: Emulating double precision on the GPU to render large worlds
#3Also 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.
Re: Emulating double precision on the GPU to render large worlds
#4I wonder if there isn’t another solution here. It seems like the issue is due to large translations? Presumably your view frustrum is small enough that single precision floats are sufficient for the entire range, so couldn’t you just add subtract some offset when calculating the translation matrix for both your view and the model translation? I suppose this may result in instances where you need to recalculate the tr…
Yeah, I agree that double precision makes sense for modeling a very large system in data, but I've never bought the need for double precision when it comes to rendering a small subsection of it. Unless you have an incredibly high resolution display, single precision should be enough.
Re: Emulating double precision on the GPU to render large worlds
#5This is similar to the solution we used in Vega Strike https://www.vega-strike.org/ detailed here https://graphics.stanford.edu/~danielh//classes/VegaStrikeBl...
Re: Emulating double precision on the GPU to render large worlds
#6I wonder if there isn’t another solution here. It seems like the issue is due to large translations? Presumably your view frustrum is small enough that single precision floats are sufficient for the entire range, so couldn’t you just add subtract some offset when calculating the translation matrix for both your view and the model translation? I suppose this may result in instances where you need to recalculate the tr…
Yeah, I agree that double precision makes sense for modeling a very large system in data, but I've never bought the need for double precision when it comes to rendering a small subsection of it. Unless you have an incredibly high resolution display, single precision should be enough.
You are correct that you can render a small section of a very large data set by re-centering your origin of the data sent to GPU around a small subsection. So, now the question becomes "But, do you really want to?"
> Overall, we are quite happy with how this solution turned out. We think it is the closest to "just works" that we can get.
I think this is the crux of it. The performance penalty is very small and the convenience factor is very high.
But, now I want to know what they do with the positions of lights in the scene... Likely transformed to view space regardless for deferred rendering, I'd guess.
Re: Emulating double precision on the GPU to render large worlds
#7I wonder if there isn’t another solution here. It seems like the issue is due to large translations? Presumably your view frustrum is small enough that single precision floats are sufficient for the entire range, so couldn’t you just add subtract some offset when calculating the translation matrix for both your view and the model translation? I suppose this may result in instances where you need to recalculate the tr…
Double precision makes sense to me for world space interactions wherein participants are very far apart.
Something like Kerbal space program is an example where I'd probably break out the doubles.
For final projection, clipping, z buffering, etc., single precision is almost certainly enough.
Re: Emulating double precision on the GPU to render large worlds
#8I wonder if there isn’t another solution here. It seems like the issue is due to large translations? Presumably your view frustrum is small enough that single precision floats are sufficient for the entire range, so couldn’t you just add subtract some offset when calculating the translation matrix for both your view and the model translation? I suppose this may result in instances where you need to recalculate the tr…
That's a common approach to deal with calculations in aerospace and automotive applications. You choose an arbitrary origin point nearby your operational area, and work in vectors relative to that. It's often referred to as "NED", or North-East-Down. Then, you just need to be able to convert between different frames of references as needed.
Re: Emulating double precision on the GPU to render large worlds
#9The book "3D Engine Design for Virtual Globes" contains a bunch of these shader tricks with different levels of precision (e.g. 1cm across the whole solar system etc.)
Re: Emulating double precision on the GPU to render large worlds
#10I wonder if there isn’t another solution here. It seems like the issue is due to large translations? Presumably your view frustrum is small enough that single precision floats are sufficient for the entire range, so couldn’t you just add subtract some offset when calculating the translation matrix for both your view and the model translation? I suppose this may result in instances where you need to recalculate the tr…
Double precision makes sense to me for world space interactions wherein participants are very far apart. Something like Kerbal space program is an example where I'd probably break out the doubles. For final projection, clipping, z buffering, etc., single precision is almost certainly enough.
> For final projection, clipping, z buffering, etc., single precision is almost certainly enough.
If you do this in the GPU then you would need it to handle double precision data.