The Holodeck interactive ray cache

Gregory Ward Larson, Maryann Simmons
1999 ACM SIGGRAPH 99 Conference abstracts and applications on - SIGGRAPH '99  
We present a new method for rendering complex environments using interactive, progressive, viewindependent, parallel ray tracing. A four-dimensional holodeck data structure serves as a rendering target and caching mechanism for interactive walk-throughs of non-diffuse environments with full global illumination. Ray sample density varies locally according to need, and on-demand ray computation is supported in a parallel implementation. The holodeck file is stored on disk and cached in memory by
more » ... server using an LRU beam-replacement strategy. The holodeck server coordinates separate ray evaluation and display processes, optimizing disk and memory usage. Different display systems are supported by specialized drivers, which handle display rendering, user interaction, and input. The display driver creates an image from ray samples sent by the server, and permits the manipulation of local objects, which are rendered dynamically using approximate lighting computed from holodeck samples. The overall method overcomes many of the conventional limits of interactive rendering in scenes with complex surface geometry and reflectance properties, through an effective combination of ray tracing, caching, and hardware rendering. three-dimensional objects are a challenge [Luebke97]. Billboarding takes advantage of texture-mapping hardware by replacing complex objects with stand-up impostors, but these must be recomputed frequently to avoid artifacts [Schaufler98, Shade96, Sillion97]. When geometric complexity is combined with complex lighting and shading, interactive rendering no longer seems possible. Therefore, some have thought it best to forego geometry and sample the light field directly. The image-based approach to interactive rendering has been explored by several researchers in recent years [Ashdown93, Chen95, Levoy96, McMillan95] , including those who have used simplified geometry in the process [Debevec96, Gortler96, Miller98, Nimeroff96, Pighin97] . Lischinski developed a method for interactive rendering that uses two ray-traced light fields for diffuse and non-diffuse contributions [Lischinski98], and Bala developed a method for ray-traced walkthroughs with guaranteed error bounds [Bala99] . With the exception of Pighin's and Bala's work, none of these methods make use of an on-line ray tracer or other sample generator to refine the displayed image. Pighin's method does not reuse ray samples, and Bala's technique does not display an image until complete, leading to potentially long frame times and slow interaction. In this paper, we present a new approach, which combines a holographic scene representation with a parallel, interactive ray calculation. This method most resembles the recent work by [Walter99] , where samples are cached and displayed interactively in a continuous update cycle. However, where Walter et al keep no permanent record of computed rays, we assume the ray computation is costly enough that persistent storage is worthwhile. In our approach, rays are computed, cached, and eventually stored to disk using a holodeck data structure --a spatial grid used to sort rays without regard to sampling density. These rays are reused for subsequent views, and additional rays may also be generated interactively. Each ray intersection distance is recorded along with the floating point color to enhance display processing. This requires a total of 10 bytes per sample in our implementation. Rays are clustered together into beams for efficient disk access, so no intermediate processing or compression is required between computing samples and using them. Typical holodeck files range from 50 Mbytes to 1 Gbyte, depending on resolution and the number of sections. Although large, these data structures may be kept on CD-ROM or other mass storage media for rapid access and rerendering, and do not need to be kept in memory. We start by describing our method, including the holodeck representation, the three-process program design, and basic display representations. This is followed by an exposition of our results, where we give example scenes, views, and timings. Finally, we conclude with some discussion of the technique, and a few ideas for the future.
doi:10.1145/311625.312142 dblp:conf/siggraph/LarsonS99 fatcat:xonxm2r46rczrizywxlvm2ibva