将来のグラフィックス エンジンで疎なボクセル octrees を使用する可能性について多くのことを読みました。
しかし、それらに関する技術情報を見つけることができませんでした。
ボクセルが何であるかは理解していますが、スパース ボクセル オクトリーとは何か、または現在使用されているポリゴン技術よりもどのように効率的であるかはわかりません。
誰かがこれについて説明したり、説明を教えてくれませんか?
これは、このテーマに関する id Software に関するスニペットです。
id Tech 6 は、MegaTexture のアイデアに基づいて構築され、ジオメトリとテクスチャの両方を仮想化してテクセルと同等の独自のジオメトリを取得する、より高度な技術を使用します: Sparse Voxel Octree (SVO)。
これは、octree に格納されているボクセル (三角形ではなく) で表されるジオメトリをレイキャストすることによって機能します。
目標は、octree の一部をビデオ メモリにストリーミングできるようにすることです。ツリーに沿ってさらに下に移動して、近くのオブジェクトを詳細に表示し、より高いレベルの大きなボクセルをさらにオブジェクトに使用して、自動レベルの詳細を提供します。ジオメトリとテクスチャの両方を同時に (LOD) システム。
詳細については、このすばらしいブログ エントリを参照してください。
まあ、ボクセルだけではそれほど興味深いものではありません。合理的に詳細なモデルを作成するには、非常に大量のボクセルが必要になるからです (均一なグリッドを使用する場合)。
したがって、八分木につながる階層システムが必要です。octree は非常に単純な空間データ構造であり、各ノードを 8 つの等しい大きさのサブノードに分割します。
疎な octree は、ほとんどのノードが空である octree であり、微分方程式を離散化するときに得られる疎行列に似ています。
八分木には 8 つの隣接要素があります。正方形を想像すると、このように 4 つの等しい四分の一に分割される
______________
| | |
| | |
|_____|______|
| | |
| | |
|_____|______|
それは「クワッド」(4)ツリーになります。
しかし、3 次元では、自分自身が正方形ではなく立方体であるため、それを水平、垂直、Z 軸に沿って切断すると、4 つではなく 8 つのチャンクが見つかります。
_____________
/ / / |
/-----/-----/ |
/_____/_____/ | |
| | | |/|
|-----|-----|/| |
| | | |/
|_____|_____|/
それ以来..
SVO のユニークな点は、色、法線などのプロパティを持つ、空間内のポイントであるボクセル情報を保存することです。
SVO の背後にあるアイデアは、ボクセル化された三角形のハル (モデル) とその表面テクスチャをすべて 1 つのオブジェクトに含む単一の SVO にそれらをまとめることで、三角形とテクスチャの必要性を無視することです。
ここで Octree が必要な理由は、そうしないと、既存のグラフィックス カードを処理するために均一なグリッド構造を使用すると、非常に多くのメモリが必要になるからです。
そのため、SVO を使用すると、一種のミップ マップ 3D テクスチャが可能になります。
MipMapping は基本的に同じ画像ですが、縮尺が異なります。詳細度が高い方と詳細度が最も低い最新の画像です (ただし、遠くから見るとかなり似ています)。
そうすれば、近くのオブジェクトは SVO からより詳細にストリーミングできますが、遠くのオブジェクトは詳細度が低くなります..つまり、レイキャスティングを使用している場合..レイがカメラから遠ざかるほど、Mega を深く掘り下げることが少なくなります。 -テクスチャ/SVO
しかし、「無制限の詳細」を備えた「ユークリッド」のように箱の外で考える場合は、スクリーン上の各テクセルの色を見つけるためにスライスされたビルボードの投影された UV を使用して、錐台のスライスと平面/aabb の交差を使用するだけです。 nvidia の単純な「ビーム最適化」を使用して、幅*高さのピクセルに光線を発射します。
PS(トピックから少し外れます): ユークリッドがどのように自分の仕事をするかを理解していない人のために、それが最も実用的な解決策であると信じています。
彼らが持っている最大の謎は、レンダリングではなく、データの保存です..RLEは単純にそれをカットしません..一部のボリューム/ボクセルデータはよりランダムで、RLEが役に立たない「ソリッド」ではない可能性があるため、圧縮も私にとっては、通常、少なくとも 5 バイトが必要です。彼らは、圧縮によって入力されたものの約半分を出力すると言います..したがって、彼らは2.5バイトを使用しています。これは、現在の三角形とほぼ同じです。
Efficient Sparse Voxel Octrees – Analysis、Extensions、and Implementationという名前のNVIDIAホワイトペーパーでは、ここ で非常に詳細に説明しています。
実際、1.15 ビットということは、驚くほど単純な方法で物事を順番に格納しているだけなのではないかと私には思われます。つまり、ボリューム データのみを格納し、色やテクスチャ データなども格納しない場合です。
次のように考えてみてください: 1 ボクセルは 1 ビットだけでよい: あるのか、ないのか? (あるべきかどうか、言い換えれば:P)。それが入っている octree ノードは、8 つのボクセルと、物に何かが含まれているかどうかを保存するためのビットで構成されています。これは、ボクセルあたり 1 ビット + 8 あたり 1 ビットです。1 + 1/8 = 1,125 です。7 つの兄弟を持つ別の親ノードを追加すると、1 + 1/8 + 1/8/8 = 1,140625 になります。彼らが言及した1.15に疑わしいほど近い. 私はおそらくかなり離れていますが、誰かに手がかりを与えるかもしれません。
すべてのポイントを単純にラスター化することもできます。最近では、ビデオ カードが無意味な量のポイントを投影する可能性があるため、レイトレースまたはレイキャストが必要です。八分木を使用するのは、立方体の形状であり、継続的に分割してより小さい立方体を作るためです。(ボクセル) ラスター技術を使ったエンジンを開発中です。見栄えは良いです。ボクセルをアニメートできないと言う人は、このトピックについてあまり考えていないと思いますが、もちろん可能です。私が見ているように、世界を作ることは「無限の3Dコート」によく似ているので、3Dコートを調べると、レベルデザインはこのプログラムの仕組みと非常に似ています. 主な欠点は、ストリーミング速度が十分に速くないこと、レイトレーシングまたはラスタリングが 60 fps に達しないこと、実際のボクセル オブジェクトをプロットするのに非常に計算コストがかかることです。現時点では、1024x1024x1024 の球体を約 12 秒でプロットできますが、これらの問題はすべて解決できる可能性があり、エキサイティングな未来です。現時点での私の最大のワールド サイズは、1 メガごとですが、実際には、この 8 倍のサイズになる可能性があります。もちろん、実際にはかなり深刻なもう 1 つの問題は、圧縮後でも 8192x8192x8192 の文字を格納するのに約 100 MB かかるため、環境はそれ以上になります。とはいえ、8192x8192x8192 のキャラクターが登場すると言うのは、今日のゲームで見られるものと比べると完全にばかげています...世界全体が 8192x8192x8192 でした :) もちろん、実際にはかなり深刻なもう 1 つの問題は、圧縮後でも 8192x8192x8192 の文字を格納するのに約 100 MB かかるため、環境はそれ以上になります。とはいえ、8192x8192x8192 のキャラクターが登場すると言うのは、今日のゲームで見られるものと比べると完全にばかげています...世界全体が 8192x8192x8192 でした :) もちろん、実際にはかなり深刻なもう 1 つの問題は、圧縮後でも 8192x8192x8192 の文字を格納するのに約 100 MB かかるため、環境はそれ以上になります。とはいえ、8192x8192x8192 のキャラクターが登場すると言うのは、今日のゲームで見られるものと比べると完全にばかげています...世界全体が 8192x8192x8192 でした :)
ポインターごとにビットを格納するだけでそれを行う方法は、ポインターが実行時にビデオメモリに構築されることです...それを理解して、独自のエンジンを作成できます。:)