0

現時点では、OpenGL を使用して Deferred Rendering を実装しましたが、これはかなり単純です。ただし、現在ステンシル パスを使用しているため (少なくとも現在の使用方法では)、パフォーマンスに大きな問題があります。私は主に ogldev.atspace のチュートリアル (投稿ごとに 2 つのリンクしかありませんでした。申し訳ありません!) を他の記事からの数十の情報とともに参照として使用してきました。

次のように機能します。

  1. Gbuffer パス (ジオメトリをレンダリングし、法線、拡散、アンビエントなどを塗りつぶす)
  2. 各ライト 2a) ステンシル パス 2b) ライト パス
  3. 画面に切り替え

この方法でステンシル パスを使用すると、シーン内のすべてのライトに対してライト パス モードとステンシル モードを切り替える必要があるため、膨大なコストが発生します。つまり、多くの GL 状態のスワップです。

ステンシル パスを使用しない別の方法は次のようになります。

  1. Gbuffer フィル
  2. ライトパスを設定
  3. すべてのライトの計算
  4. 画面に切り替え

これを行うと、シーン内の各ライトのすべての 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 か月ほど前に、これに代わるものを探していましたが、私が持っていたものに対してオーバーヘッドが少し大きすぎるのではないかと考えていました。念頭に置いて。しかし、私はその時何も見つけることができず、今でも見つけることができません。

4

1 に答える 1

0

Doom3 でライティングに使用される別のテクニックは次のとおりです。

http://fabiensanglard.net/doom3/renderer.php

For each light
    render the geometry affected only by 1 light
    accumulate the light result (clamping to 255)

最適化として、各ライトのジオメトリの可視部分のみをレンダリングするように、シザー テストを追加できます。

ステンシル ライトに対するこの利点は、必要に応じて複雑なライト計算を実行したり、単純なライトを保持したりできることです。そして、全体の作業は GPU であり、冗長な状態変更はありません (1 つのシェーダーのみ、1 つの vbo のみをセットアップし、ライトとシザー テスト領域の均一なパラメーターのみを変更するたびに再描画します)。G-Bufferさえ必要ありません。

于 2015-07-12T07:44:49.917 に答える