目錄

1. 簡介
2. 功能與支持
3. 技術決議
4. 實際使用中的擴展
5. 改進的地方

一、簡介

HLOD System主要的目標是為了減少Draw Call，然后，進行更多的Batch批處理，其次，減少面數和紋理，這樣我們相應地節省了記憶體，并提升了加載時間，
HLOD System只針對當前所在的地方進行加載，它會流式加載網格和紋理，在后臺進行異步的操作，

本篇文章將細說Unity官方的HLOD做了什么作業以及他們是如何做的，另外一些技術細節可以回過去看這篇文章：https://blog.csdn.net/qq_33700123/article/details/113835834，這是作者自制的HLOD，測驗得出性能和記憶體方面并不遜色于Unity官方HLOD，區別在于有一些思想不一樣，且官方HLOD做了根據材質球合并以及TerrainHLOD，

原始碼鏈接：https://github.com/Unity-Technologies/HLODSystem

未來官方HLOD會出現在Package Manager上，官方說的，

二、功能與支持

模式

常規HLOD：簡單合并、按照材質球分類合并

TerrainHLOD：針對地形生成HLOD

HLOD管理腳本如圖

ChunckSize：模型劃分時區域模型數量超過時分割子節點

The HLOD treew will be created with 2 levels：生成時設定運行時切換點

MinObjectSize：剔除小于該值的物體加入HLOD System

Simplifier：在生成HLOD節點的時候會減面，見面會根據HLOD層級遞增

Batcher：

Batcher:SimpleBatcher(簡單合并)、MaterrialPreservingBathcer(按材質球合并)

Streaming：

Streaming:Unsupported（默認常駐記憶體）、AddressableStreaming(使用新AB方式進行流式加載)

CompressFormat：合并的大貼圖將會設定的格式，

簡單合并

作者上篇文章自己寫的hlod是只有簡單合并的功能，簡單合并就是將模型根據4或8叉樹分割，然后根據分割的每個部位合并，不同材質球不同貼圖將會被合并成一張大貼圖供一個材質球使用，所以簡單合并會多出合并的大貼圖和新創建的材質球，大貼圖是增加記憶體的主要原因，

按照材質球合并

與簡單合并不同的是，在對每個HLOD節點合并的時候，會將該節點相同材質的模型合并成一個模型，這樣合并后的模型不需要創建材質球和貼圖就可以直接用已有的材質球，每個節點會出現合并的模型1到n個，

TerrainHLOD

BoderVertexCount：地形按照多大的尺寸切割

針對地形H官方用了另外一個腳本管理，官方是將地形切割成多塊并轉成Mesh，然后原理與簡單合并一樣進行，

三、技術決議

技術主要點：mesh劃分、mesh合并、如何運行、流式加載，

我會按照順序從生成到運行一一決議，

Mesh劃分

首先劃分是以四叉樹進行劃分，劃分的物體型別分為兩種：單純的mesh、LodGroup，

單程的mesh計算單位就是它的包圍盒大小，LodGroup計算單位就是將所有mesh作為一個整體生成一個剛好把它們包圍的包圍盒作為計算單位，

在劃分的時候首先將所有有效mesh作為一個整體生成一個最大的包圍盒，然后將被完全被這個包圍盒包裹的單位添加進去，當數量超過設定的最大值時四叉樹分割子節點，以此類推不斷遞回直到分完，

如圖，粉紅色和黑色圈因為完全被各自區域包裹所以被加入到該節點，因為父節點是這4個節點的集合大小，理所當然所有父節點也包含了它們，紅色的這種其實已經被父節點包裹了，在子節點下是不可能有任何節點會完全包裹住它，所有紅色的在出現與節點交叉的時候注定不會再被分到之后的子節點，

Mesh合并

在mesh被劃分好后就對每個區域進行合并，

簡單合并：將區域里所有模型合并成一個大模型作為這個節點的模型，貼圖也合并成一張大貼圖并創建一個新的材質球，在這里如果設定了減面，那么合并的模型將會被相對減面，

按照材質球合并：如圖兩個圈分別是分別是質球的模型，那么就合并成2個大的mesh，并將舊的材質球分別賜予，這種合并節省了記憶體，

如何運行

在上述mesh生成的時候，在每個節點生成后會計算該節點的包圍盒大小并設定成該層切換大小，

在運行的時候，HLOD會從根節點計算，如果超過上圖High 100%那么就切換成子節點（這種計算依據跟LodGroup一樣，演算法也一樣），在區間則顯示本層，如果小于30%區間將會顯示父節點，小于1%只有最大的節點才有效，因其他節點都有父節點，當到30%的時候就已經切換了父節點，而最大的節點沒有父節點就不會切換，直到Cull，

如下圖：

第一層已經完全超過了100%，因此往下遞回

第二層右邊由于相機離得遠還沒有超過100%因此不切換顯示本層

第二層左邊相機靠得比較近，最左側一直遞回直到遞回到了根節點，右側在倒數第二層由于該節點的包圍盒計算的時候沒有超過100%，因此截至到該層，

流式加載

流式加載運行計算與上述一樣，區別在于資源全部都是使用Addressables在異步做著資源的不斷流式切換，

流式切換的時候由于加載資源需要一些時間，因此官方做了在資源完全加載出來后才能切換，保證不會出現閃爍，且官方考慮到一次性大量切換導致卡頓問題，因此官方限制了只能一個一個加載，一次性加載多少數量并沒開放，從代碼中可以看到在加載一個資源的時候m_isLoading被設定成false，直到加載完才設定成true，在true的時候其他資源先在佇列里等待，

三、實際使用種的擴展

資源

這里就要提到官方生成出來的資源到底長得什么妖魔鬼怪了，如圖所示，

作者：大吃一驚，我，，，，二個月前生成出來的還是原始mesh，現在竟然改成了fbx，本人費勁九貓二鼠之力才改成fbx的，現在官方竟然也改了，我不服啊（提示：這里官方沒修改，是作者本地自己修改了忘了還原以為是官方的，作者已轉UE4，也不做本章博客更新了，，），

之前官方沒改的時候由于是原生mesh沒經過壓縮，因此會很占用磁盤空間的哦，

流式加載方式

作者還是留了一手，這是官方沒有做的哈哈哈，

官方的流式加載是需要Addressables支持的，在實際專案很多有自己的資源管理方式，比如傳統的AB模式，因此呀，我這就介紹下如何魔改擴展，

1、復制粘貼這個腳本改名成自己的名字

2、在這個腳本上看到了流式資源加載的來源地方，只要把這個資源來源換掉就好啦，

3、為了讓unity的代碼不要浪費，我就繼續套娃下去，進去看看這個腳本在做什么，

4、這不是之前貼過的代碼嘛，沒錯，就是的，這里上面有一點沒有說，在每個資源被加進來時候都會根據自身的權重與佇列里的所有等候者權重對比，權重越靠近0的越先被加載，因此怎么添加如代碼所示，

5、還是在當前腳本，找到如下代碼，這里就是Addressables加載資源的根處，我們只要把這個改成自己加載資源的介面，這樣就ok啦，

6、在生成HLOD的時候，設定的一些相關屬性的時候會將資料設定到這個腳本，

當自己復制了這個腳本做了自定義的時候把它的Editor腳本也相應自定義，在這個腳本上對應一下這個腳本修改，當然官方的Addressables有很多操作是將資源加入Addressables Groups里以便運行能正確加載，代碼都在這個腳本Build方法里，這里就需要將這些操作改成將資源地址寫入到運行腳本上，這里操作比較多我就不再贅述了，思路說出來了就ok，

五、改進的地方

1、官方HLOD每顆HLOD樹都是所有節點都會合并，這就導致一個場景要分很多HLOD樹，而作者的HLOD是可以整個場景生成一個HLOD，設定合并層，假設設定合并最底層3層，那么最終只會合并最底下3層，相當于官方HLOD創建了N顆樹，

2、由于每顆樹都是在不斷遍歷，因此可以適當加點條件，比如移動了，相機轉動了才計算，可以把遞回改成非遞回

3、如果場景HLOD樹的量很大，就像作者的那樣，一顆大樹生成下面有好多的子樹，由于HLOD計算的演算法都是一毛一樣，這樣那么多樹是可以并行計算的，那么就可以試著把并行計算改到JobSystem上計算，這樣這部分計算消耗就不用擔心了，