II. Positioning---Chapter 5----Boundaries and Clipping

Boundaries and Clipping

If you recall back to the Perspective projection tutorial, we choose to use some special hardware in the graphics chip to do the final division of the W coordinate, rather than doing the entire perspective projection ourselves in the vertex shader. At the time, it was promised that we would see why this is hardware functionality rather than something the shader does.

Let us review the full math operation we are computing here:

Equation 5.1. Perspective Computation

R is the perspective projected position, P is the camera-space position, E_z is the Z-position of the eye relative to the plane (assumed to be -1), and P_z is the camera-space Z position.

One question you should always ask when dealing with equations is this: can it divide by zero? And this equation certainly can; if the camera-space position of any vertex is ever exactly 0, then we have a problem.

This is where clip-space comes in to save the day. See, until we actually do the divide, everything is fine. A 4-dimensional vector that will be divided by the fourth component but has not yet is still valid, even if the fourth component is zero. This kind of coordinate system is called ahomogeneous coordinate system. It is a way of talking about things that you could not talk about in a normal, 3D coordinate system. Like dividing by zero, which in visual terms refers to coordinates at infinity.

This is all nice theory, but we still know that the clip-space positions need to be divided by their W coordinate. So how to we get around this problem?

First, we know that a W of zero means that the camera-space Z position of the point was zero as well. We also know that this point must lie outside of the viable region for camera space. That is because of the camera Z range: camera zNear must be strictly greater than zero. Thus any point with a camera Z value of 0 must be in front of the zNear, and therefore outside of the visible world.

Since the vertex coordinate is not going to be visible anyway, why bother drawing it and dividing by that pesky 0? Well, because that vertex happens to be part of a triangle, and if part of the triangle is visible, we have to draw it.

But we do not have to draw all of it.

Clipping is the process of taking a triangle and breaking it up into smaller triangles, such that only the part of the original triangle that is within the viewable region remains. This may generate only one triangle, or it may generate multiple triangles.

Any vertex attributes associated with that vertex are interpolated (based on the vertex shader's interpolation qualifiers) to determine the relative value of the post-clipping vertex.

As you might have guessed, clipping happens in clip space, not NDC space. Hence the name. Since clip-space is a homogeneous coordinate system, we do not have to worry about those pesky zeros. Unfortunately, because homogeneous spaces are not easy to draw, we cannot show you what it would look like. But we can show you what it would look like if you clipped in camera space, in 2D:

Figure 5.6. Triangle Clipping

To see the results of clipping in action, run the Vertex Clipping tutorial. It is the same as the one for depth buffering, except one object has been moved very close to the zNear plane. Close enough that part of it is beyond the zNear and therefore is not part of the viewable area:

Figure 5.7. Near Plane Clipping

A Word on Clipping Performance

We have phrased the discussion of clipping as a way to avoid dividing by zero for good reason. The OpenGL specification states that clipping must be done against all sides of the viewable region. And it certainly appears that way; if you move objects far enough away that they overlap with zFar, then you will not see the objects.

You can also see apparent clipping with objects against the four sides of the view frustum. To see this, you would need to modify the viewport with glViewport, so that only part of the window is being rendered to. If you move objects to the edge of the viewport, you will find that part of them does not get rendered outside this region.

So clipping is happening all the time?

Of course not. Clipping takes triangles and breaks them into pieces using 4-dimensional homogeneous mathematics. One triangle can be broken up into several; depending on the location of the triangle, you can get quite a few different pieces. The simple act of turning one triangle into several is hard and time consuming.

So, if OpenGL states that this must happen, but supposedly OpenGL-compliant hardware does not do it, then what's going on?

Consider this: if we had not told you just now that the hardware does not do clipping most of the time, could you tell? No. And that's the point: OpenGL specifies apparent behavior; the spec does not care if you actually do vertex clipping or not. All the spec cares about is that the user cannot tell the difference in terms of the output.

That's how hardware can get away with the early-z optimization mentioned before; the OpenGL spec says that the depth test must happen after the fragment program executes. But if the fragment shader does not modify the depth, then would you be able to tell the difference if it did the depth test before the fragment shader? No; if it passes, it would have passed either way, and the same goes for failing.

Instead of clipping, the hardware usually just lets the triangles go through if part of the triangle is within the visible region. It generates fragments from those triangles, and if a fragment is outside of the visible window, it is discarded before any fragment processing takes place.

Hardware usually cannot do this however, if any vertex of the triangle has a clip-space W <= zero. In terms of a perspective projection, this means that part of the triangle is fully behind the eye, rather than just behind the camera zNear plane. In these cases, clipping is much more likely to happen.

Even so, clipping only happens if the triangle is partially visible; a triangle that is entirely in front of the zNear plane is dropped entirely.

In general, you should try to avoid rendering things that will clip against the eye plane (clip-space W <= 0, or camera-space Z >= 0). You do not need to be pedantic about it; long walls and the like are fine. But, particularly for low-end hardware, a lot of clipping can really kill performance.