作者:枸杞憂天
(本文首發於公眾號“偶爾學學Unity”,文章僅為作者觀點,不代表GWB立場)
最近在準備公司的技術分享,主題是入門批量渲染,想著反正也總結了,不如充幾篇博客吧,也算顯得沒有那麼半途而廢,一舉兩得了。
所以,這次將分四篇介紹一下與批量渲染有關的知識:
第一篇的主題是靜態合批;
第二篇的主題是動態合批;
第三篇的主題是實例化渲染;
第四篇的主題是優化骨骼蒙皮動畫,以及兩種常用的批量渲染方式:烘焙頂點動畫與烘焙骨骼矩陣動畫。
那就開始吧。
批量渲染
批量渲染其實是個老生常談的話題,它的另一個名字叫做“合批”。在日常開發中,通常說到優化、提高幀率時,總是會提到它。
可以簡單的理解為:批量渲染是通過減少CPU向GPU發送渲染命令(DrawCall)的次數,以及減少GPU切換渲染狀態的次數,儘量讓GPU一次多做一些事情,來提升邏輯線和渲染線的整體效率。但這是建立在GPU相對空閒,而CPU把更多的時間都耗費在渲染命令的提交上時,才有意義。
如果瓶頸在GPU,比如GPU性能偏差,或片段著色器過於複雜等,那麼沒準適當減少批處理,反而能達到優化的效果。
所以要做性能優化,還是應該先定位瓶頸到底在哪兒,然後再考慮優化方案,而不是一股腦的就啪啪啪合批。
當然,通常情況下,確實是以CPU出現瓶頸更為常見,所以適當的瞭解些批量渲染的技法,是有那麼一丟丟必要的。
靜態合批
靜態合批是一種聽起來很常用,但在大多數手遊項目裡又沒那麼常用的合批技術。
這裡,我簡單的將靜態合批分為預處理階段的合併,和運行階段的批處理。
合併階段
合併時,引擎將符合合批條件的渲染器身上的網格取出,對網格上的頂點進行空間變換,變換到合併根節點的座標系下後,再合併成一個新的網格;這裡需要注意的是,新網格是以若干個子網格的形式組合而成的,因為需要記錄每一個合併前網格的索引數量和起始索引(相對於合併後的新網格)。
空間變換的目的,是為了“固化”頂點緩衝區和索引緩衝區內的數據,使其頂點位置等信息都在相同的座標系下。這樣運行時如果需要對合並後的對象進行空間變換(手動靜態合批對象的根節點可被空間變換),則無需修改緩衝區內的頂點屬性,只提供根節點的變換矩陣即可。
在Unity中,可以通過勾選靜態批處理標記,讓引擎在打包時自動合併;當然,也可以在運行時調用合併函數,手動合併。
打包時的自動合併會膨脹場景文件,會在一定程度上影響場景的加載時間。
此外,不同平臺對於合併是有頂點和索引數量限制的,超過此限制則會合併成多個新網格。
批處理階段
運行時是否可以合批(Batch)成功,還取決於渲染器材質的設置。
當然,如果手動替換過場景中所有Material,也會打斷批次。
如果偷偷修改了渲染器使用的網格(不再使用合批後的大網格),也會打斷批處理。
除上述之外,還有一些不常用,且不太有用的知識點。
運行時動態加載?
動態加載並實例化一個帶靜態標記的GameObject到場景中,是不會被當做靜態合批處理的。換言之,靜態標記只被作為是打包時的考慮參數,並不會在運行時被引擎處理。如果在場景加載後,希望對手動實例化的單位進行靜態合批,可以使用手動靜態合批。
合併根節點的空間變換
自動靜態合批的根節點在場景上,因此無法對其進行空間變換;而手動靜態合批,因為根節點不是場景而是一個遊戲對象,所以可以通過修改根節點的空間屬性(位置、大小及縮放值),達到諸如移動整個合批單位的目的。
當然,即使修改了合批後對象的空間屬性,頂點和索引緩衝區裡的數據也不會被修改,引擎會在渲染前,通過ConstBuffer(UniformBuffer)傳入根節點的變換矩陣,達到了整體變換的目的。
Batch ≠ DrawCall
一次靜態合批,並不表示一定只有一次DrawCall命令的調用。
合併發生後,每個參與合批的網格信息(頂點、索引等)就會被最終確定,不再被修改。當一個參與合併的單位不顯示時,如被設置為隱藏或被視椎體剔除,引擎並不會修改頂點緩衝區和索引緩衝區的內容,而會拆分若干個小的DrawCall來分次渲染。通過調整每個DrawCall的索引(起始索引、索引個數)來跳過不應該被顯示的單位。
由於,這些DrallCall之間幾乎沒有渲染狀態的切換,效率較高,所以引擎也將其統計為一次合批(儘管包含若干個DrawCall)。
靜態合批包含了多個材質時,引擎在材質分組後的處理方式也是相同的,只是不同材質在渲染時,都使用了相同的頂點、索引緩衝區。
與直接使用大網格的不同
靜態合批與直接使用大網格(是指直接製作而成,非靜態合併產生的網格)的不同,主要體現在兩方面。
其一,靜態合批可以主動隱藏部分對象。靜態合批在運行時,由於每個參與合併的對象可以通過起始索引等彼此區分,因此可以通過上述多次DrawCall的策略,實現隱藏指定的對象;而直接使用大網格,則無法做到這一點。
其二,靜態合批可以有效參與CPU的視錐剔除。當有剔除發生時,被送進渲染管線的頂點數量就會減少(通過參數控制),也就意味著被頂點著色器處理的頂點會減少,提升了GPU的效率;而使用大網格渲染時,由於整個網格都會被送進渲染管線,因此每一個頂點都需要被頂點著色器處理,如果攝像機只能照到一點點,那麼絕大多數參與計算的頂點最後都會被裁減掉,有一些浪費。
當然,這並不意味著靜態合批一定就比使用大網格要更好。如果子網格數量非常多,視錐剔除時CPU的壓力也會增加,所以具體情況具體分析吧~
靜態合批的利弊
靜態合批採用了以空間換時間的策略來提升渲染效率。
其優勢在於:網格通常在預處理階段(打包)時合併,運行時頂點、索引信息也不會發生變化,所以無需CPU消耗算力維護;若採用相同的材質,則以一次渲染命令,便可以同時渲染出多個本來相對獨立的物體,減少了DrawCall的次數。
在渲染前,可以先進行視錐體剔除,減少了頂點著色器對不可見頂點的處理次數,提高了GPU的效率。
其弊端在於:合批後的網格會常駐內存,在有些場景下可能並不適用。比如森林中的每一棵樹的網格都相同,如果對它採用靜態合批策略,合批後的網格基本等同於:單顆樹網格 x 樹的數量,這對內存的消耗可能就十分巨大了。
總而言之,靜態合批在解決場景中材質基本相同、網格不同、且自始至終都保持靜止的物體上時,很適用。
不出意外的話,下次更新的內容應該是動態合批。
下回見。