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

東寶網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)！從網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、響應(yīng)式網(wǎng)站等網(wǎng)站項目制作，到程序開發(fā)，運營維護。創(chuàng)新互聯(lián)從2013年開始到現(xiàn)在10年的時間，我們擁有了豐富的建站經(jīng)驗和運維經(jīng)驗，來保證我們的工作的順利進行。專注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)。

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

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

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

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

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

兩種性能分析工具

Profiler窗口工具

 

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

Frame Debugger

 

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

---

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

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

1. 決定要被渲染的對象

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

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

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

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

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

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

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

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

由于多線程渲染是一項復(fù)雜且依賴硬件設(shè)備的工作，我們在優(yōu)化方面就必須考慮是什么導(dǎo)致了我們的CPU瓶頸。如果問題是出在CPU花費了很多時間執(zhí)行剔除工作這個線程上，那么你從CPU發(fā)送指令到GPU的這件事上進行優(yōu)化也是于事無補的，因為它們不在同一個線程。

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

Graphics jobs選項

這個選項用戶可以通過打開player settings找到

 

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

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

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

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

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

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

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

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

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

針對這三條，我們進行展開

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

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

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

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

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

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

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

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

其中就拿 渲染路徑（rendering path）來說，選擇什么樣的渲染路徑會產(chǎn)生非常大的差異。大多數(shù)情況下，如果我們的設(shè)備是比較高端的硬件設(shè)備，選擇 延遲渲染（Deferred Rendering）相比 前向渲染（Forward Rendering）要更合適，因為它的特性可以讓你使用更多的實時光照，陰影和反射。而前向渲染更適合低端的硬件設(shè)備上，同樣的渲染量上，它對于GPU的開銷沒有那么大。到底誰更好，具體情況具體分析。

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

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

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

III . 如何將被渲染對象進行合批，減少batch?

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

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

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

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

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

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

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

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

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

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

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

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

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

標(biāo)題名稱：Render中關(guān)于Unity渲染優(yōu)化的方法是什么
本文地址：http://chinadenli.net/article30/gpppso.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站排名、面包屑導(dǎo)航、網(wǎng)站收錄、網(wǎng)頁設(shè)計公司、響應(yīng)式網(wǎng)站、品牌網(wǎng)站設(shè)計

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)