Do second part revision

report/parts/discussion.tex

@@ -27,7 +27,7 @@ \subsubsection*{WebGPU Support}
 
 \subsubsection*{PBR Standard}
 
-As discussed in \autoref{ch:materialDescriptionStandards}, a variety of standards exist for \gls{PBR}. While \gls{OpenPBR} is a new standard, it has already seen adoption by the industry and offers interoperability. \texttt{three-gpu-pathtracer} and \texttt{Three.js PathTracer} currently use custom \gls{PBR} standards or partially support \gls{glTF} \gls{PBR} extensions. \texttt{dspbr-pt} uses the \gls{DSPBR} standard.
+As discussed in \autoref{ch:materialDescriptionStandards}, a variety of standards exist for \gls{PBR}. While \gls{OpenPBR} is a new standard, it has already been adopted by the industry and offers interoperability. \texttt{three-gpu-pathtracer} and \texttt{Three.js PathTracer} currently use custom \gls{PBR} standards or partially support \gls{glTF} \gls{PBR} extensions. \texttt{dspbr-pt} uses the \gls{DSPBR} standard.
 
 \subsubsection*{Documentation}
 
@@ -39,7 +39,7 @@ \subsubsection*{Benchmark Setup}
 
 \subsubsection*{Maintenance}
 
-The availability of an \gls{npm} package can simplify the integration of the renderer into existing projects. Additionally, it enables updating libraries using a standardized process. \texttt{strahl}, \texttt{three-gpu-pathtracer}, and \texttt{dspbr-pt} provide an \gls{npm} package, while \texttt{Three.js PathTracer} does not. \texttt{strahl}, \texttt{three-gpu-pathtracer}, and \texttt{Three.js PathTracer} have been updated in 2024, while \texttt{dspbr-pt} has not been updated since 2022. Therefore, maintenance for \texttt{strahl} and \texttt{three-gpu-pathtracer} is provided while \texttt{Three.js PathTracer} and \texttt{dspbr-pt} are lacking in this regard.
+The availability of an \gls{npm} package can simplify the integration of the renderer into existing projects. Additionally, it enables updating libraries using a standardized process. \texttt{strahl}, \texttt{three-gpu-pathtracer}, and \texttt{dspbr-pt} provide an \gls{npm} package, while \texttt{Three.js PathTracer} does not. \texttt{strahl}, \texttt{three-gpu-pathtracer}, and \texttt{Three.js PathTracer} were updated in 2024, while \texttt{dspbr-pt} has not been updated since 2022. Therefore, maintenance for \texttt{strahl} and \texttt{three-gpu-pathtracer} is provided while \texttt{Three.js PathTracer} and \texttt{dspbr-pt} are lacking in this regard.
 
 \subsubsection*{Assessment}
 
@@ -77,7 +77,7 @@ \subsection*{Comparison to Alternative Strategies}
   \hfill
   \begin{subfigure}[t]{0.3\textwidth}
     \includegraphics[width=\textwidth]{resources/comparison-offline-rendering.png}
-    \caption{Offline rendering with \gls{RealityServer}, used by EAO \cite{eaoProductReference}.}
+    \caption{Offline rendering generated with \gls{RealityServer}, used by EAO \cite{eaoProductReference}.}
     \label{fig:offline-rendering}
   \end{subfigure}
   \hfill
@@ -95,7 +95,7 @@ \subsection*{Comparison to Alternative Strategies}
 \newpage
 \subsection*{Comparison to Photograph}
 
-The renderings for comparison to alternative strategies used slight variations of parameters to show the quality of the generated effects. This includes the strong red color as well as the pronounced reflection on the metal part. These adjustments do not fully replicate those found in the actual product. Therefore, a separate round of comparison to a real photograph taken under neutral lighting is conducted. The \gls{OpenPBR} material properties were adjusted to more closely resemble the photograph. See \autoref{fig:real-rendering-comparison} for the comparison.
+The renderings for comparison to alternative strategies used slight variations of parameters to show the quality of the generated effects. This includes the strong red color as well as the pronounced reflection on the metal part. These adjustments do not fully replicate those found in the actual product. Therefore, a separate round of comparison to a real photograph taken under neutral lighting is conducted. The \gls{OpenPBR} material properties were adjusted to resemble the photograph more closely. See \autoref{fig:real-rendering-comparison} for the comparison.
 
 \begin{figure}[H]
   \centering
@@ -112,7 +112,7 @@ \subsection*{Comparison to Photograph}
     \label{fig:real-rendering}
   \end{subfigure}
   \hspace*{0.2cm}
-  \caption{Comparison between photograph taken in neutral lighting situation and rendering.}
+  \caption{Comparison between a photograph taken in a neutral lighting situation and a rendering.}
   \label{fig:real-rendering-comparison}
 \end{figure}
 
@@ -142,7 +142,7 @@ \subsubsection*{Feature Set}
 
 \subsubsection*{Debuggability}
 
-None of the major browsers — Chrome, Firefox, and Safari — provide debugging as part of the developer tools. Tools for inspecting \gls{WebGPU} applications exist \cite{webGpuDevToolsDuncan, webGpuDevToolsTakahiro} but are limited in terms of feature set. While they are helpful in inspecting resources and capturing frames, they do not provide debugging capabilities such as breakpoints, stepping, or variable inspection. For specific setups, there are methods to setup profiling \cite{webGpuProfilingWithPix}, but these are not integrated into the browser developer tools and are dependent on the concrete machine hardware. Improvements in this area facilitate troubleshooting.
+None of the major browsers — Chrome, Firefox, and Safari — provide debugging as part of the developer tools. Tools for inspecting \gls{WebGPU} applications exist \cite{webGpuDevToolsDuncan, webGpuDevToolsTakahiro} but are limited in terms of feature set. While they are helpful in inspecting resources and capturing frames, they do not provide debugging capabilities such as breakpoints, stepping, or variable inspection. For specific setups, there are methods to set up profiling \cite{webGpuProfilingWithPix}, but these are not integrated into the browser developer tools and are dependent on the concrete machine hardware. Improvements in this area facilitate troubleshooting.
 
 \subsubsection*{Stability}
 
@@ -151,7 +151,7 @@ \subsubsection*{Stability}
 \begin{figure}[H]
   \centering
   \includegraphics[width=0.3\columnwidth]{resources/webgpu-crashes.png}
-  \caption{Example of a provoked \gls{WebGPU} crash on macOS; note the black squares which correspond in size to the dispatched workgroup size.}
+  \caption{Example of a provoked \gls{WebGPU} crash on macOS; note the black squares that correspond in size to the dispatched workgroup size.}
   \label{fig:webgpu-crash}
 \end{figure}
 
@@ -180,7 +180,7 @@ \subsection*{Rendering Improvements}
   \item{Motion Blur} — Effect of objects moving quickly appearing blurred.
 \end{itemize}
 
-While refraction, caustics, depth of field, and motion blur are questions of light transport, volumetric effects, hair and fur are features that are not part of the \gls{OpenPBR} specification. Other features in terms of rendering could be implemented. This section outlines some of the possibilities.
+While refraction, caustics, depth of field, and motion blur are questions of light transport, volumetric effects as well as hair and fur are features that are not part of the \gls{OpenPBR} specification. Other features in terms of rendering could be implemented. This section outlines some of the possibilities.
 
 \subsubsection*{Texture Support}
 
@@ -190,7 +190,7 @@ \subsubsection*{Texture Support}
 
 \subsubsection*{Environment Mapping}
 
-The current implementation offers a environment light setup. However, no details about the environment are visible in the reflections. By adding environment mapping, more complex lighting scenarios can be achieved. This could be done by using a skybox or a \gls{HDR} environment map.
+The current implementation offers an environment light setup. However, no details about the environment are visible in the reflections. By adding environment mapping, more complex lighting scenarios can be achieved. This could be done by using a skybox or a \gls{HDR} environment map.
 
 \subsubsection*{Spectral Rendering}
 
@@ -203,7 +203,7 @@ \subsubsection*{Full OpenPBR support}
 \begin{itemize}
   \item{Coat} — Secondary layer of specular highlight, often used for car paint.
   \item{Fuzz} — Layer for fuzzy or dusty surfaces.
-  \item{Thin-film iridescence} — Effect of thin-films of material on the surface of an object. This can be seen in objects covered in grease, oil, or alcohol.
+  \item{Thin-film iridescence} — Effect of thin films of material on the surface of an object. This can be seen in objects covered in grease, oil, or alcohol.
   \item{Subsurface Scattering and Translucency} — Effects of surfaces that transmit and scatter light.
   \item{Opacity and Transparency} — Describe partially transparent surfaces that do not scatter light.
 \end{itemize}
@@ -231,7 +231,7 @@ \subsubsection*{Independence of Three.js}
 
 \subsubsection*{Offline and Remote Rendering}
 
-As highlighted in \autoref{ch:paradigmAssessment}, it is possible to extend a real-time client-side renderer for offline and remote rendering scenarios. In order to implement offline rendering, one could opt to use a headless browser such as \texttt{Puppeteer}, a \fgls{Node.js}{a JavaScript runtime, frequently used for executing JavaScript outside of the browser.} library that provides a high-level \gls{API} to control browsers. The use of \gls{Deno} could reduce the overhead, by providing a more direct \gls{API} to \gls{wgpu}. An alternative is to use \gls{wgpu} directly, but this would necessitate a rewrite of the renderer. Possibly, the rewritten renderer could also be used in the web context by using \fgls{WebAssembly}{a portable binary code format available in modern browser engines.}.
+As highlighted in \autoref{ch:paradigmAssessment}, it is possible to extend a real-time client-side renderer for offline and remote rendering scenarios. In order to implement offline rendering, one could opt to use a headless browser such as \texttt{Puppeteer}, a \fgls{Node.js}{a JavaScript runtime, frequently used for executing JavaScript outside of the browser.} library that provides a high-level \gls{API} to control browsers. The use of \gls{Deno} could reduce the overhead by providing a more direct \gls{API} to \gls{wgpu}. An alternative is to use \gls{wgpu} directly, but this would necessitate a rewrite of the renderer. Possibly, the rewritten renderer could also be used in the web context by using \fgls{WebAssembly}{a portable binary code format available in modern browser engines.}.
 
 For remote rendering, the renderer could be extended to render images on demand and encode them as video streams.
 
@@ -263,7 +263,7 @@ \subsubsection*{Denoisers}
 
 \subsubsection*{Qualitative Assessment}
 
-The provided results highlight the quantitative performance of the renderer. However, due to the nature of a renderer, qualitative assessment based on visual inspection is also used to determine the quality of the rendered images. This could be extended to include objective metrics such as peak signal to noise ratio (PSNR), structural similarity (SSIM) \cite{ssim}, or learned perceptual image patch similarity (LPIPS) \cite{lpips}. Such a comparison could be based on reference scenes such as the Cornell Box \cite{goral1984modeling} or the Sponza Atrium \cite{dabrovic2002sponza}. To assess the differences, different comparisons could be conducted:
+The provided results highlight the quantitative performance of the renderer. However, due to the nature of a renderer, qualitative assessment based on visual inspection is also used to determine the quality of the rendered images. This could be extended to include objective metrics such as peak signal-to-noise ratio (PSNR), structural similarity (SSIM) \cite{ssim}, or learned perceptual image patch similarity (LPIPS) \cite{lpips}. Such a comparison could be based on reference scenes such as the Cornell Box \cite{goral1984modeling} or the Sponza Atrium \cite{dabrovic2002sponza}. To assess the differences, different comparisons could be conducted:
 
 \begin{itemize}
   \item{Offline Renderer} — Comparison to other offline renderers such as Mitsuba \cite{Jakob2020DrJit}, \gls{pbrt} \cite{Pharr_Physically_Based_Rendering_2023}, or Cycles which is used by \gls{Blender} \cite{cycles}.
@@ -273,8 +273,8 @@ \subsubsection*{Qualitative Assessment}
 
 \section{Conclusion}
 
-While there are a variety of areas to improve on, the proposed solution constitutes a fully functional path tracer encompassing technical features such as using \gls{BVH}, parallelization on \gls{GPU} based on \gls{WebGPU}, and supporting \gls{MIS}; rendering features including anti-aliasing, denoising options, tone mapping, generating a wide range of global illumination effects, and supporting the \gls{OpenPBR} standard; usability features such as incremental rendering, camera controls, and scene loading; benchmarking setup for reliable performance measurements; and extensive documentation to facilitate use of the renderer.
+While there are a variety of areas to improve on, the proposed solution constitutes a fully functional path tracer encompassing technical features such as using \gls{BVH}, parallelization on \gls{GPU} based on \gls{WebGPU}, and supporting \gls{MIS}; rendering features including anti-aliasing, denoising options, tone mapping, generating a wide range of global illumination effects, and supporting the \gls{OpenPBR} standard; usability features such as progressive rendering, camera controls, and scene loading; benchmarking setup for reliable performance measurements; and extensive documentation to facilitate use of the renderer.
 
-These features fulfil the requirements of the use case and present an alternative to existing offline rendering solutions by permitting a higher degree of interactivity and alleviating the need to pregenerate all images, which facilitates offering more complex product families. Compared to remote rendering services, the approach reduces infrastructure cost and network dependency. The fidelity gained by using ray tracing techniques in combination with the \gls{OpenPBR} standard provides a high-quality rendering solution without the need for pregenerated assets. The path tracer developed in this thesis is a suitable choice for the given use case of using engineering \gls{CAD} data with manifold assembly configurations and customer-specific materials.
+These features fulfill the requirements of the use case and present an alternative to existing offline rendering solutions by permitting a higher degree of interactivity and alleviating the need to pregenerate all images, which facilitates offering more complex product families. Compared to remote rendering services, the approach reduces infrastructure cost and network dependency. The fidelity gained by using ray tracing techniques in combination with the \gls{OpenPBR} standard provides a high-quality rendering solution without the need for pregenerated assets. The path tracer developed in this thesis is a suitable choice for the given use case of using engineering \gls{CAD} data with manifold assembly configurations and customer-specific materials.
 
-Generally, the ray tracing technique is slower than rasterization-based approaches and is therefore not a silver bullet for all use cases. However, as shown in \autoref{sec:benchmark}, the performance is sufficient for near real-time renderings of assembled \gls{CAD} models on the web. The use of \gls{WebGPU} over \gls{WebGL} as well as incorporating \gls{OpenPBR} provides a distinction to existing open-source path tracers for the web. \gls{WebGPU} has significant potential for the years to come and adoption of \gls{OpenPBR} by the wider industry is a promising sign of the possible longevity of the chosen technology and standards. The open-source nature of the project facilitates extension and serves as inspiration for future initiatives.
+Generally, the ray tracing technique is slower than rasterization-based approaches and is, therefore, not a silver bullet for all use cases. However, as shown in \autoref{sec:benchmark}, the performance is sufficient for near real-time renderings of assembled \gls{CAD} models on the web. The use of \gls{WebGPU} over \gls{WebGL}, as well as incorporating \gls{OpenPBR}, provides a distinction to existing open-source path tracers for the web. \gls{WebGPU} has significant potential for the years to come, and the adoption of \gls{OpenPBR} by the wider industry is a promising sign of the possible longevity of the chosen technology and standards. The open-source nature of the project facilitates extension and serves as inspiration for future initiatives.