問題タブ [ssao]

現在、ボクセルの束をレンダリングする LWJGL の作業シーンがあります。ジオメトリのすべての頂点、法線、および色を含む VBO と、それを画面に表示する glDrawArrays() を使用しています。

SSAO、または Screen-Space Ambient Occlusion を使用してシーンをレンダリングする方法を Google で検索しました。私が見つけたほとんどすべての結果は、必要な GLSL コードを詳述しているだけですが、必要な lwjgl コードは完全に除外されています。

これは、SSAO 用に見つけた Fragment シェーダーの 1 つです (作成者が誰であったか、または投稿した人が元の作成者であったかどうかは覚えていません)。

私の質問は、変数を渡すために LWJGL スペースで何をしなければならないかということです

texture0が 2D テクスチャ フォーマットの深度バッファである場合、どのように作成すればよいですか?

ジオメトリ VBO を画面にレンダリングしてから、深度バッファ テクスチャを取得する必要がありますか?

そして、texture1とは何ですか? 私のプログラムはテクスチャではなく色のみを使用しているため、それが何であるかわかりません。

John Chapman ( http://john-chapman-graphics.blogspot.nl/2013/01/ssao-tutorial.html ) によるチュートリアルに従って、遅延レンダラーに SSAO を実装しています。SSAO シェーダーへの入力バッファーは次のとおりです。

• w 成分として線形化された深さを持つワールド空間の位置。
• ワールド空間法線ベクトル
• ノイズ 4x4 テクスチャ

最初に完全なシェーダーをリストしてから、簡単に手順を説明します。

ただし、結果は満足のいくものではありません。オクルージョン バッファはほとんどすべて白で、オクルージョンは表示されません。ただし、オブジェクトに非常に近づくと、以下に示すように、奇妙なノイズのような結果が表示されます。

これは明らかに正しくありません。私はかなりの割合でデバッグを行い、関連するすべての変数が正しく渡されていると信じています (それらはすべて色として視覚化されています)。ビュー空間で計算を行います。

いずれかの手順で問題が発生した場合に備えて、私が実行した手順 (および選択) について簡単に説明します。

ビュー空間の位置/法線 John Chapman は、ビュー レイと線形化された深度値を使用して、ビュー空間の位置を取得します。フラグメントごとのワールド空間位置が既にある遅延レンダラーを使用しているので、単純にそれらを取得し、それらをビュー マトリックスで乗算して、ビュー空間に取得します。

法線ベクトルについても同様のアプローチをとります。バッファ テクスチャからワールド空間法線ベクトルを取得し、それらを [-1,1] 範囲に変換し、ビュー マトリックスの転置 (逆 (mat3(..))) で乗算します。

ビュー空間の位置と法線は、次のように視覚化されます。

これは私には正しいように見えます。

半球を法線 の周りに配置する マトリックスを作成する手順tbnは、John Chapman のチュートリアルで説明されている手順と同じです。次のようにノイズ テクスチャを作成します。

フラグメント シェーダーでノイズを視覚化できるので、機能しているように見えます。

サンプル深度 すべてのサンプルを接線からビュー空間に変換します (サンプルは、xy 軸の [-1,1] と z 軸の [0,1] の間でランダムになり、それらをフラグメントの現在のビュー空間位置 (原点) に変換します)。

次に、線形化された深度バッファーからサンプリングします (オブジェクトを近くで見たときに以下で視覚化します)。

最後に、サンプリングされた深度値を現在のフラグメントの深度値と比較し、オクルージョン値を追加します。それがこの動作の原因であるとは思わないため、範囲チェックを実行しないことに注意してください。今のところ、できるだけ最小限に抑えたいと思います。

何がこの動作を引き起こしているのかわかりません。深度値のサンプリングのどこかにあると思います。私が正しい座標系で作業していると言える限り、線形化された深度値もビュー空間にあり、すべての変数はある程度適切に設定されています。

LWJGL でボクセル ゲームを作成していて、SSAO シェーダーを実装する方法を理解しましたが、期待どおりに見えません。ブロックを遠くから見るのは問題ありません。ブロックのグラデーション シャドウの輪郭が見えます。しかし、よく見ると、そのグラデーション シャドウはなくなり、ブロックの色が残ります (さらに、各ブロックの側面に異なる色合いを与えるために作成した別の単純なシェーダー)。

さまざまな距離からゲームがどのように見えるかは次のとおり です。

これが私が期待していたものです: https://github.com/ninthworld/GreedyMeshing/raw/master/screenshot3.png

そして、これは私の SSAO.frag シェーダー コードがどのように見えるかです:

2 つのサンプラーはそれぞれ、GL_RGBA と GL_DEPTH_COMPONENT から作成したテクスチャを受け取り、gl_FragColor は画面を占める 2D 平面に描画します。

コードの詳細を見ると役立つ場合は、github ページhttps://github.com/ninthworld/GreedyMeshingをご覧ください。

タスクの背景

John Chapman によるチュートリアルに基づくOGLDev チュートリアル 45の後にSSAOを実装しようとしています。OGLDev チュートリアルでは、非常に単純化された方法を使用します。これは、フラグメント位置を中心とした半径内のランダム ポイントをサンプリングし、その場所に保存されている実際のサーフェス深度よりも深い深度を持つサンプリング ポイントの数に応じて AO 係数をステップアップします (より多くの位置フラグメントの周りは、オクルージョンが大きいほど、その前にあります)。

私が使用する「エンジン」には、OGLDev ほどモジュラーなディファード シェーディングはありませんが、基本的には、まず画面全体の色をテクスチャ アタッチメントと深度レンダー バッファー アタッチメントを使用してフレーム バッファーにレンダリングします。深さを比較するために、フラグメント ビュー空間の位置は、テクスチャが添付された別のフレーム バッファにレンダリングされます。これらのテクスチャは、SSAO シェーダーによって後処理され、結果は画面いっぱいのクワッドに描画されます。独自の両方のテクスチャがクワッドにうまく描画され、シェーダー入力のユニフォームも問題ないように見えるので、エンジン コードを含めていないのはそのためです。

以下に示すように、フラグメント シェーダーはほぼ同じです。個人的な理解に役立つコメントをいくつか含めました。

何が機能しますか?

• フラグメントの色のテクスチャは正しいです。
• テクスチャ座標は、描画して [0, 1] に変換される画面塗りつぶしクワッドの座標です。それらは次のように同等の結果をもたらしますvec2 texCoord = gl_FragCoord.xy / textureSize(screenColorTexture, 0);
• (パースペクティブ) 射影行列は、カメラが使用するものであり、その目的のために機能します。いずれにせよ、これは問題ではないようです。
• 意図したとおり、ランダム サンプル ベクトル コンポーネントは [-1, 1] の範囲にあります。
• フラグメント ビュー スペースの位置のテクスチャは問題ないようです。

どうしたの？

フラグメント シェーダーの下部にある AO ミキシング ファクターを 0 に設定すると、fps キャップまでスムーズに実行されます (計算がまだ実行されていても、少なくともコンパイラーはそれを最適化しないと思います :D )。しかし、AO が混在している場合、フレーム描画ごとに最大 80 ミリ秒かかります (バッファーがいっぱいになっているかのように、時間とともに遅くなります)。結果は非常に興味深く、混乱を招きます。

明らかに、マッピングは遠く離れているように見え、ちらつきノイズは、あたかもランダム サンプル ベクトルに直接対応しているかのように、非常にランダムに見えます。オクルージョン計算によるものではなく、AO 係数の追加によってのみ描画時間が大幅に増加したことは、最も興味深いことでした。描画バッファに問題はありますか?

それでSSAOを実装しようとしましたが、意図したとおりに機能していません。位置 z=0 (ワールド空間) で分割されているように見えます。位置 z=0 に白い線があります。また、オクルージョンが正しく見えません。

さらに距離が離れているため、カメラを移動すると、オクルージョンがさらに奇妙になります

ジオメトリをレンダリングするためのマイ シェーダー (インスタンス化):

バーテックス：

断片：

ジオメトリ パスの後、SSAO パスを法線情報と深度情報とともに適用します。

これは私のNoiseTextureです:

ハードウェアの深度バッファを使用します。ワールド空間ですべてを計算します。

フラグメント シェーダーは次のとおりです。

Oriented-Hemisphereレンダリング技術を使用した SSAO (Screen-Space Ambient Occlusion) アルゴリズムに取り組んでいます。

I) アルゴリズム

このアルゴリズムには、入力として次が必要です。

• 事前に計算されたサンプルを含む 1 つの配列 (メイン ループの前にロードされる -> 私の例では、z 軸に沿って配置された64 個のサンプルを使用します)。
• 正規化された回転ベクトルを含む 1 つのノイズ テクスチャも z 軸に従って方向付けられます (このテクスチャは 1 回生成されます)。
• GBuffer からの 2 つのテクスチャ: ビュー スペース内の位置と法線ベクトルを含む「PositionSampler」と「NormalSampler」。

私が使用するフラグメントシェーダーのソースコードは次のとおりです。

結果は次のとおりです (ブラー レンダー パスなし):

ここまではすべて正しいようです。

Ⅱ）パフォーマンス

NSight Debuggerのパフォーマンスに関する非常に奇妙な動作に気付きました。

カメラをドラゴンにどんどん近づけると、パフォーマンスが大幅に影響を受けます。

しかし、私の考えでは、SSAO アルゴリズムは Screen-Space に適用され、たとえばドラゴンのプリミティブの数に依存しないため、そうではありません。

3 つの異なるカメラ位置を使用した 3 つのスクリーンショットを次に示します (これら 3 つのケースでは、すべての 1024*768 ピクセル シェーダーがすべて同じアルゴリズムを使用して実行されます)。

a) GPU アイドル: 40% (影響を受けるピクセル: 100%)

b) GPU アイドル: 25% (影響を受けるピクセル: 100%)

c) GPU アイドル: 2%! (影響を受けるピクセル: 100%)

私のレンダリング エンジンは、私の例で正確に 2 つのレンダー パスを使用します。

• マテリアル パス(位置と通常のサンプラーを埋める)
• アンビエント パス(SSAO テクスチャを塗りつぶす)

問題はこれら 2 つのパスの実行の追加にあると考えましたが、カメラが静止している場合にマテリアル パスを計算しないという条件をクライアント コードに追加したため、そうではありません。上の 3 枚の写真を撮ったときは、アンビエント パスが実行されただけです。したがって、このパフォーマンスの欠如は、マテリアル パスとは関係ありません。もう 1 つの議論として、ドラゴン メッシュ (平面のみのシーン) を削除しても、結果は同じです。カメラが平面に近づくほど、パフォーマンスが大幅に低下します。

私にとって、この振る舞いは論理的ではありません! 上で述べたように、これら 3 つのケースでは、すべてのピクセル シェーダーがまったく同じピクセル シェーダー コードを適用して実行されます。

フラグメント シェーダー内でコードの一部を直接変更すると、別の奇妙な動作に気付きました。

行を置き換えると：

行によって：

性能不足が解消！

これは、SSAO コードが正しく実行され (確認のために実行中にいくつかのブレーク ポイントを配置しようとした場合) 、最終的な出力色を塗りつぶすために最後にこのOcclusionFactorを使用しない場合、パフォーマンスの不足がないことを意味します。 !

この問題は、 「FragColor = vec4(OcclusionFactor);」という行の前のシェーダー コードに起因するものではないと結論付けることができると思います。... おもう。

そのような行動をどのように説明できますか？

クライアント コードとフラグメント シェーダー コードの両方で多くのコードの組み合わせを試しましたが、この問題の解決策が見つかりません。私は本当に迷っています。

よろしくお願いいたします。

この簡単なテスト シーンでは、SSAO と FXAA のエフェクトを一緒に構成する必要がありますが、うまくいきません。SSAO が有効なときに FXAA も有効にすると、レンダリングが黒くなります。

フィドルでコメントを外すcomposer.addPass(FXAA_effect);と、問題が表示されます。これらの効果を一度に 1 つずつ追加する方法のさまざまな例を確認します。それらは個別に機能しますが、まとめることはできません。

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

JSFiddle: http://jsfiddle.net/ur3tpwag/

それがコードです：

SSAO シェーダー (スクリーン スペース アンビエント オクルージョン) をアンチエイリアシング レンダー スタック (スーパー サンプリング アンチエイリアシング) に統合したいと考えています。AA は高品質のレンダリングに必要です。私の GPU が提供するデフォルトのアンチエイリアシングは常に十分ではありません。現在、SSAO は通常のレンダリング プロセスに既に統合されていますが、私の新しい目標は、両方の手法を組み合わせることです。

このために、私はフィドルを設定しました。最初の EffectComposer は、キャンバスの 2 倍の解像度で renderTarget にシーンをレンダリングします。このことから、SSAO に depthTarget を使用したいと思います。最後のステップは、レンダリングされたイメージをキャンバスのサイズの平面に描画することです。これにより、ダウンサンプリングが行われるため、アンチエイリアシング効果が得られます。

フィドルへのリンク: SSAO+SSAA

スタックは次のように設定されます。

レンダリング関数は次のように設定されます。

私は同様の状況を見つけていないので、私の質問: ssao が使用されるようにスタック全体をセットアップする方法。

こんにちは、トーマス