c++ - 依存している可能性のある頂点の作成/破棄を処理する際の VBO/VAO メモリ管理プラクティス

Question

C++/OpenGL を使用して 2D の壁を作成するという単純な概念をいじっています。各壁は 4 つの頂点で表され、水平または垂直に伸び、色も付いています。衝突すると壁が連結します。壁で形成された周囲は、単純な長方形で塗りつぶされます。

私の考えは、多くの壁の頂点データを単一の VBO に保存することです。または、属性ごとに複数の場合、VAO に配置しますか? 1 つの VBO にインターリーブし、VAO 経由でアクセスしますか? とにかく、1 つのオブジェクトに多くの壁があります。保存しているものがスペースを使い果たした場合は、別の VBO (または私が使用しているもの) を作成して、別の壁のグループを保存します。また、スペースを節約するために、直角などで交わる壁が頂点を共有するようにしたいと考えました。

ただし、壁は可変であるため、頂点はいつでも追加、移動、または削除できます。これには、VBO 内の空きブロックを追跡し、必要に応じてそれらに壁データを割り当てる必要があります。また、複数の VBO がある場合、頂点を共有する 2 つの壁が同じ VBO にある必要があり、あらゆる種類の頭痛の種になる可能性があります。しかし同時に、すべての単一の壁に VBO を作成したくありません。これは、せいぜい非常に単純な 4 つの頂点にすぎません。

元の画像に発生するいくつかの変更の例:

この状況は通常どのように処理されますか? VBO を使用するには、独自のメモリ割り当てスキームをローリングする必要がありますか、それともそれほど多くの作業を必要としない適切に高速なソリューションはありますか?

Answer 1

VBO のスペースが不足する可能性があるのはなぜだと思いますか? つまり、ほとんどの GPU では、VBO の最大サイズは 16 ～ 32 ～ 64Mb のオーダーです。（こちらもチェック）

すべてのデータを単一の VBO に収めることができれば、問題ははるかに簡単になります。すべてのデータを変更する必要がある場合は、すべてのデータを再バッファリングするだけです (フレームごとに壁を追加/削除しない限り、頻繁には発生しないと思います)。

あなたのケースでこれが受け入れられない場合は、オープン ソース コードからいくつかの一般的な実装を確認することをお勧めします。たとえば、osg の GLBufferObject があります。

関数を見てくださいGLBufferObject::compileBuffer()。あなたの場合、それぞれosg::BufferEntryが接続された壁のグループになる可能性があります。シーンをレンダリングするには、このクラスにクエリを実行して、各データのオフセットを取得する必要があります。

お役に立てれば。

Answer 2

アプローチは、要件によって大きく異なります。

• ターゲット プラットフォーム (PC、電話) のパフォーマンスは?
• バッファはどのくらいの大きさになりますか (~1Mb、~10mb、~100Mb)?
• どのくらいの頻度でデータを更新しますか (毎フレームまたは時々)?

本当に必要でない限り、メモリ マネージャを実装することはお勧めしません。つまり、バッファが数メガバイトを超えていて、頻繁に更新している場合です。小さなバッファーの場合、適切なデータ構造を使用して CPU ですべてのデータを保持および処理し、レンダリング前にバッファーを構築して、すべてのデータを GPU にストリーミングできます。つまり、GL_STREAM_DRAW でバッファを作成し、フレームごとに完全に更新します。

そうでない場合は、一種のメモリ マネージャを実装します。データの移動を回避するには、縮退した三角形を使用します (つまり、壁を削除するときは、ラスタライザーによってカリングされる三角形を構成するように壁の頂点を移動します)。自由頂点 (縮退した三角形を構成するもの) のチャンクのリストを保持し、それらを使用して新しい壁を構築します。壁を追加しても問題ありません。必要なバッファは何でも使用できますが、ほとんど必要ありません (最近、300Mb までの VBO を使用するアプリケーションを実装しました。最新のハードウェアでシームレスに動作しました)。

Answer 3

データが変更されるたびに（最初の作成時を含む）、すべての頂点に新しいバッファを割り当て（VBO名を再利用しますが、古いストレージを孤立させて新しいストレージを割り当てます）、頂点を独自のデータ構造からVBOにコピーします.