diff --git a/.gitignore b/.gitignore
index 89942d9e..d7608bfc 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,6 @@
+./src/ImGui
+imgui.ini
+
*.orig
*.filters
*.sln
@@ -189,7 +192,6 @@ install_manifest.txt
*.slo
*.lo
*.o
-*.obj
# Precompiled Headers
*.gch
@@ -276,7 +278,6 @@ artifacts/
*_i.h
*.ilk
*.meta
-*.obj
*.pch
*.pdb
*.pgc
@@ -558,3 +559,4 @@ xcuserdata
*.xccheckout
*.moved-aside
*.xcuserstate
+src/ImGui/imgui.cpp
diff --git a/CMakeLists.txt b/CMakeLists.txt
index c473e2c0..c1db61fc 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -73,17 +73,22 @@ set(headers
src/sceneStructs.h
src/preview.h
src/utilities.h
+ src/material.h
+ src/bvh.h
+ src/sampler.h
+ src/mathUtil.h
+ src/cudaUtil.h
src/ImGui/imconfig.h
-
- src/ImGui/imgui.h
+ src/ImGui/imgui.h
src/ImGui/imconfig.h
src/ImGui/imgui_impl_glfw.h
- src/ImGui/imgui_impl_opengl3.h
- src/ImGui/imgui_impl_opengl3_loader.h
- src/ImGui/imgui_internal.h
- src/ImGui/imstb_rectpack.h
- src/ImGui/imstb_textedit.h
- src/ImGui/imstb_truetype.h
+ src/ImGui/imgui_impl_opengl3.h
+ src/ImGui/imgui_impl_opengl3_loader.h
+ src/ImGui/imgui_internal.h
+ src/ImGui/imstb_rectpack.h
+ src/ImGui/imstb_textedit.h
+ src/ImGui/imstb_truetype.h
+ src/common.h
)
set(sources
@@ -95,14 +100,19 @@ set(sources
src/scene.cpp
src/preview.cpp
src/utilities.cpp
-
+ src/bvh.cpp
+ src/sampler.cpp
+ src/mathUtil.cpp
src/ImGui/imgui.cpp
- src/ImGui/imgui_demo.cpp
- src/ImGui/imgui_draw.cpp
- src/ImGui/imgui_impl_glfw.cpp
- src/ImGui/imgui_impl_opengl3.cpp
- src/ImGui/imgui_tables.cpp
- src/ImGui/imgui_widgets.cpp
+ src/ImGui/imgui_demo.cpp
+ src/ImGui/imgui_draw.cpp
+ src/ImGui/imgui_impl_glfw.cpp
+ src/ImGui/imgui_impl_opengl3.cpp
+ src/ImGui/imgui_tables.cpp
+ src/ImGui/imgui_widgets.cpp
+ src/tiny_obj_loader.cpp
+ src/common.cpp
+ src/tiny_gltf.cpp
)
list(SORT headers)
diff --git a/README.md b/README.md
index 110697ce..dcaab6a5 100644
--- a/README.md
+++ b/README.md
@@ -3,11 +3,378 @@ 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)
+* Chang Liu
+ * [LinkedIn](https://www.linkedin.com/in/chang-liu-0451a6208/)
+ * [Personal website](https://hummawhite.github.io/)
+* Tested on personal laptop:
+ - i7-12700 @ 4.90GHz with 16GB RAM
+ - RTX 3070 Ti Laptop 8GB
+
+This project is about implementing a GPU path tracer with CUDA programming library.
+
+## Representative Outcome
+
+
+
+A virtual camera is capturing another virtual camera
+
+
+
+
+ | Scene Specs |
+ [./scenes/pbr_texture.txt] |
+
+
+ | Resolution |
+ 2400 x 1800 |
+
+
+ | Samples Per Pixel |
+ 3000 |
+
+
+ | Render Time |
+ < 7 minutes (> 7.5 frames per second) |
+
+
+ | Million Rays Per Second |
+ 32.4 |
+
+
+ | Triangle Count |
+ 25637 |
+
+
+
Large scene (6,704,264 triangles)
+
+
+
+Lens effect: depth of field with heart-shaped aperture blades
+
+
+
+## Features
+
+### Visual
+
+#### Direct Lighting with Multiple Importance Sampling
+
+The base code's lighting strategy is to shoot new ray at every intersected point until the ray hits a light source. This works fine with most scenes having large light sources and dominated by diffuse surfaces. However, if light sources are very small, like a point light source, rays are hardly able to hit them, thus the result image will be dark and noisy.
+
+
+
+ | BSDF Sampling |
+ Light Sampling |
+ MIS Combined |
+
+
+  |
+  |
+  |
+
+
+Rendered at 32 spp
+
+
+
+Instead of passively waiting our rays to hit the light sources, we can "pull" them to the light source that we want to get direct illuminance from. This strategy is called light sampling. Light sampling converges much faster than BSDF sampling, as you can see from the images. However, it introduces another problem: when surfaces are very specular, it becomes hard to produce any valid contribution.
+
+In this path tracer, I implemented Multiple Importance Sampling to combine samples from BSDF sampling and light sampling. MIS takes the advantage of both while avoiding the disadvantage of each, producing less noisy results.
+
+#### Importance Sampled HDR Environment Map (Skybox)
+
+Tired of repeatedly setting up and adjusting "virtual artificial" light sources for the best effect? Let's introduce some natural light from real world that can easily improve our rendering quality at no cost. That is, we retrieve luminance values stored in HDR photographs when calculating lighting and color of surfaces. As you can see, the [demo images](#representative-outcome) all benefited from such HDR images.
+
+A very simple implementation is to transform the direction of escaped rays from spherical direction to 2D texture coordinate and get the correspondent color from HDR images. However, if we want it to work well with our MIS direct lighting, we should treat it as a light source to perform importance sampling on it.
+
+The idea of importance sampling on HDR image is to first convert the color of image to a 2D brightness distribution. Then, we stretch the distribution to 1D and perform importance sampling on it. For sampling a 1D distribution, I used the alias method, which requires to build an alias table for the distribution. Sampling with alias table is $O(1)$, pretty efficient.
+
+
+
+ | No Importance Sampling |
+ Importance Sampling |
+
+
+  |
+  |
+
+
+
+These are rendered with an HDR image that has a very bright but tiny dot in it (the sun). You can see only importance sampling can capture it and correctly light the ground -- the sun is too small to be hit by a random ray sampled by BSDF.
+
+#### Physically-Based Materials
+
+For materials, I didn't implement many this time in the renderer. There are three material models implemented:
+
+- Lambertian: a classic diffuse material used to represent rough surfaces
+- Dielectric: a transparent material having both reflection and refraction. Used to simulate glass, water, air or any "clear and specular" media
+- Metallic workflow: a popular material model used in the industry. It has two parameters, Metallic and Roughness. By changing the value of two parameters, we can simulate a variety of materials such as plastic, glossy metal and mirror. It's very expressive and artist friendly, and easy to combine with textures to create realistic rendering. The model implemented by the renderer is a mixture of Lambertian diffuse and Trowbridge-Reitz (GGX; GTR2) microfacet specular
+
+
+
+Metallic workflow: changing metallic and roughness; Dielectric: IOR
+
+#### Normal Map & PBR Texture
+
+The following picture shows the type of textures supported. You can see how the workflow make a difference to turn a plain white model to very realistic image.
+
+
+
+Initially I only implemented normal map. When I first tried to add texture channels for metallic an roughness and rendered that camera image, I was shocked too by how expressive PBR material and PBR textures are.
+
+#### Physically Based Camera
+
+##### Depth of Field
+
+Real world cameras' lens system compose of sets of glasses that focus the light to the sensor. In path tracing, the basic model of camera is the pinhole model, which creates precise one-to-one mapping from world position to pixel coordinate. If we want to simulate depth of field, we'd allow one world position to be mapped to a range of pixels.
+
+How to achieve this? The answer is to create a virtual aperture and randomly generate points on the aperture, then connect the point to another point we sample in the pixel to generate the ray.
+
+| No DOF | DOF |
+| --------------------------- | ----------------------- |
+|  |  |
+
+##### Custom Aperture Shape
+
+This is my favorite part of the project.
+
+In DOF, we sample points on the camera's aperture disk to create blurred background and foreground. This idea can even be extended by stochastically sampling a mask image instead of the circle shape of the aperture, which creates very interesting and amazing results.
+
+
+
+
+
Twisted Sponza rendered with panorama camera
+
+Toggle for this feature is compile time -- change the value of `CAMERA_PANORAMA` in [`./src/common.h`](./src/common.h)
+
+#### Post Processing
+
+##### Gamma Correction
+
+Implementing gamma correction is very trivial. But it is necessary if we want our final image to be correctly displayed on monitors, through which we see by our eyes. Otherwise, the image will always look darker.
+
+##### Tone Mapping
+
+Tone mapping is also a feature that does not require heavy workload but improves overall appearance easily. It's simply remapping the value stored in color buffer from HDR to LDR before gamma correction and being displayed on monitor.
+
+
+
+ | No Tone Mapping |
+ ACES |
+
+
+  |
+  |
+
+
+
+I implemented Filmic and ACES tone mapping. The images in this readme are all processed with ACES. By comparison we can see that ACES lifts contrast so that pictures will look more appealing.
+
+You can toggle tone mapping through GUI, or by pressing `T` on your keyboard.
+
+### Performance
+
+#### Fast Intersection: Stackless SAH-Based Bounding Volume Hierarchy
+
+Ray-scene intersection is probably the best time consuming part of of ray tracing process. In a naive method we try to intersect every ray with every object in the scene, which is quite inefficient when there are numerous objects.
+
+
+
+You can enable this BVH visualizer through GUI
+
+An alternative is to setup spatial culling data structure according to how the objects distribute in the scene space and intersect the data structure before intersecting objects. For example, we could assign each object a bounding box and only try to find intersection with an object if the ray intersects its bounding box first. However, this is not sufficient to reduce intersection time. Therefore, we need more advanced spatial structures, like bounding volume hierarchy, octree or K-D tree. These tree-based structures usually have an average height of $O(\log{n})$, meaning if traversal is well handled our intersection cost will benefit.
+
+I implemented BVH as the acceleration structure in this render. Also, I did two levels of optimization to make it fast and robust. These optimizations allow my path tracer to build BVH for the [Rungholt](https://casual-effects.com/data/) scene (6,704,264 triangles) in 7 seconds and run at 3 FPS, 2560 x 1440. (Click the images to see details)
+
+
+
+ | Rendering |
+ Bounding Volume Hierarchy of the Whole Scene |
+
+
+  |
+  |
+
+
+
+##### Better Tree Structure: Surface Area Heuristic
+
+SAH, the Surface Area Heuristic, is a method to determine how to split a set of bounding volumes into subsets when constructing a BVH, that the constructed tree's structure would be highly optimal.
+
+##### Faster Tree Traversal on GPU: Multiple-Threaded BVH
+
+The second level of optimization is done on GPU. BVH is a tree after all, so we still have to traverse through it during ray-scene intersection even on GPU. Tree traversal is usually based on recursion or stack, but we know that it's hard to do these with GPU: first, recursion is almost impossible with standard GPU programming; if we use stack instead of recursion, we need to maintain a stack in every thread -- the registers required would limit thread concurrency, not to say when BVH depth exceeds the limit.
+
+For the BVH in this project, I implemented stackless traversal. The idea is to preprocess tree structure to know in advance which node to visit if the ray intersects/does not intersect the node's bounding box. By doing so we actually create a automated machine, whose traversal only requires $O(1)$ runtime memory.
+
+
+
+##### How much BVH Enhances Performance
+
+I only tested relatively small scenes considering that it would take fairly long to render without BVH.
+
+
+
+
+
+
+
Pseudorandom vs. Sobol
+
+
+ | Pseudorandom Sequence |
+ Xor-Scrambled Sobol Sequence |
+
+
+  |
+  |
+
+
+
+### Other
+
+#### Single-Kernel Path Tracing
+
+To figure out how much stream compaction can possibly improve a GPU path tracer's performance, we need a baseline to compare with. Instead of toggling streamed path tracer's kernel to disable stream compaction, we can separately write another kernel that does the entire ray tracing process. That is, we shoot rays, find intersection, shading surfaces and sampling new rays in one kernel. Unlike streamed path tracing where you have to store path information in global memory after each pass, this single kernel keeps those required variables only in threads' local memory.
+
+#### First Ray Caching (G-Buffer)
+
+In real-time rendering, a technique called deferred shading stores scene's geometry information in texture buffers (G-Buffer) at the beginning of render pass, so that later passes can save time by retrieving geometry information directly from buffer rather than rasterization process. It turns out we can do something similar with offline rendering.
+
+
+
+
+
+
+