問題タブ [deferred-shading]

オフスクリーン バッファを介して複数のテクスチャを渡そうとすると問題が発生します。問題は、他のテクスチャが適切に作成されていないことです。私に割り当てられたタスクは、sponza シーンの遅延レンダリングです。

この問題を解決するのを手伝ってくれませんか?

プログラムの作成:

テクスチャを FBO にバインドする:

GBuffer の構築:

頂点シェーダー:

フラグメント シェーダー:

私は OpenGL アプリで遅延シェーディングを実装していますが、位置情報を格納するために大量のメモリを浪費するのではなく、深度バッファーからの情報を使用してフラグメント シェーダーでビュー空間の位置を再構築したいと考えています。完全にはわかりませんが、正しい x/y があるように見えますが、z 情報が窓の外にあることはわかっています。位置の再構築を担当するフラグメント シェーダーの部分を次に示します。

matInvProj私の射影行列の逆です（CPUで計算され、均一なmat4としてアップロードされます）。位置情報 ( ) をレンダリングしようとするとfragColor = vec4(position, 1.0);、画面の左下隅が黒、右下隅が赤、左上隅が緑、右上隅が黄色になります。これは、深度がシーン全体で一様に 0.0 である場合に期待するおおまかなものですが、明らかにそうあるべきではありません。

私は何を間違っていますか？

私の遅延レンダラーでは、深度バッファーからフラグメントの位置を正常に再構築することができました....ほとんど。結果を追加のバッファーに保存されている位置と比較すると、画面から遠く離れた場所で多くのポップが発生していることに気付きました。これが私が見ているもののスクリーンショットです：

上部の緑と黄色の部分は単なるスカイボックスで、位置バッファには (0, 0, 0) が含まれていますが、再構築アルゴリズムはそれを深さ = 0.0 (または 1.0?) の通常のフラグメントとして解釈します。

シーンは を使用してレンダリングされるfragColor = vec4(0.5 + (reconstPos - bufferPos.xyz), 1.0);ため、結果のフラグメントが正確に (0.5, 0.5, 0.5) になる場所は、再構成とバッファーがまったく同じ値を持つ場所です。深度バッファーの奥の方が不正確であることが予想されますが、そのマゼンタとブルーは少し奇妙に思えます。

これは、深度バッファーから位置を再構築する方法です。

ここtexCoord = gl_FragCoord.xy / textureSize(colorBuffer, 0);で、 およびmatInvProjは、gbuffer のレンダリングに使用される射影行列の逆数です。

現在、私の位置バッファーはGL_RGBA32F(精度をテストするためだけのものであるため、帯域幅とメモリの浪費についてはあまり気にしません) であり、深度バッファーはGL_DEPTH24_STENCIL8(から同様の結果が得られましたGL_DEPTH_COMPONENT32。はい、ステンシル バッファーが必要です)。

私の znear は 0.01f で、zfar は 1000.0f です。2000.0fx 2000.0f の大きさの単一のクワッドを地面としてレンダリングしています (遠方の平面でクリップするのに十分な大きさにしたかったのです)。

このレベルの不正確さは許容できると考えられますか? 人々がこの問題を回避する方法にはどのようなものがありますか? ビュー/アイスペースの位置を再構築する方法に何か問題がありますか?

遅延シェーディングについていくつか質問があります。複数のレンダー ターゲットから色、位置、法線、およびテクスチャを取得するところまで来ました。私の質問は、私が次に何をするかに関係しています。テクスチャから正しいデータを取得したことを確認するために、画面にプレーンを配置し、そのプレーンにテクスチャをレンダリングしました。私が理解していないのは、これらのテクスチャを操作して、最終的な出力が照明でシェーディングされるようにする方法です。画面を占める平面または四角形をレンダリングし、すべての計算をその平面に適用する必要がありますか? 私がそうすると、「平面」はレンダリング可能なオブジェクトになるため、複数のライトをこのように機能させるにはどうすればよいか混乱します。そのため、ライトごとに平面を再レンダリングする必要があります。私はこれを間違って考えていますか？

つまり、実際のゲームアートを FBO の 1 つのカラーバッファーにレンダリングし、対応する法線を FBO の別のカラーバッファーにレンダリングします。

(基本的には、複数のレンダー ターゲットを使用して、これとこれを作成したいと考えています。)

私の問題は、何もレンダリングされていないか、正しくレンダリングされていないかのように、最終出力が空白であることです。

私のシェーダー (頂点とフラグメント)

画面に有効にして（FBOではなく）いくつかのスプライトを完全に正常にレンダリングすると、レンダリングされるため、これはうまくいくと確信しています。

次のコードはレンダリング ループにあります。

基本的な考え方は、FBO の 2 つのカラー バッファーを glDrawBuffers でバインドすることです。次に、ゲーム アートと通常のゲーム アートの 2 つのテクスチャ ユニットをバインドします。上記のシェーダーは、これを受け取り、ゲーム アートを 1 つのカラー バッファーに出力し、対応する通常アートを別のカラー バッファーに出力することになっています。

私が言ったように、最終出力は空白です。glCheckFramebufferStatus で確認したので、作成した FBO は有効であると確信しています。

そのFBOからカラーテクスチャを取得して画面に描画すると、空白になります。どこが間違っているのかわかりません。

任意の入力に感謝します。

私はグラフィックエンジンを開発しており、すでに延期されたテクニックを実行していますが、すべてのモデルは、そのマテリアル (独自のシェーダーとテクスチャを使用) とは無関係に、同じシェーダーでレンダリングされているということです。情報を G-Buffer に保存し、その情報を使用してライティング部分を実行する 2 番目のパス。

これは、中央の遅延シェーダーで想定されている方法ですか、それとも、各モデルが独自の方法で G バッファーに情報を格納する独自の遅延パスを持つことができますか?

タスクの背景

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 係数の追加によってのみ描画時間が大幅に増加したことは、最も興味深いことでした。描画バッファに問題はありますか?