Graphics Reference
In-Depth Information
3
4
Tested once with
θ
12
And twice with
θ
6
1
57
θ:
θθθ
1:
2:
3:
4:
5:
6:
7:
8:
9:
9
1
1
θ
1
θ
1
θ
Ray grid with queued rays
Ray links
Figure 2.8.
Intersection testing with one triangle using the ray grid. Ray grid cells
are marked in the colors of the rays enqueued. Voxelization of the light-blue triangle
generates the blue-framed voxel fragments. A lookup in the array of ray links returns
both rays in one cell and only the yellow ray in another cell.
2.4.3 Precise Intersection Testing
After the ray grid has been constructed, we have direct access to all rays in-
tersecting a particular cell just by indexing into a volume texture using the cell
coordinates. In order to compute precise ray-triangle intersections with all trian-
gles in the scene, we simply re-voxelize the scene into the ray grid as described
in Section 2.4.1: For every fragment generated by conservative rasterization, we
iterate over all cells in the corresponding voxel column that are touched by the
respective triangle. For each cell, we check for intersection with all rays that have
been enqueued there. Figure 2.8 shows an example.
Whenever a ray-triangle intersection is detected, the intersection information
of the corresponding ray has to be updated. If the new intersection is closer
than a previous intersection, the ray intersection information is locked, triangle
attributes are interpolated, hit data is stored, and finally the closest distance
is updated. If a thread finds the intersection information locked by another
thread, it temporarily skips ray update and re-checks the ray state in a subsequent
iteration (see Listing 2.1).
Ray hit information.
Our ray hit information records consist of the distance, nor-
mal, and color(s) of each ray's current closest hit point. The records are stored
in an array parallel to that storing the ray descriptions and may thus be indexed
by ray links.
Apart from the distance attribute, these attributes may be replaced or ex-
tended freely to suit any rendering engine's need. We store typical G-buffer
information to allow for simple deferred shading as described in Section 2.4.6.
To allow for atomic updating and synchronization with minimal memory over-
head, we reuse the distance attribute to mark records locked. A negative sign
indicates that the record is locked, while the absolute value of the attribute
