More on Scene Management

More on Scene Management

僅供個人學習使用，請勿轉載，勿用於任何商業用途。

     相信很多人都看過Tom Forsyth那篇著名的文章<<Scene Graph – just say no>>。我第一次看時，只覺得是Tom開的一個小玩笑。不過最近，隨著對scene management研究的深入，感覺對於大多數遊戲來說，scene graph確實不是那麼必須。

      由於scene graph實在是一個被嚴重濫用和誤用的詞，雖然以前的文章介紹過scene graph，為了避免不必要的誤解，再次列出關於SG的概念：純粹的SG只用來描述情境中物體間的空間邏輯關係而不是簡單的空間關係。如果SG中包含任何的quadtree/octree, bsp等空間資料結構，那麼這肯定不是一個SG；不應該使用SG進行裁剪或者碰撞檢測。簡單來說，SG就是一棵n叉熟。

      遊戲中什麼對象需要描述空間邏輯關係呢？顯然，對於靜態物體來說是沒有必要的，即使它包含空間邏輯關係，但由於本身“不會移動”的特性，可以在載入這個物體時就預計算出它的絕對全局座標。對於可移動物體，骨骼動畫顯然是最適合用SG來描述的，比如人物身體各部分之間的移動關係。不過更常見的情況是把同一骨骼下的物體作為一個整體，並用一個特殊的內部結構來描述其空間邏輯關係。比如整個人物是一個model對象，身體每個部份是model內的subMesh對象（類似Ogre裡Entity和SubEntity的關係）。

     仔細想想，遊戲中似乎只有幾種情況下可能需要使用scene graph，以wow為例：1，人物身上可附加的裝備，比如劍，帽子；2，當人物騎到坐騎上；3，跟隨某個角色移動。目前為止，我只想到這3點。

     我現在的設計中，SG非常簡單，只包含可移動的物體，不會出現很深的分支，並且整個樹結構將會非常flat——大部分可移動物體都直接連接到根節點。當然，對於遊戲編輯器來說則不太一樣，編輯器中，所有物體都是可移動的，並且通常需要移動一整個對象組，這時，SG中就包含了所有物體。

     那麼如何進行情境管理，culling和collision detection呢？把情境中所有物體都抽象為SceneObject。情境管理通過SceneManager完成，SM內部維護了多種資料結構，分別是Dictionary，SceneGraph，StaticSpatialGraph，DynamicSpatialGraph。SpatialGraph是用來進行空間劃分的資料結構，引擎將通過它實現culling和collision detection。StaticSpatialGraph並不必須是某種特定的資料結構，比如grid, quadtree,octree,bsp或者pvs，而可以是由多種結構組成的混合樹：每個SpatialNode只需要實現ICullable介面，實際的SpatialNode可以是前面提到的任何一種結構，非常具有靈活性，當然，子節點所覆蓋的範圍不能超出父節點。理論上，DynamicSpatialGraph也可以由多種節點群組成，但由於其本身的動態特性——會動態改變樹形結構，所以即時產生各種不同的節點並不現實。當一個so加入到sm時，sm將會把這個物體添加到Dictionary之中，以便以後訪問；之後，檢查so是否可移動，如果可以，同時添加到SceneGraph和DynamicSpatialGraph中，如果是靜態，則只添加到StaticSpatialGraph。對SceneObject來說，SpatialGraph是透明的，SceneObject完全不需要知道SpatialGraph的存在。

ps:前幾天剛好看到有人在討論sceneObject與sceneNode應該分開還是合并, 從上面的討論可以看到，sceneObject並不總是sceneNode，兩者的職責是非常不同的，合并到一起會讓整個系統非常難以擴充和修改，每次scene graph的管理方式改變，都會影響到所有sceneObject。SceneObject並不需要知道關於情境結構的任何資訊，sceneNode通過介面負責為sceneObject提供最終的全局座標，你可以用任何管理方式（group策略）進行情境管理，不會影響sceneObject系統。在任何設計良好的引擎中，都應該把sceneNode和sceneObject分開,max，maya甚至ogre都是這樣。