Unity Labs：AutoLOD自動化性能提升的實驗

作為數字3D內容的創造者，我們總希望自己的作品能呈現出它們最好的一面。在某些情況下，我們對目標硬體具有完全的控制，因此我們可能會試圖將渲染能力推向極限。在其它情況下，我們可能會嘗試創建一個在各種硬體上都能運行的體驗效果。

動機

無論哪種情況，我們都可以通過選擇一些性能優化方式，改善CPU和GPU的運行時間。例如：遮擋剔除（Occlusion Cullings）、紋理圖集（Texture atlasing）、靜態和動態批處理、GPU實例化（GPU instancing）、著色器回退（Shader fallbacks）、多線程、光照貼圖、優化垃圾回收、腳本等。在3D圖形方面，對網格使用多個不同的LOD（Levels of detail）是一種已經過驗證且可靠的技術。

LOD0是傳統的原始網格，每一個增加的LOD是對上一層LOD的多邊形數量進行抽取或減少後所得

如果LOD技術已經被驗證是可靠的，那麼為什麼還要討論它呢？因為可用的LOD還不夠完美。

以下任何一個原因，都可能使無法充分利用LOD的優勢。

需要藝術家來處理LOD。例如：單獨處理，通過UI來對它們進行批量處理等。

需要建立一個自定義管線。

涉及一些軟體工程方面的工作。

涉及對工作流程的不同階段中使用的各種產品進行評估，但是各種生產方式之間可能各不相同。

最終可能需要權衡使用LOD的利弊。

綜合上述原因，我們在Unity Labs中嘗試了一個實驗性項目AutoLOD，用來挑戰針對LOD使用的障礙。

你可以訪問Github來獲取試驗中所使用的代碼：

https://github.com/Unity-Technologies/AutoLOD

GIF

從上面的動態圖中，我們可以看見左邊是傳統LOD的渲染，平均30 fps，與右邊SceneLOD的渲染，平均42fps的對比。放大到最大時，傳統LOD需要大約9 ms / 7 ms (CPU/GPU),而SceneLOD只需要大約1 ms / 0.5 ms (CPU/GPU)。

注意：顏色的不一致是由於當前SceneLOD所使用的著色器的關係，這個著色器是可以自定義創作的。

在每個回放窗口的下面是分析器的一個錄製窗口。在左邊，你可以看到渲染開銷隨著顯示的場景內容的增多而激增。在右邊，當Hierarchical LOD開始起作用，渲染成本就維持在了一個相對恆定的水平。你可以關注右側的最小CPU使用率，這是繪製調用次數減少的結果。

願景

我們希望AutoLOD項目是探索出Unity中一個自動化可擴展和可插入的LOD系統的輪廓，以支持渲染密集型項目並作為繼續LOD研究的一個實驗平台。

首先讓我們來定義這些術語：

自動化是指使用合理的默認值來自動生成LOD，通常能使項目以更好的性能運行。

可擴展是指默認的LOD生成器和運行時可被擴展和/或重寫（例如：離散與連續）。

可插入是指第三方可以創建他們自己的LOD生成器，用以替代默認的LOD生成器。

目標

實驗項目最初的目標是：

基於導入模型生成具有合理默認值。

項目範圍或單個模型的LOD導入設置。

GPU加速的默認LOD生成器*1。

非同步可插入的LOD生成框架。

SceneLOD支持下的層級式LOD*。

能與使用其它LOD技術的LOD生成器匹配的可擴展運行時。例如連續LOD，視角依賴LOD等。

允許進行LOD生成器比較的「工作台」場景。

由於時間關係，我們並沒有完全達成所有目標。但是這個實驗是成功的，因為部分願景已獲得實現。現在讓我們深入了解其中的一些細節。

LOD生成

要實現LOD生成自動化，就需要找出適用於絕大多數項目的合理默認值。所有專業的LOD包都帶有大量的滑動條和開關按鈕，理想情況下，這些僅在自動生成的LOD太糟糕時才會使用到。在Edit ->Preferences中，可以進行項目範圍的設置。

如果生成的LOD不正確，還可以針對每個模型文件進行重寫。

我們可以為某個文件單獨更改Simplifier/Batcher下拉框的設置，或者直接關閉導入時自動生成，並手動提供LOD。甚至可以在LOD鏈中添加額外的LOD。這個LOD鏈會被包含到項目中導入版本的模型文件之中，因此無需使用額外的預製件來設置LODGroup。

SceneLOD

SceneLOD的靈感來自於Erikson, C., D. Manocha和 W. Baxter發表的論文2001 I3D Paper。我們決定創建一個與Unity中現有的LODGroup組件一起工作的實現，這樣就不需要一個定製版本的Unity了。LODGroup組件的體積包圍盒層級（目前是一個八叉樹），控制著使用哪個LOD被用於渲染場景。

2001 I3D Paper：

https://www.cs.unc.edu/Research/ProjectSummaries/hlods.pdf

為什麼是HLOD？

HLOD（Hierarchical Level of Detail）作為一種性能優化，將場景中的獨立網格進行分區，以便能使用一個組合的網格進行代替。

傳統的LOD會根據屏幕大小、距離、視角或其它指標來選擇一個合適的網格表示物。無論選擇哪個LOD，每個渲染的網格都需要增加一次額外的繪製調用。傳統LOD的局限性是繪製調用次數在總量上沒優化，因為每個對象的LOD鏈是單獨評估的。靜態批處理只解決了部分問題，因為它只根據共享材質進行合批。繪製調用通常會加重CPU的負擔，所以減少繪製調用次數能提高CPU的性能。

HLOD通過將特定空間內的所有對象組合成一個單一網格，並利用紋理圖集來實現單一材質，可以減少繪製調用的數量。對於希望在整個場景中顯示全景視圖的遊戲，HLOD能極大的提高性能。在其他情況下，當被作為一組組合網格時，HLOD可能會勝過單個LOD的質量。HLOD的缺點是，在BVH每個節點上的每個HLOD網格都需要額外的內存開銷。

性能分析

我們對Asset Store商店中POLYGON-CITY資源包中提供的一個演示場景略作修改。在5秒內，使用Timeline將一個攝像機從一個近距離視圖放大到整個城市的視圖。測試是在筆記本上進行的。

讓我們看看傳統LOD和HLOD的分析器視圖。

隨著攝像機鏡頭的放大和更多場景的顯示，上圖傳統的LOD顯示了CPU和渲染開銷的增長。

對於HLOD，在回放剛開始時傳統的LOD是激活的，這就解釋了剛開始時的渲染開銷。最終一旦HLOD被充分利用後，性能就會接近恆定的CPU和GPU消耗。BVH評估即決定哪些HLOD需要渲染也需要一些CPU消耗。

下面實驗是在整個場景呈現在遊戲視圖中（攝像機固定）和統計窗口打開的情況下進行的。

靜態批處理需要將場景中所有對象標記為靜態，然後點擊播放

實例化需要在所有使用的材質中啟用GPU實例化

正如我們看到的，針對一個大型城市場景，HLOD比傳統的LOD在性能上提高了1425%，並且將繪製調用數量從1487次減少到僅僅只有6次！

然而，當構建的場景是傳統LOD通常無法處理的時候，HLOD才會真正發揮巨大作用。

這個示例場景中包含了原始場景的4個副本，總共有620萬個三角形和11655個批處理。渲染速率為83.3ms/43.9ms（CPU/GPU），低於交互響應率。

現在將它與相同場景的HLOD版本進行比較。

儘管三角形的個數增加到700萬，但仍然以1ms/0.4ms（CPU/GPU）的速率進行渲染，並且只有6個批處理。請記住：儘管副本來源於原始場景，即使城市的每個部分都是獨一無二的，你也可以期待有同樣的性能表現。

存儲成本

在一次構建中，SceneLOD將增加靜態網格和紋理的大小，但如果BVH深度也同時減少，這可以相應減少。

HLOD：紋理 36.3 mb 5.3%網格 599.9 mb 87.6%

LOD：紋理 20.3 mb 20.9% 網格 30.0 mb 30.8%

磁碟上未壓縮的HLOD網格的大小是1.1GB。

時間成本

一次性

HLOD實現在BVH生成和每個從LOD生成分離出的HLOD生成都有一次性的成本。在場景中添加、移動或刪除對象時，這些一次性計算成本將會隨時產生。但是SceneLOD會跟蹤這些變化，並在後台自動的更新BVH和HLOD。

動態

每當一個攝像機渲染時，遍歷BVH並決定在渲染前啟用哪些LODGroup組件是非常必要的。

結語

我們發現自動化LOD能夠解決一部分在數字化內容創作中存在的痛點。合理的默認值能滿足項目的大部分需求，而如果發現有任何網格存在問題，可以根據具體情況對它們進行單獨修改。SceneLOD提供了一個HLOD的示例實現，可以用於當前Unity版本的大場景中。如果你願意用存儲成本來換取性能，對一個擁有很多靜態元素的特大場景來說，你有可能可以將其渲染性能提高一個數量級。

我們希望這個實驗項目能使開發者對自己項目中遇到的性能問題有一些深入的見解，並且讓你有能力去構建更為複雜的場景。未來的工作方向還有很多，比如支持動態對象、更好地壓縮磁碟上的HLOD、默認的LOD生成器、用於HLOD渲染的不同的著色器配置以及性能優化！

更多Unity最新技術內容盡在Unity中文官方論壇（Unitychina.cn ）！

技術直播

5月30日晚，新一期的Unity官方技術直播課程，Unity技術經理成亮將帶你了解Unity 2018中的漸進光照貼圖Progressive Lightmappe。

直播地址：https://connect.unity.com/events/unitychina-progressivelightmapper

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