Changeset 71 for trunk/VUT/doc

Timestamp:

04/29/05 18:32:50 (19 years ago)

Author:

mattausch

Message:

 

Location:

trunk/VUT/doc/DummyModules

Files:

• doxyfile_gtp_dummy (modified) (1 diff)
• doxyfile_gtp_dummy_2 (added)
• final/GtpVisibilityDummyModules.pdf (modified) (previous)
• final/GtpVisibilityDummyModules.zip (modified) (previous)
• overview.tex (modified) (4 diffs)

trunk/VUT/doc/DummyModules/doxyfile_gtp_dummy

@@ -26 +26 @@
 INLINE_INHERITED_MEMB  = NO
 FULL_PATH_NAMES        = YES
-STRIP_FROM_PATH        = "/cygdrive/d/gametools/gametools/trunk/VUT/"
+STRIP_FROM_PATH        = "d:/gametools/trunk/VUT/"
 STRIP_FROM_INC_PATH    = 
 SHORT_NAMES            = NO

trunk/VUT/doc/DummyModules/overview.tex

@@ -3 +3 @@
 
 
- The visibility work package aims to develop methods for making use of
+ The visibility workpackage aims to develop methods for making use of
 restricted visibility in large scenes. The major goal of these methods
-is to avoid wasting of the computational power on currently invisible
-parts of the scene. To address this goal we develop new methods for
-online visibility culling and offline visibility preprocessing. The
-online visibility culling is either used to render only visible part
-of the scene or to provide queries which determine visible part of the
-scene in runtime. Visibility preprocessing provides partitioning of the
-view space into view cells and for each view cell it calculates a
+is to avoid wasting computational power on currently invisible parts
+of the scene. To address this goal, we develop new methods for online
+visibility culling and offline visibility preprocessing. The online
+visibility culling is either used to render only visible part of the
+scene or to provide queries which determine visible parts of the scene
+in runtime. Visibility preprocessing provides partitioning of the view
+space into view cells, and for each view cell it calculates a
 potentially visible set.
 
@@ -17 +17 @@
 \section{Module Class Hierarchy}
 
- The visibility work package consist of a module which is integrated
+ The visibility workpackage consists of a module which is integrated
 into the game engine and an external module which deals with
 preprocessing. One of the goals of the design of the module class
 hierarchy has been easy portability of the developed methods to other
 game engines. The resulting class structure clearly separates the
-actual engine dependent parts from the game engine independent
+actual engine-dependent parts from the game engine independent
 algorithmic parts.  We have used name spaces to separate the engine
 dependent parts (name space Ogre) from the engine independent parts
-(name space GtpVisibility). The external visibility preprocessing module
-defines its own name space (GtpVisibilityPreprocessor).
+(name space GtpVisibility). The external visibility preprocessing
+module defines its own name space (GtpVisibilityPreprocessor).
 
  An overview of the important classes of the visibility work package and
@@ -43 +43 @@
 The diagram shows that the module integrated into the engine consists
 of three main parts (CullingManager, QueryManager,
-PreprocessingManager) which are encapsulated in a helper class
+PreprocessingManager), which are encapsulated in a helper class
 (Visibility Manager). The helper class then deals with the
-initialization of the contained parts and allows an easy communication
+initialization of the contained parts and allows easy communication
 between them.
 
 \section{Visibility Culling}
 
-Visibility culling seamlessly integrates into the rendering
-loop and eliminates most invisible objects from being send to the
-pipeline. Visibility culling is implemented by instances of the CullingManager
+Visibility culling seamlessly integrates into the rendering loop and
+eliminates most invisible objects from being sent to the pipeline.
+Visibility culling is implemented by instances of the CullingManager
 class. We will provide several implementations which can be easily
 switched at runtime and so the best technique for the particular scene
@@ -78 +78 @@
 the PreprocessingManager and used inside the engine.
 
- Apart from the scene definition file the preprocessor will be able
+ Apart from the scene definition file, the preprocessor will be able
 to import the view cell definition. In this case it will assume the
-view cells have to be described as meshes satisfying set of
-requirements. Alternatively the module can generate view cells by
+view cells have to be described as meshes satisfying a set of
+requirements. Alternatively, the module can generate view cells by
 automatic view space partitioning.
 
 
 %{\textbullet}\tab\textbf{Construction module for tree multiresolution models.}
-