Interactivity Considerations with PVR

With the performance numbers presented, several conclusions can be drawn about the kinds of interactivity that can be accomplished. First, for generating animations, the best scheme is to write a PVR script and let it run on the background and output the whole process to a file. In this script, one can let PVR use its defaults, that is to replicate the data set in as many clusters as possible in order to generate the most images concurrently. This strategy usually has the highest possible image throughput, but its latency may be unacceptable (specially in the case the data set fits in one processor, the images may take a long time to be generated).

The options for interactive use are more complicated. We estimate that PVR can be used on two forms of interactive applications: on demand fine granularity rendering, and on demand bulk rendering. During demand fine granularity rendering, the latency is the major concern. As soon as the user clicks on a rotation button, images need to show up almost immediately. With the Paragon performance, this is only possible with small images or a very small number of processors (Figure 10). With more powerful parallel machines and faster networks, it might be possible to render larger images.

  
Figure 13: Volume rendering of the negative potential of a high-potential iron protein using PVR (image resolution ).

  
Figure 14: Volume rendering of an MRI head using PVR (image resolution ).

Demand bulk rendering is achievable by the Paragon as is shown on Table 2. The user usually experiences a small delay between the issue of the bulk command (like creating a full rotation around a given axis) and the display of the rendered image sequence. But, PVR is able to generate images fast enough to create the desired motion. PVR uses a simple technique to avoid transmitting the images too fast to the user's workstation during the bulk image generation: a constant can be used as the minimum time between image updates (e.g., = 0.5 seconds). can be set by the user or (in the case of our renderer) can be adjusted from the pipeline (see details in [SK94]).

Real-time rendering coupled with direct manipulation (e.g., VolVis navigator [AHH94]) are not supported. We believe that when machines get about four to five times faster and external networks to get latency down into the low milliseconds with throughput in the 100-150MB/sec, this might be possible. In one year or so, with the next generation of Intel parallel machines (or with current faster parallel machines like the CRAY T3D or the IBM SP-2), and the upcoming ATM networks, it might be possible to create real-time rendering with the PVR system.