《使命召喚手遊》引擎技術經驗分享

在由Unity舉辦的Unite Shanghai 2019開發者大會上，騰訊互娛天美工作室群技術副總監郭智（專家工程師）帶來了題為“《使命召喚手遊》引擎技術升級與演化”的分享，介紹了畫麵呈現標準建立、AAA級手遊製作管線等方麵的經驗，以下為演講實錄，一起來看下這篇《使命召喚手遊》引擎技術經驗分享！

《使命召喚手遊》是由動視與騰訊合作帶來的、麵向全球FPS手遊玩家的“使命召喚”正統手遊續作，如今中國區已開啟官網預約。

按照Unity大會的國際慣例，我先介紹一下自己——2011年入職騰訊，在騰訊互娛天美工作室群任職技術副總監、技術專家，負責工作室手遊客戶端的研發和一些管理工作。曾經負責過不同品類項目的開發，用過一些自研和商業引擎，做過幾款FPS遊戲，今年剛好是我從業的第11年。

2017年是手遊畫麵升級的元年，對於今天的引擎技術的話題，我們首先要聊一聊畫麵呈現標準的建立。畫麵呈現標準可能對許多人而言比較陌生，一般大家說的都是要用哪幾張貼圖、怎麼做，畫麵標準都是美術師去定的。 COD手遊目標是打造3A手遊畫麵呈現，所以必然要探索PBR時代畫麵呈現的最佳實踐與升級。

對於整個IP產品來說，首先是要定義製作的主基調。在一開始COD手遊立項的時候，我們為了性能糾結過一段時間：要不要使用Phong的模型，要不要使用最經典的手繪模式。去年我們對COD手遊的畫麵做了重大的翻新，使用PBR複刻了整個主機的畫麵效果。我們需要挑戰的是達到主機畫麵的豐富度和還原度，去滿足整個IP高端用戶的主機情懷。

既然我們要做PBR，首先要做的第一件事就是需要統一製作管線和技術管線。對於製作管線來說，美術需要的所有貼圖資源，都需要在線性空間計算，用任何工具去製作任何貼圖，都需要是線性的。對於技術管線來說，需要為引擎定義統一的渲染管線，也就是說我們的渲染管線是通過技術做Scalable的HD渲染管線。對於高配進行HDR的RT輸入，對於低配來說為了節省性能不能做任何的後處理，就使用OnePassHDR的管線，使用Tonemapping在最終的shader做相應的數學擬合，來擬合我們的目標曲線。

整個的製作管線和技術管線建立之後，我們再說畫麵標準的建立。對於畫麵呈現來說，我們需要一致的畫麵標準——比如這個角色，每個像素我們都要定義得非常標準，其實在國際標準上，任何3A遊戲裏麵都會這麼定義，要定義Material Model、Lighting Model、Shading Model。標準建立了，就可以用同樣的語言說話，如果沒有這個標準，美術同學會說我要這樣貼圖，這裏麵畫點光上去，要做一些陰影的效果。統一標準之後，在團隊裏麵，每個場合裏麵就不會再有分歧和異義，討論起來非常簡單。這些標準都是具有物理意義的參數和基於真實物理的定律，也就是遵循PBR的。還有一點是全場景物理一致的光照環境，也就是說我們要使用動態的光影+PBR+IBL。

接下來介紹這三個方麵，Material、Lighting和Shader，在COD手遊裏麵到底是什麼樣的。

先看一下shading model是什麼。我們構建了完整的手機平台的PBR光照方案，對PBR進行分級，提出4級的PBR的數學擬合。最高級肯定是給現在的835這些係列的高端的GPU去用的，3級就是在520這種機器，2級給更低端的機器，最後一級為那種兼容性有問題的機器去使用，解決所有的兼容性問題。而人物在高中低配都使用最完整的PBR方案，也就是說不會做Shader LOD的切換。直接光用了GGX specular+lambert diffuse，間接光用cubemamp做GI Specular，用SH probe做GI diffuse。

對於建築來是，出於性能考慮，低端會簡化一些光照的部分，就是剛才說的Shader LOD。直接光其實會在遠景用shadowmask，直接光不會烘焙進lightmap，直接光用純動態的光照，間接光用的是IBLcubbmap+GPU bake的lightmap。

再來看material，固有色、一張法線+粗糙度合並的貼圖、金屬度+AO放在另外一張貼圖。材質接受了lightprobe的間接光照和一個直接光，還有來源於environment的間接光，最後得到整體的呈現，這就是我們的material model 和lighting model。

確定這些東西以後我們要討論的是製作本身。我相信一些開發者可能不太在意製作管線，但是2017年之後，大家都知道TA其實是比較吃香的。還有我認為所有技術人員都要了解美術的工作、甚至要了解策劃的一些工作，這樣才能把遊戲製做好。所以我們來聊一聊3A級手遊裏麵的製作管線是什麼樣子的。

製作過程中的核心因素，第一個是量產。所有的遊戲現在最慢也要3年出來，但是往往我們沒有那麼多的錢或者時間，所以我們需要做大量的外包。需要保證我們所有的外包、開發、美術標準都統一，才能達到量產。第二個是引擎，現在對於任何引擎我們都覺得要做成我們自己認為一兩年後所看到的最好的樣子。最後一個方麵是性能，無論是主機平台還是PC平台、手機平台都是非常重要的，要有最流暢的體驗。這三個因素決定了我們整個製作管線。

對於製作管線來說，我覺得使用流程與工具去保證美術素材的正確性與合理性，原則有兩個：一個是美術素材都是符合PBR標準的，也就是說你不能畫各種陰影，你的色彩、明暗不能大於推薦值的範圍；原則二：我們需要統一所有的生產規格和生產環境，這一切達到之後才能量產化。達到統一規格之後你的畫麵才是統一的，才是你們認為能夠把握的樣子。

PBR的初衷在歐美所提出的，它的初衷其實不是為了效果，而是為了量產。量產的策略其實有幾個：一個是驗證，我們能盡可能地驗證；一個是文檔，我們需要有各種各樣的白皮書，去闡述我們的思路。最後一個是科學性，PBR誕生本身是工業化的產物，不是美術或者是藝術的產物，所以當你一味強調各種各樣的hack、美術不同的製作方式、TA各種各樣的畫麵雕琢之後，就不可能再科學，團隊會變得不可控，就不可能把遊戲做出來，也不可能有量產。所以如果要做PBR，就一定要遵循這三個原則。

關於驗證，我們需要在sp（Substance Painter）裏麵提供一係列的光照環境給美術做驗證，以前都是在photoshop裏麵做的，但是在裏麵做的任何圖都可能是錯的，都可能讓美術製作失控。所以我們場景製作要符合三大要點，一個是圖形技術的保證，在同樣的一個PBR的光照環境，有95%以上是一致的，怎麼保證一致？大家先看sp裏麵的，再看Unity的渲染管線，就可以保證一致；另外一個是製作環境約束，美術製作者使用的渲染環境必須與標準的光照環境是一致的；再下來是驗收標準的約束，討論素材本身效果品質的時候，隻能參考標準的光照環境，不要在MAX或者是MAYA裏麵打開，也不要在任何引擎或是其他環境裏打開，我們就在標準環境裏麵打開。這樣討論才有意義，不然管線不一致，討論的結果也會有差異。

剛才說驗證的標準場景其實包含一個主場景和六個輔助場景。主場景用於驗證固有色的明暗色相，不同粗糙度表麵的鏡麵反射情況，還有金屬材質的鏡麵反射情況。輔助場景檢驗包括室內外環境光源，暖色調環境下效果，強對比度的明暗光照，還有典型室外光照下效果或固有色是否太黑的環境。我是參考裝修裏麵的原則還有各種各樣抽象出來的環境，這樣能幫助美術師做各種各樣的驗證討論時能看到一些有問題的場景。

有驗證環境之後，要定義好詳細規則的白皮書。這裏麵是我們裏麵的白皮書，比如說輸出是什麼樣子，環境是怎麼配置的，一些漫反射、鏡麵反射率是什麼樣子的，基本是一些數學原理。同時會有一些黑科技作為素材驗證的參考工具，包括屏幕校色器、照度儀，以及一些標準的色，通過這些去做校驗。同時也出去測量SH或者lightmap環境，保證你在房間色調也是一致的。美術在調各種各樣的色彩甚至是光照值都是感性的認識，我們需要給他們一個非常標準和標量的參考。

這個標準能保證我們在製作整個PBR的時候有所參考、有所依據，最後才能呈現很好的畫麵效果。

說完這些，再說一下COD手遊引擎技術的沉澱。上麵兩個部分摻雜TA、美術以及工程師的一些工作，下麵就是相關的純技術人員的工作。其實就是顛覆、拓展整個Unity引擎之路，會作為未來3A手遊引擎實踐的一些標杆。

首先我們需要做的是補齊遊戲裏麵所缺的渲染的東西。比如說頭發怎麼做、皮膚怎麼做、角色怎麼做，這些都要盡可能做補齊。對於一些包含地形的地圖或者是其他技術方案可能要做拓展，比如說到地形，我認為我們應該是在國內工作室中Unity結合houdini應用最多的。我們有這個組合的工作流，還有不同地貌的Drawcall合並，並且支持Vertex fetch texture，我們使用地形的時候，我認為是現在手遊最佳的地形方案，所以我們對地形係統做了深度的改造。

接下來是烘焙。烘焙使用了GPU烘焙，當地形非常複雜的時候，如果用Enlighten就需要通宵的時間。現在我們烘焙複雜度非常高的場景隻需要3-5分鍾，以前烘焙需要4-6個小時，這是不能接受的。出現bug的時候發現同一天就要卡十張圖，會出現無限的加班，這個迭代時間非常重要。用GPU烘焙可以做更多的效果提升，計算正確性和參數科學性有了更強的依據。甚至於可用到一些AI技術，對烘焙結果做一些降噪和算法上的改造，所以我們這邊用了整套GPU的烘焙方案。

我們對烘焙做了深度的定製，也就是說結合houdini做了自動的部署，以前我相信所有美術人員這些Light probe都是用手工一個一個去擺的，擺的純屬人體勞動力，並且不準確，所以我們拓展了整體算法，然後使用程序化自動生成Lightprobe，讓這些迭代更加快速。所有的這些光影可以看到其實是非常密集的，我相信各位如果要做這種遊戲的時候，也可以做這樣的嚐試，算法不是特別複雜。

植被方麵，原來完全是美術製作的，現在很多場景都要用到大量植被，以前的生產方式其實都是美術逐棵逐棵地做，我們現在程序化地生產AO和法線，這樣原來兩周的工作量等於節省到兩天。這些都是很有意義的，省掉大量的製作成本和人力成本，也省掉很多外包的工作，所以現在無論製作什麼，我們都要積極地去擁抱整個PCG的技術，用這些技術助力整個生產過程。

我們生產了很多很多的遊戲，大家可以看到製作標準和美術規格也是非常高的。如何保證整體製作和引擎和性能能夠保證一體化呢？我們所有程序和管線的製作都是要後期去進入的。比如我們用了4張貼圖都是零散的貼圖，我們肯定要有自己的一些技術。美術原來做的所有的都是零散的貼圖，事後會對它的圖進行整理和整合，這樣避免一開始就定規範和美術討論我的貼圖如何分配、如何做這種性能的保證。

注：圖中文本應為Texture Atlas

此外我們會用一些Texture Streaming之類的技術保證包括iPhone 6的機型兼容。所以整個製作過程都不會打亂美術的工作流，直到後續再做優化，我們會用一係列的技術比如說Texture  atalas、Texture Streaming、PBR Shader lod等，這樣後續進入優化階段也能做到性能的動態收縮。

最後一部分更為重要，就是做引擎改動的時候，需要了解引擎技術的演化。最近麵試了很多候選人，聊了很多行業裏麵的大咖，對不同層次的開發人員做討論。大家在做修改的時候，我覺得很多時候是沒有依據的，可能是在翻博客時突然發現一個技術就拿來使用。在我們的技術裏麵。我們團隊非常注重引擎技術的演化，包括最重要的三個方麵，一方麵是引擎技術的移動端化。從2017年到現在，可以認為所有PC Game技術都可以在移動端使用了，如果現在不能使用，我相信未來兩三年也可以。比如現在流行使用線性空間的運算、做PBR渲染、做霧和大氣的效果，會做渲染標準的一些更新，這些其實8年前我在端遊就做過了。但是現在手遊再次使用，所有技術都是端遊往手遊做演化，我們隻是做相對的數學擬合和科學性的一些探索。所以大家做手遊移動端化的時候，一定要注意端遊技術的移動端化。

另一方麵是引擎技術與工具的升級，引擎版本不斷升級，我第一次使用Unity的時候是4.5的版本，現在這個遊戲基本上可升到五點幾。這些引擎的不斷升級對底層的改造是比較大的，比如現在Unity ECS，各方麵的烘焙方式、各方麵的技術也都在做升級。所以升級引擎的時候你要想到用引擎升級的那一個遊戲，做一些你自己最穩定的技術演化。再加上現在的工具也在不斷地發展。近幾年其實用Substance與Houdini，之後這一係列的美術工作在團隊裏麵普及越來越明顯，所以我們需要使用所有的工具做配合進行遊戲的製作。

最後就是芯片的發展。芯片發展會更快，可以認為現在芯片可以達到了五六年前渲染的一些量級，隻是功耗沒有跟上來而已。所以我們基於現在芯片發展趨勢可以做的事會越來越高。我們團隊其實也在做一些PRT的動態GI的效果，我覺得這些將來都會變成可能。大家在一些高端平台上做這些特性，可以給遊戲加分。再加上現在業界一些前沿技術的推進，也會讓你整個手遊更邁進一步，比如說RTX光線追蹤，現在都在討論要不要用RTX做光線的一些烘焙方案，我們自己用過光線追蹤的渲染技術，發現它的理想效果會大有增益，可以做很多你想不到的東西。

再加上過程化製作，我前麵其實演示了很多過程化製作的內容，有些部分沒有在這裏講，但是從2018年開始，過程化製作已經深入到我們每一個製作過程——比如說植被立型、任務、AI還有玩法本身都可以參與到過程化製作。再加上最後一點，可能對國內來說有點前沿，就是Machine Learning。現在整個匹配算法還有後麵的AI，我們都會嚐試使用Machien Learning做探索，這些技術都會推動我們引擎技術不斷演化。

今天和大家講的就這麼多，謝謝大家。

作者：郭智 

來源：騰訊GWB遊戲無界