![(please configure the [header_logo] section in trac.ini)](/trac/gametools/chrome/site/your_project_logo.png){kind=logo}
Changeset 2177 for GTP/trunk/Lib/Vis/Preprocessing
- Timestamp:
- 03/01/07 10:19:55 (18 years ago)
- Location:
- GTP/trunk/Lib/Vis/Preprocessing/manual
- Files:
-
- 1 added
- 1 edited
-
images/pvs.png (added)
-
integration.tex (modified) (15 diffs)
Legend:
- Unmodified
- Added
- Removed
-
GTP/trunk/Lib/Vis/Preprocessing/manual/integration.tex
r2111 r2177 1 1 \section{Introduction} 2 2 \label{sec:introduction} 3 4 \label{fig:pvs} 5 \end{figure*} 6 \begin{figure*} 7 \centering 8 \includegraphics[width=0.33\textwidth]{images/pvs} 9 \caption{The PVS Computation Module integrated in the Ogre3d engine. 10 A snapshot of Vienna is shown, with the rendered PVS shown in the lower right corner. Note 11 how the PVS closely fits to the geometry actually seen.} 3 12 4 13 This manual provides a guide to apply preprocessed visibility in a particular target engine. It … … 87 96 \end{itemize} 88 97 89 Th isinclude directory must be added to your Solution.98 The following include directory must be added to your Solution. 90 99 91 100 \begin{itemize} … … 97 106 For this purpose we associate the entities of the engine with the PVS 98 107 entries from the visibility solution. 99 For this purpos se the user must implement a small number of interface classes108 For this purpose the user must implement a small number of interface classes 100 109 of the preprocessor. 101 110 We demonstrate this on a small example, which shows how to access preprocessed visibility … … 118 127 119 128 This piece of code is loading the view cells into the engine. 120 Let's analyze this code. There are t woconstructs that need explanation, the121 BoundingBoxConverter and the ObjectContainer, and the view cells manager.129 Let's analyze this code. There are three constructs that need explanation, the 130 BoundingBoxConverter and the ObjectContainer, and the ViewCellsManager. 122 131 123 132 \paragraph{BoundingBoxConverter} … … 139 148 \label{sec:ObjectContainer} 140 149 141 The object container is basiclya vector of {\em Intersectable *}. It contains all150 An object container is a vector of {\em Intersectable *}. It contains all 142 151 static entities of the scene. 143 152 A PVS entry must be derived from this class. To get access to the PVS of a view cell, … … 148 157 \label{sec:Loading} 149 158 150 The loading function returns a view cells .159 The loading function returns a view cells manager. 151 160 152 161 \begin{verbatim} 153 162 static ViewCellsManager *LoadViewCells(const string &filename, 154 ObjectContainer *objects, 155 156 163 ObjectContainer *objects, 164 bool finalizeViewCells = false, 165 BoundingBoxConverter *bconverter = NULL); 157 166 \end{verbatim} 158 167 … … 167 176 168 177 In this section we show an example implementation for the interface classes in Ogre3D. 169 170 \subsection{Intersectable} 178 First for the object class of the preprocessor, {\em Intersectable}, then for the converter class 179 {\em BoundingBoxConverter }. 180 181 \subsection{Class Intersectable} 171 182 \label{sec:intersectable} 172 183 … … 204 215 205 216 206 \subsection{ Bounding BoxConverter}217 \subsection{Class BoundingBoxConverter} 207 218 \label{sec:Converter} 208 219 209 This is maybe the most tricky part of the integration. The bounding box converter210 is necessary because we have to associate the objects of the visibility solution with 211 the objects from the engine without having unique ids. This is the interface 212 of the{\em BoundingBoxConverter }.220 This is the most involved part of the integration, but it shouldn't be too difficult, either. 221 A bounding box converter is necessary because we have to associate the objects of the 222 visibility solution with the objects from the engine without having unique ids. This is the 223 interface of the class {\em BoundingBoxConverter }. 213 224 214 225 \begin{verbatim} … … 237 248 \end{verbatim} 238 249 239 We give an example of implementation of a Bounding Box Converter 240 for Ogre3D rendering engine. It is templated in order to works with any Ogre SceneManager. 250 We give an example of implementation of a {\em BoundingBoxConverter } 251 for the Ogre3D rendering engine. It is templated in order to works with any {\em SceneManager } in Ogre3D 252 (If you are not familiar with the {\em SceneManager} concept in Ogre3D, it does not matter). 241 253 Again, the implementation of this interface must be adapted for the requirements 242 254 of the particular engine. … … 272 284 273 285 This class is inherited from {\em BoundingBoxConverter}. 274 {\em BoundingBoxConverters}has only one virtual function {\em IdentifyObjects} that must286 This class has only one virtual function {\em IdentifyObjects} that must 275 287 be implemented. Additionally we use a helper function {\em FindIntersectingObjects} that 276 288 is responsible for locating the corresponding objects in the scene. Let's now have a look … … 306 318 307 319 The function just loops over the bounding boxes of the PVS entries and finds the entities that 308 are intersected by the bouding boxes. Let's have a look now at the function 309 {\em FindIntersectingObjects}, which is searching the intersections for each individual box. 320 are intersected by the bounding boxes. Additionally we introduce a new class, the { \em OgreTypeConverter }. 321 This class is just responsible for converting basic classes like {\em Vector3 } or { \em AxisAlignedBox } 322 betwen Ogre3D types and Preprocessor types. Now we revisit the function 323 {\em FindIntersectingObjects}, which searches the intersections for each individual box. 310 324 311 325 \begin{verbatim} … … 354 368 355 369 Note that the implementation of this function is maybe the one that differs the most 356 for another engine, as it is highly depending on the particular engine design.370 for other engines, as it is highly depending on the particular engine design. 357 371 For the Ogre3D implementation, we use a two stage approach. First we find the 358 372 intersecting scene nodes. We apply a search function that is optimized for this engine. … … 360 374 The engine is responsible to provide a function for fast geometric search in the scene, 361 375 in order to quickly find the objects intersecting the bounding box of a PVS entry. 362 A spatial data structure like Octree or Kdtree is very useful in this regard.376 A spatial data structure like octree or kd-tree is very useful in this regard. 363 377 Second we traverse through the list of entities attached to the scene node. The intersection 364 378 test is then applied for each indiviual bounding box. … … 367 381 \label{sec:usage} 368 382 369 By nowthe view cells should be accessible within the target engine. The383 At this point the view cells should be accessible within the target engine. The 370 384 view cells manager provides the necessary functionality to handle the view cells. 371 385 In order to query the current view cell, use the following function of the … … 376 390 \end{verbatim} 377 391 378 In your engine, the function will called like this.392 In the target engine, the function is envoked like this. 379 393 380 394 \begin{verbatim}
Note: See TracChangeset
for help on using the changeset viewer.
