如何用UE4移動渲染器開發高品質手游？

註明：本文雖然講述的是使用UE4移動渲染器開發手游，但在如何做渲染和優化等方面的內容很值得我們移動VR遊戲開發者借鑒，希望本文能幫到大家。

隨著移動設備性能的不斷提高，高品質手游的畫面表現力也越來越強，甚至不少人認為3A畫質將成為未來手游的標配。那麼如何來製作和渲染高畫質的移動端遊戲？

引擎開發與支持工程師Jack Porter出席Unreal Open Day活動時，介紹了移動端的渲染器與桌PC渲染器延遲渲染器和VR的前像渲染器的區別，並還原了移動端完整一幀渲染的流程。同時對於大家關心的下載包大小優化以及光照設置也進行了解答。

以下是演講內容：

Jack Porter：大家好，我從1998年就加入Epic games開始製作遊戲，目前負責移動端的開發，今天為大家分享UE4移動渲染器的一些功能。

現在AAA級的手游畫質已經接近主機遊戲的品質，並且可以做到在手機上跑起完整開放世界的多人在線遊戲，就像剛才介紹過的天堂2重生。雖然只在韓國那麼小的地方發售，已經成為了發售後月收入最高的遊戲之一。

這是天堂2重生的一些截圖，已經非常像一個標準的PC MMO，明顯提升了大家對移動設備上的MMO畫面品質的預期，我相信很多人都想複製這樣的成功。這個遊戲也沒有什麼自己的黑科技，就基本上是使用了Unreal自帶的所有工具，測試和工具都是PC平台上。

在UI使用上他們使用了常規的引擎自帶的UI級的編輯器，至於多設備的適配是使用了我們的developed工具，可以支持安卓和平果這樣的設備。

移動端的渲染器與桌PC渲染器延遲渲染器和VR的前像渲染器的區別

現在Unreal引擎支持三種渲染器模式。最普通的是延遲渲染器，這個渲染器在PC包括編輯器模式下以及主機模式下都是默認使用的，對應的feature levels我們叫SM4和SM5。還有一個是我們針對VR做的前像渲染器，剛剛大家可能看到過了，這個渲染器和延遲渲染器基本是一致的，除了少了個別的效果，比如說屏幕空間特效、SSR之類的。

feature levels其實就是我們可以做選擇的幾級feature ，不同的feature levels可以影響你在材質編譯器裡面使用feature 的功能。同時feature levels同時也決定了哪個渲染器會被使用。

在移動端feature level有ES2和ES3，不等於OPEN級ES2和ES3，feature levelsES2也可以跑3.0的feature ，只要你的硬體支持。其中ES2也是移動端最穩定最常用的一個feature level。

feature level開關選項可以使得美術製作師在製作材質的時候區分不同的feature材質的功能和表現。在編譯器裡面有一個預覽渲染等級的選項，可以針對不同的feature level顯示最後渲染的效果。

正如剛才所說ES2是最常用最穩定的，因此較早或者最新的設備都是可以使用的。我們在打包的時候把對應的都打包到版本里，會根據你的硬體自動動態的編譯需要使用的shader。

但因為feature level還是與ES2的feature level掛鉤的，所以有一個限制是在低端設備只支持ES2的情況下，引擎沒有辦法進行自動識別。

然後是我們的延遲渲染器，原先最低支持的feature level是SM4，是針對IOS10的，現在IOS A8設備也可以使用。之前我們猜想未來移動端走向是可以使用延遲渲染器，但是最近的一些趨勢讓我們覺得以後還是在高端移動設備上嘗試使用現在我們新引入的給VR用的FOR Renderer。

最常見的延遲渲染器，shaderMobile，包括支持主機平台和使用 Mobile的Meta平台以及安卓的Vulkan。我們之前做過一個移動端的demo使用的設備是3.1加上安卓的擴展支持，當時是跑在一個K1的平板上，也就是在K1上延遲渲染器是可以跑這個的。本來我們以為以後趨勢是高端的設備可以使用這樣的延遲渲染器，現在我們發現這個路走不太通，因為這兩個移動的GPU設計和PC比較像，而其他的都不是，所以最後我們將Mobile5服務的VR的渲染器移植到高端的移動端。

在編譯器中，支持open3.1的有兩個改動，代碼層級會包括對應的ES3.1和overridden渲染器，同時也會生成支持ES3.1和Vulkan。如果你們把這些都勾上發布到不同的設備上，引擎會自動幫你選擇這個設備所支持的最好的feature level。

在安卓7系統已經默認帶有Vulkan的驅動，Vulkan一個比較好的地方是提供了更底層更輕度的API，有了PSO的概念，以前里繪製一個東西你要設置shader、頂點數據等一大堆，都要佔用CPU內存。現在只要設置屬性，傳了以後就能繪製出來。

Vulkan也更好的支持了現在移動端的GPU的硬體設計。這是去年我們跟三星合作做的第一個支持Vulkan的demo，叫原星，是第一個在安卓設備上可以跑ES3.1的feature level的demo。

Color Buffer和LDR模式

Color Buffer，在HDR模式下我們會用到一個16位附點的Scene color。在延遲渲染器下面我們有辦法會把各種東西塞起來，但是在移動端的前像渲染器我們直接把最重的顏色繪製到16位附點，所以你可以存高動態範圍的顏色。大家可以看到右上角圖片是高範圍的Scene color輸出的一張圖，保留了很多顏色範圍的細節，包括雲這裡的高亮的白色以及陰影下比較暗的黑色。

當然移動的顯示屏幕是並不支持高端範圍的輸出，所以我們會把色調影射後再處理，影射為一個32位的Backbuffer。下面這個圖是最終影射完之後的Backbuffer，亮的地方也沒有之前那麼亮了。

剛剛我們就說了在HDR下我們需要16位附點64位的，但是畢竟有一些設備我們希望能跑HDR，但是不支持16位附點，只支持32位的。我們在支持這些擴展的設備上，比如S6我們用了一些東西來展示效果。

LDR是直接渲染出來的模式，這個模式下我們直接把顏色寫回了最終的backbuffer，這是最快最有效的性能。因為這個模式下的backbuffer是在EGL中申請的，所以引擎沒有辦法直接操作和訪問，導致了很多效果在這個模式下沒有辦法支持，比如說一些後期處理的效果，包括一些延遲和shader。

做移動VR的MRP模式 移動渲染器中完整一幀的渲染

這個模式主要我們用來做移動端的VR，大家知道它對性能要求比較高，需要跑到60禎，我們還在做一些改進。完整的一幀渲染在移動渲染器是如何進行的？

第一步我們做的是可見性，我們會用距離裁減以及預計算的可見性剔除不需要的物體。

在這之後我們會做GPU之後的一些模擬，在做這些模擬的時候我們會輸出兩張，一張是用來存位置，一張用來存速度。每一幀模擬的時候我們會從這兩個貼圖裡讀取前一幀數據然後再寫回。

下一步渲染Shadow Map，無論你用什麼，都是在這個時候生成的。CSM是整個場景一起繪製的，而Shadow Map不是。一般Shadow Map渲染都是光源的位置渲染儲存它的深度信息。

接下來是Base Pass，會置整個場景，包括計算光照和投影。shader組合情況比較多，可能是動態加靜態光照，也可能是帶距離的投影加上Shadow Map。這可能會最終導致你的APK包比較大，包含了大量的shader，甚至大部分是無用的。

好在4.14以上的版本我們已經在編寫中剔除掉一些不會用到的組合。動態的物體在場景裡面移動可能受到光照的結果計算都不一樣，所以我們每幀都會計算。但是對於靜態的物體我們只會第一次加到場景計算一次。

經過Base Pass以後，我們已經把各種動態和靜態的光照投影和反射繪製完。

接下來是繪製的順序的排序問題，這個與設備有關，比如說GPU。其實你順序無所謂，是不會重複計算的。那麼對於其他的安卓的設備我們一般都會從近到遠排序進行繪製，這樣利用深度緩存就可以防止大量的order depends。

在這種排序的情況我們有兩種可選的方式，一種是直接從近到遠的排序。還有一種模式是我們把材質用一樣的東西併到一起，能減少狀態切換，渲染現成的CPU就可以。默認我們是使用前後排序的，如果你用了很多不一樣的材質導致你的狀態切換特別多，開銷很高，可以採用第二種方式，對於高通的GPU特別有效。

Base Pass後有一個延遲的貼花，我們這裡只有最後的顏色信息，所以我們的延遲的貼花在移動端是不支持和光照計算的，Modulated Shadows也是用於延遲計算。因為在這個時候只能訪問前面整個計算完的顏色，所以存在一個很大的問題，不能將動態的投影和靜態的投影融合起來。所以4.12以後的版本我們推薦大家使用靜態的陰影加動態的CSM。

在這之後我們會畫半透，因為半透不能寫到深度。

完成半透後我們就可以做後處理。可以完成一項DOF的效果，也可以自定義你的效果。最後做色調映射到低動態的範圍屏幕上的顏色。

光照和投影的組合

第一個是全動態的光照。開發世界用這樣一個全動態地光照設置，不需要計算大量的光照貼圖的數據，所以包體和內存都是比較小的。

缺點在於，因為高品質的投影本來都是靜態，在這種情況下就沒有了，所有的東西都會繪製到CSM，精度會不夠，開銷也比較高。

最簡單的固定方向光的設置，所有的東西都是計算好的，所以效率相當高，品質也相當的好。

問題在於大型的MMO遊戲可能包體和內存佔用都比較大。

在最近的版本中我們加入了固定方向光加上CSM shadows，將兩者很好的融合起來。剛開始的時候，需要手動選擇哪些可以接受靜態的CSM shadows，哪些是動態shadow。新的版本以後這個設置就是自動的。

缺點在於動態的CSMshadows會有額外的開銷。另外一個限制是它會額外的佔用你一張紋理採樣，所以ES2隻有八個採樣的情況下會吃緊一些。

我們也支持動態的點光源，這個也沒有額外的開銷。缺點是它可能會導致shadows組合數量變多。從4.15開始我們在movable有一個排列組合，如果整個項目都沒有用到動態點光源可以把組合勾掉，可以最大的減少最後生成的shadows量，減少包體的大小。

4.13以後的版本我們支持了Lighting channels。如果一個物體設置了同樣的通道，他們就會互相影響，而不會影響其他的通道的場景。左邊是有一個綠色的點光源和一個藍色的方向光，右邊這個圖我們把綠色點光源放到了一個Lighting channels裡面，所以大家可以看到綠色的點光源隻影響了左邊，沒有影響其他的場景。Lighting channels的缺點在於，目前同時只有一個方向光可以影響每個物體。

新版本我們引入了影射化的色調編譯器。4.15我們想使整個引擎的渲染變得更加物理真實，所以我們默認打開了tonemapperfilm。這導致Post Process在移動端效果很好，但是開銷也大了不少。為了解決這個問題我們引入了一個分離的變數，專門來控制Mobile，在PC編譯器你可以打開，移動編輯器你可以關閉。

在最近的4.13以後的版本里我們加入了自定義後處理材質的支持，設計師可以自行定義後處理流程的一些效果。

與之配合的Custom Depth，會額外的輸出depth buffer，來繪製你上述的效果。有了這個功能就可以把這個獨立選中設置的對象提高到Custom Post Process中使用，比如高亮勾邊效果等等。

在最近的版本里我們還加入了Custom Stencil，存一個Stencil WBuffer值。除了渲染的我們還做了一些其他的針對移動設備的一些改進。

下載包的設置

大家都希望初始包是最小的，僅包含初始的邏輯。當用戶第一次打開下載應用的時候，會檢測，有精度調UI，再去伺服器端抓取實際的數據包。這個好處在於可以強制用戶每次打開的時候更新版本，而不需要去應用商店裡更新應用。這種設置其實相當複雜，因為需要設置哪些才是初始的包，哪些做DLC，要做很複雜的管理。

因此我們做了這樣一個嚮導的窗口，通過問一些問題，設置好一些資源路徑，自動生成初始包和接下來下載的DLC數據包。用戶打開應用時，會檢查SD卡剩餘空間是否足夠，是否連接WIFI等。基於這些需求我們把這些功能都包裹在了一個叫Mobile patch Utilities的庫中，大家可以使用它。

國內有些渠道廠商可能希望一次打包，因為二次下載肯定會有流失。針對這種情況，大家可以看到右面的圖是在國內上線的APK包的情況，其實是沿用了我們以前的方式，是一個小包加下載內容的形式。

以前超過兩G的打包，由於谷歌API的問題，虛擬影射會佔BSS，BSS超過兩個G有的時候就會崩掉。現在已經沒有任何阻礙，你想分包，無論多大的內容打到一個APK包里都是可以實現的。

我們在4.16裡面對移動端還做的其他的改進，一個比較重要的是減小了執行文件的大小，包括去掉一些沒有使用的代碼以及一些重複的模板函數。

另外一個比較明顯的改進是在UM級UI的效率上。手游的UI元素很豐富，非常複雜，Imprvement的改進大量的減少了折扣，我們對運行時的許可權管理做了更多的改進，例如不會再應用剛打開的時候就彈提示框告訴你要使用什麼功能，只有在具體第一次使用的時候才會提示，也可以選擇禁止下次使用重新提示。

4.16在裁製編輯器有一個新的功能叫Vertex Winterpolator。之前移動端的shader精度是全精度，有時候使用者會覺得精度不太夠。一種方式是通過UV傳過去，這樣是比較複雜的。現在這個節點就是為了利用UV直接把數據傳給shader，我們推薦使用這樣的方式。還有我們正在做改進的功能，下一個版本還不會放出來，一個是改善項目迭代的時間，例如只改了一點點內容或者改的一點代碼的時候，我們希望用最短的時間重新迭代發布出來。

此外還有預覽移動端效果的改進，以及希望在PC端直接打包，利用遠程的Mak系統來編譯和發布到IOS的功能。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！