GPU Rendering of Secondary Effects

Kai Burger, Stefan Hertel, Jens Kruger and Rudiger Westermann

Technische Universitat MunchenEmail: {buergerk,hertel,jens.krueger,westermann}@in.tum.de

Abstract

In this paper we present an efficient data structureand algorithms for GPU ray tracing of secondary ef-fects like reflections, refractions and shadows. Ourmethod extends previous work on layered depthcubes in that it uses layered depth cubes as an adap-tive space partitioning scheme for ray tracing. Wepropose a new method to efficiently build LDCs onthe GPU using geometry shaders available in Di-rect3D 10. The overhead of peeling the scene mul-tiple times can thus be avoided. We further showthat the traversal of secondary rays is greatly accel-erated by exploiting a two level hierarchy and theadaptive nature of the LDC. Due to the computa-tional and bandwidth capacities available on recentGPUs our method enables high-quality rendering ofstaticanddynamic scenes at interactive rates.

1 Introduction and Related Work

Since the early years of computer graphics there hasbeen interest in ray tracing due to its potential forthe accurate rendering of complex light phenomena.Over the last few years, there was an ever grow-ing interest due to the observation that interactiveray tracing can now be achieved on custom hard-ware [8, 23, 22], or by using a cluster of customcomputers [19, 26]. Recent advances in hardwareand software technology, including specialized raytracing chips [25] as well as advanced space parti-tioning and traversal schemes [27, 30], have evenshown that ray tracing is potentially suited for realtime applications like computer games and virtualenvironments.

Simultaneously, considerable effort has been putinto the implementation of ray tracing on pro-grammable graphics hardware. Inspired by theearly work of Purcell et al. [21] and Carr et al. [2],in a number of succeeding implementations it wasshown that the capabilities of recent GPU stream ar-

chitectures including parallelism across stream ele-ments and low-latency memory interfaces can ef-fectively be used for ray tracing [17]. While theseapproaches were solely based on uniform space par-titioning schemes, recent work has also demon-strated the possibility to build and traverse adaptivespatial hierarchies on the GPU [15]. Hereafter, Fo-ley and Sugerman [5] as well as Popov et al. [20] in-dependently examined stack operations—a featurenot well-supported by the GPU—and they reporteda significant performance gain by using a stacklesstraversal algorithm for kd-trees. Alternatively, Carret al. [3] represented surfaces as geometry imagesand introduced linked bounding volume hierarchiesto avoid conditionals and stack operations. By tak-ing advantage of the GPU to construct these hier-archies, for the first time the authors could demon-strate real-time GPU ray tracing of dynamic scenes.

Despite all the advancements in GPU ray tracing,including efficient approximations for ray-objectintersection using pre-computed environment im-posters [14] and ray-object penetration depths [31],it can still not be denied that high quality ray tracingusing optimized CPU codes performs favorable oreven faster than many GPU implementations. Themain reason why rasterization hardware is not per-fectly suited for ray tracing is the inability of cur-rent GPUs to efficiently determine ray-object inter-sections for rays others than view rays. This makesit difficult to accurately simulate secondary effectslike reflections, refractions, and shadows, as sucheffects require parts of the scene to be rendered mul-tiple times under different projections, i.e. onto dif-ferent receivers. Although possible in principle, itwas shown by Wand and Straßer [28] for the ren-dering of underwater caustics that this approach isnot practicable in general.

On the other hand it can be observed that a sig-nificant part of the render time in typical 3D appli-cations is shading, and it is well accepted that theGPU outperforms the CPU in this respect. Appar-

VMV 2007 H. P. A. Lensch, B. Rosenhahn, H.-P. Seidel, P. Slusallek, J. Weickert (Editors)

Figure 1: Method demonstration: Cubemap reflections (left), our method (middle) and software ray tracing(right). On a single Geforce 8800 GTX our method renders the scene into a 1280x1024 image at 3 fps.

ently, due to the GPUs inability to effectively ex-ploit adaptive space partitioning schemes this ad-vantage is entirely amortized in ray tracing. Ourmotivation is thus to overcome GPU limitations infinding ray-object intersections, at the same timeexploiting the intrinsic strength of these architec-tures to shade billions of fragments in real-time.

1.1 Contribution

The main contribution of this paper is a new GPUapproach for ray tracing of secondary effects like re-flections, refractions and shadows. This is achievedby using an adaptive spatial data structure at ex-treme resolution, and by providing novel meth-ods to construct and traverse this data structure onthe GPU. Just as proposed by Lischinski and Rap-poport [13], our data structure represents the sceneas a set of layered depth images (LDI) [24, 16, 6]along three orthogonal projections. According toLischinski and Rappoport [13] we will refer to thisstructure as the layered depth cube (LDC). We ex-tend LDCs in the following ways:

• LDIs are constructed via depth peeling [4], butwe employ Direct3D 10 functionality so thatthe scene only has to be peeled once to gener-ate LDIs along multiple viewing directions. Toaccelerate the LDC construction every poly-gon is rendered only into the LDI capturing thescene from the direction most perpendicular tothis polygon (see Figure 5). To accommodatedeferred shading the LDC stores not only frag-ment depth, but also interpolated colors andtexture values as well as normals. The processleads to a view independent scene representa-tion using a minimal number of samples.

• For each LDI a two level hierarchy is built.This method is similar to the empty spaceskipping structure used by Kruger and Wester-mann [11]. Entries in this low resolution repre-sentation of one LDC direction store for eachbundle the minimum and maximum distancesfrom a reference plane perpendicular to the di-rection of projection.

• We present an efficient ray-object intersectiontest using LDCs. As in each LDI the sampleslie on a 2D raster we perform ray traversal inthese rasters alternatively. This method is sim-ilar to screen-space ray tracing described byKruger et al. [10], but it has a major advan-tage: The hierarchical representation is usedto skip regions in these rasters not containingany structures a ray could intersect with.

As both the LDC construction and the traversalare performed on the GPU the rasterization capac-ities of recent architectures can effectively be ex-ploited. In particular, since our approach does notrequire any pre-process to modify the initial scenerepresentation it can be used in the same way to ren-der dynamic scenes or scenes created or modifiedon the GPU. Some results of our approach togetherwith a comparison to cubemap reflections and soft-ware ray tracing are shown in Figures 1 and 2.

The remainder of this paper is organized as fol-lows: In the next chapter we will discuss the LDCconstruction in particular the use of Direct3D 10features to speed up this process. We will then de-scribe how this structure can be efficiently traversedon the GPU. Next, we explain the integration of theLDC construction and the ray traversal into the ren-dering algorithm. Finally, we analyze the perfor-

Figure 2: Method demonstration: Cubemap reflections (left), our method (middle) and software ray tracing(right). On a single Geforce 8800 GTX our method renders the scene into a 1280x1024 image at 5 and 3fps, respectively.

mance of the major components of our system, andwe conclude the paper with some remarks about fu-ture research in this field.

1.2 LDC Construction

To efficiently construct LDCs on the GPU we firstemploy depth peeling [4] to generate LDIs alongthree orthogonal viewing directions. Depth-peelingrequires multiple rendering passes. For each pixel,in then-th pass the(n−1)-th nearest fragments arerejected in a fragment program and the closest ofall remaining fragments is retained by the standarddepth test. A floating point texture map—the depthmap—is used to communicate the depth of the sur-viving fragments to the next pass. The number ofrendering passes is equal to the objects depth com-plexity, i.e. the maximum number of object pointsfalling into a single pixel. This number is deter-mined by rendering the objects once and by count-ing at each pixel the number of fragments fallinginto it during rasterization. The maximum over allpixels is then collected in a log-step reduce-max op-eration [12].

Although more efficient depth peeling vari-ants exist, for instance the method proposed byWexler et al. [29] showing linear complexity in thenumber of polygons compared to quadratic com-plexity of standard depth peeling, in the currentwork we favor the more complex approach. Thisis because it does not require any pre-processingand thus can be used for the processing of dynamicscenes and scenes modified or generated on theGPU.

1.2.1 Construction using Geometry Shader

In this chapter we describe how to efficiently gen-erate an LDC that captures the entire scene. Fromthe text it should become clear that the same ap-proach can of course be used to generate LDCs forseparate objects in the scene. In particular for rigidobjects this allows us to pre-compute the LDC onceand to exclude it from depth peeling in successiveframes. LDC construction greatly benefits from lat-est graphics APIs and hardware as explained in thefollowing paragraphs.

Input Data

Input AssemblerStage (IA)

Vertex ShaderStage (VS)

Geometry ShaderStage (GS)

Stream OutputStage (SO)

Rasterizer Stage(RS)

Pixel ShaderStage (PS)

Output MergerStage (OM)

Output Data

MemoryResources:

Buffers,Textures,

Constant Buffers

Buffer

Texture, Constant Buffer

Texture, Constant Buffer

Texture, Constant Buffer

Buffer

States

Buffer, Texture, Constant Buffer

Figure 3: The Direct3D 10 rendering pipeline. Pro-grammable stages are drawn in yellow. Note inparticular the new programmable Geometry Shaderstage after the Vertex Shader.

One of the key novelties of Direct3D 10 capa-ble hardware [1] is a new programmable stage inthe rendering pipeline. This stage—the Geometry

Shader—is placed directly after the Vertex Shaderstage (see Figure 3). In contrast to the Vertex Shaderthe Geometry Shader takes as input an entire graph-ics primitive (e.g. a triangle or a triangle and itsneighbors) and outputs zero to multiple new prim-itives. This is achieved by letting the GeometryShader append the new primitives to one or mul-tiple output streams. The LDC construction algo-rithm makes use of this feature and binds multipleoutput streams called render targets (MRTs) to theGeometry Shader. Note that these MRTs are differ-ent from the ones known in the Pixel Shader stage.

While MRTs in the Pixel Shader are used tooutput multiple color values at the very end ofthe pipeline, to each Geometry Shader MRT itsown rasterizer, Pixel Shader stack, depth and colorbuffers are associated. One can even assign anotherstack of Pixel Shader MRTs to each of these sepa-rate pipelines (see Figure 4).

GS MRT

Input Data

Input AssemblerStage (IA)

Vertex ShaderStage (VS)

Geometry ShaderStage (GS)

Rasterizer Stage(RS)

Pixel ShaderStage (PS)

Output MergerStage (OM)

Rasterizer Stage(RS)

Pixel ShaderStage (PS)

Output MergerStage (OM)

PS MRT

...

PS MRT PS MRT PS MRT

... ...

GS MRT

Figure 4: This figure depicts the difference betweenMRTs used in the Geometry Shader and in the PixelShader stage.

Without the functionality provided by the Ge-ometry Shader LDC construction requires the en-tire scene to be rendered three times. By usingthe Geometry Shader MRTs we only need to pro-cess and rasterize the scene once. This is achieved

by letting the Vertex Shader perform the geometrytransformation excluding the viewing transforma-tion. Transformed vertices are then combined totriangles and sent to the Geometry Shader stage.Here, face normals are computed for every trian-gle and compared against the three directions alongwhich peeling is performed. Triangles are then ras-terized into the MRT which captures those parts ofthe scene most perpendicular to its projection direc-tion (see Figure 5). In this way every triangle has tobe processed and rasterized only once. This methodnot only reduces GPU load to one third, but it alsoreduces the depth complexity along all three direc-tions since lesser primitives appear in either target.

Furthermore, as no primitive is rasterized intomore than one MRT the process avoids storage ofredundant samples in different projection directionsthus leading to an optimal view independent scenerepresentation. As mentioned earlier, each Geom-etry Shader MRT pipeline can have multiple PixelShader MRTs at its very end (see Figure 4), we usethis additional possibility to capture multiple val-ues at once. In particular we use two Pixel ShaderMRTs, one target to store the normal and depth in-formation of the fragments and a second target fortexture and color information. In the final render-ing step we use the later values to perform deferredshading of the reflected and refracted surfaces.

Z

Y

X

Figure 5: This figure shows how triangles are pro-jected into only one LDI stack depending on theirface normal orientation.

By using the Geometry Shader MRTs the com-plexity of our algorithm to construct the LDC isreduced tomax(depthComplexity) passes. How-

ever, with the advent of layered depth/color buffersat the end of the rendering pipeline we expect ourconstruction procedure to become even more effi-cient. For a long time such a functionality is presenton GPUs (e.g. ATI/AMDs FBuffer technology [9])though it has not yet been exposed. On the otherhand we perceive an ever growing demand for depthpeeling in a number of applications ranging fromorder independent transparency [4] and CSG ren-dering [7] to volume rendering applications [18]and real-time rendering [10]. As a consequencewe expect graphics APIs to support these featuresin the foreseeable future. Then, the generation ofLDCs could even be performed in one single ren-dering pass.

1.3 Two Level LDC

An LDC exhibits an extremely adaptive and com-pact representation of the scene, yet it lacks the hier-archical nature of other space partitioning schemessuch as octrees or kd-trees. It is on the other handwell known that such schemes can greatly acceler-ate ray tracing in that they allow for an efficient de-termination of ray-object intersections.

To generate a two-level LDC we first computethe LDC as described above. Then a single low res-olution data structure is generated for every LDI.This structure is built only on the depth valueswhereas the the normal and texture stacks remainunchanged. For the generation of ann×m reducedempty space skipping texture we employ a custompixel shader, that performs a max/min computationon a grid ofn×m fragments from all LDI layers inone direction (see Figure 6). Such a texture can beseen as an axis aligned bounding box, which will beused later on to efficiently skip empty space in thescene.

Equipped with the acceleration texture as de-scribed we will now show how to exploit this datastructure for GPU ray tracing.

1.4 Ray Traversal

To traverse rays through a two level LDI we employan approach similar to the one proposed by Krugerand Westermann [11]. We perform a modified DDAalgorithm to find the coarse level grid cells inter-sected by the ray. Therefore the ray is tested againstthe depth range stored in the cells of the accelera-tion texture being hit. If an intersection is found we

AccelerationTexture

LDI Layer 0 LDI Layer 1

Figure 6: The image shows how two LDI layers(top) are combined into a single acceleration texture(bottom). This texture effectively stores boundingboxes around all LDI layers for a givenn × m gridin this case2 × 2.

step down to the LDIs and use the same DDA al-gorithm within then × m block. If an intersectionwith one of the values stored in the LDIs is foundwe terminate the ray traversal, otherwise we con-tinue at the next block in the coarser empty spaceskipping texture.

In the way described we subsequently processone peel direction after another. Note that if an in-tersection in one direction is found this intersectiondoes not necessarily has to be the first intersectionalong the ray. However, in this case we can changethe end point of the ray to the position of that in-tersection, continually reducing the remaining dis-tance to be considered along the ray. After all layershave been traversed the intersection point betweenthe ray and an object in the scene is found, or justthe intersection with the LDCs bounding box. Thisinformation is used later on for shading the reflectedsample point.

2 Rendering

After having described both the two level data struc-ture used to represent a scene on the GPU and anefficient ray traversal scheme for this data structurewe will now present the rendering algorithm thatfinally generates an image of the scene. This al-gorithm renders the scene in three passes. In thefirst pass—which itself consists of multiple sub-passes—the LDC capturing the scene is generated.In the second pass “primary ray-object intersec-tions” are determined by rasterizing the scene un-der the current viewing transformation. In the third

pass the secondary rays are traced in the LDC tosimulate reflections, refractions and shadows.

While passes one and two are clear, pass threeneeds some further explanations.

2.1 Ray Tracing and Shading

After the second pass the scene as seen from the cur-rent view point, appropriately shaded but withoutany secondary effects, has been generated. In thisimage we need to find for every specular receiverthe points in the scene from where to receive an ad-ditional radiance contribution. Therefore we pro-ceed in two steps. In the first step we render reflec-tive/refractive objects by employing a pixel shaderprogram that computes for every fragment the fol-lowing values:

• the reflection vector• the intersection of this vector with the LDC• the parallel projection of the reflection vector

into the three orthogonal LDIsThe later two quantities are stored in three render

targets, of which we use the first to store the inter-section point and the remaining two to store pro-jected directions (see Figure 7). In the second stepwe use these values to perform the LDC traversalas described in the previous section. This resultsin either an intersection point with an object in thescene or with the scene’s bounding box. In the lat-ter case we simply perform a lookup into an envi-ronment map to compute the color of the reflection.In the former case we lookup the normal and thecolor generated for the intersected point in the LDCconstruction, and we use this information to shadethe reflected point. Finally, the color seen along theprimary rays is combined with the color of the sec-ondary ray and rendered into the color buffer.

3 Results

We have tested the proposed GPU ray tracing tech-nique in a number of different scenarios consist-ing of several thousands up to hundreds of thou-sands triangles. Images of such scenes togetherwith ground truth images generated by a softwareray tracer are given in Figures 1 and 2. At the endof this chapter some additional examples includingshadowing and refractions are shown. In contrast tothe first four examples, in the fifth example a dy-namic object is rendered using vertex shader skin-

Y

X

Z

Figure 7: This image illustrates the four values gen-erated prior to the ray traversal. Firstly, the intersec-tion point between the reflected ray and the bound-ing box yellow) is computed. Next, the ray is pro-jected into the three orthogonal LDIs (red, green,blue).

ning. In this case the LDC is constructed on-the-flyin every frame of the animation (see Figure 10).

All of our tests were run on a single core Pentium4 equipped with a NVIDIA Geforce 8800 GTXgraphics card with 768 MB local video memory. Inall of our tests1K × 1K LDIs were used to sam-ple the objects along three orthogonal viewing di-rections. Note that this corresponds to a resolutionof the spatial data structures of1K

3. However, aswe store 16 Bit floating point depth values in everyLDI this resolution is in fact significantly higher. Aswe only capture those areas in space where someobjects are present, our approach requires consid-erably less memory than other techniques using auniform grid structure to represent the scene.

All objects are encoded as indexed vertex arraysstored in GPU memory. In all our experiments anintersection was determined if the distance betweena point on the secondary ray and a fragment codedin the LDC was less than0.001 in world space.This tolerance was also used in all other examplesthroughout this paper. It can be seen in all our ex-amples that the scene is adequately sampled by theLDC and GPU ray tracing produces almost exactlythe same results as the software ray tracer runningin double floating point precision on the CPU.

Representative timings in milliseconds (ms) forGPU ray casting of secondary effects in the four ex-ample scenes are listed in Table 1. The number of

LDIs required to capture the scenes adequately are8, 12, 7, 6 and 6 respectively. The values in columnslabeled (A) show the amount of time spent by theGPU for LDC construction. Columns labeled (B)show the time spent for ray tracing including ren-dering of the final result. Performance was mea-sured using LDIs at512 × 512 and1K × 1K reso-lution. All tests were rendered into a1280 × 1024viewport (see Figures 8 to 10) .

Figure 8: Two reflective teapots above a mirroringplane and the EG07 Phlegmatic Dragon with a re-flective surface. Note the reflection of the dragonsface on its nose.

As the timings show, by means of the proposedtechnique secondary effects in very complex scenescan be simulated at interactive rates and convinc-ing quality. In particular it can be observed that the

LDI resolution512 x 512 1024 x 1024A B A B

Bunny 7 61 19 115(8192 tris)Car 9 82 25 250(20264 tris)Dragon 12 205 31 441(120K tris)Max Planck 19 160 53 346(300K tris)Tiny (animation) 5 44 16 95(1628 tris)

Table 1: Timing statistics (in ms) for differentscenes.

LDC construction is fast enough to allow for on-the-fly capturing of reasonable scenes. This prop-erty makes it possible to render dynamic objects athigh frame rates and quality.

4 Conclusions and Future Work

In this work we have described a technique for GPUray tracing of secondary effects. By using a view-independent, two level LDI representation in com-bination with an adaptive ray traversal scheme onthe GPU interactive rendering of such effects is pos-sible. We have shown how to construct LDCs effi-ciently on the GPU by exploiting recent function-ality on Direct3D 10 capable graphics hardware to-gether with the intrinsic strength of these architec-tures to shade millions of points in real-time. As ourtimings indicate, the proposed techniques enable in-teractive ray tracing of complex scenes at high ac-curacy. In comparison to software ray tracing visualartifacts are marginal.

Due to the efficiency of the LDC construction itis in particular possible to integrate this process intothe rendering pass. This enables the rendering ofdynamic objects without any additional modifica-tions of the proposed algorithm. As the constructionprocess only requires objects to be available in anyrenderable format our method can also deal with ob-jects being modified or constructed on the GPU.

In the future, we will investigate how to furtherimprove the performance of the proposed renderingtechnique. In particular we will focus on the prob-lem how to effectively exploit the internal RGBApipeline on current GPUs. In principle this can bedone in two ways: Firstly, by storing four LDIs intoone RGBA texture target and thus by providing the

possibility to trace every ray in four depth layerssimultaneously. Secondly, by tracing four rays si-multaneously in one fragment program. As bothoptimizations are greatly influenced by the abilityof recent GPUs to effectively exit shader programs,a detailed analysis of the performance gains for dif-ferent scenes and architectures is required. Further-more, we plan to compare our two-level accelera-tion structure to fully octree or kd-tree hierarchies.

5 Acknowledgments

The authors wish to thank the AIM@SHAPEproject and all of its partners for providing most ofthe meshes used in this paper as well the Academyof Sciences of the Czech Republic, and CGG,Czech Technical University in Prague for providingthe Phlegmatic Dragon data set.

References

[1] David Blythe. The direct3d 10 system. InSIG-GRAPH ’06: ACM SIGGRAPH 2006 Papers,pages 724–734, New York, NY, USA, 2006.ACM Press.

[2] N. Carr, J. Hall, and J. Hart. The ray engine.In Proceedings of the ACM SIGGRAPH /EU-ROGRAPHICS conference on Graphics hard-ware, pages 37–46, 2002.

[3] Nathan A. Carr, Jared Hoberock, KeenanCrane, and John C. Hart. Fast gpu ray tracingof dynamic meshes using geometry images. InGI ’06: Proceedings of the 2006 conferenceon Graphics interface, pages 203–209, 2006.

[4] Cass Everitt. Interactive order-independenttransparency. Technical report, NVIDIAWhite papers, 2001.

[5] Tim Foley and Jeremy Sugerman. Kd-treeacceleration structures for a gpu raytracer.In HWWS ’05: Proceedings of the ACMSIGGRAPH/EUROGRAPHICS conference onGraphics hardware, pages 15–22, 2005.

[6] Steven J. Gortler, Li-Wei He, and Michael F.Cohen. Rendering layered depth images.Technical Report Technical Report MSTR-TR-97-09, Microsoft Research, Redmond,WA, 1997.

[7] John Hable and Jarek Rossignac. Blister:Gpu-based rendering of boolean combinationsof free-form triangulated shapes. InSIG-

GRAPH ’05: ACM SIGGRAPH 2005 Papers,pages 1024–1031, 2005.

[8] Daniel Hall. The ar350: Today’s ray trace ren-dering processor. SIGGRAPH / EurographicsWorkshop On Graphics Hardware - Hot 3DSession, 2001.

[9] Mike Houston, Arcot Preetham, and Mark Se-gal. A hardware f-buffer implementatio. Tech-nical report, Stanford University ComputerScience Technical Reports, 2006.

[10] Jens Kruger, Kai Burger, and Rudiger Wester-mann. Interactive screen-space accurate pho-ton tracing on GPUs. InRendering Tech-niques (Eurographics Symposium on Render-ing - EGSR), pages 319–329, June 2006.

[11] Jens Kruger and Rudiger Westermann. Ac-celeration Techniques for GPU-based VolumeRendering. InProceedings IEEE Visualiza-tion 2003, 2003.

[12] Jens Kruger and Rudiger Westermann. Linearalgebra operators for GPU implementation ofnumerical algorithms.ACM Transactions onGraphics (TOG), 22(3), 2003.

[13] Dani Lischinski and Ari Rappoport. Image-based rendering for non-diffuse syntheticscenes. InProceedings, Ninth Eurograph-ics Workshop on Rendering, pages 301–314,1998.

[14] Szirmay-Kalos Lszl, Aszdi Barnabs, LaznyiIstvn, and Premecz Mtys. Approximate ray-tracing on the GPU with distance impostors.Computer Graphics Forum, 24(3), 2005.

[15] Gunther Greiner Manfred Ernst, Christian Vo-gelgsang. Stack implementation on pro-grammable graphics hardware. InVision Mod-eling and Visualization, pages 255–262, 2004.

[16] Nelson Max. Hierarchical rendering of treesfrom precomputed multi-layer z-buffers. InProceedings of the eurographics workshop onRendering techniques ’96, pages 165–174,London, UK, 1996. Springer-Verlag.

[17] Gabo Moreno-Fortuny and Michael McCool.Unified stream processing raytracer. Posterat GP2: The ACM Workshop on GeneralPurpose Computing on Graphics Processors,2004.

[18] Zoltan Nagy and Reinhard Klein. Depth-peeling for texture-based volume rendering. InPG ’03: Proceedings of the 11th Pacific Con-ference on Computer Graphics and Applica-

tions, 2003.[19] W. Martin Parker, P.-P. Sloan, P. Shirley,

B. Smits, and C. Hansen. Interactive ray trac-ing. In Symposium on Interactive 3D Com-puter Graphics, pages 119–126, 1999.

[20] Stefan Popov, Johannes Gunther, and PhilippSlusallek. Stackless kd-tree traversal for highperformance gpu ray tracing. InProceed-ings of EUROGRAPHICS annual conference,2007.

[21] Timothy J. Purcell, Ian Buck, William R.Mark, and Pat Hanrahan. Ray tracing on pro-grammable graphics hardware.ACM Transac-tions on Graphics, 21(3):703–712, July 2002.

[22] J. Schmittler, S. Woop, D. Wagner, W.J. Paul,and P. Slusallek. Realtime ray tracing of dy-namic scenes on an fpga chip. InGraph-ics Hardware 2004. Eurographics Associa-tion, 2004.

[23] Jorg Schmittler, Ingo Wald, and PhilippSlusallek. SaarCOR: a hardware architecturefor ray tracing. InHWWS ’02: Proceedings ofthe ACM SIGGRAPH/EUROGRAPHICS con-ference on Graphics hardware, pages 27–36,2002.

[24] Jonathan Shade, Steven Gortler, Li wei He,and Richard Szeliski. Layered depth images.In SIGGRAPH ’98: Proceedings of the 25thannual conference on Computer graphics andinteractive techniques, pages 231–242, 1998.

[25] Jorg Schmittler Sven Woop and PhilippSlusallek. Rpu: A programmable ray process-ing unit for realtime ray tracing. InProceed-ings of ACM SIGGRAPH 2005, July 2005.

[26] Ingo Wald, Carsten Benthin, and PhilippSlusallek. Distributed interactive ray tracingof dynamic scenes. InProceedings of theIEEE Symposium on Parallel and Large-DataVisualization and Graphics (PVG), 2003.

[27] Ingo Wald, Thiago Ize, Andrew Kensler,Aaron Knoll, and Steven G Parker. Ray Trac-ing Animated Scenes using Coherent GridTraversal. ACM Transactions on Graphics,pages 485–493, 2006. (Proceedings of ACMSIGGRAPH 2006).

[28] Michael Wand and Wolfgang Straßer. Real-time caustics. In P. Brunet and D. Fellner,editors, Computer Graphics Forum, volume22(3), 2003.

[29] Daniel Wexler, Larry Gritz, Eric Ender-

ton, and Jonathan Rice. Gpu-acceleratedhigh-quality hidden surface removal. InHWWS ’05: Proceedings of the ACMSIGGRAPH/EUROGRAPHICS conference onGraphics hardware, pages 7–14, New York,NY, USA, 2005. ACM Press.

[30] Sven Woop, Gerd Marmitt, and PhilippSlusallek. B-KD Trees for Hardware Accel-erated Ray Tracing of Dynamic Scenes. InProceedings of Graphics Hardware, 2006.

[31] Chris Wyman. Interactive image-space refrac-tion of nearby geometry. InProceedings ofGRAPHITE, pages 205–211, 2005.

Figure 9: These Images depict from top to bottom.Shadows of a complex tree computed by our ap-proach, and a reflective bust of Niccolo da Uzzano.

Figure 10: Various renderings using the proposed GPU ray casting are shown. Note that the rightmostfigure in the middle row is one snapshot out of a GPU animation using vertex-skinning. In the last row weshow cubemap reflections (left) and reflections rendered with our method (middle) and with a software raytracer (right).