静的バッチ処理の原理
静的バッチ処理で最も重要なことの 1 つは、グリッドのマージです。
実行またはパブリッシュする前に、 エンジンは、シーン内のStaticBatchingUtility.Combineか、コードを使用してマージ関数を呼び出します (としてマークされているBatching Static同じマテリアル
新しい大きな頂点バッファー オブジェクト (VBO 頂点バッファー オブジェクト) とインデックス バッファー オブジェクト (IBO インデックス バッファー オブジェクト) を形成し (これら 2 つのバッファーは、一度決定されると変更されません)、最終的にバッチ頂点情報でこれらを送信します。(後でマージされたグリッドで空間変換を実行する必要がある場合は、既に同じ座標系にいるため、マージされたノードでマトリックス変換を直接実行できます)。
静的バッチ処理は DC を削減しますか?
このキャッシュは、各レンダリング オブジェクトの IBO の範囲を記録し、各レンダリング オブジェクトをトラバースする前に、それらを同じレンダリング状態 (つまり、マテリアル情報が一貫していなければならない理由) に設定してから、各レンダリング オブジェクトの IBO をトラバースします。描画オブジェクトを一つずつ, glDrawElement と同様の API を呼び出して描画します. 描画する前に, 描画オブジェクトが視錐台にあるかどうかを判断する必要があります. そうでない場合は描画されません. したがって、スタティック バッチ処理は DC を減らすのではなく、DrawState の設定を減らすためのものです。
静的バッチ処理はメッシュをマージして 1 つのバッチでより多くの頂点情報を送信しますが、バッチの数とレンダリング ステート SetPassCall の変更の数を効果的に減らすことができます。ただし、これは、このバッチに DC が 1 つしかないという意味ではありません。
たとえば、マージされたグリッドでは、シーン内のオブジェクトの可視性のために、大きなグリッドの特定の部分をカリングまたは非表示にする必要がある場合、それに対応する頂点バッファーとインデックス バッファーは変更されません。サブレンダリングのために大きなグリッド全体をいくつかの小さな部分に分割します. それぞれの小さなレンダリングはDCです. 各DCを調整することにより, 表示されていないコンテンツはスキップされます. これらのサブオブジェクトはマテリアルを共有するため, したがって, レンダリング状態/描画コマンドは切り替えられず、DC が呼び出されたときに描画コマンドがコマンド バッファーにキャッシュされます。これは、最適化の目的を果たします。
そのため、静的バッチ処理はDraw 呼び出しの数を減らしません(ただし、計算方法の違いによりエディターでの Draw 呼び出しの数は減ります)が、すべてのサブモデルの頂点をワールド空間に変換したためです。これらのサブモデルはマテリアルを共有するため、複数の Draw 呼び出し間でレンダリング状態が切り替わることはなく、レンダリング API は描画コマンドをキャッシュしてレンダリング最適化の目的を達成します。さらに、すべての頂点位置処理を実行時に計算する必要がないため、コンピューティング リソースを節約できます。
静的バッチ処理の欠点
Unity はマージされたメッシュの関連情報をシーン ファイル (.scene) に保存するため、静的オブジェクトを含むシーン ファイルは通常、はるかに大きくなります。また、ファイル サイズが大きくなるだけでなく、静的なバッチ グリッドが実行時にメモリに常駐します。多数の静的なバッチ グリッドが存在する場合、メモリの負担が大きくなります。それは実際には、空間を時間と交換する戦略です。静的にバッチ化された Buffer は実行時メモリを増やすだけでなく、パッケージ本体も増加させるため、最初にロードされたメモリと時間を使用してパッケージ本体のサイズを変更する、実行時の静的バッチ化の戦略を採用することもできます。
リファレンスゲーム グラフィックスのバッチ レンダリングと最適化: Unity 静的バッチ処理技術 | indienova Independent Games
Unity が drawcall_unity スクロールを減らす - Tencent Cloud Developer Community - Tencent Cloud