由浅到浅入门批量渲染（二）
上回簡單總結了一下靜態合批，這次我們繼續說說動態合批。
| 動態合批
試想一個場景：一場激烈的戰斗中，雙方射出的箭矢飛行在空中，數量很多，材質也相同；但因為都在運動狀態，所以無法進行靜態合批；倘若一個一個的繪制這些箭矢，則會產生非常多次繪制命令的調用。
?
讓人熱血沸騰的一場激戰
對于這些模型簡單、材質相同、但處在運動狀態下的物體，有沒有適合的批處理策略呢？有吧，動態合批就是為了解決這樣的問題。
動態合批沒有像靜態合批打包時的預處理階段，它只會在程序運行時發生。動態合批會在每次繪制前，先將可以合批的對象整理在一起（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中，存在多種可以被動態合批的渲染器類型，而且其合批規則可能也略有不同；但我個人認為其原理應該是相似的，因此這里就不針對每種渲染器做單獨的測試和說明了，后面有必要、有機會、有緣分的話，再仔細了解吧，嘿嘿。
| 寫在最后
不出意外的話，下次更新的內容應該是實例化渲染。
總結
以上是生活随笔為你收集整理的由浅到浅入门批量渲染（二）的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 由浅到浅入门批量渲染（一）
- 下一篇： 由浅到浅入门批量渲染（三）