[71] | 1 | \newcommand{\tab}{\hspace{2mm}} |
---|
| 2 | \chapter{Overview} |
---|
| 3 | |
---|
| 4 | |
---|
| 5 | The visibility work package aims to develop methods for making use of |
---|
| 6 | restricted visibility in large scenes. The major goal of these methods |
---|
| 7 | is to avoid wasting of the computational power on currently invisible |
---|
| 8 | parts of the scene. To address this goal we develop new methods for |
---|
| 9 | online visibility culling and offline visibility preprocessing. The |
---|
| 10 | online visibility culling is either used to render only visible part |
---|
| 11 | of the scene or to provide queries which determine visible part of the |
---|
| 12 | scene in runtime. Visibility preprocessing provides partitioning of the |
---|
| 13 | view space into view cells and for each view cell it calculates a |
---|
| 14 | potentially visible set. |
---|
| 15 | |
---|
| 16 | |
---|
| 17 | \section{Module Class Hierarchy} |
---|
| 18 | |
---|
| 19 | The visibility work package consist of a module which is integrated |
---|
| 20 | into the game engine and an external module which deals with |
---|
| 21 | preprocessing. One of the goals of the design of the module class |
---|
| 22 | hierarchy has been easy portability of the developed methods to other |
---|
| 23 | game engines. The resulting class structure clearly separates the |
---|
| 24 | actual engine dependent parts from the game engine independent |
---|
| 25 | algorithmic parts. We have used name spaces to separate the engine |
---|
| 26 | dependent parts (name space Ogre) from the engine independent parts |
---|
| 27 | (name space GtpVisibility). The external visibility preprocessing module |
---|
| 28 | defines its own name space (GtpVisibilityPreprocessor). |
---|
| 29 | |
---|
| 30 | An overview of the important classes of the visibility work package and |
---|
| 31 | their integration into the Ogre engine is depicted in |
---|
| 32 | Figure~\ref{fig:classes}. |
---|
| 33 | |
---|
| 34 | \begin{figure}[htb] |
---|
| 35 | \centerline{ |
---|
| 36 | \includegraphics[angle=270,width=1.0\textwidth]{../classes} |
---|
| 37 | } |
---|
| 38 | \caption{Overview of the visibility work packages classes and their integration |
---|
| 39 | into the Ogre game engine.} |
---|
| 40 | \label{fig:classes} |
---|
| 41 | \end{figure} |
---|
| 42 | |
---|
| 43 | The diagram shows that the module integrated into the engine consists |
---|
| 44 | of three main parts (CullingManager, QueryManager, |
---|
| 45 | PreprocessingManager) which are encapsulated in a helper class |
---|
| 46 | (Visibility Manager). The helper class then deals with the |
---|
| 47 | initialization of the contained parts and allows an easy communication |
---|
| 48 | between them. |
---|
| 49 | |
---|
| 50 | \section{Visibility Culling} |
---|
| 51 | |
---|
| 52 | Visibility culling seamlessly integrates into the rendering |
---|
| 53 | loop and eliminates most invisible objects from being send to the |
---|
| 54 | pipeline. Visibility culling is implemented by instances of the CullingManager |
---|
| 55 | class. We will provide several implementations which can be easily |
---|
| 56 | switched at runtime and so the best technique for the particular scene |
---|
| 57 | and scene representation can be selected. Note that the Ogre |
---|
| 58 | integration design allows to exploit all already existing methods for |
---|
| 59 | scene management, such as octree, BSP tree, or plain scene graph. |
---|
| 60 | |
---|
| 61 | |
---|
| 62 | \section{Visibility Queries} |
---|
| 63 | |
---|
| 64 | Visibility queries determine the visible geometry for a given view |
---|
| 65 | point in the scene. Additionally they can also report the visible |
---|
| 66 | scene hierarchy nodes. Visibility queries are implemented by |
---|
| 67 | instances of the QueryManager class. Note that some of these instances |
---|
| 68 | will make use of the preprocessed visibility data through the use of |
---|
| 69 | PreprocessingManager. |
---|
| 70 | |
---|
| 71 | \section{Visibility Preprocessing} |
---|
| 72 | |
---|
| 73 | Visibility preprocessing precalculates visibility for all viewpoints |
---|
| 74 | corresponding to cells of a view space partitioning. The visibility |
---|
| 75 | preprocessor is implemented as a standalone module which imports files |
---|
| 76 | generated by the PreprocessingManager. The results of the visibility |
---|
| 77 | computation will be exported to the file which can then be loaded by |
---|
| 78 | the PreprocessingManager and used inside the engine. |
---|
| 79 | |
---|
| 80 | Apart from the scene definition file the preprocessor will be able |
---|
| 81 | to import the view cell definition. In this case it will assume the |
---|
| 82 | view cells have to be described as meshes satisfying set of |
---|
| 83 | requirements. Alternatively the module can generate view cells by |
---|
| 84 | automatic view space partitioning. |
---|
| 85 | |
---|
| 86 | |
---|
| 87 | %{\textbullet}\tab\textbf{Construction module for tree multiresolution models.} |
---|
| 88 | |
---|