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

今天跟大家分享一篇文章，關於遊戲圖形批量渲染及優化：Unity靜態合批技術！最近在準備公司的技術分享，主題是入門批量渲染，這次將分四篇介紹一下與批量渲染有關的知識：

第一篇的主題是靜態合批；

第二篇的主題是動態合批；

第三篇的主題是實例化渲染；

第四篇的主題是優化骨骼蒙皮動畫，以及兩種常用的批量渲染方式：烘焙頂點動畫與烘焙骨骼矩陣動畫。

那就開始吧。

一、批量渲染

批量渲染其實是個老生常談的話題，它的另一個名字叫做“合批”。在日常開發中，通常說到優化、提高幀率時，總是會提到它。

可以簡單的理解為：批量渲染是通過減少CPU向GPU發送渲染命令（DrawCall）的次數，以及減少GPU切換渲染狀態的次數，盡量讓GPU一次多做一些事情，來提升邏輯線和渲染線的整體效率。但這是建立在GPU相對空閑，而CPU把更多的時間都耗費在渲染命令的提交上時，才有意義。

如果瓶頸在GPU，比如GPU性能偏差，或片段著色器過於複雜等，那麼沒準適當減少批處理，反而能達到優化的效果。

所以要做性能優化，還是應該先定位瓶頸到底在哪兒，然後再考慮優化方案，而不是一股腦的就啪啪啪合批。

當然，通常情況下，確實是以CPU出現瓶頸更為常見，所以適當的了解些批量渲染的技法，是有那麼一丟丟必要的。

二、靜態合批

靜態合批是一種聽起來很常用，但在大多數手遊項目裏又沒那麼常用的合批技術。

這裏，我簡單的將靜態合批分為預處理階段的合並，和運行階段的批處理。

合並階段

合並時，引擎將符合合批條件的渲染器身上的網格取出，對網格上的頂點進行空間變換，變換到合並根節點的坐標係下後，再合並成一個新的網格；這裏需要注意的是，新網格是以若幹個子網格的形式組合而成的，因為需要記錄每一個合並前網格的索引數量和起始索引（相對於合並後的新網格）。

空間變換的目的，是為了“固化”頂點緩衝區和索引緩衝區內的數據，使其頂點位置等信息都在相同的坐標係下。這樣運行時如果需要對合並後的對象進行空間變換（手動靜態合批對象的根節點可被空間變換），則無需修改緩衝區內的頂點屬性，隻提供根節點的變換矩陣即可。

盡管網格不同、材質不同，Unity也會將它們的網格進行合並

在Unity中，可以通過勾選靜態批處理標記，讓引擎在打包時自動合並；當然，也可以在運行時調用合並函數，手動合並。

通過勾選開關標記單位參與靜態合批

打包時的自動合並會膨脹場景文件，會在一定程度上影響場景的加載時間。

包含靜態合批的場景體積大了一丟丟

此外，不同平台對於合並是有頂點和索引數量限製的，超過此限製則會合並成多個新網格。

批處理階段

運行時是否可以合批（Batch）成功，還取決於渲染器材質的設置。

使用不同的材質，會分為不同的批次

當然，如果手動替換過場景中所有Material，也會打斷批次。

運行時手動替換所有渲染器的材質球

不再有合批發生

如果偷偷修改了渲染器使用的網格（不再使用合批後的大網格），也會打斷批處理。

替換網格後，也不會再被批處理

除上述之外，還有一些不常用，且不太有用的知識點。

運行時動態加載？

動態加載並實例化一個帶靜態標記的GameObject到場景中，是不會被當做靜態合批處理的。換言之，靜態標記隻被作為是打包時的考慮參數，並不會在運行時被引擎處理。如果在場景加載後，希望對手動實例化的單位進行靜態合批，可以使用手動靜態合批。

合並根節點的空間變換

自動靜態合批的根節點在場景上，因此無法對其進行空間變換；而手動靜態合批，因為根節點不是場景而是一個遊戲對象，所以可以通過修改根節點的空間屬性（位置、大小及縮放值），達到諸如移動整個合批單位的目的。

當然，即使修改了合批後對象的空間屬性，頂點和索引緩衝區裏的數據也不會被修改，引擎會在渲染前，通過ConstBuffer（UniformBuffer）傳入根節點的變換矩陣，達到了整體變換的目的。

Batch ≠ DrawCall

一次靜態合批，並不表示一定隻有一次DrawCall命令的調用。

合並發生後，每個參與合批的網格信息（頂點、索引等）就會被最終確定，不再被修改。當一個參與合並的單位不顯示時，如被設置為隱藏或被視椎體剔除，引擎並不會修改頂點緩衝區和索引緩衝區的內容，而會拆分若幹個小的DrawCall來分次渲染。通過調整每個DrawCall的索引（起始索引、索引個數）來跳過不應該被顯示的單位。

通過兩次DrawCall來跳過隱藏的三角形

由於，這些DrallCall之間幾乎沒有渲染狀態的切換，效率較高，所以引擎也將其統計為一次合批（盡管包含若幹個DrawCall）。

隱藏掉部分立方體後，形成了兩次DrawCall

引擎的Statistics窗口、FrameDebugger和Profiler(Renderer)會體現出這種差異

靜態合批包含了多個材質時，引擎在材質分組後的處理方式也是相同的，隻是不同材質在渲染時，都使用了相同的頂點、索引緩衝區。

與直接使用大網格的不同

靜態合批與直接使用大網格（是指直接製作而成，非靜態合並產生的網格）的不同，主要體現在兩方麵。

其一，靜態合批可以主動隱藏部分對象。靜態合批在運行時，由於每個參與合並的對象可以通過起始索引等彼此區分，因此可以通過上述多次DrawCall的策略，實現隱藏指定的對象；而直接使用大網格，則無法做到這一點。

其二，靜態合批可以有效參與CPU的視錐剔除。當有剔除發生時，被送進渲染管線的頂點數量就會減少（通過參數控製），也就意味著被頂點著色器處理的頂點會減少，提升了GPU的效率；而使用大網格渲染時，由於整個網格都會被送進渲染管線，因此每一個頂點都需要被頂點著色器處理，如果攝像機隻能照到一點點，那麼絕大多數參與計算的頂點最後都會被裁減掉，有一些浪費。

大網格不會被視錐體剔除，全部頂點都會被送進渲染管線

靜態合批會被視錐體剔除，隻有部分頂點被送進渲染管線

靜態合批下合並後的網格

靜態合批下，頂點著色器隻處理了部分頂點

當然，這並不意味著靜態合批一定就比使用大網格要更好。如果子網格數量非常多，視錐剔除時CPU的壓力也會增加，所以具體情況具體分析吧~

三、靜態合批的利弊

靜態合批采用了以空間換時間的策略來提升渲染效率。

其優勢在於：網格通常在預處理階段（打包）時合並，運行時頂點、索引信息也不會發生變化，所以無需CPU消耗算力維護；若采用相同的材質，則以一次渲染命令，便可以同時渲染出多個本來相對獨立的物體，減少了DrawCall的次數。

在渲染前，可以先進行視錐體剔除，減少了頂點著色器對不可見頂點的處理次數，提高了GPU的效率。

其弊端在於：合批後的網格會常駐內存，在有些場景下可能並不適用。比如森林中的每一棵樹的網格都相同，如果對它采用靜態合批策略，合批後的網格基本等同於：單顆樹網格 x 樹的數量，這對內存的消耗可能就十分巨大了。

極端情況下可能導致內存占用過高

總而言之，靜態合批在解決場景中材質基本相同、網格不同、且自始至終都保持靜止的物體上時，很適用。

不出意外的話，下次更新的內容應該是動態合批。

下回見。

作者：枸杞憂天

來源：公眾號“偶爾學學Unity”