整理 | 遊戲陀螺
9月21日，在騰訊遊戲學院舉辦的第三屆遊戲開發者大會（TGDC）上，來自騰訊互娛天美工作室的技術美術師楊拓以「善用過程化技術，助力大世界的場景製作」為主題進行了分享。
他提到，在IEG內部的工作室，Houdini技術已是一種被廣泛使用的技術，充分利用這項技術對於推進過程化方案，製作開放世界場景十分有效。
以下為遊戲陀螺整理的分享實錄：
這幾年過程化大世界遊戲逐漸變成了熱點，很多項目組也都自己定製了新的大世界遊戲。另外的做法是在上線的遊戲項目中加入BR玩法，拓展新玩法。過去一年來我主要的工作是在天美已有的產品線上為他們加入一些開放世界的內容。
我今年開始另外一個工作，主要是服務天美兩款新IP的3A級別的開放世界遊戲的管線製作和搭建，培訓場景美術人員，以及相關的TA人員。
大世界的製作技術其實已經成型很久了，最近逐漸被人重視起來的原因，一是國外3A大廠遊戲品質不斷提升，在背後推進場景製作技術的發展，特別是Houdini技術逐漸被國內的各個工作室了解和接受——IEG內部每個工作室都有自己的一套Houdini管線，而且大家都在推進過程化的方案。
之所以TGDC邀請我來做演講，主要的原因也是因為天美通過一套自己對產品線的需求分析，以及對分析得到的過程化技術的方法定義，通過這套方式很好地把Houdini這套管線技術落地到已有的各個項目裡，並成功地發布到線上，得到一定的肯定。
接下來根據我為幾款重要IP遊戲所做的管線分析以及定位，來進行方案的描述。如果你要具體管理一個遊戲的開發，或者作為場景主美需要遊戲管線，希望這些方法可以為你提供一些建議。如果你是Houdini工具的開發者或者是過程化技術的開發者，希望這次可以幫助你們去梳理管線的一些問題。
當設計開放世界的時候，對場景製作有什麼要求？
為什麼要用過程化技術？是因為開放世界製作的要求。我們所定義的開放世界類別的場景要求，我分為兩部分：
第一部分，如果大家對吃雞、BR玩法有所熟悉，通過它的場景可以看到，首先它的區域比較廣闊，可能至少是4×4公裡或者8×8公裡，而且裡面要有樹木配合大家躲在樹林對著射擊的玩法，而且要有密集的草地，可以趴下在地上躲藏；有道路可以通過載具快速移動到不同的區域，以躲避毒；而且要有豐富的建築，建築裡面可以探索你要的武器、道具，可以進行一些躲避工作。這可能是關卡美術對過程化場景製作的要求。
第二部分，關卡策劃對場景的要求。傳統的策劃要求是在場景裡面圈一塊地方，在這個地方擺一些玩法內容。今年以來有一些新的BR玩法或者開放世界的玩法，除了關卡策劃要辦法和PVP相關的物件位置以外，還要加入新的場景互動，比如攀爬、跑酷和掩體具體的躲避的玩法。
我先從關卡美術這邊來介紹，大家想到的開放世界，第一點是非常大的地圖，而且有非常豐富的地形地貌，比如對應的不同季節的草地、雪地，包括丘陵、山地、雪地以及平原的效果。以往MMO裡面也確實做了這些，IEG過去的遊戲並沒有做到完全無縫的遊戲世界，有時候你去切換一張大地圖的時候才會具體替換到新的地貌效果，而現在最新的開放世界要求的是你要把所有的地形地貌集中顯示在幾公裡的範圍內。比如《王者榮耀》的BR圖，三種地貌顯示在1x1公裡的場景裡，其他的BR遊戲是在8x8公裡或者4x4公裡中，至少實現2-3種地貌的混合。這也是需要我們有一套比較好的過程化工具來對它進行管理。
第二點是當你的地形做完以後並不代表場景有生機，給場景帶來生機勃勃的感覺首先要素是植被和生態系統。植被和生態系統設計的要求，首先是植被需要去對應到具體的地貌上去的，比如綠地要長綠草，沙土上不能長草，有湖面的地方不能有任何樹木生長的，但湖邊的地方可能需要要長一些簡單的小草，而越靠近沙土的地方草的密度越少，而實際上美術對於根據地形地貌對植被的生長有嚴格的控制和規則。如果傳統的用筆刷的工具去刷的話，或許一次可以用人力來完成，但是一旦你的水面有些變化或者場景有些改動，那麼你的美術又要頻繁根據你的地形地貌的改變去重新對植被進行修改。這明顯是對美術製作體驗有非常大的影響，也是需要有工具去解決。
有了植被和生態環境以後，你想進一步增加活力要素的話，那就要有人群的概念，有人群必定要有人群所居住的環境，也就是城市規劃。城市規劃裡面跟自然環境最大的區別是自然環境也有自己的規則，但受到環境的影響有一定的隨機性，而城鎮其實包括從最初的道路的規劃到道路劃分出的區塊，以及區塊中的房屋和房屋周圍的花園，停車場等等。另外小區房屋之間有些要有通道，而且道路周圍要做綠化，可能是按照一定的距離去擺放你的樹木和路燈，這些是一層一層的規則疊加下來，這是一整套規則的樹狀結構。一旦處於規則頂層的道路發生了變化，同樣也會引起道路周圍每個要素的變化。這個東西也是整個的一套城市建築的製作方案，也應該一套標準的流程對它進行管理。
第三點，細化到城市裡的某棟建築或者某個房間或者一棟樓的時候，這時候就關係到美術或者原畫需要對這個建築風格和效果做把控。通常來說這些都是通過外包來做，我們怎麼用更好的方式讓外包控制一個風格的同時，能夠加快製作效率，能夠快速地去鋪量的製作一整個城鎮，以及城鎮的細節變化，這點也是需要有工具能夠解決的。這些可能就是說我們要定位我們的過程化工具在美術方面的幾個點。
除此之外，前面也提到，關卡策劃除了把PVP、PVE玩法相關的，比如設計出生點、對戰掩體外，還要有跟場景的交互。
第一點是像跑酷，場景裡面每個花壇、垃圾桶、障礙物，每個房頂，以及房頂與房頂之間要能夠跨越，實際上都是依賴於你的建築之間的擺放的觸發器來控制。當我的角色跑到綠框的時候，觸發器才會觸發按鍵提示，玩家確認后角色做出跨越動作，而物件上面的綠框用來輔助提示角色能跨多遠，通過參數來控制動畫藍圖做出。如果每個建築物件都要人工配，而實際上一個大世界有成千上萬的部件，而且會經常有調整，全靠人力是不可行的。因此我們需要把這些物件進行模塊化，通過模塊的方式來管理每個物件的觸發器。另外一個是要有自動化的工具，根據建築的形狀來自動的把對應的觸發器生成出來。
第二個玩法是攀爬，我們的角色可能不會像蜘蛛俠一樣，在場景的任何地方都可以爬、都可以跳。像《諜中諜》的阿湯哥一樣，所有的攀爬都是要基於物理正確性，也就是說建築哪裡能爬、哪裡不能爬，這並不是純粹靠程序或者遊戲玩法系統去控制的，而是要由美術在視覺上做提示或者策劃在玩法上做限制，有統一的規劃。這樣才能確定一個人可以通過設置的攀爬線，從房底爬到房頂——紅線就是攀爬線，當角色有攀爬線的時候，才能趴在牆邊上，玩法程序是說根據攀爬線的位置信息，結合建築的物理碰撞體，最後得到配合他的動畫藍圖的系統，最後得到一個正確的攀爬動作。
第三點是大世界的核心玩法掩體射擊和掩體移動。角色可以沿著隔離帶進行橫向移動的。那麼角色在一個位置上可以如何去移動，是根據綠框的信息來的確定的，綠框代表著首先會告訴角色的的控制系統，在這個位置我能做什麼動作，比如中間我只能橫向移動，或者像圖中的位置可以進行蹲下的掩體射擊動作。如果在建築的兩邊可能就是做向外的掩體射擊或窺視的動作。而且這套掩體系統不光是玩家角色使用，如果你是PVP遊戲，首先機器人AI也是要依賴這套系統；如果做PVE遊戲，可能你的隊友AI也是要依賴這套系統。其實這可以說是第三人稱射擊遊戲的核心支持的組件。這個東西如果不考慮是程序或者是策劃的訴求，而是直接生成或者人工擺放，這也是非常大的影響製作效率的地方。
總結起來是這兩款大世界遊戲面臨的幾個綜合問題：
1、巨大的美術工作量會導致外包的數量，以及有大量要在編輯器裡面手工編輯的工作，這是需要解決的；
2、巨大的工作量會引起遊戲包體的膨脹，現在實際上雖然是做3A手遊，還是要受到手機移動端的渲染、內存的壓力影響。如果你想說，現在這款遊戲能夠在國外或者歐美市場上市，那麼你的硬體可能只有給你1G內存的使用量，1G內存使用量意味著不可能把非常豐富的資源直接全部加載到場景裡，而是需要用模塊化、實例化的方案解決。
3、一旦你加入更多策劃性的玩法，實際上就需要在製作場景的時候要有場景美術，要有場景策劃，要有具體的場景的渲染人員以及玩法相關的這些開發人員，大家一起討論這個問題，其實它會導致非常大的溝通成本。而且這個溝通成本並不僅僅是在上線以前，而是在整個項目的生命周期內，因為上線後會不斷開發新的關卡、開發新的玩法和PVP的地圖，所以如果不解決的話，它會是長期的成本問題。
基於這些問題所在，我們定義了自己的場景開發管線的方案。我之前提到的過程化技術，過程化技術是什麼呢？我通過幾個例子來介紹。我解釋過程化技術，它是美術提供的一些元素，包括基礎的圖形參數或輪廓元件，以及提供的一些可以調整的數值，最後加上一個可以抽象出來的公式，就能夠到你最後想要的結果。以遊戲貼圖製作為例，很多美術都用過Substance Designer，這張圖最左邊是用SD生成的形狀，可以理解為是你的過程化的輸入項。中間部分顏色是你過程化輸入的參數，最右邊是你得到的最終結果。只要你修改你的輸入項，修改參數就可以得到不同的結果。過程化貼圖主要是用在地表貼圖和一部分過程化生成的建築裡，比如牆磚和房頂的貼圖，可以做四方連續的圖，有些會用SD。
「我們的過程化技術其實是以點云為驅動的過程化技術」
接下來要講的是過程化建模。這個東西是Houdini軟體和官方主力推的事情。你可以看到這裡通過簡單的建築模型加上一定的算法和參數可以把簡單的模型變成比較複雜，有一定美術感的場景。這種一個簡單的地表平面加入一些參數就可以把它變成類似這種Top Down視角的遊戲關卡，我在地形上連上一條曲線，用曲線讀取地形信息，得到的是我比較物理正確的去衝擊地形的河床以及這個河床所生成的河流效果。目前來看，Houdini官方網站的推廣大部分都是這類，可以很方便地幫你通過一些簡單的點線面的輸入得到最終效果，我們的態度是說這個東西有幾大隱患：
1、以河流為例，河流橫穿8×8公裡的地圖，意味著只要你這河流改變一點參數，河流橫穿的8×8的地塊都是被「汙染」掉的，也就是說需要重新構建的。如果有人開發手機遊戲就知道我們的遊戲每天都做增量構建，每天也做全量構建。如果你的地圖所有地塊每天做全量構建，對遊戲場景開發迭代很不利的。
2、你創建的資源每次修改都是一個新的資源，新的資源意味著要重新放到引擎裡。如果Unity要重新映射，UE4要把它導入UE4的引擎裡面生成一個產品，這些資源的修改在引擎裡面是無法做增量判斷，任何的修改都是一次新的改變。比如說你過了幾天以後要返回一個比較舊的版本，但很抱歉，你不知道改了什麼，只能通過Houdini的節點修改來做判斷。而且如果你們當初做過遊戲，可能有些人會在場景裡面拜訪一個場景，裡面有幾百M，大的上G，這時候如果導UE4和Unit，根本無法維護版本的可維護性。因為升級包體和更新包體不可能一次更新幾G，最多更新幾M和幾十M。這個東西對美術的可控性很差——你做一些自然環境也許還可以，但是做建築類或者做一些特殊藝術性的東西，美術需要有非常強的可控性，除非操作Houdini的人是主美或者非常有藝術素養的人做，可能可以做出好的效果；但如果只是TA或者以前做過特效或者是對Houdini的工具非常熟悉的人，那不一定適合。其實會導致雖然你Houdini做得很快，但效果並沒有外包做得快做的好。
正常的方法是什麼？我們定義為模塊化點雲方案。現在所有市面上的產品，特別是國外3A的產品其實大部分使用也是基於點雲。點雲是什麼呢？這裡介紹《使命召喚》移動版的場景裡面植被點雲生成的流程，你可以看到我通過把地形地貌的坡度信息、高度信息以及它的地形圖層的信息總和生成在Houdini裡面，把它轉成一些點。
你可以看到Houdini的實例圖裡面，第一個例子，這些點包含的是這棵樹或者這種樹的大小和縮放信息和旋轉信息，這些信息的包體量大概多大，一百棵樹可能就幾K的數據量，而且這個東西通過渲染引擎的實例化方案，一個批次可以完全渲染完。這樣的方法可以說以第二個CODM的草體來說，同屏的草體是多少？同屏的草體可能是十萬級，而這十萬級真正用到的是兩種草、兩種花、一種石頭，我的包體可能就是這5種資源加幾百萬級的點雲信息，而且這種數量信息除了位置信息大家知道在MAX編輯裡面，U位置信息是是小數點後多少位，旋轉信息可能只是以30度或者15度為Snap單位旋轉，旋轉信息是可以壓縮優化的，你的縮小信息是可以壓縮優化的。這可以保證你的場景是非常小的數據組成。最後導入到場景裡的話，比如我要換另外一種植被效果，只要換一棵草的樣子，整個場景的草都換了；換樹也是，只需要修改一棵樹。優化下來覺得性能不好，要降低草的密度，我只要點一個參數就全部改變。用這種方法我們就可以很快不斷迭代、不斷嘗試，真正適合不同手機平臺的場景的植被的複雜度。
第二個例子，這是我們做的建築的實例，其實是歐式建築。這個歐式建築的組件是10-20個，我們還是一樣，先通過點雲組織位置信息，每個點實際上是一個建築模塊，我們把建築模塊和這些點雲信息組織完了以後再做細化的替換。這個樓房也是，如果我想改變樓層只需要調參數就可以，如果要改變大小也是調參數，如果我們覺得這個樓房的內存量太大，可以優化縮減每個單元模塊的面數、貼圖的使用，這樣就是給予了我們場景非常便利的優化條件。
通過這種方式，我們整個遊戲場景就是一些點雲的組成，樹、植被、建築包括所有的道路都是點雲構成，這些點雲導入虛幻引擎或者Unity引擎裡面，通過實際化渲染，一個批次就可以全部渲完。這個東西優化起來直接調參數就可以優化，不是每次要改什麼東西還要反覆調。
這些建築都是用同一套點雲生成方案組成。通過一些簡單模型就可以把外型確定出來，具體的效果會在UE4裡面替換不同的材質球，得到不同的表現效果。如果材質球可以合批成到一個材質球上，整個樓可以保證幾個批次就完全渲完。
總結一下，我們的過程化技術其實是以點云為驅動的過程化技術。正是因為有點雲的組織結構，我們所有的操作、所有的變化是可以通過一個EXCEL表就知道我加了什麼、減了什麼，也可以通過分析EXCEL表或者數據表的格式，知道某個單位內我們的美術資源量到底消耗了多少。也是通過這種方式我才有可能把非常大密度的建築或者社區手機平臺上渲染出來。接下來我會基於點雲系統才可以給予遊戲的可迭代性。
融合Houdini與點雲系統，實現產品的高效迭代
什麼是美術遊戲開發的可迭代性？這是大家作為美術人員都很了解，場景開發是從概念設計開始，做頂式圖；然後關卡策劃和關卡美術加入，一起把灰盒搭建出來，當灰盒測試完成以後再發包把整個灰盒的場景真正做成有細節、有色彩、有美術藝術效果的場景，而且這個時候如果我們需要對場景做變化，我們可以通過SD的方式修改材質球和貼圖，最後打光得到一個效果。
這個流程是瀑布式的流程，優秀的美術團隊可以做到第一步到最後一步一次性不做任何修改的完成，問題是一旦你的關卡策劃對這個場景有變化，小的變化還好說，可能我這裡面要加一個東西、減一個東西，這裡面要放新的東西，你做微小的修改就可以。大的變化是整體場景風格的變化，比如這是一個平原，哪天覺得這個遊戲玩法好，要變成山地，這不是美術做簡單修改的問題，而是重新考慮你的建築和你地形融合的問題。這時候你用過程化技術，用Houdini生成地形，通過Houdini與這套地形和點雲系統做融合，你就可以很方便給予迭代性。
另一個影響的主要基點是適配性的問題：比如我的整個建築都已經做完以後，把它發包放到手機上，這時候手機測試說哪個國家那邊的手機都是三年前的機器，東西跑不動，但是我要它上線，那要削減每個美術資源，把面數做減法、貼圖做減法，全基於模塊化組成，首先你只要改一個模塊的面數，整個場景裡面所有用到這個模塊的地方都會削減。如果你通過點雲的方式去維護場景的細節，比如說你一個建築周圍有些花草、有些小的擺放物，你直接說因為我的包體不允許把這些擺放物隱藏掉，也需要刪除點雲就可以。美術的手工操作是沒有任何的操作的。
這是模塊化的例子，首先我們也是說先做一些白模模塊，把模塊通過Houdini工具去把它進行組合，然後通過去修改不同貼圖和材質的效果就可以做出不同風格的變化。另外像這種模塊我的另外一個用途是，比如掩體系統可以直接在模塊上製作出掩體信息，跑酷信息和攀爬信息做出來，點雲組合的時候，也根據合併邏輯把信息再進行加減法，比如兩個牆壁反過來疊加肯定是做不了掩體。這些我們在Houdini裡面用算法進行了判斷。
可迭代性的價值在於，我認為是關卡美術把關卡策劃以及玩法程序之間的工作剝離出來。從關卡美術來說，關卡美術我只需要前期把每個模塊的基礎單元提供給關卡策劃和玩法程序就可以，我自己就放心的去做外包、做我的設計，而且我所有的建築構成是通過點雲、通過Houdini的組建方式拼的，我只要按照這種方式拼肯定可以達到最終的效果。而且這時候關卡策劃可以通過簡單的模型先搭建玩法，驗證設計的方式。而玩法程序也是一樣，拿到最簡單的模型和最簡單的導航線和攀爬線各種數據，就可以自己組。
等到美術回包以後，大家在一個階段把所有資源全部替換成新的美術資源，這個階段都是無縫的，不會影響到每個行業的操作。如果到了某個程度，這個關卡策劃要改規則，大家也就一樣，重新回到最原始的模塊的規則修改，美術什麼都不需要改，而關卡策劃和關卡程序只需要修改模塊的生成規則。導致所有的修改量是可控的，保證在非常小的範圍內。
這張圖，如果做過Houdini你們就應該了解，它實際上是Houdini怎麼最後運行到UE4裡面的過程，我把它理解為是我們天美過程化管線進化的過程。最左邊是我直接在Houdini裡面做一些操作，在Houdini裡面連節點、生成東西，生成點雲，自己隨便寫一個工具導進來。更好的方法是通過Houdini引擎，直接在Unity或者UE4裡面讀到Houdini面板，我通過調整面板，然後在底層調Houdini的庫，調HDA，然後重新生成。最終形態是說我直接把Houdini裡面的算法以及它的節點內容直接翻譯成的Python或者C++這種程序的語言，就可以得到一個高度集成的工具。而原始的的方法，大家在Houdini做完後在統一導入到UE，Houdini裡面看到的東西和引擎裡面看到的東西不一樣，你要想辦法說我需要這個開發人員有一定的這種從抽象能力到渲染最終效果模擬的能力。不然就很難把需求做好。
我們在推行Houdini的過程中，很多美術也有這種訴求，你這個工具越集成到編輯器裡面，美術的接受度和可承受度也會越高。所以天美現在的方法，最初的時候我們會用Houdini去做遊戲的原形開發，所有的算法沒有用任何Houdini的功能節點，所有算法是基於Vex和Python進行，Houdini另外優勢是這套Vex的參數調整模板，可以方便控制點雲和生成簡單的幾何體，當時機成熟以後會把整個Vex體系移植到UE4裡面，過程化方法不光是離線技術，還可以做到直接實時加載、實時生成、實時組織。這點也是我們能夠真正推進天美把Houdini真正推進下來的原因。
最後就是我們對整個過程化管線的定義，它到底是什麼呢？我覺得分三部分：
1. 對美術要幫助美術提高效率，同時解決以往美術大場景開發時候的迭代問題；
2. 在玩法方面要支持玩法和關卡策劃的各種需求，而且是需要能夠配合關卡策劃、關卡程序一起做事情；
3. 另外在渲染上是必須要保證渲染效率在手機上達到3A品質的同時，不影響幀率，同時你的包體不管是做更新還是做全量還是做日常迭代，這套流程不能影響到整個每天的生成的規則。
也正是因為天美是以這套方案或者這個景願在推進Houdini技術，它才能在短短一年內在三款線上項目裡面把Houdini技術落地，以及在最新和大廠的合作中讓大家接受用這套方案推進自己的開放世界遊戲。
實操：過程化技術落地項目的實踐
第三部分我是具體講幾個我們現有的例子，舉兩個例子，自然環境，地貌加植被，另外一個是建築管線。
1、地貌製作。大家用過UE4地貌，你才知道UE4地形是有圖層的概念的，因為渲染的採樣數16次限制，導致一個地形，實際上一個地塊上最多只能支持4個圖層，包括現在很多線上項目，每個地塊上只能有4個圖層，這裡面綠地、斜坡、沙土以及道路是四層。這四層如何做迭代呢？每個層有自己的權重，通過權重值的混合，得到最終的結果。這會有什麼問題？首先，嚴格限制地形最基礎的組件，只能使用4層圖層，如果我想要用更多圖層怎麼辦？有些項目是創建多個材質球，這邊用這4種圖層的材質球，那邊用另外4種圖層的材質球，這確實是一種辦法。如果10層以內可以用這種辦法。另外一種方法是直接用Virtual texture或者基於TexAray的虛擬貼圖方式，確實也可以解決一部分採樣數限制的問題，但是權重的總數還是會受到限制。這是我們現在項目的一個最初原形遇到的問題，2公裡範圍內用50張貼圖，這是UE4 連了50個Layer，首先它編輯Shader，如果不聯機編譯Shader的話，光編譯就要等30分鐘，我只要地形上刷一筆，它都要重新組織圖層，肯定涉及重新編譯shader，哪又是等待時間。這種方案美術根本沒有辦法使用的。
現在的方案，首先我們把40-50張貼圖atlas到在一張圖上，這是fallback的方案，另外一個方案是用基於TexArray的Virtual Texture的方法，就是動態的來組合altas，兩個方法對美術的感官上是一樣的。那每個圖層是什麼？以前一個層是0-255的值，是一個權重，可以是0~1之間，是根據255的值做權重，兩個層之間會根據權重值做混合算法。如果一個像素上有4個層，就是4個層的權重一起混合。這會導致一個問題是，美術需要考慮控制權重總數，超過4層以後，權重總數怎麼控制？或者地圖編輯上刷一筆以後，這個層變成5層，導致shader變不過去怎麼辦？現在的新的方法是每個象素上只有一層layer，你可以看到這兩張圖的象素要麼是0、要麼是1，不可能出現0.1到0.5，或者一半這個元素、一半那個元素。這樣的好處是不會因為混合導致這個層的顏色會受到汙染。我們以前做這種產品經常遇到的問題，比如有一張沙子圖或者綠草圖，把這兩張圖按0.5的比例混合，得到一張黃草圖，得到黃草圖之後，玩家觀察的時候黃草圖上長綠草，玩家會認為這個效果不對。這種方案除了短暫的過度，大部分地方都是保證貼圖的唯一性，像素上肯定只用這一個層。
2、植被系統生成。它是參考這幾年GDC上的視頻，用過的話看到這個界面就會很熟悉。我們讀取地表的每層參數，比如坡度、地表的高度、AO信息，把所有的信息輸出到一張表裡，通過修改這張表，我們自己寫了一套自己的Houdini的插件，這比原生插件的好處是不需要拖節點進去才能生成東西。我們把一組植被通過複雜的參數封裝簡化以後就是一組植被的節點，這是Houdini裡面的效果，直接一個樹、一個生成疊加起來，每個樹的優先級和權重都不一樣，疊出來就是比較豐富的植被效果，而這個效果不需要走Houdini，直接通過Houdini引擎管線直接調用就可以實現。
第二個例子是建築管線的製作實例。前面說到所有建築都是全模塊化設計，在通過一個工具對它進行點雲的管理，這個點雲分為兩部分：一是街區模塊的點雲，你可以看到這裡做的圓形，如果街區做細分以後，我是可以在這裡面生成很多點。具體的位置應該放什麼樓、放什麼東西，並不是通過自己計算它的位置得到的，而是通過篩選些生成的點得到這個位置能生成什麼樓，然後根據美術和策劃提的要求，這個位置需要有多少個高樓、需要多少平房或者某個樓一定要生產出來，那麼最後通過這些點得到了正好塞到這個區塊裡面的樓房就得到規劃比較好的城鎮的規劃。這就是簡單街道的規劃。
街道與街道之間，一個區塊內部之間的規劃，有一部分是需要我們用下一步過程化工具，我們會根據建築周圍的一些規則生成一些垃圾堆，在道路周圍生成一些電燈泡、電線桿或者阻擋物，這些東西的生成是按層數走的，就是最底層的街道到下面建築的分層以及建築周圍掩體的分層，每套樓層之間獨立，不會出現點一下以後整個場景都變了，不會的。因為每個階段就是一套點雲，一個樓是一個點雲，對應的樓自己所有建築組件又是一個點雲。最後，我們通過這個過程化生成一條街，然後生成一個城鎮樓房的組合，然後導到UE4裡面的效果。
簡單介紹我們現在建築的結構，這其實是我們結合合作方的方案去制定的，這等於所有的樓房都是基於這套面板做的，這套面板的主要功能是什麼呢？首先這套面板原始的用Houdini做樓，可能拉一條曲線，通過曲線把地基弄出來。而我們的面板上描述的是整個輪廓的走向，當第一層輪廓確定以後，你可以調整它的層數，讓它不斷往上疊，中間部分可以增加拷貝的變化。另外當整個樓層確定以後，還有房頂部分，所有的部分的走勢並不是通過曲線或者放幾何體確定，我們的每個走向，包括房屋的拐角都是面板裡面的節點確定的。這麼做的好處是，我的節點可以覆蓋所有的樓，包括高樓、矮樓和所有的房子，只要你有這種輪廓的現代建設方式製作的，你就是可以用這套節點涵蓋。
這可以看到一個例子，紅色部分是節點上面的一個建築的標記，實際整個樓的每個部件都是對應有節點上的設置。當多個節點進行組合以後就可以做出各種豐富的建築出來，而且所有的建築、所有的樓都是通過一個節點製作。這樣不會出現一個建築是一個做法，另外一個建築是另外一個人做的有另外一種做法的情況，沒有這樣的，我們的建築是統一的做法，任何人做的樓，其他人都可以維護，而且這些都是基於Vex語言製作，隨時移植到UE4裡面，可以擺脫Houdini對我們的控制。
Q：UE4開發移動端3A品質場景的關鍵點是什麼？
A：這個關鍵點我個人翻譯成兩點：1、細節。以前一個建築或者玩過IEG BR遊戲，它的建築就是簡單的圖。到3A品質以後建築要有更加複雜的輪廓結構，包括有些一樓可能要通過內置貼圖的算法把細節做出來，首先質感、建築的細節是要能表現出來。
2、整個建築的數量，你需要把真實的城鎮做出來，像深圳重要的商業區整個物量非常高，壓力不僅是美術的製作，壓力還在渲染製作，等於你做3A級品質的時候要充分考慮到製作的這條管線能否支撐移動端的要求以及對內存的要求，製作管線的時候需要有充分的可控性。比如一個30層的樓，30層樓橫排10個窗戶就是300個窗戶，300個窗戶用實例化渲染還是存300個窗戶的數據量，如果這個樓在很高的地方，其實不需要用300個建築做。可能把4×4或者9×9做成更大的單元更好一點，那就需要在工具裡面提供這種合併實例的功能，這樣能保證你在具體的3A品質上讓你的品質在3A移動平臺上跑起來。你確實要有類似PC 3A製作的理念，另外你還要充分考慮到移動端的硬體的壓力，你需要留足夠給程序做優化的可能。我們現在的方案考慮了很多，如果最新實例化渲染GPUDriven的剔除不行的時候該怎麼做。
Q：Houdini的軟體在你們的項目和製作管線中的具體定位是什麼？
A：天美對Houdini的定位，首先是原形系統，我做任何過程化工具的時候先在Houdini裡面做，它的優點確實很快，一個TA可能一天製作一個非常複雜的面板。程序在UE4裡面做界面，大家也知道這個很難，Unity可能會好一點。第二點，我們對裡面的節點使用有非常嚴格的控制，如果不用那種循環我們儘量不會用，如果能夠用簡單的腳本語言或者算法語言，基於Vex把你的工具能完成，我們不推薦使用Houdini裡面的節點，這樣保證這個功能將來可以移植到UE4裡面去的，而且有些功能將來可能直接做成Round Time的特性實現，否則如果不這麼控制，每個美術或者每個Houdini的TA在Houdini裡面維護自己一套節點，這就和UE4裡面做材質球一樣。UE4特效可能可以做一個材質球，特殊的需求可以做材質球，大部分材質球還是要基於材質模板，否則每個人連這種圖，到最後會發現連這種圖的除了用的人，其他人根本不了解它怎麼做的。而且像複雜的植被，如果不能抽象成一個節點，會導致你到後面的維護節點的成本和Houdini帶來的紅利完全不成正比，會花很多時間在維護Houdini上。其實UE4自己也在不斷地更新它的地形系統、更新它的植被系統，所以做過程化的另外一個風險是，如果你的工具鏈不夠完善，就被UE4或者Unity原生的功能超車，這塊要充分考慮到未來會不會有這種可能性。
現在的幾點，首先我們的節點全是Vex做的，我們的節點布局是Python控制，我們所有節點布局可以通過Python腳本和類似的文件描述。如果我們想要一套節點是讀一個腳本，自動化把所有節點創造出來，把每個語言的功能塊做成VEX單元組合起來，你可以理解我們的Houdini是全程序化控制，不需要美術做任何參數，美術的需求是他們提要求，我們繼續提供最後的方案。
Q：過程化管線推進方面有什麼心得？怎麼更方便讓這個技術落地到項目裡？
A：你用過程化或者用到Houdini就要發揮它的優點，優點就是快。用一個功能讓美術等三天或者一個星期，實際上是有問題的。我之前舉的例子，包括王者、CF、CODM，給Houdini管線的時間只有兩三個月，我們從定製管線到最終做完以及上線只用幾個月時間，特別是CFM和CODM，我們去年10月份開始做，11月份CFM的管線已經做完了植被就可以上線。剩下這些人直接跑到CODM繼續開發，CODM兩個月之後場景完成，結果是如果你想落地，第一點要做到的是趕上產品製作的流程，不管方法是不是優雅，你想用上它就得盡力讓它在這個時間點支持你的項目。很多項目組也推廣他們自己的Houdini，但都沒有天美落地的順暢。他們統一的問題都是一個，實際上這個東西不是你做了好看的工具或者感覺非常花哨的功能，這個東西就有用。實際上是需要考慮到美術的訴求。
另外，Houdini為什麼能夠迅速在上面三款項目落地？因為Unity的編輯器很爛，這三款老的遊戲都是用Unity5的，如果用Unity，到Unity2018以後，2019的地編功能就非常強了。UE4也是一樣，UE4目前的版本不能很好的支持超過10層以上的地形圖層的管理，40層以後沒有辦法管。那圖層的修改、維護就得進到Houdini裡面做，很大的緣故是當你的技術或者當你的需求、當你的引擎沒有辦法去替它做更多的支持的時候，其實Houdini確實是很好的軟體。包括以前日本很多遊戲公司直接拿Maya、Max做編輯器也是這個道理，當你的人員沒有辦法支持到項目的需求，項目又想在某個點上能夠有自己的突破或者是爆發的時候，那麼Houdini確實是一個非常方便的工具，因為只要有策劃、只要有美術，它自己就可以搞定事情，不需要程序做過多的幹預。