Changeset 252 for trunk/VUT


Ignore:
Timestamp:
08/26/05 14:56:09 (19 years ago)
Author:
mattausch
Message:

added ogre image

Location:
trunk/VUT/doc/SciReport
Files:
3 added
1 edited

Legend:

Unmodified
Added
Removed
  • trunk/VUT/doc/SciReport/online.tex

    r251 r252  
    4242connectivity, occlusion by few closest depth layers). 
    4343 
     44\begin{figure}%[htb] 
     45  %\centerline 
     46        \centering \footnotesize 
     47        \begin{tabular}{c} 
     48        \includegraphics[width=0.5\textwidth, draft=\DRAFTFIGS]{images/ogre_terrain} \\ 
     49        %\hline  
     50        \includegraphics[width=0.25\textwidth, draft=\DRAFTFIGS]{images/vis_viewfrustum} \hfill \includegraphics[width=0.25\textwidth, draft=\DRAFTFIGS]{images/vis_chc} \\ 
     51        \end{tabular} 
     52\label{tab:averages} 
     53  \caption{Top row: The rendered scene. Bottom row: The visualizion of the rendering overdraw. 
     54    Using view frustum culling (left image) vs. occlusion queries (right image). 
     55    The yellow boxes show the actually rendered scene objects. The 
     56        red boxes depict the view frustum culled hierarchy nodes, the blue boxes depict the 
     57        occlusion query culled hierarchy nodes.} 
     58  \label{fig:online_culling_example} 
     59\end{figure} 
     60 
    4461Recent graphics hardware natively supports an \emph{occlusion query} 
    4562to detect the visibility of an object against the current contents of the 
     
    5875existing real-time rendering packages on architectures supporting the 
    5976underlying occlusion query. 
    60  
     77In figure~\ref{fig:online_culling_example}, the same scene (top row) is rendered using view frustum 
     78culling (visualization in the bottom left image) versus online culling using occlusion queries (visualization  
     79in the bottom right image). We can clearly see the large overdraw that happens for view frustum culling. 
    6180%Using spatial and assuming temporal coherence 
    6281 
     
    661680wait till the result of the query becomes available. 
    662681 
    663 \subsection{Initial depth pass} 
    664 \label{sec:initial} 
    665  
    666 To achieve maximal performance on modern GPU's, one has to take care of a number of issues. 
    667 First, it is very important to reduce material switching. Thus modern rendering engines sort the  
    668 objects (or patches) by materials in order to eliminate the material switching as good as possible.  
    669  
    670 Next, materials can be very costly, sometimes complicated shaders have to be evaluated several times per batch. Hence it should be 
    671 avoided to render the full material for fragments which eventually turn out to be occluded. This can be achieved 
    672 by rendering an initial depth pass (i.e., enabling only depth write to fill the depth 
    673 buffer). Afterwards the geometry is rendered again, this time with full shading. Because the  
    674 depth buffer is already established, invisible fragments will be discarded before any shading is done calculated. 
    675  
    676 This approach can be naturally adapted for use with the CHC algorithm. Only an initial depth pass is rendered 
    677 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. 
    678  
    679 \subsection{Batching multiple queries} 
    680682\begin{figure}%[htb] 
    681683{\footnotesize 
     
    685687  \label{fig:pseudocode_batching} 
    686688\end{figure} 
     689 
     690\subsection{Initial depth pass} 
     691\label{sec:initial} 
     692 
     693To achieve maximal performance on modern GPU's, one has to take care of a number of issues. 
     694First, it is very important to reduce material switching. Thus modern rendering engines sort the  
     695objects (or patches) by materials in order to eliminate the material switching as good as possible.  
     696 
     697Next, 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 
     698by rendering an initial depth pass (i.e., enabling only depth write to fill the depth 
     699buffer). Afterwards the geometry is rendered again, this time with full shading. Because the  
     700depth buffer is already established, invisible fragments will be discarded before any shading is done calculated. 
     701 
     702This approach can be naturally adapted for use with the CHC algorithm. Only an initial depth pass is rendered 
     703in 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. 
     704 
     705If the materials requires several rendering passes, we can use a variant of the depth pass method. We render 
     706only the first passes using the algorithm (e.g., the solid passes), determining the visibility of the patches, and  
     707render all the other passes afterwards. This approach can be used when there are passes which require a special 
     708kind of sorting to be rendered correctly (e.g., transparent passes, shadow passes). 
     709 
     710 
     711 
     712\subsection{Batching multiple queries} 
     713\label{sec:batching} 
     714 
    687715When occlusion queries are rendered interleaved with geometry, there is always a state change involved. To 
    688716reduce state changes, it is beneficial not to execute one query at a time, but multiple queries at once~\cite{Staneker:2004:EMO}. 
    689717Instead 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. 
    690 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}.  
     718To 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}.  
    691719 
    692720 
Note: See TracChangeset for help on using the changeset viewer.