On Tuesday 01 February 2005 16:59, Timothy Miller wrote:
> Nicolai Haehnle wrote:
> > Orthographic means that there is no perspective foreshortening (sp?). 
> > Everything that is parallel in world coordinates will also be parallel 
on 
> > the screen, and all lines that have the same length in world coordinates 
> > will also have the same length in screen coordinates.
> > This mode of projection is essential for everything related to 2D 
graphics, 
> > and it is often a useful mode to work in in modelling programs - think 
of 
> > building the model of a house which has many parallel planes (unless 
you're 
> > Hundertwasser, that is).
> > 
> > Since parallels and lengths are retained in the projection, there is no 
> > perspective correction going on (actually, the perspective correction 
just 
> > vanishes because both the OpenGL W and the W in the software model end 
up 
> > as 1) - but you obviously still want to use a depth buffer.
> > 
> > This is where your assumption that Z and W can be easily interconverted 
> > using a fixed formula simply breaks down.
> 
> Huh... you make a good point.  I hadn't thought of that.  Well, I guess 
> it's good that we catch such things now rather than when it's too late, 
eh?
> 
> Anyone got suggestions?  Does Z need to be computed separately?  Can we 
> just "turn off" W divide (but still use it for depth)?

Anybody else who thinks about this should consider this: I chose 
orthographic projection as the example in my earlier mail because it is 
both easy on the imagination and easy on the math. But there are more 
tricks that one can play with Z and W within OpenGL (using the OpenGL 
meaning of Z and W here), for example projections using a far plane at 
infinity. This technique is described in e.g.

http://www.gamasutra.com/features/20021011/lengyel_02.htm

In particular, look at the normal OpenGL projection matrix P, and the 
modified matrix P_\inf. Note that W is calculated as the same value in both 
cases, however Z is not. This is why problems are very likely occur, and I 
don't believe this can be fixed in the current software model without 
adding a Z interpolant in the sense that OpenGL uses it.

I obviously don't know how the hardware works internally, but consider this: 
Maybe I missed something, but I believe the current "W" in the software 
model will only be used for the perspective divide. So while the additional 
interpolant is necessary, a) you don't need to multiply this interpolant 
with 1/W (because Z is linear in screen space) and b) you don't need to 
keep both W and Z around in later stages of the pipeline, so the number of 
registers you have to shift along stays the same (of course I might eat my 
words later when it turns out that this assessment was incorrect, but...).

cu,
Nicolai

Attachment: pgpG8rm3t46Ov.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