By storing just relevant voxels in the RenderList structure, neighborhood information, which is implicitly present in a conventional volume representation, is not available. It is not trivial to obtain spatial neighbors of a voxel from the list to perform interpolation. This means, that voxels have to be treated individually, performing splatting (or something similar) for projection.
The fastest software-based rendering method is shear/warp projection. Voxels from the RenderList can be efficiently projected onto the base plane using look-up tables for determining projected positions. To maximize performance, nearest-neighbor interpolation is used during projection of voxels. Each voxel is projected onto the center of exactly one pixel of the base plane. The voxel affects only the value of the pixel it has been projected to. The calculation of the contribution depends on the compositing mode used. If optical properties of voxels are stored at the corresponding RenderListEntrys (figure 3.2), it is easily possible to assign different parameters to each group of voxels. In practice, all RenderListEntrys which store voxels of the same object will have identical parameters, like color and opacity transfer functions.
Projection is performed, by merging the RenderLists of all distinct objects, and sequentially processing all RenderListEntrys of the joint RenderList which represents the volume. Within each RenderListEntry all voxels are also projected sequentially. The strictly sequential order of voxel projection which does not depend on the viewing direction leads to an excellent cache-efficiency of this approach. In contrast, traversal of the usual, spatially ordered volumes, suffers from severe performance degradation due to frequent cache misses, when viewing the volume from certain directions. Although there are methods to reduce this effect [51] by reordering the volume into bricks, they do not reach the effectivity of the presented, purely sequential approach.
If rendering parameters are changed, some of the extracted voxels may become irrelevant for the visualization. An effective way to skip them during rendering without much effort, is to reorder voxels belonging to each RenderListEntry in a way, that irrelevant voxels are moved to the end of the group. This allows to render the block of relevant voxels at the beginning of the group, and to skip the remaining, irrelevant ones efficiently. Clipping or removal of parts of the volume can be done in a similar way. If voxels which are clipped away are moved to the end of the list of each RenderListEntrys voxels, they can be skipped in the same way as irrelevant voxels. for details, please refer to chapter 6.
![]() |
For fast evaluation of lighting models, a look-up table based approach can be used [19]. For this purpose, the gradient vector is quantized to 12-16 bit, and stored as an attribute with the voxels. The compact representation of the gradient vector is used as an index into a look-up table which stores precomputed shading information. The content of the look-up table has to be recomputed whenever a factor which influences lighting is modified, for example, a light source is moved, or the volume is rotated. Due to the small size of the table (4096-65536 entries, depending on the gradient quantization), various shading models can be applied on a per-object basis at interactive frame rates. Phong shading [49] and non-photorealistic shading models [10,11] can be easily mixed within a single image (figure 3.3).
To ensure constant quality of shear/warp-based rendering, voxels
should be isotropic, i.e., equally sized in all dimensions. If the
original volume
does not fulfill this condition, as, for example, the sampling
distance in
direction is larger than in
and
-
resampling can be performed during voxel extraction to
obtain isotropic voxels in the RenderList. The resampling can
be performed on-the-fly, and does not require the creation of a
whole resampled, and thus possibly much larger copy of the
original volume.