ボクセルデータの管理

私は今から約4か月間C ++で趣味としてプログラミングをしてきましたが、ボクセルを使ってものを作成するのが大好きでした。私はMinecraftのような世界をレンダリングする「ゲーム」（私は実際には地形のみを行い、ゲームプレイではないので、単なる個人的な挑戦の詳細）を書きましたが、最近、ゲーム/チャレンジ/などを書き込もうと考えていますマーチングキューブやデュアルコンターリングなどのアルゴリズムを使用し、ボクセルサイズを縮小します。Minecraftのようなプロジェクトを書いたとき、各チャンクのデータを符号なしshortの多次元配列に格納しました（したがって、最大65536の異なるブロックタイプが得られます）。さらに、レンダリングのために、1つのポイント（GLubyteとして）ともう1つのGLubyteだけを保存して、6つのポイントのうちどれが表されているポイントに面しているかを示しました。次に、ジオメトリシェーダーを使用して顔をレンダリングしました。

私が考えていた新しいプロジェクトで、頭を包むことができないのは、ボクセルが約1cmサイズのボクセルと比べて約5cmまたは10cmになるのに十分なボクセルデータをどのように保存できるかです。ブロックの704x704x704領域をレンダリングしたとき、私の古いプロジェクトは約670MBのRAMを使用していました。ボクセルサイズを10cmに縮小し、同じレンダリング距離を維持すると、ボクセルデータは約649GBになります（ボクセルごとに2バイトと7040 ^ 3ボクセルの領域を想定）。ボクセルデータをより効率的な方法で保存できる方法はありますか？

一度にすべてのチャンク（チャンクを使用していると想定）をメモリに保持する必要がありますか？一部は閉塞します-特に地下-または山々の背後など。多くはおそらく空/空であり、フラグが付いている可能性があります。

また、LODオクツリーまたは同様の構造を使用して、現在の詳細を、観測者からの距離に反比例して見えるように維持することもできます。Jasonが述べたように、これはパフォーマンスを購入する可能性がはるかに高くなりますが、フラットチャンクマップからの大きな構造上の変更です。

私のお気に入りのブログからのクリップマップについてのこの記事を参照してください（ボクセルエンジンは、ボクセルサイズ〜a decimetreで記述したものに似ています）。

Ken SilvermanのVoxLapやその後継のAce of Spadesなどのエンジンの標準的なアプローチは、RLE圧縮と他のいくつかのビットレベルのトリックを使用して、データの保存とアクセスの両方を行うことです。この種の1D圧縮は効率が高く、オクツリーよりもはるかに使いやすい傾向があります。シルバーマンのエンジンは、10cmの立方体のようなボクセル解像度を達成したと思います。今日は一般的に見られないもので、はるかに弱いハードウェアで実現されたものです。

彼のアプローチが露出されていないボクセルの色を保存しなかったこと、その代わりに高さの関数として表面ボクセルの色を計算したこと、または地形のどの領域が爆破されて開いているかを思い出してこれらを「新鮮な土壌」として色付けしたことも私は信じています」これを行うには、perlinノイズのようなある種の連続関数を使用できますが、（おそらく、GPUで実行されない限り）大きな表面積に対して急速にコストがかかる可能性があります。

オクトリーは悪くありませんが、実際に使用するのは難しく、キャッシュ効率の良い割り当ては、チャンクで線形化が容易なRLEよりもかなり困難です。TERO KarrasとSVOsにサムリ・レインの精液の論文は、本当にパフォーマンスオクトツリーの実装に入り、どれだけ多くの努力を示している-それは検討しているだけではないゲームプレイやネットワーク通信、レンダリング。

プロジェクトのどこまで進んだかわかりませんが、私と私の友人は、Octreeチャンク構造に基づいたデュアルマーチングキューブアルゴリズムを使用し、デュアルグリッドを使用してデータをレンダリングしています。必要なメモリが非常に少ないこと、レンダリングが非常に速いことなど、多くの利点があります。他のチャンクとの境界でチャンクの境界に詳細レベル（LOD）を実装するのは少し難しいかもしれませんが、時間があれば、Ogre3D開発者がどのように行ったかを知ることができます。