Using a Multithreaded Forward Path Tracer in C++ and OpenMP

(1)

Examining the effects of SPP in Monte Carlo Path Tracing

Using a Multithreaded Forward Path Tracer in C++ and OpenMP

Undersökning av SPP och dess påverkan inom Monte Carlo Path Tracing

TIM WAYBURN

KTH

SKOLAN FÖR ELEKTROTEKNIK OCH DATAVETENSKAP

(2)

ii

Abstract

This paper involves implementing a forward path tracer in C++ using OpenMP in order to examine the effects of Samples per Pixel (SPP) on output images given in different environments. Output images of scenes with different amounts of lighting are rendered in different resolutions. These renders are timed and output images are saved to files. Looking at these results, varying the SPP-value results in drastic changes in render time and image quality. Such performance differences ultimately affect the possibilities for the developed path tracer and its applications.

(3)

Sammanfattning

Denna rapport undersöker effekten av Samples per Pixel (SPP) på ren- derade bilder genom implementerandet av en forward path tracer i C++. Bilderna består av olika scener med olika ljustyrkor i olika bild- storlekar. Dessa resultat visar att ändring av SPP-värden leder till dras- tiska förändringar i bildkvalitet och renderingstid. Dessa faktorer på- verkar i slutändan möjligheterna till vidare appliceringar av path tracer implementationen

(4)

Introduction

Computer graphics have grown to become a very important aspect of different industries in a world of technology. The standard for realistic graphical simulations have gone from drawing a few vectors on a screen to the use of photorealistic simulations in everyday situations in less than a century. The demand for even greater realistic repre- sentations however still persists as large corporations spend hundreds of millions on developing hardware and software that enables us to achieve such simulations.[17, 16] The products of computer graphics research are used in everything from further research at medical insti- tutes to video-games.

One of the core aspects involved in computer graphics is rendering.

It can be defined as the automatic process of generating an image from a given 2-D or 3-D data structure, commonly referred to as a scene.

Given geometrical, lighting, shading, texture and other relevant data, a rendering program processes such data into the output of a digital image or several images in the form of a simulation.

There are several state-of-the-art rendering techniques, including the popular rasterization and ray tracing techniques, which both come in different levels of implementation levels. Another rendering technique, called path tracing, utilizes the so called Monte-Carlo algorithm in order to produce images faithful to reality.

1

(8)

2 CHAPTER 1. INTRODUCTION

1.1 Purpose

Different rendering techniques best fit different types of problems, and there are many different ways to code each rendering algorithm. While one rendering implementation may be faster than another, the other might produce higher quality output images than the first. The aspect considered more essential may also differ, depending on whether it is a reference image or a real-time simulation that the rendering program is being developed for. Therefore it is essential to adapt the code of one’s rendering program and choose a technique depending on the problem one is trying to solve.

One of the variables that alters both the image-quality and time performance of a Monte Carlo Path Tracing program is the Samples Per Pixel (SPP) used. The SPP-constant decides how many random Monte Carlo samples are used for each pixel in the output image. The greater the SPP, the greater the accuracy. The lower the SPP, the lower the accuracy. Acknowledging the behavior of such an indipendent vari- able, what is the sufficient SPP-count for generating images of certain quality? How large SPP-values can one use before time performance suffers and real-time simulations become infeasible?

Figure 1.1: Demonstration of SPP effect on time performance and image quality by Kevin Beason [3].

1.2 Research Question

How does variating the Samples Per Pixel (SPP) affect image quality and time performance in a Monte Carlo Path Tracing program?

(9)

1.3 Scope & Limitations

The goal of this paper is to conduct an experiment that involving rendering images of a given scene and examining them. By creating a path tracing program that allows the user to create different images based on different SPP and time limit as input, a plethora of images will be created based on the two indipendent variables: time and SPP- value.

There are many variables that will affect the quality of rendering in a path tracer in such an experiment. The implementation quality will highly unlikely match that of state-of-the art path tracers since it will be developed by the author of this thesis over the course of a few months as described in section 3.0.1. Such a naive implementation of a path tracing algorithm might lead to anomalies and misrepresentative conclusions if compared to those of eg. high-grade bidirectional path tracers developed by large companies. It is important to note that the results drawn will be specific to the developed implementation.

The scope of images to be rendered is also limited by the equipment provided to regular students at KTH (school computer personal com- puters). This will lead to the exclusion of rendering of images SPP- values over a certain value for they require computational power of such size that rendering them would require a time frame of several hours. In addition to this SPP-cutoff, the rendered scenes will contain basic shapes and lights as defined in 3.0.2. The experiment will be limited to one scene containing only specular and diffuse surfaces.

1.4 Definitions

Rendering Algorithm/Rendering Technique - The algorithm/technique used to render an image eg. The Path Tracing Algorithm

Samples Per Pixel (SPP) - The count of random samples used per pixel during Monte Carlo integration in the path tracer

Bidirectional reflectance distribution function (BRDF) - The function which defines how light is reflected upon an opaque surface

(10)

4 CHAPTER 1. INTRODUCTION

Open Multi-Processing (OpenMP) - An API used for parallel programming in C, C++ and Fortran

Multithreading/Parallel Programming - The ability to execute several processes/threads simultaneously, thus allowing for optimization of a program.

Application Programming Interface (API) - A set of tools, definitions and protocols for buidling software.

Graphical Noise/ Variance - The unwanted disturbance/imperfections in image quality when rendering images as a result of the Monte- Carlo sampling.

RNG - Random Number Generator

(11)

Background

2.1 Rendering

2.1.1 Ray tracing

One of the first image synthesis methods has its origins rooted in the concepts of physics. Traditionally, when physicists designed lenses, they would plot rays of light on paper, starting at a light source, pass- ing through the lense and beyond. It is from this concept which was also named "ray tracing" that the rendering technique ray tracing stems from. [7] Towards the beginning of the 21st century, such a concept would grow to become one of the most popular, powerful and simple techniques in image synthesis. The power of the ray tracing algorithm can handle many different kinds of optical effects to the point of great realism.[7] Turner Whitted can be acclaimed for large parts of the recursive ray tracing algorithm, where rays are traced and generate three new types of rays (reflection, shadow and refraction) upon the closest image object that the ray intersects. Shadow rays can be traced towards each light source. This recursive algorithm allows for greater realism in the rendering of images using ray tracing.[15]

Figure 2.1 displays the possibilities of a state-of-the-art ray tracer by NVIDIA that uses artificial intelligence in order to reduce noise. By training a neural network using 15,000 image pairs from 3,000 different scenes on their supercomputer, they have created a network that takes fractions of a second to clean up noise in any image.[10]

5

(12)

6 CHAPTER 2. BACKGROUND

Figure 2.1: Demonstration of NVIDIA’s Iray technology [10].

2.1.2 Path Tracing

Path tracing may be seen as an extension or variant of ray tracing.

It is a fuller global illumination algorithm that involves stochastically sampling all light paths. Dependent on the surface of objects, the illu- minance of each pixel is reduced by a surface-specific BRDF in order to determine how much is reflected towards the camera. The described process is then repeated for every point or pixel in the output image.

Due to its stochastic nature, it can be characterized as unbiased. De- pendent on the model of BRDFs, cameras and light sources, path tracing may produce images indistinguishable of that from photographs.

(13)

Figure 2.2: Example of image created using Octane Render; Path Trac- ing, 3000 SPP, render time: 40 minutes [4]

Figure 2.2 illustrates how realistic of an image can be created in 40 minutes using the GPU-based rendering software Octane Render program that supports path tracing.

(14)

The Render Equation

The concept of path tracing was introduced by James Kayija in The Rendering Equation. It can be described as the integral equation in which the statement in figure 2.3 holds.

Figure 2.3: The render equation as defined in The Render Equation[9]

Figure 2.4 illustrates a geometrical representation of the formula in fig- ure 2.3. It shows how the total amount of light emitted from a point x along a view direction given a function from light sources and a BRDF for the object surface of the point x.

Figure 2.4: A geometrical representation of the render equation equation[5]

The method for implementing the given render equation into a path tracer can result in several different solutions. A conventional forward path tracer involves recursively evaluating the render equation using Monte Carlo integration. These implementations may however be slow to converge when there is a lot of indirect lighting since shadow rays target light sources. In order to combat such issues one may want to implement a bidirectional path tracer, which evaluates the path integral formulation of the rendering equation. This allows each sample to

(15)

be formulated as a product of several subpaths. One subpath is traced from the light source and the other from the camera. Though these might be harder to implement, bidirectional path tracers should converge at a faster rate than forward path tracers in scenes with plenty of indirect light.[14]

Russian Roulette & Random Number Generation

In order to implement a Monte Carlo simulation into a path tracer, a Russian Roulette technique may well come into handy. One way of implementing such a technique is to declare a probability ε ∈ (0, 1) . At each recursive evaluation of a ray, that is every time the ray bounces, the ray has a probability ε of terminating. In order to make sure that the path will terminate, it might be good to increase the probability af- ter each step of recursion. In order to also prevent the ray trace terminating too early, one can declare that the ray path will only terminate at a minimum level of recursion. Such an implementation of Russian Roulette allows us to terminate ray paths without systematic bias.

Cosine Weighted Sampling

A method for reducing variance in path tracing is by introducing weighted importance sampling in the Monte Carlo shooting illumination algorithm. Figure 2.5 and 2.6 illustrate how weighted importance sampling can be intoduced into the Monte Carlo quadrature evaluation formula, thus allowing for greater convergence in a path tracer, and greater re- duction of variance as suggested by Balázs, Szirmay-Kalos, György.[2]

Figure 2.5: The classical Monte Carlo quadrature evaluation formula.[2]

(16)

Figure 2.6: Weighted importance sampling quadrature formula.[2]

Figure 2.7: Cosine weighter hemisphere sampler in code. [6]

A simple way of introducing such a concept to a path tracer is dis- played in figure 2.7 by Rory Driscoll [6]. Here, a hemisphere sampler is used with cosine weighting. Uniform points are generated on a disk and then projected up on the hemisphere. Samples on areas of the integral which will get multiplied out by a cosine term (bottom of the hemisphere) are avoided by choosing proportionally fewer samples in those areas.

Bidirectional Reflectance Distribution Function

A Bidirectional Reflectance Distribution Function (BRDF) is a function that defines how light is reflected off an opaque surface. The relevance of such a function when constructing a path tracer is so that one can understand the behavior of each ray as it hits an object. There are several models of reflections for different surfaces. The ones discussed in this paper are diffuse and specular BRDFs which are both described in Geometrical Considerations and Nomenclature for Reflectance.

A perfectly diffuse or "lambertian" surface is one for which the re-

(17)

flected radiance is isotrophic with the same value for all directions as described in figure 2.8.

Figure 2.8: Perfect diffuse reflection BRDF. [13]

Figure 2.9: Perfect diffuse reflection BRDF. [13]

A perfect specular "mirror-like" surface will for each incidental ray create a corresponding reflected ray as described in figure 2.9.

(18)

Figure 2.10 illustrates how both specular and diffuse rays would re- act upon bouncing off a surface. In part (a), we can see how an incident ray results in an even spread of illumination in a certain angle range of the given surface normal. In part (b), we can see how an incident ray results in the single outgoing reflection, with a line of symmetry along the normal vector. There are many ways to implement such formulas into a path tracer, and depending on programming language, hardware and other variables, performance of such calculations will vary.

Note that there are more complex and alternative models of surface reflections. These will however not be described or used in this report.

Figure 2.10: Perfect diffuse(a)/specular(b) reflection illustration. [1]

2.1.3 OpenMP

OpenMP is an API that can be used for multiprogramming in C++ on several platforms. It includes compiler directives and library routines that influence runtime behaviour. It uses scalable models which allows it to serve as a suitable platform for low-level computer graphics programming.[11]

(19)

2.1.4 Related Work

There are many state-of-the-art path tracers such as IRay by NVIDIA.

However, these types of technologies are cutting-edge and are therefore most probably unavailable to the general public. For naive implementations, there are tons of path tracers and small optimizations scat- tered around the web in the form of individual projects on eg. GitHub or open source technologies such as Mitsuba Renderer [8]. Much of the mathetmatics behind state-of-the art path tracers should also be avail- able in the form of research papers, such as the Rendering Equation.

Regarding related work to the experiment to be conducted in this paper, there is not much to relate to in terms of the research question it- self, but rather the development of a path tracer and its optimisations in general.

(20)

Chapter 3 Methods

3.0.1 Creating a Path Tracer

The path tracer used in this report is developed by the author of the report. It has been developed as a forward path tracer according to the state-of-the-art concepts descriped in the Background 2 section. These include:

• Russian Roulette algorithm with Pseudo-Random Number Gen- erationusing the C++ built-in mt19937 Mersenne Twister.

• Cosine Weighted Hemisphere Sampling

• Two BRDFs: Diffuse and Specular.

• Multithreading using the OpenMP API

It will be adapted to measure time elapsed rendering each image, as well as generate images of given SPP-values and resolutions. The ability to create own scenes using planes and spheres is implemented. The path tracer is developed using C++.

The developed implementation of a path tracer might be too naive to be representational of state-of-the art path tracer algorithms which most probably outperform the one used in this thesis. Though it might be naive, it should nevertheless be optimized and able to render images of realistic quality within reasonable time limits.

14

(21)

3.0.2 Creating a scene

The path tracer developed is able to produce two general objects, planes (which appear as walls) and spheres. Each of these objects have color and light emittance. In this experiment, two different scenes will be rendered. One will be a well lit room (Scene 1) with plenty of indirect light consisting of:

1. Five Planes/Walls - ceiling, floor, left wall, right wall, back wall 2. Three Spheres - One diffuse, one specular, one specular used

purely as light source

The other scene (Scene 2) will be a bit darker, simple and consist of:

1. One Plane/Wall - floor

2. Three Spheres - One diffuse, one specular, one specular used purely as light source

3.0.3 Rendering Images

Each of the scenes described in 3.0.2 will be rendered in a 1920x1920 pixel resolution in order to represent a state-of-the-art resolution commonly used at the time of this experiment.[12] Each scene will be rendered using a series of SPP values increasing from 1 to 10,000. De- pending on the render time for an image, certain images might not be able to be produced due to time restrictions. In order to prevent bias, all images will be rendered on a KTH school computer on the same day.

3.0.4 Evaluating the Rendered Images

Based on the two outputs of every image based on the variables of SPP/image resolution:

1. Image quality 2. Render time

We will then be able to construct tables, graphs plotting the efficiency of each SPP-value based on a resolution and create sets of render images which can then be discussed.

(22)

Chapter 4 Results

In this chapter, the results of the experiment will be presented. The render time and SPP for each rendered image is presented along with sample images of what each scene looks like in its most detailed render image. Due to the inability to render Scene 1 in very high SPP’s in reasonable time, a third test 4.3 has been conducted rendering Scene 1 in smaller resolutions as well.

4.0.1 Scene 1 (Well-lit Room) - 1920x1920 pixels

4.1 shows the render times for images in Scene 1. All rendered images can be found in appendix A. Figure 4.2 displays a line plot of render time for different SPP values.

Table 4.1: Scene 1 - Render times per SPP SPP (int) Render Time (s)

1 3.72215

2 6.80958

3 9.33795

4 12.5959

5 14.6316

10 30.3686

25 72.2873

50 138.636

100 273.045

300 807.829

16

(23)

Figure 4.1: Sample image of Scene 1 rendered with 300 SPP, 1920x1920 pixels

Figure 4.2: Graph plot of Render Time based on SPP

(24)

18 CHAPTER 4. RESULTS

4.0.2 Scene 2 (Dark Plane) - 1920x1920 pixels

Figure 4.3: Sample image of Scene 2 rendered with 5000 SPP, 1920x1920 pixels

4.2 shows the render times for images in Scene 1. All rendered images can be found in appendix B. Figure 4.4 displays a line plot of render time for different SPP values.

(25)

Table 4.2: Scene 2 - Render times per SPP SPP (int) Render Time (s)

1 1.02832

2 1.08934

3 1.50373

4 1.79107

5 1.97855

10 3.2592

25 6.90258

50 12.345

100 24.7456

200 45.9789

300 70.4569

400 92.5701

500 113.511

850 196.275

1000 224.996 1500 331.191 2000 435.953 5000 1087.74

(26)

20 CHAPTER 4. RESULTS

4.0.3 Scene 3 (Well-lit room)- 100x100 pixels

Figure 4.5: Sample image of Scene 1 rendered with 10,000 SPP, 100x100 pixels

4.3 shows the render times for images in Scene 1 with a minimized resolution size. All rendered images can be found in appendix C. Fig- ure 4.6 displays a line plot of render time for different SPP values.

(27)

Table 4.3: Scene 1 Minimized resolution - Render times per SPP SPP (int) Render Time (s)

1 0.0475822

2 0.0652689

3 0.0723216

4 0.0554831

5 0.0882531

10 0.120979

25 0.256765

50 0.456863

100 0.867595

200 1.69358

300 2.50091

400 3.32476

500 3.89516

850 6.99812

1000 8.23258 1500 12.3428

2000 16.106

5000 38.7206 10000 77.4823

(28)

Chapter 5 Discussion

In this chapter, the reason for the outcomes presented in the results 4 section will be revised and discussed. Considering the research question, what did the outcomes of our specific path tracer tell us about SPP choices we should make, assuming we were to use the developed path tracer for a purpose.

5.0.1 Result Analysis

Scene 1 - 1920x1920 pixels

The first render of Scene 1 rendered in times from around 3.7 seconds (1 SPP) to 808 seconds (300 SPP) as seen in table 4.1.

Scene 2 - 1920x1920 pixels

The rendering of Scene 2 ran much faster than Scene 1 with times rang- ing from around 1.03 seconds (1 SPP) to 70.46 seconds (300 SPP) to 1087.74 seconds (5000 SPP). The much fast rendering allowed for many more renderings to be produced as seen in table4.2.

Scene 1 Minimized - 100x100 pixels

Scene 1 was therefore also rendered in a much smaller resolution of 100x100 pixels and generated render times between around 0.048 seconds (1 SPP) to 2.50 seconds (300 SPP) to 77.48 seconds (10,000 SPP) as seen in table 4.3.

As we can see in the graph plots for each render test in 4.2, 4.4 and

22

(29)

4.6 the result of varying the SPP for a given scene and resolution results in a linear impact on render time. Though not so astounding on its own, this linear function can be useful if a SPP cutoff is to be made.

Comparing the results from different resolutions of Scene 1 4.14.3, render time at 300 SPP is over 300 times faster on a 100x100 pixel resultion compared to one at 1920x1920 pixel. This will definetely effect the ca- pabilities of our path tracer.

The difference in time between different scenes of the same resolution are also worth noting. In 1920x1920 pixels, Scene 1 renders around 3.6 times slower at 1 SPP and 11.5 times slower at 300 SPP.

5.0.2 SPP Cutoff

An optimal SPP value can be seen as the balance of importance between image quality and time performance. This will be discussed in 5.0.4 and 5.0.5. However, there might be a point where the SPP values affect the perception of an image so little that there is no point in per- forming additional calculations.

Figure 5.1: Sample image of Scene 1 rendered in 100x100 pixels with 5000 SPP (left), 10,000 SPP (right)

Figure 5.0.2 illustrates the difference in image quality with a difference of 5000 SPP. Consider the render time difference if a large resolution were used.

(30)

24 CHAPTER 5. DISCUSSION

Figure 5.2: Sample image of Scene 2 rendered in 1920x1920 pixels with 2000 SPP (top), 5000 SPP (bottom)

(31)

Figure 5.0.2 further illustrates this phenomenon with an even smaller difference of 3000 SPP in a 1920x1920 resolution. Perhaps it is then useful to conduct user studies for a given path tracer application. These user studies should survey whether differences in certain SPP-values are distinguishable by the human eye and at which point certain images are deemed to have so little variance such that an increment in SPP-value is deemed unnecessary. This optimization of variables will guarantee the best image quality for time. The use of machine learning in order to discover when SPP values no longer improve images to a specified extent is also a possibility that most likely will be even more effective.

5.0.3 The Relevance of Scene choice

As described in section 2.3 and shown in Scene 1 and 2 results, the negative effects on render time as a result of indirect light are emphasized as images can be rendered over ten times slower at 300 SPP by simply adding four planes to the scene that reflect light. This might be detrimental to detailed scenes where plenty of light is being reflected (plenty of indirect light). This slow convergence can be relieved to a certain extent by implementing a bidirectional path tracer. However, this path tracer does not allow for complex shapes, which if implemented would take even longer to calculate than planes or spheres.

5.0.4 Reference Images

In cases where the goal of the path tracer is to produce a reference image, or an extremely high quality image, high SPP values are a must.

Here, the mentioned point of using an SPP so high such that incre- menting the SPP no longer affects the image is emphasized. Assuming the path tracer developed in this thesis is used, one could analyse the pixel differences between different high SPP images and call an image optimal when the pixel difference is less than a specified amount. The time to generate one image with very high SPP-values might take a while let alone rendering several such pictures and comparing them.

Nevertheless, for such a cause, it might be considered acceptable to render images for hours. The images will however be very photorealistic in comparison to other rendering techniques.

(32)

26 CHAPTER 5. DISCUSSION

5.0.5 Real-Time Simulations

For real-time simulations such as video games or simulations, rendering images in a fraction of a second is a must in order to preserve an acceptable frame rate. Given the used path tracer, it seems highly unlikely that a real-time application could be developed with photorealistic quality. In order to render images within the given time-frame, one would have to accept variance. This variance will also increase drastically if we use a HD-resolution.

Since the amount of light effects time performance but not quality performance, a very dark simulation will have a larger chance to be deemed fast enough to render in a reasonable resolution larger than 100x100 pixels which currently renders Scene 1 in 0.120979 seconds with 10 SPP. That would equate around 8.2 frames per second in a real-time simulation. A dark scene such as Scene 2 would however allow for the same frame rate with slightly higher SPP/ resolutions.

However if our intention is to simply generate a non real-time simulation or video, the possibility for doing so with high frame rates, SPP and resolutions would take long but is technically feasible. How- ever in such a case it might be more suitable to pick another rendering technique if photorealism is not a requirement.

5.0.6 Future Work

There are many areas of this experiment which could be improved in order to give further results.

Naive Implementation

The path tracer implemented for this report is naive and far from state- of-the-art path tracers. It could use many further simple improvements:

• Expansion into a bidirectional path tracer, will especially increase performance during indirect scenes.

• Implementation of several BRDF formulas and alternate BRDF models that are faster to calculate

(33)

• Optimisation of mathematical concepts that improve cacluation speeds.

• Choices of alternative mathematical concepts that improve calculations

Hardware/Software limitations

The system which the path tracer is developed on also plays a role in its performance. It would be interesting to develop a path tracer on an OS and programming language optimal for certain mathematical calculations, and do so on state-of-the-art hardware such as a supercomputer (also optimal for the specified calculations).

Experiment improvements

In order to generate results of greater detail, one could write a program that uses the developed path tracer in order to render images of hundreds of SPP-values in many different resolutions. One could also generate many more scenes in order to find out more about the relation between time performance for different SPP-values in different light.

(34)

Chapter 6 Conclusion

The goal of this work was to investigate how variating Samples Per Pixel affect image quality and time performance in a Monte Carlo Path Tracing program? The results show that there is a linear relation between SPP and render time. This linear function is determined by the resolution of the output image as well as the amount of light and objects in a scene. Though these results only can be concluded regarding the forward path tracer developed for this thesis along with its implemented concepts, future improvement of the implementation into a more state-of-the-art path tracer would open up for a much wider discussion.

28

(35)

[1] Tayfun Aytac and Billur Barshan. “Surface differentiation by para- metric modeling of infrared intensity scans”. In: 44 (June 2005).

[2] Benedek Balázs, László Szirmay-Kalos, and Antal György. “Weighted Importance Sampling in Shooting Algorithms”. In: Proceedings of the 19th Spring Conference on Computer Graphics. SCCG ’03. Bud- merice, Slovakia: ACM, 2003, p. 177. ^ISBN: 1-58113-861-X. ^DOI: 10 . 1145 / 984952 . 984981. URL: http://doi.acm.org.

focus.lib.kth.se/10.1145/984952.984981.

[3] Kevin Beason. smallpt: Global Illumination in 99 lines of C++. 2014.

URL: http://www.kevinbeason.com/smallpt (visited on 06/04/2018).

[4] Iain Chudleigh. Fairy Light Table Render. 2016. ^URL: https://

www . behance . net / gallery / 33165571 / Fairy - Light - Table - Render - (Project - File - Included) (visited on 06/04/2018).

[5] Ivan Dimov, Todor Gurov, and Anton Penzov. A Monte Carlo Approach for the Cook-Torrance Model. Feb. 2005.

[6] Rory Dricoll. BETTER SAMPLING. 2009. URL: http : / / www . rorydriscoll . com / 2009 / 01 / 07 / better - sampling/

(visited on 06/04/2018).

[7] Andrew S Glassner. An introduction to ray tracing. Elsevier, 1989,

"preface".

[8] Wenzel Jakob. Mitsuba - Physically based renderer. 2010.URL: https:

//www.mitsuba-renderer.org(visited on 06/04/2018).

[9] James T. Kajiya. “The Rendering Equation”. In: SIGGRAPH Com- put. Graph. 20.4 (Aug. 1986), "143". ^ISSN: 0097-8930. ^DOI: 10 . 1145/15886.15902. ^URL: http://doi.acm.org.focus.

lib.kth.se/10.1145/15886.15902.

29

(36)

30 BIBLIOGRAPHY

[10] Phil Miller. NVIDIA Brings AI to Ray Tracing to Speed Graphics Workloads. 2017. URL: https://blogs.nvidia.com/blog/

2017/05/10/ai-for-ray-tracing/(visited on 06/04/2018).

[11] N/A. OpenMP. 2018. URL: https : / / www . openmp . org / specifications/(visited on 06/04/2018).

[12] N/A. statcounter - GlobalStats. 2018.URL: http://gs.statcounter.

com/screen-resolution-stats(visited on 06/04/2018).

[13] United States. National Bureau of Standards and Fred Edwin Nicodemus. Geometrical considerations and nomenclature for reflectance.

Vol. 160. US Department of Commerce, National Bureau of Stan- dards, 1977, pp. 43, 44.

[14] Eric Veach. “Robust Monte Carlo Methods for Light Transport Simulation”. In: (Dec. 1997).URL: http://graphics.stanford.

edu/papers/veach_thesis/#Postscript.

[15] Turner Whitted. “An Improved Illumination Model for Shaded Display”. In: ACM SIGGRAPH 2005 Courses. SIGGRAPH ’05. Los Angeles, California: ACM, 2005. ^DOI: 10 . 1145 / 1198555 . 1198743. ^URL: http://doi.acm.org.focus.lib.kth.

se/10.1145/1198555.1198743.

[16] Ycharts. Advanced Micro Devices Research and Development Expense.

2018. URL: https : / / ycharts . com / companies / AMD / r _ and_d_expense(visited on 06/04/2018).

[17] Ycharts. NVIDIA Research and Development Expense. 2018. URL: https : / / ycharts . com / companies / NVDA / r _ and _ d _ expense(visited on 06/04/2018).

(37)

Scene 1 (Well-lit Room) - 1080x1080 pixel Render Images

Note that none of the following images are of their full original render size. The images are listed in order of their appearance in table 4.1.

31

(38)

32 APPENDIX A. SCENE 1 (WELL-LIT ROOM) - 1080X1080 PIXEL RENDER IMAGES

(39)

(40)

(41)

(42)

(43)

Scene 2 (Dark Plane)- 1080x1080 pixel Render Images

37

(44)

38 APPENDIX B. SCENE 2 (DARK PLANE)- 1080X1080 PIXEL RENDER IMAGES

(45)

(46)

(47)

(48)

(49)

(50)

(51)

(52)

(53)

Scene 1 (Well-lit Room) - 100x100 pixel Render Images

47

(54)

48 APPENDIX C. SCENE 1 (WELL-LIT ROOM) - 100X100 PIXEL RENDER IMAGES

(55)

(56)

(57)

(58)

(59)

(60)

www.kth.se

Using a Multithreaded Forward Path Tracer in C++ and OpenMP

Examining the effects of SPP in Monte Carlo Path Tracing