diff --git a/report/parts/discussion.tex b/report/parts/discussion.tex index 1430ef7..b605e4d 100644 --- a/report/parts/discussion.tex +++ b/report/parts/discussion.tex @@ -18,7 +18,7 @@ \section{Comparison} \subsection*{Comparison to Prior Work} \label{sec:comparisonToPriorWork} -The three open-source path tracers introduced in \autoref{sec:web-path-tracers} are alternatives to the renderer developed in this work. Comparing them based on quantitative measures such as \fGls{FPS}{\e{Frames Per Second}, a measure of the rate at which consecutive images are rendered and displayed} is not meaningful as the number of samples required for high-fidelity renderings differs across the renderers. Nevertheless, defining a set of criteria to compare them is still possible. +The three open-source path tracers introduced in \autoref{sec:web-path-tracers} are alternatives to the renderer developed in this work. Comparing them based on quantitative measures such as \fGls{FPS}{\e{Frames Per Second}, a measure of the rate at which consecutive images are rendered and displayed.} is not meaningful as the number of samples required for high-fidelity renderings differs across the renderers. Nevertheless, defining a set of criteria to compare them is still possible. \subsubsection*{WebGPU Support} @@ -65,7 +65,7 @@ \subsubsection*{Assessment} \newpage \subsection*{Comparison to Alternative Strategies} -The chosen architecture paradigm serves as an alternative to offline rendering solutions. In addition, the decision to implement ray tracing techniques contrasts with rasterization-based rendering engines. This section shows the comparison between these different options. For rasterization, \gls{Three.js} is used as an example, based on a minimal setup without pregenerated artifacts or advanced rendering techniques. For offline rendering, \fGls{RealityServer}{a platform for 3D rendering, which integrates the NVIDIA Iray global illumination rendering technology} renderings used by EAO are shown as a representative example. The three different renderings are visualized in \autoref{fig:final-rendering-comparison}. +The chosen architecture paradigm serves as an alternative to offline rendering solutions. In addition, the decision to implement ray tracing techniques contrasts with rasterization-based rendering engines. This section shows the comparison between these different options. For rasterization, \gls{Three.js} is used as an example, based on a minimal setup without pregenerated artifacts or advanced rendering techniques. For offline rendering, \fGls{RealityServer}{a platform for 3D rendering, which integrates the NVIDIA Iray global illumination rendering technology.} renderings used by EAO are shown as a representative example. The three different renderings are visualized in \autoref{fig:final-rendering-comparison}. \begin{figure}[H] \centering @@ -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. @@ -241,7 +241,7 @@ \subsubsection*{WebGPU Compatibility Mode} \subsubsection*{Automatic Shader Conversion} -During the specification phase of \gls{WebGPU}, the relation to \fgls{SPIR-V}{\e{Standard Portable Intermediate Representation}, an intermediate language for parallel computing and graphics developed by the \gls{Khronos Group}} was discussed \cite{webGPUSpirVRelation}. In general, many of the modern shading languages can be compiled to one another. Projects such as \texttt{Tint}, which is part of \gls{Dawn} \cite{dawnImplementation} or \texttt{Naga} \cite{nagaImplementation} could be used to compile shaders from different frontends to different backends. Similarly, other engines, such as \gls{Three.js} with \fGls{TSL}{\e{Three.js Shading Language}, a shading language used in \gls{Three.js} that supports \gls{GLSL} as well as \gls{WGSL}}, have their own shading languages that support a variety of backends \cite{ThreeJSShadingLanguage}. Parts of \gls{MaterialX} shader generation could be used to generate shaders for \gls{WebGPU} and update them automatically as \gls{OpenPBR} is updated. +During the specification phase of \gls{WebGPU}, the relation to \fgls{SPIR-V}{\e{Standard Portable Intermediate Representation}, an intermediate language for parallel computing and graphics developed by the \gls{Khronos Group}.} was discussed \cite{webGPUSpirVRelation}. In general, many of the modern shading languages can be compiled to one another. Projects such as \texttt{Tint}, which is part of \gls{Dawn} \cite{dawnImplementation} or \texttt{Naga} \cite{nagaImplementation} could be used to compile shaders from different frontends to different backends. Similarly, other engines, such as \gls{Three.js} with \fGls{TSL}{\e{Three.js Shading Language}, a shading language used in \gls{Three.js} that supports \gls{GLSL} as well as \gls{WGSL}.}, have their own shading languages that support a variety of backends \cite{ThreeJSShadingLanguage}. Parts of \gls{MaterialX} shader generation could be used to generate shaders for \gls{WebGPU} and update them automatically as \gls{OpenPBR} is updated. \subsubsection*{Low-Level Performance Optimizations} diff --git a/report/parts/glossary.tex b/report/parts/glossary.tex index 32f318e..ce67886 100644 --- a/report/parts/glossary.tex +++ b/report/parts/glossary.tex @@ -10,206 +10,206 @@ \newglossaryentry{WebGPU} { name={WebGPU}, - description={a new standard for 3D graphics on the web} + description={a new standard for 3D graphics on the web.} } \newglossaryentry{WGSL} { name={WGSL}, - description={\e{WebGPU Shading Language}, the shading language used in \gls{WebGPU}} + description={\e{WebGPU Shading Language}, the shading language used in \gls{WebGPU}.} } \newglossaryentry{RNG}{ name={RNG}, - description={\e{Random Number Generator}} + description={\e{Random Number Generator}.} } \newglossaryentry{BVH}{ name={BVH}, - description={\e{Bounding Volume Hierarchy}, a common tree-based acceleration structure} + description={\e{Bounding Volume Hierarchy}, a common tree-based acceleration structure.} } \newglossaryentry{AABB}{ name={AABB}, - description={\e{Axis-Aligned Bounding Boxes}, a bounding volume aligned with the coordinate axes} + description={\e{Axis-Aligned Bounding Boxes}, a bounding volume aligned with the coordinate axes.} } \newglossaryentry{CPU}{ name={CPU}, - description={\e{Central Processing Unit}, the main processing unit of a computer} + description={\e{Central Processing Unit}, the main processing unit of a computer.} } \newglossaryentry{CAD}{ name={CAD}, - description={\e{Computer-Aided Design}, describes the use of computers to aid in modeling of a design} + description={\e{Computer-Aided Design}, describes the use of computers to aid in modeling of a design.} } \newglossaryentry{PDF}{ name={PDF}, - description={\e{Probability Density Function}, describes the likelihood of a random variable} + description={\e{Probability Density Function}, describes the likelihood of a random variable.} } \newglossaryentry{CDF}{ name={CDF}, - description={\e{Cumulative Distribution Function}, describes the probability that a random variable is less than or equal to a given value} + description={\e{Cumulative Distribution Function}, describes the probability that a random variable is less than or equal to a given value.} } \newglossaryentry{BSDF}{ name={BSDF}, - description={\e{Bidirectional Scattering Distribution Function}, describes the interaction of light with surfaces} + description={\e{Bidirectional Scattering Distribution Function}, describes the interaction of light with surfaces.} } \newglossaryentry{BxDF}{ name={BxDF}, - description={\e{Bidirectional Distribution Functions}, describe the interaction of light with surfaces, commonly used interchangeably with \gls{BSDF}} + description={\e{Bidirectional Distribution Functions}, describe the interaction of light with surfaces, commonly used interchangeably with \gls{BSDF}.} } \newglossaryentry{BRDF}{ name={BRDF}, - description={\e{Bidirectional Reflectance Distribution Function}, describes the reflection of light off a surface} + description={\e{Bidirectional Reflectance Distribution Function}, describes the reflection of light off a surface.} } \newglossaryentry{BTDF}{ name={BTDF}, - description={\e{Bidirectional Transmittance Distribution Function}, describes the transmission of light through a surface} + description={\e{Bidirectional Transmittance Distribution Function}, describes the transmission of light through a surface.} } \newglossaryentry{NDF}{ name={NDF}, - description={\e{Normal Distribution Function}, describes the distribution of microfacet normals on a surface} + description={\e{Normal Distribution Function}, describes the distribution of microfacet normals on a surface.} } \newglossaryentry{GPGPU}{ name={GPGPU}, - description={\e{General-Purpose GPU} Programming, using \glspl{GPU} for non-graphics tasks} + description={\e{General-Purpose Computing on GPU}, describes using \glspl{GPU} for non-graphics tasks.} } \newglossaryentry{BMRT}{ name={BMRT}, - description={\e{Blue Moon Rendering Tools}, a free and open-source ray tracing software that was \gls{RenderMan} compatible} + description={\e{Blue Moon Rendering Tools}, a free and open-source ray tracing software that was \gls{RenderMan} compatible.} } \newglossaryentry{ML}{ name={ML}, - description={\e{Machine Learning}, a field of computer science that uses data and algorithms to give computer systems the ability to improve accuracy without being explicitly programmed} + description={\e{Machine Learning}, a field of computer science that uses data and algorithms to give computer systems the ability to improve accuracy without being explicitly programmed.} } \newglossaryentry{OBJ}{ name={OBJ}, - description={a common text-based format for 3D models initially developed by Wavefront Technologies} + description={a common text-based format for 3D models initially developed by Wavefront Technologies.} } \newglossaryentry{PBR}{ name={PBR}, - description={\e{Physically Based Rendering}, a rendering technique that simulates real-world materials} + description={\e{Physically Based Rendering}, a rendering technique that simulates real-world materials.} } \newglossaryentry{HDR}{ name={HDR}, - description={\e{High Dynamic Range}, describes a signal with a large range of luminance values} + description={\e{High Dynamic Range}, describes a signal with a large range of luminance values.} } \newglossaryentry{MIS}{ name={MIS}, - description={\e{Multiple Importance Sampling}, a technique to combine multiple sampling strategies in Monte Carlo integration} + description={\e{Multiple Importance Sampling}, a technique to combine multiple sampling strategies in Monte Carlo integration.} } \newglossaryentry{LOD}{ name={LOD}, - description={\e{Level of Detail}, describes artifacts that define finer or coarser representations of a model} + description={\e{Level of Detail}, describes artifacts that define finer or coarser representations of a model.} } \newglossaryentry{ReSTIR}{ name={ReSTIR}, - description={\e{Reservoir-based Spatio-Temporal Importance Resampling}, a technique to optimize sampling in path tracing} + description={\e{Reservoir-based Spatio-Temporal Importance Resampling}, a technique to optimize sampling in path tracing.} } \newglossaryentry{GLSL}{ name={GLSL}, - description={\e{OpenGL Shading Language}, the shading language used in \gls{OpenGL}} + description={\e{OpenGL Shading Language}, the shading language used in \gls{OpenGL}.} } \newglossaryentry{MaterialX}{ name={MaterialX}, - description={an open standard for rich material definition} + description={an open standard for rich material definition.} } \newglossaryentry{OpenPBR}{ name={OpenPBR}, - description={an open specification of a \gls{PBR} surface shading model} + description={an open specification of a \gls{PBR} surface shading model.} } \newglossaryentry{DSPBR}{ name={DSPBR}, - description={\e{Dassault Systèmes PBR Shading Model}, a specification of a \gls{PBR} shading model} + description={\e{Dassault Systèmes PBR Shading Model}, a specification of a \gls{PBR} shading model.} } \newglossaryentry{OIDN}{ name={OIDN}, - description={\e{Open Image Denoise}, an open-source library for denoising images} + description={\e{Open Image Denoise}, an open-source library for denoising images.} } \newglossaryentry{uber shader}{ name={uber shader}, - description={a shader design that offers parameter configuration but no custom shader code} + description={a shader design that offers parameter configuration but no custom shader code.} } \newglossaryentry{OpenGL}{ name={OpenGL}, - description={\e{Open Graphics Library}, cross-platform API for rendering 2D and 3D graphics} + description={\e{Open Graphics Library}, cross-platform API for rendering 2D and 3D graphics.} } \newglossaryentry{Vulkan}{ name={Vulkan}, - description={an open standard for cross-platform 3D graphics and computing} + description={an open standard for cross-platform 3D graphics and computing.} } \newglossaryentry{Metal}{ name={Metal}, - description={an \gls{API} developed by Apple for 3D graphics and computing} + description={an \gls{API} developed by Apple for 3D graphics and computing.} } \newglossaryentry{DirectX 12}{ name={DirectX 12}, - description={an \gls{API} developed by Microsoft for 3D graphics and computing} + description={an \gls{API} developed by Microsoft for 3D graphics and computing.} } \newglossaryentry{Dawn}{ name={Dawn}, - description={an open-source and cross-platform \gls{WebGPU} implementation developed by Google} + description={an open-source and cross-platform \gls{WebGPU} implementation developed by Google.} } \newglossaryentry{wgpu}{ name={wgpu}, - description={an open-source and cross-platform \gls{WebGPU} implementation} + description={an open-source and cross-platform \gls{WebGPU} implementation.} } \newglossaryentry{pbrt}{ name={pbrt}, - description={an open-source ray tracing renderer, described in the book Physically Based Rendering \cite{Pharr_Physically_Based_Rendering_2023}} + description={an open-source ray tracing renderer, described in the book Physically Based Rendering \cite{Pharr_Physically_Based_Rendering_2023}.} } \newglossaryentry{Babylon.js}{ name={Babylon.js}, - description={an open-source 3D engine for the web based on \gls{WebGL} and \gls{WebGPU}} + description={an open-source 3D engine for the web based on \gls{WebGL} and \gls{WebGPU}.} } \newglossaryentry{Three.js}{ name={Three.js}, - description={an open-source 3D engine for the web based on \gls{WebGL}} + description={an open-source 3D engine for the web based on \gls{WebGL}.} } \newglossaryentry{PlayCanvas}{ name={PlayCanvas}, - description={an open-source 3D engine for the web based on \gls{WebGL}} + description={an open-source 3D engine for the web based on \gls{WebGL}.} } \newglossaryentry{A-Frame}{ name={A-Frame}, - description={an open-source 3D engine for the web based on \gls{WebGL}} + description={an open-source 3D engine for the web based on \gls{WebGL}.} } \newglossaryentry{Unity}{ name={Unity}, - description={a proprietary, cross-platform game engine developed by Unity Technologies} + description={a proprietary, cross-platform game engine developed by Unity Technologies.} } diff --git a/report/parts/introduction.tex b/report/parts/introduction.tex index 98c9027..23b9160 100644 --- a/report/parts/introduction.tex +++ b/report/parts/introduction.tex @@ -41,7 +41,7 @@ \section{CAD Data Preprocessing} \label{fig:cad-preprocessing} \end{figure} -\fGls{STEP}{\e{Standard for the Exchange of Product model data}, a standard formalized in ISO 10303 for product manufacturing information} files are a common format for exchanging \gls{CAD} data and can be used for this purpose. However, as will be discussed in \autoref{ch:specializedFormats}, other formats are more suitable for rendering and address the inherent limitations of \gls{STEP} files. An important consideration is intellectual property rights when using \gls{CAD} models from engineering processes. The models may contain proprietary information which should not be disclosed to the end user. As described by Stjepandić et al. \cite{ipr}, steps to circumvent this issue may include data filtering. Filtering can be implemented by removing meta information such as constraints or by removing occluded parts of the model, limiting the model to the hull of the model. As a positive side-effect, this potentially reduces the complexity of the model, which can be beneficial for rendering performance. +\fGls{STEP}{\e{Standard for the Exchange of Product model data}, a standard formalized in ISO 10303 for product manufacturing information.} files are a common format for exchanging \gls{CAD} data and can be used for this purpose. However, as will be discussed in \autoref{ch:specializedFormats}, other formats are more suitable for rendering and address the inherent limitations of \gls{STEP} files. An important consideration is intellectual property rights when using \gls{CAD} models from engineering processes. The models may contain proprietary information which should not be disclosed to the end user. As described by Stjepandić et al. \cite{ipr}, steps to circumvent this issue may include data filtering. Filtering can be implemented by removing meta information such as constraints or by removing occluded parts of the model, limiting the model to the hull of the model. As a positive side-effect, this potentially reduces the complexity of the model, which can be beneficial for rendering performance. Preprocessing includes triangulation of the meshes, which is a common requirement for rendering engines. Frequently, the triangulated meshes are fine-grained and consist of a large number of triangles. This can lead to performance issues when rendering the scene. One way to handle this is to simplify the meshes by decimating triangles. Procedures for this purpose are well-established and include algorithms for generating level of detail (\gls{LOD}) artifacts \cite{luebke2003level}. @@ -65,7 +65,7 @@ \subsection*{Offline Rendering} \subsection*{Client-Side Real-time Rendering} -An alternative to offline rendering is real-time rendering. Client-side rendering is a frequently used option for real-time rendering. The configurations are only rendered as requested by the end user. This is the main benefit of using a real-time rendering pipeline, as illustrated in \autoref{fig:cad-online}. The rendering is done in the browser, limiting the server to serve the role of a file host and provide the geometry and material information in a 3D exchange format such as \fgls{glTF}{\e{Graphics Library Transmission Format}, a common 3D exchange format optimized for transmission and real-time rendering}. This approach is more flexible and can be used for a large number of configurations. The amount of data to be stored and processed offline grows linearly with the number of options, independent of the number of possible configurations. +An alternative to offline rendering is real-time rendering. Client-side rendering is a frequently used option for real-time rendering. The configurations are only rendered as requested by the end user. This is the main benefit of using a real-time rendering pipeline, as illustrated in \autoref{fig:cad-online}. The rendering is done in the browser, limiting the server to serve the role of a file host and provide the geometry and material information in a 3D exchange format such as \fgls{glTF}{\e{Graphics Library Transmission Format}, a common 3D exchange format optimized for transmission and real-time rendering.}. This approach is more flexible and can be used for a large number of configurations. The amount of data to be stored and processed offline grows linearly with the number of options, independent of the number of possible configurations. \begin{figure}[H] \includegraphics[width=\columnwidth]{resources/cad-pipeline-online.png} @@ -77,7 +77,7 @@ \subsection*{Client-Side Real-time Rendering} \subsection*{Remote Real-time Rendering} -For real-time rendering, an alternative paradigm is remote rendering \cite{remoteRendering}, which employs a server to render the scene and stream the visualization to the browser. The main drawbacks of this approach are network latency, reliance on network stability, and operational cost for the server infrastructure, which frequently requires dedicated \fGlspl{GPU}{\e{Graphics Processing Unit}, a specialized processor for parallel computation} for rendering. +For real-time rendering, an alternative paradigm is remote rendering \cite{remoteRendering}, which employs a server to render the scene and stream the visualization to the browser. The main drawbacks of this approach are network latency, reliance on network stability, and operational cost for the server infrastructure, which frequently requires dedicated \fGlspl{GPU}{\e{Graphics Processing Unit}, a specialized processor for parallel computation.} for rendering. \begin{figure}[H] \includegraphics[width=\columnwidth]{resources/cad-pipeline-remote.png} @@ -97,7 +97,7 @@ \subsubsection{Preprocessing Cost} \subsubsection{Hosting Cost} -The infrastructure cost involved in hosting the application during operations. Generally, lower is better. Offline rendering does not require application servers and mainly relies on storage for the generated images. Similarly, client-side rendering needs storage for the models. These two paradigms may employ \fglspl{CDN}{\e{Content Delivery Network}, a distributed group of servers for caching content near end users}. Remote rendering requires a rendering server. For scenarios where load is unpredictable, additional techniques such as auto-scaling and load balancing may be required. This can be costly and may induce additional complexity. In addition, bandwidth costs need to be considered. +The infrastructure cost involved in hosting the application during operations. Generally, lower is better. Offline rendering does not require application servers and mainly relies on storage for the generated images. Similarly, client-side rendering needs storage for the models. These two paradigms may employ \fglspl{CDN}{\e{Content Delivery Network}, a distributed group of servers for caching content near end users.}. Remote rendering requires a rendering server. For scenarios where load is unpredictable, additional techniques such as auto-scaling and load balancing may be required. This can be costly and may induce additional complexity. In addition, bandwidth costs need to be considered. \subsubsection{Storage} @@ -169,7 +169,7 @@ \subsection*{Web-based Real-Time Renderers} \item {\gls{A-Frame}} \cite{aFrameWebsite} — web framework for building virtual reality experiences. \end{itemize} -In addition, \gls{Unity}, a common game engine for desktop and mobile applications, also supports \fgls{WebGL}{\e{Web Graphics Library}, since 2011 the de-facto standard API for 3D graphics on the web} \cite{unityWebGLCompatibility}. These engines focus on rasterization techniques and are widely used for web-based applications. The focus of these engines lies in real-time rendering performance as used in games, advertising campaigns, virtual reality (VR), augmented reality (AR), medical imaging, scientific visualization, and educational applications. However, they lack support for ray tracing. +In addition, \gls{Unity}, a common game engine for desktop and mobile applications, also supports \fgls{WebGL}{\e{Web Graphics Library}, since 2011 the de-facto standard API for 3D graphics on the web.} \cite{unityWebGLCompatibility}. These engines focus on rasterization techniques and are widely used for web-based applications. The focus of these engines lies in real-time rendering performance as used in games, advertising campaigns, virtual reality (VR), augmented reality (AR), medical imaging, scientific visualization, and educational applications. However, they lack support for ray tracing. \subsection*{Web Path Tracers} \label{sec:web-path-tracers} @@ -190,7 +190,7 @@ \subsection*{Web Path Tracers} \subsection*{WebGPU} -As of 2024, \gls{WebGPU} is a new web \fGls{API}{\e{Application Programming Interface}} that leverages the power of \glspl{GPU} and serves as a successor to \gls{WebGL}. Various applications of \gls{WebGPU} have been investigated in recent years. Examples include \texttt{Dynamical.JS}, a framework for visualizing graphs \cite{dotson2022dynamicaljs}; \texttt{RenderCore}, a research-oriented rendering engine \cite{Bohak_Kovalskyi_Linev_Mrak_Tadel_Strban_Tadel_Yagil_2024}; and demonstrations of how to use \gls{WebGPU} for client-side data aggregation \cite{kimmersdorfer2023webgpu}. +As of 2024, \gls{WebGPU} is a new web \fGls{API}{\e{Application Programming Interface}.} that leverages the power of \glspl{GPU} and serves as a successor to \gls{WebGL}. Various applications of \gls{WebGPU} have been investigated in recent years. Examples include \texttt{Dynamical.JS}, a framework for visualizing graphs \cite{dotson2022dynamicaljs}; \texttt{RenderCore}, a research-oriented rendering engine \cite{Bohak_Kovalskyi_Linev_Mrak_Tadel_Strban_Tadel_Yagil_2024}; and demonstrations of how to use \gls{WebGPU} for client-side data aggregation \cite{kimmersdorfer2023webgpu}. Research on the performance comparison between existing 3D engines and \gls{WebGPU} engines has been conducted as part of the development of \texttt{FusionRender}, which concluded that measurable performance gains can be achieved by using \gls{WebGPU}, but only when effectively leveraging its novel design principles \cite{fusionRenderWebGPU}. Similar findings have emerged from other independent studies, showing that \gls{WebGPU} can be faster than \gls{WebGL} \cite{webGPUWebGis, fransson2023performance, CHICKERUR2024919}. diff --git a/report/parts/results.tex b/report/parts/results.tex index 7405e04..80f115c 100644 --- a/report/parts/results.tex +++ b/report/parts/results.tex @@ -9,7 +9,7 @@ As discussed in the introduction and theory chapters, the goal of this work is to implement a web-based path tracer. The path tracer is designed to be used for product visualization based on engineering \gls{CAD} data, leveraging the \gls{OpenPBR} surface shading model and \gls{WebGPU}. -The concrete result of this work consists of multiple parts. The core is a path tracing library called \texttt{strahl}. The code as well as documentation is published under the \fGls{MIT license}{a permissive license originating at the Massachusetts Institute of Technology (MIT)} on GitHub with an accompanying website. See \url{https://www.github.com/StuckiSimon/strahl} for details. This also includes detailed instructions on how to set up and configure the renderer. The library is published on the \fgls{npm}{a package manager for JavaScript} registry as \texttt{strahl}. This report serves as the primary documentation of the work but does not contain library usage documentation. In addition, a dedicated short paper has been published for WEB3D '24: The 29th International ACM Conference on 3D Web Technology \cite{ownShortPaper}. The short paper includes the main insights and results of this work. +The concrete result of this work consists of multiple parts. The core is a path tracing library called \texttt{strahl}. The code as well as documentation is published under the \fGls{MIT license}{a permissive license originating at the Massachusetts Institute of Technology (MIT).} on GitHub with an accompanying website. See \url{https://www.github.com/StuckiSimon/strahl} for details. This also includes detailed instructions on how to set up and configure the renderer. The library is published on the \fgls{npm}{a package manager for JavaScript.} registry as \texttt{strahl}. This report serves as the primary documentation of the work but does not contain library usage documentation. In addition, a dedicated short paper has been published for WEB3D '24: The 29th International ACM Conference on 3D Web Technology \cite{ownShortPaper}. The short paper includes the main insights and results of this work. This chapter focuses on the implementation details and highlights design decisions of the path tracer. It also provides an overview of the available documentation, insights into the performance of the renderer, and its applicability for the described use case. @@ -96,7 +96,7 @@ \subsection*{Ray Generator} \label{fig:rngSeed} \end{figure} -When increasing the sample count, the differences in the setup remain visible. Adjacent surfaces show similar patterns, as shown in \autoref{fig:rngNoiseArtifactsHighlightsBadNoisy}. These patterns resemble image compression artifacts encountered in aggressively compressed \fGlspl{JPEG}{\e{Joint Photographic Experts Group}, a common method for lossy image compression}. In contrast, the renderings with independent seeds show stark differences in adjacent pixels akin to noise as shown in \autoref{fig:rngNoiseArtifactsHighlightsGoodNoisy}. As shown in \autoref{fig:rngNoiseArtifactsHighlightsBadAnti} compared to \autoref{fig:rngNoiseArtifactsHighlightsGoodAnti}, the anti-aliasing is less noticeable when using independent seeds. The implementation of the anti-aliasing strategy indicated in \autoref{sec:anti-aliasing} is implemented in \coderef{ALIASING} and is highly dependent on the \gls{RNG} setup. +When increasing the sample count, the differences in the setup remain visible. Adjacent surfaces show similar patterns, as shown in \autoref{fig:rngNoiseArtifactsHighlightsBadNoisy}. These patterns resemble image compression artifacts encountered in aggressively compressed \fGlspl{JPEG}{\e{Joint Photographic Experts Group}, a common method for lossy image compression.}. In contrast, the renderings with independent seeds show stark differences in adjacent pixels akin to noise as shown in \autoref{fig:rngNoiseArtifactsHighlightsGoodNoisy}. As shown in \autoref{fig:rngNoiseArtifactsHighlightsBadAnti} compared to \autoref{fig:rngNoiseArtifactsHighlightsGoodAnti}, the anti-aliasing is less noticeable when using independent seeds. The implementation of the anti-aliasing strategy indicated in \autoref{sec:anti-aliasing} is implemented in \coderef{ALIASING} and is highly dependent on the \gls{RNG} setup. \begin{figure}[H] \centering @@ -134,7 +134,7 @@ \subsection*{Ray Generator} \subsection*{Path Tracer} -The path tracer is the core of the library and is responsible to test for intersections, conduct scene sampling, and calculate the final radiance. The basic procedure can be seen in \autoref{fig:path-tracer-workflow}. The ray, cast by the ray generator, is tested for intersections. If it misses, the path will be terminated. If a surface hit is detected, the shading will be generated based on the \gls{OpenPBR} specification. The shading generates a new scattered ray and determines the throughput of the ray. Russian roulette uses the throughput to perform probabilistic path termination. If it should be continued, the ray is cast again. The max depth of the ray determines the end of the path. During termination, the radiance contribution is collected in \fGls{RGB}{\e{red, green, and blue}, a common system for color representation in computer graphics} color space. +The path tracer is the core of the library and is responsible to test for intersections, conduct scene sampling, and calculate the final radiance. The basic procedure can be seen in \autoref{fig:path-tracer-workflow}. The ray, cast by the ray generator, is tested for intersections. If it misses, the path will be terminated. If a surface hit is detected, the shading will be generated based on the \gls{OpenPBR} specification. The shading generates a new scattered ray and determines the throughput of the ray. Russian roulette uses the throughput to perform probabilistic path termination. If it should be continued, the ray is cast again. The max depth of the ray determines the end of the path. During termination, the radiance contribution is collected in \fGls{RGB}{\e{red, green, and blue}, a common system for color representation in computer graphics.} color space. \begin{figure}[H] \centering @@ -251,7 +251,7 @@ \section{Documentation} \label{fig:strahl-homepage} \end{figure} -Documentation on how to configure the renderer is provided. The library uses custom exceptions that the user can catch and handle. It provides different exceptions to enable the user to react appropriately to different error conditions. This includes basic exceptions, where the action is limited, such as missing browser support for \gls{WebGPU}, as well as transparent information on what the user misconfigured. The use of \fGls{TypeScript}{a typed superset of JavaScript developed by Microsoft} enables code completion and type checking. The documentation describes how to control sampling, denoising, environment lighting, and more. See \autoref{fig:strahl-documentation} for an example of a code snippet with an interactive sandbox. +Documentation on how to configure the renderer is provided. The library uses custom exceptions that the user can catch and handle. It provides different exceptions to enable the user to react appropriately to different error conditions. This includes basic exceptions, where the action is limited, such as missing browser support for \gls{WebGPU}, as well as transparent information on what the user misconfigured. The use of \fGls{TypeScript}{a typed superset of JavaScript developed by Microsoft.} enables code completion and type checking. The documentation describes how to control sampling, denoising, environment lighting, and more. See \autoref{fig:strahl-documentation} for an example of a code snippet with an interactive sandbox. \begin{figure}[H] \centering diff --git a/report/parts/theory.tex b/report/parts/theory.tex index 267cb44..0725aa3 100644 --- a/report/parts/theory.tex +++ b/report/parts/theory.tex @@ -938,7 +938,7 @@ \subsubsection{Intersection Testing} \subsubsection{Production Ray Tracing} -Early ray tracing applications were primarily for research purposes or special effects in movies. Adoption expanded as computers became more powerful. One of the first widely used ray tracing software was \fGls{POV-Ray}{\e{Persistence of Vision Ray Tracer}, a cross-platform ray tracing renderer officially released in 1991}, released in 1991 \cite{POV_Ray_Documentation}. Blue Moon Rendering Tools (\gls{BMRT}) \cite{bmrt}, a renderer compliant with \fGls{RenderMan}{a software for photorealistic 3D rendering developed by Pixar}, was released in the mid-1990s and was one of the first ray tracing renderers to be used in the industry. In 2003 \gls{RenderMan} included ray tracing capabilities \cite{RenderMan_11_Release_Notes}. Nowadays, ray tracing is widely used in industries such as film, architecture, and automotive. +Early ray tracing applications were primarily for research purposes or special effects in movies. Adoption expanded as computers became more powerful. One of the first widely used ray tracing software was \fGls{POV-Ray}{\e{Persistence of Vision Ray Tracer}, a cross-platform ray tracing renderer officially released in 1991.}, released in 1991 \cite{POV_Ray_Documentation}. Blue Moon Rendering Tools (\gls{BMRT}) \cite{bmrt}, a renderer compliant with \fGls{RenderMan}{a software for photorealistic 3D rendering developed by Pixar.}, was released in the mid-1990s and was one of the first ray tracing renderers to be used in the industry. In 2003 \gls{RenderMan} included ray tracing capabilities \cite{RenderMan_11_Release_Notes}. Nowadays, ray tracing is widely used in industries such as film, architecture, and automotive. \subsubsection{Hybrid Approaches} @@ -1000,7 +1000,7 @@ \subsubsection{Random Number Generator} \item{Space Usage} — The amount of memory required to store state. \end{itemize} -Based on the use case, other factors such as prediction difficulty or others such as highlighted by O’Neill \cite{o2014pcg} may be important. Cryptography, for example, requires randomness of the \gls{RNG} to prevent an adversary from predicting secret keys. Options to generate the randomness require additional signals \cite{randomnessCryptography} or may require special hardware, such as \fGls{Lavarand}{a hardware \gls{RNG} based on pictures taken of lava lamps to generate randomness} \cite{cloudflareLavaRand}. Many generators are pseudorandom generators. These generators are deterministic and require a seed to start the sequence. For cryptographically secure generators, the seed must be random. +Based on the use case, other factors such as prediction difficulty or others such as highlighted by O’Neill \cite{o2014pcg} may be important. Cryptography, for example, requires randomness of the \gls{RNG} to prevent an adversary from predicting secret keys. Options to generate the randomness require additional signals \cite{randomnessCryptography} or may require special hardware, such as \fGls{Lavarand}{a hardware \gls{RNG} based on pictures taken of lava lamps to generate randomness.} \cite{cloudflareLavaRand}. Many generators are pseudorandom generators. These generators are deterministic and require a seed to start the sequence. For cryptographically secure generators, the seed must be random. However, for a path tracer, there is no need for cryptographic security. Instead, it is more important to have high performance and to have a long period to avoid repetition. Therefore, a pseudorandom number generator without a cryptographically secure seed is sufficient. One option for such a pseudorandom generator is using Xorshifts, such as described by Marsaglia \cite{marsaglia2003xorshift}. The algorithm can be defined as shown in \autoref{code:xorShift}. $x$ is the state of the \gls{RNG} and $a$, $b$ and $c$ are constants which are chosen to achieve good statistical properties. Frequent choices for these constants are $a = 13$, $b = 17$, and $c = 5$. @@ -1015,7 +1015,7 @@ \subsubsection{Random Number Generator} \label{code:xorShift} \end{figure} -The Mersenne Twister \cite{rngMersenneTwister} is an alternative \gls{RNG}. It is a pseudorandom number generator which has a long period and good statistical properties. However, it is slower than Xorshifts \cite{o2014pcg}. More recently, \fGls{PCG}{\e{Permuted Congruential Generator}, a family of random number generators} has been proposed as an alternative to these options. \gls{PCG} is a family of fast generators that is well-suited for ray tracing use. +The Mersenne Twister \cite{rngMersenneTwister} is an alternative \gls{RNG}. It is a pseudorandom number generator which has a long period and good statistical properties. However, it is slower than Xorshifts \cite{o2014pcg}. More recently, \fGls{PCG}{\e{Permuted Congruential Generator}, a family of random number generators.} has been proposed as an alternative to these options. \gls{PCG} is a family of fast generators that is well-suited for ray tracing use. \subsubsection{Anti-aliasing} \label{sec:anti-aliasing} @@ -1073,11 +1073,11 @@ \section{Computer Graphics Technology} \paragraph{Parallel Processing} -Sequential processing is limited in terms of performance. As the amount of data to process grows, the time to process the data grows linearly. Computer graphics exhibits a large number of problems which can be parallelized. In 1966, Flynn introduced a classification system for computer architectures based on the instruction streams and data streams that can be processed in parallel \cite{flynnTaxonomy,flynnTaxonomy2}. Already in 1970, Watkins described an algorithm for computer graphics leveraging a specialized processor for parallel processing \cite{surfaceAlgorithmProcessor}. Further research, such as Chap, a \fGls{SIMD}{\e{Single Instruction, Multiple Data}, a type of parallel processing of data points with a single instruction as defined by Flynn \cite{flynnTaxonomy}} graphics processor proposed in 1984 by Levinthal and Porter as part of Lucasfilm, introduced a special-purpose processor executing a single instruction on multiple data points \cite{chapSIMDgpu}. +Sequential processing is limited in terms of performance. As the amount of data to process grows, the time to process the data grows linearly. Computer graphics exhibits a large number of problems which can be parallelized. In 1966, Flynn introduced a classification system for computer architectures based on the instruction streams and data streams that can be processed in parallel \cite{flynnTaxonomy,flynnTaxonomy2}. Already in 1970, Watkins described an algorithm for computer graphics leveraging a specialized processor for parallel processing \cite{surfaceAlgorithmProcessor}. Further research, such as Chap, a \fGls{SIMD}{\e{Single Instruction, Multiple Data}, a type of parallel processing of data points with a single instruction as defined by Flynn \cite{flynnTaxonomy}.} graphics processor proposed in 1984 by Levinthal and Porter as part of Lucasfilm, introduced a special-purpose processor executing a single instruction on multiple data points \cite{chapSIMDgpu}. \paragraph{GPU} -The first consumer graphics processing unit (\gls{GPU}), the GeForce 256 produced by NVIDIA \cite{evolutionOfGPU}, was developed in the 1990s and extended upon research conducted in the decades prior such as the superworkstations introduced by Silicon Graphics in the 1980s \cite{sigWorkstation}. These workstations were special-purpose computers optimized for computer graphics. The \gls{GPU} on the other hand is a specialized processor that is well-suited for workloads which require parallel processing and can be installed on a standard computer. While \gls{CPU} parallelization on consumer hardware is generally limited to a few cores, modern \glspl{GPU} have thousands of compute units that enable \gls{SIMD} and, more commonly, \fGls{SIMT}{\e{Single Instruction, Multiple Threads}, an extension to \gls{SIMD} which is frequently used on modern \glspl{GPU}} processing. The difference is that \gls{SIMD} operates on a single processor, while \gls{SIMT} operates on multiple processors. +The first consumer graphics processing unit (\gls{GPU}), the GeForce 256 produced by NVIDIA \cite{evolutionOfGPU}, was developed in the 1990s and extended upon research conducted in the decades prior such as the superworkstations introduced by Silicon Graphics in the 1980s \cite{sigWorkstation}. These workstations were special-purpose computers optimized for computer graphics. The \gls{GPU} on the other hand is a specialized processor that is well-suited for workloads which require parallel processing and can be installed on a standard computer. While \gls{CPU} parallelization on consumer hardware is generally limited to a few cores, modern \glspl{GPU} have thousands of compute units that enable \gls{SIMD} and, more commonly, \fGls{SIMT}{\e{Single Instruction, Multiple Threads}, an extension to \gls{SIMD} which is frequently used on modern \glspl{GPU}.} processing. The difference is that \gls{SIMD} operates on a single processor, while \gls{SIMT} operates on multiple processors. Due to computational complexity, ray tracing techniques have been limited to offline rendering for a long time. Early ray tracers such as \gls{BMRT} were developed, focusing on leveraging the \gls{CPU} for computations. The introduction of \glspl{GPU} has led to further research optimizing speed for ray tracing techniques. One such example of research for a well-established technique is \gls{BVH} construction on the \gls{GPU} \cite{lauterbach2009GPUbvh}. This research has enabled real-time ray tracing in recent years. Notable developments include reservoir-based spatio-temporal importance resampling (\gls{ReSTIR}) \cite{restir} and subsequent improvements \cite{restirAdvancements,restirGeneralized,restirArea}. @@ -1108,10 +1108,10 @@ \subsection*{OpenGL} \subsection*{Modern Graphics APIs} -While \gls{OpenGL} and derivatives such as \fgls{OpenGL ES}{\e{OpenGL for Embedded Systems}, a subset of \gls{OpenGL} designed for embedded systems like smartphones} have been widely adopted, the introduction of a number of new \glspl{API} has changed the landscape. The standards share an understanding of giving developers more control over the hardware and can be more efficient than \gls{OpenGL}. Modern hardware-accelerated features such as ray tracing are more easily accessible using these new \glspl{API}. Some of the most notable \glspl{API} are: +While \gls{OpenGL} and derivatives such as \fgls{OpenGL ES}{\e{OpenGL for Embedded Systems}, a subset of \gls{OpenGL} designed for embedded systems like smartphones.} have been widely adopted, the introduction of a number of new \glspl{API} has changed the landscape. The standards share an understanding of giving developers more control over the hardware and can be more efficient than \gls{OpenGL}. Modern hardware-accelerated features such as ray tracing are more easily accessible using these new \glspl{API}. Some of the most notable \glspl{API} are: \begin{itemize} - \item{\gls{Vulkan}} — Developed by the \fgls{Khronos Group}{a consortium for developing interoperability standards for 3D graphics}, \gls{Vulkan} is a low-level \gls{API} that is supported on a wide range of platforms. + \item{\gls{Vulkan}} — Developed by the \fgls{Khronos Group}{a consortium for developing interoperability standards for 3D graphics.}, \gls{Vulkan} is a low-level \gls{API} that is supported on a wide range of platforms. \item{\gls{Metal}} — Developed by Apple, \gls{Metal} is a low-level \gls{API} that is supported on Apple devices. \item{\gls{DirectX 12}} — Developed by Microsoft, DirectX is a collection of \glspl{API} for Microsoft Windows. \end{itemize} @@ -1124,7 +1124,7 @@ \subsection*{WebGL} \subsection*{WebGPU} -\gls{WebGPU} is a new web standard developed by \fGls{W3C}{\e{World Wide Web Consortium}, a non-profit organization dedicated to developing web standards} \cite{webgpuSpecification}. Unlike its predecessor, \gls{WebGL}, it is no longer based on \gls{OpenGL}. One of the main capabilities is support for \gls{GPGPU} by design. While all major browser vendors have announced intent to support \gls{WebGPU}, to date only Chrome has shipped \gls{WebGPU} for general use on desktop as well as mobile. +\gls{WebGPU} is a new web standard developed by \fGls{W3C}{\e{World Wide Web Consortium}, a non-profit organization dedicated to developing web standards.} \cite{webgpuSpecification}. Unlike its predecessor, \gls{WebGL}, it is no longer based on \gls{OpenGL}. One of the main capabilities is support for \gls{GPGPU} by design. While all major browser vendors have announced intent to support \gls{WebGPU}, to date only Chrome has shipped \gls{WebGPU} for general use on desktop as well as mobile. The standard is still in development and new features are being added. Common 3D engines such as \gls{Babylon.js}, \gls{Three.js}, \gls{PlayCanvas} and \gls{Unity} have announced support for \gls{WebGPU}. @@ -1133,9 +1133,9 @@ \subsubsection{Implementations} Three major implementations of \gls{WebGPU} exist: \begin{itemize} - \item{\gls{Dawn}} \cite{dawnImplementation} — Developed by Google, \gls{Dawn} is a C++ library which provides a \gls{WebGPU} implementation. It is used in browsers based on \fGls{Chromium}{a browser engine primarily developed by Google, used in browsers such as Chrome, Edge, and Opera}. - \item{\gls{wgpu}} \cite{wgpuImplementation} — A Rust library which provides a \gls{WebGPU} implementation. It is used in Firefox and \fGls{Deno}{a JavaScript runtime, alternative to Node.js}. - \item{\fGls{WebKit}{a browser engine primarily used in Safari} \gls{WebGPU}} \cite{webKitWebGPUImplementation} — Developed by Apple for Safari. + \item{\gls{Dawn}} \cite{dawnImplementation} — Developed by Google, \gls{Dawn} is a C++ library which provides a \gls{WebGPU} implementation. It is used in browsers based on \fGls{Chromium}{a browser engine primarily developed by Google, used in browsers such as Chrome, Edge, and Opera.}. + \item{\gls{wgpu}} \cite{wgpuImplementation} — A Rust library which provides a \gls{WebGPU} implementation. It is used in Firefox and \fGls{Deno}{a JavaScript runtime, alternative to Node.js.}. + \item{\fGls{WebKit}{a browser engine primarily used in Safari.} \gls{WebGPU}} \cite{webKitWebGPUImplementation} — Developed by Apple for Safari. \end{itemize} As the standard is under active development, there are differences between the implementations and the specification \cite{wgpuStandardDeviation}. However, the implementations are largely compatible thanks to alignment efforts and the extensive conformance test suite \cite{WebGPUConformanceTestSuite}. Generally, these implementations run natively on modern graphics \glspl{API} such as \gls{Vulkan}, \gls{Metal}, and \gls{DirectX 12}. Some also support \gls{OpenGL} and \gls{WebGL} as a fallback. @@ -1281,7 +1281,7 @@ \section{Exchange Formats} In order to exchange 3D scenes between a multitude of applications, various standardized formats have been developed. These formats are optimized for different use cases depending on the requirements of the application. For this thesis, the focus is on formats well-suited for real-time rendering on the web. In comparison to other use cases, certain aspects are critical on the web. These aspects include: \begin{itemize} - \item{Efficiency} — It should be optimized for transmission and parsing. While data compression algorithms such as \fGls{gzip}{\e{GNU zip}, a file format and software application for compression and decompression} can alleviate some of the issues during transmission, pure text-based formats are generally less efficient than binary formats. + \item{Efficiency} — It should be optimized for transmission and parsing. While data compression algorithms such as \fGls{gzip}{\e{GNU zip}, a file format and software application for compression and decompression.} can alleviate some of the issues during transmission, pure text-based formats are generally less efficient than binary formats. \item{Feature Set} — The format should support a wide range of features such as geometry, materials, and scene graphs. \item{Extensibility} — The format should be extensible to support additional features. \item{Interoperability} — 3D engines and applications should widely support the format. @@ -1292,24 +1292,24 @@ \section{Exchange Formats} \subsection*{General Purpose Formats} -One of the most widely used formats is Wavefront \gls{OBJ}, which was developed in the 1980s. The format is text-based and has basic support for materials and textures via a companion \fGls{MTL}{\e{Material Template Library}, a companion file format to \gls{OBJ} for material definitions} file. However, it lacks support for more advanced features such as animations. Additionally, due to its encoding, it is not well-suited for transmission over the web compared to more modern alternatives. +One of the most widely used formats is Wavefront \gls{OBJ}, which was developed in the 1980s. The format is text-based and has basic support for materials and textures via a companion \fGls{MTL}{\e{Material Template Library}, a companion file format to \gls{OBJ} for material definitions.} file. However, it lacks support for more advanced features such as animations. Additionally, due to its encoding, it is not well-suited for transmission over the web compared to more modern alternatives. -Formats such as the proprietary \fGls{FBX}{\e{Filmbox}, a proprietary 3D exchange format nowadays managed by Autodesk} by Autodesk, established in 2006, can address the shortcomings in terms of feature set. A wide range of applications supports the format. However, one of the main disadvantages is the proprietary nature of the format, which can make it challenging to integrate in applications that lack access to the \fGls{SDK}{\e{Software Development Kit}}. +Formats such as the proprietary \fGls{FBX}{\e{Filmbox}, a proprietary 3D exchange format nowadays managed by Autodesk.} by Autodesk, established in 2006, can address the shortcomings in terms of feature set. A wide range of applications supports the format. However, one of the main disadvantages is the proprietary nature of the format, which can make it challenging to integrate in applications that lack access to the \fGls{SDK}{\e{Software Development Kit}.}. \subsection*{Specialized Formats} \label{ch:specializedFormats} -For specific use cases, specialized formats have been developed. One such example is \gls{STEP}. The format is widely used in product manufacturing and offers support for a wide range of modeling features. The \fGls{ASCII}{\e{American Standard Code for Information Interchange}, a character encoding standard for electronic communication} encoding of the format is human-readable but is not well-suited for real-time rendering requirements of the web due to transmission size and parsing complexity \cite{marjudi2010StepIgesreview}. Parsing complexity is exhibited by the large number of different entities which can be defined in the format. +For specific use cases, specialized formats have been developed. One such example is \gls{STEP}. The format is widely used in product manufacturing and offers support for a wide range of modeling features. The \fGls{ASCII}{\e{American Standard Code for Information Interchange}, a character encoding standard for electronic communication.} encoding of the format is human-readable but is not well-suited for real-time rendering requirements of the web due to transmission size and parsing complexity \cite{marjudi2010StepIgesreview}. Parsing complexity is exhibited by the large number of different entities which can be defined in the format. -Another such format is \fGls{STL}{\e{Stereolithography}, a 3D exchange format developed by 3D Systems} which is widely used in 3D printing and supports binary and \gls{ASCII} encoding. It lacks support for advanced features such as material representation, animations, and scene graphs. +Another such format is \fGls{STL}{\e{Stereolithography}, a 3D exchange format developed by 3D Systems.} which is widely used in 3D printing and supports binary and \gls{ASCII} encoding. It lacks support for advanced features such as material representation, animations, and scene graphs. \subsection*{Interoperability Formats} The aforementioned formats have shortcomings in interoperability and feature set for complex 3D scenes, such as those found in the film industry. Special formats have been developed to address issues encountered in these scenes. -Other formats such as \fGls{COLLADA}{\e{Collaborative Design Activity}, a 3D exchange format managed by \gls{Khronos Group}} have been developed to improve the exchange of 3D scenes between different applications. Based on \fGls{XML}{\e{Extensible Markup Language}}, the format was established in 2004 and has been managed by the \gls{Khronos Group} since then. However, its latest release was in 2008. +Other formats such as \fGls{COLLADA}{\e{Collaborative Design Activity}, a 3D exchange format managed by \gls{Khronos Group}.} have been developed to improve the exchange of 3D scenes between different applications. Based on \fGls{XML}{\e{Extensible Markup Language}.}, the format was established in 2004 and has been managed by the \gls{Khronos Group} since then. However, its latest release was in 2008. -One notable format is \fGls{USD}{\e{Universal Scene Description}, a 3D exchange format}, which has been open-sourced by Pixar in 2016. Similar to \gls{COLLADA}, the format is designed with interoperability in mind and is widely supported by 3D engines and applications. The main focus of \gls{USD} is support for complex scenes and complex collaboration workflows, which are common in the film industry but are less relevant for the use case in this thesis. +One notable format is \fGls{USD}{\e{Universal Scene Description}, a 3D exchange format.}, which has been open-sourced by Pixar in 2016. Similar to \gls{COLLADA}, the format is designed with interoperability in mind and is widely supported by 3D engines and applications. The main focus of \gls{USD} is support for complex scenes and complex collaboration workflows, which are common in the film industry but are less relevant for the use case in this thesis. \subsection*{Runtime Formats} @@ -1510,7 +1510,7 @@ \subsection*{BxDF} \subsection*{Microfacet Theory} -While the macroscopic appearance of a surface is visible to the human eye, the microscopic structure of the surface is not. However, the microscopic structure is crucial in determining how light interacts with the surface. Microfacet theory is a model which describes this microscopic structure. Microsurfaces are aggregated to form the coarse macroscopic surface. See \autoref{fig:microfacet-model} for a visualization of a rough surface. Theoretically, it would be possible to model the geometry as microsurfaces, but in practice, this leads to a high computational complexity due to increased storage and computation requirements. Instead, the distribution of normals is described as a normal distribution function (\gls{NDF}). A rough surface has a wide distribution of normals, which leads to scattering, resulting in a diffuse reflection. A smooth surface has a narrow distribution of normals, which leads to a specular reflection. One of the most widely used \glspl{NDF} is the \fGls{GGX}{\e{Ground Glass Unknown}, a frequently used microfacet distribution function derived by Neyret and independently by Walter et al. \cite{walter2007microfacet,heitz2018sampling}} distribution function. \cite{Pharr_Physically_Based_Rendering_2023} +While the macroscopic appearance of a surface is visible to the human eye, the microscopic structure of the surface is not. However, the microscopic structure is crucial in determining how light interacts with the surface. Microfacet theory is a model which describes this microscopic structure. Microsurfaces are aggregated to form the coarse macroscopic surface. See \autoref{fig:microfacet-model} for a visualization of a rough surface. Theoretically, it would be possible to model the geometry as microsurfaces, but in practice, this leads to a high computational complexity due to increased storage and computation requirements. Instead, the distribution of normals is described as a normal distribution function (\gls{NDF}). A rough surface has a wide distribution of normals, which leads to scattering, resulting in a diffuse reflection. A smooth surface has a narrow distribution of normals, which leads to a specular reflection. One of the most widely used \glspl{NDF} is the \fGls{GGX}{\e{Ground Glass Unknown}, a frequently used microfacet distribution function derived by Neyret and independently by Walter et al. \cite{walter2007microfacet,heitz2018sampling}.} distribution function. \cite{Pharr_Physically_Based_Rendering_2023} \begin{figure}[H] \centering @@ -1560,14 +1560,14 @@ \subsection*{Material Description} \begin{itemize} \item{Disney Principled \gls{BRDF}} \cite{disney2012pbr} — Developed by Disney in 2012, the model is not necessarily physically accurate and focuses on being art-directable with limited parameters. Although the model is influential, it is not an established standard and lacks a reference implementation despite being adopted by some applications, including \gls{RenderMan} \cite{renderManDisneyPbrDocs}. - \item{Autodesk Standard Surface} \cite{autodeskStandardSurface} — Developed by Autodesk, the goals are similar to Disney Principled \gls{BRDF} in that the parameter set is kept small in order to be easier to use. The model is developed as an open standard with a reference implementation in \fgls{OSL}{\e{Open Shading Language}, a shading language for production global illumination renderers maintained by Academy Software Foundation}. However, the standard has not seen much development in recent years. + \item{Autodesk Standard Surface} \cite{autodeskStandardSurface} — Developed by Autodesk, the goals are similar to Disney Principled \gls{BRDF} in that the parameter set is kept small in order to be easier to use. The model is developed as an open standard with a reference implementation in \fgls{OSL}{\e{Open Shading Language}, a shading language for production global illumination renderers maintained by the Academy Software Foundation.}. However, the standard has not seen much development in recent years. \item{Adobe Standard Material} \cite{adobeStandardMaterial} — Developed by Adobe, the model is also influenced by the Disney Principled \gls{BRDF} and Autodesk Standard Surface. It has a full specification and has been adopted by Adobe for its applications. \item{\gls{DSPBR}} \cite{dspbrModel} — Developed by Dassault Systèmes, it is also influenced by the Disney Principled \gls{BRDF}. The specification is detailed and the model is designed for industrial use cases. \end{itemize} -In addition to these standards, many real-time rendering engines, such as \gls{Unity} and \fGls{Unreal}{Unreal Engine, a proprietary, cross-platform game engine developed by Epic Games}, and modeling software, such as \fGls{Blender}{an open-source 3D computer graphics software toolset} and \fGls{Rhino3D}{\e{Rhinoceros}, a proprietary 3D computer graphics and \gls{CAD} toolset}, have their own shading models. Supporting many different shading models in a web-based real-time rendering application can be challenging, making the need for a common material description standard apparent. This is where new models come into play: open standards developed by multiple companies intended to be used across different applications to address the siloed development of prior shading models. +In addition to these standards, many real-time rendering engines, such as \gls{Unity} and \fGls{Unreal}{Unreal Engine, a proprietary, cross-platform game engine developed by Epic Games.}, and modeling software, such as \fGls{Blender}{an open-source 3D computer graphics software toolset.} and \fGls{Rhino3D}{\e{Rhinoceros}, a proprietary 3D computer graphics and \gls{CAD} toolset.}, have their own shading models. Supporting many different shading models in a web-based real-time rendering application can be challenging, making the need for a common material description standard apparent. This is where new models come into play: open standards developed by multiple companies intended to be used across different applications to address the siloed development of prior shading models. -\gls{MaterialX} is an open standard which was originally developed by Lucasfilm in 2012. The standard has since been adopted by the \fgls{ASWF}{\e{Academy Software Foundation}, an organization promoting the development and adoption of open-source software in the motion picture industry} as an open standard with support from a variety of companies. \gls{MaterialX} supports representing materials using the flexibility of a node-based approach. While not strictly limited to \gls{PBR}, it provides a wide range of features to describe physically-based materials \cite{Harrysson2019}. The standard supports extensive shader generation capabilities. This permits to re-use shaders across different applications and frameworks and aids in understanding the used approximations. +\gls{MaterialX} is an open standard which was originally developed by Lucasfilm in 2012. The standard has since been adopted by the \fgls{ASWF}{\e{Academy Software Foundation}, an organization promoting the development and adoption of open-source software in the motion picture industry.} as an open standard with support from a variety of companies. \gls{MaterialX} supports representing materials using the flexibility of a node-based approach. While not strictly limited to \gls{PBR}, it provides a wide range of features to describe physically-based materials \cite{Harrysson2019}. The standard supports extensive shader generation capabilities. This permits to re-use shaders across different applications and frameworks and aids in understanding the used approximations. \subsection*{OpenPBR}