Render中關(guān)于Unity渲染優(yōu)化的方法是什么

本篇內(nèi)容介紹了“Render中關(guān)于Unity渲染優(yōu)化的方法是什么”的有關(guān)知識(shí)，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

哪些屬于渲染產(chǎn)生的性能問題？

首先，要明確一點(diǎn)：整個(gè)渲染工作只有當(dāng)CPU和GPU完成了各自全部的任務(wù)時(shí)，才能成功渲染出一幀畫面。任意一個(gè)任務(wù)執(zhí)行超時(shí)，都會(huì)導(dǎo)致整個(gè)這一幀的渲染延時(shí)。

渲染問題一般可分為兩類，第一種是由低效的渲染管線引起的。渲染工作中的一步或多步耗時(shí)過長(zhǎng)，執(zhí)行效率低下，打斷了平滑的數(shù)據(jù)流，便會(huì)導(dǎo)致低效的渲染管線，這種現(xiàn)象我們也稱之為 渲染瓶頸（bottlenecks）。第二種是由于一口氣向渲染管線發(fā)送過多的指令引起的渲染瓶頸。

當(dāng)我們發(fā)現(xiàn)游戲里渲染一幀需要很長(zhǎng)的時(shí)間，而且與CPU的執(zhí)行效率有關(guān)，這種情況我們稱之為 CPU瓶頸（CPU bound）。同樣的，當(dāng)我們發(fā)現(xiàn)游戲渲染一幀時(shí)間過長(zhǎng)與GPU花費(fèi)了大量的時(shí)間進(jìn)行渲染計(jì)算有關(guān)，這種情況我們稱之為 GPU瓶頸（GPU bound）。

在對(duì)我們的代碼進(jìn)行修改之前，通過合適的性能分析工具來定位渲染性能問題很重要，要對(duì)陣下藥，當(dāng)然合理的對(duì)我們的修改進(jìn)行評(píng)估也很重要。性能優(yōu)化是一種權(quán)衡行為，可能對(duì)這方面性能的改善會(huì)給其他部分帶來負(fù)面影響。

兩種性能分析工具

Profiler窗口工具

 

Profiler 窗口 工具可以讓你實(shí)時(shí)監(jiān)控游戲性能的表現(xiàn)。我們可以通過Profiler工具看到我們游戲中的許多方面，包括內(nèi)存使用情況，渲染管線使用情況，以及用戶腳本使用情況（代碼質(zhì)量）。

Frame Debugger

 

Frame Debugger 可以讓我們看到游戲每一幀是如何一步步渲染的。它可以讓我們看到更多的細(xì)節(jié)，包括每一個(gè)draw call它讓GPU渲染了哪些東西，它影響了shader代碼塊中的哪些屬性 以及 CPU 發(fā)送給GPU的事件，這些信息將幫助我們理解我們的游戲是如何渲染的，并且該如何改進(jìn)我們的性能表現(xiàn)。

如果渲染問題是由CPU瓶頸（CPU bound）引起的

一般來說，CPU這部分工作與渲染相關(guān)的步驟如下：

1. 決定要被渲染的對(duì)象

2. 準(zhǔn)備要發(fā)送給GPU的數(shù)據(jù)

3. 發(fā)送指令給GPU

這些步驟由許多獨(dú)立的任務(wù)組成，而這些任務(wù)又多線程來處理。多線程可以同時(shí)處理多個(gè)任務(wù)。這意味著整個(gè)渲染工作可以更快。我們也稱這種工作模式為多線程渲染（multithreaded rendering）。

Unity的渲染進(jìn)程主要由三種類型的線程來執(zhí)行：主線程，渲染線程，工作線程。

主線程主要是處理CPU的大多數(shù)任務(wù)，包括部分渲染任務(wù)。

渲染線程顧名思義，專門是處理那些CPU發(fā)送給GPU的指令的任務(wù)。

工作線程中的每個(gè)線程各自都處理一個(gè)任務(wù)，比如一些剔除任務(wù)或材質(zhì)蒙皮任務(wù)。

至于哪些任務(wù)由哪些線程來處理主要取決于我們?cè)陧?xiàng)目中的 設(shè)置（settings）以及我們項(xiàng)目運(yùn)行的 硬件設(shè)備（hardware）。比如，內(nèi)核越多的CPU，就擁有更多的工作線程。因此，同一款游戲在不同的設(shè)備可能表現(xiàn)截然不同。

由于多線程渲染是一項(xiàng)復(fù)雜且依賴硬件設(shè)備的工作，我們?cè)趦?yōu)化方面就必須考慮是什么導(dǎo)致了我們的CPU瓶頸。如果問題是出在CPU花費(fèi)了很多時(shí)間執(zhí)行剔除工作這個(gè)線程上，那么你從CPU發(fā)送指令到GPU的這件事上進(jìn)行優(yōu)化也是于事無補(bǔ)的，因?yàn)樗鼈儾辉谕粋€(gè)線程。

當(dāng)然，也不是所有的平臺(tái)都支持多線程渲染，至少在寫這篇文章時(shí)，WebGL還不支持這個(gè)功能。如果一臺(tái)設(shè)備不支持多線程渲染，所有的CPU任務(wù)都將被同一個(gè)線程執(zhí)行，這樣雖然在渲染效率上不如其他設(shè)備，但是一旦發(fā)生了CPU瓶頸，你的任何針對(duì)CPU方面的優(yōu)化手段都會(huì)提升CPU的表現(xiàn)。

Graphics jobs選項(xiàng)

這個(gè)選項(xiàng)用戶可以通過打開player settings找到

 

它的功能是決定unity是否使用工作線程來處理渲染的任務(wù)，如果不勾選，則主要還是使用主線程或渲染線程。在支持graphics jobs的平臺(tái)上，勾選該選項(xiàng)，可以很大提升性能表現(xiàn)。大家可以自行測(cè)試觀察性能效果。

向GPU發(fā)送渲染指令

一幀向GPU發(fā)送過多的渲染指令，在 CPU瓶頸（CPU bound）中是最常見的問題，這個(gè)任務(wù)在大多數(shù)的平臺(tái)上都是發(fā)生在渲染線程上，但是某些平臺(tái)（如PS4等）是發(fā)生在工作線程上。

這類任務(wù)中開銷最大的操作要?dú)w咎于向GPU發(fā)送 SetPass call 的指令，減少它的請(qǐng)求次數(shù)是優(yōu)化這類任務(wù)的最佳手段。

我們可以通過Profiler窗口中 Rendering的部分看到到底有多少SetPass call和batch被發(fā)送到GPU。當(dāng)然，根據(jù)目標(biāo)硬件的不同，對(duì)SetPass call的數(shù)量的承受度是不同的，比如PC客戶端能接受的數(shù)量要比移動(dòng)設(shè)備多許多。

我們可以通過以下手段來減少SetPass call和 batch的數(shù)量：

• 減少被渲染物體的數(shù)量可以減少 SetPass call 和 batch的數(shù)量

• 減少被渲染物體的請(qǐng)求渲染的次數(shù)可以減少SetPass calls的數(shù)量

• 將被渲染物體的數(shù)據(jù)進(jìn)行合批，可以減少batch的數(shù)量

針對(duì)這三條，我們進(jìn)行展開

I . 如何減少被渲染物體的數(shù)量？

減少被渲染物體的數(shù)量是最簡(jiǎn)單的方式來提升渲染性能表現(xiàn)，我們可以通過以下幾個(gè)方法：

1. 減少在場(chǎng)景中相機(jī)可見（視錐體）的被渲染物體的數(shù)量。比如，如果我們渲染一群各不相同的角色，我們可以嘗試去掉幾個(gè)，然后看一下效果。這比用復(fù)雜的技術(shù)去進(jìn)行優(yōu)化來的快得多。

2. 我們可以通過使用相機(jī)的 遠(yuǎn)裁減平面（Far Clip Plane）屬性進(jìn)行控制，這一點(diǎn)跟第一條的原理是一樣的。

3. 我們可以通過改變相機(jī)的 遠(yuǎn)近剔除（Layer Cull Distances）屬性來自定義對(duì)渲染對(duì)象的剔除距離。這種方法一般多應(yīng)用于非常小的物體（比如草地上的花卉），一旦距離相機(jī)超過一定的距離，即使在相機(jī)的視錐體內(nèi)，也不進(jìn)行渲染。

4. 我們還可以使用相機(jī)上面的 遮擋剔除（occlusion culling）選項(xiàng)，顧名思義，如果一個(gè)被渲染對(duì)象完全被另一個(gè)被渲染對(duì)象遮擋（相對(duì)于相機(jī)），那么它將不會(huì)被渲染。但是，occlusion culling 選項(xiàng)并不適用于所有場(chǎng)景，慎用。

II . 如何減少被渲染物體的請(qǐng)求渲染的次數(shù)？

我們都知道，實(shí)時(shí)光照，陰影和反射會(huì)給游戲增添許多真實(shí)感，但是也會(huì)產(chǎn)生巨大的開銷。因?yàn)樗麄儠?huì)導(dǎo)致同一被渲染對(duì)象被多次渲染，這將大大影響性能。

其中就拿 渲染路徑（rendering path）來說，選擇什么樣的渲染路徑會(huì)產(chǎn)生非常大的差異。大多數(shù)情況下，如果我們的設(shè)備是比較高端的硬件設(shè)備，選擇 延遲渲染（Deferred Rendering）相比 前向渲染（Forward Rendering）要更合適，因?yàn)樗奶匦钥梢宰屇闶褂酶嗟膶?shí)時(shí)光照，陰影和反射。而前向渲染更適合低端的硬件設(shè)備上，同樣的渲染量上，它對(duì)于GPU的開銷沒有那么大。到底誰更好，具體情況具體分析。

動(dòng)態(tài)光照 很昂貴，在優(yōu)化方式上面也很復(fù)雜， 感興趣的小伙伴可以點(diǎn)擊前方傳送門。如果場(chǎng)景中有很多被渲染物體不會(huì)移動(dòng)，可以考慮使用 光照烘培（baking）。這樣在游戲運(yùn)行時(shí)就可以不用考慮動(dòng)態(tài)光的計(jì)算。

陰影 的質(zhì)量可以通過 Quality Settings 來進(jìn)行設(shè)置，比如，我們可以通過設(shè)置陰影距離（Shadow Distance）來控制多少距離以內(nèi)物體之間會(huì)投射陰影。

反射 的優(yōu)化比較復(fù)雜，這里也不展開，留下傳送門。

III . 如何將被渲染對(duì)象進(jìn)行合批，減少batch?

被渲染對(duì)象必須具備以下要素符合合批條件

• 共享同一材質(zhì)實(shí)例

• 有相同的材質(zhì)配置（貼圖，shader，shader參數(shù)）

盡管合批渲染對(duì)象可以提升渲染性能，但是也需要考慮如何確保合批產(chǎn)生的消耗不超過性能的收益。

以下是一些關(guān)于合批的方法：

1. 靜態(tài)合批（Static batching），這種方法可以把鄰近的符合條件靜態(tài)的渲染對(duì)象進(jìn)行合批。靜態(tài)合批會(huì)導(dǎo)致較高的內(nèi)存占用，所以我們也需要考慮它的利弊。

2. 動(dòng)態(tài)合批（Dynamic batching）是另一種技術(shù)，允許unity非靜態(tài)的對(duì)象進(jìn)行合批，但是有一些限制。同樣的，動(dòng)態(tài)合批會(huì)導(dǎo)致CPU比較搞的內(nèi)存使用，我們也需要權(quán)衡利弊。

3. UI方面的合批，UI元素相對(duì)來說有一些復(fù)雜， 它是受制于我們的UI層。

4. GPU instancing 選項(xiàng)可以讓許多同樣的渲染對(duì)象非常高效的合批。但是它受限于硬件設(shè)備。

5. Texture atlasing 圖集，可以把重復(fù)使用的圖片合并到一張更大的貼圖上。這個(gè)技術(shù)在2D游戲和UI系統(tǒng)中應(yīng)用比較多，3D游戲也可以使用。Unity有一個(gè)內(nèi)置圖集工具叫做 Sprite Packer。

6. 我們還可以通過unity編輯或代碼人為地對(duì)網(wǎng)格和貼圖進(jìn)行合并，當(dāng)然這么做的話需要知道這些渲染對(duì)象的陰影，光照和剔除都仍然會(huì)各自處理。這意味著你通過合并材質(zhì)達(dá)到提升性能的目的會(huì)與通過剔除渲染對(duì)象以至于不渲染它達(dá)到的效果相抵消。

7. 我們需要注意在腳本中當(dāng)通過 Renderer.material 來對(duì)材質(zhì)進(jìn)行操作，引擎會(huì)復(fù)制一份實(shí)例并返回它的引用，也就是說你的操作只會(huì)在它被復(fù)制的實(shí)例上進(jìn)行，不會(huì)影響到它原來的材質(zhì)，如果你想通過代碼來修改多個(gè)共享材質(zhì)的渲染對(duì)象，你需要使用 Render.sharedMaterial 。

“Render中關(guān)于Unity渲染優(yōu)化的方法是什么”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！