GDC -《幽靈行動：荒野》地形技術和工具

來自專欄 GT的虛幻引擎筆記及技術文檔4 人贊了文章

文檔翻譯自GDC 2017的技術演講文檔：《Ghost Recon Wildlands Terrain Technology and tools》；網上也有類似的譯文，但沒有看見完整翻譯的；本人在學習這篇文檔的時候順便完整翻譯一遍，自己的收穫也頗多；

文檔其中穿插了若干視頻演示，此文中以鏈接的形式給出；一些技術術語保留了原文以便於理解；

以下為原文檔的翻譯：

程序化開發工具及技術 - 摘要：

• 第一個原型 - 2012年開始製作
• 地形工具 - Guillaume將要談到他創建的工具，以及地形渲染的一些細節問題
• 程序化工具 - Benoit將要談到場景的創建工具和流程

在《幽靈行動：未來戰士》完成後開始嘗試製作更大的地形；

配合world machine使用現實世界的數據獲得相關DEM文件；

然後結合Houdini開發了一些工具如：

• 自動生成自帶LOD的Tiled Mesh；
• 根據基於斜坡、高度、粗糙度和來自World Machine的其它蒙板如flowmap制定的一些規則，來定義材質分配的splatting mask；
• 通過坡度，高度，材質，密度，樹木之間的距離等一系列規則來獲得植物的散布點；

原型只由4個美術和1個圖形程序員花了若干個月做出來；

這個原型讓我們認識到了兩點：

• 我們必須改進自己的地形製作流程；如處理模型需要在編輯器和各種DCC軟體中來來回回，很不方便；因此需要新的地形製作技術：方便美術的編輯和滿足運行時很好的性能；
• Houdini被證明是一個非常靈活和高效的工具：技術美術可以在沒有專門開發人員的情況下創建工具；

在這幾個月中，美術團隊開發出了一套基於WorldMachine生成Heightmap的流程管線；

地形編輯器的主要目標則是使用這張高精度的而且不帶任何材質信息的Heightmap，轉化成一個逼真且多樣化的世界：

我們開發的第一個功能就是Heightmap雕刻工具；基於GPU開發有幾個原因，首先當然是快，我們需要能編輯巨大地圖中的區域，一個簡單的點擊就能刷出一整座山；還有就是在編輯地形時這是最好的能提供準確視覺化反饋的方法；Heighmap和筆刷混合在一個浮點渲染目標中（floating point render target），並且能被遊戲Shader直接使用；

製作遊戲是一個迭代過程；

我們需要在遊戲中嘗試各種新的創意並且不想在還原的時候花費太多時間；

所以我們想到了層的概念；

World machine的輸出被保存在我們稱為<base>的層，編輯器中的每次修改結果放在<macro>層；當不滿意修改結果時，<macro>層中的內容可以被輕易抹掉還原成原始的heightmap；

以下是這個雕刻工具的展示視頻：

材質分布的結果之後被存儲在2張貼圖中；第一張我們稱為<splatting>，其包含了heightmap每個元素（entry）對應的材質索引；

第二張稱為<Vista>貼圖，看上去像是谷歌地圖的截圖；作用為渲染遠景時作為albedo map；

所以我們決定在運行時生成這些內容，材質和decals在離屏面混合然後使用Async Compute管線實時壓縮；但駕車飛馳時需要地圖塊的大量更新，很快就會幀率狂降這樣的幀間低一致性（low frame-to-frame coherency）的情況處理起來很棘手；

多幀間的Virtual texture更新不得不做時間切分，以及還要做很多讓高幀率和低潛伏期（latency）達到平衡的調整工作；

我們嘗試成功的去把很費的近景shader替換成virtual texturing；

幸運的是我們在開發前期就做出了這個決定，結果調整了內存的預算；

如大家所看到的，遊戲在1080p的情況下運行時，存儲atlas圖大概需要200MB多一點；原生4k的情況下，會達到1GB左右；

譯者註：把所有要混合的貼圖做成一張貼圖，這張圖稱為Atlas；

規模

• 工具適合從大到小的各種規模的場景；
• 編輯範圍從最小的岩石到最大的山巒是製作這個工具的準則；

協作性

• 一整個巨大的關卡；
• 兩個在不同地點的製作團隊：巴黎和布加勒斯特；

迭代性

• 我們需要能修改需求；
• 試驗新的想法；
• 工具即為數據：工具的創建和存儲與世界上任何其它實體完全一樣；工具是生成自身實體的元實體；

當然最重要的是：每天都必須能保持其可遊玩性；

• 基於規則的工具：使用者編輯參數和調整規則就能產生相關內容；
• 確定性：相同的輸入產生相同的結果；
• 離線性：沒有任何東西是在運行時生成；所有的都是在製作時烘焙的；
• Houdini：世界創建流程管線和所有的製作的工具使用Houdini；
• CPU：自從我們開始使用Houdini大部分工具都基於CPU（Houdini的最新版本能更好的支持GPU，但我們製作時並非如此）；依賴CPU並不是問題：CPU很便宜，但我們需要更多內存，一些工具非常佔用內存！

什麼是Houdini：

• SideFX公司的DCC（Digital Content Creation，數字內容創作）軟體；
• 在特效領域大量使用（但不關我們的事）；
• 我們用來進行場景創作；

我們用Houdini來做什麼？

• 原型：很好的能快速實現想法的工具集；
• 工具創建：創作相關內容；
• 視覺預覽數據/獲取統計數據/處理數據/優化數據；

為什麼使用Houdini而不是C++/GPU工具？

• 快速迭代；
• 沒有編譯時間：工具是HDA（Houdini digital assets）- 在HDA中做修改或修復Bug -> 發布給團隊 -> 每個人可以馬上使用；
• 性能問題？專用的工具當然會更快一些，但Houdini有無可取代的靈活性；

Houdini團隊：

• 一個技術美術總監（Benoit Martinez）和三個技術美術創建了所有的工具並設置了流程管線；
• 30個場景構建人員（由關卡美術和關卡策劃組成）在開發過程中使用了這些工具；

我們所使用的SideFX產品？

• Houdini（DCC軟體）-> 創建HDA/工具
• Houdini engine -> Houdini的核心API整合到了我們的遊戲編輯器；在編輯器中使用HDA/工具；
• Houdini Batch（渲染農場） -> 渲染農場中的計算工作；

我們有很多在這個世界中填充大量物件的工具；

這些工具並不創建模型，而是幫助美術對已有的物件制定擺放的規則；

我們大部分的Houdini工具處理好擺放點然後返回引擎以下數據：

• 矩陣；
• 已有物件的ID；

我們估計有80%的數據是使用Houdini創建或操作的；由於它們是基於規則的工具，所以能很好地保持一致性；

這些工具修改迭代世界中的大量區域，為美術節省時間，讓他們能專註於更有價值且不能使用自動工具完成的任務：

• 統一大局；
• 賦予意義於這個遊戲世界；
• 通過場景環境來講述故事；

地形不僅僅是高度以及貼圖混合；

我們推導出能夠在其它工具中復用的有用信息，比如：

• 從海拔高度中我們可以獲得粗糙度、檢測出山頂，這些信息對擺放石頭或植被很有用；
• 從河流、材質和一些特定的物件我們可以定義出潮濕度，然後可以使用在植被的規則中，或影響地形的高光；
• 求陽光照射的平均值，我們可以得到一張有用的蒙版，用來驅動植被和環境音效；
• 來自world machine的初始水流蒙版（waterflow mask）用來影響地形splatting；但是當地形被雕刻修改後我們想保持這張蒙版的更新；

我們在渲染農場中自動更新這些地形層：

每次當有用戶提交了地形的拓撲結構修改，會觸發Houdini渲染農場的重新計算；更新文件存儲在Houdini工具可以立刻讀取的伺服器上；成為中間數據後可以隨時更新，我們對此沒有任何版本控制；沒有版本控制和備份聽上去有點嚇人，但製作中我們也沒出什麼問題；

在談到我們工具集的具體細節之前，用以上的視頻展示一下程序化生成的層；

• 道路生成和程序輔助；
• 野外的道路、植被、岩石；除了最後兩塊大石頭是手動擺放其它的都是程序化生成，包括河流的成形、水體模型和流向；
• 甚至村莊也是生成的，從仿地成形到建築的擺放；
• 帶有隧道和橋樑的鐵軌線路；
• 在全局運作，連接所有的道路，計算flow map蒙版，擺放植被和村莊；

根據這篇論文：http://arches.liris.cnrs.fr/publications/articles/EG2010_ProceduralGenerationOfRoads.pdf

我們開始試驗加權各向異性（weighted anisotropic）最短路線演算法；

其關鍵是搜尋多個方向和每個方向的多個距離，而不是之前的四個方向；

最後的結果正是我們想要的；

道路層輸出的信息有：

道路軌跡：我們可以在很多情況下使用這些信息，如AI的交通系統；

地形塑造：一張heightfield貼圖塑造了地形；

Splatting：一張更新地形材質的貼圖蒙版；

橋樑：假如是最優路線，我們允許尋路演算法能跨過河流；

之前提到的一些工具，比如視頻所展示的橋樑工具，可以在獨立模式下手工創建橋樑或嵌入到更大的工具中去自動創建相關內容；

注意：橋樑或隧道是模塊化的，並沒有新的模型被創建，只是實例化而已；

遊戲中16平方公里的地方被水覆蓋；

這是一個被切分為塊（tile/平方公里）的單獨連續模型；

水關乎到湖、河流和小溪；

河流湖泊這些地形的主要特徵可以在地形工具中直接製作；

另一方面數量龐大的小溪使用道路的尋路做法把山頂的源頭和河流連接起來（然後河流連接到湖泊）；

對於地形地貌我們定義了一些層順序，所以小溪會在道路下鋪設的管道中流動，但河流我們更傾向於讓其穿過橋樑來保持連續性；

我們生成小溪的軌跡信息後（還有某些河流）我們就能復用這些信息來定義flowmap的向量；然後flowmap被存儲在頂點色中；

我們用了比較傳統的方式來做岩石的分布：

定義一張分布蒙版 - 美術可以在編輯器中直接視覺預覽：

• 分布規則應用在什麼地方
• Material – Occlusion – Curvature – Flowmap – Roughness – postFilter

創建應用在蒙版內的分布規則：

• 模型
• 相對坡度調整
• 比例參數
• 密度/最小距離

我們可以在開發過程中不斷的改進這些工具；

為了避免每一個可能的用戶都有特定的需求，我們決定每個工具都有一個擁有者；通常是一個美術與將創建相關工具的技術美術合作；為一個工具編寫相關文檔的也可以是工具的擁有者，來編寫更友好易於理解的幫助文檔而不是技術文檔；

我們還整合了預設支持，那麼工具擁有者就能夠創建一系列規則，其它的用戶可以直接使用這些預設值而不用去理解和使用所有的參數；

排除法工作流：

混合程序化內容和手工控制是非常複雜的；

假如想要好的手動控制那麼就應該純手工去做；所有的工具都支持輸入手工定義曲線來排除某個區域，或隱式輸入（比如：排除道路上的植被）；

使用這個工作流，負責植被或岩石擺放的美術可以不用考慮村莊、道路等諸如此類的問題；他們只用任意定義生物群落的規則，必要的排除過程會在之後的整合過程中完成；

非同步更新：

我們需要保證一個始終可遊玩的世界，但並不意味著其要很準確；

假如地形的拓撲結構修改了，我們不必完全重算植被的擺放，大部分情況下我們只需要保證沒什麼東西擋住道路並且所有東西吸附到了地形；

記住這些工具是獨立使用的，不受其它物件擺放的約束，並且它們都應用在原始的基礎地形上；

我們還有「點緩存（point cache）」，所有point來自各個工具；

• 首先編輯器針對地形檢查所有實例；
• 把所有的東西吸附到地形(保持所有的地形相對偏移 - 想想陷入到泥土中的石塊)
• 刪除程序地形化區域所不需要的物件
• 從道路、河流和定居點等等地方移除植被；
• 然後針對所有實例組間的相互關係
• 橋樑和隧道則刪掉石頭
• 石頭上則刪掉植被
• 電線不能穿過樹木
• 還有諸如此類的情況。。。。。

Worldbatch可以幫助自動處理這種任務，或者允許你在任何時候更新世界所使用的任何類型的數據 ；

Worldbatch基於Houdini python (hython) ，使用 "Hqueue" 任務分配系統（由SideFX開發）在渲染農場開始一個數據任務；

一個任務讀取一個Houdini asset資產文件（otl格式），假如需要的話設置好參數然後開始此otl文件的渲染進程；

用戶在UI模式下能夠從世界地圖中直接選擇想要重新計算的東西，它能自己運行，把任務發送到自己的電腦上或發送到渲染農場；

之前我提到過把Perforce也加入了進來，worldBatch會在用戶提交Anvil引擎的地形相關修改清單時自動運行，命令行腳本將會讓worldBatch發送基礎任務到渲染農場保證數據的更新；

<全文完>