1.1 HLOD System簡介
首先，HLOD System主要的目標是為了減少Draw Call。然后，進行更多的Batch批處理，從而大大提高渲染性能，減少面數和紋理，這樣我們相應地節省了內存，並提升了加載時間。
HLOD System只針對當前所在的地方進行加載，它會流式加載網格和紋理，在后台進行異步的操作。
本次HLOD是基於官方AutoLOD代碼的擴展和改進制作出來的，鏈接：https://github.com/Unity-Technologies/AutoLOD，鏈接是AutoLOD的文章，可以先看看。下面將詳細介紹HLOD原理和實現。
1.2 HLOD與LOD對比
HLOD與傳統LOD差異對比如表所示。
|
|
LOD |
HLOD |
| 減面 |
√ |
√ |
| 減少Batches、紋理數量 |
× |
√ |
| 減少內存使用 |
× |
√ |
| CPU性能提升 |
× |
√ |
| 磁盤空間 |
= |
+ |
2.1 系統支持
- BVH划分LOD Group
- 根據BVH划分進行合並模型和貼圖
- HLOD CULL系統
2.2 系統概述
1.系統架構
系統主要由編輯層和運行層組成，編輯層負責每個預制體的LODGroup生成、BVH划分、網格、貼圖合並，同時自動做好運行層所需要的關聯。運行層負責該系統中Renderder、LODGroup管理及BVH層級切換，系統架構如圖所示。
2.系統流程
本套系統擁有一條完整流程，其系統流程如圖所示。
2.3 BVH划分LOD Group
八叉樹對LOD Group進行划分到各個區域，划分條件由每個區域超過n個mesh開始划分，划分依據由LOD Group中心點作為划分點，可設置剔除實際包圍盒超過指定大小的mesh，划分規則如圖2-4所示。
划分后效果如圖所示。
這里划分方式對AutoLOD進行了改進，AutoLOD划分方式如下圖所示，下圖是BVH划分的同一級別中其中的4個區域，圈內是一組LodGroup，AutoLOD在進行BVH划分規則是只要該組LodGroup有任何模型與區域接觸，那么該組LodGroup就會被算入該區域，圖中4角星與2、3、4區域同時有相交，因此在模型合並的時候這3個區域都會將該組LodGroup下的模型合並。假設HLOD切換到了該層級且同時顯示2、3、4節點的合並模型，那么這個LodGroup合並的模型就會被顯示了3份，這樣的效果是不允許的，解決辦法就是同一個層級每個區域不能出現相同的LodGroup。
本次HLOD采用的解決辦法是使用LodGroup的中心點進行划分，這樣就可以保證一個LodGroup最多能被一個區域包含，如下圖所示，箭頭指向的點就是LodGroup的中心點，它只有4這個區域包含。
2.4 根據BVH划分進行合並模型和貼圖
1.合並原理
根據2.3的划分，可以設置合並幾層的模型(從最底下開始計算)，如下圖所示的為合並2層，其中第一層(最底層)有三個區域合並，第二層有兩個區域合並。這里節點比2.3少了，是因為沒用的節點會被剔除掉，如果這里設置只合並一層也就是最底層，那么上面兩層也會被剔除掉。
2.合並的網格
網格每生成一層就會多一倍以上磁盤大小，如果重復的模型多了，那么合並后的網格磁盤大小將會成倍增加，合並后的網格如下圖所示。
例如：（300*300M場景），原始網格6M磁盤空間，合並原始網格兩層后多出20M空間(fbx)。
3.合並的貼圖
如下圖，貼圖目前只保留了MainTex貼圖，默認使用Standard物理光照shader（帶陰影），支持GPU Instancing。
貼圖合並規則如下圖所示，設置合並層次，比如圖中設置3層，那么第三層是所有子節點合集的大貼圖（不重復）。
例如：300*300M場景，原始貼圖大小26M，合並原始網格兩層后多出50M，多出這么多主要是因為把整個場景合並，原始貼圖很多是共用的，導致合並后內存上升問題，所以合並時選擇模型和貼圖復用性低的模型合並比較好。
2.6 HLOD CULL系統
1.如何工作
當上述步驟做好后，在BVH的根節點上會有個HLOD CULL腳本，用於控制當前管理的HLOD的切換。
當攝像機靠近部分精細模型時，HLOD切換狀態如圖2-10所示（紅色為當前顯示的層級，藍色為不顯示層級）。
當攝像機靠近少部分精細模型時，HLOD切換狀態如下圖所示。
當攝像機距離精細模型比較遠時，HLOD切換狀態如圖2-12所示。
2.計算原理
首先是精細度模型是否需要顯示計算，根據距離LOD Group的距離、屏幕占比與攝像機FieldOfView計算出relativeHeight，這個數值對應如圖2-14所示的攝像機位置，如果這個數值不指向最精細模型，那么就顯示合批模型。
relativeHeight表示
3.工作原理
如圖2-15所示，LODGroup的計算只會計算最精細的模型，只要有一個精細模型被激活那么該節點的精細模型都會被激活，父節點的所有HLOD被dirty並隱藏。如果精細模型不激活，那么直到找到父節點被dirty或已經是最頂層情況激活當前層HLOD。
HLOD流式加載
3.1 流式系統設計
流式加載的設計主要針對移動端內存占用過高問題，利用流式加載可以做到極大降低移動端運行常駐的內存。設計如圖3-1所示。
首先，一個HLOD System里面有多顆子樹，每顆子樹都會帶有一個流式管理器，該管理器負責當前子樹的所有節點流式加載，而HLOD Cull系統負責通知每顆子樹哪些節點狀態出現了變動。
3.2 流式資源加載設計
如下圖，流式加載有兩種模式，經過大量測試，總結出了各自優缺點。
1.裝完再卸載
當前子樹下，所有需要加載的節點加載完畢后再卸載需要卸載的。
優點：可以保證模型常在視區
缺點：經常會出現內存峰值，經常會卡幀
2.直接卸
當前子樹下，卸載不等待其他節點加載完就卸載
優點：極大避免卡幀問題，少許出現內存峰值問題。
缺點：不可保證模型常在視區，加載的模型內存大可能會出現閃爍現象。
3.3 流式加載距離緩沖設計
經常會出現玩家在加載邊沿處來回走動，這會造成資源不斷的來回裝卸，因此加入距離緩沖策列。
設定一定距離的緩沖，當觸發流式切換后，要再次激活流式切換需要走出設定的緩沖距離才會切換，設計如圖3-3所示。
四、適用
HLOD Stream應用場景：
1.大城鎮，很多房屋需要處理很多Bathces的情況
2.需要看得遠，遠處看得見輪科且數量較多的情況使用
3.物件密集並且無法使用GPU Instancing的地方使用
4.只要有很多Batches的地方而無法優化掉的都可以考慮使用
五、問題
1.貼圖合並只保留MainTex貼圖，默認使用Standard物理光照shader（帶陰影），支持GPU Instancing。
2.相同的預制體的網格合並時內存會翻倍（這個跟靜、動態合批一樣）
3.每生成一層HLOD所需要的網格內存會多一倍以上
4.不同子樹相同貼圖會出現重復貼圖合並現象。