next up previous contents
Next: Discussion Up: RTVR - a Flexible Java Previous: Data Optimization   Contents


Performance


Table 6.1: Timings for various data sets and rendering modes
data set size scene MIP DVR DVR/ mixed
    voxels     mono MIP/DVR
hand & vessels 256$^2\times$124 380k 80ms 135ms 80ms 170ms
head & vessels 256$^2\times$158 640k 100ms 185ms 110ms 290ms
attractor & basin 256$^3$ 1M 130ms 250ms 140ms 333ms


Figure 6.8: RTVR rendering examples
\includegraphics[width=6.5cm]{Figures/dynsys3.ps} \includegraphics[width=6.5cm]{Figures/dynsys2.ps}
a) basins of attraction b) contact bifurcation -
and a critical surface (green) one out of a sequence of 40 volumes

High responsiveness of a visualization system to user actions is a crucial factor for the effectivity of data exploration and analysis. The rendering times for the surface rendering [44], MIP [42] and two-level volume rendering approach [22] used by RTVR can be found in chapter 4. Thus, instead of broadly surveying the behavior of each method, a comparison of the measured times for rendering the same data set with RTVR using various methods is given in table 6.1. The measurements have been carried out on a PII/400MHz PC using the virtual machine of JDK1.3 from Sun and the AWT frontend of RTVR. The size of the rendered images is $512^2$. The first row shows timings for the data set shown in figure 6.1. Skin, bones, and vessels are represented by their surface voxels. The rendering is carried out using MIP, DVR, a gray-scale DVR view, and a combination of DVR for the vessels and MIP for bones and skin. The second row displays timings for the head data shown in figure 6.7b, with bone, skin and vessels represented as surfaces. The data set in row 3 is similar to the one depicted in figure 6.8b. The basin is represented by it's surface voxels, the chaotic attractor is a highly complex structure, and is thus treated as a truly volumetric object.

The pure rendering time reflects the rendering performance for most interactions. These include interactive changes of the viewing parameters (viewer position and zoom), changes to content of look-up tables (moving light source, changing transfer function), and changes to the parameters and rendering modes of objects. Clipping operations require scanning and reordering of object voxels. During simple clipping of all objects at an axis aligned plane, the response time increases by approximately 40% compared to when changing viewer position. Time required for clipping at more complex objects depends on the complexity of the test which has to be performed for each voxel. Clipping of a complex scene at an oblique plane, for example, can be done with 1-2 frames per second. During browsing through large (time or parameter) series of volumes, voxel data may have to be fetched from disk cache, thus increasing the response time by the time required to read the data. Depending on the size of the scene, this may range from few milliseconds, to more than one second. The time for extraction of new objects from a volume depends on the complexity of the segmentation criteria and on the amount of voxels selected (gradient computation). The extraction of an iso-surface from a $256^3$ volume for example requires approximately 1.5 seconds.

The choice of the virtual machine used to execute the application has severe impact on the performance. Among the tested runtime environments, fastest execution and rendering has been observed for the VMs (1.1.6++, 1.2, 1.3) from Sun on Windows and (1.1.8, 1.2, 1.3) from IBM on Windows and Linux. Virtual machines provided by web-browsers are in general slower, probably due to additionally performed security checks. Worst results are obtained by the VM which is used by Netscape browsers (Version $<=$ 4.7.4) on Linux - the results are more than ten times slower than the timings in table 6.1.


next up previous contents
Next: Discussion Up: RTVR - a Flexible Java Previous: Data Optimization   Contents
Lukas Mroz, May 2001,
mailto:mroz@cg.tuwien.ac.at.