Proposed Graphics Hardware Extension

Commodity graphics hardware supports blending operations that enable translucent polygons. Thus, a naïve approach to rendering translucent volumes might be simply to render the faces that make up the model of the volume as translucent polygons. However, the difference between rendering a translucent solid object versus the translucent surfaces of an object is subtle but important. Getting it wrong can lead to significant artifacts as shown in Figure 1.4.

Figure 1.4: Different renderings of two hexahedron cells. The image on the left is generated by rendering the faces as translucent polygons. The image on the right is a true rendering of a solid volume.

Hollow cells with translucent faces.	Solid, translucent cells.

Figure 1.5: Demonstration of light transport through faces versus light transport through solids. The material properties are homogeneous throughout the faces or solid. The attenuation and emission of light is constant through the faces but varies based on the thickness of the solid.

(a) Light transport through a hollow triangle with translucent edges.

(b) Light transport through a solid, translucent triangle.

Figure 1.5 demonstrates in two dimensions why face rendering is different from solid rendering. We can easily extrude the triangles to 3D prisms for an equally valid demonstration in three dimensions. When rendering only faces, as shown in Figure 1.5(a), each ray of light passing through the triangle crosses exactly two faces of the triangle. The result is that the contribution of the triangle is consistent throughout its projection on the viewing plane.

In contrast, when rendering solids, as shown in Figure 1.5(b), light must pass through more of the solid at its thickest parts. Therefore, the contribution of the triangle is much greater where it is thick and negligible where the corners taper off. The result is a nonlinear change in color across the viewing plane. I shall discuss the light transport through volumes in detail in Chapter 1.

Given the interest in volumetric rendering, can we modify the popular graphics pipeline to render such objects? Surprisingly, yes. For roughly a decade, applications have used texture hardware to render rectilinear volumes [6,12,106] while others have used polygon rendering hardware to speed up the rendering of unstructured tetrahedra [86]. More recently, King, Wittenbrink, and Wolters [45] proposed (but never implemented) a graphics pipeline architecture capable of rendering translucent tetrahedra. A year later, both Wylie [110] and Weiler [98,100], each with their respective colleagues, used commodity graphics hardware with programmable shaders to render tetrahedra directly in the pipeline.

Figure 1.6: The standard graphics pipeline.

Figure 1.6 shows a simplified diagram of the standard graphics pipeline. Almost all commodity 3D graphics hardware today implements this pipeline.¹ At the left, vertices of primitives (points, lines, and polygons) enter the pipeline. Each vertex has associated with it several properties such as position, material, and texture coordinates. The first unit of the pipeline transforms, lights, and clips each vertex independently. The second unit assembles the transformed vertices into primitives and rasterizes them. That is, it projects the primitives onto the viewing plane and samples them. We call the samples generated fragments. Fragments are like vertices in that they carry along information such as color and texture coordinates. The next unit independently applies the final color to each fragment. The final unit blends the results into the appropriate pixel of the frame buffer, a rectangular array storing color, depth, and other information of an image.

As can be seen, we can split operations into two major categories: geometric processing, which determines which primitives are intersected by each viewing ray, and fragment processing, which assembles material properties of intersected primitives along a ray to determine the final color of a pixel. Until recently, this pipeline was fixed. Fortunately, the latest releases of graphics cards have flexible programmable units for both geometric and fragment processing [59,61,66,77].

The tasks of volume rendering can also be divided into geometric and fragment processing. Previous work [45,98,110] has shown that the geometric processing for 2D primitives needs to be tweaked little to support 3D primitives. The fragment processing of 2D and 3D primitives also can be similar, but the computation for 3D primitives is significantly greater. The color computation of a ray segment through a 3D cell must take into account color and opacity changes throughout the segment and integrate all these values. Consequently, most implementations perform a rough approximation rather than perform the actual integration.