Unity 繪圖性能優化 - Draw Call Batching

Unity 繪圖性能優化 - Draw Call Batching

 

Unity官方連接：http://docs.unity3d.com/Manual/DrawCallBatching.html

轉載請註明本文連接：http://www.cnblogs.com/fly-100/p/5422734.html

Draw Call Batching

在屏幕上繪製一個物體，U3D引擎必須向繪圖API（openGL或者D3D）發起一次DrawCall。這些DrawCall每每是昂貴的，當繪圖API爲每一個DrawCall作一些重要的事情，引發GPU的性能消耗較高。
這些消耗大部分是由於DrawCall結束的狀態切換引發的（好比，從一個材質切換到另外一個材質），由於這會引起昂貴顯卡驅動的驗證和變換步驟。

Unity使用多種技術來解決這個問題：

• 靜態Batching：把靜態的物體合併成一個大meshes，而後用更快的方法渲染他們。
• 動態Batching：對於足夠小的meshesh，變換他們的頂點在CPU上，將一些類似的組合到一塊兒，在一個go中繪製。

內建的Baching相對於手動合併物體到一塊兒有幾個好處（值得注意的是，這些對象仍能夠被單獨銷燬）。
可是他也有它的缺點（靜態Batching會致使內存和存儲的開銷，動態Batching會致使CPU開銷）。

 

Material Setup For Batching

只有共享同一個材質的物體才能被Batched在一塊兒。若是，你想達到一個好的batching，你須要竟可能多的在不一樣物體中共享材質。

若是你有兩個一樣的材質可是他們的textures不一樣，你能夠合併這些textures到一個大texture - 這個過程常常被叫作texture atlasing。一旦textures在同一個圖集中，你就可使用一個材質來代替了。 

若是你須要在腳本中訪問共享了的材質，有一個很重的點須要注意：修改Renderer.material屬性會建立一個當前材質的副本。因此，做爲替換方案，你應該使用Rednerer.sharedMaterial以保證材質被共享。

當渲染陰影投射的時候，即便他們的材質是不一樣的，也常常被batched到一塊兒。只要材質中的數值在shadow pass是相同的，即便陰影投射有不一樣的材質，他們也可使用動態batching。舉個例子，許多箱可使用具備不一樣的texture的材質，但對於陰影投射渲染 texture是不相關 - 在這種狀況下，他們能夠被batched到在一塊兒。

 

Dynamic Batching

Unity能夠自動batch移動物體到相同的draw call，若是它們具備相同的材質和知足其它標準。動態Batching是自動完成的，不須要你作額外的事情。

• Batching 動態的物體每一個頂點會有某些開銷，因此batching只適用於定點數小於900的meshes。
  • 若是你得shader使用了頂點位置，法線和單獨的UV，那麼你能夠batch 300 個頂點;若是你得shader使用了頂點位置，法線，UV0，UV1，和正切，只能batch 180個頂點。
  • 這個限制的數量未來有可能會變化。
• 若是物體包含鏡像變換，他們將不會被batched，例如，object A 的scale 爲 +1 object B 的scale 爲-1，就不能batched到一塊兒。
• 使用不一樣材質的實例，即便他們實質上是相同的，也會致使兩個物體不能被batched到一塊兒。陰影投射除外。
• 具備光照貼圖的對象有額外的渲染參數：光照索引和 偏移/放縮 的光照。因此通常動態lightmapped對象應指向徹底相同的光照貼圖位置而後再進行batch。
• 多通道的shader將不會被batching
  • 幾乎全部的Unity shader都支持前置渲染幾個燈光，有效的爲他們作更多的通道。「額外的逐像素的燈光」的draw call 將不會被batched。
  • 傳統的延遲渲（逐通道光照）染通道禁用了動態batching，由於它必須繪製兩次。

因爲它的工做原理是變換全部的物體的頂點到CPU的世界座標中，因此它僅僅在它的工做（變換到cpu的世界座標）比作一次「draw call」小的時候才能起到好的做用。究竟一個DrawCall有多昂貴取決於諸多因素，主要是所用的繪圖API。例如，在控制檯或當前流 
行的APIs 例如Apple Metal DrawCall的開銷通常比較低，因此通常動態batching不會達到好的效果。

 

Static Batching

靜態batching容許引擎減小draw call適用於任何大小的幾何（假設沒有移動和共享材質）。大部分狀況下他比動態batching更高效 ，可是它會佔用更多的內存。

爲了使靜態batching更好的獲益，你須要明確的指定遊戲中某些物體是靜態的並且不會移動，旋轉或者縮放。這樣作，你能夠在Inspector界面中的「Static」選項（chekbox）標記物體爲static：

 

使用靜態batching將須要額外的內存來存儲合併後的幾何信息。若是幾個物體在靜態batching以前共享同一個幾何圖元，那麼這個幾何圖元將會爲每一個物體複製一份，不管在Editor中仍是runtime中都是如此。這不是一個好方法 - 有時候爲了保持更小的內存佔用量，你必須犧牲渲染性能爲了不一些物體的靜態batching。例如，在一個稠密的森林中，標記樹木爲static會產生嚴重的內存影響。

在內部，靜態batching的原理是變換這些靜態物體到世界控件而後爲他們創建一個很大頂點+索引 緩衝區。而後全部顯示的物體都放到一個batch，一系列「便宜的」draw call就完成了，這期間幾乎沒有狀態切換（state change）。因此 從技術上來說 這並無節省「3D API draw call」，可是他節省了他們之間的狀態切換（狀態切換纔是罪魁禍首）。

 

Other Batching Related Tips

目前，只有網格渲染才被batched。像 skinned meshes，cloth，拖尾渲染器（Trail Renderer）和其餘類型的渲染組件是不被batched的。半透明shader爲了作透明度的工做，常常須要物體以從後到前的順序進行渲染。Unity首先會對物體進行排序，而後試着batch他們 - 由於這個順序是嚴格限制的，這就意味着 相對於不透明物體來講，會有不多的batching產生。相對調用draw call來講，手動合併比較近的物體多是一個很是不錯的選擇。例如，許多抽屜的靜態櫃子合併成一個mesh常常是有道理的，不管是在3D建模軟件中仍是使用Mesh.CombineMeshaes.