由淺到淺入門批量渲染（二）

上回簡單總結了一下靜態合批，這次我們繼續說說動態合批。

動態合批

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


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

動態合批沒有像靜態合批打包時的預處理階段，它只會在程式執行時發生。動態合批會在每次繪製前，先將可以合批的物件整理在一起（Unity中由引擎自動完成），然後將這些單位的網格資訊進行“合併”，接著僅向GPU傳送一次繪製命令，就可以完成它們整體的繪製。

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

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

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

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


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

在向頂點和索引緩衝區內填充資料前，引擎會處理被合批網格的每個頂點資訊，將其空間變換到世界座標系下。

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

Unity動態合批的條件

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

• 材質球相同；
• Mesh頂點數量不能超過300以及頂點屬性不能超過900；
• 縮放不能為負值（x、y、z向量的乘積不能為負）等。
  

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

與靜態合批的差別

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

• 動態合批不會建立常駐記憶體的“合併後網格”，也就是說它不會在執行時造成記憶體的顯著增長，也不會影響打包時的包體大小；
• 動態合批在繪製前會先將頂點轉換到世界座標系下，然後再填充進頂點、索引緩衝區；靜態合批後子網格不接受任何變換操作，僅手動合批後的Root節點可被操作，因此靜態合批的頂點、索引緩衝區中的資訊不會被修改（Root的變換資訊則會通過Constant Buffer傳入）；
• 因為2的原因，動態合批的主要開銷在於遍歷頂點進行空間變換時的對CPU效能的開銷；靜態合批沒有這個操作，所以也沒有這個開銷；
• 動態合批使用根據渲染器型別分配的公共緩衝區，而靜態合批使用自己專用的緩衝區。
  

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


來源：騰訊遊戲學院
原文：https://gameinstitute.qq.com/community/detail/133590