OptimizedProxyGeometry

Table of Contents

1. Using the Processor

The OptimizedProxyGeometry processor is located within the base module. It provides an optimized proxy geometry, allowing for empty-space leaping, which might massively increase rendering performance, especially for data sets with large regions that are classified as completely transparent by the transfer function. The processor also provides axis-aligned clipping. Since optimizing the proxy geometry might take some time (especially for large data sets), the computation is done by a background thread. While this computation is not finished, a simple bounding box proxy geometry is used.

Note that the OptimizedProxyGeometry's transfer function has to be linked with the volume renderer that uses the proxy geometry, since the optimization employs the transfer function to determine the transparency of regions.

A basic volume rendering network using the processor could look like this:

 

The OptimizedProxyGeometry processor provides four different modes and several options to the user:

Mode: Selects how the proxy geometry is built. There are four modes available:

  • Bounding Box
    This mode simply uses a bounding box containing the whole volume. No empty space leaping or optimization is applied here.
  • Minimal Visible Bounding Box
    This mode subdivides the volume into several bricks, where the size of the bricks is adjustable. Afterwards an approximate minimal bounding box is computed by adding all the bricks that are not entirely transparent to an initially empty bounding box. Transparency is determined by a pre-integration heuristic that compares the opacity of the pre-integration table entry with the minimum and maximum intensity values within the brick to a threshold as described by [Knoll et al., 2011].
  • Visible Bricks
    This mode subdivides the volume into several bricks, where the size of the bricks is adjustable. Afterwards the visibility of the data within the bricks is determined (ie. some bricks are marked as transparent regions by the pre-integration heuristic described above). Then a proxy geometry is built by combining neighboring bricks to larger boxes.

Note that the data structures that are built for the second and third mode only have to be newly computed once the volume or the resolution (ie. the size of the bricks) changes. The proxy geometry computed by these modes is built by a background thread. During background computation, a bounding box proxy geometry is temporarily used.

Transfer Function: The transfer function that is used to identify transparent regions within the volume. Has to be linked with the transfer function of the raycaster as it is needed for determining transparent regions.

Resolution Mode: Determines how the resolution for subdividing the volume into bricks is set, either by subdivisions of the shortest edge of the volume or by the edge length of the bricks in voxels.

Resolution: Determines the size of the bricks by dividing the size of the shortest edge of the volume.
Edge Length (Voxels): Determines the edge length of the bricks in voxels.

Visibility Threshold (*10e-4): Determines the threshold for classifying bricks as empty (multiplied by 10^(-4)). Increasing this value might lead to better performance, but choosing the visibility threshold too high might remove features of the data set that should be visible.

Enable Clipping: Selects if axis-aligned clipping is enabled for the proxy geometry.

Wait for optimization: If selected, no temporary bounding box is used while computing the optimized proxy geometry, but the processor waits for the computation to finish. Does not have an effect in bounding box mode.
 

2. Benchmarks

Data sets have been fully rotated around the y-axis in 100 steps via a Python script, measuring the average frame rate. All benchmarks have been rendered to a canvas of size 1024x768. For rendering, the SingleVolumeRaycaster has been used with a sampling rate of 2.0 and Phong shading. Unless otherwise noted, the Threshold property of the OptimizedProxyGeometry processor was set to 1*10e-4 (default setting).

2.1 Used Data Sets and Transfer Functions

  • walnut, dimensions: 128 x 96 x 114, 16-bit, mem size: 2,7 MB

    Rendering:

    Transfer Function:

     

     

     

     

     

    Bounding Box:

    Minimal Visible Bounding Box (res. 32):

    Visible Bricks (res.16):

     

  • backpack, dimensions: 512 x 512 x 373, 16-bit, 186,5 MB

    Rendering:

    Transfer Function:

     

     

     

     

     

    Bounding Box:

    Minimal Visible Bounding Box (res. 32):

    Visible Bricks (res. 32):

  • skull, dimensions: 512 x 512 x 709, 16-bit, 354.5 MB

    Rendering:

     

    Transfer Function:

     

     

     

     

     

    Bounding Box:

    Minimal Visible Bounding Box (res. 24):

    Visible Bricks (res. 24):

         

2.2 Rendering Benchmarks

We have performend rendering benchmarks with a screen resolution of 1024x768 on two different systems: a notebook and a desktop setup.

Desktop: Intel Core i7 2.8 GHz, 12 GB RAM, NVIDIA GeForce GTX 480 (1.5 GB)

walnut, dimensions: 128 x 96 x 114, 16-bit, 2.7 MB


Mode Resolution:
subdivisions of shortest edge
(edge length of bricks in voxels)
FPS Speedup
Bounding Box - 52.11 -
Minimal Visible Bounding Box 8 (12) 52.19 1.00
  32 (3) 54.61 1.05
Visible Bricks 8 (12) 66.31 1.27
  32 (3) 78.31 1.50

backpack, dimensions: 512 x 512 x 373, 16-bit, 186.5 MB


Mode Resolution:
subdivisions of shortest edge
(edge length of bricks in voxels)
FPS Speedup
Bounding Box - 11.84 -
Minimal Visible Bounding Box 16 (23) 18.58 1.57
  32 (12) 18.55 1.57
  64 (6) 19.28 1.63
Visible Bricks 16 (23) 48.83 4.12
  32 (12) 62.50 5.28
  64 (6) 76.51 6.46

skull, dimensions: 512 x 512 x 709, 16-bit, 354.5 MB


Mode Resolution:
subdivisions of shortest edge
(edge length of bricks in voxels)
FPS Speedup
Bounding Box - 16.29 -
Minimal Visible Bounding Box 16 (32) 16.57 1.02
  64 (8) 16.77 1.03
Visible Bricks 16 (32) 35.51 2.18
  64 (8) 52.80 3.24

Notebook: Intel Core i7 1,73 GHz, 4 GB RAM, NVIDIA GT 435M (2GB)

walnut, dimensions: 128 x 96 x 114, 16-bit, 2.7 MB


Mode Resolution:
subdivisions of shortest edge
(edge length of bricks in voxels)
FPS Speedup
Bounding Box - 10.28 -
Minimal Visible Bounding Box 8 (12) 10.40 1.01
  32 (3) 11.23 1.09
Visible Bricks 8 (12) 14.99 1.46
  32 (3) 19.98 1.94

backpack, dimensions: 512 x 512 x 373, 16-bit, 186.5 MB


Mode Resolution:
subdivisions of shortest edge
(edge length of bricks in voxels)
FPS Speedup
Bounding Box - 2.10 -
Minimal Visible Bounding Box 16 (23) 3.66 1.74
  32 (12) 3.65 1.74
  64 (6) 3.79 1.81
Visible Bricks 16 (23) 11.56 5.51
  32 (12) 14.42 6.87
  64 (6) 16.86 8.04

skull, dimensions: 512 x 512 x 709, 16-bit, 354.5 MB


Mode Resolution:
subdivisions of shortest edge
(edge length of bricks in voxels)
FPS Speedup
Bounding Box - 3.27 -
Minimal Visible Bounding Box 16 (32) 3.28 1.00
  64 (8) 3.35 1.02
Visible Bricks 16 (32) 8.35 2.55
  64 (8) 10.97 3.35

 

2.3 Initial Creation of the Data Structures

Before using the optimized geometry, the processor needs to compute the data structures and traverse them in order to detect opaque regions. This is done by a background thread. While the optimized geometry is not ready, the processor's output is a simple bounding box geometry, enabling the user to continue working interactively, although at lower frame rates. Below, measurements are listed for the computation of the data structures and the traversal. Note that the data structure has to be built only once for a volume and a certain resolution. Traversal, determining the actual proxy geometry, is necessary every time the transfer function changes.

Time has been measured using one core of an Intel Core i7, 1.73 GHz.

        


                   

walnut

(time building the data structures /

time for traversal)

backpack

(time building the data structures /

time for traversal)

8 / 12 16 / 6 32 / 3 16 / 23 32 / 12 64 / 6
Minimal Visible Bounding Box - -

329 ms /

12 ms

8900 ms /

2 ms

10309 ms /

2 ms

-
Visible Bricks

145 ms /

1 ms

181 ms /

3 ms

347 ms /

19 ms

9487 ms /

3 ms

10564 ms /

17 ms

12717 ms /

117 ms

Analysis

The measurements clearly show that a finer resolution (ie. smaller edge length of the bricks) increases rendering performance, especially for data sets containing a lot of empty space like the backpack data set with the given transfer function. However, computing and traversing the data structures takes more time for finer resolutions. Especially the traversal time is important when interactively changing the transfer function as rendering speed decreases with the temporary bounding box. The proxy geometry generated by the "Visible Bricks" mode provides the best performance of all modes.
 

References

Knoll, A., Thelen, S., Wald, I., Hansen, C., Hagen, H., and Papka, M. (2011).
Full-Resolution Interactive CPU Volume Rendering with Coherent BVH
Traversal. In IEEE Pacific Visualization Symposium 2011, pages 3–10.