商用ゲームエンジンはどのようにインデックス/頂点バッファーを編成しますか？

序文：この質問は、Direct3Dの視点からのものになります。これは、私がよく知っていることだからです。

明らかに、Direct3Dで頂点バッファーまたはインデックスバッファーを変更するたびに（つまりを使用してIASetIndexBuffer）、わずかなオーバーヘッドが発生します。しかし、1つの巨大なインデックス/頂点バッファーを割り当てると、メモリを手動で管理しなければならず、断片化の問題（または、すべてのデータを交換している間、一時停止）になるでしょう。

では、商用エンジンはどのようにデータをロード/アンロードするのでしょうか？私は「パッケージ」ベースのアプローチに少し傾いているので、モデルの「パッケージ」には、パッケージが不要になったときにロード/アンロードできる独自の頂点/インデックスバッファーがあります。そして、同じパッケージからすべてのインスタンスを一緒に描画しようとします。

しかし、これを処理するための受け入れられた/標準的な方法が何であるか聞いてみたいですか？

データを整理するためのさまざまなテクニックがあり、多くのゲームはそれらを組み合わせて使用​​します。

静的なジオメトリの場合は、個々のIBとVBを少なくするのが最善です。

従来、ゲームは「レベル」に基づいており、プレイのセクションのアセットがロードされ、その後ゲームプレイが開始されます。ロード時間を最小限に抑えるために、情報はこれをサポートするように理想的に編成されます（つまり、メディア/ディスクを探し回ることなく、レベルのすべてを可能な限り高速にロードします）、おそらくレベル間で情報を複製します。このアプローチの1つのスキームは、モデルまたは一連のモデルに大きなVBとIBを用意し、そこからサブセットを送信して描画することです。

Xbox 360 / PS 3世代では、RAMの量はゲームのサイズに比べてかなり小さかったため、エンジンは「ストリーミング」指向になりました。つまり、プレーヤーが移動するときにコンテンツを動的にロードします。これは「オープンワールド」アプローチとも呼ばれます。このアプローチでは、空間的なヒントに基づいて、ジオメトリを読み込み可能なビットに「チャンク」することが課題です。特に32ビットプラットフォームのもう1つの課題は、長期間にわたってメモリが断片化されない（または仮想アドレス空間が断片化されることもない）ことを保証することです。レベルベースのゲームは、レベル間でメモリをリセットすることが多く、ストリーミングエンジンでは実行できません。簡単に。したがって、割り当てられてプールとして再利用されたIB / VBの固定サイズまたは固定サイズのセットにパッキングすることは有用です。

Xbox One / PS 4世代では、以前のコンソールに比べて動作するRAMが多く、追加のコアがたくさんあるため、多くのゲームは積極的にアセットを圧縮し、「追加の」CPUコアを使用してそれらをバックグラウンド。64ビットの仮想アドレススペースを使用すると、仮想アドレススペースの断片化の心配が少なくなります。このアプローチは、読み込み時間を低く保ち、デジタルダウンロード用にアセットを適切にパックし、「オープンワールド」レンダリングをサポートします。ここでは、IB / VBを管理するためのプールアプローチが使用されています。

地形、変形可能/破壊可能なモデルなどによく使用される動的なジオメトリの送信もあります。GPUバスの帯域幅の点で効率的ではないため、ゲームには多くの場合、静的なジオメトリと動的なジオメトリの両方が混在しています。この場合、Direct3DマップのDISCARD更新パターンは通常、単一のIB / VB（またはマルチスレッドレンダリングシナリオでは、各フレームの塗りつぶし/レンダリングを入れ替えるデュアルIB / VB）のみを使用していることを意味します。