Changeset 252 for trunk/VUT/doc

Timestamp:

08/26/05 14:56:09 (19 years ago)

Author:

mattausch

Message:

added ogre image

Location:

trunk/VUT/doc/SciReport

Files:

• images/ogre_terrain.png (added)
• images/vis_chc.png (added)
• images/vis_viewfrustum.png (added)
• online.tex (modified) (4 diffs)

trunk/VUT/doc/SciReport/online.tex

@@ -42 +42 @@
 connectivity, occlusion by few closest depth layers).
 
+\begin{figure}%[htb]
+  %\centerline
+        \centering \footnotesize
+        \begin{tabular}{c}
+        \includegraphics[width=0.5\textwidth, draft=\DRAFTFIGS]{images/ogre_terrain} \\
+        %\hline 
+        \includegraphics[width=0.25\textwidth, draft=\DRAFTFIGS]{images/vis_viewfrustum} \hfill \includegraphics[width=0.25\textwidth, draft=\DRAFTFIGS]{images/vis_chc} \\
+        \end{tabular}
+\label{tab:averages}
+  \caption{Top row: The rendered scene. Bottom row: The visualizion of the rendering overdraw.
+    Using view frustum culling (left image) vs. occlusion queries (right image).
+    The yellow boxes show the actually rendered scene objects. The
+        red boxes depict the view frustum culled hierarchy nodes, the blue boxes depict the
+        occlusion query culled hierarchy nodes.}
+  \label{fig:online_culling_example}
+\end{figure}
+
 Recent graphics hardware natively supports an \emph{occlusion query}
 to detect the visibility of an object against the current contents of the
@@ -58 +75 @@
 existing real-time rendering packages on architectures supporting the
 underlying occlusion query.
-
+In figure~\ref{fig:online_culling_example}, the same scene (top row) is rendered using view frustum
+culling (visualization in the bottom left image) versus online culling using occlusion queries (visualization 
+in the bottom right image). We can clearly see the large overdraw that happens for view frustum culling.
 %Using spatial and assuming temporal coherence
 
@@ -661 +680 @@
 wait till the result of the query becomes available.
 
-\subsection{Initial depth pass}
-\label{sec:initial}
-
-To achieve maximal performance on modern GPU's, one has to take care of a number of issues.
-First, it is very important to reduce material switching. Thus modern rendering engines sort the 
-objects (or patches) by materials in order to eliminate the material switching as good as possible. 
-
-Next, materials can be very costly, sometimes complicated shaders have to be evaluated several times per batch. Hence it should be
-avoided to render the full material for fragments which eventually turn out to be occluded. This can be achieved
-by rendering an initial depth pass (i.e., enabling only depth write to fill the depth
-buffer). Afterwards the geometry is rendered again, this time with full shading. Because the 
-depth buffer is already established, invisible fragments will be discarded before any shading is done calculated.
-
-This approach can be naturally adapted for use with the CHC algorithm. Only an initial depth pass is rendered
-in front-to-back order using the CHC algorithm. The initial pass is sufficient to fill the depth buffer and determine the visible geometry. Then only the visible geometry is rendered again, exploiting the full optimization and material sorting capability of the rendering engine.
-
-\subsection{Batching multiple queries}
 \begin{figure}%[htb]
 {\footnotesize
@@ -685 +687 @@
   \label{fig:pseudocode_batching}
 \end{figure}
+
+\subsection{Initial depth pass}
+\label{sec:initial}
+
+To achieve maximal performance on modern GPU's, one has to take care of a number of issues.
+First, it is very important to reduce material switching. Thus modern rendering engines sort the 
+objects (or patches) by materials in order to eliminate the material switching as good as possible. 
+
+Next, materials can be very costly, sometimes complicated shaders have to be evaluated several times per batch. Hence it should be avoided to render the full material for fragments which eventually turn out to be occluded. This can be achieved
+by rendering an initial depth pass (i.e., enabling only depth write to fill the depth
+buffer). Afterwards the geometry is rendered again, this time with full shading. Because the 
+depth buffer is already established, invisible fragments will be discarded before any shading is done calculated.
+
+This approach can be naturally adapted for use with the CHC algorithm. Only an initial depth pass is rendered
+in front-to-back order using the CHC algorithm. The initial pass is sufficient to fill the depth buffer and determine the visible geometry. Then only the visible geometry is rendered again, exploiting the full optimization and material sorting capability of the rendering engine.
+
+If the materials requires several rendering passes, we can use a variant of the depth pass method. We render
+only the first passes using the algorithm (e.g., the solid passes), determining the visibility of the patches, and 
+render all the other passes afterwards. This approach can be used when there are passes which require a special
+kind of sorting to be rendered correctly (e.g., transparent passes, shadow passes).
+
+
+
+\subsection{Batching multiple queries}
+\label{sec:batching}
+
 When occlusion queries are rendered interleaved with geometry, there is always a state change involved. To
 reduce state changes, it is beneficial not to execute one query at a time, but multiple queries at once~\cite{Staneker:2004:EMO}.
 Instead of immediately executing a query for a node when we fetch it from the traversal stack, we add it to the {\em pending queue}. If {\em n} of these queries are accumulated in the queue, we can execute them at once.
-To optain an optimal value for {\em n}, several some heuristics can be applied, e.g., a fraction of the number of queries issued in the last frame. The new pseudo-code of the algorithm is given in Figure~\ref{fig:pseudocode_batching}. 
+To optain an optimal value for {\em n}, several some heuristics can be applied, e.g., a fraction of the number of queries issued in the last frame. The pseudo-code of the algorithm including the batching is given in Figure~\ref{fig:pseudocode_batching}.