遊戲圖形批量渲染及優化：Unity動態合批技術

上回 遊戲圖形批量渲染及優化：Unity靜態合批技術簡單總結了一下靜態合批，這次我們繼續說說動態合批技術。

| 動態合批

試想一個場景：一場激烈的戰鬥中，雙方射出的箭矢飛行在空中，數量很多，材質也相同；但因為都在運動狀態，所以無法進行靜態合批；倘若一個一個的繪製這些箭矢，則會產生非常多次繪製命令的調用。

讓人熱血沸騰的一場激戰

對於這些模型簡單、材質相同、但處在運動狀態下的物體，有沒有適合的批處理策略呢？有吧，動態合批就是為了解決這樣的問題。

動態合批沒有像靜態合批打包時的預處理階段，它隻會在程序運行時發生。動態合批會在每次繪製前，先將可以合批的對象“整理”在一起，然後將這些單位的網格信息進行“合並”，接著僅向GPU發送一次繪製命令，就可以完成它們整體的繪製。

動態合批比較簡單，但有兩點仍然需要注意：

1、合批並非是在繪製前“合並網格“

動態合批不會在繪製前創建新的網格，它隻是將可以參與合批單位的頂點屬性，連續填充到一塊頂點和索引緩衝區中，讓GPU認為它們是一個整體。

在Unity中，引擎已自動為每種可以動態合批的渲染器分配了其類型公用的頂點和索引緩衝區，所以動態合批不會頻繁的創建頂點和索引緩衝區。

MeshRenderer、SpriteRenderer動態合批時使用了公用的頂點、索引緩衝區

ParticleSystemRenderer動態合批時使用了與MeshRenderer不同的公用頂點、索引緩衝區

2、合批前會先處理每個頂點的頂點屬性

在向頂點和索引緩衝區內填充數據前，引擎會處理被合批網格的每個頂點信息，將其空間變換到世界坐標係下。

這是因為這些對象可能都不屬於相同的父節點，因此無法對其進行統一的空間轉換（本地到世界），需要在送進渲染管線前將每個頂點的坐標轉換為世界坐標係下的坐標（所以Unity中，合並後對象的頂點著色器內被傳入的M矩陣，都是單位矩陣）。

| Unity動態合批的條件

相對於上述看起來有點厲害但是本質上無用的知識而言，了解動態合批規則其實更為重要。比如：

●材質球相同；

●Mesh頂點數量不能超過300以及頂點屬性不能超過900；

●縮放不能為負值（x、y、z向量的乘積不能為負）等。

但我個人認為你不需要記住每一個條件，除了上述相對重要些的條件外，其餘的可以通過FrameDebugger中提示的合批失敗原因，來反向了解合批條件。

| 與靜態合批的差別

動態合批與靜態合批最大的差別在於：

1、動態合批不會創建常駐內存的“合並後網格”，也就是說它不會在運行時造成內存的顯著增長，也不會影響打包時的包體大小；

2、動態合批在繪製前會先將頂點轉換到世界坐標係下，然後再填充進頂點、索引緩衝區；靜態合批後子網格不接受任何變換操作，僅手動合批後的Root節點可被操作，因此靜態合批的頂點、索引緩衝區中的信息不會被修改（Root的變換信息則會通過Constant Buffer傳入）；

3、因為2的原因，動態合批的主要開銷在於遍曆頂點進行空間變換時的對CPU性能的開銷；靜態合批沒有這個操作，所以也沒有這個開銷；

4、動態合批使用根據渲染器類型分配的公共緩衝區，而靜態合批使用自己專用的緩衝區。

雖然在Unity中，存在多種可以被動態合批的渲染器類型，而且其合批規則可能也略有不同；但我個人認為其原理應該是相似的，因此這裏就不針對每種渲染器做單獨的測試和說明了，後麵有必要、有機會、有緣分的話，再仔細了解吧，嘿嘿。

|  寫在最後

不出意外的話，下次更新的內容應該是實例化渲染。

作者：枸杞憂天

來源：公眾號偶爾學學Unity