問題タブ [deferred-rendering]

Deferred レンダラーも実装した後、修士論文プロジェクト用に OpenGL で Pre-Pass Lighting アルゴリズムを実装しています。Deferred レンダラーは完全に機能し、PPL の実装はこれに基づいています。アルゴリズムのライティング パスの後、非常に奇妙なアーティファクトが発生しました。シーン内のライトの影響を蓄積する L バッファに含まれるデータは正しいのですが、結果はジオメトリに関してわずかにずれているため、マテリアルパスのシーンに適用すると、結果がはっきりと見えます! （ここに画像を投稿することはできませんが、ここにそれを見るためのリンクがありますhttp://postimage.org/image/kxhlbnl9v/）

ライト マップ キューブは、ジオメトリからのオフセット (軸ごとに異なる) を使用して何らかの方法で計算されているようです。シェーダーと C++ コードを何度も確認しましたが、この問題の原因がわかりません。アイデアが不足しています。以下は、順番に呼び出されるアルゴリズムの 3 つのパスのコードです。コードは今のところ実験的なものなので、この段階では適切に設計されていないことはわかっています。また、すべての段階で使用するシェーダーを追加して、G バッファー、L バッファー、フレームバッファーに順番に書き込みます。

C++ コード:

NVIDIA CG シェーダー:

助言がありますか？

ogre コンポジター フレームワークを使用して遅延レンダラーを設定しようとしています。以下のコードで、ポイント ライト シェーダーを実装しようとしました (フルスクリーン クワッド エフェクトとして、減衰や鏡面反射計算なし)。

遅延データを GBuffer に出力するマテリアル:

頂点プログラムの説明:

フラグメント プログラムの説明:

ライト マテリアル スクリプト:

ライト シェーダ:

これは、.cpp ファイルでライトを宣言する方法です。

私は出力を取得し、すべてが正常に機能します-照明が正しく機能しないことを除いて。G バッファには有効なデータ (ビュー空間法線、線形 Z 深度、テクスチャ) が含まれています。また、ビュー スペース内のライトの位置をパラメーターとして取得しますが、ベクトルの計算中にいくつかの問題があり、出力はポイント ライトとは異なります。ここで何が間違っていますか？

ありがとう！

PSまた、コンポジターリスナーを介して手動でlightPosパラメーターを渡そうとしましたが、ライトはディレクショナルライトのように見えました...

ページ番号をクリックしたときにデータをロードする遅延初期化 dataTable を作成したいと思います。

リクエストに応じてデータをロードするためにこのように作成しますが、テーブルは最初に空のテーブルをレンダリングし、他の番号をクリックすると、すべてのページ番号に対して 10 を超えるレコードが表示され、このキャプションも表示されます " Show 41 to Nan from NaN ( NaN 合計エントリからフィルター処理)" ページ番号をクリックすると、クリックされたページ番号に応じて 41 という数字が変化します。

編集

Json の戻り値は非常に大きいですが、そのサンプルを次に示します

texture(texture0,textCoord)一度使用してから、別のテクスチャで再度使用しようとすると、texture(texture1,textCoord);(0,0,0,0) が返されるようです。理由はわかりません。

私のプログラムでは、深度が他のものよりも機能する場合、深さを使用しない場合は色のみが機能するなど、作業の順序のようです.(深さ、色、法線、位置、輝きが順序です)

これはバインディング部分です:

これはFBOクラスの可能性があります：

編集:フラグメント シェーダーを変更して、実行ごとに 1 つのライトのみが可能になるようにすると、最初の問題が解決されました。私の2番目の問題はまだ残っています。

あなたが提供できる助けを前もって感謝します。ここ数週間、LWJGL レンダリング エンジンのディファード シェーディング パイプラインに取り組んでいます。私はすべてを期待どおりに動作させることができたと思っていましたが、プログラムを数人の知人に配布した後、問題が発生し始めました。これをできるだけ短くしようと思います。私と一緒にいてくれてありがとう。

タイトルにある 2 つの問題のうち最初のものから始めます。私のマシン (AMD Phenom II 965 および Nvidia GTX 480) では、レンダラーの最終製品はまさに期待どおりでした。(私は画像へのリンクを投稿しようとしましたが、私は新しいユーザーであるため、ハイパーリンクを 3 つ以上投稿することができませんでした。しかし、あるべきように見えたと言っても過言ではありません。)

これはまさに私が意図したことなので、レンダラーは正常に動作していました。友人（GT 440を使用していた）に送ったところ、同じ結果が得られました.

この後すぐに、ラップトップ (GT 540M を使用) を持っている友人にエンジンのビルドを渡しました。これは、レンダラーが生成したものです (FPS カウンターは無視してください。機能しません)。

http://i.imgur.com/DxxFEpy.png

明らかに、これは私が期待した結果ではありません。テストできた他のすべてのモバイル グラフィックス カードで同じ結果が得られました。1 週間以上机に頭をぶつけた後、glBlendFunc が呼び出されるライティング パスに問題を絞り込むことができました。私のコードは次のとおりです。

最初に気付くのは、クワッドを描画してから深度とカラー バッファーをクリアしていることです。それは私の次の質問で対処されるでしょうが、私の次の質問の問題がこの質問の問題と密接に関連していたとしても驚かないでしょう. 問題がこの方法にあることはほぼ確実 (99%) です。これは、1 つのライトのみをサポートし、遅延パイプラインをまだ使用しているエンジンの古いビルドでテストしたときに、テストしたすべてのコンピューターで完璧な結果を得ることができたからです。 . 繰り返しになりますが、レンダラーはテストしたすべてのデスクトップ グラフィック カードで動作しますが、ラップトップ グラフィック カードでは動作しません。この方法を除いて、ほとんどすべてを除外しました。GL_RGBA32fまたはそうでない内部フォーマットのテクスチャを使用して成功しなかったことは注目に値するかもしれませんGL_RGBA16fレンダー ターゲットとして。誰かがこれを以前に見たことがありますか、または誰かが支援を提供できますか? 私は何も持っていないので、この時点でどこから問題を探し始めるか、誰かが何か考えていれば幸いです. 私は完全に自分で解決策を見つけることができませんでした。

次に、2 番目の問題と 2 番目の質問に進みます。最後のコード ブロックの冒頭に、シェーダーなしで画面上にクワッドを作成する数行のコードがありました。

私が知る限り、このコードはまったく何もしないはずです。しかし、クワッドの描画を削除すると、ウィンドウに次のように表示されます。

http://i.imgur.com/mkMsP0F.png

これを「ゴースト」以外に何と呼べばいいのかわかりませんでした。これはゴースト イメージのようなものだからです (少なくとも、私にはそう見えます)。MV マトリックスを回転させると、回転方向に歪み、最初のライト セット (7 個のアレイを使用) がそれを照らしますが、残りは実際のモデルを照らします。なぜこれが起こるのか説明できません。なぜなら、この画像を生成するコードは上記のコードとまったく同じでありglCallList(quadList);、ループに入る直前に深度バッファとカラー バッファがまだクリアされていることを意味します。私はこの問題をまったく説明できません。何が問題なのか、それを修正する方法、または少なくとも何が問題なのかについての考えを誰かが知っていますか?

編集これは、テクスチャ座標を持つモデルでのみ発生することがわかりました。どうしてか分かりません。

編集各シェーダーで許可されるライトの量を 1 に制限すると、ゴーストが目立たなくなりますが、まだ存在するように見えます。したがって、これは、フラグメント シェーダーを 1 回実行するとこれらのゴーストが発生することを意味すると思います。

これら 2 つの問題のいずれかについて誰かが助けてくれてありがとう、それは大歓迎です。ご不明な点がございましたら、お気軽にお問い合わせください。返信に時間がかかる場合がありますが、できるだけ早く返信できるように努めます。

編集申し訳ありませんが、シェーダーコードを忘れました:GeometryPass vertex:

GeometryPass フラグメント:

LightPass フォン頂点:

LightPass フォン フラグメント

スクリーン スペース ポイントをビュー スペースに投影して照明で使用することにより、ポジション バッファの使用を回避しようとしています。逆投影行列を掛けてみましたが、これはビュー スペース ポイントを返しません。位置バッファーを回避するために行列乗算を追加する価値はありますか?

最終パス シェーダー:

数日前、ハードウェアが変更されたため、コンピューターをセットアップし、Windows 8 の新しいコピーをインストールしました。とりわけ、ビデオ カードを Radeon HD 7870 から Nvidia GTX 660 に変更しました。

Visual Studio 11 を再度セットアップした後、最後の OpenGL プロジェクトを Github からダウンロードし、プロジェクト全体を再構築しました。Visual Studio からアプリケーションを実行したところ、 が原因でクラッシュしましたnvoglv32.dll。

Application.exe の 0x5D9F74E3 (nvoglv32.dll) で未処理の例外: 0xC0000005: アクセス違反の読み取り場所 0x00000000。

古い環境では、アプリケーションは期待どおりに機能しました。プロジェクトやソース コードは何も変更していません。唯一の違いは、Visual Studio のインストールの言語が英語で、以前はドイツ語だったことです。そのため、新しいプロジェクトを作成し、すべての設定を採用しましたが、エラーが残ります。

クラッシュの場所を特定するために、すべての初期化 (ウィンドウ、シェーダーなど) が成功しglDrawElements()、遅延レンダラーのジオメトリ パスを参照するドロー コールでエラーが発生していることに気付きました。

nvoglv32.dllいくつかの調査の後、それはNvidiaからのものであり、というサービスに関するものであることがわかりましたCompatible OpenGL ICD。これは、私のアプリケーションが互換モードで実行されていることを意味しますか? それは古いアプリケーションをサポートするためのモードのように聞こえますが、私は通常モードで実行したいと思っています! ちなみに、ビデオカードには最新の安定したドライバーをインストールしました。

正直なところ、このクラッシュを修正する方法がわかりません。何が原因で、どのように修正するのですか？

更新: Geforce フォーラムで、私の問題に関する投稿を見つけました。応答はありませんでしたが、作成者は 2 つの OpenGL 呼び出しの順序を変更することで問題を解決できました。

こんにちは、みんな、

アプリケーションのソース コードを数時間調べた後、関数を呼び出していることがわかりました...

...この順序で、nvoglv64.dll でクラッシュが発生します。これらの呼び出しの順序を逆にしています...

...クラッシュを防ぎ、行儀が良いようです。

乾杯、ロバート・グラフ

私は頂点配列を使用していないため、この修正を簡単に行うことはできませんが、同様の問題が発生する可能性があります。進捗状況を報告します。

更新: 問題を解決する方法がまったくわかりません。さまざまなビデオ ドライバーのバージョンを試しましたが、違いはありません。最小限のシェーダーと単純なフォワード レンダリングを使用して、レンダラーを完全に書き直しました。しかし、クラッシュシルは最初のドローコールで発生します。

動作するGバッファ（色、法線、深度）があり、各スポットライトについて、ライトの観点からの深度マップがあります。問題はライティングマップフェーズにあり、動作させることができません。ここで何が問題なのか指摘していただけますか？

プロセスの私の「理解」は次のとおりです。

現在、多くのポイント ライトを含む大きなシーンを Unity で構築しています。シーン内の各部屋 (~40 部屋) には 2 つのポイント ライトがあり、遅延レンダリングを使用しています (光が部屋から漏れないように影を有効にするため)。

フォワード レンダリングを使用すると、私のゲームは 60 fps で実行されますが、ディファード ライティングに切り替えると、約 25 ～ 30 fps で実行されます (ポイント ライトのソフト シャドウを計算するため)。

ライトが壁から漏れるのを防ぎながら、この問題を解決するにはどうすればよいですか?

ありがとう！

私は OpenGL 3D レンダラーに取り組んでいます。Java と JOGL API を使用しています。現在、遅延レンダラーのパフォーマンスを微調整しようとしています。このために、貴重な CPU サイクルを食い尽くしているものを確認するために VisualVM プロファイラーを使用し、OpenGL 関数呼び出しを追跡するために gDEBugger も使用しています。現時点では、20 ～ 30 個のライトしか存在しない場合でも 30 FPS 未満に低下しています (また、照明が必要な実際のメッシュの数が非常に少ない場合でも)。また、シャドウ マッピングや法線マッピングなどもまだ追加していません。

これは、現時点での外観です (41 個のライトが 20 FPS のみ)。

VisualVM では、ほとんどのCPU時間がネイティブjogamp.opengl.windows.wgl.WGLUtil.SwapBuffersメソッドで費やされていることに気付きました。ただし、この情報がシェーダーの実行時間に関連しているのか、何らかの形で関連しているのかはわかりません。呼び出しの実行時間glDrawArraysはごくわずかです。これは、このメソッドが GPU に呼び出しを発行するだけであり、戻る前に呼び出しが終了するのを待たないという事実を裏付けています。アプリケーションの時間のほとんどがその関数呼び出しに費やされているのはなぜですか?

さらに奇妙なのは、3 ～ 4 個のライトがある場合、60 FPS で実行することです。その数を 20 に増やすと、数は 20FPS に低下します。1000 ～ 1100 個のライトを追加しても、約 10 FPS が得られます。何故ですか？ライトの計算は加算的であるため、ライトが 1000 の場合は、ライトが 20 の場合よりも多くのフラグメント シェーダーがピクセルごとに実行されるはずです。3 ～ 4 個のライトから 20 個のライトにジャンプすると、なぜこのようにパフォーマンスが大幅に低下するのでしょうか?

そして、私の質問のパート II: 前に言ったように、OpenGL 呼び出しのプロファイリングに gDEBugger を使い始めましたが、残念ながら、実行に最も時間がかかるものを正確に判断する方法を見つけることができないようです -どの関数が最も多く呼び出されるかに関する情報のみを取得します。冗長な状態変更などを探し出すときに役立ちますが、私がいる段階では、レンダラーの速度を低下させる大きな問題があると確信しています。

フラグメントシェーダーの実行時間を追跡し、どのフラグメントのどの計算が最も長くかかるかを正確に確認する信頼できる方法を知っている人はいますか? nVidia nSight が優れたグラフィックス デバッグ機能を提供していることは知っていますが、それらのほとんどは DirectX アプリケーションでしか利用できません。