RenderList as Data Representation

Figure 6.3: Volumetric object representation: voxels which are relevant for rendering an object are extracted slice by slice from the volume and stored into RenderLists.

During the object extraction process, the volume is scanned slice by slice, producing for each object within the volume a distinct RenderList which is in fact an array of RenderListEntry objects, each one containing the object's voxels within a slice (figure 6.3). Note, that the original (implicit) spatial arrangement of data values within the 3D array is sacrificed for an object-aware enumeration scheme of arbitrarily arranged voxels. For each voxel it's position within the slice and a user-definable set of attributes are stored. As gradient computation from extracted voxels is not trivial due to the lack of connectivity information within the RenderList structure, gradient direction and gradient magnitude are usually precomputed during the extraction step and stored with the RenderList. Typically, also the original data values (one or more scalar values) are added as attributes here. All the attributes of a voxel are stored in separate arrays, the RenderListEntry just stores information which is required for rendering:

• object-level opacity for clipped and non-clipped voxels
• look-up tables for clipped and non-clipped voxels
• specification of rendering mode for clipped and non-clipped voxels
• a reference to an array which contains a renderable representation of voxel data (derived from voxel attributes). Within this array, voxels between first and firstClipped belong to the non-clipped part of an object, voxels between firstClipped and lastInSlice belong to the clipped part. Only voxels between first and last, respective firstClipped and lastClipped have to be rendered, voxels between last and firstClipped, and lastClipped and lastInSlice have been identified by the optimizer-thread as non-contributing for the current transfer function setting and are not rendered.

The ``blocking'' of voxels into non-contributing, clipped, etc., as shown in figure 6.3, is achieved by simply reordering the voxels within RenderListEntrys during clipping and optimization operations. This may be done, as the voxel order within a slice is not relevant for the fast shear/warp algorithm in use for rendering.

For fast rendering, position and attribute information for each voxel is fitted into a single 32 bit integer. The $x$ and $y$ coordinates of the voxel are stored using 8 bit each, the $z$ coordinate is identical for all voxels within a RenderListEntry as they are all extracted from the same slice of the volume and thus it is stored just once. Using just 8 bits per coordinate limits the maximum extent of an object to $256^3$ voxels. Larger volumes and objects are internally split into $256^3$ pieces and the missing high bits of the coordinates are encoded into an offset, which is also stored once at the RenderListEntry. The remaining 16 bits are typically split into a 12 bit and a 4 bit field which store the data attributes used for rendering as previously described. This ``renderable'' voxel representation is attached as an additional array to each RenderListEntry. Reordering of voxel data during clipping and optimization has to be performed synchronously on all attribute arrays as well as on the derived renderable data array.

Although the common coordinate stored at the RenderListEntry for all voxels is referred to as $z$ for reasons of simplicity, in fact three copies of the data and thus three RenderLists are required for the shear/warp algorithm - each one grouped and sorted by one of the three coordinates.

Although the limitation to two voxel attributes with an overall of 16 bit for rendering is clearly a limitation with respect to flexibility and accuracy, the compact representation is perfectly suited for very fast rendering. Together with the ability to re-order voxels within a RenderListEntry the rendering process turns into a ``streaming'' of sequential chunks of voxels - an optimal scenario for caching and prefetching as implemented by recent processors. The problem of the low bit resolution of data attributes for rendering can be addressed by applying intelligent remapping when copying voxel attribute data into it's renderable form: instead of clipping low bits of an attribute, a logarithmic remapping can be performed, or a certain sub-range of attribute values can be mapped to the range of values available for rendering.

mailto:mroz@cg.tuwien.ac.at.