Nicolai Haehnle wrote:
Have you thought about what to do when the number of interpolants required for a particular render state exceeds the number that can be practically hard coded?
The only thing that isn't clear to me is whether I need to store Z (world) or Z/W (screen coordiates) in the depth buffer.
Normalized device coordinates I think.
Well, window coordinates. But these only differ from normalized device coordinates (Ndc) by a bias.
By the way, this bias is also one of the things that the user can control - especially look at glDepthRange, which is one more problem factor that we would have to deal with if we wanted to escape the need for the OpenGL Z. Compare section 2.11 Coordinate Transformation of the OpenGL spec.
BTW, just because it makes sense for OpenGL to divide Z by W (like it must do with everything else) doesn't mean that it actually DOES.
Anyhow, I'm going to implement "screen Z", which is Z/W, and I'm not going to bother to multiply by W before storing it (because that would be a lot worse). I'm going to store it in float24 format (only 15 mantissa bits this time, unless we decide to short the exponent by one bit).
I'm going to do it this way until someone comes along with a reason to dispute it.
Therein lies a problem. Since the reciprocal isn't precise (we use only 10 mantissa bits when computing it)
Hmm, I thought we had 18 bits of precision readily available. Is this a consequence of using linear interpolation for the divide?
I was also under the impression that 10 mantissa bits were used for the LUT, and the other bits were used for linear interpolation between two 18 bit values from the LUT.
I wasn't even going to bother with the interpolation. The reason is that we have a limited number of RAM blocks and they're dual ported. If we're going to properly compute every fragment (not estimate odd ones), then we have to look up two reciprocals every cycle.
Now, there ARE two extra bits. Our manitssas are 16 bits, but the RAMs hold 18. If there's anything useful we can do with the 6 extra bits from M and the 2 extra bits from the table, then I'm open for suggestions!
This should actually yield a pretty good result, I think Nicolas Caspens was the one who contributed most of this in the original discussion (obviously, I may be mistaken, so please don't kill me if I got the attribution wrong). In any case, with linear interpolation the precision should be *much* better than 10 bits.
We need a different solution here. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
