Index: GTP/trunk/Lib/Vis/OnlineCullingCHC/OGRE/include/OgreBoundingBoxConverter.h
===================================================================
--- GTP/trunk/Lib/Vis/OnlineCullingCHC/OGRE/include/OgreBoundingBoxConverter.h	(revision 2097)
+++ GTP/trunk/Lib/Vis/OnlineCullingCHC/OGRE/include/OgreBoundingBoxConverter.h	(revision 2111)
@@ -8,5 +8,4 @@
 #include "Containers.h"
 #include "IntersectableWrapper.h"
-//#include "KdTree.h"
 
 
@@ -14,4 +13,5 @@
 
 #define USE_KD_PVS 1
+
 class Entity;
 class OctreeSceneManager;
Index: GTP/trunk/Lib/Vis/OnlineCullingCHC/OGRE/src/Plugin_VisibilitySceneManager.vcproj
===================================================================
--- GTP/trunk/Lib/Vis/OnlineCullingCHC/OGRE/src/Plugin_VisibilitySceneManager.vcproj	(revision 2100)
+++ GTP/trunk/Lib/Vis/OnlineCullingCHC/OGRE/src/Plugin_VisibilitySceneManager.vcproj	(revision 2111)
@@ -638,7 +638,4 @@
 			Filter="cpp;c;cxx;def;odl;idl;hpj;bat;asm">
 			<File
-				RelativePath="..\src\OgreBoundingBoxConverter.cpp">
-			</File>
-			<File
 				RelativePath="..\src\OgreMeshInstance.cpp">
 			</File>
Index: GTP/trunk/Lib/Vis/OnlineCullingCHC/OGRE/src/OgreBoundingBoxConverter.cpp
===================================================================
--- GTP/trunk/Lib/Vis/OnlineCullingCHC/OGRE/src/OgreBoundingBoxConverter.cpp	(revision 1595)
+++ 	(revision )
@@ -1,14 +1,0 @@
-#include "OgreBoundingBoxConverter.h"
-#include "OgreTypeConverter.h"
-#include "OgreMeshInstance.h"
-#include "OgreOctreeSceneManager.h"
-#include "OgreKdTreeSceneManager.h"
-#include <OgreLogManager.h>
-
-
-namespace Ogre
-{
-
-
-
-}
Index: GTP/trunk/Lib/Vis/OnlineCullingCHC/ObjReader/include/ObjManualMeshLoader.h
===================================================================
--- GTP/trunk/Lib/Vis/OnlineCullingCHC/ObjReader/include/ObjManualMeshLoader.h	(revision 2110)
+++ GTP/trunk/Lib/Vis/OnlineCullingCHC/ObjReader/include/ObjManualMeshLoader.h	(revision 2111)
@@ -1,4 +1,4 @@
-#ifndef __IVManualMeshLoader_H__
-#define __IVManualMeshLoader_H__
+#ifndef __ObjManualMeshLoader_H__
+#define __ObjManualMeshLoader_H__
 
 
@@ -7,10 +7,10 @@
 
 
-class __declspec(dllexport) IVManualMeshLoader: public Ogre::ManualResourceLoader
+class __declspec(dllexport) ObjManualMeshLoader: public Ogre::ManualResourceLoader
 {
 	public:
-		IVManualMeshLoader();
-		IVManualMeshLoader(IVMeshData *mData);
-		~IVManualMeshLoader(); 
+		ObjManualMeshLoader();
+		ObjManualMeshLoader(ObjMeshData *mData);
+		~ObjManualMeshLoader(); 
 
 		void loadResource(Ogre::Resource *resource);
@@ -18,5 +18,5 @@
 		Ogre::AxisAlignedBox *getBoundingBox();
 	private:
-		IVMeshData *data;
+		ObjMeshData *data;
 
 };
Index: GTP/trunk/Lib/Vis/OnlineCullingCHC/ObjReader/include/ObjReader.h
===================================================================
--- GTP/trunk/Lib/Vis/OnlineCullingCHC/ObjReader/include/ObjReader.h	(revision 2110)
+++ GTP/trunk/Lib/Vis/OnlineCullingCHC/ObjReader/include/ObjReader.h	(revision 2111)
@@ -1,131 +1,38 @@
-#ifndef __mIVReader_H__
-#define __mIVReader_H__
+#ifndef __ObjReader_H__
+#define __ObjReader_H__
+
+//#include <stdlib>
+#include <string>
+#include <vector>
+#include <Ogre.h>
+/*#include "ObjNode.h"
+#include "ObjMeshData.h"
+#include "ObjManualMeshLoader.h"
+*/
 
 
-#include "ObjNode.h"
-#include "ObjMeshData.h"
-#include "ObjManualMeshLoader.h"
-#include "Ogre.h"
+namespace GtpVisibilityPreprocessor {
 
-#define COMMENTCHAR '#'
-#define BLOCKSIZE 150
-#define BUFFERSIZE 256
+struct Triangle3;
 
+}
 
-static const int validIVHeaderCnt = 2;
+typedef std::vector<GtpVisibilityPreprocessor::Triangle3 *> TriangleContainer;
 
-static const char *validIVHeader[2] = {
-    { "#Inventor V2.1 ascii\n" },
-	{ "#VRML V1.0 ascii\n" },
+class __declspec(dllexport) ObjReader
+{
+public:
+	ObjReader();
+	~ObjReader();
+
+	bool LoadFile(const std::string &filename,
+				  TriangleContainer &triangles) const;
+	
+	const std::vector<Ogre::Entity *> &GetObjects() const;
+
+protected:
+
+	std::vector<Ogre::Entity *> mObjects;
 };
 
-
-enum IVTokenType
-{
-	IV_TOKEN_INVALID = -1,
-	IV_TOKEN_STRING = 0,
-	IV_TOKEN_INT = 1,
-	IV_TOKEN_REAL = 2,
-	IV_TOKEN_BRACEOPEN = 3,				// {
-	IV_TOKEN_BRACECLOSE = 4,			// }
-	IV_TOKEN_BRACKETOPEN = 5,			// [
-	IV_TOKEN_BRACKETCLOSE = 6,			// ]
-	IV_TOKEN_PARENTHESISOPEN = 7,		// (
-	IV_TOKEN_PARENTHESISCLOSE = 8,		// )
-	IV_TOKEN_DEF = 9,					// DEF
-	IV_TOKEN_USE = 10,					// USE
-};
-
-class __declspec(dllexport) IVMeshListNode
-{
-	public:
-		IVMeshListNode(std::string name, IVManualMeshLoader *loader);
-		~IVMeshListNode();
-
-		void attachNewNode(std::string name, IVManualMeshLoader *loader);
-
-		IVManualMeshLoader *getManualMeshLoader(std::string name);
-
-		IVMeshListNode *next;
-
-	private:
-		std::string name;
-		IVManualMeshLoader *loader;
-};
-
-class __declspec(dllexport) IVDefListNode
-{
-	public:
-		IVDefListNode(std::string name, IVNode *node);
-		~IVDefListNode();
-
-		void attachNewNode(std::string name, IVNode *node);
-
-		IVNode *getDef(std::string name);
-
-		IVDefListNode *next;
-
-	private:
-		std::string name;
-		IVNode *node;
-
-};
-
-class __declspec(dllexport) IVReader
-{
-	public:
-		IVReader();
-		~IVReader();
-
-		void setLog(Ogre::Log *IVLog = NULL);
-
-		bool loadFile(const char* filename);
-		void print();
-//		IVNode *getNode(const char* name);
-
-
-		void buildTree(Ogre::SceneManager *sceneMgr, Ogre::SceneNode *sceneNodeRoot);
-
-		void collapse();
-
-		static std::string intToStr(int num);
-		static std::string realToStr(Ogre::Real num);
-		
-		static Ogre::Log *IVLog;
-
-	private:
-		bool checkHeader(const char *string);
-		char buf[BUFFERSIZE];
-		int bufOffset;
-		bool getNextElement(char *token, IVTokenType *type);
-		void classify(char *token, IVTokenType *type);
-
-		bool isSpace(char c);
-		bool isNewline(char c);
-		bool eof;
-		bool isDigit(char c);
-		bool isHexDigit(char c);
-
-		IVNode *root;
-		FILE* infile;
-
-		static IVMeshListNode *meshList;
-		static void addMeshToList(std::string name, IVManualMeshLoader *loader);
-		
-		static int instanceCnt;
-
-		int treeCnt, nodeCnt, matCnt;
-		char *fileName;
-
-		Ogre::Entity *createEntity(Ogre::SceneManager* sceneMgr, std::string name, IVMeshData *mData, Ogre::Vector3 *translation = NULL);
-
-		void buildTree(Ogre::SceneManager *sceneMgr, Ogre::SceneNode *sceneNodeRoot, IVNode *mIVReaderoot, IVMeshData *mData = NULL, Ogre::Material *material = NULL);
-
-		IVDefListNode *defList;
-		void addDefToList(std::string name, IVNode *node);
-
-
-};
-
-
 #endif
Index: GTP/trunk/Lib/Vis/OnlineCullingCHC/ObjReader/include/ObjNode.h
===================================================================
--- GTP/trunk/Lib/Vis/OnlineCullingCHC/ObjReader/include/ObjNode.h	(revision 2109)
+++ GTP/trunk/Lib/Vis/OnlineCullingCHC/ObjReader/include/ObjNode.h	(revision 2111)
@@ -1,4 +1,4 @@
-#ifndef __IVNode_H__
-#define __IVNode_H__
+#ifndef __ObjNode_H__
+#define __ObjNode_H__
 
 
@@ -6,5 +6,5 @@
 #include <Ogre.h>
 
-enum IVType
+enum ObjType
 {
 	IV_INVALID = -1,
@@ -15,44 +15,44 @@
 
 
-class IVField
+class ObjField
 {
 public:
-	IVField();
-	~IVField();
+	ObjField();
+	~ObjField();
 
 	char *name;
 	void *value;
-	IVType typ;
+	ObjType typ;
 	int cnt;
-	IVField *next;
+	ObjField *next;
 };
 
-class __declspec(dllexport) IVNode
+class __declspec(dllexport) ObjNode
 {
 	public:
-		IVNode();
-		IVNode(const char *s);
-		~IVNode();
+		ObjNode();
+		ObjNode(const char *s);
+		~ObjNode();
 
 		void print(int ident=0);
-		void attachNode(IVNode *child);
+		void attachNode(ObjNode *child);
 		void addField(const char *name, char *value);
-		void addField(const char *name, void *value, int cnt, IVType typ);
+		void addField(const char *name, void *value, int cnt, ObjType typ);
 
-		IVNode *getParent() { return parent; }
+		ObjNode *getParent() { return parent; }
 		char *getName() { return name; }
-		IVNode *getNodeRecursive(const char *name);
-		IVNode *getNextChildNode(bool reset = false);
-		IVField *getField(const char *name);
-		void *getField(const char *name, IVType *typ, int *cnt);
+		ObjNode *getNodeRecursive(const char *name);
+		ObjNode *getNextChildNode(bool reset = false);
+		ObjField *getField(const char *name);
+		void *getField(const char *name, ObjType *typ, int *cnt);
 
 	private:
 		char *name;
-		IVField *fields;
-		IVNode *parent;
-		IVNode *children;
-		IVNode *next;
+		ObjField *fields;
+		ObjNode *parent;
+		ObjNode *children;
+		ObjNode *next;
 
-		IVNode *actual;
+		ObjNode *actual;
 };
 
Index: GTP/trunk/Lib/Vis/OnlineCullingCHC/ObjReader/include/ObjMeshData.h
===================================================================
--- GTP/trunk/Lib/Vis/OnlineCullingCHC/ObjReader/include/ObjMeshData.h	(revision 2109)
+++ GTP/trunk/Lib/Vis/OnlineCullingCHC/ObjReader/include/ObjMeshData.h	(revision 2111)
@@ -1,9 +1,9 @@
-#ifndef __IVMeshData_H__
-#define __IVMeshData_H__
+#ifndef __ObjMeshData_H__
+#define __ObjMeshData_H__
 
 
 #include <Ogre.h>
 
-enum mIVReaderenderOperationType
+enum ObjReaderOpType
 {
 	IV_ROT_INVALID = -1,
@@ -13,11 +13,11 @@
 };
 
-class __declspec(dllexport) IVMeshData
+class __declspec(dllexport) ObjMeshData
 {
 	public:	
-		IVMeshData();
-		~IVMeshData();
+		ObjMeshData();
+		~ObjMeshData();
 
-		IVMeshData *expand();
+		ObjMeshData *expand();
 
 		void collapse();
@@ -25,5 +25,5 @@
 		Ogre::Real *vertices, *normals, *texCoords, *indices, *normalIndices, *texCoordIndices;
 		int vcnt, ncnt, tcnt, icnt, nicnt, ticnt;
-		mIVReaderenderOperationType roType;
+		ObjReaderOpType roType;
 		Ogre::AxisAlignedBox *boundingBox;
 
Index: GTP/trunk/Lib/Vis/OnlineCullingCHC/ObjReader/src/ObjReader.vcproj
===================================================================
--- GTP/trunk/Lib/Vis/OnlineCullingCHC/ObjReader/src/ObjReader.vcproj	(revision 2110)
+++ GTP/trunk/Lib/Vis/OnlineCullingCHC/ObjReader/src/ObjReader.vcproj	(revision 2111)
@@ -72,5 +72,5 @@
 			<Tool
 				Name="VCCLCompilerTool"
-				AdditionalIncludeDirectories="&quot;$(OGRE_PATH)\Dependencies\include\CEGUI&quot;;&quot;$(OGRE_PATH)\Samples\Common\CEGUIRenderer\include&quot;;&quot;$(OGRE_PATH)\OgreMain\include&quot;;&quot;$(OGRE_PATH)\Dependencies\include&quot;;&quot;$(OGRE_PATH)\Samples\Common\include&quot;;..\include"
+				AdditionalIncludeDirectories="&quot;$(OGRE_PATH)\OgreMain\include&quot;;&quot;$(OGRE_PATH)\Dependencies\include&quot;;&quot;$(OGRE_PATH)\Samples\Common\include&quot;;..\include;..\..\..\Preprocessing\src"
 				PreprocessorDefinitions="WIN32;NDEBUG;_WINDOWS;_USRDLL;OBJREADER_EXPORTS;GTP_VISIBILITY_MODIFIED_OGRE;GAMETOOLS_ILLUMINATION_MODULE"
 				RuntimeLibrary="2"
@@ -83,8 +83,8 @@
 			<Tool
 				Name="VCLinkerTool"
-				AdditionalDependencies="OgreMain.lib CEGUIBase.lib OgreGUIRenderer.lib"
-				OutputFile="$(OutDir)/ObjReader.dll"
-				LinkIncremental="1"
-				AdditionalLibraryDirectories="&quot;$(OGRE_PATH)\OgreMain\lib\$(ConfigurationName)&quot;;&quot;$(OGRE_PATH)\Samples\Common\CEGUIRenderer\lib&quot;;&quot;..\..\GtpVisibility\lib\$(ConfigurationName)&quot;;&quot;..\..\lib\$(ConfigurationName)&quot;;&quot;..\lib\$(ConfigurationName)&quot;;&quot;$(OGRE_PATH)\Dependencies\lib\$(ConfigurationName)&quot;"
+				AdditionalDependencies="OgreMain.lib zdll.lib zziplib.lib Preprocessor.lib xerces-c_2.lib"
+				OutputFile="$(OutDir)/ObjReader.dll"
+				LinkIncremental="1"
+				AdditionalLibraryDirectories="&quot;$(OGRE_PATH)\OgreMain\lib\$(ConfigurationName)&quot;;&quot;$(OGRE_PATH)\Dependencies\lib\$(ConfigurationName)&quot;;&quot;..\..\lib\$(ConfigurationName)&quot;;&quot;..\lib\$(ConfigurationName)&quot;;&quot;..\..\..\Preprocessing\lib\$(ConfigurationName)&quot;;..\..\..\..\..\..\..\NonGTP\Xerces\xercesc\lib"
 				GenerateDebugInformation="FALSE"
 				SubSystem="2"
@@ -339,13 +339,4 @@
 			UniqueIdentifier="{4FC737F1-C7A5-4376-A066-2A32D752A2FF}">
 			<File
-				RelativePath="..\src\ObjManualMeshLoader.cpp">
-			</File>
-			<File
-				RelativePath="..\src\ObjMeshData.cpp">
-			</File>
-			<File
-				RelativePath="..\src\ObjNode.cpp">
-			</File>
-			<File
 				RelativePath="..\src\ObjReader.cpp">
 			</File>
@@ -356,13 +347,4 @@
 			UniqueIdentifier="{93995380-89BD-4b04-88EB-625FBE52EBFB}">
 			<File
-				RelativePath="..\include\ObjManualMeshLoader.h">
-			</File>
-			<File
-				RelativePath="..\include\ObjMeshData.h">
-			</File>
-			<File
-				RelativePath="..\include\ObjNode.h">
-			</File>
-			<File
 				RelativePath="..\include\ObjReader.h">
 			</File>
Index: GTP/trunk/Lib/Vis/OnlineCullingCHC/ObjReader/src/ObjNode.cpp
===================================================================
--- GTP/trunk/Lib/Vis/OnlineCullingCHC/ObjReader/src/ObjNode.cpp	(revision 2110)
+++ GTP/trunk/Lib/Vis/OnlineCullingCHC/ObjReader/src/ObjNode.cpp	(revision 2111)
@@ -2,5 +2,5 @@
 #include "ObjReader.h"
 
-IVField::IVField()
+ObjField::ObjField()
 {
 	next = NULL;
@@ -9,5 +9,5 @@
 
 
-IVField::~IVField()
+ObjField::~ObjField()
 {
 	if (value != NULL) free(value);
@@ -17,5 +17,5 @@
 
 
-IVNode::IVNode()
+ObjNode::ObjNode()
 {
 	parent = children = next = actual = NULL; 
@@ -25,5 +25,5 @@
 
 
-IVNode::IVNode(const char *s)
+ObjNode::ObjNode(const char *s)
 {
 	name = new char[strlen(s)+1];
@@ -33,10 +33,10 @@
 }
 
-IVNode::~IVNode()
+ObjNode::~ObjNode()
 {
 	if (name != NULL) delete[] name;
 	if (fields != NULL) 
 	{
-		IVField *help = fields, *delme = NULL;
+		ObjField *help = fields, *delme = NULL;
 		while (help->next != NULL)
 		{
@@ -47,5 +47,5 @@
 	if (children != NULL) 
 	{
-		IVNode *help = children, *delme = NULL;
+		ObjNode *help = children, *delme = NULL;
 		while (help->next != NULL)
 		{
@@ -60,10 +60,10 @@
 
 
-void IVNode::attachNode(IVNode *child)
+void ObjNode::attachNode(ObjNode *child)
 {
 	if (children == NULL) children = child;
 	else 
 	{
-		IVNode *help = children;
+		ObjNode *help = children;
 		while (help->next != NULL) help = help->next;
 		help->next = child;
@@ -73,5 +73,5 @@
 
 
-void IVNode::print(int ident)
+void ObjNode::print(int ident)
 {
 	if (IVReader::IVLog != NULL)
@@ -85,5 +85,5 @@
 		IVReader::IVLog->logMessage(msg);
 
-		IVField *help = fields;
+		ObjField *help = fields;
 		while (help != NULL)
 		{
@@ -128,7 +128,7 @@
 }
 
-void IVNode::addField(const char *name, void *value, int cnt, IVType typ)
-{
-	IVField *newone = new IVField();
+void ObjNode::addField(const char *name, void *value, int cnt, ObjType typ)
+{
+	ObjField *newone = new ObjField();
 	newone->name = new char[strlen(name)+1];
 	strcpy(newone->name, name);
@@ -153,5 +153,5 @@
 	else
 	{
-		IVField *help = fields;
+		ObjField *help = fields;
 		while (help->next != NULL) help = help->next;
 		help->next = newone;
@@ -160,5 +160,5 @@
 
 
-void IVNode::addField(const char *name, char *value)
+void ObjNode::addField(const char *name, char *value)
 {
 	addField(name, value, 1, IV_STRING);
@@ -166,10 +166,10 @@
 
 
-IVNode *IVNode::getNodeRecursive(const char *name)
+ObjNode *ObjNode::getNodeRecursive(const char *name)
 {
 	if (strcmp(name, this->name) == 0) return this;
 	if (this->children != NULL)
 	{
-		IVNode *help = this->children->getNodeRecursive(name);
+		ObjNode *help = this->children->getNodeRecursive(name);
 		if (help != NULL) return help;
 	}
@@ -178,5 +178,5 @@
 
 
-IVNode *IVNode::getNextChildNode(bool reset)
+ObjNode *ObjNode::getNextChildNode(bool reset)
 {
 	if (reset) actual = this->children;
@@ -186,7 +186,7 @@
 
 
-IVField *IVNode::getField(const char *name)
-{
-	IVField *help = fields;
+ObjField *ObjNode::getField(const char *name)
+{
+	ObjField *help = fields;
 	while (help != NULL)
 	{
@@ -197,7 +197,7 @@
 }
 
-void *IVNode::getField(const char *name, IVType *typ, int *cnt)
-{
-	IVField *help = fields;
+void *ObjNode::getField(const char *name, ObjType *typ, int *cnt)
+{
+	ObjField *help = fields;
 	while (help != NULL)
 	{
Index: GTP/trunk/Lib/Vis/OnlineCullingCHC/ObjReader/src/ObjMeshData.cpp
===================================================================
--- GTP/trunk/Lib/Vis/OnlineCullingCHC/ObjReader/src/ObjMeshData.cpp	(revision 2110)
+++ GTP/trunk/Lib/Vis/OnlineCullingCHC/ObjReader/src/ObjMeshData.cpp	(revision 2111)
@@ -3,5 +3,5 @@
 
 
-IVMeshData::IVMeshData()
+ObjMeshData::ObjMeshData()
 { 
 	vertices = normals = texCoords = indices = normalIndices = texCoordIndices = NULL; 
@@ -11,9 +11,9 @@
 }
 
-IVMeshData::~IVMeshData()
+ObjMeshData::~ObjMeshData()
 { 
 }
 
-void IVMeshData::collapse()
+void ObjMeshData::collapse()
 {
 	if (indices != NULL)	delete [] indices;
@@ -28,5 +28,5 @@
 }
 
-int IVMeshData::getSeparatorCnt(Ogre::Real *data, int end)
+int ObjMeshData::getSeparatorCnt(Ogre::Real *data, int end)
 {
 	int cnt = 0;
@@ -35,5 +35,5 @@
 }
 
-Ogre::AxisAlignedBox *IVMeshData::calcBoundingBox()
+Ogre::AxisAlignedBox *ObjMeshData::calcBoundingBox()
 {
 	if ((vertices == NULL) || (vcnt <=0)) 
@@ -58,5 +58,5 @@
 
 
-Ogre::Real *IVMeshData::expandTriangleStripIndices(Ogre::Real *indices, int icnt, int *icntOut)
+Ogre::Real *ObjMeshData::expandTriangleStripIndices(Ogre::Real *indices, int icnt, int *icntOut)
 {
 	if (indices[icnt-1] >= 0.0)
@@ -94,5 +94,6 @@
 }	
 
-int IVMeshData::getNextFaceSize(int start)
+
+int ObjMeshData::getNextFaceSize(int start)
 {
 	for (int i=start; i < icnt; i++) 
@@ -103,5 +104,6 @@
 }
 
-Ogre::Real *IVMeshData::expandFaceSetIndices(Ogre::Real *indices, int icnt, int *icntOut)
+
+Ogre::Real *ObjMeshData::expandFaceSetIndices(Ogre::Real *indices, int icnt, int *icntOut)
 {
 	if (indices[icnt-1] >= 0.0)
@@ -126,9 +128,9 @@
 }
 
-IVMeshData *IVMeshData::expand()
+ObjMeshData *ObjMeshData::expand()
 {
 	using namespace Ogre;
 
-	IVMeshData *mDataOut = new IVMeshData();
+	ObjMeshData *mDataOut = new ObjMeshData();
 
 	mDataOut->boundingBox = calcBoundingBox();
Index: GTP/trunk/Lib/Vis/OnlineCullingCHC/ObjReader/src/ObjManualMeshLoader.cpp
===================================================================
--- GTP/trunk/Lib/Vis/OnlineCullingCHC/ObjReader/src/ObjManualMeshLoader.cpp	(revision 2110)
+++ GTP/trunk/Lib/Vis/OnlineCullingCHC/ObjReader/src/ObjManualMeshLoader.cpp	(revision 2111)
@@ -2,5 +2,5 @@
 #include "ObjReader.h"
 
-IVManualMeshLoader::IVManualMeshLoader()
+ObjManualMeshLoader::ObjManualMeshLoader()
 {
 	data = NULL;
@@ -8,46 +8,12 @@
 
 
-IVManualMeshLoader::IVManualMeshLoader(IVMeshData *mData)
+ObjManualMeshLoader::ObjManualMeshLoader(ObjMeshData *mData):
+data(mData)
 {
-	data = mData;
-/*	data = new IVMeshData();
-	if ((mData->indices != NULL) && (mData->icnt > 0))
-	{
-		data->icnt = mData->icnt;
-		data->indices = new Ogre::Real[mData->icnt];
-		memcpy(data->indices, mData->indices, mData->icnt*sizeof(Ogre::Real));
-	}
-	if ((mData->vertices != NULL) && (mData->vcnt > 0))
-	{
-		data->vcnt = mData->vcnt;
-		data->vertices = new Ogre::Real[mData->vcnt];
-		memcpy(data->vertices, mData->vertices, mData->vcnt*sizeof(Ogre::Real));
-	}
-	if ((mData->normals != NULL) && (mData->vcnt > 0))
-	{
-		data->ncnt = mData->ncnt;
-		data->normals = new Ogre::Real[mData->ncnt];
-		memcpy(data->normals, mData->normals, mData->ncnt*sizeof(Ogre::Real));
-	}
-	if ((mData->texCoords != NULL) && (mData->tcnt > 0))
-	{
-		data->tcnt = mData->tcnt;
-		data->texCoords = new Ogre::Real[mData->tcnt];
-		memcpy(data->texCoords, mData->texCoords, mData->tcnt*sizeof(Ogre::Real));
-	}
-	*/
 }
 
-IVManualMeshLoader::~IVManualMeshLoader()
+
+ObjManualMeshLoader::~ObjManualMeshLoader()
 {
-/*	if (data != NULL)
-	{
-		if (data->vertices != NULL)		delete [] data->vertices;
-		if (data->normals != NULL)		delete [] data->normals;
-		if (data->texCoords != NULL)	delete [] data->texCoords;
-		if (data->indices != NULL)		delete [] data->indices;
-		delete data;
-	}
-	*/
 	if (data != NULL)
 	{
@@ -58,5 +24,5 @@
 
 
-Ogre::AxisAlignedBox *IVManualMeshLoader::getBoundingBox()
+Ogre::AxisAlignedBox *ObjManualMeshLoader::getBoundingBox()
 {
 	return data->boundingBox;
@@ -64,5 +30,5 @@
 
 
-void IVManualMeshLoader::loadResource(Ogre::Resource *resource)
+void ObjManualMeshLoader::loadResource(Ogre::Resource *resource)
 {
 	using namespace Ogre;
Index: GTP/trunk/Lib/Vis/OnlineCullingCHC/ObjReader/src/ObjReader.cpp
===================================================================
--- GTP/trunk/Lib/Vis/OnlineCullingCHC/ObjReader/src/ObjReader.cpp	(revision 2110)
+++ GTP/trunk/Lib/Vis/OnlineCullingCHC/ObjReader/src/ObjReader.cpp	(revision 2111)
@@ -1,503 +1,60 @@
 #include "ObjReader.h"
-#include <string>
-#include <stdlib.h>
-#include <sstream>
-
-IVMeshListNode *IVReader::meshList = NULL;
-int IVReader::instanceCnt = 0;
-Ogre::Log *IVReader::IVLog = NULL;
-
-
-
-IVMeshListNode::IVMeshListNode(std::string name, IVManualMeshLoader *loader)
-{
-	this->name = name;
-	this->loader = loader;
-	next = NULL;
-}
-
-IVMeshListNode::~IVMeshListNode()
-{
-	if (loader != NULL) delete loader;
-}
-
-void IVMeshListNode::attachNewNode(std::string name, IVManualMeshLoader *loader)
-{
-	IVMeshListNode *help = this;
-
-	while (help->next != NULL) help = help->next;
-	help->next = new IVMeshListNode(name, loader);
-}
-
-IVManualMeshLoader *IVMeshListNode::getManualMeshLoader(std::string name)
-{
-	IVMeshListNode *help = this;
-	if (help->name == name) return help->loader;
-	while (help->next != NULL) 
-	{
-		help = help->next;
-		if (help->name == name) return help->loader;
-	}
-	return NULL;
-}
-
-IVDefListNode::IVDefListNode(std::string name, IVNode *node)
-{
-	this->name = name;
-	this->node = node;
-	next = NULL;
-}
-
-IVDefListNode::~IVDefListNode()
-{
-}
-
-void IVDefListNode::attachNewNode(std::string name, IVNode *node)
-{
-	IVDefListNode *help = this;
-
-	while (help->next != NULL) help = help->next;
-	help->next = new IVDefListNode(name, node);
-}
-
-IVNode *IVDefListNode::getDef(std::string name)
-{
-	IVDefListNode *help = this;
-	if (help->name == name) return help->node;
-	while (help->next != NULL) 
-	{
-		help = help->next;
-		if (help->name == name) return help->node;
-	}
-	return NULL;
-}
-
-IVReader::IVReader()
-{	
-	root = NULL; meshList = NULL; defList = NULL; fileName = NULL;
-	instanceCnt++;
-	IVLog = NULL;
-}
-
-IVReader::~IVReader()
-{
-	collapse();
-
-	instanceCnt--;
-	if (instanceCnt == 0) if (meshList != NULL) 
-	{	
-		IVMeshListNode *help = meshList, *delme = NULL;
-		while (help->next != NULL)
-		{
-			delme = help; help = help->next; delete delme;
-		}
-		delete help;
-	}
-}
-
-void IVReader::collapse()
-{
-	if (root != NULL) {	delete root; root = NULL; }
-	if (defList != NULL)
-	{	
-		IVDefListNode *help = defList, *delme = NULL;
-		while (help->next != NULL)
-		{
-			delme = help; help = help->next; delete delme;
-		}
-		delete help;
-		defList = NULL;
-	}
-	if (this->fileName != NULL) { delete [] this->fileName; this->fileName = NULL; }
-
-}
-
-void IVReader::setLog(Ogre::Log *IVLog)
-{
-	this->IVLog = IVLog;
-}
-
-std::string IVReader::intToStr(int num)
-{
-	std::ostringstream myStream; 
-	myStream << num;
-	myStream.flush();
-	
-	return(myStream.str());
-}
-
-std::string IVReader::realToStr(Ogre::Real num)
-{
-	std::ostringstream myStream; 
-	myStream << num;
-	myStream.flush();
-	
-	return(myStream.str());
-}
-
-bool IVReader::loadFile(const char* fileName)
-{
-	std::string message = "trying to load "; message = message + fileName + "...";
-	
-	if (IVLog != NULL) 
-		IVLog->logMessage(message);
-	
-	collapse();
-	this->fileName = new char[strlen(fileName)+1]; strcpy(this->fileName, fileName);
-	treeCnt = 0;
-
-    infile = fopen(fileName, "r"); root = NULL;
-
-	if (infile == NULL)
-	{
-		message = "! Error loading File "; message = message + fileName + " !";
-		if (IVLog != NULL) IVLog->logMessage(message);
+#include "gzstream.h"
+#include "Triangle3.h"
+
+
+ObjReader::ObjReader()
+{}
+
+ObjReader::~ObjReader()
+{}
+
+
+bool ObjReader::LoadFile(const string &filename,
+						 TriangleContainer &triangles) const
+{
+	igzstream samplesIn(filename.c_str());
+	
+	if (!samplesIn.is_open())
 		return false;
-	}
-
-	if ((fgets(buf, BUFFERSIZE, infile) == NULL) && !feof(infile)) 
-	{
-		message = "! Error loading File "; message = message + fileName + " !";
-		if (IVLog != NULL) IVLog->logMessage(message);
-		fclose(infile);
-		return false;
-	}
-
-	if (!checkHeader(buf)) 
-	{
-		message = "! Invalid Header !";
-		if (IVLog != NULL) IVLog->logMessage(message);
-		fclose(infile);
-		return false;
-	}
-
-	IVTokenType tmptyp = IV_TOKEN_INVALID;
-	eof = false;	
-
-	bufOffset = 0;
-	char token[BUFFERSIZE] = "\0", oldtoken[BUFFERSIZE] = "\0", fieldtoken[BUFFERSIZE] = "\0";
-	int level = 0; 
-
-	while (getNextElement(token, &tmptyp)) 
-	{
-		if (tmptyp == IV_TOKEN_BRACEOPEN) 
-		{
-			root = new IVNode(oldtoken);
-			level++;
+	
+	// read in triangle size
+	int numTriangles;
+
+	samplesIn.read(reinterpret_cast<char *>(&numTriangles), sizeof(int));
+	triangles.reserve(numTriangles);
+	
+	while (1)
+	{
+		GtpVisibilityPreprocessor::Triangle3 *tri = 
+			new GtpVisibilityPreprocessor::Triangle3();
+		
+		samplesIn.read(reinterpret_cast<char *>((*tri).mVertices + 0), 
+					   sizeof(GtpVisibilityPreprocessor::Vector3));
+		samplesIn.read(reinterpret_cast<char *>((*tri).mVertices + 1), 
+					   sizeof(GtpVisibilityPreprocessor::Vector3));
+		samplesIn.read(reinterpret_cast<char *>((*tri).mVertices + 2), 
+					   sizeof(GtpVisibilityPreprocessor::Vector3));
+
+		// end of file reached
+		if (samplesIn.eof())
 			break;
-		}
-
-		strcpy(oldtoken, token);
-	}
-
-	IVNode *actualNode = root, *parent = root, *fieldNode = root, *newNode = NULL;
-	IVTokenType oldtmptyp = tmptyp;
-	bool textfield = false, realfield = false; IVType fieldtyp = IV_INVALID;
-	bool def = false; std::string defLabel;
-	Ogre::Real rblock[BLOCKSIZE]; 
-	float *rvalues;
-	int cnt = 0; int blockcnt = 0;
-	while (getNextElement(token, &tmptyp))
-	{
-		if ((tmptyp == IV_TOKEN_BRACKETOPEN)) 
-			if (!getNextElement(token, &tmptyp)) break;
-		if ((tmptyp == IV_TOKEN_INVALID)) 
-			if (!getNextElement(token, &tmptyp)) break;
-		if (tmptyp == IV_TOKEN_BRACEOPEN) 
-		{
-			actualNode = new IVNode(oldtoken); 
-			if (parent == NULL)
-			{
-				message = "Error loading file "; message = message + fileName + "! Invalid tree structure.";
-				if (IVLog != NULL) IVLog->logMessage(message);
-				fclose(infile);
-				return false;
-			}
-			parent->attachNode(actualNode);
-			parent = actualNode;
-			level++;
-
-			if (def)
-			{
-				addDefToList(defLabel, actualNode);
-				def = false;
-			}
-
-		} else
-		if (tmptyp == IV_TOKEN_BRACECLOSE) 
-		{
-			if (realfield)
-			{
-				if (blockcnt == 0) rvalues = (Ogre::Real *)malloc((cnt)*sizeof(Ogre::Real));
-				else rvalues = (Ogre::Real *)realloc(rvalues, (BLOCKSIZE*(blockcnt) + cnt)*sizeof(Ogre::Real));						
-				memcpy((void *)&rvalues[BLOCKSIZE*blockcnt], rblock, cnt*sizeof(Ogre::Real));
-				fieldNode->addField(fieldtoken, rvalues, BLOCKSIZE*blockcnt+cnt, fieldtyp);
-				realfield = false;
-//				free(rvalues);
-			}
-
-			if (level > 0)
-			{
-				actualNode = parent = actualNode->getParent();
-				level--;
-			}
-		} else
-		{
-			if (oldtmptyp == IV_TOKEN_DEF)
-			{
-				def = true; defLabel = ""; defLabel = defLabel + token;
-			} else
-			if (oldtmptyp == IV_TOKEN_USE)
-			{
-					newNode = new IVNode("USE"); 
-					if (parent == NULL)
-					{
-						message = "Error loading file "; message = message + fileName + "! Invalid tree structure.";
-						if (IVLog != NULL) IVLog->logMessage(message);
-						fclose(infile);
-						return false;
-					}
-					char *s = (char *)malloc(sizeof(char)*(strlen(token)+1));
-					memcpy(s, token, strlen(token));
-					s[strlen(token)] = '\0';
-					newNode->addField("label", s);
-					actualNode->attachNode(newNode);
-			} else
-			if (!def)
-			if (oldtmptyp == IV_TOKEN_STRING)
-			{
-				if (!textfield)
-				{
-					if (tmptyp == IV_TOKEN_STRING)
-					{
-/*						char *s = new char[strlen(token)+1];
-						strcpy(s, token);
-*/						
-						char *s = (char *)malloc(sizeof(char)*(strlen(token)+1));
-						memcpy(s, token, strlen(token));
-						s[strlen(token)] = '\0';
-						actualNode->addField(oldtoken, s);
-//						delete [] s;
-					}
-				}
-				if (!realfield)
-				{
-					if ((tmptyp == IV_TOKEN_REAL) || (tmptyp == IV_TOKEN_INT))
-					{	
-						cnt = 0; blockcnt = 0;
-						char *stopstring;						
-						rblock[0] = strtod(token, &stopstring);
-						cnt++;
-						strcpy(fieldtoken, oldtoken);
-						fieldNode = actualNode;
-					    if (tmptyp == IV_TOKEN_REAL) fieldtyp = IV_REAL;
-						if (tmptyp == IV_TOKEN_INT)	fieldtyp = IV_INT;
-						realfield = true;
-					}
-				}
-				textfield = !textfield;
-			}
-			else 
-			{
-				if (realfield)	
-				{
-					if ((tmptyp == IV_TOKEN_REAL) || (tmptyp == IV_TOKEN_INT))
-					{		
-						char *stopstring;
-						if (cnt >= BLOCKSIZE) 
-						{
-							if (blockcnt == 0) rvalues = (Ogre::Real *)malloc((BLOCKSIZE)*sizeof(Ogre::Real));
-							else rvalues = (Ogre::Real *)realloc(rvalues, (BLOCKSIZE*(blockcnt+1))*sizeof(Ogre::Real));
-							memcpy((void *)&rvalues[BLOCKSIZE*blockcnt], rblock, BLOCKSIZE*sizeof(Ogre::Real));
-							cnt = 0;
-							blockcnt++;
-							
-						}
-						rblock[cnt] = strtod(token, &stopstring);
-						cnt++;
-					    if (tmptyp == IV_TOKEN_REAL) fieldtyp = IV_REAL;
-					}
-					else
-					{
-						if (blockcnt == 0) rvalues = (Ogre::Real *)malloc((cnt)*sizeof(Ogre::Real));
-						else rvalues = (Ogre::Real *)realloc(rvalues, (BLOCKSIZE*(blockcnt) + cnt)*sizeof(Ogre::Real));						
-						memcpy((void *)&rvalues[BLOCKSIZE*blockcnt], rblock, cnt*sizeof(Ogre::Real));
-						fieldNode->addField(fieldtoken, rvalues, BLOCKSIZE*blockcnt+cnt, fieldtyp);
-						realfield = false;
-//						free(rvalues);
-					}
-				}
-				
-				textfield = false;
-			}
-		}
-
-
-		strcpy(oldtoken, token);
-		oldtmptyp = tmptyp;
-	}
-	message = ""; ; message = message + fileName + " loaded.";
-	if (IVLog != NULL) IVLog->logMessage(message);
-	fclose(infile);
-
+
+		triangles.push_back(tri);
+	}
+	
 	return true;
 }
 
-void IVReader::print()
-{
-	if (root != NULL) root->print();
-}
-
-bool IVReader::checkHeader(const char *string)
-{
-	for (int i=0; i < validIVHeaderCnt; i++)
-		if (strcmp(validIVHeader[i], string) == 0) return true;
-	return false;
-}
-bool IVReader::isSpace(char c)
-{
-	if ((c==' ') || (c=='\t')) return true;
-	return false;
-}
-bool IVReader::isNewline(char c)
-{
-	if (c=='\n') return true;
-	return false;
-}
-bool IVReader::isDigit(char c)
-{
-	if ((c>=48) && (c<=57)) return true;
-	return false;
-}
-bool IVReader::isHexDigit(char c)
-{
-	if ( ((c>=48) && (c<=57)) || ((c>=65) && (c<=70)) || ((c>=97) && (c<=102)) ) return true;
-	return false;
-}
-
-
-bool IVReader::getNextElement(char *token, IVTokenType *type)
-{
-	if (eof) return false;
-	bool quoted = false;
-	while (isSpace(buf[bufOffset])) bufOffset++;
-	int i=0;
-	while ((!isSpace(buf[bufOffset])) || (quoted))
-	{
-		if (!quoted)
-		{
-			if (isNewline(buf[bufOffset]) || (buf[bufOffset] == COMMENTCHAR))
-			{
-				token[i] = '\0'; 
-				classify(token, type);
-				bufOffset = 0;
-				if (fgets(buf, BUFFERSIZE, infile) == NULL) 
-				{			
-					eof = true;
-				}
-				if (i==0) return getNextElement(token, type);
-				return true;
-			}
-			if ((buf[bufOffset] == ',') || (buf[bufOffset] == ']'))
-			{
-				token[i] = '\0';
-				bufOffset++;
-				classify(token, type);
-				return true;
-			}
-		
-			
-
-		} else if (isNewline(buf[bufOffset])) {	eof = true;	}
-
-		
-		token[i] = buf[bufOffset]; 
-		i++;
-		if (buf[bufOffset] == '"') 
-		{
-			quoted = !quoted; i--;
-		}
-		bufOffset++;
-
-		
-	}
-	token[i] = '\0';
-	classify(token, type);
-	return true;
-}
-
-void IVReader::classify(char *token, IVTokenType *type)
-{
-	bool isInt = true, isReal = true;
-	if (!isDigit(token[0]) && (token[0] != '-') && (token[0] != '+')) 
-	{
-		isInt = false; 
-		if (token[0] != '.') isReal = false; 
-	}
-	int i = 1;
-	while ((token[i] != '\0') && isReal)
-	{
-		if (isInt && (i!=2) && !isHexDigit(token[i])) 
-		{
-			isInt = false;
-		}
-		if (isInt && (i==2) && !isHexDigit(token[i]) && (token[i] != 'x') && (token[i] != 'X')) isInt = false;
-		if (isReal && (!isDigit(token[i])) && (token[i] != '.') && (token[i] != 'e') && (token[i] != 'E') && (token[i] != 'd') && (token[i] != 'D') && (token[i] != '-') && (token[i] != '+')) isReal = false;
-		i++;
-	}
-	if (isInt) *type = IV_TOKEN_INT; 
-	else if (isReal) *type = IV_TOKEN_REAL;
-	else *type = IV_TOKEN_STRING;
-
-	if (strcmp(token, "DEF") == 0) *type = IV_TOKEN_DEF;
-	if (strcmp(token, "USE") == 0) *type = IV_TOKEN_USE;
-
-	if (token[1] == '\0')
-	{
-		if (token[0] == '{') *type = IV_TOKEN_BRACEOPEN;
-		if (token[0] == '}') *type = IV_TOKEN_BRACECLOSE;
-		if (token[0] == '[') *type = IV_TOKEN_BRACKETOPEN;
-		if (token[0] == ']') *type = IV_TOKEN_BRACKETCLOSE;
-		if (token[0] == '(') *type = IV_TOKEN_PARENTHESISOPEN;
-		if (token[0] == ')') *type = IV_TOKEN_PARENTHESISCLOSE;
-	}
-	if (token[0] == '\0')
-	{
-		*type = IV_TOKEN_INVALID;
-	}
-
-}
-
-/*
-IVNode *IVReader::getNode(const char* name)
-{
-	return root->getNodeRecursive(name);
-}
-*/
-void IVReader::addMeshToList(std::string name, IVManualMeshLoader *loader)
-{	
-	if (meshList == NULL) 
-	{
-		meshList = new IVMeshListNode(name, loader);
-	}
-	else
-	{
-		meshList->attachNewNode(name, loader);
-	}
-}
-
-void IVReader::addDefToList(std::string name, IVNode *node)
-{	
-	if (defList == NULL) 
-	{
-		defList = new IVDefListNode(name, node);
-	}
-	else
-	{
-		defList->attachNewNode(name, node);
-	}
-}
-
-Ogre::Entity *IVReader::createEntity(Ogre::SceneManager* sceneMgr, std::string name, IVMeshData *mData, Ogre::Vector3 *translation)
+
+const std::vector<Ogre::Entity *> &ObjReader::GetObjects() const
+{
+	return mObjects;
+}
+
+
+#if TODO
+
+Ogre::Entity *IVReader::createEntity(Ogre::SceneManager* sceneMgr, std::string name, ObjMeshData *mData, Ogre::Vector3 *translation)
 {
 	using namespace Ogre;
@@ -510,7 +67,7 @@
 	{
 
-		IVMeshData *data = mData->expand();
-
-		IVManualMeshLoader *loader	= new IVManualMeshLoader(data);
+		ObjMeshData *data = mData->expand();
+
+		ObjManualMeshLoader *loader	= new ObjManualMeshLoader(data);
 
 		if (translation != NULL) *translation = data->boundingBox->getCenter();
@@ -544,6 +101,5 @@
 
 
-
-void IVReader::buildTree(Ogre::SceneManager* sceneMgr,  Ogre::SceneNode *sceneNodeRoot)
+void IVReader::buildTree(Ogre::SceneManager* sceneMgr, Ogre::SceneNode *sceneNodeRoot)
 {
 	using namespace Ogre;
@@ -575,5 +131,5 @@
 void IVReader::buildTree(Ogre::SceneManager* sceneMgr,  
 						 Ogre::SceneNode *sceneNodeRoot, 
-						 IVNode *IVReaderoot, IVMeshData *mData, 
+						 ObjNode *IVReaderoot, ObjMeshData *mData, 
 						 Ogre::Material *material)
 {
@@ -585,11 +141,11 @@
 	if (mData == NULL)
 	{
-		mData = new IVMeshData();
+		mData = new ObjMeshData();
 		meshDataCreated = true;
 	}
 
-	IVType t; int i;
-	
-	IVNode *help = IVReaderoot->getNextChildNode(true);
+	ObjType t; int i;
+	
+	ObjNode *help = IVReaderoot->getNextChildNode(true);
 	while (help != NULL)
 	{	
@@ -743,5 +299,5 @@
 			if (t != IV_INT) mData->texCoordIndices = NULL;
 
-			IVNode *n = help->getNextChildNode(true);
+			ObjNode *n = help->getNextChildNode(true);
 			while ((n != NULL) && (strcmp(help->getName(), "VertexProperty") == 0))
 			{
@@ -775,3 +331,3 @@
 	if (meshDataCreated) if (mData != NULL) delete mData;
 }
-
+#endif
Index: GTP/trunk/Lib/Vis/Preprocessing/src/ViewCellsManager.h
===================================================================
--- GTP/trunk/Lib/Vis/Preprocessing/src/ViewCellsManager.h	(revision 2105)
+++ GTP/trunk/Lib/Vis/Preprocessing/src/ViewCellsManager.h	(revision 2111)
@@ -286,5 +286,5 @@
 	virtual void GetPrVS(const Vector3 &viewPoint, PrVs &prvs, const float filterWidth);
   
-	/** Get a viewcell containing the specified point 
+	/** Get a viewcell containing the specified view point.
 		@param active if the active or elementary view cell should be returned.
 	*/
Index: GTP/trunk/Lib/Vis/Preprocessing/src/Preprocessor.cpp
===================================================================
--- GTP/trunk/Lib/Vis/Preprocessing/src/Preprocessor.cpp	(revision 2076)
+++ GTP/trunk/Lib/Vis/Preprocessing/src/Preprocessor.cpp	(revision 2111)
@@ -265,5 +265,5 @@
 
 
-bool Preprocessor::LoadBinaryObj(const string filename,
+bool Preprocessor::LoadBinaryObj(const string &filename,
 								 SceneGraphNode *root,
 								 vector<FaceParentInfo> *parents)
@@ -277,12 +277,4 @@
 	cout << "binary obj dump available, loading " << filename.c_str() << endl;
 	
-	// table for vertices
-	VertexContainer vertices; 
-	
-	if (parents)
-		cout << "using face parents" << endl;
-	else
-		cout << "not using face parents" << endl;
-
 	// read in triangle size
 	int numTriangles;
@@ -309,7 +301,5 @@
 		root->mGeometry.push_back(obj);
 		
-		i ++;
-	
-		if (i % 500000 == 499999)
+		if ((i ++) % 500000 == 499999)
 			 cout<<"\r"<<i<<"/"<<numTriangles<<"\r";
 	}
Index: GTP/trunk/Lib/Vis/Preprocessing/src/Preprocessor.h
===================================================================
--- GTP/trunk/Lib/Vis/Preprocessing/src/Preprocessor.h	(revision 2105)
+++ GTP/trunk/Lib/Vis/Preprocessing/src/Preprocessor.h	(revision 2111)
@@ -260,5 +260,5 @@
 protected:
 
-	bool LoadBinaryObj(const string filename,
+	bool LoadBinaryObj(const string &filename,
 					   SceneGraphNode *root,
 					   vector<FaceParentInfo> *parents);
Index: GTP/trunk/Lib/Vis/Preprocessing/src/BoundingBoxConverter.h
===================================================================
--- GTP/trunk/Lib/Vis/Preprocessing/src/BoundingBoxConverter.h	(revision 2066)
+++ GTP/trunk/Lib/Vis/Preprocessing/src/BoundingBoxConverter.h	(revision 2111)
@@ -16,6 +16,6 @@
 };
 
-/** Class used to assign unique indices to objects using a 
-	comparison of bounding boxes.
+/** This class assigns unique indices to objects by
+    comparing bounding boxes.
 */
 class BoundingBoxConverter
Index: GTP/trunk/Lib/Vis/Preprocessing/manual/integration.aux
===================================================================
--- GTP/trunk/Lib/Vis/Preprocessing/manual/integration.aux	(revision 2104)
+++ GTP/trunk/Lib/Vis/Preprocessing/manual/integration.aux	(revision 2111)
@@ -20,10 +20,10 @@
 \@writefile{toc}{\contentsline {subsection}{\numberline {5.1}Intersectable}{4}}
 \newlabel{sec:intersectable}{{5.1}{4}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {5.2}Bounding Box Converter}{4}}
-\newlabel{sec:Converter}{{5.2}{4}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {5.2}Bounding Box Converter}{5}}
+\newlabel{sec:Converter}{{5.2}{5}}
 \@writefile{toc}{\contentsline {section}{\numberline {6}View Cells Usage}{7}}
 \newlabel{sec:usage}{{6}{7}}
 \@setckpt{integration}{
-\setcounter{page}{8}
+\setcounter{page}{9}
 \setcounter{equation}{0}
 \setcounter{enumi}{0}
Index: GTP/trunk/Lib/Vis/Preprocessing/manual/integration.tex
===================================================================
--- GTP/trunk/Lib/Vis/Preprocessing/manual/integration.tex	(revision 2104)
+++ GTP/trunk/Lib/Vis/Preprocessing/manual/integration.tex	(revision 2111)
@@ -148,8 +148,17 @@
 \label{sec:Loading}
 
-A view cells manager is returned from the loading call. It will be used to access and
-manage the view cells from now on. For example, it can be applied to locate the current view cell.
-For loading, the user has to provide the filename of the visibility solution, an ObjectContainer 
+The loading function returns a view cells.
+
+\begin{verbatim}
+static ViewCellsManager *LoadViewCells(const string &filename, 
+										   ObjectContainer *objects, 
+										   bool finalizeViewCells = false,
+										   BoundingBoxConverter *bconverter = NULL);
+\end{verbatim}
+
+The user has to provide the filename of the visibility solution, an ObjectContainer 
 containing all the static entities of the scene, and a bounding box converter. 
+From now on, the view cells manager is used to access and
+manage the view cells. For example, it can be applied to locate the current view cell.
 After this step the view cells should be loaded and accessable in the engine.
 
@@ -170,5 +179,4 @@
 
 \begin{verbatim}
-
 // a vector of engine entities
 typedef vector<Entity *> EntityContainer;
@@ -201,14 +209,39 @@
 This is maybe the most tricky part of the integration. The bounding box converter
 is necessary because we have to associate the objects of the visibility solution with
-the objects from the engine without having unique ids.
-
-We give an example for a Bounding Box Converter 
-for Ogre. It is templated in order to works with any Ogre SceneManager.
+the objects from the engine without having unique ids. This is the interface
+of the {\em BoundingBoxConverter }.
+
+\begin{verbatim}
+/** This class assigns unique indices to objects by
+    comparing bounding boxes.
+*/
+class BoundingBoxConverter
+{
+public:
+	/** Takes a vector of indexed bounding boxes and 
+	    identify objects with a similar bounding box
+      It will then assign the bounding box id to the objects.
+      The objects are returned in the object container.
+		
+      @returns true if conversion was successful
+  */
+  virtual bool IdentifyObjects(
+                 const IndexedBoundingBoxContainer &iboxes,
+                 ObjectContainer &objects) const
+  {
+    // default: do nothing as we assume that a unique id is 
+    // already assigned to the objects.
+    return true;
+  }
+};
+\end{verbatim}
+
+We give an example of implementation of a Bounding Box Converter 
+for Ogre3D rendering engine. It is templated in order to works with any Ogre SceneManager.
 Again, the implementation of this interface must be adapted for the requirements 
 of the particular engine. 
 
 \begin{verbatim}
-
-/**	Class which converts preprocessor entites to Ogre3D entities
+/**	This class converts preprocessor entites to Ogre3D entities
 */
 template<typename T> PlatFormBoundingBoxConverter: 
@@ -216,16 +249,11 @@
 {
 public:
+  /** This constructor takes a scene manager template as parameter.
+  */
   PlatFormBoundingBoxConverter(T *sm);
 	
-  /** Takes a vector of indexed bounding boxes and uses it to 
-      identify objects with a similar bounding box
-      and assigns them the proper index (id).
-      The objects are returned in the object container.
-		
-      @returns true if conversion was successful
-  */
   bool IdentifyObjects(const GtpVisibilityPreprocessor::
          IndexedBoundingBoxContainer &iboxes,
-	       GtpVisibilityPreprocessor::ObjectContainer &objects) const;
+         GtpVisibilityPreprocessor::ObjectContainer &objects) const;
 
 protected:
@@ -241,13 +269,11 @@
 typedef PlatFormBoundingBoxConverter<OctreeSceneManager> 
           OctreeBoundingBoxConverter;
-
 \end{verbatim}
 
 This class is inherited from {\em BoundingBoxConverter}.
 {\em BoundingBoxConverters} has only one virtual function {\em IdentifyObjects} that must
-be implemented. Additionally we 
-use a helper function {\em FindIntersectingObjects} that is responsible for locating the 
-corresponding objects in the scene. Let's now have a look at the 
-implementation of {\em IdentifyObjects} for Ogre3D.
+be implemented. Additionally we use a helper function {\em FindIntersectingObjects} that 
+is responsible for locating the corresponding objects in the scene. Let's now have a look 
+at the implementation of {\em IdentifyObjects} for Ogre3D.
 
 \begin{verbatim}
@@ -280,7 +306,6 @@
 
 The function just loops over the bounding boxes of the PVS entries and finds the entities that
-are intersected by the bouding boxes. Let's have a look now at the function {\em FindIntersectingObjects}, which
-is searching the intersections for each individual box.
-
+are intersected by the bouding boxes. Let's have a look now at the function 
+{\em FindIntersectingObjects}, which is searching the intersections for each individual box.
 
 \begin{verbatim}
@@ -330,7 +355,7 @@
 Note that the implementation of this function is maybe the one that differs the most
 for another engine, as it is highly depending on the particular engine design. 
-For the Ogre3D implementation, we use a two stage approach. First we find the intersecting scene nodes.
-We apply a search function that is optimized for this engine. 
-In the Ogre3D case, this is the function {\em findNodesIn}.
+For the Ogre3D implementation, we use a two stage approach. First we find the 
+intersecting scene nodes. We apply a search function that is optimized for this engine. 
+In case of Ogre3D, this is the function {\em findNodesIn}.
 The engine is responsible to provide a function for fast geometric search in the scene,
 in order to quickly find the objects intersecting the bounding box of a PVS entry. 
@@ -342,13 +367,20 @@
 \label{sec:usage}
 
-By now the view cells should be accessible within the target engine. This happens through
-the view cells manager. In order to query the current view cell, use the following code.
+By now the view cells should be accessible within the target engine. The 
+view cells manager provides the necessary functionality to handle the view cells. 
+In order to query the current view cell, use the following function of the 
+view cells manager.
+
+\begin{verbatim}
+ViewCell *GetViewCell(const Vector3 &point, const bool active = false) const;
+\end{verbatim}
+
+In your engine, the function will called like this.
 
 \begin{verbatim}
 ViewCell *currentViewCell = viewCellsManager->GetViewCell(viewPoint);
-
-\end{verbatim}
-
-where {\em viewPoint} contains the current location of the player. It must be of type
+\end{verbatim}
+
+{\em viewPoint} contains the current location of the player. It must be of type
 {\em GtpVisibilityPreprocessor::Vector3}. In order to traverse the PVS of this view cell, we 
 apply a PVS iterator, like in the following example.
@@ -377,5 +409,4 @@
   }	
 }
-
-\end{verbatim}
-
+\end{verbatim}
+
Index: GTP/trunk/Lib/Vis/Preprocessing/manual/manual.ilg
===================================================================
--- GTP/trunk/Lib/Vis/Preprocessing/manual/manual.ilg	(revision 2068)
+++ GTP/trunk/Lib/Vis/Preprocessing/manual/manual.ilg	(revision 2111)
@@ -1,4 +1,4 @@
-This is D:\texmf\MiKTeX\bin\makeindex.exe, version 2.14 [02-Oct-2002] (with Thai support).
-Scanning input file D:\svn\gametools\GTP\trunk\Lib\Vis\Preprocessing\manual\manual.idx...done (0 entries accepted, 0 rejected).
-Nothing written in D:\svn\gametools\GTP\trunk\Lib\Vis\Preprocessing\manual\manual.ind.
-Transcript written in D:\svn\gametools\GTP\trunk\Lib\Vis\Preprocessing\manual\manual.ilg.
+This is C:\texmf\MiKTeX\bin\makeindex.exe, version 2.14 [02-Oct-2002] (with Thai support).
+Scanning input file E:\svn\gametools\GTP\trunk\Lib\Vis\Preprocessing\manual\manual.idx...done (0 entries accepted, 0 rejected).
+Nothing written in E:\svn\gametools\GTP\trunk\Lib\Vis\Preprocessing\manual\manual.ind.
+Transcript written in E:\svn\gametools\GTP\trunk\Lib\Vis\Preprocessing\manual\manual.ilg.
Index: GTP/trunk/Lib/Vis/Preprocessing/manual/manual.log
===================================================================
--- GTP/trunk/Lib/Vis/Preprocessing/manual/manual.log	(revision 2104)
+++ GTP/trunk/Lib/Vis/Preprocessing/manual/manual.log	(revision 2111)
@@ -1,12 +1,11 @@
-This is pdfeTeX, Version 3.141592-1.21a-2.2 (MiKTeX 2.4) (preloaded format=latex 2005.8.25)  8 FEB 2007 14:02
+This is pdfeTeX, Version 3.141592-1.21a-2.2 (MiKTeX 2.4) (preloaded format=latex 2007.1.5)  9 FEB 2007 14:21
 entering extended mode
-**D:/svn/gametools/GTP/trunk/Lib/Vis/Preprocessing/manual/manual.tex
-(D:/svn/gametools/GTP/trunk/Lib/Vis/Preprocessing/manual/manual.tex
+**E:/svn/gametools/GTP/trunk/Lib/Vis/Preprocessing/manual/manual.tex
+(E:/svn/gametools/GTP/trunk/Lib/Vis/Preprocessing/manual/manual.tex
 LaTeX2e <2003/12/01>
-Babel <v3.8g> and hyphenation patterns for english, dumylang, nohyphenation, ge
-rman, ngerman, french, loaded.
-(D:\texmf\tex\latex\base\article.cls
+Babel <v3.8a> and hyphenation patterns for english, french, german, ngerman, dumylang, nohyphenation, loaded.
+(C:\texmf\tex\latex\base\article.cls
 Document Class: article 2004/02/16 v1.4f Standard LaTeX document class
-(D:\texmf\tex\latex\base\size10.clo
+(C:\texmf\tex\latex\base\size10.clo
 File: size10.clo 2004/02/16 v1.4f Standard LaTeX file (size option)
 )
@@ -22,13 +21,12 @@
 \belowcaptionskip=\skip42
 \bibindent=\dimen102
-) (D:\texmf\tex\latex\psnfss\times.sty
-Package: times 2005/04/12 PSNFSS-v9.2a (SPQR) 
-)
-(D:\texmf\tex\latex\ltxmisc\a4wide.sty
+) (C:\texmf\tex\latex\psnfss\times.sty
+Package: times 2004/09/15 PSNFSS-v9.2 (SPQR) 
+) (C:\texmf\tex\latex\ltxmisc\a4wide.sty
 Package: a4wide 1994/08/30
- (D:\texmf\tex\latex\ntgclass\a4.sty
+
+(C:\texmf\tex\latex\ntgclass\a4.sty
 Package: a4 2004/04/15 v1.2g A4 based page layout
-))
-(D:\texmf\tex\latex\float\float.sty
+)) (C:\texmf\tex\latex\float\float.sty
 Package: float 2001/11/08 v1.3d Float enhancements (AL)
 \c@float@type=\count87
@@ -47,46 +45,44 @@
 \symmathboldr=\mathgroup6
 LaTeX Font Info:    Redeclaring math symbol \beta on input line 74.
- (D:\texmf\tex\latex\thumbpdf\thumbpdf.sty
-Package: thumbpdf 2005/07/06 v3.8 Inclusion of thumbnails (HO)
+ (C:\texmf\tex\latex\thumbpdf\thumbpdf.sty
+Package: thumbpdf 2004/11/19 v3.7 Inclusion of thumbnails (HO)
 
 
 Package thumbpdf Warning: Thumbnail data file `manual.tpt' not found.
 
-) (D:\texmf\tex\latex\base\alltt.sty
+) (C:\texmf\tex\latex\base\alltt.sty
 Package: alltt 1997/06/16 v2.0g defines alltt environment
-) (D:\texmf\tex\latex\tools\hhline.sty
+) (C:\texmf\tex\latex\tools\hhline.sty
 Package: hhline 1994/05/23 v2.03 Table rule package (DPC)
-)
-(multirow.sty
+) (multirow.sty
 \bigstrutjot=\dimen103
-) (D:\texmf\tex\latex\ltxmisc\url.sty
+)
+(C:\texmf\tex\latex\ltxmisc\url.sty
 \Urlmuskip=\muskip10
-Package: url 2005/06/27  ver 3.2  Verb mode for urls, etc.
+Package: url 2004/03/15  ver 3.1  Verb mode for urls, etc.
 ) (rotating.sty
 Package: rotating 1997/09/26, v2.13 Rotation package
-
-(D:\texmf\tex\latex\graphics\graphicx.sty
+ (C:\texmf\tex\latex\graphics\graphicx.sty
 Package: graphicx 1999/02/16 v1.0f Enhanced LaTeX Graphics (DPC,SPQR)
 
-(D:\texmf\tex\latex\graphics\keyval.sty
+(C:\texmf\tex\latex\graphics\keyval.sty
 Package: keyval 1999/03/16 v1.13 key=value parser (DPC)
 \KV@toks@=\toks16
-)
-(D:\texmf\tex\latex\graphics\graphics.sty
+) (C:\texmf\tex\latex\graphics\graphics.sty
 Package: graphics 2001/07/07 v1.0n Standard LaTeX Graphics (DPC,SPQR)
- (D:\texmf\tex\latex\graphics\trig.sty
+ (C:\texmf\tex\latex\graphics\trig.sty
 Package: trig 1999/03/16 v1.09 sin cos tan (DPC)
-) (D:\texmf\tex\latex\00miktex\graphics.cfg
+) (C:\texmf\tex\latex\00miktex\graphics.cfg
 File: graphics.cfg 2003/03/12 v1.1 MiKTeX 'graphics' configuration
 )
 Package graphics Info: Driver file: pdftex.def on input line 80.
-
-(D:\texmf\tex\latex\graphics\pdftex.def
-File: pdftex.def 2005/06/20 v0.03m graphics/color for pdftex
+ (C:\texmf\tex\latex\graphics\pdftex.def
+File: pdftex.def 2002/06/19 v0.03k graphics/color for pdftex
 \Gread@gobject=\count88
 ))
 \Gin@req@height=\dimen104
 \Gin@req@width=\dimen105
-) (D:\texmf\tex\latex\base\ifthen.sty
+)
+(C:\texmf\tex\latex\base\ifthen.sty
 Package: ifthen 2001/05/26 v1.1c Standard LaTeX ifthen package (DPC)
 )
@@ -115,9 +111,8 @@
 LaTeX Font Info:    ... okay on input line 135.
 LaTeX Font Info:    Try loading font information for OT1+ptm on input line 135.
-
- (D:\texmf\tex\latex\psnfss\ot1ptm.fd
+ (C:\texmf\tex\latex\psnfss\ot1ptm.fd
 File: ot1ptm.fd 2001/06/04 font definitions for OT1/ptm.
-)
-(D:\texmf\tex\context\base\supp-pdf.tex (D:\texmf\tex\context\base\supp-mis.tex
+) (C:\texmf\tex\context\base\supp-pdf.tex
+(C:\texmf\tex\context\base\supp-mis.tex
 loading : Context Support Macros / Miscellaneous (2004.10.26)
 \protectiondepth=\count90
@@ -158,8 +153,7 @@
 LaTeX Font Info:    External font `cmex10' loaded for size
 (Font)              <6> on input line 164.
-LaTeX Font Info:    Try loading font information for OML+cmbrm on input line 16
-4.
- (D:\texmf\tex\latex\cmbright\omlcmbrm.fd
-File: omlcmbrm.fd 2005/04/13 v8.1 (WaS)
+LaTeX Font Info:    Try loading font information for OML+cmbrm on input line 164.
+ (C:\texmf\tex\latex\cmbright\omlcmbrm.fd
+File: omlcmbrm.fd 1999/05/12 v7.3 (WaS)
 )
 LaTeX Font Info:    Font shape `OT1/ptm/bx/n' in size <14.4> not available
@@ -172,8 +166,8 @@
  [1
 
-{psfonts.map}]
-(integration.tex
+{psfonts.map}] (integration.tex
 LaTeX Font Info:    Try loading font information for OT1+pcr on input line 27.
- (D:\texmf\tex\latex\psnfss\ot1pcr.fd
+
+(C:\texmf\tex\latex\psnfss\ot1pcr.fd
 File: ot1pcr.fd 2001/06/04 font definitions for OT1/pcr.
 )
@@ -181,6 +175,5 @@
 (Font)              Font shape `OT1/ptm/b/n' tried instead on input line 62.
 LaTeX Font Info:    Try loading font information for OMS+ptm on input line 68.
-
-(D:\texmf\tex\latex\psnfss\omsptm.fd
+ (C:\texmf\tex\latex\psnfss\omsptm.fd
 File: omsptm.fd 
 )
@@ -190,55 +183,62 @@
 
 ] [3]
-Overfull \hbox (1.41376pt too wide) in paragraph at lines 195--195
-[]                                \OT1/pcr/m/n/10 IntersectableWrapper<EntityCo
-ntainer *>[] 
- []
-
-
-Overfull \hbox (19.41376pt too wide) in paragraph at lines 195--195
-[]   \OT1/pcr/m/n/10 EngineIntersectable(EntityContainer *item): GtpVisibilityP
-reprocessor::[] 
- []
-
-[4]
-Overfull \hbox (31.41376pt too wide) in paragraph at lines 279--279
-[]       \OT1/pcr/m/n/10 const GtpVisibilityPreprocessor::IndexedBoundingBoxCon
-tainer &iboxes,[] 
- []
-
-[5]
-Overfull \hbox (1.41376pt too wide) in paragraph at lines 279--279
-[]    \OT1/pcr/m/n/10 EngineIntersectable *entry = new EngineIntersectable(entr
-yObjects);[] 
- []
-
-
-Overfull \hbox (1.41376pt too wide) in paragraph at lines 328--328
-[]  \OT1/pcr/m/n/10 for (sit = sceneNodeList.begin(); sit != sceneNodeList.end(
-); ++ sit)[] 
- []
-
-
-Overfull \hbox (7.41376pt too wide) in paragraph at lines 328--328
-[]      \OT1/pcr/m/n/10 // test for intersection (note: function provided of pr
-eprocessor)[] 
- []
-
-[6]) [7] (manual.aux (integration.aux)) ) 
+Overfull \hbox (1.41376pt too wide) in paragraph at lines 203--203
+[]                                \OT1/pcr/m/n/10 IntersectableWrapper<EntityContainer *>[] 
+ []
+
+
+Overfull \hbox (19.41376pt too wide) in paragraph at lines 203--203
+[]   \OT1/pcr/m/n/10 EngineIntersectable(EntityContainer *item): GtpVisibilityPreprocessor::[] 
+ []
+
+[4] [5]
+Overfull \hbox (31.41376pt too wide) in paragraph at lines 305--305
+[]       \OT1/pcr/m/n/10 const GtpVisibilityPreprocessor::IndexedBoundingBoxContainer &iboxes,[] 
+ []
+
+
+Overfull \hbox (1.41376pt too wide) in paragraph at lines 305--305
+[]    \OT1/pcr/m/n/10 EngineIntersectable *entry = new EngineIntersectable(entryObjects);[] 
+ []
+
+
+Overfull \hbox (1.41376pt too wide) in paragraph at lines 353--353
+[]  \OT1/pcr/m/n/10 for (sit = sceneNodeList.begin(); sit != sceneNodeList.end(); ++ sit)[] 
+ []
+
+[6]
+Overfull \hbox (7.41376pt too wide) in paragraph at lines 353--353
+[]      \OT1/pcr/m/n/10 // test for intersection (note: function provided of preprocessor)[] 
+ []
+
+
+Overfull \hbox (37.41376pt too wide) in paragraph at lines 376--376
+[]\OT1/pcr/m/n/10 ViewCell *GetViewCell(const Vector3 &point, const bool active = false) const;[] 
+ []
+
+
+Overfull \hbox (12.43904pt too wide) in paragraph at lines 384--389
+[]\OT1/ptm/m/it/10 viewPoint \OT1/ptm/m/n/10 con-tains the cur-rent lo-ca-tion of the player. It must be of type \OT1/pt
+m/m/it/10 Gt-pVis-i-bil-i-tyPre-proces-sor::Vector3\OT1/ptm/m/n/10 .
+ []
+
+[7]) [8] (manual.aux (integration.aux))
+
+LaTeX Warning: Label(s) may have changed. Rerun to get cross-references right.
+
+ ) 
 Here is how much of TeX's memory you used:
- 1532 strings out of 95515
- 16755 string characters out of 1189489
- 64951 words of memory out of 1065662
- 4500 multiletter control sequences out of 60000
- 21808 words of font info for 49 fonts, out of 1000000 for 2000
- 14 hyphenation exceptions out of 4999
- 32i,7n,21p,279b,239s stack positions out of 5000i,500n,10000p,200000b,32768s
+ 1532 strings out of 95512
+ 16885 string characters out of 1189449
+ 64934 words of memory out of 1065638
+ 4503 multiletter control sequences out of 60000
+ 21808 words of font info for 49 fonts, out of 500000 for 1000
+ 14 hyphenation exceptions out of 607
+ 32i,7n,21p,279b,241s stack positions out of 1500i,500n,5000p,200000b,32768s
 PDF statistics:
- 38 PDF objects out of 300000
+ 41 PDF objects out of 300000
  0 named destinations out of 300000
  1 words of extra memory for PDF output out of 65536
-<D:\texmf\fonts\type1\bluesky\cm\cmsy1
-0.pfb>{8r.enc}<D:\texmf\fonts\type1\urw\urwstd\ucrr8a.pfb><D:\texmf\fonts\type1
-\urw\urwstd\utmri8a.pfb><D:\texmf\fonts\type1\urw\urwstd\utmb8a.pfb><D:\texmf\f
-onts\type1\urw\urwstd\utmr8a.pfb>
-Output written on manual.pdf (7 pages, 82926 bytes).
+<C:\texmf\fonts\type1\bluesky\cm\cmsy10.pfb>{8r.enc}<C:\texmf\fonts\type1\urw\urwstd\ucrr8a.pfb><C:\texmf\fonts\type1\
+urw\urwstd\utmri8a.pfb><C:\texmf\fonts\type1\urw\urwstd\utmb8a.pfb><C:\texmf\fonts\type1\urw\urwstd\utmr8a.pfb>
+Output written on manual.pdf (8 pages, 84658 bytes).
Index: GTP/trunk/Lib/Vis/Preprocessing/manual/manual.toc
===================================================================
--- GTP/trunk/Lib/Vis/Preprocessing/manual/manual.toc	(revision 2104)
+++ GTP/trunk/Lib/Vis/Preprocessing/manual/manual.toc	(revision 2111)
@@ -9,4 +9,4 @@
 \contentsline {section}{\numberline {5}Example Implementation}{4}
 \contentsline {subsection}{\numberline {5.1}Intersectable}{4}
-\contentsline {subsection}{\numberline {5.2}Bounding Box Converter}{4}
+\contentsline {subsection}{\numberline {5.2}Bounding Box Converter}{5}
 \contentsline {section}{\numberline {6}View Cells Usage}{7}
Index: GTP/trunk/Lib/Vis/Preprocessing/manual/introduction.tex
===================================================================
--- GTP/trunk/Lib/Vis/Preprocessing/manual/introduction.tex	(revision 2066)
+++ 	(revision )
@@ -1,705 +1,0 @@
-\chapter{Introduction}%\chapter
-
-\label{chap:introduction}
-
-\section{Structure of the report}
-
-  The report consists of two introductory chapters, which provide a
- theoretical background for description of the algorithms, and three
- chapters dealing with the actual visibility algorithms.
-
-  This chapter provides an introduction to visibility by using a
- taxonomy of visibility problems and algorithms. The taxonomy is used
- to classify the later described visibility
- algorithms. Chapter~\ref{chap:analysis} provides an analysis of
- visibility in 2D and 3D polygonal scenes. This analysis also includes
- formal description of visibility using \plucker coordinates of
- lines. \plucker coordinates are exploited later in algorithms for
- mutual visibility verification (Chapter~\ref{chap:mutual}).
-
- Chapter~\ref{chap:online} describes a visibility culling algorithm
- used to implement the online visibility culling module. This
- algorithm can be used accelerate rendering of fully dynamic scenes
- using recent graphics hardware.  Chapter~\ref{chap:sampling}
- describes global visibility sampling algorithm which forms a core of
- the PVS computation module. This chapter also describes view space
- partitioning algorithms used in close relation with the PVS
- computation. Finally, Chapter~\ref{chap:mutual} describes mutual
- visibility verification algorithms, which are used by the PVS
- computation module to generate the final solution for precomputed
- visibility.
-
-
-
-
-%% summarize the state of the art
-%% visibility algorithms and their relation to the proposed taxonomy of
-%% visibility problems. The second part of the survey should serve as a
-%% catalogue of visibility algorithms that is indexed by the proposed
-%% taxonomy of visibility problems.
-
-
-
-\section{Domain of visibility problems}
-\label{sec:prob_domain}
-
- Computer graphics deals with visibility problems in the context of
-2D, \m25d, or 3D scenes. The actual problem domain is given by
-restricting the set of rays for which visibility should be
-determined.
-
-Below we list common problem domains used and the corresponding domain
-restrictions:
-
-\begin{enumerate}
-\item
-  {\em visibility along a line}
-  \begin{enumerate}
-  \item line
-  \item ray (origin + direction)
-  \end{enumerate}
-  \newpage
-\item
-  {\em visibility from a point} ({\em from-point visibility})
-  \begin{enumerate}
-  \item point
-  \item point + restricted set of rays
-    \begin{enumerate}
-    \item point + raster image (discrete form)
-    \item point + beam (continuous form)
-    \end{enumerate}
-  \end{enumerate}
-
-  
-\item
-  {\em visibility from a line segment} ({\em from-segment visibility})
-  \begin{enumerate}
-  \item line segment
-  \item line segment + restricted set of rays
-  \end{enumerate}
-  
-\item
-  {\em visibility from a polygon} ({\em from-polygon visibility})
-  \begin{enumerate}
-  \item polygon
-  \item polygon + restricted set of rays
-  \end{enumerate}
-  
-\item
-  {\em visibility from a region} ({\em from-region visibility})
-  \begin{enumerate}
-    \item region
-    \item region + restricted set of rays
-  \end{enumerate}
-
-\item
-  {\em global visibility}
-  \begin{enumerate}
-    \item no further input (all rays in the scene)
-    \item restricted set of rays
-  \end{enumerate}
-\end{enumerate}
-  
- The domain restrictions can be given independently of the dimension
-of the scene, but the impact of the restrictions differs depending on
-the scene dimension. For example, visibility from a polygon is
-equivalent to visibility from a (polygonal) region in 2D, but not in
-3D.
-
-%*****************************************************************************
-
-\section{Dimension of the problem-relevant line set}
-
- The six domains of visibility problems stated in
-Section~\ref{sec:prob_domain} can be characterized by the {\em
-problem-relevant line set} denoted ${\cal L}_R$. We give a
-classification of visibility problems according to the dimension of
-the problem-relevant line set. We discuss why this classification is
-important for understanding the nature of the given visibility problem
-and for identifying its relation to other problems.
-
-
- For the following discussion we assume that a line in {\em primal
-space} can be mapped to a point in {\em line space}. For purposes of
-the classification we define the line space as a vector space where a
-point corresponds to a line in the primal space\footnote{A classical
-mathematical definition says: Line space is a direct product of two
-Hilbert spaces~\cite{Weisstein:1999:CCE}. However, this definition
-differs from the common understanding of line space in computer
-graphics~\cite{Durand99-phd}}.
-
-
-
-\subsection{Parametrization of lines in 2D}
-
- There are two independent parameters that specify a 2D line and thus
-the corresponding set of lines is two-dimensional. There is a natural
-duality between lines and points in 2D. For example a line expressed
-as: $l:y=ax+c$ is dual to a point $p=(-c,a)$. This particular duality
-cannot handle vertical lines. %See Figure~\ref{fig:duality2d} for an
-example of other dual mappings in the plane.  To avoid the singularity
-in the mapping, a line $l:ax+by+c=0$ can be represented as a point
-$p_l=(a,b,c)$ in 2D projective space ${\cal
-P}^2$~\cite{Stolfi:1991:OPG}. Multiplying $p_l$ by a non-zero scalar
-we obtain a vector that represents the same line $l$. More details
-about this singularity-free mapping will be discussed in
-Chapter~\ref{chap:analysis}.
-
-
-%\begin{figure}[!htb]
-%\centerline{
-%\includegraphics[width=0.9\textwidth,draft=\DRAFTFIGS]{figs/duality2d}}
-%\caption{Duality between points and lines in 2D.}
-%\label{fig:duality2d}
-%\end{figure}
-
-
-
-
-
- To sum up: In 2D there are two degrees of freedom in description of a
-line and the corresponding line space is two-dimensional. The
-problem-relevant line set ${\cal L}_R$ then forms a $k$-dimensional
-subset of ${\cal P}^2$, where $0\leq k \leq 2$. An illustration of the
-concept of the problem-relevant line set is depicted in
-%Figure~\ref{fig:classes}.
-
-
-%\begin{figure}[htb]
-%\centerline{
-%\includegraphics[width=0.8\textwidth,draft=\DRAFTFIGS]{figs/classes}}
-%\caption{The problem-relevant set of lines in 2D. The ${\cal L}_R$ for
-%visibility along a line is formed by a single point that is a mapping
-%of the given line. The ${\cal L}_R$ for visibility from a point $p$ is
-%formed by points lying on a line. This line is a dual mapping of the
-%point $p$. ${\cal L}_R$ for visibility from a line segment is formed
-%by a 2D region bounded by dual mappings of endpoints of the given
-%segment.}
-%\label{fig:classes}
-%\end{figure}
-
-
-\subsection{Parametrization of lines in 3D}
-
-
-Lines in 3D form a four-parametric space~\cite{p-rsls-97}. A line
-intersecting a given scene can be described by two points on a sphere
-enclosing the scene. Since the surface of the sphere is a two
-parametric space, we need four parameters to describe the line.
-
- The {\em two plane parametrization} of 3D lines describes a line by
-points of intersection with the given two
-planes~\cite{Gu:1997:PGT}. This parametrization exhibits a singularity
-since it cannot describe lines parallel to these planes. See
-%Figure~\ref{fig:3dlines} for illustrations of the spherical and the
-two plane parameterizations.
-
-
-%\begin{figure}[htb]
-%\centerline{
-%\includegraphics[width=0.78\textwidth,draft=\DRAFTFIGS]{figs/3dlines}}
-%\caption{Parametrization of lines in 3D. (left) A line can be
-%  described by two points on a sphere enclosing the scene. (right) The
-%  two plane parametrization describes a line by point of intersection
-%  with two given planes.}
-%\label{fig:3dlines}
-%\end{figure}
-
- Another common parametrization of 3D lines are the {\em \plucker
-coordinates}. \plucker coordinates of an oriented 3D line are a six
-tuple that can be understood as a point in 5D oriented projective
-space~\cite{Stolfi:1991:OPG}. There are six coordinates in \plucker
-representation of a line although we know that the ${\cal L}_R$ is
-four-dimensional. This can be explained as follows:
-
-\begin{itemize}
-  \item Firstly, \plucker coordinates are {\em homogeneous
-    coordinates} of a 5D point. By multiplication of the coordinates
-    by any positive scalar we get a mapping of the same line.
-  \item Secondly, only 4D subset of the 5D oriented projective space
-  corresponds to real lines. This subset is a 4D ruled quadric called
-  the {\em \plucker quadric} or the {\em Grassman
-  manifold}~\cite{Stolfi:1991:OPG,Pu98-DSGIV}.
-\end{itemize}
-
- Although the \plucker coordinates need more coefficients they have no
-singularity and preserve some linearities: lines intersecting a set of
-lines in 3D correspond to an intersection of 5D hyperplanes. More
-details on \plucker coordinates will be discussed in
-Chapter~\ref{chap:analysis} and Chapter~\ref{chap:mutual} where they
-are used to solve the from-region visibility problem.
-
-  To sum up: In 3D there are four degrees of freedom in the
-description of a line and thus the corresponding line space is
-four-dimensional. Fixing certain line parameters (e.g. direction) the
-problem-relevant line set, denoted ${\cal L}_R$, forms a
-$k$-dimensional subset of ${\cal P}^4$, where $0\leq k \leq 4$.
-
-
-\subsection{Visibility along a line}
-
- The simplest visibility problems deal with visibility along a single
-line. The problem-relevant line set is zero-dimensional, i.e. it is
-fully specified by the given line. A typical example of a visibility
-along a line problem is {\em ray shooting}.
-
- A similar problem to ray shooting is the {\em point-to-point}
-visibility.  The  point-to-point visibility determines whether the
-line segment between two points is occluded, i.e. it has an
-intersection with an opaque object in the scene. Point-to-point
-visibility provides a visibility classification (answer 1a), whereas
-ray shooting determines a visible object (answer 2a) and/or a point of
-intersection (answer 3a). Note that the {\em point-to-point}
-visibility can be solved easily by means of ray shooting. Another
-constructive visibility along a line problem is determining the {\em
-%maximal free line segments} on a given line. See Figure~\ref{fig:val}
-for an illustration of typical visibility along a line problems.
-
-%\begin{figure}[htb]
-%\centerline{
-%\includegraphics[width=0.85\textwidth,draft=\DRAFTFIGS]{figs/val}}
-%\caption{Visibility along a line. (left) Ray shooting. (center) Point-to-point visibility. (right) Maximal free line segments between two points.}
-%\label{fig:val}
-%\end{figure}
-
-
-\subsection{Visibility from a point}
-
- Lines intersecting a point in 3D can be described  by two
-parameters. For example the lines can be expressed by an intersection
-with a unit sphere centered at the given point. The most common
-parametrization describes a line by a point of intersection with a
-given viewport. Note that this parametrization accounts only for a
-%subset of lines that intersect the viewport (see Figure~\ref{fig:vfp}).
-
-%\begin{figure}[htb]
-%\centerline{
-%\includegraphics[width=0.6\textwidth,draft=\DRAFTFIGS]{figs/vfp}}
-%\caption{Visibility from a point. Lines intersecting a point can be described by a
-%  point of intersection with the given viewport.}
-%\label{fig:vfp}
-%\end{figure}
-
- In 3D the problem-relevant line set ${\cal L}_R$ is a 2D subset of
-the 4D line space. In 2D the ${\cal L}_R$ is a 1D subset of the 2D
-line space. The typical visibility from a point problem is the visible
-surface determination. Due to its importance the visible surface
-determination is covered by the majority of existing visibility
-algorithms. Other visibility from a point problem is the construction
-of the {\em visibility map} or the {\em point-to-region visibility}
-that classifies a region as visible, invisible, or partially visible
-with respect to the given point.
-
-
-\subsection{Visibility from a line segment}
-
- Lines intersecting a line segment in 3D can be described by three
-parameters. One parameter fixes the intersection of the line with the
-segment the other two express the direction of the line. The
-problem-relevant line set ${\cal L}_R$ is three-dimensional and it can
-be understood as a 2D cross section of ${\cal L}_R$  swept according
-to the translation on the given line segment (see
-%Figure~\ref{fig:vls}).
-
-
-%\begin{figure}[htb]
-%\centerline{
-%\includegraphics[width=0.8\textwidth,draft=\DRAFTFIGS]{figs/vls}}
-%\caption{Visibility from a line segment. (left) Line segment, a
-%  spherical object $O$, and its projections $O^*_0$, $O^*_{0.5}$, $O^*_{1}$
-%  with respect to the three points on the line segment. (right)
-%  A possible parametrization of lines that stacks up 2D planes.
-%  Each plane corresponds to mappings of lines intersecting a given
-%  point on the line segment.}
-%\label{fig:vls}
-%\end{figure}
-
-In 2D lines intersecting a line segment form a two-dimensional
-problem-relevant line set. Thus for the 2D case the ${\cal L}_R$ is a
-two-dimensional subset of 2D line space.
-
-
-\subsection{Visibility from a region}
-
- Visibility from a region (or from-region visibility) involves the
-most general visibility problems. In 3D the ${\cal L}_R$ is a 4D
-subset of the 4D line space. In 2D the ${\cal L}_R$ is a 2D subset of
-the 2D line space. Consequently, in the presented classification
-visibility from a region in 2D is equivalent to visibility from a line
-segment in 2D.
-
- A typical visibility from a region problem is the problem of {\em
-region-to-region} visibility that aims to determine if the two given
-regions in the scene are visible, invisible, or partially visible (see
-%Figure~\ref{fig:vfr}). Another visibility from region problem is the
-computation of a {\em potentially visible set} (PVS) with respect to a
-given view cell. The PVS consists of a set of objects that are
-potentially visible from any point inside the view cell. Further
-visibility from a region problems include computing form factors
-between two polygons, soft shadow algorithms or discontinuity meshing.
-
-
-%\begin{figure}[htb]
-%\centerline{
-%\includegraphics[width=0.6\textwidth,draft=\DRAFTFIGS]{figs/vfr}}
-%\caption{Visibility from a region --- an example of the region-to-region
-%  visibility. Two regions and two occluders $A$, $B$
-%  in a 2D scene.  In line space the region-to-region visibility can be
-%  solved by subtracting the sets of lines $A^*$ and $B^*$
-%  intersecting objects $A$ and $B$ from the lines intersecting both
-%  regions.}
-%\label{fig:vfr}
-%\end{figure}
-
-
-\subsection{Global visibility}
-
- According to the classification the global visibility problems can be
-seen as an extension of the from-region visibility problems. The
-dimension of the problem-relevant line set is the same ($k=2$ for 2D
-and $k=4$ for 3D scenes). Nevertheless, the global visibility problems
-typically deal with much larger set of rays, i.e.  all rays that
-penetrate the scene. Additionally, there is no given set of reference
-points from which visibility is studied and hence there is no given
-priority ordering of objects along each particular line from ${\cal
-L}_R$. Therefore an additional parameter must be used to describe
-visibility (visible object) along each ray.
-
-
-\subsection{Summary}
-
- The classification of visibility problems according to the dimension
-of the problem-relevant line set is summarized in
-Table~\ref{table:classification3D}.  This classification provides
-means for understanding how difficult it is to compute, describe, and
-maintain visibility for a particular class of problems. For example a
-data structure representing the visible or occluded parts of the scene
-for the visibility from a point problem needs to partition a 2D ${\cal
-L}_R$ into visible and occluded sets of lines. This observation
-conforms with the traditional visible surface algorithms -- they
-partition a 2D viewport into empty/nonempty regions and associate each
-nonempty regions (pixels) with a visible object. In this case the
-viewport represents the ${\cal L}_R$ as each point of the viewport
-corresponds to a line through that point. To analytically describe
-visibility from a region a subdivision of 4D ${\cal L}_R$ should be
-performed. This is much more difficult than the 2D
-subdivision. Moreover the description of visibility from a region
-involves non-linear subdivisions of both primal space and line space
-even for polygonal scenes~\cite{Teller:1992:CAA,Durand99-phd}.
-
-\begin{table*}[htb]
-\begin{small}
-\begin{center}
-\begin{tabular}{|l|c|l|}
-\hline
-\multicolumn{3}{|c|}{2D} \\
-\hline
-\mc{domain} & $d({\cal L}_R)$ & \mc{problems} \\
-\hline
-\hline
-\begin{tabular}{l}visibility along a line\end{tabular}         & 0 &  \begin{tabular}{l}ray shooting, point-to-point visibility\end{tabular}\\
-\hline
-\begin{tabular}{l}visibility from a point\end{tabular}         & 1 &  \begin{tabular}{l}view around a point, point-to-region visibility\end{tabular}\\
-\hline
-\begin{tabular}{l} visibility from a line segment \\ visibility from region \\ global visibility \end{tabular}
-   & 2 & \begin{tabular}{l} region-to-region visibility, PVS \end{tabular}\\
-\hline
-\hline
-\multicolumn{3}{|c|}{3D} \\
-\hline
-\mc{domain} & $d({\cal L}_R)$ & \mc{problems} \\
-\hline
-\hline
-\begin{tabular}{l}visibility along a line\end{tabular}  & 0 & \begin{tabular}{l} ray shooting, point-to-point visibility \end{tabular}\\
-\hline
-\begin{tabular}{l}from point in a surface\end{tabular}  & 1 & \begin{tabular}{l} see visibility from point in 2D \end{tabular}\\
-\hline
-\begin{tabular}{l}visibility from a point\end{tabular}  & 2 & \begin{tabular}{l} visible (hidden) surfaces, point-to-region visibility,\\
-                                      visibility map, hard shadows
-                               \end{tabular} \\
-\hline
-\begin{tabular}{l}visibility from a line segment\end{tabular} & 3 & \begin{tabular}{l} segment-to-region visibility (rare) \end{tabular}\\
-\hline
-\begin{tabular}{l}visibility from a region\\global visibility\end{tabular}       & 4 & \begin{tabular}{l} region-region visibility, PVS, aspect graph,\\
-                                            soft shadows, discontinuity meshing
-                                     \end{tabular} \\
-
-\hline  
-\end{tabular}
-\end{center}
-\end{small}
-\caption{Classification of visibility problems in 2D and 3D according
-to the dimension of the problem-relevant line set.}
-\label{table:classification3D}
-\end{table*}
-
-
-
-
-
-\section{Classification of visibility algorithms}
-
-
-The taxonomy of visibility problems groups similar visibility problems
-in the same class.  A visibility problem can be solved by means of
-various visibility algorithms. A visibility algorithm poses further
-restrictions on the input and output data. These restrictions can be
-seen as a more precise definition of the visibility problem that is
-solved by the algorithm.
-
- Above we classified visibility problems according to the problem
-domain and the desired answers. In this section we provide a
-classification of visibility algorithms according to other
-important criteria characterizing a particular visibility algorithm.
-
-
-\subsection{Scene restrictions}
-\label{sec:scene_restrictions}
-
-Visibility algorithms can be classified according to the restrictions
-they pose on the scene description.  The type of the scene description
-influences the difficulty of solving the given problem: it is simpler
-to implement an algorithm computing a visibility map for scenes
-consisting of triangles than for scenes with NURBS surfaces. We list
-common restrictions on the scene primitives suitable for visibility
-computations:
-
-
-\begin{itemize}
-\item
-  triangles, convex polygons, concave polygons,
-  
-\item
-  volumetric data,
-
-\item
-  points,
-
-\item
-  general parametric, implicit, or procedural surfaces.
-
-\end{itemize}
-
-Some attributes of scenes objects further increase the complexity of the visibility computation:
-
-\begin{itemize}
-
-\item
-  transparent objects,
-
-\item
-  dynamic objects.
-
-\end{itemize}
-
-The majority of analytic visibility algorithms deals with static
-polygonal scenes without transparency. The polygons are often
-subdivided into triangles for easier manipulation and representation.
-
-\subsection{Accuracy}
-\label{sec:accuracy}
-
- Visibility algorithms can be classified according to the accuracy of
-the result as:
-
-\begin{itemize}
-\item exact,
-\item conservative,
-\item aggressive,
-\item approximate.
-\end{itemize}
-
-
- An exact algorithm provides an exact analytic result for the given
-problem (in practice however this result is typically influenced by
-the finite precision of the floating point arithmetics). A
-conservative algorithm overestimates visibility, i.e. it never
-misses any visible object, surface or point. An aggressive algorithm
-always underestimates visibility, i.e. it never reports an invisible
-object, surface or point as visible.  An approximate algorithm
-provides only an approximation of the result, i.e. it can overestimate
-visibility for one input and underestimate visibility for another
-input.
-
- The classification according to the accuracy is best illustrated on
-computing PVS: an exact algorithm computes an exact PVS. A
-conservative algorithm computes a superset of the exact PVS.  An
-aggressive algorithm determines a subset of the exact PVS.  An
-approximate algorithm computes an approximation to the exact PVS that
-is neither its subset or its superset for all possible inputs.
-
- A more precise quality measure of algorithms computing PVSs can be
-expressed by the {\em relative overestimation} and the {\em relative
-underestimation} of the PVS with respect to the exact PVS.  We can
-define a quality measure of an algorithm $A$ on input $I$ as a tuple
-$\mbi{Q}^A(I)$:
-
-\begin{eqnarray}
-  \mbi{Q}^A(I) & = & (Q^A_o(I), Q^A_u(I)), \qquad  I \in {\cal D} \\
-  Q^A_o(I) & = & {|S^A(I) \setminus S^{\cal E}(I)| \over |S^{\cal E}(I)|} \\
-  Q^A_u(I) & = & {|S^{\cal E}(I) \setminus S^A(I) | \over |S^{\cal E}(I)|}
-\end{eqnarray}
-
-where $I$ is an input from the input domain ${\cal D}$, $S^A(I)$ is
-the PVS determined by the algorithm $A$ for input $I$ and $S^{\cal
-E}(I)$ is the exact PVS for the given input. $Q^A_o(I)$ expresses the
-{\em relative overestimation} of the PVS, $Q^A_u(I)$ is the {\em
-relative underestimation}.
-
-The expected quality of the algorithm over all possible inputs can be
-given as:
-
-\begin{eqnarray}
-Q^A & = & E[\| \mbi{Q}^A(I) \|] \\
-    & = & \sum_{\forall I \in {\cal D}} f(I).\sqrt{Q^A_o(I)^2 + Q^A_o(I)^2}
-\end{eqnarray}
-
-where f(I) is the probability density function expressing the
-probability of occurrence of input $I$. The quality measure
-$\mbi{Q}^A(I)$ can be used to classify a PVS algorithm into one of the
-four accuracy classes according to Section~\ref{sec:accuracy}:
-
-\begin{enumerate}
-\item exact\\
-  $\forall I \in {\cal D} :Q_o^A(I) = 0 \wedge Q_u^A(I) = 0$
-\item conservative\\
-  $\forall I \in {\cal D} : Q_o^A(I) \geq 0 \wedge Q_u^A(I) = 0$
-\item aggressive \\
-  $\forall I \in {\cal D} : Q_o^A(I) = 0 \wedge Q_u^A(I) \geq 0$
-\item approximate \\
-  $\qquad \exists I_j, I_k \in {\cal D}: Q_o^A(I_j) > 0 \wedge Q_u^A(I_k) > 0$
-\end{enumerate}
-
-
-
-\subsection{Solution space}
-
-\label{sec:solspace}
-
- The solution space is the domain in which the algorithm determines
-the desired result. Note that the solution space does not need to
-match the domain of the result.
-
-The algorithms can be classified as:
-
-\begin{itemize}
-  \item discrete,
-  \item continuous,
-  \item hybrid.
-\end{itemize}
-
- A discrete algorithm solves the problem using a discrete solution
-space; the solution is typically an approximation of the result. A
-continuous algorithm works in a continuous domain and often computes an
-analytic solution to the given problem. A hybrid algorithm uses both
-the discrete and the continuous solution space.
-
- The classification according to the solution space is easily
-demonstrated on visible surface algorithms: The
-z-buffer~\cite{Catmull:1975:CDC} is a common example of a discrete
-algorithm. The Weiler-Atherton algorithm~\cite{Weiler:1977:HSR} is an
-example of a continuous one. A hybrid solution space is used by
-scan-line algorithms that solve the problem in discrete steps
-(scan-lines) and for each step they provide a continuous solution
-(spans).
-
-Further classification reflects the semantics of the solution
-space. According to this criteria we can classify the algorithms as:
-
-\begin{itemize}
-  \item primal space (object space),
-  \item line space,
-    \begin{itemize}
-    \item image space,
-    \item general,
-    \end{itemize}
-  \item hybrid.
-\end{itemize}
-
- A primal space algorithm solves the problem by studying the
-visibility between objects without a transformation to a different
-solution space. A line space algorithm studies visibility using a
-transformation of the problem to line space. Image space algorithms
-can be seen as an important subclass of line space algorithms for
-solving visibility from a point problems in 3D. These algorithms cover
-all visible surface algorithms and many visibility culling
-algorithms. They solve visibility in a given image plane that
-represents the problem-relevant line set ${\cal L}_R$ --- each ray
-originating at the viewpoint corresponds to a point in the image plane.
-
- The described classification differs from the sometimes mentioned
-understanding of image space and object space algorithms that
-incorrectly considers all image space algorithms discrete and all
-object space algorithms continuous.
-
-
-%*****************************************************************************
-
-
-
-\section{Summary}
-
-The presented taxonomy classifies visibility problems independently of
-their target application. The classification should help to understand
-the nature of the given problem and it should assist in finding
-relationships between visibility problems and algorithms in different
-application areas.  The algorithms address the following classes of
-visibility problems:
-
-\begin{itemize}
-\item Visibility from a point in 3D $d({\cal L}_R)=2$.
-\item Global visibility in 3D $d({\cal L}_R)=4$.
-\item Visibility from a region in 3D, $d({\cal L}_R)=4$.
-\end{itemize}
-
- This chapter discussed several important criteria for the
-classification of visibility algorithms. This classification can be
-seen as a finer structuring of the taxonomy of visibility problems. We
-discussed important steps in the design of a visibility algorithm that
-should also assist in understanding the quality of a visibility
-algorithm. According to the classification the visibility algorithms
-described later in the report address algorithms with the following
-properties:
-
-\begin{itemize}
-\item Domain:
-  \begin{itemize}
-  \item viewpoint (online visibility culling),
-  \item global visibility (global visibility sampling)
-  \item polygon or polyhedron (mutual visibility verification)
-  \end{itemize}
-\item Scene restrictions (occluders):
-  \begin{itemize}
-  \item meshes consisting of convex polygons
-  \end{itemize}
-\item Scene restrictions (group objects):
-  \begin{itemize}
-  \item bounding boxes
-  \end{itemize}
-\item Output:
-  \begin{itemize}
-  \item PVS
-  \end{itemize}
-\item Accuracy:
-  \begin{itemize}
-  \item conservative
-  \item exact
-  \item aggresive
-  \end{itemize}
-\item Solution space:
-  \begin{itemize}
-  \item discrete (online visibility culling, global visibility sampling, conservative and approximate algorithm from the mutual visibility verification)
-  \item continuous (exact algorithm from mutual visibility verification)
-  \end{itemize}
-  \item Solution space data structures: viewport (online visibility culling), ray stack (global visibility sampling, conservative and approximate algorithm from the mutual visibility verification), BSP tree (exact algorithm from the mutual visibility verification)
-  \item Use of coherence of visibility:
-    \begin{itemize}
-    \item spatial coherence (all algorithms)
-    \item temporal coherence (online visibility culling)
-    \end{itemize}
-  \item Output sensitivity: expected in practice (all algorithms)
-  \item Acceleration data structure: kD-tree (all algorithms)
-  \item Use of graphics hardware: online visibility culling
-  \end{itemize}
-
-
Index: GTP/trunk/Lib/Vis/Preprocessing/manual/integration.txt
===================================================================
--- GTP/trunk/Lib/Vis/Preprocessing/manual/integration.txt	(revision 2066)
+++ 	(revision )
@@ -1,707 +1,0 @@
-
-
-
-\chapter{Introduction}%\chapter
-\label{chap:introduction}
-
-\section{Structure of the report}
-
-  The report consists of two introductory chapters, which provide a
- theoretical background for description of the algorithms, and three
- chapters dealing with the actual visibility algorithms.
-
-  This chapter provides an introduction to visibility by using a
- taxonomy of visibility problems and algorithms. The taxonomy is used
- to classify the later described visibility
- algorithms. Chapter~\ref{chap:analysis} provides an analysis of
- visibility in 2D and 3D polygonal scenes. This analysis also includes
- formal description of visibility using \plucker coordinates of
- lines. \plucker coordinates are exploited later in algorithms for
- mutual visibility verification (Chapter~\ref{chap:mutual}).
-
- Chapter~\ref{chap:online} describes a visibility culling algorithm
- used to implement the online visibility culling module. This
- algorithm can be used accelerate rendering of fully dynamic scenes
- using recent graphics hardware.  Chapter~\ref{chap:sampling}
- describes global visibility sampling algorithm which forms a core of
- the PVS computation module. This chapter also describes view space
- partitioning algorithms used in close relation with the PVS
- computation. Finally, Chapter~\ref{chap:mutual} describes mutual
- visibility verification algorithms, which are used by the PVS
- computation module to generate the final solution for precomputed
- visibility.
-
-
-
-
-%% summarize the state of the art
-%% visibility algorithms and their relation to the proposed taxonomy of
-%% visibility problems. The second part of the survey should serve as a
-%% catalogue of visibility algorithms that is indexed by the proposed
-%% taxonomy of visibility problems.
-
-
-
-\section{Domain of visibility problems}
-\label{sec:prob_domain}
-
- Computer graphics deals with visibility problems in the context of
-2D, \m25d, or 3D scenes. The actual problem domain is given by
-restricting the set of rays for which visibility should be
-determined.
-
-Below we list common problem domains used and the corresponding domain
-restrictions:
-
-\begin{enumerate}
-\item
-  {\em visibility along a line}
-  \begin{enumerate}
-  \item line
-  \item ray (origin + direction)
-  \end{enumerate}
-  \newpage
-\item
-  {\em visibility from a point} ({\em from-point visibility})
-  \begin{enumerate}
-  \item point
-  \item point + restricted set of rays
-    \begin{enumerate}
-    \item point + raster image (discrete form)
-    \item point + beam (continuous form)
-    \end{enumerate}
-  \end{enumerate}
-
-  
-\item
-  {\em visibility from a line segment} ({\em from-segment visibility})
-  \begin{enumerate}
-  \item line segment
-  \item line segment + restricted set of rays
-  \end{enumerate}
-  
-\item
-  {\em visibility from a polygon} ({\em from-polygon visibility})
-  \begin{enumerate}
-  \item polygon
-  \item polygon + restricted set of rays
-  \end{enumerate}
-  
-\item
-  {\em visibility from a region} ({\em from-region visibility})
-  \begin{enumerate}
-    \item region
-    \item region + restricted set of rays
-  \end{enumerate}
-
-\item
-  {\em global visibility}
-  \begin{enumerate}
-    \item no further input (all rays in the scene)
-    \item restricted set of rays
-  \end{enumerate}
-\end{enumerate}
-  
- The domain restrictions can be given independently of the dimension
-of the scene, but the impact of the restrictions differs depending on
-the scene dimension. For example, visibility from a polygon is
-equivalent to visibility from a (polygonal) region in 2D, but not in
-3D.
-
-%*****************************************************************************
-
-\section{Dimension of the problem-relevant line set}
-
- The six domains of visibility problems stated in
-Section~\ref{sec:prob_domain} can be characterized by the {\em
-problem-relevant line set} denoted ${\cal L}_R$. We give a
-classification of visibility problems according to the dimension of
-the problem-relevant line set. We discuss why this classification is
-important for understanding the nature of the given visibility problem
-and for identifying its relation to other problems.
-
-
- For the following discussion we assume that a line in {\em primal
-space} can be mapped to a point in {\em line space}. For purposes of
-the classification we define the line space as a vector space where a
-point corresponds to a line in the primal space\footnote{A classical
-mathematical definition says: Line space is a direct product of two
-Hilbert spaces~\cite{Weisstein:1999:CCE}. However, this definition
-differs from the common understanding of line space in computer
-graphics~\cite{Durand99-phd}}.
-
-
-
-\subsection{Parametrization of lines in 2D}
-
- There are two independent parameters that specify a 2D line and thus
-the corresponding set of lines is two-dimensional. There is a natural
-duality between lines and points in 2D. For example a line expressed
-as: $l:y=ax+c$ is dual to a point $p=(-c,a)$. This particular duality
-cannot handle vertical lines. %See Figure~\ref{fig:duality2d} for an
-example of other dual mappings in the plane.  To avoid the singularity
-in the mapping, a line $l:ax+by+c=0$ can be represented as a point
-$p_l=(a,b,c)$ in 2D projective space ${\cal
-P}^2$~\cite{Stolfi:1991:OPG}. Multiplying $p_l$ by a non-zero scalar
-we obtain a vector that represents the same line $l$. More details
-about this singularity-free mapping will be discussed in
-Chapter~\ref{chap:analysis}.
-
-
-%\begin{figure}[!htb]
-%\centerline{
-%\includegraphics[width=0.9\textwidth,draft=\DRAFTFIGS]{figs/duality2d}}
-%\caption{Duality between points and lines in 2D.}
-%\label{fig:duality2d}
-%\end{figure}
-
-
-
-
-
- To sum up: In 2D there are two degrees of freedom in description of a
-line and the corresponding line space is two-dimensional. The
-problem-relevant line set ${\cal L}_R$ then forms a $k$-dimensional
-subset of ${\cal P}^2$, where $0\leq k \leq 2$. An illustration of the
-concept of the problem-relevant line set is depicted in
-%Figure~\ref{fig:classes}.
-
-
-%\begin{figure}[htb]
-%\centerline{
-%\includegraphics[width=0.8\textwidth,draft=\DRAFTFIGS]{figs/classes}}
-%\caption{The problem-relevant set of lines in 2D. The ${\cal L}_R$ for
-%visibility along a line is formed by a single point that is a mapping
-%of the given line. The ${\cal L}_R$ for visibility from a point $p$ is
-%formed by points lying on a line. This line is a dual mapping of the
-%point $p$. ${\cal L}_R$ for visibility from a line segment is formed
-%by a 2D region bounded by dual mappings of endpoints of the given
-%segment.}
-%\label{fig:classes}
-%\end{figure}
-
-
-\subsection{Parametrization of lines in 3D}
-
-
-Lines in 3D form a four-parametric space~\cite{p-rsls-97}. A line
-intersecting a given scene can be described by two points on a sphere
-enclosing the scene. Since the surface of the sphere is a two
-parametric space, we need four parameters to describe the line.
-
- The {\em two plane parametrization} of 3D lines describes a line by
-points of intersection with the given two
-planes~\cite{Gu:1997:PGT}. This parametrization exhibits a singularity
-since it cannot describe lines parallel to these planes. See
-%Figure~\ref{fig:3dlines} for illustrations of the spherical and the
-two plane parameterizations.
-
-
-%\begin{figure}[htb]
-%\centerline{
-%\includegraphics[width=0.78\textwidth,draft=\DRAFTFIGS]{figs/3dlines}}
-%\caption{Parametrization of lines in 3D. (left) A line can be
-%  described by two points on a sphere enclosing the scene. (right) The
-%  two plane parametrization describes a line by point of intersection
-%  with two given planes.}
-%\label{fig:3dlines}
-%\end{figure}
-
- Another common parametrization of 3D lines are the {\em \plucker
-coordinates}. \plucker coordinates of an oriented 3D line are a six
-tuple that can be understood as a point in 5D oriented projective
-space~\cite{Stolfi:1991:OPG}. There are six coordinates in \plucker
-representation of a line although we know that the ${\cal L}_R$ is
-four-dimensional. This can be explained as follows:
-
-\begin{itemize}
-  \item Firstly, \plucker coordinates are {\em homogeneous
-    coordinates} of a 5D point. By multiplication of the coordinates
-    by any positive scalar we get a mapping of the same line.
-  \item Secondly, only 4D subset of the 5D oriented projective space
-  corresponds to real lines. This subset is a 4D ruled quadric called
-  the {\em \plucker quadric} or the {\em Grassman
-  manifold}~\cite{Stolfi:1991:OPG,Pu98-DSGIV}.
-\end{itemize}
-
- Although the \plucker coordinates need more coefficients they have no
-singularity and preserve some linearities: lines intersecting a set of
-lines in 3D correspond to an intersection of 5D hyperplanes. More
-details on \plucker coordinates will be discussed in
-Chapter~\ref{chap:analysis} and Chapter~\ref{chap:mutual} where they
-are used to solve the from-region visibility problem.
-
-  To sum up: In 3D there are four degrees of freedom in the
-description of a line and thus the corresponding line space is
-four-dimensional. Fixing certain line parameters (e.g. direction) the
-problem-relevant line set, denoted ${\cal L}_R$, forms a
-$k$-dimensional subset of ${\cal P}^4$, where $0\leq k \leq 4$.
-
-
-\subsection{Visibility along a line}
-
- The simplest visibility problems deal with visibility along a single
-line. The problem-relevant line set is zero-dimensional, i.e. it is
-fully specified by the given line. A typical example of a visibility
-along a line problem is {\em ray shooting}.
-
- A similar problem to ray shooting is the {\em point-to-point}
-visibility.  The  point-to-point visibility determines whether the
-line segment between two points is occluded, i.e. it has an
-intersection with an opaque object in the scene. Point-to-point
-visibility provides a visibility classification (answer 1a), whereas
-ray shooting determines a visible object (answer 2a) and/or a point of
-intersection (answer 3a). Note that the {\em point-to-point}
-visibility can be solved easily by means of ray shooting. Another
-constructive visibility along a line problem is determining the {\em
-%maximal free line segments} on a given line. See Figure~\ref{fig:val}
-for an illustration of typical visibility along a line problems.
-
-%\begin{figure}[htb]
-%\centerline{
-%\includegraphics[width=0.85\textwidth,draft=\DRAFTFIGS]{figs/val}}
-%\caption{Visibility along a line. (left) Ray shooting. (center) Point-to-point visibility. (right) Maximal free line segments between two points.}
-%\label{fig:val}
-%\end{figure}
-
-
-\subsection{Visibility from a point}
-
- Lines intersecting a point in 3D can be described  by two
-parameters. For example the lines can be expressed by an intersection
-with a unit sphere centered at the given point. The most common
-parametrization describes a line by a point of intersection with a
-given viewport. Note that this parametrization accounts only for a
-%subset of lines that intersect the viewport (see Figure~\ref{fig:vfp}).
-
-%\begin{figure}[htb]
-%\centerline{
-%\includegraphics[width=0.6\textwidth,draft=\DRAFTFIGS]{figs/vfp}}
-%\caption{Visibility from a point. Lines intersecting a point can be described by a
-%  point of intersection with the given viewport.}
-%\label{fig:vfp}
-%\end{figure}
-
- In 3D the problem-relevant line set ${\cal L}_R$ is a 2D subset of
-the 4D line space. In 2D the ${\cal L}_R$ is a 1D subset of the 2D
-line space. The typical visibility from a point problem is the visible
-surface determination. Due to its importance the visible surface
-determination is covered by the majority of existing visibility
-algorithms. Other visibility from a point problem is the construction
-of the {\em visibility map} or the {\em point-to-region visibility}
-that classifies a region as visible, invisible, or partially visible
-with respect to the given point.
-
-
-\subsection{Visibility from a line segment}
-
- Lines intersecting a line segment in 3D can be described by three
-parameters. One parameter fixes the intersection of the line with the
-segment the other two express the direction of the line. The
-problem-relevant line set ${\cal L}_R$ is three-dimensional and it can
-be understood as a 2D cross section of ${\cal L}_R$  swept according
-to the translation on the given line segment (see
-%Figure~\ref{fig:vls}).
-
-
-%\begin{figure}[htb]
-%\centerline{
-%\includegraphics[width=0.8\textwidth,draft=\DRAFTFIGS]{figs/vls}}
-%\caption{Visibility from a line segment. (left) Line segment, a
-%  spherical object $O$, and its projections $O^*_0$, $O^*_{0.5}$, $O^*_{1}$
-%  with respect to the three points on the line segment. (right)
-%  A possible parametrization of lines that stacks up 2D planes.
-%  Each plane corresponds to mappings of lines intersecting a given
-%  point on the line segment.}
-%\label{fig:vls}
-%\end{figure}
-
-In 2D lines intersecting a line segment form a two-dimensional
-problem-relevant line set. Thus for the 2D case the ${\cal L}_R$ is a
-two-dimensional subset of 2D line space.
-
-
-\subsection{Visibility from a region}
-
- Visibility from a region (or from-region visibility) involves the
-most general visibility problems. In 3D the ${\cal L}_R$ is a 4D
-subset of the 4D line space. In 2D the ${\cal L}_R$ is a 2D subset of
-the 2D line space. Consequently, in the presented classification
-visibility from a region in 2D is equivalent to visibility from a line
-segment in 2D.
-
- A typical visibility from a region problem is the problem of {\em
-region-to-region} visibility that aims to determine if the two given
-regions in the scene are visible, invisible, or partially visible (see
-%Figure~\ref{fig:vfr}). Another visibility from region problem is the
-computation of a {\em potentially visible set} (PVS) with respect to a
-given view cell. The PVS consists of a set of objects that are
-potentially visible from any point inside the view cell. Further
-visibility from a region problems include computing form factors
-between two polygons, soft shadow algorithms or discontinuity meshing.
-
-
-%\begin{figure}[htb]
-%\centerline{
-%\includegraphics[width=0.6\textwidth,draft=\DRAFTFIGS]{figs/vfr}}
-%\caption{Visibility from a region --- an example of the region-to-region
-%  visibility. Two regions and two occluders $A$, $B$
-%  in a 2D scene.  In line space the region-to-region visibility can be
-%  solved by subtracting the sets of lines $A^*$ and $B^*$
-%  intersecting objects $A$ and $B$ from the lines intersecting both
-%  regions.}
-%\label{fig:vfr}
-%\end{figure}
-
-
-\subsection{Global visibility}
-
- According to the classification the global visibility problems can be
-seen as an extension of the from-region visibility problems. The
-dimension of the problem-relevant line set is the same ($k=2$ for 2D
-and $k=4$ for 3D scenes). Nevertheless, the global visibility problems
-typically deal with much larger set of rays, i.e.  all rays that
-penetrate the scene. Additionally, there is no given set of reference
-points from which visibility is studied and hence there is no given
-priority ordering of objects along each particular line from ${\cal
-L}_R$. Therefore an additional parameter must be used to describe
-visibility (visible object) along each ray.
-
-
-\subsection{Summary}
-
- The classification of visibility problems according to the dimension
-of the problem-relevant line set is summarized in
-Table~\ref{table:classification3D}.  This classification provides
-means for understanding how difficult it is to compute, describe, and
-maintain visibility for a particular class of problems. For example a
-data structure representing the visible or occluded parts of the scene
-for the visibility from a point problem needs to partition a 2D ${\cal
-L}_R$ into visible and occluded sets of lines. This observation
-conforms with the traditional visible surface algorithms -- they
-partition a 2D viewport into empty/nonempty regions and associate each
-nonempty regions (pixels) with a visible object. In this case the
-viewport represents the ${\cal L}_R$ as each point of the viewport
-corresponds to a line through that point. To analytically describe
-visibility from a region a subdivision of 4D ${\cal L}_R$ should be
-performed. This is much more difficult than the 2D
-subdivision. Moreover the description of visibility from a region
-involves non-linear subdivisions of both primal space and line space
-even for polygonal scenes~\cite{Teller:1992:CAA,Durand99-phd}.
-
-\begin{table*}[htb]
-\begin{small}
-\begin{center}
-\begin{tabular}{|l|c|l|}
-\hline
-\multicolumn{3}{|c|}{2D} \\
-\hline
-\mc{domain} & $d({\cal L}_R)$ & \mc{problems} \\
-\hline
-\hline
-\begin{tabular}{l}visibility along a line\end{tabular}         & 0 &  \begin{tabular}{l}ray shooting, point-to-point visibility\end{tabular}\\
-\hline
-\begin{tabular}{l}visibility from a point\end{tabular}         & 1 &  \begin{tabular}{l}view around a point, point-to-region visibility\end{tabular}\\
-\hline
-\begin{tabular}{l} visibility from a line segment \\ visibility from region \\ global visibility \end{tabular}
-   & 2 & \begin{tabular}{l} region-to-region visibility, PVS \end{tabular}\\
-\hline
-\hline
-\multicolumn{3}{|c|}{3D} \\
-\hline
-\mc{domain} & $d({\cal L}_R)$ & \mc{problems} \\
-\hline
-\hline
-\begin{tabular}{l}visibility along a line\end{tabular}  & 0 & \begin{tabular}{l} ray shooting, point-to-point visibility \end{tabular}\\
-\hline
-\begin{tabular}{l}from point in a surface\end{tabular}  & 1 & \begin{tabular}{l} see visibility from point in 2D \end{tabular}\\
-\hline
-\begin{tabular}{l}visibility from a point\end{tabular}  & 2 & \begin{tabular}{l} visible (hidden) surfaces, point-to-region visibility,\\
-                                      visibility map, hard shadows
-                               \end{tabular} \\
-\hline
-\begin{tabular}{l}visibility from a line segment\end{tabular} & 3 & \begin{tabular}{l} segment-to-region visibility (rare) \end{tabular}\\
-\hline
-\begin{tabular}{l}visibility from a region\\global visibility\end{tabular}       & 4 & \begin{tabular}{l} region-region visibility, PVS, aspect graph,\\
-                                            soft shadows, discontinuity meshing
-                                     \end{tabular} \\
-
-\hline  
-\end{tabular}
-\end{center}
-\end{small}
-\caption{Classification of visibility problems in 2D and 3D according
-to the dimension of the problem-relevant line set.}
-\label{table:classification3D}
-\end{table*}
-
-
-
-
-
-\section{Classification of visibility algorithms}
-
-
-The taxonomy of visibility problems groups similar visibility problems
-in the same class.  A visibility problem can be solved by means of
-various visibility algorithms. A visibility algorithm poses further
-restrictions on the input and output data. These restrictions can be
-seen as a more precise definition of the visibility problem that is
-solved by the algorithm.
-
- Above we classified visibility problems according to the problem
-domain and the desired answers. In this section we provide a
-classification of visibility algorithms according to other
-important criteria characterizing a particular visibility algorithm.
-
-
-\subsection{Scene restrictions}
-\label{sec:scene_restrictions}
-
-Visibility algorithms can be classified according to the restrictions
-they pose on the scene description.  The type of the scene description
-influences the difficulty of solving the given problem: it is simpler
-to implement an algorithm computing a visibility map for scenes
-consisting of triangles than for scenes with NURBS surfaces. We list
-common restrictions on the scene primitives suitable for visibility
-computations:
-
-
-\begin{itemize}
-\item
-  triangles, convex polygons, concave polygons,
-  
-\item
-  volumetric data,
-
-\item
-  points,
-
-\item
-  general parametric, implicit, or procedural surfaces.
-
-\end{itemize}
-
-Some attributes of scenes objects further increase the complexity of the visibility computation:
-
-\begin{itemize}
-
-\item
-  transparent objects,
-
-\item
-  dynamic objects.
-
-\end{itemize}
-
-The majority of analytic visibility algorithms deals with static
-polygonal scenes without transparency. The polygons are often
-subdivided into triangles for easier manipulation and representation.
-
-\subsection{Accuracy}
-\label{sec:accuracy}
-
- Visibility algorithms can be classified according to the accuracy of
-the result as:
-
-\begin{itemize}
-\item exact,
-\item conservative,
-\item aggressive,
-\item approximate.
-\end{itemize}
-
-
- An exact algorithm provides an exact analytic result for the given
-problem (in practice however this result is typically influenced by
-the finite precision of the floating point arithmetics). A
-conservative algorithm overestimates visibility, i.e. it never
-misses any visible object, surface or point. An aggressive algorithm
-always underestimates visibility, i.e. it never reports an invisible
-object, surface or point as visible.  An approximate algorithm
-provides only an approximation of the result, i.e. it can overestimate
-visibility for one input and underestimate visibility for another
-input.
-
- The classification according to the accuracy is best illustrated on
-computing PVS: an exact algorithm computes an exact PVS. A
-conservative algorithm computes a superset of the exact PVS.  An
-aggressive algorithm determines a subset of the exact PVS.  An
-approximate algorithm computes an approximation to the exact PVS that
-is neither its subset or its superset for all possible inputs.
-
- A more precise quality measure of algorithms computing PVSs can be
-expressed by the {\em relative overestimation} and the {\em relative
-underestimation} of the PVS with respect to the exact PVS.  We can
-define a quality measure of an algorithm $A$ on input $I$ as a tuple
-$\mbi{Q}^A(I)$:
-
-\begin{eqnarray}
-  \mbi{Q}^A(I) & = & (Q^A_o(I), Q^A_u(I)), \qquad  I \in {\cal D} \\
-  Q^A_o(I) & = & {|S^A(I) \setminus S^{\cal E}(I)| \over |S^{\cal E}(I)|} \\
-  Q^A_u(I) & = & {|S^{\cal E}(I) \setminus S^A(I) | \over |S^{\cal E}(I)|}
-\end{eqnarray}
-
-where $I$ is an input from the input domain ${\cal D}$, $S^A(I)$ is
-the PVS determined by the algorithm $A$ for input $I$ and $S^{\cal
-E}(I)$ is the exact PVS for the given input. $Q^A_o(I)$ expresses the
-{\em relative overestimation} of the PVS, $Q^A_u(I)$ is the {\em
-relative underestimation}.
-
-The expected quality of the algorithm over all possible inputs can be
-given as:
-
-\begin{eqnarray}
-Q^A & = & E[\| \mbi{Q}^A(I) \|] \\
-    & = & \sum_{\forall I \in {\cal D}} f(I).\sqrt{Q^A_o(I)^2 + Q^A_o(I)^2}
-\end{eqnarray}
-
-where f(I) is the probability density function expressing the
-probability of occurrence of input $I$. The quality measure
-$\mbi{Q}^A(I)$ can be used to classify a PVS algorithm into one of the
-four accuracy classes according to Section~\ref{sec:accuracy}:
-
-\begin{enumerate}
-\item exact\\
-  $\forall I \in {\cal D} :Q_o^A(I) = 0 \wedge Q_u^A(I) = 0$
-\item conservative\\
-  $\forall I \in {\cal D} : Q_o^A(I) \geq 0 \wedge Q_u^A(I) = 0$
-\item aggressive \\
-  $\forall I \in {\cal D} : Q_o^A(I) = 0 \wedge Q_u^A(I) \geq 0$
-\item approximate \\
-  $\qquad \exists I_j, I_k \in {\cal D}: Q_o^A(I_j) > 0 \wedge Q_u^A(I_k) > 0$
-\end{enumerate}
-
-
-
-\subsection{Solution space}
-
-\label{sec:solspace}
-
- The solution space is the domain in which the algorithm determines
-the desired result. Note that the solution space does not need to
-match the domain of the result.
-
-The algorithms can be classified as:
-
-\begin{itemize}
-  \item discrete,
-  \item continuous,
-  \item hybrid.
-\end{itemize}
-
- A discrete algorithm solves the problem using a discrete solution
-space; the solution is typically an approximation of the result. A
-continuous algorithm works in a continuous domain and often computes an
-analytic solution to the given problem. A hybrid algorithm uses both
-the discrete and the continuous solution space.
-
- The classification according to the solution space is easily
-demonstrated on visible surface algorithms: The
-z-buffer~\cite{Catmull:1975:CDC} is a common example of a discrete
-algorithm. The Weiler-Atherton algorithm~\cite{Weiler:1977:HSR} is an
-example of a continuous one. A hybrid solution space is used by
-scan-line algorithms that solve the problem in discrete steps
-(scan-lines) and for each step they provide a continuous solution
-(spans).
-
-Further classification reflects the semantics of the solution
-space. According to this criteria we can classify the algorithms as:
-
-\begin{itemize}
-  \item primal space (object space),
-  \item line space,
-    \begin{itemize}
-    \item image space,
-    \item general,
-    \end{itemize}
-  \item hybrid.
-\end{itemize}
-
- A primal space algorithm solves the problem by studying the
-visibility between objects without a transformation to a different
-solution space. A line space algorithm studies visibility using a
-transformation of the problem to line space. Image space algorithms
-can be seen as an important subclass of line space algorithms for
-solving visibility from a point problems in 3D. These algorithms cover
-all visible surface algorithms and many visibility culling
-algorithms. They solve visibility in a given image plane that
-represents the problem-relevant line set ${\cal L}_R$ --- each ray
-originating at the viewpoint corresponds to a point in the image plane.
-
- The described classification differs from the sometimes mentioned
-understanding of image space and object space algorithms that
-incorrectly considers all image space algorithms discrete and all
-object space algorithms continuous.
-
-
-%*****************************************************************************
-
-
-
-\section{Summary}
-
-The presented taxonomy classifies visibility problems independently of
-their target application. The classification should help to understand
-the nature of the given problem and it should assist in finding
-relationships between visibility problems and algorithms in different
-application areas.  The algorithms address the following classes of
-visibility problems:
-
-\begin{itemize}
-\item Visibility from a point in 3D $d({\cal L}_R)=2$.
-\item Global visibility in 3D $d({\cal L}_R)=4$.
-\item Visibility from a region in 3D, $d({\cal L}_R)=4$.
-\end{itemize}
-
- This chapter discussed several important criteria for the
-classification of visibility algorithms. This classification can be
-seen as a finer structuring of the taxonomy of visibility problems. We
-discussed important steps in the design of a visibility algorithm that
-should also assist in understanding the quality of a visibility
-algorithm. According to the classification the visibility algorithms
-described later in the report address algorithms with the following
-properties:
-
-\begin{itemize}
-\item Domain:
-  \begin{itemize}
-  \item viewpoint (online visibility culling),
-  \item global visibility (global visibility sampling)
-  \item polygon or polyhedron (mutual visibility verification)
-  \end{itemize}
-\item Scene restrictions (occluders):
-  \begin{itemize}
-  \item meshes consisting of convex polygons
-  \end{itemize}
-\item Scene restrictions (group objects):
-  \begin{itemize}
-  \item bounding boxes
-  \end{itemize}
-\item Output:
-  \begin{itemize}
-  \item PVS
-  \end{itemize}
-\item Accuracy:
-  \begin{itemize}
-  \item conservative
-  \item exact
-  \item aggresive
-  \end{itemize}
-\item Solution space:
-  \begin{itemize}
-  \item discrete (online visibility culling, global visibility sampling, conservative and approximate algorithm from the mutual visibility verification)
-  \item continuous (exact algorithm from mutual visibility verification)
-  \end{itemize}
-  \item Solution space data structures: viewport (online visibility culling), ray stack (global visibility sampling, conservative and approximate algorithm from the mutual visibility verification), BSP tree (exact algorithm from the mutual visibility verification)
-  \item Use of coherence of visibility:
-    \begin{itemize}
-    \item spatial coherence (all algorithms)
-    \item temporal coherence (online visibility culling)
-    \end{itemize}
-  \item Output sensitivity: expected in practice (all algorithms)
-  \item Acceleration data structure: kD-tree (all algorithms)
-  \item Use of graphics hardware: online visibility culling
-  \end{itemize}
-
-
Index: GTP/trunk/Lib/Vis/Preprocessing/manual/introduction.aux
===================================================================
--- GTP/trunk/Lib/Vis/Preprocessing/manual/introduction.aux	(revision 2066)
+++ 	(revision )
@@ -1,60 +1,0 @@
-\relax 
-\@writefile{toc}{\contentsline {chapter}{\numberline {1}Introduction}{2}}
-\@writefile{lof}{\addvspace {10\p@ }}
-\@writefile{lot}{\addvspace {10\p@ }}
-\newlabel{chap:introduction}{{1}{2}}
-\@writefile{toc}{\contentsline {section}{\numberline {1.1}Structure of the report}{2}}
-\@writefile{toc}{\contentsline {section}{\numberline {1.2}Domain of visibility problems}{2}}
-\newlabel{sec:prob_domain}{{1.2}{2}}
-\citation{Weisstein:1999:CCE}
-\citation{Durand99-phd}
-\citation{Stolfi:1991:OPG}
-\citation{p-rsls-97}
-\@writefile{toc}{\contentsline {section}{\numberline {1.3}Dimension of the problem-relevant line set}{3}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {1.3.1}Parametrization of lines in 2D}{3}}
-\citation{Gu:1997:PGT}
-\citation{Stolfi:1991:OPG}
-\citation{Stolfi:1991:OPG}
-\citation{Pu98-DSGIV}
-\@writefile{toc}{\contentsline {subsection}{\numberline {1.3.2}Parametrization of lines in 3D}{4}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {1.3.3}Visibility along a line}{4}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {1.3.4}Visibility from a point}{4}}
-\citation{Teller:1992:CAA}
-\citation{Durand99-phd}
-\@writefile{toc}{\contentsline {subsection}{\numberline {1.3.5}Visibility from a line segment}{5}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {1.3.6}Visibility from a region}{5}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {1.3.7}Global visibility}{5}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {1.3.8}Summary}{5}}
-\@writefile{toc}{\contentsline {section}{\numberline {1.4}Classification of visibility algorithms}{5}}
-\@writefile{lot}{\contentsline {table}{\numberline {1.1}{\ignorespaces Classification of visibility problems in 2D and 3D according to the dimension of the problem-relevant line set.}}{6}}
-\newlabel{table:classification3D}{{1.1}{6}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {1.4.1}Scene restrictions}{6}}
-\newlabel{sec:scene_restrictions}{{1.4.1}{6}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {1.4.2}Accuracy}{6}}
-\newlabel{sec:accuracy}{{1.4.2}{6}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {1.4.3}Solution space}{7}}
-\newlabel{sec:solspace}{{1.4.3}{7}}
-\citation{Catmull:1975:CDC}
-\citation{Weiler:1977:HSR}
-\@writefile{toc}{\contentsline {section}{\numberline {1.5}Summary}{8}}
-\@setckpt{introduction}{
-\setcounter{page}{10}
-\setcounter{equation}{5}
-\setcounter{enumi}{4}
-\setcounter{enumii}{2}
-\setcounter{enumiii}{2}
-\setcounter{enumiv}{0}
-\setcounter{footnote}{1}
-\setcounter{mpfootnote}{0}
-\setcounter{part}{0}
-\setcounter{chapter}{1}
-\setcounter{section}{5}
-\setcounter{subsection}{0}
-\setcounter{subsubsection}{0}
-\setcounter{paragraph}{0}
-\setcounter{subparagraph}{0}
-\setcounter{figure}{0}
-\setcounter{table}{1}
-\setcounter{float@type}{4}
-\setcounter{r@tfl@t}{0}
-}
