<commit_before>\part{Rasterizer}


\section{Introduction}
Rasterization is an object order method. We have a list of objects in our scene and draw one after another. This is the opposite of an image order rendering technique, like raytracing, where each pixel is traversed. This is why raytracing can be slower than rasterization; -testing each pixel and, for each pixel, testing every object. This pipeline can require more computation than a rasterization pipeline, which is iterating over every object once and coloring the pixels the object occupies.

Raytracing can be accelerated by spatial sorting, like bounding volume hierarchies, but so can rasterization. Frustrum- and occlusion-culling are just two examples.

The most basic job of a rasterizer is to draw triangles using pixels on a raster display. A popular method is scanline rendering, because of cache locality and the way displays update their image a scanline at a time.

\begin{figure}[H]
  \centering
  \includegraphics{Media/raster_scanline.png}
  \caption{Scanline rasterization of pixels}   
  \label{fig:Scanline rasterization of pixels}
\end{figure}


\section{Rasterization Pipelines}

Write something general about rasterization pipelines, to introduce the concept.


\subsection{Forward Rendering}

\begin{figure}[H]
	\begin{math}
		\orderof(\sum {pixel_{rasterized + shaded}} \times \sum light)
	\end{math}
	\caption{The rasterization and shading complexity of a Forward Rendering Pipeline}
	\label{fig:FRP_complexity}
\end{figure}

In a forward rendering pipeline (FRP), all surfaces are shaded immediately. As figure~\ref{fig:FRP_complexity} show, this doesn't scale well as the number of lights go up.

\subsubsection{Multiple Lights}

There are different methods for dealing with multiple lights in an FRP. These different approaches all have their strengths and weaknesses.

\paragraph{Ubershader}

The Ubershader is a single-pass shader that handles any material and light combination or programatically create different shaders for all material- and light-type combinations. Creating an uber-shader becomes unwieldy as the types of lights and materials increase due to combinatorial explosion, each material-light pair will require custom code.

\paragraph{Multi-pass}

Another way of shading a surface with an arbitrary number lights is using a multi-pass technique. Each geometry is shaded with each light at a time. The framebuffer is set to blend fragments together, combining the effect of each light. Multi-pass rendering requires re-drawing the entire mesh for each light and requires transforming vertices and rasterizing each pass, making the scene quickly vertex and fillrate bound.

\subsection{Deferred Rendering}

\begin{figure}[H]
	\begin{math}
		\orderof(\sum {pixel_{rasterized}}) + \orderof(\sum {pixel_{GBuffer}} \times \sum {light})
	\end{math}
	\caption{The rasterization and shading complexity of a Deferred Rendering Pipeline}
	\label{fig:DRP_complexity}
\end{figure}

Deferred Rendering Deering1988 is a rasterization-based rendering technique in which the result of drawing the scene is divided and stored in intermediate buffers (called the G-Buffer) using multiple render targets (MRT).  The G-buffer, or Geometry-Buffer, is called so because it stores per pixel geometric properties like depth, normals and texture coordinates; - a caching of the geometry that the camera is viewing, for repeated use further down the rendering pipeline. The G-Buffer is input into a shading algorithm, usually as samplers, to produce the final result. This reduces the input of the scene to what is in the view space when performing shading, and specially reduce the cost of lighting. Lights are rendered in a second pass as geometric volumes, who's surface color is accumulated into a final render target using additive blending. In essence, this gives us a rendering pipeline which drives a single pass per light, as opposed to forward rendering's single pass with a complex shader or multi-pass techniques (typically single pass per mesh per light).

Historically, deferred rendering has had some limitations. Due to the nature of the G-Buffer, transparency couldn't be supported directly in the deferred pipeline. Instead, a forward renderer has commonly been used for handling transparent objects in the scene. Further, a deferred pipeline can't take advantage of Multisample anti-aliasing (MSAA) in hardware, forcing quite expensive anti-aliasing filters to be programmed into the pipeline. The amount of parameters one can pass to shader programs is also directly limited by the size of the G-Buffer, and the amount of render targets supported. This forces a deferred pipeline to be quite expensive, bandwidth and memory wise. Further, due to how a deferred pipeline accumulates the color of lights using additive blending, overlapping lights cause overhead.

On the positive side, a deferred rendering pipeline is greatly simplified and more general than a forward rendering pipeline. The scene is rendered with one shader program, filling the G-Buffer, and then the G-Buffer is handled in multiple passes by different shader programs, like the lighting pass, shadow pass, and so forth. These shader programs can also be simplified, as everything in the G-Buffer used for the shading, already is in screen-space. The cost for light calculation is greatly reduced compared to a forward renderer, since shading is only done in screen-space for geometry that is visible by the camera; there is no wasted shading effort.

A deferred shading approach could lend well as a hybrid foundation of rasterization and raytracing, as the G-Buffer data could be generated by any method, as long as it is in screenspace, and could also be used as a first-ray lookup for a raytracer.<commit_msg>figure -> equation. use \eqref{labeltext} to refer to numbered equations<commit_after>\part{Rasterizer}


\section{Introduction}
Rasterization is an object order method. We have a list of objects in our scene and draw one after another. This is the opposite of an image order rendering technique, like raytracing, where each pixel is traversed. This is why raytracing can be slower than rasterization; -testing each pixel and, for each pixel, testing every object. This pipeline can require more computation than a rasterization pipeline, which is iterating over every object once and coloring the pixels the object occupies.

Raytracing can be accelerated by spatial sorting, like bounding volume hierarchies, but so can rasterization. Frustrum- and occlusion-culling are just two examples.

The most basic job of a rasterizer is to draw triangles using pixels on a raster display. A popular method is scanline rendering, because of cache locality and the way displays update their image a scanline at a time.

\begin{figure}[H]
  \centering
  \includegraphics{Media/raster_scanline.png}
  \caption{Scanline rasterization of pixels}   
  \label{fig:Scanline rasterization of pixels}
\end{figure}


\section{Rasterization Pipelines}

Write something general about rasterization pipelines, to introduce the concept.


\subsection{Forward Rendering}

The rasterization and shading complexity of a Forward Rendering Pipeline

\begin{equation}\label{fig:FRP_complexity}
  \orderof(\sum {pixel_{rasterized + shaded}} \times \sum light)
\end{equation}

In a forward rendering pipeline (FRP), all surfaces are shaded immediately. As figure \eqref{fig:FRP_complexity} shows, this doesn't scale well as the number of lights go up.

\subsubsection{Multiple Lights}

There are different methods for dealing with multiple lights in an FRP. These different approaches all have their strengths and weaknesses.

\paragraph{Ubershader}

The Ubershader is a single-pass shader that handles any material and light combination or programatically create different shaders for all material- and light-type combinations. Creating an uber-shader becomes unwieldy as the types of lights and materials increase due to combinatorial explosion, each material-light pair will require custom code.

\paragraph{Multi-pass}

Another way of shading a surface with an arbitrary number lights is using a multi-pass technique. Each geometry is shaded with each light at a time. The framebuffer is set to blend fragments together, combining the effect of each light. Multi-pass rendering requires re-drawing the entire mesh for each light and requires transforming vertices and rasterizing each pass, making the scene quickly vertex and fillrate bound.

\subsection{Deferred Rendering}

The rasterization and shading complexity of a Deferred Rendering Pipeline:
\begin{equation}\label{fig:DRP_complexity}
		\orderof(\sum {pixel_{rasterized}}) + \orderof(\sum {pixel_{GBuffer}} \times \sum {light})
\end{equation}

Deferred Rendering Deering1988 is a rasterization-based rendering technique in which the result of drawing the scene is divided and stored in intermediate buffers (called the G-Buffer) using multiple render targets (MRT).  The G-buffer, or Geometry-Buffer, is called so because it stores per pixel geometric properties like depth, normals and texture coordinates; - a caching of the geometry that the camera is viewing, for repeated use further down the rendering pipeline. The G-Buffer is input into a shading algorithm, usually as samplers, to produce the final result. This reduces the input of the scene to what is in the view space when performing shading, and specially reduce the cost of lighting. Lights are rendered in a second pass as geometric volumes, who's surface color is accumulated into a final render target using additive blending. In essence, this gives us a rendering pipeline which drives a single pass per light, as opposed to forward rendering's single pass with a complex shader or multi-pass techniques (typically single pass per mesh per light).

Historically, deferred rendering has had some limitations. Due to the nature of the G-Buffer, transparency couldn't be supported directly in the deferred pipeline. Instead, a forward renderer has commonly been used for handling transparent objects in the scene. Further, a deferred pipeline can't take advantage of Multisample anti-aliasing (MSAA) in hardware, forcing quite expensive anti-aliasing filters to be programmed into the pipeline. The amount of parameters one can pass to shader programs is also directly limited by the size of the G-Buffer, and the amount of render targets supported. This forces a deferred pipeline to be quite expensive, bandwidth and memory wise. Further, due to how a deferred pipeline accumulates the color of lights using additive blending, overlapping lights cause overhead.

On the positive side, a deferred rendering pipeline is greatly simplified and more general than a forward rendering pipeline. The scene is rendered with one shader program, filling the G-Buffer, and then the G-Buffer is handled in multiple passes by different shader programs, like the lighting pass, shadow pass, and so forth. These shader programs can also be simplified, as everything in the G-Buffer used for the shading, already is in screen-space. The cost for light calculation is greatly reduced compared to a forward renderer, since shading is only done in screen-space for geometry that is visible by the camera; there is no wasted shading effort.

A deferred shading approach could lend well as a hybrid foundation of rasterization and raytracing, as the G-Buffer data could be generated by any method, as long as it is in screenspace, and could also be used as a first-ray lookup for a raytracer.
{'fraction_non_alphanumeric': 0.04326007959854646, 'fraction_numerical': 0.0006921612735767433, 'mean_word_length': 4.949047864127638, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 4, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2952141', 'n_tokens_mistral': 2783, 'n_tokens_neox': 2664, 'n_words': 1636}