私はC++とOpenGL（àlaMinecraft）でボクセルエンジンを作成していますが、ATIX1600を使用して3GHzで適切なfpsを取得できません...私はすべてアイデアがありません。
画面に約12000個のキューブがあると、20fps未満になります-哀れです。
これまでのところ、最適化は次のとおりです。錐台カリング、背面カリング（OpenGLのglEnable（GL_CULL_FACE）を使用）、エンジンは表示されている面のみを描画し（もちろん、カリングされた面を除く）、それらは八分木にあります。
私はVBOを試しましたが、それらは好きではなく、fpsを大幅に上げることはありません。
Minecraftのエンジンはどうしてこんなに速くなるのでしょうか...私は10000の立方体に苦労していますが、Minecraftはより高いfpsではるかに多くを簡単に描くことができます。
何か案は？
@genpfault: 接続を分析し、外側の目に見える表面の面を生成するだけです。VBOには、glTranslate()dした単一のキューブがありました
私は OpenGL の専門家ではありませんが、すべてのキューブをカードに送信する必要があるため、時間の節約にはほとんどなりません。
代わりに、目に見えるすべての外側サーフェスの面を生成し、それを VBO に入れ、それをカードに送信して、ジオメトリが変更されるまでその VBO をレンダリングし続ける必要があります。これにより、カードがプロセッサでジオメトリ情報を送信するのを実際に待機する時間を大幅に節約できます。
アプリケーションのボトルネックが CPU にあるのか GPU にあるのかを調べるために、コードをプロファイリングする必要があります。たとえば、カリング/octtree アルゴリズムが遅い可能性があります。その場合、OpenGL の問題ではありません。
また、各フレームに描画した立方体の数を数えて、画面に表示します。カリングルーチンが期待どおりに機能することを確認するためです。
最後に、キューブにテクスチャが付けられているかどうかについては言及しません。小さいテクスチャを使用するか、テクスチャを無効にしてみて、フレームレートがどれだけ増加するかを確認してください。
gDEBuggerは、OpenGL のボトルネックを見つけるのに役立つ優れたツールです。
ここで古い質問を「バンプ」してもいいのかどうかはわかりませんが、いくつかのことが頭に浮かびました。
ボクセルが静的である場合、錐台のカリングなどに octree を使用することで、レンダリング プロセス全体を高速化できます。さらに、静的シーンを octree の潜在的な可視性セットにコンパイルすることもできます。PVS の主な原則は、他のノードが可視になる可能性があるツリー内のすべてのノードを事前計算し、それらへのポインタをベクトルに格納することです。レンダリングに関しては、最初にカメラが配置されているノードを確認し、ノードの PVS ベクトル内のすべてのノードに対してフラスタム カリングを実行します。
ボクセルのシェーディングがちょっと複雑な場合は、カラー バッファーに書き込むことなく、深度バッファーを埋めるためだけに事前深度のみのパスを実行することも高速です。その後、2 番目のパスをレンダリングします。Depthbuffer への書き込みを無効にし、Depthbuffer をチェックしながら Colorbuffer のみにレンダリングします。そのため、ビューアーに近い新しいフラグメントによって後で上書きされる高価なシェーダー計算を回避できます (Carmack は Quake3 でそれを使用しました)。
間違いなく高速化するもう 1 つのことは、インスタンス化の使用です。各ボクセルの位置のみを保存し、必要に応じてそのスケールやその他のパラメータをテクスチャ バッファ オブジェクトに保存します。頂点シェーダーでは、スポーンするボクセルの位置を読み取り、ボクセルのインスタンス (頂点バッファー オブジェクトでシェーダーに与えられる立方体) を作成できます。したがって、8 つの頂点 + 8 つの法線 (3 *sizeof(float) *8 +3 *sizeof(float) *8 + 色/テクスチャなどの floats...) を VBO のカードに 1 回だけ送信し、次にTBO 内の Cube (3*sizeof(float)*number of voxels) のインスタンスの位置。
おそらく、2 つのスレッドで 3 つのステップすべてを組み合わせることにより、GPU と CPU の間で物事を並列化することが可能です。CPU スレッドでは、octrees pvs をチェックし、次のフレームでインスタンス化するために TBO を更新します。その間、GPU スレッドは 2 をレンダリングします。前の手順で CPU スレッドによって作成されたインスタンス化用の TBO を使用しているときにパスします。その後、TBO を切り替えます。カメラが移動していない場合は、CPU 計算を再度行う必要さえありません。
私が興味を持っている別の種類のツリーは、いわゆるkdツリーです。これは、octreesよりも一般的です。
PS：私の英語で申し訳ありませんが、それは最も明確ではありません....
レンダリングをより効率的にするために使用できるサードパーティのライブラリがあります。たとえば、C ++ PolyVoxライブラリはボリュームを取得し、効率的な方法でメッシュを生成できます。三角形の数を減らし、アンビエントオクルージョンなどを生成するためのメソッドが組み込まれています。周りには良いコミュニティがあるので、フォーラムでサポートを受けるのは簡単です。
すべてのキューブに共通の表示リストを使用しましたか？
ユーザーに表示されないキューブの描画コードの呼び出しをスキップしますか？