1 | \newcommand{\tab}{\hspace{2mm}} |
---|
2 | \chapter{Overview} |
---|
3 | |
---|
4 | |
---|
5 | The visibility workpackage 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 computational power on currently invisible parts |
---|
8 | of the scene. To address this goal, we develop new methods for online |
---|
9 | visibility culling and offline visibility preprocessing. The online |
---|
10 | visibility culling is either used to render only visible part of the |
---|
11 | scene or to provide queries which determine visible parts of the scene |
---|
12 | in runtime. Visibility preprocessing provides partitioning of the view |
---|
13 | 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 workpackage consists 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 |
---|
28 | module 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 easy communication |
---|
48 | between them. |
---|
49 | |
---|
50 | \section{Visibility Culling} |
---|
51 | |
---|
52 | Visibility culling seamlessly integrates into the rendering loop and |
---|
53 | eliminates most invisible objects from being sent to the pipeline. |
---|
54 | 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 a 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.} |
---|