18
|
model |
size |
basic (fps) |
classify (fps) |
|
engine |
256 × 256 × 256 |
34 |
14 |
|
foot |
256 × 256 × 256 |
37 |
10 |
|
head |
128 × 256 × 256 |
40 |
13 |
|
GroEL |
240 × 240 × 240 |
38 |
16 |
Table 2.2 : The rendering speed for each of the data sets. All results were measured
in Frames per Second (fps).
The second operation Restrict again takes as input a multi-material map and a
two-material map (with materials A and -∣A). In this case, the Restrict operation
modifies the second map to return the intersection of the first map (viewed as ma-
terials A and -∣A) and the second map. Essentially, the second map is restricted to
only those regions where the material A exists in the first map.
2.3 Results
Our method has been implemented and tested on a Intel Xeon 5150 machine with 2
duo-core CPUs running at 2.66GHz. We use an nVidia GTX280 graphics card with
1GB of video RAM. The shaders are written in GLSL. We use OpenMP to enable
multi-core processing for easily parallelizable portions of the code.
We gather rendering times for each of our test cases. The models are displayed
in Figure 4.2. The running time largely depends on the maximum dimension of
the volume as we use that to determine the number of quads to use as proxies for
rendering. The rendering screen is 512 × 512 pixels. The intensive portion of the
shader is called only for inhomogeneous cells, which implies that the rendering is
slower for examples with a higher number of materials. This slowdown is evident in
the “foot” example, where the number of materials is high. Note that the rendering
speed also depends on the pixel estate required to display each volume; the smaller