GPU-CPU Balanced Cell Projection

In this section, I modify the view independent cell projection algorithm of Weiler, Kraus, and Ertl [98] by removing one constraint: view independence. In order for the projection to be view independent, the algorithm must perform all the calculation on the graphics card. Furthermore, the algorithm must pass all the data required for the calculation to the graphics card. Because I plan to use optical models that are view dependent, having a view independent cell projection is not helpful.

I modify Weiler, Kraus, and Ertl's algorithm by moving some of the calculations from the vertex program back into the CPU. The changes I make have minimal effect on either the CPU or GPU running time. Rather, my changes minimize the amount of memory that we must transfer from the CPU to the GPU.

Let us compare the differences between VICP-ProjectTet and Balanced-ProjectTet. First, the balanced cell projection calls IntersectBackFace here on the CPU rather than in the vertex program. Thus, rather than send the vectors for $P_v$ and $\vec{g}$, we send the two scalars $d$ and ${s}_{\,\mathrm{b}}$. Second, the balanced cell projection sends vertex information 4 times rather than 12. To do this, I use an indexing mode that allows me to reuse vertex information among faces. Vertex arrays and the vertex buffer object extension support indexing mode. The reason we need to send the vertex information twelve times in VICP-ProjectTet and only four times in Balanced-ProjectTet becomes clear when we analyze Balanced-VertProg.

Balanced-VertProg differs from VICP-VertProg in two ways. First, the Balanced-VertProg procedure does not compute IntersectBackFace because Balanced-ProjectTet already computed it. Second, $\vec{d}$ and $\vec{s}$ are 4-vectors rather than 3-vectors. One of the values in the 4-vector corresponds to the face that the rasterizer interpolates. Thus, we know the corresponding values in $\vec{d}$ and $\vec{s}$ will be 0 and ${s}_{\,\mathrm{f}}$, respectively. However, commodity graphics hardware has redundant arithmetic units to handle 4-vectors, so the extra computation costs us nothing.

The 4-vectors $\vec{d}$ and $\vec{s}$ maintain the intersection of the viewing ray with all four faces of the tetrahedron. The four faces do not change with the face being projected, and so the indexing of the faces may remain consistent. When dealing with 3-vectors as in VICP-VertProg, the indexing of these vectors must change with each face being projected. This is why VICP-ProjectTet has to send data for twelve vertices whereas Balanced-ProjectTet has to send data for only four vertices. We thus reduce the amount of data sent to the GPU from 132 floats to 28 floats. Balanced-ProjectTet has also to send six indices, but these indices can remain constant while a sorting algorithm reorders the vertex information. Therefore, we can store them directly on the graphics card with vertex buffer objects, and we do not have to send them every frame.

Balanced-FragmentProg looks exactly like VICP-FragmentProg. The only difference is that $\vec{d}$ and $\vec{s}$ are 4-vectors instead of 3-vectors. Again, the extra entry holds the intersection for the face being projected. That entry in $\vec{d}$ will be zero, so Balanced-FragmentProg will never select it.