Mathematical Topics from 3D Graphics - 3D Math Primer for Graphics and Game Development - page 379

(0,0) is in the upper-left corner. Under these conventions, +y points up
in clip space, but down in screen space. In fact, if we continue to think
about +z pointing into the screen, then screen space actually becomes
a right-handed coordinate space, even though it's left-handed everywhere
else in DirectX. In OpenGL, the origin is in the lower left corner, and
the negation of the y-coordinate does not occur. (As already discussed, in
OpenGL, they choose a different place to introduce confusion, by flipping
the z-axis between eye space, where −z points into the screen, to clip space,
where +z points into the screen.)
Speaking of z, what happens to clip z ? In general it's used in some way
for depth buffering. A traditional method is to take the normalized depth
value clip z /clip w and store this value in the depth buffer. The precise
details depend on exactly what sort of clip values are used for clipping,
and what sort of depth values go into the depth buffer. For example, in
OpenGL, the conceptual convention is for the view frustum to contain −1 ≤
clip z /clip w ≤ +1, but this might not be optimal for depth buffering. Driver

vendors must convert from the API's conceptual conventions to whatever
is optimal for the hardware.
An alternative strategy, known as w-buffering, is to use clip w as the
depth value. In most situations clip w is simply a scaled version of the
camera-space z value; thus by using clip w in the depth buffer, each value has
a linear relationship to the viewing depth of the corresponding pixel. This
method can be attractive, especially if the depth buffer is fixed-point with
limited precision, because it spreads out the available precision more evenly.
The traditional method of storing clip z /clip w in the depth buffer results
in greatly increased precision up close, but at the expense of (sometimes
drastically) reduced precision near the far clip plane. If the depth buffer
values are stored in floating-point, this issue is much less important. Also
note that w-buffering doesn't work for orthographic projection, since an
orthographic projection matrix always outputs w = 1.
The clip w value is also not discarded. As we've said, it serves the im-
portant purpose as the denominator in the homogeneous division to nor-
malized device coordinates. But this value is also usually needed for proper
perspective-correct interpolation of texture coordinates, colors, and other
vertex-level values during rasterization.
On modern graphics APIs at the time of this writing, the conversion of
vertex coordinates from clip space to screen space is done for you. Your
vertex shader outputs coordinates in clip space. The API clips the triangles
to the view frustum and then projects the coordinates to screen space. But
that doesn't mean that you will never use the equations in this section in
your code. Quite often, we need to perform these calculations in software
for visibility testing, level-of-detail selection, and so forth.