Ogre 場景管理

每個3D引擎都會用scene graph 來組織它的可渲染對象。scene graph　總是會為了更快地搜索與查詢做
優化，提供給用戶查找目標對象附近特定對象的功能，允許查找，排序，剔除多邊形，以實現更高效的渲染。偶爾，scene graph也用于碰撞檢測。有時，一個單獨的scene graph可被用于程序中的所有子系統，包括
音效與物理。
Ogre使用插件機制來實現場景管理功能。ScenceManager只是接口，他可以有很多具體的實現。Ogre允許
在同一時刻同一場景中使用多個Scene Manager,這樣在不同的場景類型切換時帶來好處。

場景管理器的責任
1，創建，放置場景中的可移動對象，light,camera，并可以在圖形遍歷中有效地訪問它們。
2，加載，裝配world geometry(它通常很大，向四處延伸，不可移動）
3，完成場景查詢，例如可以回答這樣的問題：在世界空間的特定點畫一個球體，它會包含哪些對象？
4，剔除不可見對象，把可見對象放入渲染隊列進行渲染
5，從當前可渲染的透視圖中組織，揀選各方向光照
6，設置，渲染場景中的所有陰影
7　設置，渲染場景中的其他對象（如背景，天空盒）
8　傳遞組織良好的內容到渲染系統進行渲染

場景管理器類型

以分析源碼的方式討論一下插件的加載機制與特定場景管理器是如何進行運用的。
上一章提到了以手工的方式初始化ogre,包括手工加載場景管理器：
root->loadPlugin("Plugin_OctreeSceneManager");
其實所謂的自動方式下，Root:Root()中也會間接調用到loadPlugin()方法，這已在前面的筆記
(配置文件Plugins.cfg )中提到過。既然特定管理器以插件的形式（dll文件）給出，下面先看如何
加載dll. 進入源碼：標號表明執行順序。
void Root::loadPlugin(const String& pluginName)
?{
?// Load plugin library
　　　 DynLib* lib = DynLibManager::getSingleton().load( pluginName ); //(1)
??// Store for later unload
?mPluginLibs.push_back(lib); //(4)
?// Call startup function
　　　　DLL_START_PLUGIN pFunc = (DLL_START_PLUGIN)lib->getSymbol("dllStartPlugin"); //(5)
?// This must call installPlugin
?pFunc(); //(6)

?}
DynLib* DynLibManager::load( const String& filename)? //(2)
{
??????? DynLib* pLib = new DynLib(filename);
?pLib->load();???????
?????? ?mLibList[filename] = pLib;
?return pLib;
}
void DynLib::load() //(3)
{
m_hInst = (DYNLIB_HANDLE)DYNLIB_LOAD( name.c_str() );
}
第(3)中的宏定義如下：
#if OGRE_PLATFORM == OGRE_PLATFORM_WIN32
#??? define DYNLIB_HANDLE hInstance
#??? define DYNLIB_LOAD( a ) LoadLibrary( a )
到此，DLL被加載到內存,第(4)步，mPluginLibs是個STL容器，它存放動態庫指針。
第(5)步，進入源碼可以看到
void* DynLib::getSymbol( const String& strName ) const throw()
??? {
??????? return (void*)DYNLIB_GETSYM( m_hInst, strName.c_str() );
??? }
其中宏定義：define DYNLIB_GETSYM( a, b ) GetProcAddress( a, b )，很顯然，它取得一個名為
dllStartPlugin的函數指針：不防再看看宏定義： typedef void (*DLL_START_PLUGIN)(void);
說明DLL_START_PLUGIN為參數為空，返回值為空的函數指針。
每個注冊到ogre的dll都實現了這個約定函數。對于我們當前討論的場景管理器Plugin_OctreeSceneManager
來講，我們可以找到其相應的定義:它在第(6)步中執行

OctreePlugin* octreePlugin;
extern "C" void _OgreOctreePluginExport dllStartPlugin( void )
{
??? // Create new scene manager
??? octreePlugin = new OctreePlugin();　//(6-1)

??? // Register
??? Root::getSingleton().installPlugin(octreePlugin); //(6-2)

}
程序執行到(6-1)步，new 來一個OctreePlugin,我們看一下它的定義：
class OctreePlugin : public Plugin
{
?public:
??OctreePlugin();
??const String& getName() const;
??void install();
???void initialise();
???void shutdown();
???void uninstall();
?protected:
??OctreeSceneManagerFactory* mOctreeSMFactory;
??TerrainSceneManagerFactory* mTerrainSMFactory;
??TerrainPageSourceListenerManager* mTerrainPSListenerManager;

};

我們會注意到它包含兩個工廠類指針:OctreeSceneManagerFactory,TerrainSceneManagerFactory
他們就是用來生產特定ScenManager的，稍后討論。先看(6-2)步：
void Root::installPlugin(Plugin* plugin)
{
?mPlugins.push_back(plugin);　　//(6-2-1)
?plugin->install();???????????? //(6-2-2)
?// if rendersystem is already initialised, call rendersystem init too
?if (mIsInitialised)
?{
?plugin->initialise();???????? //(6-2-3)
?}
}
//(6-2-1)步把插件放到容器中。看看(6-2-2)做了什么：
void OctreePlugin::install()
?{
??// Create objects
??mOctreeSMFactory = new OctreeSceneManagerFactory();
??mTerrainSMFactory = new TerrainSceneManagerFactory();
??mTerrainPSListenerManager = new TerrainPageSourceListenerManager();

?}
呵，剛才還說兩個工廠類指針，現在把兩個工廠建起來，以后可以用來生產東西了。
繼續看看(6-2-3):
void OctreePlugin::initialise()
?{
??// Register
??Root::getSingleton().addSceneManagerFactory(mOctreeSMFactory);
??Root::getSingleton().addSceneManagerFactory(mTerrainSMFactory);
?}
哦，把這兩個工廠注冊到Root中，讓Root可以使用它們。啊這句話有點問題，Root只是間接的用到，
直接雇主是 SceneManagerEnumerator* mSceneManagerEnum;它被包含在Root中。于是我們可以看到
void Root::addSceneManagerFactory(SceneManagerFactory* fact) //(6-2-3-1)
?{
??mSceneManagerEnum->addFactory(fact);
?}

工廠已經有了，我們如何利用這個工廠生產出我們想到的東西(SceneManager)呢？
回憶上一章的手工初始化過程中，我們一般用以下語句來創建SceneManager:
? SceneManager *sceneMgr = root->createSceneManager(ST_GENERIC); //(A)
也可以這樣用
? sceneMgr = ogre->createSceneManager("OctreeSceneManager"); //(B)
每個工廠類都用一個字符串表示其類型。上面說的兩個工廠分別使用的字符串為：“TerrainSceneManager”，"OctreeSceneManager"
(A)語句肯定會調用工廠類的方法來產生實際的SceneManager,下面看源碼驗證一下：
SceneManager* Root::createSceneManager(const String& typeName,
??const String& instanceName)
?{
??return mSceneManagerEnum->createSceneManager(typeName, instanceName);
?}
繼續挖：
SceneManager* SceneManagerEnumerator::createSceneManager(
??const String& typeName, const String& instanceName)
?{
??SceneManager* inst = 0;
??for(Factories::iterator i = mFactories.begin(); i != mFactories.end(); ++i)
??{
???if ((*i)->getMetaData().typeName == typeName)
???{
????if (instanceName.empty())
????{
?????// generate a name
?????StringUtil::StrStreamType s;
?????s << "SceneManagerInstance" << ++mInstanceCreateCount;
?????inst = (*i)->createInstance(s.str());
????}
????else
????{
?????inst = (*i)->createInstance(instanceName);
????}
????break;
???}
??}
?}
上述代碼很簡單：因為執行(6-2-3-1)已經過實際工廠類實例進行了注冊。于是遍歷每個工廠實例，
找到類型相符的。找到之后，如果沒有傳場景管理器實例的名字，就起個名字。然后用這個名字
生產出一個實例來。CreateInstance沒干什么，new　唄。
SceneManager* OctreeSceneManagerFactory::createInstance(
?const String& instanceName)
{
?return new OctreeSceneManager(instanceName);
}
就是這樣。OctreeSceneManager and TerrainSceneManager 的功能都是由一個DLL提供的。它們的關系是：class _OgreOctreePluginExport TerrainSceneManager : public OctreeSceneManager，按照一般的類關系邏輯，
我們知道派生類一般功能都比父類強大，父類應用于一般場景，子類針對特定場景。這個邏輯在這里是對的。本來是寫讀書筆記，跑題了，打住。

?

?

?

?

?

?

?

?

?

?

?

?