查看引用/信息源請點擊：映維網

開發移動VR內容時應避免的PC渲染技術

（映維網 2019年11月25日）有不少開發者都是以與PC相同的方式來開發Quest游戲，但這可能會導致優化性能方面出現大量困難。Oculus軟件工程師特雷弗·達什（Trevor Dasch）的工作是幫助開發者構建高質量的游戲，并確保它們能夠以穩定的72FPS速度運行。日前，達什撰文分享了在為移動VR開發內容時應該避免的PC渲染技術。下面是映維網的具體整理：

盡管移動芯片組可以支持下面概述的大多數技術，但我們強烈建議你不要這樣做。不過，這并不總是一成不變的規則，因為我有看到開發者有實現下述技術但依然達到幀速率的要求。但通過避免下文提及的PC渲染技術，你會為自己省下大量的麻煩。

1. 延遲渲染

延遲渲染（或延遲著色）這種技術是將光照/渲染計算推遲到第二步進行計算。這樣做的目的是為了避免多次渲染同一個像素。延遲渲染主要分為兩步：在第一步中，渲染場景，但只是簡單地將幾何信息（位置坐標，法線向量，紋理坐標和反射系數等等）存儲在中間緩沖區中；在第二步中，從中間緩沖區讀取信息，應用反射模型，計算出每個像素的最終顏色。延遲渲染對PC開發非常有效，因為它可以將幾何圖形與照明分離，你只需更新每個照明所觸達的像素，即可在更少的GPU周期內渲染更多照明。

為何不適合移動開發？

原因有很多，但主要是因為解析成本。什么是解析費用？在我告訴你什么是解析成本之前，你首先需要理解基于圖塊渲染的工作原理。

為了以更低功耗實現更高的吞吐量，移動GPU（如Oculus Quest中的驍龍835）通常采用基于圖塊的架構，其中每個渲染目標都分解為塊狀網格或“圖塊”（從16×16像素到256×256像素之間，具體取決于硬件和像素格式）。接下來，你的幾何會“綁定”到圖塊，然后再提交給異步處理器，異步處理器執行渲染工作并計算每個“圖塊”的圖像結果。計算完每個圖塊圖像后，GPU必須從片上內存中將圖塊復制回通用內存。這實際上非常慢，因為它需要通過總線傳輸數據。我們將這個轉移過程稱為“解析”，所以花費的時間稱為“解析費用”。

因為要渲染的每個紋理都需要解析，并且延遲渲染需要在計算照明之前渲染大量紋理，所以你的解析成本將從正向渲染的大約1ms增加至3ms以上。如你所見，你可能沒有這樣的時間。

除了解析成本問題之外，延遲渲染僅在幾何形狀復雜且有多個光源的情況下才能顯露出優勢。無論如何，移動設備都真正實現這兩者，因為GPU用來處理大量頂點和計算計像素填充的能力有限。

目前的答案是堅持采用正向渲染。

2. Depth Pre-Pass

Depth/Z Pre-Pass是一種常見的技術，其中所有場景幾何圖形都作為第一步渲染，無需填充幀緩沖區，僅生成深度緩沖區值。然后，你渲染第二通道，檢查每個像素的計算深度是否等于深度緩沖區中的值。如果不是，則可以跳過對這一片段的著色處理。由于處理頂點的速度通常比像素著色快得多，所以可以節省大量時間。

為何不適合移動開發？

首先，如果在提交繪制調用之前對幾何進行排序，通過進行Depth Pre-Pass而節省的片段填充時間應該最少。來回繪制會導致常規深度測試拒絕你的像素，所以你只能避免對未正確排序或兩個對象在不同點彼此重疊的幾何圖形進行像素填充。

其次，這需要繪制調用加倍，因為你必須先提交所有內容以進行Depth Pre-Pass，然后再才是Forward Pass。由于CPU的繪制調用已經相當沉重，所以你需要避免這種情況。

第三，所有頂點都需要處理兩次，與通過避免填充少數像素兩次而節省的時間相比，你通常增加的GPU時間會更多。這是因為移動設備的頂點處理會在PC耗費更多的時間，并且處理片段的時間同樣相對較少。

3. HDR紋理

解析成本與圖像中的字節數直接相關，而不與像素數直接相關，所以，盡管我們通常以32位RGBA像素來思考量度，但如今大多數開發者都在使用HDR紋理，即每像素64位。這會將你的解析成本增加一倍，并且由于顯示器僅支持每通道8位，所以你在解析HDR紋理時會浪費大量時間。更不用說移動GPU是針對32位幀緩沖區進行優化。

4. 后處理

后處理是一種經常用于為游戲施加多種效果的技術，如Color Grading，Bloom照明和運動模糊。具體的實現方式是獲取游戲渲染的輸出，然后對圖像運行全屏通道以產生新圖像，然后再將其呈現給玩家。一些后期處理效果是作為一個額外的通道執行（如顏色分級），另一些則需要多個通道。

對于移動設備，后處理的主要問題同樣是解析成本。生成第二張圖像將引起另一次解析，并會立即消耗大約1毫秒的時間。更不用說計算后處理效果所花費的時間，取決于效果，這可能會占用大量資源。所以，最好避免進行后處理。

以下是替代常見后處理效果的方案：

1. Color grading：與其在后處理中執行Color Grading，不如在每個片段著色器的末尾添加一個函數調用以執行相同的數學運算。這將產生相同的視覺結果，但無需額外的解析。
2. Bloom：真正的Bloom效果非常耗時。最好的選擇是“偽造”。采用包含blob紋理的billboarding sprite可以產生非常接近的效果。

5. 實時陰影

我認為這是最有爭議的一項技術。一系列具有完整實時陰影的應用已成功支持移動設備。但是，這樣做存在大量的折衷，而我認為值得避免使用。

實時陰影的一種常用技術是級聯陰影貼圖，這意味著場景會以各種視口大小進行多次渲染。對于必須由GPU處理的幾何，這會令次數增加1到4倍，這從根本上限制了場景可以支持的頂點數量。它同時增加了陰影貼圖紋理的解析成本（與紋理大小有關）。在GPU管道的另一端，在對陰影貼圖進行采樣時有兩個選項：硬陰影和軟陰影。硬陰影可以更快地渲染，但具有不可避免的鋸齒問題。

由于陰影貼圖的工作方式，這個測試只能得出二進制結果。你無法對陰影貼圖進行雙線性采樣，因為它表示深度值而非顏色值。應該避免使用軟陰影，因為它們需要將多個采樣放到陰影貼圖中，而這當然很慢。最好的選擇是烘烤所有可能的陰影，而如果需要實時陰影，請尋找另一種方法。如果照明大部分都是漫反射，則通常可以接受blob陰影。如果需要強光照明并且陰影表面是平面，則幾何陰影的效果同樣相當出色。

6. 深度（及幀緩沖區）采樣

對于PC，你可以在著色器中采樣當前的深度紋理（Unity將其顯示為_CameraDepthTexture）。之所以可行，是因為深度紋理只是PC上的另一種紋理，并且由于每個繪制調用都接連發生，所以深度紋理的狀態將是上一次繪制調用之后的狀態。但對于基于圖塊渲染，當前深度不在紋理之中，而是僅存儲在你的圖塊內存中，所以無法將其作為普通紋理進行采樣。

考慮到上述情況，有一個GLES擴展可允許你查詢深度緩沖區（和幀緩沖區）的當前狀態。問題是它們非常慢，只能支持你對相同像素的值進行采樣（無法查詢附近的像素），并且在啟用MSAA時它們會產生一系列的問題。

啟用MSAA時，圖塊實際上具有一個足夠大，能夠容納所有采樣的緩沖區（即2×MSAA的像素為2倍，4×MSAA的像素為4倍）。這意味著默認情況下，如果對深度緩沖區進行采樣，則必須按每個采樣執行片段著色器，這意味著時間密集度將比預期高2倍或4倍。存在一種“解決方案”，即調用glDisable（FETCH_PER_SAMPLE_ARM）。但這樣做的問題是，它將僅檢索第一個采樣的值，而不是混合采樣的結果，所以在啟用所述功能后，MSAA將被禁用。

除非絕對必要，否則你應避免它們對幀時間產生的影響。

7. 幾何著色器

幾何著色器允許你在運行時生成額外的頂點，這對于諸如動態細分等功能十分有用。但是，對于基于圖塊渲染的GPU而言，幾何著色器會產生問題。生成額外頂點的步驟阻止了合并過程的進行，這意味著GPU不能這樣做，所以它會切換為“立即”模式（完全跳過分塊過程）。可以猜到，這非常緩慢。所以，最好避免使用幾何著色器，并且如果有必要，選擇CPU生成頂點。

8. Mirrors/Portals

如果你用天真的方式實現它們……對于“天真的方式”，我是指分配兩個眼睛緩沖區大小的紋理，計算反射矩陣，然后將場景渲染到兩個紋理中。然后，你的mirror幾何將進行屏幕空間紋理采樣，從而顯示反射。這種方法存在眾多明顯的缺陷：

1. 繪制調用增加了兩倍。
2. 填充的像素比屏幕可見的像素要多。
3. 必須解析另外兩個紋理。

我發現的最低提升是限制了mirror camera的視口，并更改了相應的投影矩陣，只能在視錐中渲染camera平面邊界框。這對上面的第二點問題有所幫助。理想情況下，你同時可以使用多視圖，通過一組繪制調用來渲染左右眼，但Unity目前不支持這項功能，它不能解決上面的第三點問題 ，并且會令第二點問題更加惡化，因為你只能為兩只眼睛使用單個視口，所以你必須使用兩個mirror邊界框的重疊。所以，理想的解決方案將首先解決第三點問題，這意味著一次繪制mirror場景和非mirror場景。

有一種解決方案可以利用修改后的著色器和模板緩沖區。場景中的每種材質都將具有兩種版本的著色器，一種僅在模板緩沖區中的特定位為0時繪制，而另一種僅在1時繪制。然后，你將使用材質繪制mirror網格。它會在模具緩沖區中設置所述位，使用第一組著色器繪制場景，使用反射矩陣設置camera，并且在最后使用第二組著色器繪制場景。這將產生你想要的反射，同時不會填充超出所需像素的像素，并且避免了不必要的解析。然而，它無法避免繪制一堆對象兩次（任何解決方案都無法避免）。

盡管這聽起來很容易，但如果是使用Unity，你將會遇到很多問題（我在Unreal中沒有遇到過，但你可能會遇到類似的挑戰）。首先，在啟用Single Pass Stereo（多視圖）后，Unity將不允許你修改camera的投影矩陣，所以你不能使用反射camera（如果關心CPU性能，你絕對應該使用這個camera）。其次，這沒有考慮Late-Latching（在渲染線程啟動時更新camera矩陣，從而盡可能減少延遲）。通常來說，這是一次純粹的勝利，但如果你使用mirror camera，則反射camera的變形將不再與頭部變形匹配，所以你會得到奇怪的偽影，鏡面中的元素不會按照預期方式排列。

最簡單的解決方案是“偽造”。如果你的鏡面是靜態，則只需創建所有世界幾何的反射副本，然后將其放在場景中即可。你需要使用腳本來移動任何動態對象的“反射”副本，從而模仿包括玩家在內的“真實”版本位置，但這將是最快、最簡單的渲染解決方案，無需復雜的矩陣數學。如果可以看到鏡子后面，你將不得不使用兩組具有不同模板蒙版的著色器，但如果玩家由于墻壁等原因而無法看到后面，則可以只保留一組著色器。

9. 總結

無論你是從零開始一個新項目，還是要從PC移植到移動設備，明確哪里可以沿用原有的知識經驗，哪里又需要采取創新的解決方案是獲得最佳游戲效果的關鍵。 但是，你不必遵循本文的建議。請自由探索，并尋找最適合自己的方案。

---
原文鏈接：https://yivian.com/news/69240.html