VR游戲相對傳統(tǒng)游戲，個人認(rèn)為主要有三個方面的不同：玩法設(shè)計，輸入方式，性能壓力。今天就來談一下VR游戲中的性能優(yōu)化。
為什么VR游戲的性能壓力很大?
·??主要有三個因素的影響：高幀率，高分辨率，畫兩遍，影響權(quán)重由高到低。
·??高幀率：DK2為75，最新的CV1是90；HTC Vive為90；PS4 VR為120。對比PC游戲的60以及主機游戲的30，壓力可想而知！
·??需要說明的是鑒于幀率這么高，每一幀即便2ms的提升意義也巨大。即便以75為例，每幀時間為13.33ms，2ms占比15%！
·??高分辨率：DK2為1920 * 1080，最新的CV1為2160 * 1200；HTC Vive為2160 * 1200；PS4 VR為1920 * 1080
·??除了賬面分辨率之外，實際渲染時為抵消透鏡畸變帶來的分辨率損失需要超采樣，具體：DK2為135%，CV1和HTC Vive都為140%
·??即使以DK2的數(shù)據(jù)：1920 * 1080 @75Hz來說，每秒的像素處理量為283 millions， 這個數(shù)據(jù)4倍于一般的主機游戲！更別忘了，最新硬件的這個數(shù)據(jù)提升至457 millions
·??畫兩遍
方法一：依次畫兩遍場景
， SetTexture，SetTransforms，SetViewport，切換RenderState，DrawCall等均翻倍
方法二：依次畫兩遍物體
，相比較方法一有節(jié)省，但DrawCall依舊翻倍
關(guān)于像素處理部分
通過上面的數(shù)據(jù)可以看到其實VR游戲性能壓力主要集中在像素處理方面，那么如下和像素處理相關(guān)的部分就要特別注意：
·??光影計算方案的選擇：空間換時間尤為重要，light map、靜態(tài)AO，環(huán)境反射貼圖等能上就上，dynamic shadow在任何時候能省則省。
·??后期處理：不用的效果統(tǒng)統(tǒng)干掉。如DOF、Motion Blur、Lens Flare等本就不適合VR游戲；SSR、SSAO等盡量用前面說的靜態(tài)方案來替代；
AA也可以不用，因為已經(jīng)有Super Sampling了
·??特別注意OverDraw的問題：典型的如范圍巨大的透明面片特效省著點用，不要動不動疊加個7、8層。
·??Shader復(fù)雜度問題：UE4的viewmode里面有一個是專門查看shader復(fù)雜度的。一般來說，出現(xiàn)粉色和白色的情況說明shader太復(fù)雜了，需要修正。
原理：
延遲渲染已經(jīng)成為各大引擎的標(biāo)配，很多人覺得對于延遲渲染來講，early z culling沒有存在的必要，畢竟生成GBuffer之后 相當(dāng)于已經(jīng)做了像素級別的culling，而且多了一個pass提前寫深度往往得不償失；
但early z culling針對延遲渲染的受益部分主要在GBuffer的 生成階段，傳統(tǒng)游戲這部分相對于lighting計算階段開銷不大，所以往往被忽略掉，但VR游戲中受制于超大的像素處理量，這部分的優(yōu)化提升 在我們游戲中經(jīng)過測試是相當(dāng)明顯的。
當(dāng)然，世事無絕對，這里僅作下提醒，實際要根據(jù)自己的游戲場景做下詳盡的測試。
關(guān)于畫兩遍批次翻倍加上面數(shù)翻倍因此VR游戲中優(yōu)化批次和面數(shù)較傳統(tǒng)游戲的意義更大。
·? ?靜態(tài)場景的批次優(yōu)化：針對UE4，我們專門做了擴展工具來合并場景中相同物體的批次，而不需要美術(shù)對已經(jīng)做好的場景進(jìn)行返工。絕大多數(shù)情況下，這事總是程序開發(fā)效率對美術(shù)制作效率的妥協(xié)，程序逃不掉的：）
·??動態(tài)批次優(yōu)化：多用instance的思想合并數(shù)量巨多但因個頭小而往往被忽視的物體，典型的如FPS游戲中的子彈。
·??其實優(yōu)化中很多這樣的情況，比如不起眼的string對性能和內(nèi)存造成的巨大的壓力（當(dāng)然如string相關(guān)的如此底層的優(yōu)化，現(xiàn)代成熟引擎已經(jīng)都做好了）
·??面數(shù)：對UE4而言，其消耗體現(xiàn)在生成GBuffer的Base pass階段，要善用統(tǒng)計工具去定時定性得分析游戲場景；
·??另外關(guān)于面數(shù)除了美術(shù)提供的靜態(tài)場景和角色之外一定要關(guān)注下自動生成的東西，如tessellation；工具可能也會統(tǒng)計不到。
·??舉例：UE4中Ribbon特效的tessellation默認(rèn)步長為15uu，而我們游戲中的Ribbon特效可達(dá)30000uu,如果不改變默認(rèn)值，一條拖尾可生成4000面，同屏50條拖尾就令絕大部分GPU歇菜了
·??特定游戲中特例化的問題防不勝防，應(yīng)善用不同工具從多種角度分析。
其他
當(dāng)然，前面講的都是針對VR游戲的特點來重點強調(diào)的，其他的優(yōu)化方法同樣使用，根據(jù)之前的經(jīng)驗做下總結(jié)，包括但不限于：
·??對表現(xiàn)效果妥協(xié)，如很多手機平臺的游戲角色連normal都沒有。。還有貼圖精度，模型精度等
·??對制作流程 、制作效率的妥協(xié)。如開發(fā)無盡之劍XboxOne版時發(fā)現(xiàn)，UI直接調(diào)用d3d API畫的。。
·??開發(fā)效率的妥協(xié)。 注意shader中的數(shù)據(jù)類型，頂點的數(shù)據(jù)格式等，能用16位浮點就不要用32位的浮點
·??游戲類型具體分析，比如如果確定場景中物件都必須渲染則把Ocullusion Culling關(guān)掉，因此這種情況下不需要預(yù)計算遮擋剔除關(guān)系！
·??特別注意下CPU、GPU的同步點，線程之間的同步點（多發(fā)生在競爭統(tǒng)一資源上，如主線程和第三方庫的線程用同一個內(nèi)存分配器）
·??善用第三方庫站在巨人肩膀，比如小內(nèi)存多，分配頻繁自己又懶得寫內(nèi)存庫的話，干脆用tcmalloc、nedmalloc等
·??多用LOD，不只是貼圖mipmap、模型LOD等這種，還有邏輯層面的LOD，如特效分層LOD
·??不同Actor、不同Component、不同系統(tǒng)設(shè)置不同的更新頻率
·??多線程加速、SIMD加速
·??很track的做法：避免使用基于win32 API的高級函數(shù)，例如memeset，因為這個是單字節(jié)填充；可用匯編進(jìn)行優(yōu)化，效率提升明顯（當(dāng)然成熟引擎不需要操心這點）
其他方案
除了這些，業(yè)界還有些全新的優(yōu)化方案，這里也做下介紹。
·??多/雙顯卡渲染：
·??DX12支持顯卡混搭，可把render task綁定到任意GPU上
·??Nvidia的SLI和ATI的CrossFire可應(yīng)付非DX12的情況，叫法不同但原理相同：一塊顯卡渲染左眼，另一塊顯卡渲染右眼：
要求兩塊顯卡必須型號一致，實測效果很不錯
·? ?StencilMesh的思想，同樣是culling，不過在另外的層面上。UE4中的實現(xiàn)叫做HMD Distortion Mask，實際也是節(jié)省掉周圍四角區(qū)域的像素計算。
·? ?Instanced stereo Rendering：
·? ?核心思想：一次提交繪制雙份幾何體，draw call不需要翻倍了
·? ?UE4的4.11 preview版本已經(jīng)放出了第一個版本的實現(xiàn)
·? ?Multi-Resolution
·??人眼對中心區(qū)域像素更敏感，所以保持中心區(qū)域分辨率并降低邊緣區(qū)域分辨率。整體分辨率降低的同時盡可能抵消對效果的影響。
這種方法可以節(jié)省25%~50%的像素處理量
補充和總結(jié)
其實真正做優(yōu)化之前，有兩點怎么強調(diào)都不為過：
· 穩(wěn)定測試環(huán)境。包括關(guān)閉PC上其他3D程序，關(guān)閉垂直同步，保證每次采樣點以及采樣上下文完全一致，不要以編輯器模式啟動等等。
· 量化觀測數(shù)據(jù)。同一游戲，在完全穩(wěn)定的測試環(huán)境下，前后兩次測試的性能觀測數(shù)據(jù)有有些許浮動都是很正常的，因此直覺不可靠！直覺不可靠！
直覺不可靠！重要的事情說三遍！不要想當(dāng)然的認(rèn)為：”這個沒影響“，”那個沒關(guān)系“，”這次有提升“，”感覺沒作用“等等。捕獲如下精確的數(shù)據(jù)加以分析才是靠譜的做法。
另外，優(yōu)化是一個長期迭代進(jìn)行的過程，中間過程做好記錄；遇到和美術(shù)PK的情況，也要做到盡量用數(shù)據(jù)說話。
聯(lián)系方式：0755-81699111
課程網(wǎng)址： http://www.vrkuo.com/course/vr.html
