地図のような地球サイズのマインクラフトをレンダリングするには、どのようなハードウェアが必要ですか？

私はこの問題について考えてきました。現在のテクノロジーで、ボクセルベースのゲームで地球の1：1のレプリカを作成することは可能ですか？この巨大な地図を保存するのに最適なデータ構造は何ですか？このデータ構造をリアルタイムでレンダリングするには、どのアルゴリズムを使用する必要がありますか？

これらの質問はこれらの仮定をします：

• 各ボクセルの解像度は1立方メートルです。

• 簡単にするために、各ボクセルに必要なメタデータ情報は1バイトだけです。この情報は、ボクセルの「タイプ」（地球、水、岩など）の識別情報を格納するために使用されます。

• 地球の体積は1 * 10ˆ21立方メートルです。

• 「現在のテクノロジー」には、市販されているものはすべて含まれますが、スーパーコンピューターは含まれません。

• 地図の生成には、地球の地形と水深のみが使用されます。人間の建物、植物、洞窟は除きます。地下ブロックは、地質学的研究に基づいて選択されます。たとえば、深度が3000 kmを超える場合は、「マグマ」ボクセルをレンダリングします。

• Minecraftと同様に、マップは静的ではなく、ゲーム内で変更できます。

• 「無限」の描画距離は大きなプラスです。もしあなたが飛んで地球全体を見ることができないならば、地図に地球全体を持っていることの意味は何ですか？

この問題について考えたときに私が最初に結論付けたのは、各ボクセルがメモリの1バイトしか占有しないと仮定すると、マップを格納するのに1ゼタバイトが必要になると仮定すると、地球データを線形に格納することは不可能であるということです。したがって、何らかの圧縮が必要です。

ボクセル八分木はマップを圧縮できると思いますが、どれほどかはわかりません。このボクセルマップのエントロピーはおそらく非常に低いため、非常に高いレベルの圧縮を実現できると思います。

免責事項

これは理論的な質問です。ボクセル地球を書くつもりはありません

編集

ESA GOCEはすでに1cm-2cmの精度で地球ジオイドをマッピングしています。この情報を使用して、地球の非常に正確な高さマップを生成できると思います。これにより、地球の地形のギャップを埋めるためにアルゴリズムを使用する必要がなくなります。

これは、使用する空間サブディビジョンメソッドに依存しますが、すべてのサブディビジョンメソッド（任意の圧縮メソッドと同様）は、データ構造のオーバーヘッドやその他の論理的/数学的な要因により、最終的にはそれ以上圧縮できない場所でパンします。例はoctreesにあります。意味のあるトラバーサルを有効にするには、オクツリーの各ノードについて、その親または子（データ構造アーキテクチャの扱い方に応じて異なります）へのポインタを保持する必要があります。どのツリー構造にもn個の子を含めることができます。1：nの比率が低いほど、スペースをより効率的に使用できます。その結果、ツリートラバーサルのオーバーヘッドが大きくなります。これは、同じ数の葉のボクセル（この場合、約510兆）を含む祖先ノードが必要になるためです。これらの表面積を表す）。

インスタンスでの主な問題はストレージコストであり、惑星全体（またはその一部）をかなりの距離からレンダリングすることであることを考えると、八分木よりも推奨するデータ構造はありません。ミップマッピングは必要です。最も近い2の累乗での直径1280万メートルは2 ^ 24 = 1680万です。トラバースする24のオクツリーレベルは、膨大な量の分岐に相当します。GPUとCPUの両方にとって非常にコストがかかります。しかし、正しいことを行えば、一度にいくつかのレベルをトラバースするだけで済みます。ただし、必要なスペースの量を考えると、代替手段はほとんどなく、はるかに少ないです（以下を参照）。

octreesのミップマッピング機能は、あなたが説明するような大容量のボリュームに対して非常に強力なツールにするものです。他のすべての既知のサブディビジョン方式（KDツリーを除く）とは異なり、octreeはレベルごとのサブディビジョンを最小限に保ちます。つまり、ミップマップレベル間の視覚的および物理的な差異も最小限に保たれます。ツリーの下。

一方、階層的なグリッドトラバーサルが最小限に抑えられる世界を生成したい場合は、スペースを犠牲にして速度を上げる必要があります。

理想的な1：n比について言えば、この点でkdツリーよりも細かい構造はありません。octreeが各軸で2に分割され、2 ^ 3 = 8の個別の子セルが生成される場合、kdツリーはサブディビジョンレベルごとに1回だけ分割されます。この問題は、分割する超平面を選択する必要があり、この超平面は3つの軸のいずれかを中心に選択できることです。空間的には最適ですが、3Dトラバーサル（レイマーチ時、物理やレンダリングにオクツリーを使用する場合の基本的な操作など）は、オクツリーよりもはるかに難しくなります。動的なポータルタイプの構造を記録しておく必要があるためです。個々のkdツリーノード間のインターフェース。

RLEは圧縮への別のアプローチですが、RLE圧縮は1次元であり、それが動作する軸を選択する必要があるため、このような問題（操作のベースが球形である場合）に適用することは多くの点で困難です。惑星では、極軸を選択する場合がありますが、単一軸を選択すると、特定の最適でない角度から動作するときに、レンダリングと物理のトラバーサルに特定の問題が発生します。もちろん、さらに最適化するために、RLEを3軸で同時に実行してストレージコストを3倍にするか、6軸（-x、+ x、-y、+ y、-z、+ z）で実行することもできます。

だからあなたの質問に答える（またはしない！）

私は、どのようなハードウェアのに答えるに直接移動するつもりはないが、私は視点が八分木からそれを見て考えるから始まるあなたのハードウェアの種類に、実際に何ができるかのアイデアを与えるために。このルートをたどることをお勧めします。本当に知りたい場合は、単純なスパースオクツリーを実際に実装するのが最も簡単かもしれません。（参考文献のレインの論文を参照）、表面ボクセルの球形シェルをその中に配置し、結果として生じるスペースの使用法を確認します。そこからステップアップ。システムメモリが解放され始めるまでの距離を確認してください。これは、視覚化が必要でない限り、レンダラーを作成する必要はありません。また、これはCPUで行うのが最適です。GPUは、概して、この規模の問題に対処するためのメモリ容量を備えていません。これがIntelが超並列プロセッサへの移行を検討している理由の1つです。この種の点で優れているGPGPUの利点は、システムバスのボトルネックが対処しなくても、はるかに広いメモリ空間に適用できます。おそらく他にもここにあるか、mathematics.stackexchange.comにあります。

無限視距離の要件という点では確かですが、問題は常に「どのくらいの距離でどれだけ詳細に」かということになります。無限の詳細をレンダリングするには、無限のリソースが必要になります。そこで登場するのが、シーンごとに可変のミップマッピングです。また、すべてのデータ構造は、速度とスペースのトレードオフ、またはその逆を具体化していることに注意してください。同じ量のエンジニアリング作業でより大きな世界が必要な場合は、レンダリングが少ない/遅いことを意味します。

この問題について考えたときに私が最初に結論付けたのは、各ボクセルがメモリの1バイトしか占有しないと仮定すると、マップを格納するのに1ゼタバイトが必要になると仮定すると、地球データを線形に格納することは不可能であるということです。したがって、何らかの圧縮が必要です。

現実世界の各立方メートルのプロパティを見つけることはほとんどないので、仮定に基づいて不確かなデータを生成する方法が必要になります。したがって、それを理解できれば、すべてのデータを計算して保存する必要はありませんが、その場で生成できます。

何よりもまず、地球内のすべてのボクセルを破棄できます。これは、誰かが実際に穴を掘った場合にのみ計算する必要があるためです。ボクセルが表示されます。

地球の表面については、おそらく計算の出発点として画像を使用します。多分ある種の温度と湿度のマップは、あなたが適用するブロックのタイプを計算することを可能にするでしょう。例えば。水、砂（砂漠）、草、雪など。画像には、おそらく地表の1平方メートルごとに1ピクセルの情報がないので、これをノイズと混ぜて、表面。常に同じランダムシードを使用する場合でも、結果は確定的でなければなりません。

さらに、標高マップが役立つので、サーフェスフィーチャの高さを決定できます。そうすれば、山などを追加できます。

つまり、地表に関する情報を含む2D画像のデータ量になります。内側のすべてについて、純粋な手続き型アプローチに戻り、地球中心からの距離に応じて、さまざまなタイプのブロックをレンダリングします。しかし、上記のように、これらは、誰かが穴を掘るときにのみ計算する必要があります。

変更を永続的にするために、私は変更を世界にのみ保存します。したがって、誰かが穴を掘った場合、取り除いたボクセルに関する情報を保存します。これは、周囲のボクセルを手続き的にレンダリングできるはずだからです。

レンダリングについて：これを機能させるには、高度な詳細レベルとカリングアルゴリズムが必要です。カメラが全世界を表示するズームレベルにある場合、すべてのサーフェスボクセルをレンダリングするのはばかげています。このレベルでは、ボクセルははるかに大きくなるはずです。おそらく、単純なテクスチャの球体で十分でしょう。

最もトリッキーなことは、ボクセルのプロパティを計算できるソリッドジェネレーターを用意して、さまざまな「解像度」でも、それを使用してさまざまな詳細レベルを生成できるようにすることです。

基本的に、Minecraftと同じことを行うことができます。このような量のデータを作成するのではなく、世界を数式として定義できます。表示にデータが必要な場合は常に、数式を使用して生成します。

このような式は通常、Perlinノイズの概念を使用して構築されます。これにより、すべてのレベルの詳細が可能になり、現実の世界と同じ大きさの山脈を持つことができますが、その一部のみを生成することを選択できます。好みの量のディテールを生成できるので、近いものに対して非常に細かいディテールを作成することが可能でありながら、必要なレベルのディテールで遠くの風景を生成することもできます。

Minecraftは、あなたが訪れたすべてのブロックを保存し、加えられた変更を加えて完全に保存します。生成された世界と更新された世界の違いのみを保存することもできますが、大きなブロックを保存する方が簡単で、比較的よく圧縮されます。

本当にこれを限界まで利用できるゲームはないと思いますが、大規模なゲームワールドのすべての「重要でない」ディテールの公式生成を使用することは非常に一般的です。単にロットを生成してディスクに配置するのではなく、必要なときに生成する方法がどれほど一般的であるかはわかりません。

地球の大陸のベクトルデータを探すことができます。これは、ベクトルデータには任意のスケールにスケーリングできるという利点があるためです。地球の高さマップと組み合わせて、地形の高さを生成します。最後のステップは、詳細な衛星画像です。ここから、画像に基づいて上部ブロックのタイプを選択できるため、岩のある場所の岩、砂のある場所の砂などを取得できます。実際の惑星の内部が生成されるはずです。 Minecraftのように、詳細な地理データを見つけることができない場合を除きます。基本的には、XYZ座標入力のみを指定して、地理データを検索し、そこから外挿します。これは、データが限られていることを意味し、残りをできる限り正確に推定します。