CIS565-Fall-2016 · jian-ru · Oct 7, 2016 · Oct 9, 2016 · Oct 9, 2016 · Oct 9, 2016
diff --git a/README.md b/README.md
@@ -3,11 +3,58 @@ CUDA Path Tracer
 
 **University of Pennsylvania, CIS 565: GPU Programming and Architecture, Project 3**
 
-* (TODO) YOUR NAME HERE
-* Tested on: (TODO) Windows 22, i7-2222 @ 2.22GHz 22GB, GTX 222 222MB (Moore 2222 Lab)
+* Jian Ru
+* Tested on: Windows 10, i7-4850 @ 2.3GHz 16GB, GT 750M 2GB (Personal)
 
-### (TODO: Your README)
+### Results and Analysis
 
-*DO NOT* leave the README to the last minute! It is a crucial part of the
-project, and we will not be able to grade you without a good README.
+#### List of features
+* MIS - Multiple Importance Sampling
+* BVH - Used Surface Area Heuristic. Construction done on CPU
+* Mesh loading and rendering - tinyobj for loading. Self-implemented triangle intersection test (Moller Trumbore's method)
+* Path regeneration
+* Materials - Glass (Fresnel)/Mirror/Lambert
+* Depth of field
+* Stratified jittering AA
 
+#### Results
+
+<img src="img/final_1.png" width="800" height="800">
+<img src="img/final2.png" width="800" height="800">
+
+#### Analysis
+* Methodology
+  * Performance analysis was performed under the following context unless otherwise specified
+  * Image dimension: 800 x 800
+  * Execution time: the time for one pathtrace() call in milliseconds
+  * Standfard scene: cornell box with a sphere and a cube
+* A problem with random number generation
+  * Monte Carlo method estimate integrals through random processes and hence relies on well distributed sampling pattern. All the sampling (cosine-weighted hemisphere sampling, cone sampling, concentric disk sampling, etc.) is based on a cannonical uniform distribution (i.e. between 0 and 1). If the assumption of uniform distribution doesn't hold, the results won't be correct.
+  * The following image shows artifacts casued by incorrect random number generation. I forgot to update the depth value passed to the hashing function at the beginning. In this case, the skewed, correlated sampling pattern gives preference to certain directions on the hemisphere but this is not reflected in the pdf caculation. And the result is weird final color which is not easy to debug because there is no direct relation between the phenomenon and cause.
+  * <img src="img/rng_error_1.png" width="400" height="400"> <img src="img/rng_error_3.png" width="400" height="400">
+* MIS - cost and benefit
+  * The following two images were rendered after 200 iterations using MIS and IS, respectively. It is obvious that MIS greately improves rate of convergence.
+  * MIS is not free. The cost comes in as extra light source sampling and shadow ray intersection test for each path segement. The good thing is that this cost scales with image resolution (i.e. number of pathes) instead of scene complexity (unless there are materials that don't require light source sampling such as mirror or glass). In the standard scene, MIS cost about 100 ms on my machine which is about one fifth more expensive than IS. But obviously, the quality improvement is mcuh higher than the price. There is no way for IS to get the same quality if it is run the amount of time as MIS does.
+  * <img src="img/mis_200.png" width="400" height="400"> <img src="img/is_200.png" width="400" height="400">
+* BVH - not always useful
+  * My BVH implementation was a naive port from last year's CPU path tracer but instead of using a variable size container, std::vector, to simulate recursion stack, a fixed size array is used and hence impose a requirement on the maximum depth of the bvh hierarchy.
+  * Surface area heuristic becomes extremely important here because it ensures a very balanced tree so greately reduce the height of the tree.
+  * BVH is not always useful. When there are a very small number of primitives in the scene, BVH is actually much slower than bruteforce test (in the standard scene where only 8 primitives exist, BVH is more than 400 ms slower). But bruteforce quickly become infeasible when the scene complexity increases. When I add a stanford bunny (about 5,000 triangles) to the standard scene, bruteforce took more than 100,000 ms to finish one iteration (impossible without turning off TDR) while BVH took about 3,600 ms.
+  * Even though BVH offers greate acceleration when there are lots of geometry in the scene, it is still way too slow (take more than 3 seconds to finish just one iteration of the bunny scene). If I have more time, a faster intersection test method will definitely be one of the most important things in the todo list.
+  * <img src="img/bvh.png" width="400" height="400"> <img src="img/bruteforce.png" width="400" height="400">
+  * <img src="img/bunny_bvh.png" width="400" height="400"> <img src="img/mitsuba_bvh.png" width="400" height="400">
+* Path regen vs. removing/ignoring terminated threads
+  * Instead of removing/ignoring terminated threads using stream compaction, I tried path regeneration approach from the Wavefront Path Tracing paper. The basic idea is that a new path from the camera will replace a terminated path in each sub-iteration. The color of the terminated path is saved before being overwritten and the new path will have the same pixel index as the old one.
+  * The point is that we will always have enough work/threads for the GPU to execute and therefore improves performance by increasing utilization rate of GPU. This scheme is benefitial if your GPU has vacant power/resource to execute more threads.
+  * Even though path regen eliminate the need to perform stream compaction, a sort on the path according to their material type is still benefitial because nearby threads will likely to run the same material code and thus reduce execution divergence.
+  * Interesting enough. Experimentation shows that removing/ignoring terminated paths gives higher number of finished paths per milliseconds. I think this may due to several reasons. First, my GPU is not powerful enough to keep all threads alive anyway so path regen may keep too many threads alive and haence not increasing utilization. I am using the mega kernel approach for simplicity so it is possible that each thread uses too much resource and may again results in no increase in utilization because the GPU is full already. Many paths tend to terminate at the same time. Since I am using fixed depth instead of Russian-Roulette, except a small number of paths that escape the scene from opening, all paths end at max depth. So check for regeneration after each depth may not be that helpful. Regen kernel usually operate with high code and data divergence and it also increases divergence in following stages because it only operate on terminated paths which may be scattered after the shading stage. Restoring coherency is possible by using extra sorting of path indices but I found out through experiment that there is not obvious improvement possibly because the cost of sorting is basically the same as the slowdown cost by divergence.
+  * Even though the experiment shows no benefit from path regen, more tests are needed. I think path regen should improve performance given a careful designed algorithm/workflow that minimizes divergence and a powerful enough GPU that can actually keep a large number of threads alive.
+  * ![](img/ppi.png)
+* Path sorting - index or actual data?
+  * Increasing data coherency is good but sorting is not free. In the flocking project, each boid was only represented using two float3 and the algorithm requires acessing data of neighbouring boids. Therefore sorting the actual data was able to improve performance by a reasonable factor due to increased cache hit-rate. But in this project, paths are assumed to be independent and each path also has much larger size of data to hold its state. Sorting the actual data become infeasible here.
+  * Instead of sorting the actual data, I sort the indices of the paths and find that this improves performance. Execution time is reduced by about 60 ms in the standard scene.
+  * ![](img/sd_si.png)
+* Open scenes vs. closed scenes
+  * Test was performed on an open and a closed cornell box.
+  * As expected, the execution time is longer in the closed scene because fewer rays terminate due to entering void and hence the shading kernel usually has more work to do. The closed scene is also brighber because no rays can escape.
+  * <img src="img/open_scene.png" width="400" height="400"> <img src="img/closed_scene.png" width="400" height="400">
diff --git a/img/.2016-10-08_15-38-42z.672samp.png b/img/.2016-10-08_15-38-42z.672samp.png
diff --git a/img/.2016-10-08_16-48-41z.5samp.png b/img/.2016-10-08_16-48-41z.5samp.png
diff --git a/img/bruteforce.png b/img/bruteforce.png
diff --git a/img/bunny_bvh.png b/img/bunny_bvh.png
diff --git a/img/bvh.png b/img/bvh.png
diff --git a/img/closed_scene.png b/img/closed_scene.png
diff --git a/img/cornell.2016-10-07_02-22-24z.15samp.png b/img/cornell.2016-10-07_02-22-24z.15samp.png
diff --git a/img/cornell.2016-10-07_02-26-10z.521samp.png b/img/cornell.2016-10-07_02-26-10z.521samp.png
diff --git a/img/cornell.2016-10-07_02-31-22z.117samp.png b/img/cornell.2016-10-07_02-31-22z.117samp.png
diff --git a/img/final2.png b/img/final2.png
diff --git a/img/final_1.png b/img/final_1.png
diff --git a/img/is_200.png b/img/is_200.png
diff --git a/img/mis_200.png b/img/mis_200.png
diff --git a/img/mitsuba_bvh.png b/img/mitsuba_bvh.png
diff --git a/img/open_scene.png b/img/open_scene.png
diff --git a/img/ppi.png b/img/ppi.png
diff --git a/img/rng_error_1.png b/img/rng_error_1.png
diff --git a/img/rng_error_2.png b/img/rng_error_2.png
diff --git a/img/rng_error_3.png b/img/rng_error_3.png
diff --git a/img/sd_si.png b/img/sd_si.png
diff --git a/img/sort_data.png b/img/sort_data.png
diff --git a/img/sort_indices.png b/img/sort_indices.png
diff --git a/models/mitsuba/copyright.txt b/models/mitsuba/copyright.txt
@@ -0,0 +1,15 @@
+Material preview scene by Jonas Pilo. 
+
+This is the standard material test object provided with the Mitsuba renderer.
+      We converted it to a single OBJ file and separated the backdrop.
+      This data was provided by Wenzel Jakob for the purpose of
+      direct comparisons between the Mitsuba renderer and others. Please don't use this for other purposes,
+      such as a standard test object in your own renderer.
+----------------------
+This distribution was created by Morgan McGuire and Guedis Cardenas.
+http://graphics.cs.williams.edu/data/
+
+Downloaded from:
+http://www.mitsuba-renderer.org/download.html
+
+We scaled and rotate the objects.
diff --git a/scenes/bvh_test.txt b/scenes/bvh_test.txt
@@ -0,0 +1,32 @@
+// Emissive material (light)
+MATERIAL 0
+TYPE        Lambert
+RGB         1 1 0.9
+SPECEX      0
+SPECRGB     0 0 0
+REFL        0
+REFR        0
+REFRIOR     0
+EMITTANCE   20
+
+// Camera
+CAMERA
+RES         800 800
+FOVY        45
+LENSRADIUS  0.2
+FOCALD      9
+ITERATIONS  5000
+DEPTH       8
+FILE        cornell
+EYE         0 0 5
+LOOKAT      0 0 0
+UP          0 1 0
+
+// Mesh
+OBJECT 0
+mesh
+material 0
+TRANS       0 -1 0
+ROTAT       0 0 0
+SCALE       1 1 1
+FILE        C:/Users/Jian Ru/Documents/CIS565/Project3-CUDA-Path-Tracer/models/mitsuba/mitsuba-sphere.obj
diff --git a/scenes/cornell.txt b/scenes/cornell.txt
@@ -1,15 +1,17 @@
 // Emissive material (light)
 MATERIAL 0
-RGB         1 1 1
+TYPE        Lambert
+RGB         1 1 0.9
 SPECEX      0
 SPECRGB     0 0 0
 REFL        0
 REFR        0
 REFRIOR     0
-EMITTANCE   5
+EMITTANCE   20
 
 // Diffuse white
 MATERIAL 1
+TYPE        Lambert
 RGB         .98 .98 .98
 SPECEX      0
 SPECRGB     0 0 0
@@ -20,6 +22,7 @@ EMITTANCE   0
 
 // Diffuse red
 MATERIAL 2
+TYPE        Lambert
 RGB         .85 .35 .35
 SPECEX      0
 SPECRGB     0 0 0
@@ -30,6 +33,7 @@ EMITTANCE   0
 
 // Diffuse green
 MATERIAL 3
+TYPE        Lambert
 RGB         .35 .85 .35
 SPECEX      0
 SPECRGB     0 0 0
@@ -38,8 +42,31 @@ REFR        0
 REFRIOR     0
 EMITTANCE   0
 
-// Specular white
+// Specular pink
 MATERIAL 4
+TYPE        Glass
+RGB         .98 .9 .98
+SPECEX      0
+SPECRGB     .98 .98 .98
+REFL        1
+REFR        1
+REFRIOR     1.6
+EMITTANCE   0
+
+// Cyan glass
+MATERIAL 5
+TYPE        Glass
+RGB         .2 .8 .98
+SPECEX      0
+SPECRGB     .98 .98 .98
+REFL        1
+REFR        1
+REFRIOR     1.6
+EMITTANCE   0
+
+// white Mirror
+MATERIAL 6
+TYPE        Mirror
 RGB         .98 .98 .98
 SPECEX      0
 SPECRGB     .98 .98 .98
@@ -48,25 +75,39 @@ REFR        0
 REFRIOR     0
 EMITTANCE   0
 
+// Torrance
+MATERIAL 7
+TYPE        TorranceSparrow
+RGB         .28 .68 .98
+SPECEX      20
+SPECRGB     .98 .98 .98
+REFL        1
+REFR        0
+REFRIOR     3.1
+EMITTANCE   0
+
 // Camera
 CAMERA
+//RES         10 10
 RES         800 800
 FOVY        45
+LENSRADIUS  0.2
+FOCALD      9
 ITERATIONS  5000
 DEPTH       8
 FILE        cornell
-EYE         0.0 5 10.5
+EYE         0.0 5 9
 LOOKAT      0 5 0
 UP          0 1 0
 
 
 // Ceiling light
 OBJECT 0
-cube
+sphere
 material 0
-TRANS       0 10 0
+TRANS       0 8 0
 ROTAT       0 0 0
-SCALE       3 .3 3
+SCALE       1 1 1
 
 // Floor
 OBJECT 1
@@ -111,7 +152,24 @@ SCALE       .01 10 10
 // Sphere
 OBJECT 6
 sphere
-material 4
-TRANS       -1 4 -1
+material 1
+TRANS       -3 2 0
 ROTAT       0 0 0
 SCALE       3 3 3
+
+// Mirror Cube
+OBJECT 7
+cube
+material 1
+TRANS       2 6 -2
+ROTAT       45 30 10
+SCALE       2 2 2
+
+// Mesh
+//OBJECT 8
+//mesh
+//material 1
+//TRANS       2.5 1.5 -1
+//ROTAT       0 0 0
+//SCALE       1.5 1.5 1.5
+//FILE        C:/Users/Jian Ru/Documents/CIS565/Project3-CUDA-Path-Tracer/models/bunny/bunny.obj