私は、まもなく実際のゲームに実装されるMinecraftに着想を得たグラフィックエンジンに取り組んでいます。ジオメトリストレステストで最大60FPS以上のエンジンを使用しています。グラフィック支援にLWJGLのみを使用しています。ある時点で、ローカルメモリ上のVBOデータを更新する際に大きな遅延が発生しましたが、マルチスレッド化、合理化、および汎用ブロックカラー/コンストラクターの同期によってそれを解決しました。
カリング後にVBOデータをビデオメモリにバッファリングしている間、ときどき小さな問題（20〜30ミリ秒）が発生し、その時間の間画面がフリーズする可能性があります。遅延が発生する理由は、数フレームごとにglBufferData（静的描画モード）を介して大量のジオメトリデータをVBO（3-5mb）に送信するためだと思います。私はすでにチャンク錐台カリング、ブロック錐台カリング、エアブロックカリング、および指向性周囲カラーを実装しました。
これは私に2つの質問を残します：
glBufferDataよりも高速な別のデータバッファリング方法を使用できますか？（おそらく、準備として2番目のバッファーをマルチスレッド化する方法です。これによりヒッチが2番目のスレッドに移動します）？
そうでない場合は、立方体の角を示すフローティングポイントのマトリックス（簡単に操作できる）を使用して、ローカルメモリ（おそらくビデオメモリ）から直接オクルージョンカリングを実装するにはどうすればよいですか？アンチポータルは私のフレームワークと互換性がないことに注意してください。
または、「プレーン」英語：データサイズをさらに縮小せずに、glBufferDataを使用してvramへのデータのバッファリングを高速化するにはどうすればよいですか？
更新：カスタムオクルージョンカリングルートを実行します。データのバッファリング時間は、オクルードされたブロックを追加するのにかかる時間によって大幅に増加し、カリングアップデーターがロックを取得するため、同期によって遅延する可能性さえあると確信しています。誰かがバッファからのオクルージョンカリングに関する提案を持っているなら、それは素晴らしいことです。
アップデート2：隠し顔のカリングを追加すると、問題は偶然に解決されました（2つの接触面=どちらもレンダリングされません）。バッファサイズが90％減少し、フレームレートが400％増加したため、パフォーマンスをさらに向上させる必要はありません。回答RTSをありがとう。