Efficient Implementation of Bi-Directional Path Tracer On

Efﬁcient Implementation of Bi-directional Path Tracer on GPU

Bc. Vilem´ Otte∗ Supervised by: RNDr. Marek Vinkler Ph.D.†

Faculty of Informatics Masaryk University Brno / Czech Republic

Abstract allowing for advanced materials, including textures and computing the entire image using the graphics hardware. Most of the implementations solving photo-realistic image The contributions of this paper are the following: rendering use standard unidirectional path tracing, having fast and accurate results for scenes without caustics • Design and implementation of three variants of bidi- or hard cases. These hard cases are usually solved by a rectional pathtracing on the GPU. bidirectional path tracing algorithm. However, due to the • Comparison of their speed and quality to the ground complexity of the bidirectional path tracing algorithms, truth path tracing solution. its implementations almost exclusively target sequential CPUs. The following paper proposes a new parallel im- • Comparison to other GPU based renderers. plementation of the bi-directional path tracing algorithm for the GPUs. Our approach is compared with existing so- lutions in terms of both performance and image quality. 2 Related Work As the references we use the standard unidirectional GPU path tracer and commercial off-line bidirectional path trac- In this section we summarize literature most relevant to ers. We achieve interactive rendering rates for scenes of bidirectional path tracing - various approaches to global medium complexity. illumination focused on parallel GPU algorithms. Keywords: bidirectional path tracing, path tracing, physically based rendering, ray tracing, CUDA 2.1 Ray Casting The core of almost every global illumination technique is ray casting, which allows for finding closest ray-primitive 1 Introduction intersection point along each ray and also to test visibility between two points. This visibility computation is the key Global illumination research recently focuses on unbiased to the evaluation of light transport. The focus of research methods. Unbiased method is such method, that under on ray casting are following three issues: selection of ac- some assumptions, converges to the solution of the ren- celeration structure, their construction and their traversal. dering equation. High performance and well established ray casting solu- One of the common techniques for rendering unbiased tions are available for public, including NVidia OptiX [11] images is path tracing, respectively the extension of path targeting NVidia hardware (which is actually full ray trac- tracing - bidirectional path tracing. These techniques are ing engine), Intel Embree [15] targeting traditional SIMD- well known for high quality rendering output. Formerly, based CPU architectures. Our implementation is based on most of the path tracing and bidirectional path tracing the open source framework by Aila et al. [1, 2]. implementations were done on the CPU. However, these techniques are well fit for massively parallel hardware, like the recent generations of graphics hardware. 2.2 Early Global Illumination Even though there are already present implementations Whitted [14] used ray-casting for generation of photo re- of bidirectional path tracing on the graphics hardware, alistic images, allowing for recursive specular reflections most of the implementations are either using the graphics and refractions. Later Cook extended ray tracing to dis- hardware only for small part of the computation or they do tributed ray tracing to allow for effects such as diffuse in- not contain any surface shading at all. terreflection [3]. The rendering equation was introduced The presented work focuses mainly on the implementa- in 1986 by Immel et al. [5] and Kajiya [7]. tion of a full featured bidirectional path tracing renderer, The rendering equation describes light transport in the ∗[email protected] scene. Light transport describes the energy transfers in a †xvinkl@fi.muni.cz given scene that affects visibility.

Proceedings of CESCG 2015: The 19th Central European Seminar on Computer Graphics (non-peer-reviewed) 2.3 Path Tracing and Bidirectional Path Trac- ing Path tracing algorithm allows for computing the solution of the rendering equation. By computing the paths of light from the camera into the scene (eventually reaching light source), it closely resembles the behavior of light. The path starts with primary ray at the camera and is traced into the scene. Upon intersection, in continues in random direction. For further efficiency, at each vertex of the path it is Figure 1: All possible connections between a light path determined whether path should be terminated or not by and camera path. 1. Represents camera path, 2. Repre- Russian roulette, thus preventing infinite path lengths. It sents light path, Dashed lines represent possible connec- allows for physically based computation of lighting, and tions between light path and camera path. so the synthesis of photo realistic images. The algorithm is also unbiased, with theoretically absolute accuracy when using infinite number of samples. Standard (Explicit) Path Tracing Due to very bad con- Bidirectional path tracing is further extension of path vergence ratio using naive path tracing, it is often under- tracing algorithm, introduced by Veach [12]. By gener- stood that generic path tracing algorithm does single ex- ating one sub path from a light source and one sub path plicit step towards light on each vertex of the path. These from the camera, later joining them together, it is possible path tracers are to be designated as standard, or explicit, to handle indirect lighting computation more robustly (and path tracers. efficiently) compared to ordinary path tracing. Further- For the sake of completeness, pseudo algorithms for more, this modification still keeps the resulting algorithm standard path tracing (see Algorithm 1) and bidirectional physically based and unbiased. path tracing (see Algorithm 2) are provided. Bidirectional path tracing, computes two paths, one 2.4 Other Global Illumination Methods from the light and another one from the camera. These paths are later connected (see Figure 1). These connec- Lately a lot of fast algorithms for computation of global il- tions attempt to solve several problems introduced by uni- lumination were introduced. Most of the algorithms were, directional path tracers: compared to path tracing, biased, providing a trade off between rendering quality and speed. Small light sources For naive path tracers, the probabil- Recent interactive global illumination methods are ity of hitting a light source is proportional to its size. Hav- modifications of Virtual Point Lights, introduced by Keller ing point lights (lights that are infinitely small) in naive et al. [9], allowing for real time smooth global illumina- path tracer often ends up with nothing visible in rendered tion [10] image, as the probability of hitting the light source reaches One of the other popular global illumination techniques, zero. used in real time rendering, are Cascaded Light Propaga- This can be solved by sampling light in explicit man- tion Volumes [8]. ner each step in path computation, resulting in very fast Photon mapping introduced by Jensen [6], is currently convergence for directly lit scenes. While sometimes this popular in production renderers, especially for interior technique is referred as explicit path tracing, it actually is rendering. The technique was further extended into pro- a special case of bidirectional path tracing, where the light gressive photon mapping [4]. Compared to standard pho- path contains only a single vertex. ton mapping, which is a biased rendering algorithm, pro- The visibility function between each camera path vertex gressive photon mapping is an unbiased one. and light path vertex has to be computed, resulting in 2 · N cast rays for camera path length of N. For bidirectional path tracing, even more complex paths 3 Bidirectional Path Tracing from the light can be easily evaluated, e.g. light hidden inside a lamp. This section presents some improvements when using bidirectional path tracing. For proper description of these Interior scenes lit by exterior light Assuming we are features it is critical to define some terms. inside a room, where there is only a single window, standard, or even explicit, path tracers are not going to con- Naive Path Tracing This designation is used for path verge very quickly because the probability of sampling the tracers that does not do any explicit steps, but wait for light is low. In fact, in case where no path vertex on cam- camera ray to actually hit light (or get terminated). era path lies in direct light, the contribution of that path is

Proceedings of CESCG 2015: The 19th Central European Seminar on Computer Graphics (non-peer-reviewed) Algorithm 2 Bidirectional Path Tracing 1: procedure BIDIRPATHTRACE 2: for each path: 3: Generate vertex on random light 4: Push this vertex to light path 5: ray ← setup light ray 6: while ray.terminated = false do 7: result ← raycast(ray) 8: if result.hit = false then 9: ray.terminated ← true 10: else Figure 2: Difference between path tracer and bidirectional 11: Push this hitpoint to light path path tracer when computing caustics. On the left side, 12: if Russian roulette terminates path then the fireflies generated by standard path tracer compared to 13: ray.terminated ← true more smooth caustics generated by the bidirectional path 14: ray ← setup primary ray tracer on the right side. 15: while ray.terminated = false do 16: result ← raycast(ray) 17: if result.hit = false then zero. This is one of the so called ’pathological scenarios’ 18: Accumulate background color for path tracing, where the algorithm fails to provide result 19: ray.terminated ← true fast enough. 20: else Using a bidirectional path tracer with light path of 21: Compute contribution by joining light path length M, it is enough that single point of the light path 22: with this vertex is directly visible from any of the camera path vertices. If 23: if Russian roulette terminates path then this condition is true, that paths’ contribution will be non- 24: ray.terminated ← true zero, resulting in faster convergence. 25: else 26: ray ← Get B*DF Sample Caustics convergence Using a unidirectional path tracer often results in poor caustics and fireflies in the resulting image, as their convergence rate is by magnitudes 3.1 Parallel Bidirectional Path Tracing using worse to convergence rate of diffuse light. Computing GPU caustics with bidirectional path tracer is faster (see Fig- ure 2), yet there are still difficulties with reflected caustics. Computation of different samples, (sub)paths in terms of Bidirectional path tracer can be, however, further extended path tracing, and different pixels is independent on each with Metropolis Light Transport [13], improving the per- other. Path tracing and also bidirectional path tracing are formance on reflected caustics. therefore good candidates for massively parallel computation. Algorithm 1 Path Tracing The resulting parallel algorithm looks similar to sequen- 1: procedure PATHTRACE tial version. The parallel run is performed over the pixels, 2: for each path: with each sample is computed by a single thread in a single 3: ray ← setup primary ray kernel launch. 4: while ray.terminated = false do 5: result ← raycast(ray) 6: if result.hit = false then 4 Implementation 7: Accumulate background color The bidirectional ray tracing kernels were implemented 8: ray.terminated ← true on top of open source framework by Aila. For this pur- 9: else pose, new rendering kernels for each variant of bidirec- 10: Compute and Accumulate surface emission tional path tracer were added. 11: Compute contribution of random light To achieve high performance of the source code, the 12: if Contribution is non zero then speculative while-while traversals were used. As oppos- 13: Accumulate contribution ing to persistent threads they perform, in general, better 14: if Russian roulette terminates path then on new hardware. Also, bounding volume hierarchy with 15: ray.terminated ← true spatial splits was used as acceleration structure for the ren- 16: else dering. 17: ray ← Get B*DF Sample The Aila framework was further extended to support high resolution textures, reflective, refractive and dielec-

Proceedings of CESCG 2015: The 19th Central European Seminar on Computer Graphics (non-peer-reviewed) tric materials. Light sources are handled as geometry 5.2 Path pre-generation with emissive material, so in general any number of light sources is supported. Given a static scene, all the light paths can actually be pre- The bidirectional path tracer kernel always processes computed. Later, during the execution of the algorithm, one pixel in single walk through, e.g. the light path gen- we only select one of the light paths from given M pre- eration (storing required data), followed by computation computed light paths. of the camera path. During each step of the camera path While this approach is highly efﬁcient, it often means computation the join for currently processed vertex is per- that the resulting algorithm is biased. This can be over- formed when necessary. come by re-generating these light paths on runtime. Once we start joining samples to random pre-generated paths, it is possible that some samples are to be joined with a single 5 Optimizations and Limitations light path. This could lead to unnatural patterns in resulting image, and of course breaking unbiased nature of the The following section describes possible optimizations algorithm. By re-generating the paths after they have been and limitations when implementing bidirectional path used, it is possible to avoid this problem. tracer on the GPU. For each optimization a brief summary Unless large M is selected, the quality of resulting im- is given. age can be highly degraded. To keep the quality of the resulting image high enough, it was experimentally evaluated that the number of light paths must be at least the 5.1 Sub path join same as the number of pixels in the resulting image.

Full join 5.3 Biasing Joining of the light sub path of length M and the camera sub path of length N is a non trivial task. There are mul- Biasing the algorithm does not have much sense for simu- tiple ways to join these, the intuitive solution is joining lations. Although, for performance heavy applications, in each vertex from light sub path to each vertex in camera case where we have limited time for calculating an image, sub path. While this actually leads to faster convergence, for example in games, it is possible to trade off quality for N · M rays have to be used to compute the visibility be- speed. tween samples, which is slow. Moreover, the full light During the implementation, two of the biasing tech- path has to be stored in the memory, and so larger memory niques were considered. space is required.

Limiting maximum camera path length Generally, the Single-step join camera path length can be very long (assuming it doesn’t Performance wise, the most efficient idea is joining the directly hit the light), until Russian Roulette finally termi- last camera sub path vertex and the last light sub path ver- nates the path. tex. Such approach has some advantages. Single path By limiting the length of camera path to some value it computation is of the same performance as naive path trac- is possible to increase performance. First of all, longer ing, although improving the situations where naive path paths generally tend to have smaller contribution, by end- tracing has major problems. However, by combining only ing them at some given maximum length we terminate the ends of both paths contributions of these light paths are them early, effectively reducing the number of computa- very small. tions they need to do. Also, from the GPU perspective, we are always waiting K-step join for the longest path to finish the computation, in the worst It is also possible to select an approach using random- situation, whole warp is waiting for single thread to finish ized algorithm. For each of the N · M joining rays, the a very long path. By bounding the maximum length, we algorithm discards some of these joins. The actual join- effectively reduce this issue and increase the computation ing ray rejection can be built upon multiple criteria - either performance. fully random, or deterministic (removing less contributing joins and accordingly weighting the rest). This join is to On the other hand, the unbiased nature of the algo- be designated as K-step join. The join is performed by rithm is lost, by limiting the maximum path length we taking each vertex from camera against k vertices from the are effectively limiting the maximum number of reflec- light path. The k value has to be smaller than the number tions/refractions, which may cause visible problems in im- of vertices in the light path. ages (for example, missing reflection).

Random Number Generation As each Monte-Carlo When implemented properly, the different sub path technique, path tracing and bidirectional path tracing, joins do not break the unbiased property of the algorithm. heavily depend on random number generation. Having a

Proceedings of CESCG 2015: The 19th Central European Seminar on Computer Graphics (non-peer-reviewed) random number generator with large period means, that Path Tracing Bidirectional resulting image will converge closely to the ground truth. Each Monte-Carlo technique spends some amount of time in random number generator. If the application tar- gets performance instead of precision, it is possible to pre- generate random numbers into an array and use those later. Doing so introduces a limit at which the image is not 5s able to converge more towards the ground truth (as all the RMSE 0.1002 0.0628 samples were already taken). It is important to note that the results taken using the implementation were recorded with unbiased version of the algorithms. The biased version is between 2 and 3 times faster compared to unbiased version.

10s 6 Results RMSE 0.0784 0.0456

6.1 Evaluation and Analysis Table 1: comparison between Path Tracing and Bidirec- tional Path Tracing with full path join. Results of the implementation were evaluated on low-end laptop GPU NVidia GeForce 720M, with 1.5 GB memory. The system was running under Windows 8.1 OS, with compared to standard path tracing. This is especially the CUDA 5.5 installed. Kernels were compiled with com- case for caustics. pute capability 2.0. The light paths were generated on the runtime. Crytek Sponza A low end GPU was used to demonstrate, that even cur- The following scene shows complex materials, like tex- rent generation laptop based GPUs are capable of interac- tured, alpha-tested, reflective and refractive surfaces, lit by tive rendering of moderately complex scenes. an area light source. The rendered images were taken each 5 seconds, while All three different bidirectional kernels were run on this the used algorithm was running progressively. Results pre- scene, and the results show how the scene looked after 5 sented in this section show the difference in quality be- seconds of processing. All the results are compared to the tween the specific implementations. The resulting images ground truth in terms of RMSE (see Table 2). are also compared to ground truth using the root mean We observed the same behavior in all of our measure- square error (further RMSE, lower is better). ments, full path join results in best image quality and The first set of comparisons is between path tracing fastest speed. This shows, that the algorithm is not bound and bidirectional path tracing. Followed by comparison by memory performance, in which case K-step join or sin- against other GPU based Monte-Carlo rendering systems. gle step join would result in higher performance and thus quality on a fixed budget. The single-step join does need to keep just a single (last) vertex of the light path. K-step join needs to keep K ver- Caustics Test tices of the light path in the memory during the compu- We also ran three different bidirectional kernels, as well tation, while full join needs to keep all the vertices in the as standard path tracing method, on a scene with a caus- light path. While single-step join and K-step join have tic. The results show how the scene looked after 5 and 10 constant memory footprint, the full join footprint grows seconds of processing (see Table 3). with the length of the light path. The full path join also results in the highest quality caustics, that are almost perfectly smooth after ten seconds of 6.2 Bidirectional vs. Unidirectional computation.

6.3 Other GPU rendering packages Cornell Box We ran two algorithms on the following scene, bidirectional path tracing (with full path join) and standard path iRay tracing. Both of the resulting images are compared to the NVidia iRay is a physically based renderer highly scal- ground truth. The sample images were taken after 5 sec- able in performance across GPUs and CPUs. We rendered onds and after 10 seconds. (see Table 1) the Crytek Sponza scene using our bidirectional path trac- From the given comparison, it can be stated that bidirec- ing renderer and the iRay from a similar viewpoint (see tional path tracing with full path joining converges faster Table 4).

Proceedings of CESCG 2015: The 19th Central European Seminar on Computer Graphics (non-peer-reviewed) NVidia iRay Bidirectional

Renderer Image RMSE

Single-step 0.1584

10s

Table 4: Comparison between iRay and our bidirectional K-step (K=3) 0.0701 path tracing implementation. The brightness/contrast difference is caused by different handling of output between both implementations.

Again we target images generated after 5 and 10 sec- Full 0.0095 onds, which shows the quality achievable using an interactive preview on low end graphics card. Table 2: Equal-time comparison between three different The resulting images are untextured, as there is not a implementations of bidirectional path tracing and their dis- full support for textured surfaces in iRay, and the scene tance to ground truth in terms of RMSE. was lit using single directional light. This setting also allows for an easier comparison of the quality of the global illumination without the masking effect of the textures. The technique iRay uses is actually standard path tracing, in comparison it is clearly visible that our Bidirec- tional technique produces smoother results for a similar time budget. Renderer 5s 10s LuxRender LuxRender is a physically based and unbiased rendering engine. The LuxRender package was used through Blender software, possibly limiting some options leading Single-step to slightly decreased quality (see Table 5). LuxRender uses a technique called LuxRays to produce the image, it is an unbiased technique similar to bidirectional path tracing. The implemented bidirectional solution might seem to converge better, although it is important K-step (K=3) to state, that LuxRender is a very large package supporting complex material setup (along with subsurface scattering effects for example), while the implemented solution does not. Full

Table 3: Comparison of a caustic scene with three different implementations of bidirectional path tracing. The contrast was intentionally enhanced so it is possible to see the difference in sampling inside caustics casted by a glass sphere. Single step join has very slow convergence and so the resulting image is darker compared to the others.

Proceedings of CESCG 2015: The 19th Central European Seminar on Computer Graphics (non-peer-reviewed) LuxRender Bidirectional Report NVR-2012-02, NVIDIA Corporation, June 2012. [3] Robert L. Cook, Thomas Porter, and Loren Carpen- ter. Distributed ray tracing. In Proceedings of the 11th Annual Conference on Computer Graphics and Interactive Techniques, SIGGRAPH ’84, pages 137– 10s 145, New York, NY, USA, 1984. ACM. [4] Toshiya Hachisuka, Shinji Ogaki, and Henrik Wann Jensen. Progressive photon mapping. ACM Trans. Graph., 27(5):130:1–130:8, December 2008. [5] David S. Immel, Michael F. Cohen, and Donald P. 20s Greenberg. A radiosity method for non-diffuse envi- ronments. SIGGRAPH Comput. Graph., 20(4):133– Table 5: Comparison between LuxRenderer and our 142, August 1986. bidirectional path tracing implementation. The brightness/contrast difference is caused by different handling of [6] Henrik Wann Jensen. Global illumination using pho- output between both implementations. ton maps. In Proceedings of the Eurographics Work- shop on Rendering Techniques ’96, pages 21–30, London, UK, UK, 1996. Springer-Verlag. 7 Summary [7] James T. Kajiya. The rendering equation. In Com- Path tracing, in general, excels in exterior scenes or when puter Graphics, pages 143–150, 1986. there are large light sources. Bidirectional path trac- [8] Anton Kaplanyan and Carsten Dachsbacher. Cas- ing is an extension that allows for faster computation of caded light propagation volumes for real-time indi- more complex situations, like interior scenes or small light rect illumination. In Proceedings of the 2010 ACM sources. SIGGRAPH Symposium on Interactive 3D Graphics The created GPU-based implementation showed, that and Games, I3D ’10, pages 99–107, New York, NY, bidirectional path tracing is also suitable for massively USA, 2010. ACM. parallel implementation. The results confirmed, that convergence rates are in general better for bidirectional path [9] Alexander Keller. Instant radiosity. In Proceed- tracer, which effectively reduces computation time. ings of the 24th Annual Conference on Computer Full path joining proved to lead to the highest quality Graphics and Interactive Techniques, SIGGRAPH global illumination, although keeping large memory foot- ’97, pages 49–56, New York, NY, USA, 1997. ACM print. However, on modern GPU architectures, the mem- Press/Addison-Wesley Publishing Co. ory footprint required by full path joining is bearable. [10] Jaroslav Krivˇ anek,´ Iliyan Georgiev, Toshiya K-path join proved to be an interesting alternative to full Hachisuka, Petr Vevoda,´ Martin Sik,ˇ Derek path join. Even though the full path join actually results in Nowrouzezahrai, and Wojciech Jarosz. Uni- better convergence rates, it is possible to alter the number fying points, beams, and paths in volumetric of joins for K-join on the fly. This can be used to achieve light transport simulation. ACM Trans. Graph., a constant refresh rate when running the algorithm in pro- 33(4):103:1–103:13, July 2014. gressive mode. Such approach can be interesting for interactive preview of rendered scene. [11] Steven G. Parker, James Bigler, Andreas Dietrich, Heiko Friedrich, Jared Hoberock, David Luebke, David McAllister, Morgan McGuire, Keith Morley, References Austin Robison, and Martin Stich. Optix: A general purpose ray tracing engine. ACM Trans. Graph., [1] Timo Aila and Samuli Laine. Understanding the ef- 29(4):66:1–66:13, July 2010. Proceedings ficiency of ray traversal on gpus. In [12] Eric Veach. Robust Monte Carlo Methods for Light of the Conference on High Performance Graphics Transport Simulation. PhD thesis, Stanford, CA, 2009 , HPG ’09, pages 145–149, New York, NY, USA, 1998. AAI9837162. USA, 2009. ACM. [13] Eric Veach and Leonidas J. Guibas. Metropolis light [2] Timo Aila, Samuli Laine, and Tero Karras. Under- transport. In Proceedings of the 24th Annual Con- standing the efficiency of ray traversal on GPUs – ference on Computer Graphics and Interactive Tech- Kepler and Fermi addendum. NVIDIA Technical niques, SIGGRAPH ’97, pages 65–76, New York,

Proceedings of CESCG 2015: The 19th Central European Seminar on Computer Graphics (non-peer-reviewed) NY, USA, 1997. ACM Press/Addison-Wesley Pub- lishing Co. [14] Turner Whitted. An improved illumination model for shaded display. Commun. ACM, 23(6):343–349, June 1980.

[15] Sven Woop, Louis Feng, Ingo Wald, and Carsten Benthin. Embree ray tracing kernels for cpus and the xeon phi architecture. In ACM SIGGRAPH 2013 Talks, SIGGRAPH ’13, pages 44:1–44:1, New York, NY, USA, 2013. ACM.

Proceedings of CESCG 2015: The 19th Central European Seminar on Computer Graphics (non-peer-reviewed)