View Full Version : Z-buffer transfering and clipping. there are many questions. ...?

03-21-2001, 05:17 AM
It's said the projection matrix in OpenGl uses the following equation to transfer Z value between [0,1]:
z' = (-(f+n)/(f-n))*z - (2fn/(f-n))*w.

I don't know what the "w" means. Why there are four parameters in eye coordinates, that is (xe, ye, ze, we).

And also, according to the above eq., z'=0 when z=n, and z'=1 when z=f? I cann't work out it.

03-21-2001, 03:27 PM
Yukon Ho,

the w you speak of is the magic homogeneous coordinate factor. <takes deep breath, and prepares to lecture about projective geometry>

I can't think of a really cool way of explaining the homogeneous coordinate... so, I'll say this:

if you have a cartesian coordinate (a, b, c), then the cartesian coordinate is (d, e, f, g) s.t. a=d/g, b=e/g and c=f/g

a trivial example is to set g=1 and then d=a, e=b and f=c.

an example. all of these coordiantes are EQUIVILENT:

(1, 2, 3) (cartesian)
(1, 2, 3, 1) (homogeneous)
(2, 4, 6, 2) (h)
(10, 20, 30, 10) (h)

and so on, ad neuseum. okay, you think, what if w=0? well, this is also a valid homogeous coordinate, but it ISN'T a valid cartesian coordiniate. such coordinates are said to be point/lines/planes/hyperplanes/etc at infinity. The fabled "vanishing point" that artists speak of with revered tones is a point at infinity; it can't be expressed in cartesian coordinates, but it DOES have a corresponding homogeneous coordinate. The set of all vanishing points defines the LINE of infinity, or (as you'd see it), the horizon. Yep, there's even a plane of infinity, which is the set of all horizons... and so on and so on. Homeogeous coordinates in the realm of projective geoemtry extend to n-spaces, so you have hyperplanes (sets of planes) and n-spaces and so on. but, that's beyond the scope of this email.

so, suffice to say: w is a funky homogeous coordinate. its there to make the maths easier for opengl.

your second point: yep, the z-buffer range is from 0..1 which is a map to the near..far clip planes. its done like that because the z-buffer doesn't have unlimited precision.


03-21-2001, 09:50 PM
Well, thanks for your reply.

But how can know the current 'w' value used by OpenGl. Can I assume it as 1.0?

Also, the TRUE z value is inverse of the equation:
z=-(f-n)/(f+n)*z' - 2fn/(f+n)*w,
where z' is between [0,1].
Is that right?

03-21-2001, 10:43 PM
the "current" w value? er, it depends on what vector you're talking about. the short answer is: you don't, and you really don't care... (unless you're talking about some morbidly complicated and pathological case which i'm not thinking about...)

the story goes like this:

you create some vertex with the glVertex3? command, specififying some cartesian point in 3-space:

glVertex3f(x, y, z);

since opengl wants to deal only with homogeneous coordinates, it converts it into a homogeneous coordinate.. many ways to do this, like i said in the previous post, and it doesn't matter which way is used. lets say, for arguments sake, that it turns [x,y,z] -> [x,y,z,1] (==v)
So, opengl internally stores this new homogeneous coordinate and starts playing with it. if you have some arbitrary tranform matrix M, then the Mv is some NEW vector with some undeterminate w value. well, it IS determinant, but it depends on the fourth row of M and v. The short answer is: it is very VERY unlikley that w will ==1 in the vector Mv. does this matter? not at all... 'cause as i explained above, to convert back to carteisn coordinates we divde the first three elements by w.

so, in summary: w may start OFF as 1.0 when opengl turns your cartesian coordinates into homogeneous coordinates; and certainly becomes 1.0 again when you convert homogeneous back to cartesian coordinates, but inbetweem this, w may be some arbitrary value.

why do you want to know when w is not == 1.0?