11–20 of 66 posts
Also 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/
I was taught that MV/MVP should be calculated CPU-side per-model, and that doing it in the vertex shader is wasteful. Is that advice out of date?
Is there a “lossy compression” benefit to describing space with floats?
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 hardware can't do it?
I actually have to implement this soon in something I'm doing. So I really want to know.
I 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.
Also 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/
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-precision numbers have an exponent range that is large enough to make underflow and overflow very unlikely in most algorithms. With the very small exponent range of FP32 numbers, underflow and overflow is very likely and this must be corrected in any double precision implementation.
So it is not enough to use two FP32 numbers to represent one FP64 number. One must use either a third number for the exponent, or at least one of the two 32-bit numbers must be integer and partitioned into exponent and significand parts.
Both approaches will lead to much more complex algorithms and a much worse speed ratio for FP64 implemented with FP32 vs. FP128 implemented with FP64.
Why not describe the world space in integers? Where 1 is the Planck length of the simulation? Is there a “lossy compression” benefit to describing space with floats?
While most GPUs support FP64, unless you pay for the really high-end scientific computing models, you're typically getting 1/32nd rate compared to FP32 performance. Even your shiny new RTX 4090 runs FP64 at 1/64th rate.
2xFP32 for most basic operations can be 1/4th the rate of FP32. It is quite often the superior solution compared to using the FP64 support provided in GPU languages.
Earlier quoted context omitted.
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 Kerbal, isn't it easier and more accurate to set the origin on the craft being simulated? Why use world space?
Earlier quoted context omitted.
For Kerbal, isn't it easier and more accurate to set the origin on the craft being simulated? Why use world space?
That is what is done in KSP ever since planets beyond the Mun were added - on every frame, the coordinate system is re-centered on the active vehicle. The problem that still remains is mainly in trajectory calculations - you might have an intercept with a planet way on the other side of the solar system, and you can generally see that the predicted trajectory does not pass through the encounter point in these cases d…
I wonder whether they should just use rational numbers for those?