1:メッシュがチャンクに分割されることを、チャンクLODパイプラインのどのポイントで理解できない。これは最初のメッシュ生成中ですか、またはこれを行う別のアルゴリズムがあります。
それはどうでもいい事です。たとえば、チャンクをメッシュ生成アルゴリズムに統合できます。これを動的に行うこともできます。そのため、プラズマのような改良アルゴリズムを使用して、より低いレベルが動的に追加されます(たとえば、プレーヤーが近づくにつれて)。アーティスト入力または標高測定データから高解像度メッシュを生成し、アセットのファイナライズ時にすべてのLODチャンクに集約することもできます。または、組み合わせて使用できます。本当にアプリケーションに依存します。
2:チャンクLODデータの格納にQuadtreeデータ構造が使用されていることを理解しています。ポイントが少し欠落していると思いますが、quadtreeは各サブディビジョンレベルの頂点と三角形のデータを格納していますか?
必ずしも。ツリーは、ジオメトリとそのレンダリング方法に関する情報を保存するだけです。これは、すべてのツリーノードに頂点/面のリストがあることを意味します。この日と時代では、より現実的には、メッシュ/インスタンスのハンドルをGPUメモリに保存します。
3a:カメラ距離は通常どのように計算されますか。四分木について読むとき、軸に沿った境界ボックスが多く言及されます。この場合、各チャンクには、カメラまたはプレーヤーが近くにあることを検出するための衝突境界ボックスがありますか?またはこれを行うより良い方法はありますか?(多分レイキャスト?)
非常に安価で簡単なオプションは、チャンクの中心点までの距離を使用して修正することです。この距離は常に過小評価であることがわかっています。中心点がdistanceにあるZ
場合、これはチャンクの半分がそれより近いことを意味します。しかし、私たちが知らないのはオリエンテーションです。エッジオンの幅のチャンクを表示している場合、チャンクのw
最も近いビットはdistanceにありZ-w
ます。ただし、チャンクコーナーを最初に表示している場合、最も近いビットはdistanceにありZ-sqrt(2)*w
ます。この不確実性に耐えることができるなら(ほぼいつでも可能です)、完了です。基本的な三角法を使用して視野角を補正することもできます。
アーチファクトを最小限に抑えるために、カメラからチャンクまでの絶対最小距離を計算することを好みます。実際には、これはポイント平方距離テストを実行することを意味します。中心点までの距離を計算するよりも少し手間がかかりますが、これらのフレームごとに何十億も実行するわけではありません。
物理エンジンを利用してこれを行うことができる場合は、ぜひ行ってください。しかし、実際には、「衝突」よりも「距離クエリ」の観点で考えたいと思います。
3b:チャンクはカメラ距離を自分で計算しますか?
エンジンの設計次第です。ただし、葉を比較的軽量に保つことをお勧めします。プラットフォームによっては、数千のテレインチャンクがフレームごとに独自の更新を実行することによる呼び出しのオーバーヘッドが、パフォーマンスに深刻な影響を与える可能性があります。
4:各チャンクに同じ「解像度」がありますか。たとえば、最上位では、メッシュは32x32になり、各サブノードは32x32になります。
必要はありませんが、すべてのチャンクが同じ容量を占有していると便利です。次に、「GPU」メモリ管理を「チャンク」単位で実行できます。また、1つの解像度が他の解像度の倍数である場合、より多くの頂点を共有するため、異なるサイズの2つのチャンク間の継ぎ目を削除/非表示にするのも簡単です。(例:32x32および64x64は、32x32および57x57よりも管理が簡単です)(Guiberに感謝します!)チャンクジオメトリサイズを変更する正当な理由がある場合は、ぜひ行ってください。