We have run the implementation under Linux on a Pentium II (450MHz) PC with 256MB memory. All test data was produced in NFF with the SPD package (version 3.13, compiled with `JENKINS_HASH' for the scene `mount') and was converted into binary form. No instancing was used. Other parameters such as a screen resolution followed the testing procedure of SPD: 513x513 eye rays were shot and the maximum tracing depth was 5. Consult `Readme.txt' in the SPD package for more details and scenes' properties. Parameters for refinements were initialized as follows:

• For a bounding box hierarchy (Section 3.1):
  s=3, n=1,000, and l=4 (5 levels). For `balls', `gears', and `trees', t was set to 0.5 resulting two top-level boxes, while it was set to 1.0 for other types of scenes resulting one top-level box. The number of resulting levels depends on types of scenes; for example, it was 3 for `balls', while 4 to 5 for `rings'.
• For two-level grids storing rays (Section 3.2):
  Ru=256 and Rl=4.

We firstly tested relatively small data (up to 50,000,000 objects/6GB) for investigating various tendencies. Table 1 shows how refinements in Section 3.1 - separation of geometry and bounding boxes (S), lazy processing for each object's geometry (G), and lazy processing with a bounding box hierarchy (B) - affect rendering (preprocess and tracing) time. Each grid resolution was determined by the method described in Section 3.2 and high-resolution grids were employed if necessary. The percentage of each phase depends on both scenes and applied refinements, but it is approximately the following: the preprocess phase is 1-34%, the intersection phase is 49-89%, and the shading phase is 4-37%. In this table, `SGB' becomes more effective as data grows. Both `S' and `G' generally result in speed-up as was expected, while the effectiveness of `B' greatly depends on the depth complexity (how many objects a ray passes through) and/or the occlusion complexity (how many objects are occluded) as in other culling techniques. `B' however does not cause large overheads in worst cases such as `tetra' and `tree'.

Figure 1 and Table 2 show how refinements in Section 3.2 are efficient in realizing high-resolution grids. In the figure, slow growth of time is achieved with refinements, while limited-resolution grids result in more linear growth of time. Although shorter absolute time is achieved with limited-resolution grids in `gears', it changes linearly for latter three size factors. The table shows overheads of two-level grids. There is 10-20% loss, which is rewarded with the efficiency of high-resolution grids.

Figure 1. Changes in rendering time with/without high-resolution grids. All refinements for redundant data processing were applied. No suffix means that high-resolution grids were used by applying refinements in Section 3.2, while the suffix `-l' means that the maximum resolution for an axis was limited to 128 and single-level grids were used.

balls	gears
mount	rings
teapot	tetra
tree

The next results show how refinements are efficient for huge data. Table 3 and Table 4 show statistics and Figure 2 shows their rendered images. These tables show that applying refinements for huge data further improves both preprocess and tracing time. The gain factors range from 5 to 14 in rendering time. The gain factor in tracing time is quite large for `rings368m' (`rings368' with different view data), because only a small portion of objects contributed to the image and many objects were culled by `B'. Note that it is not an ordinary view-frustum culling; there are reflection/shadow rays going outside the frustum. Note also that high-resolution grids were used by applying refinements in Section 3.2 even for `base', as in Table 1, in order to avoid lengthy computation time. The gain factors would be much larger if the grid resolution for `base' was limited.

Creation time is extremely long for large data. This results from strictly following the testing procedure of SPD. In actual systems, however, it is important to cooperate with modeling systems for efficient rendering of huge data.

Figure 2. Rendered images for huge data. The view parameter is the only difference between `rings368m' and `rings368': the view frustum of `rings368m' contains approximately 1,000,000 objects.

mount14	rings368	rings368m
#objects: 536,870,916	#objects: 1,000,787,041	#objects: 1,000,787,041
48.50GB	86.77GB	86.77GB