On Tuesday 01 February 2005 18:19, Daniel Phillips wrote:
> On Tuesday 01 February 2005 11:54, Timothy Miller wrote:
> > I've decided that I'm going to add the Z into the rasterizer.
> 
> I hope it's only a temporary decision.  The payoff for working out all 
> the little problems with using W instead of Z is pretty big.  If 
> there's an extra interpolant in the pipeline I'd far rather see it used 
> for, say, color or alpha than Z.

Why is this payoff so big, anyway?

Note that an additional "normal" (i.e. color or texture) interpolant would 
be a lot more expensive than Z.

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

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

cu,
Nicolai

Attachment: pgpswZt8dr17D.pgp
Description: PGP signature

_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)

Reply via email to