惑星レンダリングに最適なLODメソッドはどれですか？

私は現在、私の論文に取り組んでいます。それは惑星サイズの地形をレンダリングするエンジンです。

私はまだ研究を終えており、この主題に関する多くの問題に遭遇しました。問題は、どの詳細レベル（LOD）メソッドを使用すべきかを決定できないことです。

ジオミマップ、ジオメトリクリップマップ（GPU）、UlrichのチャンクLODについて知っています。これらは大きな地形でうまく機能し、キューブの6つの面をレンダリングし、この方法でキューブを「球状化」することができます。 C ++ / OpenGL / GLSLを使用したGPUでのこれらのメソッド（ROAMなどのメソッドを使用するか、キューブを使用しない他のメソッドを使用することは、テクスチャリングが苦手なので私の手の届かないところにあります）。また、最近、ここでテッセレーションシェーダーを使用して地形をレンダリングするチュートリアルに参加しました

だから、私はすべての方法を実装し、どれが惑星規模に最適でより適しているかを見る時間がないので、誰かがこの種の比較を行ったかどうかを確認し、どの方法を決定するのを助けたいと思います私は実装して使用する必要があります（私の家庭教師はちょっと変わっていて、20面体で何かをしたいと思っていますが、ROAMを使用しないとその方法を理解できません）

とにかく、あなたが私を決定するのを手伝うことができるか、または他の提案または方法があるならば、私は本当に感謝します。1つの条件は、メソッドがCPUのボトルネックを防ぐためにGPU側（少なくともそのほとんど）を実装できることです。

別の要求は、地形で多くの詳細を取得するときにフロートの精度に関する数値的な問題があることを知っていることです。それを解決する方法がわかりません。実装すると、そのスレッドを追跡できなくなり、この精度の問題を解決する方法を知りたいと思います。

私は現在、フロートの精度、zファイティングの問題、動的z値での錐台カリング、チャンクのデータ表現を解決するためのいくつかのマトリックス変換について読んでいます（フロートとワールド座標での位置をダブルとして使用）精度の問題は簡単に解決できると思います。このプロジェクトに最適なLODメソッドを決定するために、LODメソッドとあなたの意見や提案を比較する必要があります。実装の難易度と視覚的品質とパフォーマンスを考慮に入れて、最高のものが欲しいです。

私が言及するのを忘れていたのは、世代がハイブリッドであるということです、つまり、GPU（その場で計算される高さ）を使用して、および/またはベースの高さマップ画像を使用して、地球を完全にレンダリングし、GPU（頂点シェーダー）。テクスチャリングは、私が後者を悩ます側面の部分になります。今は、高さに応じて色だけを使用するか、フラグメントシェーダーで生成された何らかのノイズテクスチャを使用することができます。

最後に、多くの調査を行った後、誰かが前に言ったように、普遍的に「最良の」方法はないと結論付けることができます。しかし、私の研究により、次のことを知るようになりました。

最終的に使用するメッシュに応じて：

• Spherified Cube： quadtree実装を使用したLODメソッドはすべて正常に動作します。面間の境界などの特別な場合には注意する必要があります。
• その他： ROAM（新しいバージョン2.0またはBDAM、CABTT、RUSTICなどの他の拡張機能）はうまくいくと思いますが、これらのアルゴリズムは動作が難しく、より多くのメモリを必要とし、キューブを使用する他のアプローチよりも少し遅いです。

うまく適合することができる多くのLODメソッドがありますが、私の個人的なトップ5は：

1. 連続距離依存LOD（CDLOD）
2. GPUベースのジオメトリクリップマップ（GPUGCM）
3. チャンクLOD
4. OpenGL GPUテセレーションによる地形のレンダリング（書籍：OpenGL Insight、第10章）
5. 幾何学的ミップマッピング

それぞれがテレインをレンダリングする独自の方法を提供します。たとえば、CDLODはシェーダー（GLSLまたはHLSL）を使用して非常に簡単に実装できますが、CPU（レガシーハードウェア）に実装することもできますが、Planet Renderingの目標は、最新のGPUで最適なため、GPUを圧縮する場合はGPUGCMが最適です。これらは両方とも、大規模な地形のデータベース、手順、または混合（固定データまたは高さマップに基づく地形、および手順作業で追加された詳細）レンダリングで非常にうまく機能します。

また、基本的なGeometrical Clipmapsメソッドへの球体拡張も存在しますが、高さマップの平面サンプルは球体座標を使用してパラメーター化する必要があるため、いくつかの問題があります。

一方、チャンクLODはレガシーハードウェアに最適であり、GPU側の計算を必要とせず、大規模なデータセットには最適ですが、プロシージャデータをリアルタイムで処理することはできません（修正が必要な場合があります）

テッセレーションシェーダーを使用することは、OpenGL 4.xがリリースされて以来、非常に新しい別の手法です。私の意見では、それが最良である可能性があります。精度について。

頂点間の精度を1Kmだけにしたい場合を除き、テッセレーションシェーダーを使用します。この方法で非常に大きな地形の問題は、ジッターを解決するのが難しいことです（少なくとも、私にとってはテッセレーションシェーダーが初めてなので）。

Geomipmappingは優れた手法であり、クアッドツリーを活用し、投影誤差を低く抑えていますが、惑星レンダリングでは少なくとも16以上のレベルの詳細を設定する必要があります。さまざまなレベルを接続して隣人のレベルを管理するために、特に6つのテレインフェイスを使用すると、これは解決するのが面倒です。

別の方法があり、それ自体が非常に具体的です。「惑星地形の投影グリッドマッピング」は視覚化に優れていますが、欠点があります。詳細を知りたい場合は、リンクにアクセスしてください。

問題点：

• ジッタ：今日のGPUのほとんどは32ビットの浮動小数点値のみをサポートしていますが、これは惑星規模の地形で大きな位置を操作するのに十分な精度を提供しません。ジッターは、視聴者がズームインして回転または移動すると発生し、ポリゴンが前後に跳ね返り始めます。

  これに対する最善の解決策は、「GPUを使用した目に対する相対的なレンダリング」メソッドを使用することです。この方法は、書籍「Virtual Globes用の3Dエンジンの設計」（インターネットでも見つけることができます）で説明されています。基本的に、CPUのすべての位置（パッチ、クリップマップ、オブジェクト、視錐台、カメラなど）、MVは変換を（0、0、0）Tに設定することでビューアーを中心に配置され、doubleは2つのfloatの小数部（仮数）ビットを使用して固定小数点表現でエンコードされます。いくつかの方法で高い（Olarikの実装とDSFUN90 Fortranライブラリの使用について読んでください）。

  頂点シェーダーは、追加の2つの減算と1つの加算のみを必要としますが、GPU RTEは位置に必要な頂点バッファーメモリの量を2倍にします。位置のみが保存されている場合を除き、これは必ずしもメモリ要件を2倍にするわけではありません。

• 深度バッファーの精度：Zファイティング。非常に大きな地形をレンダリングしているため、この場合：惑星、Zバッファーは巨大でなければなりませんが、znearとzfarに設定した値は重要ではありません。常に問題があります。

  Zバッファは浮動小数点の間隔に依存し、また（遠近法による投影は非線形ですが）線形であるため、32ビット浮動小数点の精度が低いため、目の近くの値はZファイティングの影響を受けます。

  この問題を解決する最良の方法は、「対数深度バッファ」を使用することです http://outerra.blogspot.com/2012/11/maximizing-depth-buffer-range-and.html

  対数深度バッファーは、zscreenの対数分布を使用することにより、遠くのオブジェクトの深度バッファーの精度を向上させます。近くのオブジェクトの精度と、遠くのオブジェクトの精度を交換します。LODメソッドを使用してレンダリングするため、遠くのオブジェクトは三角形が少ないため、精度が低くなります。

言及するべき重要なことは、リストされているすべてのメソッド（射影グリッドを除く）は、Quadtreeベースのために物理学を行うときに非常に優れていることです（ほとんどの場合、衝突）。

結論として、利用可能なすべてのオプションを確認し、より快適なオプションを選択してください。CDLODは素晴らしい仕事をしていると思います。ジッタとZバッファの問題を解決することを忘れないでください。そして最も重要なことは、それを楽しんでください！

LODの詳細については、このリンクを確認してください。

キューブの球状化に関する完全なデモについては、このリンクを確認してください。

ジッターとZ-Bufferの精度の解決に関するより良い説明については、この本をチェックしてください。

この小さなレビューがお役に立てば幸いです。