問題タブ [deferred-shading]

最近、FXAAアルゴリズムをOpenGLアプリケーションに実装しました。このアルゴリズムは今のところ完全には理解していませんが、最終的な画像のコントラストデータを使用して選択的にぼかしを適用していることは知っています。意味のある後処理効果として。Bアプリケーションで遅延シェーディングを使用しているため、シーンの奥行きテクスチャがすでにあります。これを使用すると、そこにブラーを適用するためのエッジを見つけるのがはるかに簡単で正確になる可能性があります。

では、エッジを見つけるために最終画像の代わりに深度テクスチャを使用する既知のアンチエイリアスアルゴリズムはありますか？偽物とは、頂点ベースではなくピクセルベースに基づくアンチエイリアスアルゴリズムを意味します。

複数のレンダリングターゲットを持つフレームバッファがあります。それらはすべてテクスチャであり、レンダーバッファではありません。テクスチャのAコンポーネントを深度アタッチメントとして使用するにはどうすればよいですか？デフォルトの深度テストを使用したい。RGBA

こんにちは。dx11エンジンに遅延シェーディングを追加するつもりですが、アーキテクチャに関する質問があります。最初にMRTを使用してgbufferをレンダリングし、それを計算シェーダーに渡してディスパッチし、結果を出力することを考えていました。私の質問は、2つのスワップチェーンを作成します。1つはgbufferをレンダリングし、もう1つはuavを作成して、計算シェーダーをバックバッファーにレンダリングして表示しますか、それとも別の方法がありますか。ここで避けようとしているのは、fullscren quadを使用して、csの出力をレンダリングする必要があることです。オーバーヘッドが多すぎます。前もって感謝します。

計算シェーダー (DirectX 11) を使用してタイル内のライトをカリングするディファード シェーディング システムを実装しているため、安定したフレームレートで何千ものライトを取得できます。ライトがシーンによってブロックされているかどうかを判断する必要があるときに問題が発生します。ポイント ライトが壁と橋を通過することを意味します。メイン ライト (太陽) の視点にシャドウ マップがありますが、シーン上の各ポイント ライトのシャドウ マップを生成するには、1000 のキューブマップを生成する必要があり、それはDead Space 3 や Battlefield 3 などのゲームでは、シーンに多くのライトがありますが、固体オブジェクトを通り抜けることはありません。

編集: OpenCL または計算シェーダーの使用に関するヘルプをまだ探しています。OGL 3.3 を使用し続け、OGL 4.3 と OpenCL 1.2 の不適切なドライバー サポートに対処する必要がないようにしたいのですが、2 つのうちの 1 つを使用せずにこのタイプのシェーディングを行うことは考えられません (ライトとタイル)。GPGPU を使用せずにタイルベースのカリングを実装することは可能ですか?

OpenGL 3.3 で遅延レンダリングを作成しました。現在、ライト パスのカリングは行っていません (すべてのライトに対してフル スクリーン クワッドをレンダリングするだけです)。これには（明らかに）大量のオーバードローがあります。(場合によっては ~100% になることもあります)。このため、ライト パス中のパフォーマンスを改善する方法を検討してきました。(ほぼ) 誰もが考える最善の方法は、スクリーン スペース タイルを使用してシーンを選別することです。これは Frostbite 2 で使用された方法でした。SIGGRAPH 2010 での Andrew Lauritzen のプレゼンテーションを読みました ( http://download-software.intel.com/sites/default/files/m/d/4/1/d/8 /lauritzen_deferred_shading_siggraph_2010.pdf ) であり、その概念を完全に理解しているかどうかはわかりません。（そして、それが他の何よりも優れている理由、そしてそれが私にとって優れているかどうか）

プレゼンテーションで、Laurtizen は、シーンをカリングするためのライト ボリューム、クワッド、およびタイルを使用したディファード シェーディングについて説明します。彼のデータによると、タイル ベースの遅延レンダラーが (群を抜いて) 最速でした。なぜなのかはわかりませんが。タイルごとにすべてのライトがまとめられているという事実と関係があると思います。プレゼンテーションでは、G バッファを 1 回読み取ってからライティングを計算するように指示されていますが、これは私には意味がありません。私の考えでは、これを次のように実装します。

これには、G-Buffer を大量にサンプリングする必要があります。それを行うと、すべてのライトに対して画面に合わせたクワッドをレンダリングするのと同じ（悪くはないにしても）パフォーマンスが得られると思います。言葉遣いからすると、次のようなことが起こっているように思われます。

しかし、一部の GPU でフラグメント シェーダーの命令制限を超えずにこれを行う方法がわかりません。誰でもこれで私を助けることができますか？また、ほとんどすべてのタイル ベースの遅延レンダラーが計算シェーダーまたは OpenCL (ライトをバッチ処理するため) を使用しているように見えますが、これはなぜですか?これらを使用しなかった場合はどうなりますか?

ディファード シェーディング フレームワークでは、さまざまなフレーム バッファ オブジェクトを使用して、さまざまなレンダー パスを実行しています。最初のパスでは、シーン全体の をテクスチャに書き込みます。DEPTH_STENCIL_ATTACHMENTこれを と呼びましょうDepthStencilTexture。さまざまなレンダー パスから格納されている深度情報にアクセスするにはDepthStencilTexture、さまざまなフレーム バッファー オブジェクトを使用します。2 つの方法を知っています
。1) をシェーダーにバインドDepthStencilTextureし、フラグメント シェーダーでアクセスします。これ

私も設定glDisable(GL_DEPTH_TEST)し、glDepthMask(GL_FALSE)

2) をDepthStencilTextureフレームバッファ オブジェクトにバインドしDEPTH_STENCIL_ATTACHMENT、設定glEnable(GL_DEPTH_TEST)しますglDepthMask(GL_FALSE)(編集: この場合、ループ フィードバックを避けるために、シェーダにバインドしませんDepthStencilTexture。Nicol Bolas の回答を参照してください。使用するフラグメント シェーダーgl_FragCorrd.z)

ステンシル テストとステンシル バッファーへの書き込みが必要なライト ボリュームの描画などの特定の状況では、ソリューション 2) を使用します。ステンシルを完全に無視し、深さを に保存する必要がある他の状況では、DepthStencilTextureオプション 1) はより「自然な」オプション 2) よりも利点がありますか?

たとえば、私は（ばかげていると思いますが）それについて疑問を持っています。フラグメント シェーダーでは、深さから WorldPosition を計算することがあります。1)の場合はこうなる

ケース 2) の場合は次のようになります (編集: これは間違っています。gl_FragCoord.z は現在のフラグメントの深度であり、テクスチャに格納されている実際の深度ではありません)

gl_FragCoord.zケース 2) はケース 1) と同じであると想定しています。texture(DepthStencilTexture ,uv).rつまり、DepthStencilTexture. 本当ですか？gl_FragCoord.z現在バインドされている からDEPTH_STENCIL_ATTACHMENTも読み取られますglDisable(GL_DEPTH_TEST)および? glDepthMask(GL_FALSE)

ようやく GBuffer が機能するようになりましたが (実際にはそうではありません)、奇妙な問題がいくつかあり、その理由がわかりません。

画面に法線テクスチャを描画すると、常に法線が表示されます (青い色が常にカメラを指しています)。正しく説明する方法がわからないので、いくつかの画面を次に示します。

(これが私の照明パスがかなり奇妙に見える問題だと思います)

GBuffer を作成する方法は次のとおりです。

ここでジオメトリパス:

ジオメトリ パス シェーダーは次のとおりです。

長い質問/コード フラグメントで申し訳ありませんが、次に何をすべきかわかりません。他の GBuffer 実装ですべてをチェックしましたが、エラーを見つけることができませんでした。

//編集：

問題は gbuffer ではなく、ライティング パスです。私はそれをたくさんいじりましたが、うまくいきません:(

ライティングパスは次のとおりです。

必要に応じて、sencil パスやその他すべての処理を投稿することもできます。

DirectX 11、c++ でディファード シェーディングを実現しようとしています。G-Buffer を作成し、それにシーンをレンダリングすることができました (「GPU PerfStudio」で確認)。最終的なライティング ステージで問題が発生しています。SV_Position が返す座標を使用して、テクスチャ (拡散、法線、鏡面反射光) から読み取ることができません。

これは、光を形状としてレンダリングするために使用されるピクセル シェーダーです。

「GPU PerfStudio」で入力テクスチャが適切にバインドされていることを確認しました。

上記のコードは、テクスチャをクリアするために使用した色を返しています (私のデバッグから、戻り値がピクセル位置 0,0 であることがわかりました)。

問題のある行を次のように置き換えると:-

次に、適切な形状の光で 350,300 ピクセルの位置に値をレンダリングします。

ありがとう