問題タブ [deferred-rendering]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
opengl - ディファード シェーディング - 複数のライト (OpenGL/GLSL)
私はディファード シェーディング プログラムに取り組んでおり、シーンに 50 の異なるライトを設定する必要があります。そのために、次のコードを使用して属性 (位置、拡散色、反射色) をランダムに生成しています。
ただし、複数のライトでライティングを実行する方法がよくわかりません。アンビエント ライトはディフューズ ライトと等しくなければならず、スペキュラー ライトは白であるべきだと言われました。
Phong Ilumination を実行するために必要だったシェーダーを適応させると、次のようになります。
ただし、次の図に示すように、(間違っていない場合でも) 醜い結果が得られます。
この結果は 2 つのライトのみを使用しています。50を使わないといけないので、真っ白な画面ばかりだと思いますが…
opengl - z = 0 および距離で SSAO が正しくない
それでSSAOを実装しようとしましたが、意図したとおりに機能していません。位置 z=0 (ワールド空間) で分割されているように見えます。位置 z=0 に白い線があります。また、オクルージョンが正しく見えません。
さらに距離が離れているため、カメラを移動すると、オクルージョンがさらに奇妙になります
ジオメトリをレンダリングするためのマイ シェーダー (インスタンス化):
バーテックス:
断片:
ジオメトリ パスの後、SSAO パスを法線情報と深度情報とともに適用します。
これは私のNoiseTextureです:
ハードウェアの深度バッファを使用します。ワールド空間ですべてを計算します。
フラグメント シェーダーは次のとおりです。
opengl - OpenGL と GLSL を使用したステンシル バッファーと遅延レンダリング
遅延レンダリング コンテキストでのステンシル バッファの使用に関して 1 つ疑問に思っているのは、スクリーン スペース上のすべてのフラグメント シェーダが「オクルード」領域内で使用されているかということです。
Web サイトhttp://www.learnopengl.com/#!Advanced-OpenGL/Stencil-testingの例を次に示します(ステンシル バッファーのトピックのみで、遅延レンダリングとは関係ありません)。
質問: ここで「他は捨てる」という表現は何を意味していますか? これは、マスク サンプラーで値が 0 の場合、ピクセル シェーダーが呼び出されないことを意味します。または、画面上の各フラグメントに対してピクセル シェーダーが呼び出されますが、値が 0 の場合、ピクセルの塗りつぶしを破棄する条件が適用されます。
左の最初の画像が、ステンシル バッファリングなしの結果であるとします。情報のサポートは、2 つの三角形で構成されるクワッドです (遅延レンダリング手法を適用するため、画面空間で作業しています。画面の寸法は 500x500 です)。そのため、ラスタライズ後、500 * 500 のフラグメント シェーダーが呼び出されてフレーム バッファーが満たされ、光のない暗い領域でもそれらのすべてが使用されます。これは、ブリンフォン シェーディング モデルを適用すると、この最後のモデルが画面のどこにでも適用され、暗い領域でも適用されることを意味し、パフォーマンスの無駄だと思います。
したがって、この場合に行う論理的なことは、マスクを作成し (ステンシル バッファーを使用するか、他のフレーム バッファーを使用してマスクを塗りつぶす外部カスタム マスク レンダー パスを使用して)、最後に blinn-phong シェーディング モデルのみを使用することです。ここで、スクリーン スペースのマスク サンプラーのピクセルの値は 1 です。このようにして、フォン シェーディング モデルは、この例でのみ 2 つのボックスとプレーンに適用されます。
最初のアプローチでジョブを正しく行うための秘訣は、フラグメント シェーダーに条件を追加して、現在のフラグメントのブリンフォン シェーディングを計算する必要があるかどうかを、サンプリングされたマスク テクスチャの値に従って判断することです。
しかし、(上の 3 番目の図を見ると) 色付きの領域のみに関係するフラグメント シェーダーを呼び出すように OpenGL API に指示できるかどうか疑問に思っています! (つまり、フラグメント シェーダーのメインには入らないということです)。この場合、使用されるフラグメント シェーダーの数が大幅に削減され、パフォーマンスが向上します。または、上記のようにフラグメント シェーダーに条件を入れることが唯一の解決策ですか?
c++ - それらは Stencil Pass の代わりになるか
現時点では、OpenGL を使用して Deferred Rendering を実装しましたが、これはかなり単純です。ただし、現在ステンシル パスを使用しているため (少なくとも現在の使用方法では)、パフォーマンスに大きな問題があります。私は主に ogldev.atspace のチュートリアル (投稿ごとに 2 つのリンクしかありませんでした。申し訳ありません!) を他の記事からの数十の情報とともに参照として使用してきました。
次のように機能します。
- Gbuffer パス (ジオメトリをレンダリングし、法線、拡散、アンビエントなどを塗りつぶす)
- 各ライト 2a) ステンシル パス 2b) ライト パス
- 画面に切り替え
この方法でステンシル パスを使用すると、シーン内のすべてのライトに対してライト パス モードとステンシル モードを切り替える必要があるため、膨大なコストが発生します。つまり、多くの GL 状態のスワップです。
ステンシル パスを使用しない別の方法は次のようになります。
- Gbuffer フィル
- ライトパスを設定
- すべてのライトの計算
- 画面に切り替え
これを行うと、シーン内の各ライトのすべての OpenGL 状態 (およびバッファーのクリアなど) を交換する必要がなくなります。
CodeXL と基本的な fps の std::cout'ng を使用して、これをテスト/プロファイリングしました。ステンシル パス メソッドを使用する状態変更関数は、私の GL 呼び出しの 44% を占めます (描画の場合は 6%、テクスチャの場合は 6% と比較して)、バッファ スワップ/クリアなどのコストもかなりの % 高くなります。2 番目の方法に行くと、GL 状態の変化は 2.98% に低下し、他の方法も同様にかなりのマージンを低下させます。FPS も大幅に変化します。たとえば、シーンに 65 個のライトがあり、動的に移動します。リリース モードで運が良ければ、ステンシル パスは約 20 ~ 30 fps を提供します (合計時間の大半をレンダリングに費やします)。2 番目の方法では 71~ になります (レンダリングにかかる時間は合計時間よりも短くなります)。
では、なぜ 2 番目の方法を使用しないのでしょうか。まあ、それは私が最初に得られない深刻な照明の問題を引き起こします. それらを取り除く方法がわかりません。次に例を示します。
2 番目の非ステンシル バージョン (基本的にブリードし、その範囲外のものにオーバーラップします): http://imgur.com/BNn9SP2
最初のステンシル バージョン (どのように見えるか): http://imgur.com/kVGRwH2
私の主な質問は、タイル化された遅延レンダリングのようなものにアルゴリズムを完全に変更せずに、ステンシル パスの使用を回避する方法 (およびグラフィック グリッチなしで最初のものと同様のものを使用する方法) があるかどうかです。
そうでない場合、それらは代替の遅延レンダリング方法ですか?それは、私が使用している遅延レンダラーのスタイルからあまりジャンプしていませんか?
ステンシル パスを取り除くことは、私にとって新しい問題ではありません。最初に実装した 6 か月ほど前に、これに代わるものを探していましたが、私が持っていたものに対してオーバーヘッドが少し大きすぎるのではないかと考えていました。念頭に置いて。しかし、私はその時何も見つけることができず、今でも見つけることができません。
jquery - 遅延レンダリングでソート可能なjQuery
私は jQuery プラグイン (Scroller 拡張機能を備えた DataTable) を使用してtable
おり、遅延レンダリングのおかげで HTML を数千行表示できます。
私はそれを作りたいですsortable
(ソート可能なjQuery-UIプラグインで)。
問題は、要素をドラッグしてはるか下にドロップしたい場合、最初nodes
のテーブルが DOM から消え、新しいテーブルが表示されることです。そのため、ドラッグした要素をドロップできなくなりました。
例は長いテキストよりも優れています: http://jsfiddle.net/91dr6utg/
最初の要素をドラッグすると、90 番目の要素の後にドロップできません。
詳しくは :
start
ドラッグした線が消えるのを防ぐ機能をしました。実際、元の要素がnode
DOM から削除されると、sortable
プラグインはその要素を削除できなくなります (要素を認識できなくなります)。そのため、更新されないDOMの別のコンテナに移動します。
node
この関数を削除すると、オリジナルが約 50 行下に削除されることがわかります
=> これは DOM の再生成によるものですが
、要素を 90 行下まで削除することができます
=> 次の行がDOM、限界だ
c++ - 遅延レンダリング: レンダー ターゲットをシェーダー リソース ビューとしてシェーダーに渡す際の問題
私は遅延レンダリング/シェーディングを初めて実装しています。自分で解決するのに苦労しているいくつかの問題に遭遇しました:/。
ジオメトリ パスと遅延パスを一緒にレンダリングすると、この奇妙に見える出力が得られます
トポロジ、入力レイアウトなどを設定する前に、遅延パスの最初に緑色のクリア カラーを使用しています。これが緑色の由来です。ただし、出力画像が半分に分割される理由はわかりません。
ただし、私の主な問題は、レンダー ターゲットをジオメトリ パスからシェーダー リソース ビューとして遅延シェーダーに正常に渡すことです。これは私のジオメトリ シェーダーの結果です
それで、私が見た出力画像から判断すると、正しい空間への変換を管理していますか?
ジオメトリ パスで、レンダー ターゲットを設定しました
遅延パスでは、それらをシェーダー リソース ビューとして設定しました
私の遅延シェーダーでは、それらを登録します
そしてそれらをサンプリングする
ジオメトリ パスが与えたのとまったく同じ出力を得るには、次のように記述します。
しかし、私が得たのは、投稿した黒と緑の分割画像だけです。これをデバッグするために、float3 サンプルの要素の 1 つが 0.0f で、すべての要素が 0.0f の場合に色を返す if ステートメントをいくつか入れました。gbuffer レンダー ターゲットをシェーダー リソース ビューとして本当に正しく設定していますか?
私の理解では、gbuffer に ID3D11ShaderResourceView* と ID3D11RenderTargetView* が含まれ、両方を作成するために使用される ID3D11Texture2D* がD3D11_BIND_RENDER_TARGET | D3D11_BIND_SHADER_RESOURCEバインド フラグは、レンダー ターゲット ビューが使用されると、そのコンテンツが gbuffer シェーダー リソース ビューに自動的に「コピー」され、後でシェーダーの入力として使用できるようになります。
私を訂正したり、この件に関する私の視野を広げたりしてください。私の問題に関する提案はありますか?ありがとうございました!
opengl - マルチサンプル テクスチャが地平線にアーティファクトを生成する
遅延レンダリングを実装し、マルチサンプル テクスチャをアンチ エイリアシングに使用しようとしています。
マルチサンプル テクスチャを使用してシーンを FBO にレンダリングし、glBlit を使用して 2 番目の FBO で通常のテクスチャを作成し、最終的にテクスチャを照明シェーダーにバインドして、最終的な画像を生成します。
これにより、地平線 (ジオメトリとスカイボックスの間) に目に見える線が生成されます。カラーはクリアカラーです。深さをクリアするだけで、移動時の問題が軽減されます。ジオメトリをレンダリングする前に SkyBox を FBO にレンダリングすると、目に見えるアーティファクトは少なくなりますが、線はまだ残っています。
opengl - 後続のテクスチャの読み取りと書き込みに関する問題
私のレンダリング パイプライン (OpenGL 3.3 コア) には、次のサイクル (疑似コード) があります。
のときn=1
は、すべて OK です。ただし、 の場合n=2
、最初のレンダリングが正しくありません。
のサンプリングが完了する前にrender to texture T
への書き込みを開始したと思われます。T
render to back buffer
T
サイクルの終わりに置くglFlush()
と、レンダリングは正しくなりますが、FPS は少し低下します。インターネットのいたるところで、「glFlush() を使用する必要がある場合は、おそらく何か間違ったことをしている可能性があります」を見つけ続けています。
問題を正しく特定しましたか? glFlush()
この場合、正しい解決策はありますか? 反復ごとに異なるテクスチャを使用すること (私は知っていますn
) がより良い解決策でしょうか?
GTX580 では発生しますが、ATI Mobility Radeon 3470 では発生しません。
私のコンテキスト - 詳細:
2 つのライトと G バッファー (FBO) があります。各反復で、1 つのライトとそのシャドウ マップ (T
すべてのライトに対して相互にテクスチャを持つ別の FBO)を使用してディファード シェーディングを実行していn
ます。中render to back buffer
に光を蓄えます。
次の画像では、光を蓄積しませんでした。代わりに、最初の反復を左側のビューポートにレンダリングし、2 番目の反復を右側のビューポートにレンダリングして、問題を示しました。