OpenGL ES 2.0 GLSL 機能を使用して画像を操作しています。私が実現したいのは、フラグメント シェーダー内のテクスチャからサンプルをフェッチするときに、特定の詳細レベル (LOD) を選択することです。どうやら、OpenGL ES 2.0 のフラグメント シェーダーではサポートされていません (ただし、オプションでそれを提供できるtexture2DLod()拡張機能があります)。GL_EXT_shader_texture_lod

ただし、デフォルトtexture2D()関数は、3 番目のオプション パラメータ バイアスを提供します。私が理解している限り、このパラメーターは現在の LOD に追加されたオフセットであると想定されています。

私のテストでは、画面サイズのクワッドを描画し、サンプル座標をスケーリングしてテクスチャを拡大しています。縮小フィルターとして GL_LINEAR_MIPMAP_LINEAR を使用して、テクスチャのミップマッピングを有効にしました。ARM Mali-400 GPU でゼロ以外のバイアス パラメーターを使用してサンプリングした場合の結果は、下の画像で確認できます。

一部のピクセルが縮小フィルターを使用し、他のピクセルが拡大フィルターを使用していることを示す ISTM。

これはどのように制御されていますか？また、バイアスを使用する場合に初期 LOD を決定するにはどうすればよいですか? 頂点シェーダーから調整できますか?

関連する質問は次のとおりです。

GLSL サンプラーは、テクスチャの縮小、つまりミップマップ レベルをどのように決定しますか?

更新: 画面を覆うようにテクスチャをサンプリングすると、(拡大されていても) 適切なミップマップ ルックアップを実行しているように見えることに気付きました。ここで、サンプル座標に小さなオフセットを追加すると、上の画像に見られるバンディングが見え始めます (さらに拡大されています)。バイアス パラメータを使用しない場合、バンディングはまったく見られません。

私は、次の withpaper NVidia TerrainTessellation WhitePaperから直径で LoD を実装しました。章「ハル シェーダー: テッセレーション LOD」7 ページには、直径を使用した LoD の非常に優れた説明があります。ここに良い引用があります：

パッチ エッジごとに、シェーダーはエッジの長さを計算し、その周囲に概念的に球体を当てはめます。球はスクリーン スペースに投影され、そのスクリーン スペースの直径を使用して、エッジのテッセレーション ファクターが計算されます。

ここで私の HullShader:

コードのグラフィカルな説明: まず、2 つの頂点間の中心を見つけます 。長さを計算してテッセレーション ファクターを計算するために、投影空間で 「円」プロジェクト sUp と sDown のカメラから直交基底 (カメラ方向に対して直角) を見つけ ます。

問題

テッセレーションはうまくいきました。しかし、いくつかのテスト上の理由から、オブジェクトを回転させたので、テッセレーションが回転に合わせて進行しているかどうかを確認できます。100%正しくないと思う部分もあります。平面を見てください。この平面は (1.0f, 2.0f, 0.0f) だけ回転しており、明るい赤は、暗い赤に比べてテッセレーション ファクターが高いことを示しています。緑色は係数 1.0 です。平面の下部よりも上部の方が詳細である必要があります。

私は何が欠けていますか？

いくつかのテストケース

ローテーションのものを削除すると、次のようになります。

回転を削除し、直交基底計算のこの単純なバージョンを含めると、次のようになります。

次のようになります。

ルックアップ ベクターを使用していない場合、問題になる可能性はありますか? LoDの調子はどうですか？私は何か他のことをしようとしています...

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

私はまだ研究を終えており、この主題について多くのことに遭遇しました。問題は、どの 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 (頂点シェーダー) で詳細を追加できるはずです。 . テクスチャリングは後回しにします。今のところ、高さに応じた色だけを使用するか、フラグメント シェーダーで生成された何らかのノイズ テクスチャを使用することで満足しています。

LOD の概念は理解していますが、そのマイナス面を見つけようとしていますが、グーグルでそれを参照していません。私が遭遇し続ける唯一の長所は、オブジェクトが遠くにある場合は詳細を省略し、オブジェクトが近くにある場合はより良いグラフィックを表示することでパフォーマンスが向上することです.

真剣に、それが唯一の賛否両論ですか？ご意見をお聞かせください。Tnks。

グリッドベースの地形とロッド用の四分木があります。1 つのシミュレーション ステップで、次のことを行います。

1. 入力を処理します。
2. マトリックスを更新します。
3. quadtree を構築します (錐台カリングの表示、距離チェック)。
4. 亀裂を閉じます。
5. 有効なポイントを頂点配列にコピーします。
6. 頂点配列を描画します。

当然、接続されていないポイントをチェックせずに、ロッドが異なる隣接するクワッドの間にクラックが発生します。

カメラを静止させたまま、すべての隙間を塞ぐことができます。

しかし問題は、私のカメラが動いている間、最後のフレームの後に変更されたいくつかのクワッドの間に目に見える亀裂があることです.

OpenGL ES 2.0 フラグメント シェーダーでミップマップされたテクスチャの詳細レベルを理解しようとしています。

この回答によると、biasパラメーターを使用texture2Dしてフラグメントシェーダーの特定の詳細レベルにアクセスすることはできません。この投稿によると、詳細レベルは代わりに、隣接するフラグメントの並列実行から自動的に計算されます。それが物事の仕組みだと信じなければなりません。

私が理解できないのは、その理由です。特定のレベルの詳細にアクセスできないのはなぜですか?実際には非常に簡単なはずなのに、アクセスできないのはなぜですか? なぜ代わりに複雑な固定機能に頼らなければならないのでしょうか?

私には、これは非常に直感に反するように思えます。結局のところ、OpenGL 関連のものはすべて、固定機能から離れて進化しています。また、OpenGL ES は、OpenGL よりも幅広いハードウェアをカバーすることを目的としているため、多くの単純なバージョンのみをサポートしています。したがって、仕様の開発者が LOD パラメーターを必須 (おそらくデフォルトはゼロ) であると判断し、シェーダー プログラマーが適切と考える方法で適切な LOD を計算する必要があることを完全に理解できます。その計算を自動的に行う関数を追加することは、デスクトップの OpenGL で期待していたことのように思えます。

特定のレベルへの直接アクセスを提供しないことは、どう見ても私にはまったく意味がありません。特に、そのbiasパラメーターは実際に詳細レベルを微調整できることを示しているため、これは明らかに、並列処理される一連のフラグメントの単一レベルのメモリからデータをフェッチすることではありません。他に理由が思いつきません。

もちろん、なぜ質問が意見を引き寄せる傾向があるのか​​. ただし、Stack Overflow では意見に基づく回答は受け付けていないため、意見はコメントとしてのみ投稿してください。一方、回答は、明確な知識を持っている人の発言など、検証可能な事実に基づいている必要があります。この事実について開発者が話し合った記録があれば、それで完璧です。内部の誰かがこの問題について議論しているブログ投稿があれば、それは非常に良いことです。

スタック オーバーフローの質問は実際のプログラミングの問題に対処する必要があるため、理由を尋ねるのは悪い質問であると主張する人もいるかもしれません。答えを得ても、その明示的な lod アクセスが突然現れるわけではないので、差し迫った問題の解決には役立ちません。しかし、ここでの理由は、これまで把握していなかった OpenGL ES の動作に関する重要な側面にあるのではないかと思います。その場合、この 1 つの決定の背後にある動機を理解することは、私や他の人が OpenGL ES 全体をよりよく理解し、パフォーマンス、正確性、移植性などの点でプログラムでより有効に利用するのに役立ちます。 . したがって、私はこの質問を「何が欠けているのか?」と述べたかもしれませんが、これは現時点で私にとって非常に現実的なプログラミングの問題のように感じます。