将来のグラフィックスエンジンでスパースボクセル八分木の使用の可能性についてたくさん読んでいます。
しかし、それらに関する技術情報を見つけることができませんでした。
ボクセルが何であるかは理解していますが、まばらなボクセル八分木とは何か、または現在使用されているポリゴンテクニックよりも効率的かどうかはわかりません。
誰かがこれについて説明したり、説明を教えたりできますか?
NVidiaのホワイトペーパーでは、非常に詳細に説明されています〜 http://www.nvidia.com/object/nvidia_research_pub_018.html
これは、このテーマの idソフトウェアに関するスニペットです
id Tech 6は、MegaTextureのアイデアに基づいて構築され、ジオメトリとテクスチャの両方を仮想化して、テクセルと同等のスパースボクセルオクトリー(SVO)までユニークなジオメトリを取得する、より高度な手法を使用します。
これは、オクツリーに格納された(三角形ではなく)ボクセルによって表されるジオメトリをレイキャスティングすることで機能します。
目的は、オクツリーの一部をビデオメモリにストリーミングし、ツリーに沿ってさらに下のオブジェクトに移動して詳細を提供し、さらに詳細なオブジェクトに高レベルで大きなボクセルを使用して、自動詳細レベルを提供することです。 (LOD)システムで、ジオメトリとテクスチャの両方を同時に使用できます。
また、 これに関する論文があります
まあ、ボクセルだけではそれほど興味深いものではありません。合理的に詳細にモデル化された場合、非常に大量のボクセルが必要になるためです(均一なグリッドを使用する場合)。
したがって、階層システムが必要であり、それがオクツリーにつながります。八分木は非常に単純な空間データ構造であり、各ノードを8つの等しい大きなサブノードに分割します。
スパース八分木は、微分方程式を離散化するときに得られるスパース行列と同様に、ほとんどのノードが空の八分木です
八分木は8つの隣人を持っています
______________
| | |
| | |
|_____|______|
| | |
| | |
|_____|______|
それから、それは「クワッド」(4)ツリーになります。
しかし、3次元では、正方形ではなく立方体なので、水平方向、垂直方向、Z軸に沿ってカットすると、4つではなく8つのチャンクが見つかります。
_____________
/ / / |
/-----/-----/ |
/_____/_____/ | |
| | | |/|
|-----|-----|/| |
| | | |/
|_____|_____|/
それがそれ以降になることを願っています...
sVOをユニークにしているのは、空間内のポイントであるColor、Normalなどのプロパティを持つボクセル情報を格納することです。
sVOの背後にある考え方は、三角形とテクスチャの必要性を無視することです。それらを1つのSVOにまとめて、ボクセル化された三角形のハル(モデル)とその表面テクスチャをすべて1つのオブジェクトに含めます。
ここでOctreeが必要な理由は、それ以外の場合、均一なグリッド構造では、既存のグラフィックスカードが処理するにははるかに多くのメモリが必要になるためです。
そのため、SVOを使用すると、ある種のミップマップ3Dテクスチャが可能になります。
MipMappingは基本的に同じ画像ですが、縮尺が異なり、詳細度の高いものと詳細度の最も低い最新の縮尺です(ただし、遠くから見るとかなり似ています)。
そうすれば、オブジェクトの近くでSVOからより詳細にストリーミングできますが、オブジェクトのディテールが少なくストリーミングされます。つまり、レイキャスティングを使用している場合、カメラからの光線が遠くなるほど、メガへの掘り込みが少なくなります。 -テクスチャ/ SVO
ただし、「無制限の詳細」を備えた「ユークリドン」のようなボックスの外側を考える場合は、錐台スライスと平面/ abb交差を使用して、スクリーン上の各テクセルカラーを見つけるために、スライスされたビルボードの投影されたUVを反対にします。 nvidiaの素朴な「ビーム最適化」を使用して、幅*高さのピクセルに光線を放出します。
PS(トピックから外れています):ユークリドンが自分のshiをどのように行うのかを理解していない人にとっては、これが最も実用的な解決策であると私は信じており、それをバックアップする理由があります(レイキャスティングを使用しないこと)
彼らが持っている最大の謎は、レンダリングではなく、データを保存することです。RLEは単純にそれをカットしません。RLEが使用されない場合、一部のボリューム/ボクセルデータはよりランダムで「ソリッド」ではないため、圧縮も行われます。私にとっては、通常、それより少ないものには少なくとも5バイトが必要です。彼らは彼らが圧縮によって入力されたものの約半分を出力すると言います...それで彼らは2.5バイトを使用しています、それは今日の三角形とほぼ同じです
実際、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にならないこと、そして実際のVoxelオブジェクトのプロットは非常に計算コストが高く、現時点では1024x1024x1024の球を約12秒でプロットできるが、これらすべての問題救済できる、そのエキサイティングな未来。現時点での最大の世界サイズは、1 MBずつですが、実際にはこれよりも8倍大きくなる可能性があります。もちろん、実際に非常に深刻な他の問題は、圧縮後でも8192x8192x8192文字を格納するために約100 MBを必要とするため、環境はこれよりもさらに大きくなります。とはいえ、8192x8192x8192の文字を使用するというのは、今日のゲームで見られるものと比べるとまったく馬鹿げています...以前は全世界が8192x8192x8192でした:)
ポインターあたりのビットのみを格納することによってそれを行う方法は、ポインターが実行時にビデオメモリに構築されることです。そのことを頭に入れて、独自のエンジンを用意することもできます。 :)