7

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

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

私は geomipmapping、geometry clipmap (GPU)、および Ulrich によるチャンク LOD について知っています。これらは大規模な地形で適切に機能し、立方体の 6 つの面をレンダリングしてからこの方法で立方体を「球体化」するために使用でき、すべてを実装する方法を理解しています。 C++/OpenGL/GLSL を使用して GPU でこれらのメソッドを使用します (ROAM などのメソッドを使用するか、キューブを使用しない他のメソッドを使用することは、テクスチャリングが面倒であるため、私の手の届かないところにあります)。

だから、私はすべての方法を実装し、どの方法が惑星規模に最適でより適しているかを確認する時間がありません。誰かがこの種の比較を行っているかどうかを確認し、どの方法を決定するのを手伝ってくれるかをここで尋ねています.実装して使用する必要がありますか (私の家庭教師はちょっとクレイジーで、正二十面体で何かをしてほしいと言っていますが、ROAM を使用しない限り、その方法を理解できません)

とにかく、私が決めるのを手伝ってくれたり、他の提案や方法があれば、本当に感謝しています. 1 つの条件は、CPU のボトルネックを防ぐために、メソッドが GPU 側 (少なくともそのほとんど) を実装できる必要があることです。

もう 1 つのリクエストは、地形の詳細を取得する際にフロートの精度に関する数値的な問題があることを知っていることです。解決方法がわかりません。フォーラムで解決策を読みましたが、方法を理解できません。実装すると、そのスレッドを見失いました。この精度の問題を解決する方法を知りたいです。

PD: 私の英語でごめんなさい。

[編集] 現在、フロート精度、Z ファイティングの問題、動的 Z 値を使用したフラストラム カリング、およびチャンクのデータ表現を解決するためのいくつかの行列変換について読んでいます (フロートを含むパッチ空間とワールド座標での位置を次のように使用) double) なので、精度の問題は簡単に解決できると思います。このプロジェクトにどちらが適しているかを判断するために、LOD メソッドとあなたの意見や提案を比較する必要があります。実装の難しさvsビジュアル品質vsパフォーマンスを考慮して、私は最高のものを望みます。

私が言及するのを忘れていたのは、世代がハイブリッドであることです。つまり、GPU (オンザフライで計算された高さ) を使用して、および/またはベースの高さマップ イメージを使用して惑星を完全にレンダリングし、GPU (頂点シェーダー) で詳細を追加できるはずです。 . テクスチャリングは後回しにします。今のところ、高さに応じた色だけを使用するか、フラグメント シェーダーで生成された何らかのノイズ テクスチャを使用することで満足しています。

4

1 に答える 1

23

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

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

  • Spherified Cube:四分木を実装した 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 が最適です。どちらも、大規模な地形のデータベース、手続き型、または混合 (固定データまたは高さマップに基づく地形と手続き型作業で追加された詳細) レンダリングで非常にうまく機能します。

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

一方、チャンク LOD はレガシー ハードウェアに最適で、GPU 側の計算を実行する必要がなく、大規模なデータセットには最適ですが、手続き型データをリアルタイムで処理することはできません (変更を加えると可能になるかもしれません)。

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

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

Geomipmapping は優れた手法であり、quadtree を利用し、投影ピクセル エラーが低くなりますが、惑星のレンダリングでは、少なくとも 16 レベル以上の詳細を設定する必要があります。つまり、(pourposes をステッチするために) 追加のパッチが必要になります。異なるレベルを接続して隣のレベルを処理するには、特に 6 つの地形面を使用すると、解決するのが面倒になる可能性があります。

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

問題:

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

    これに対する最善の解決策は、「GPU を使用した目に対するレンダリング」メソッドを使用することです。この方法は、本「3D Engine Design for Virtual Globes」(インターネットでも見つけることができると確信しています) で説明されており、基本的にはすべての位置を CPU 上の double で設定する必要があります (パッチ、クリップマップ、オブジェクト、視錐台、カメラなど)、次に MV は、変換を (0, 0, 0)T に設定することでビューアーの中心に配置され、double は 2 つの float の小数 (仮数) ビットを使用して固定小数点表現でエンコードされます。そして何らかの方法で高い（Ohlarikの実装の使用と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 方式でレンダリングしているため、遠方のオブジェクトは三角形が少ないため、必要な精度が低くなります。

言及する重要なことは、リストされているすべてのメソッド (射影グリッドを除く) は、ゲームを作成する場合に必須のクアッドツリー ベースのため、物理 (主に衝突) を行うときに非常に優れているということです。

結論として、利用可能なすべてのオプションをチェックして、より快適に感じるオプションを選択してください。私の意見では、CDLOD は素晴らしい仕事をします。ジッタと Z バッファの問題を解決することを忘れないでください。そして最も重要なことは、作成を楽しんでください!

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

立方体の球体化に関する完全なデモンストレーションについては、このリンクを確認してください。

ジッタリングと Z バッファーの精度の解決に関するより良い説明については、この本を確認してください。

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

于 2013-06-20T05:04:11.637 に答える