wmo(wow map object) research
The wmo是一個非常有趣的設計，wow中比較小的物體使用doodad，而building使用wmo，
這里的building可以是橋梁、了望臺、簡單的小房子、復雜點的旅館這樣的房屋、非常
復雜的建筑群（例如地下城場景），本文對wmo場景文件進行簡單的介紹，關于wmo文件的具
體信息請參考wowmapview的source code，這里非常感謝ufoz所做的貢獻。
1、命名規則
wmo保存在以.wmo結尾的文件中，這個文件使用數據塊來保存數據。一個wmo通常由一個或多個
group組成，而group數據也保存在以.wmo結尾的文件中，不過文件名稱存在不同，例如一個wmo
保存在name.wmo文件中，那么group文件名就為name_001.wmo name_002.wmo......
2、結構
wmo就組織結構來說包含兩個層次，group和batch。一個group通常包含多個batch，其中group包含
一個AABB。batch是wmo最小的渲染單元，它保存了頂點索引列表，可以直接調用DP進行渲染。group
內保存一個標志位，可以將group分為indoor/outdoor兩類，這一個信息非常重要，通過它wmo就將
building分成了內外兩部分，outdoor group就是building的外殼，他通過portal與室內場景連接
在一起。
3、portal
wmo文件中保存了portal信息，在wmo中規定group必須通過portal進行連接，portal由PVS和PRS
兩部分組成，PVS記錄portal頂點信息，PRS記錄portal和group的連接信息，PRS結構如下：
struct WMOPR {
int portal;
int group;
int dir;
};
需要注意的是dir，這個成員只有兩個值-1或1，由于portal的頂點信息按照順時針記錄，因此group
位于portal的正面時dir為1，否則為-1，通過dir可以快速確定group到底位于portal的哪一側。
通過wmo中記錄的portal信息可以使用portal culling來檢查group的可見性，但是這里還是有一些
難度，主要是指portal的記錄方式。由于一個group可能有多個portal，而查找連接的portal只能
通過PRS，這樣在大的場景中非常不方便。而且在wmo中竟然沒有記錄portal的plane信息，如何確定
camera到底是位于portal的正面還是反面呢？（現在wmo文件由于沒有完全破解，存在一些wowmapview
未讀入的數據塊，例如MVER、MOPT、MOVV、MOVB等，其中MVER應該是wmo文件的版本號，MOPT懷疑是保
存所有plane信息，而MOVV可能是保存包圍體頂點信息，而MOVB保存包圍體信息，MOVV、MOVB應當用于
碰撞檢測，這些暫時沒有驗證）我的做法是在載入時計算portal的plane信息，并將PRS信息轉換為類似
Q3 BSP中portal的結構。
struct portal_t {
int othergroup;
int pvs;//pvs index
int dir;
};
struct group_t {
int firstportal;
int numportals;
};
4、碰撞檢測
在wmo中并沒有使用BSP、OC TREE這樣的結構來進行場景管理，可能所有人都感覺非常困惑。
場景管理的功能主要是為了加速渲染和方便碰撞檢測，由于存在portal，這樣第一個功能已經完成。
而對于碰撞檢測，我的想法應當是AABB TREE。仔細觀察WOW的場景可以發現在indoor場景中曲面、斜面
這樣的幾何物體非常少，大多數是規則物體，因此可以判斷在wmo中所有的物體都是嚴格按照軸對齊
方式進行建模，也就是對規則性物體AABB=OBB。由于MOVV和MOVB信息并沒有完全研究透徹，因此關于
這一部分只能是我的猜測。
5、渲染
對wmo的渲染由于batch的存在從而變的簡單化，但還有可以優化的地方。由于wmo中使用portal將其分割
成group，因此有大量的材質相同的model被分割成不同的batch，在渲染時將材質相同的batch合并到一起
渲染可以避免一些無謂的DP調用。wmo一個令人詬病的地方是使用vertex light，為了減少圖元數量從而
使頂點數量降低，造成渲染的時候出現色帶效果，應當加入lightmap，由于wmo的場景通常不大，預處理
時做radiosity的時間也不會太長。
6、動態載入
對于只包含幾個group的小場景的wmo，由于載入時間不是太長，在動態載入時一次性載入對程序影響
并不會太大。但是對于超大場景的wmo就需要考慮載入策略，這樣場景典型的就是wow中的地下城場景，
它一個wmo中包含了幾百個group，一次性載入時間非常長，需要分段進行載入。此時就顯示出wmo分
文件保存group的優勢了，為了實現動態載入wmo場景，一種可能的做法是在載入wmo后需要根據camera
所在的group快速的建立group連接層次圖，這個圖通過PRS數據建立，建立流程如下：
一、將camera所在group作為當前group，獲得所有相連的protal；
二、將protal連接的group保存到第一層列表中，遍歷第一層列表中所有的group；
三、獲得第一層列表中group的portal，檢查portal所連接的group是否保存在第一層列表中，如果沒有
將其保存到第二層列表中；
四、重復上述過程，直到整個層次圖建立。
這個層次圖可以預先建立然后保存到文件中運行時載入，這樣wmo就是分層載入而不需要一次性載入。
（這里我考慮是否在wmo中也可以建立類似bsp的pvs數據呢？雖然pvs現在已經開始淘汰，但是如果
存在pvs就可以方便確定哪些group需要立即載入，只是不知被portal分割后的group到底是不是convex
hull，如果是的話可以建立pvs，但對建模時限制更加明顯，兩難的選擇！！！）
7、建模
由于wmo是按照group對場景進行保存，因此為了建立wmo需要設計一個強力的模型構建工具，這個工具
主要功能就是對從建模工具（3DS MAX）中建立的場景模型進行分組和處理。美工在制作模型時需要非常
小心，所有的模型要嚴格的軸對齊（軸對齊的原因是需要模型的AABB=OBB），然后將模型導入工具中。
模型構建工具有以下功能：分組（group）功能、group選擇、group顯示/隱藏、指定portal，portal對
齊（考慮門、窗戶這樣天然的portal，手動指定portal時肯定無法與外表墻壁對齊，需要程序自動對齊）
、batch操作（分割、選擇、顯示/隱藏等）、圖元級操作（triangle揀選，用于batch分割）、光照運算
（產生vertex light數據）、放置光源、放置doodad（場景中的道具，如桌子、椅子等）。可能還需要其
他一些功能，但是對比其他引擎的場景建模工具（hammer、sandbox）明顯簡單化許多。
8、優勢及不足
當前處理室內場景的主流技術依然是bsp，但是隨著硬件的發展bsp的優勢在慢慢地喪失，bsp賴以生存的
預處理PVS現在已經完全被實時的portal culling所取代，bsp優勢只剩下對圖元排序（用于透明物體的
渲染）和基于brush的快速碰撞檢測上，但是對比建模工具的復雜化和場景的限制，采用bsp的開銷確實
顯得太大。而基于純portal引擎的結構開始流行，例如cryengine中處理室內場景時就完全拋棄bsp，
場景完全由一塊塊固定大小的墻壁組成，一塊墻壁基本和bsp中brush類似，這樣做的好處是建模工具變
的簡單（不需要進行CSG運算），而且非常容易的產生portal，同時由于場景使用brush構成也兼具了
bsp方便進行碰撞檢測的優勢。wmo有些類似cryengine，但是在某些方面更具優勢。
首先在建模方面，wmo的場景完全可以通過成熟的建模工具來構建，這樣對于美工不需要重新學習新的
建模工具，可以節約大量的時間。其次模型構建工具需要的功能非常少，減少了程序的復雜性，縮短了
編寫相關工具的時間。再次，場景管理簡單化，相應代碼量大幅度減少，同時由于portal的存在，可以方便
的與其他引擎相對接。可以說wmo是一種可以進行快速開發的場景結構。