轉-情境管理，放棄情境圖

http://www.cnblogs.com/cproom/archive/2007/09/14/893496.html

 

情境圖一直被認為是適合遊戲的通用情境管理演算法，彷彿沒實現過情境圖就不算寫過引擎。但是經過思

考和分析，我覺得情境圖並不適合作為一種通用的情境組織方式，在下面我會說明理由，並提出一種替代的

適合目前mmorpg網遊的情境管理方式。如果大家有什麼不同看法可以和我討論。

    情境圖是一種層級組織情境的資料結構，要產生情境圖就要選擇一種層級關係，或曰父子關係，或曰繼

承關係。比如幾何變換矩陣的級聯關係，或者空間範圍的包圍關係，或者渲染屬性的繼承關係。然而你選擇

了一種關係就不得不放棄另一種關係，或者你不得不在不同層級或者不同枝杈間選擇不同的級聯關係而使系

統變得複雜晦澀。另一方面並不是所有的系統都是層級關係，比如地形更適合用四叉樹或者是數組結構來組

織（我覺得對於目前網遊的可視範圍來說數組就很好了，根本不需要四叉樹），室內情境更適合用通過

Portal串連的地區這種類似圖的結構來組織，如果生硬的將這些結構附和到級聯關係的情境圖，將難以設計

，帶來混亂。很多不好的情境圖的實現往往帶來扁平的情境組織圖，情境圖就像一個鏈表，失去了層級組

織的優勢。

    下面我提出一種適合目前mmorpg網遊的情境管理方式：

    首先定義一個情境管理器介面ISceneMgr，包括如下介面函數（僅列舉講解思路所必須的函數）：
    class ISceneMgr
    {
        public:
           繪製函數
           一組碰撞檢測函數 
    }

    從ISceneMgr介面派生兩個情境管理器類，分別是地形管理器ITerrainMgr和室內情境管理器

IBuildingMgr，地形管理器通過數組結構組織管理地形Patch，室內情境管理器通過Portal串連的地區組成的

類似圖的結構管理室內情境。

        假設一塊地形上有一座城堡，讓我們來看看上面的結構如何完成遊戲功能。地形管理器會通過室內情境

（城堡）的最大包圍盒、城堡所覆蓋的地形Patch地區、和串連室內外地區的Portal與室內情境發生聯絡。首

先來看繪製過程，假如攝像機在地形地區，地形管理器會通過數組結構、地平線演算法、PVS可能可見級來做繪

制裁減和剔除的最佳化，如果城堡的包圍盒在視錐範圍內則交給室內情境管理器進行繪製。室內情境管理器會

通過Portal做遮擋剔除來最佳化繪製過程。如果攝像機在室內，則首先由室內情境管理器進行繪製，如果攝像

機通過串連室內外的Portal看到了室外情境再把繪製交給地形管理器。

        再來看看碰撞檢測，以射線的碰撞檢測為例，如果射線的起點在室外地形，則先由地形管理器做檢測，

同樣可以利用地形的一切特點進行碰撞檢測的最佳化。如果射線與城堡的最大包圍盒相交，則把檢測交給室內

情境管理器，同樣的室內情境管理器可以利用Portal、bsp樹等一切可以利用的室內情境特性做檢測的最佳化。

假如射線的起點在室內，則先由室內情境管理器做檢測，如果射線穿過了一個串連室內外的Portal，再把射

線交給地形管理器去檢測。

    看上去不錯，也許有些人會問那模型系統、特效系統怎麼辦，都作為情境管理器豈不是會有越來越多的

管理器，碰撞檢測和繪製要遍曆越來越多的系統？其實不然，模型和特效我們不把它們看成是情境管理器，

而是作為更低一級的底層對象，它們必須依賴一個情境管理器對象而存在，也就是說它們必須屬於一個地形

系統或一個室內地區，它們的繪製和碰撞檢測由它們所屬的情境管理器對象驅動，不同的管理器會通過各自

特殊的資料結構來最佳化對模型和特效的管理，比如地形系統紀錄模型所在的地形Patch，室內情境管理器紀錄

模型所在的地區（房間）。

   一切就這麼簡單、清晰，不需要去附和到一個統一的結構，各個系統有各自的特點，有自己的最佳化組織方

式，放棄情境圖，你將遠離煩惱。

    找到一篇與我觀點相近的文章，連結如下，有興趣的朋友可以參考。

    http://home.comcast.net/~tom_forsyth/blog.wiki.html 中的“Scene Graphs - just say no”主題