CIS565-Fall-2020 · HaoyuSui · Sep 30, 2020 · Sep 30, 2020 · Sep 30, 2020 · Sep 30, 2020
diff --git a/CMakeLists.txt b/CMakeLists.txt
@@ -73,6 +73,7 @@ set(headers
     src/sceneStructs.h
     src/preview.h
     src/utilities.h
+    src/tiny_obj_loader.h
     )
 
 set(sources
@@ -86,11 +87,29 @@ set(sources
     src/utilities.cpp
     )
 
+set(imgui
+    imgui/imconfig.h
+    imgui/imgui.cpp
+    imgui/imgui.h
+    imgui/imgui_draw.cpp
+    imgui/imgui_internal.h
+    imgui/imgui_widgets.cpp
+    imgui/imgui_demo.cpp
+    imgui/imgui_impl_glfw.cpp
+    imgui/imgui_impl_glfw.h
+    imgui/imgui_impl_opengl2.cpp
+    imgui/imgui_impl_opengl2.h
+    imgui/imgui_impl_opengl3.cpp
+    imgui/imgui_impl_opengl3.h
+    )
+
 list(SORT headers)
 list(SORT sources)
+list(SORT imgui)
 
 source_group(Headers FILES ${headers})
 source_group(Sources FILES ${sources})
+source_group(imgui FILES ${imgui})
 
 #add_subdirectory(stream_compaction)  # TODO: uncomment if using your stream compaction
 

diff --git a/README.md b/README.md
@@ -3,11 +3,128 @@ 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)
+* Haoyu Sui
+  	* [LinkedIn](http://linkedin.com/in/haoyu-sui-721284192)
+* Tested on: Windows 10, i5-9600K @ 3.70GHz 16GB, RTX 2070 SUPER 8GB 
+* SM：7.5
+
+### Denoise
+**Fallguys**
+
+| With denoising (32 pt iters) | Without denoising (32 pt iters) | Without denoising (2000 pt iters) |
+| ------------------------ | ----------------------- | -----------------------|
+| ![](img/denoise/fallguys_denoise.png) | ![](img/denoise/fallguys.png) |![](img/denoise/fallguys_2000.png)|
+
+As can be seen from the above three images, when PT has only 32 iterations, denoising can help to present a very good effect, which is similar to the PT result that has 2000 PT iterations and is without denoising. And the result of 32 PT iterations without denoising is very poor (the middle image).
+
+**Ceiling light**
+
+| PT reference (500 iters) | Denoise- 2 iters |
+| ------------------------ | ----------------------- |
+| ![](img/denoise/500iter_rt.png) | ![](img/denoise/ceiling_light_10_2.png) |
+
+| Denoise- 5 iters | Denoise- 10 iters |
+| ------------------------ | ----------------------- |
+| ![](img/denoise/ceiling_light_10_5.png) | ![](img/denoise/ceiling_light_10_10.png) |
+
+**Ceiling light VS Cornell**
+
+| Ceiling light (20 pt iters / 5 dn iters)| Cornell (20 pt iters / 5 dn iters) | Cornell (100 pt iters / 5 dn iters) |
+| ------------------------ | ----------------------- | --------------------------|
+| ![](img/denoise/ceiling_light_20_5.png) | ![](img/denoise/cornell_20_5.png) | ![](img/denoise/cornell_100_5.png) |
+
+Comparing these two scenes, the denoising of the ceiling light scene under the same parameters can produce better results. For cornell, it may require more PT iterations to produce better results, such as in the third picture. I think it is because of the different light sizes, because for a smaller light, more noise will be generated under the same sampling times, so more samples are needed to achieve better results.
+
+**Analysis**
+
+| 10 iters for PT, 5 iters for denoising | 
+| ------------------------ | 
+| ![](img/denoise/resolution.png) | 
+
+According to the figure above, the denoising time increases with the increase in resolution, and there is a linear increase trend.
+
+
+| Resolution: 800 * 800, 5 iters for denoising | 
+| ------------------------ | 
+| ![](img/denoise/materials.png) |
+
+
+For different materials, from my results, it has almost no effect on the running time of denoising, because denoising processes the output image of path trace, so it has nothing to do with the material.
+
+### Features
+* Ideal diffuse surface
+* Specular-reflective surface
+* Stream compaction for path continue and termination 
+* Sort rays with same material
+* Cache first bounce
+* Refraction with Frensel effects using Schlick's approximation
+* Physically-based depth-of-field
+* Stochastic Sampled Antialiasing
+* Arbitrary .obj mesh loading
+* Bounding volume intersection culling
+* Stratified sampling method
+* Object motion and motion blur
+
+### Rendered images
+
+**Arbitrary .obj mesh loading**
+
+| Fallguys | Dragon |
+| ------------------------ | ----------------------- |
+| ![](img/fallguys_2000.png) | ![](img/dragon_2000.png) |
+
+**Specular surface reflection & Diffuse surface reflection & Refraction**
+
+| Specular Surface | Diffuse Surface | Refraction |
+| ---------------- | --------------- | -----------|
+| ![](img/specular.png) | ![](img/diffuse.png) | ![](img/refract.png)
+
+**Physically-based depth-of-field (Focal Distance = 7.f)**
+
+| Lens Radius 0.0 | Lens Radius 0.5 | Lens Radius 1.0 |
+| ---------------- | --------------- | -----------|
+| ![](img/DOF_LEN_00_FD_7.png) | ![](img/DOF_LEN_05_FD_7.png) | ![](img/DOF_LEN_1_FD_7.png)
+
+**Stochastic Sampled Antialiasing**
+
+| With Antialiasing | Without Antialiasing |
+| ------------------------ | ----------------------- |
+| ![](img/Antialiasing_detail.png) | ![](img/Antialiasing_detail2.png) |
+
+**Stratified sampling method**
+
+| Naive Sampling | Stratified Sampling |
+| ------------------------ | ----------------------- |
+| ![](img/naive_sample_200.png) | ![](img/Stratified_200.png) |
+
+For stratified sampling comparsion, it can be seen from the figure that the difference is not very large, but some subtle differences can be found, for example, the shadow of the stratified sampling is a little bit more concentrated.
+
+**Object motion and motion blur**
+
+| Without Motion | Motion and motion blur |
+| ------------------------ | ----------------------- |
+| ![](img/naive_sample.png) | ![](img/motion_blur_5000.png) |
+
+
+### Performance Analysis
+
+![](img/Analysis.png)
+
+I calculated the average time spent in each depth loop in 200 iterations and got the result shown in the figure above. 
+
+In terms of sorting rays, I originally thought that sorting would reduce the time it took because it would reduce the divergence in a thread warp, but from the results, on my computer, sorting actually reduced performance. It may because there are relatively few existing materials. When there are many kinds of materials in the scene, the performance should be improved.
+
+For caching the first bounce, it can be seen from the chart that there is a slight improvement in performance, because the cache can only reduce the time to calculate the intersection for the first time, so the larger the depth, the smaller the performance improvement. And I think it has nothing to do with the number of iterations.
+
+
+![](img/boundingbox_analysis.png)
+
+For bounding volume intersection culling, I tested the meshes with different numbers of triangles. From the table, it can be seen that when the number of triangles is relatively small, the effect of the bounding box is not obvious. As the number of triangles increases, the bounding box improves the performance more significantly.
+
+
+### Third-party code
+
+[tinyObj](https://github.com/tinyobjloader/tinyobjloader)
 
-### (TODO: Your README)
 
-*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.
 
diff --git a/img/Analysis.png b/img/Analysis.png
diff --git a/img/Antialiasing.png b/img/Antialiasing.png
diff --git a/img/Antialiasing_detail.png b/img/Antialiasing_detail.png
diff --git a/img/Antialiasing_detail2.png b/img/Antialiasing_detail2.png
diff --git a/img/DOF_LEN_00_FD_7.png b/img/DOF_LEN_00_FD_7.png
diff --git a/img/DOF_LEN_05_FD_7.png b/img/DOF_LEN_05_FD_7.png
diff --git a/img/DOF_LEN_1_FD_7.png b/img/DOF_LEN_1_FD_7.png
diff --git a/img/Stratified.png b/img/Stratified.png
diff --git a/img/Stratified_200.png b/img/Stratified_200.png
diff --git a/img/boundingbox_analysis.png b/img/boundingbox_analysis.png
diff --git a/img/denoise/500iter_rt.png b/img/denoise/500iter_rt.png
diff --git a/img/denoise/ceiling_light_10_10.png b/img/denoise/ceiling_light_10_10.png
diff --git a/img/denoise/ceiling_light_10_2.png b/img/denoise/ceiling_light_10_2.png
diff --git a/img/denoise/ceiling_light_10_5.png b/img/denoise/ceiling_light_10_5.png
diff --git a/img/denoise/ceiling_light_20_5.png b/img/denoise/ceiling_light_20_5.png
diff --git a/img/denoise/cornell_100_5.png b/img/denoise/cornell_100_5.png
diff --git a/img/denoise/cornell_20_10.png b/img/denoise/cornell_20_10.png
diff --git a/img/denoise/cornell_20_5.png b/img/denoise/cornell_20_5.png
diff --git a/img/denoise/fallguys.png b/img/denoise/fallguys.png
diff --git a/img/denoise/fallguys_2000.png b/img/denoise/fallguys_2000.png
diff --git a/img/denoise/fallguys_denoise.png b/img/denoise/fallguys_denoise.png
diff --git a/img/denoise/materials.png b/img/denoise/materials.png
diff --git a/img/denoise/resolution.png b/img/denoise/resolution.png
diff --git a/img/diffuse.png b/img/diffuse.png
diff --git a/img/dragon_2000.png b/img/dragon_2000.png
diff --git a/img/fallguys_2000.png b/img/fallguys_2000.png
diff --git a/img/iteration.gif b/img/iteration.gif
diff --git a/img/motion_blur_2000.png b/img/motion_blur_2000.png
diff --git a/img/motion_blur_5000.png b/img/motion_blur_5000.png
diff --git a/img/naive_sample.png b/img/naive_sample.png
diff --git a/img/naive_sample_200.png b/img/naive_sample_200.png
diff --git a/img/refract.png b/img/refract.png
diff --git a/img/specular.png b/img/specular.png
diff --git a/imgui/LICENSE.txt b/imgui/LICENSE.txt
@@ -0,0 +1,21 @@
+The MIT License (MIT)
+
+Copyright (c) 2014-2019 Omar Cornut
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
diff --git a/imgui/imconfig.h b/imgui/imconfig.h
@@ -0,0 +1,94 @@
+//-----------------------------------------------------------------------------
+// COMPILE-TIME OPTIONS FOR DEAR IMGUI
+// Runtime options (clipboard callbacks, enabling various features, etc.) can generally be set via the ImGuiIO structure.
+// You can use ImGui::SetAllocatorFunctions() before calling ImGui::CreateContext() to rewire memory allocation functions.
+//-----------------------------------------------------------------------------
+// A) You may edit imconfig.h (and not overwrite it when updating Dear ImGui, or maintain a patch/branch with your modifications to imconfig.h)
+// B) or add configuration directives in your own file and compile with #define IMGUI_USER_CONFIG "myfilename.h"
+// If you do so you need to make sure that configuration settings are defined consistently _everywhere_ Dear ImGui is used, which include
+// the imgui*.cpp files but also _any_ of your code that uses Dear ImGui. This is because some compile-time options have an affect on data structures.
+// Defining those options in imconfig.h will ensure every compilation unit gets to see the same data structure layouts.
+// Call IMGUI_CHECKVERSION() from your .cpp files to verify that the data structures your files are using are matching the ones imgui.cpp is using.
+//-----------------------------------------------------------------------------
+
+#pragma once
+
+//---- Define assertion handler. Defaults to calling assert().
+//#define IM_ASSERT(_EXPR)  MyAssert(_EXPR)
+//#define IM_ASSERT(_EXPR)  ((void)(_EXPR))     // Disable asserts
+
+//---- Define attributes of all API symbols declarations, e.g. for DLL under Windows
+// Using dear imgui via a shared library is not recommended, because of function call overhead and because we don't guarantee backward nor forward ABI compatibility.
+//#define IMGUI_API __declspec( dllexport )
+//#define IMGUI_API __declspec( dllimport )
+
+//---- Don't define obsolete functions/enums names. Consider enabling from time to time after updating to avoid using soon-to-be obsolete function/names.
+//#define IMGUI_DISABLE_OBSOLETE_FUNCTIONS
+
+//---- Don't implement demo windows functionality (ShowDemoWindow()/ShowStyleEditor()/ShowUserGuide() methods will be empty)
+// It is very strongly recommended to NOT disable the demo windows during development. Please read the comments in imgui_demo.cpp.
+//#define IMGUI_DISABLE_DEMO_WINDOWS
+//#define IMGUI_DISABLE_METRICS_WINDOW
+
+//---- Don't implement some functions to reduce linkage requirements.
+//#define IMGUI_DISABLE_WIN32_DEFAULT_CLIPBOARD_FUNCTIONS   // [Win32] Don't implement default clipboard handler. Won't use and link with OpenClipboard/GetClipboardData/CloseClipboard etc.
+//#define IMGUI_DISABLE_WIN32_DEFAULT_IME_FUNCTIONS         // [Win32] Don't implement default IME handler. Won't use and link with ImmGetContext/ImmSetCompositionWindow.
+//#define IMGUI_DISABLE_WIN32_FUNCTIONS                     // [Win32] Won't use and link with any Win32 function (clipboard, ime).
+//#define IMGUI_ENABLE_OSX_DEFAULT_CLIPBOARD_FUNCTIONS      // [OSX] Implement default OSX clipboard handler (need to link with '-framework ApplicationServices', this is why this is not the default).
+//#define IMGUI_DISABLE_DEFAULT_FORMAT_FUNCTIONS            // Don't implement ImFormatString/ImFormatStringV so you can implement them yourself (e.g. if you don't want to link with vsnprintf)
+//#define IMGUI_DISABLE_DEFAULT_MATH_FUNCTIONS              // Don't implement ImFabs/ImSqrt/ImPow/ImFmod/ImCos/ImSin/ImAcos/ImAtan2 so you can implement them yourself.
+//#define IMGUI_DISABLE_DEFAULT_FILE_FUNCTIONS              // Don't implement ImFileOpen/ImFileClose/ImFileRead/ImFileWrite so you can implement them yourself if you don't want to link with fopen/fclose/fread/fwrite. This will also disable the LogToTTY() function.
+//#define IMGUI_DISABLE_DEFAULT_ALLOCATORS                  // Don't implement default allocators calling malloc()/free() to avoid linking with them. You will need to call ImGui::SetAllocatorFunctions().
+
+//---- Include imgui_user.h at the end of imgui.h as a convenience
+//#define IMGUI_INCLUDE_IMGUI_USER_H
+
+//---- Pack colors to BGRA8 instead of RGBA8 (to avoid converting from one to another)
+//#define IMGUI_USE_BGRA_PACKED_COLOR
+
+//---- Avoid multiple STB libraries implementations, or redefine path/filenames to prioritize another version
+// By default the embedded implementations are declared static and not available outside of imgui cpp files.
+//#define IMGUI_STB_TRUETYPE_FILENAME   "my_folder/stb_truetype.h"
+//#define IMGUI_STB_RECT_PACK_FILENAME  "my_folder/stb_rect_pack.h"
+//#define IMGUI_DISABLE_STB_TRUETYPE_IMPLEMENTATION
+//#define IMGUI_DISABLE_STB_RECT_PACK_IMPLEMENTATION
+
+//---- Define constructor and implicit cast operators to convert back<>forth between your math types and ImVec2/ImVec4.
+// This will be inlined as part of ImVec2 and ImVec4 class declarations.
+/*
+#define IM_VEC2_CLASS_EXTRA                                                 \
+        ImVec2(const MyVec2& f) { x = f.x; y = f.y; }                       \
+        operator MyVec2() const { return MyVec2(x,y); }
+
+#define IM_VEC4_CLASS_EXTRA                                                 \
+        ImVec4(const MyVec4& f) { x = f.x; y = f.y; z = f.z; w = f.w; }     \
+        operator MyVec4() const { return MyVec4(x,y,z,w); }
+*/
+
+//---- Use 32-bit vertex indices (default is 16-bit) is one way to allow large meshes with more than 64K vertices.
+// Your renderer back-end will need to support it (most example renderer back-ends support both 16/32-bit indices).
+// Another way to allow large meshes while keeping 16-bit indices is to handle ImDrawCmd::VtxOffset in your renderer.
+// Read about ImGuiBackendFlags_RendererHasVtxOffset for details.
+//#define ImDrawIdx unsigned int
+
+//---- Override ImDrawCallback signature (will need to modify renderer back-ends accordingly)
+//struct ImDrawList;
+//struct ImDrawCmd;
+//typedef void (*MyImDrawCallback)(const ImDrawList* draw_list, const ImDrawCmd* cmd, void* my_renderer_user_data);
+//#define ImDrawCallback MyImDrawCallback
+
+//---- Debug Tools
+// Use 'Metrics->Tools->Item Picker' to pick widgets with the mouse and break into them for easy debugging.
+//#define IM_DEBUG_BREAK  IM_ASSERT(0)
+//#define IM_DEBUG_BREAK  __debugbreak()
+// Have the Item Picker break in the ItemAdd() function instead of ItemHoverable() - which is earlier in the code, will catch a few extra items, allow picking items other than Hovered one.
+// This adds a small runtime cost which is why it is not enabled by default.
+//#define IMGUI_DEBUG_TOOL_ITEM_PICKER_EX
+
+//---- Tip: You can add extra functions within the ImGui:: namespace, here or in your own headers files.
+/*
+namespace ImGui
+{
+    void MyFunction(const char* name, const MyMatrix44& v);
+}
+*/