GLSL、1つまたは多くのシェーダープログラムですべてですか?


17

OpenGLを使用して3Dデモを行っていますが、GLSLが多少「制限されている」ことに気づきました(または、私だけですか?)。とにかく、私は多くの異なる種類の資料を持っています。一部のマテリアルにはアンビエントカラーと拡散カラーがあり、一部のマテリアルにはアンビエントオクルージョンマップがあり、一部にはスペキュラマップとバンプマップがあります。

1つの頂点/フラグメントシェーダーペアですべてをサポートする方が良いでしょうか、それとも多くの頂点/フラグメントシェーダーを作成し、現在選択されているマテリアルに基づいて選択する方が良いでしょうか?OpenGLまたはD3Dの通常のシェーダー戦略とは何ですか?



これは誤った二分法であり、シェーダーを管理するためのいずれかのアプローチを選択する必要があります。業界での15年間、私はどちらの極端にも固執したプロジェクトに取り組んだことはありませんでしたが、シェーダーを管理する2つのアプローチのバランスを常に取りました。
トレバーパウエル

回答:


12

答えは、それはちょっと依存します。

基本的に2つの考え方があります。あらゆるものと超シェーダーキャンプに最適な小型のシェーダー。

小さなシェーダーはまさにそれです。一つだけ、そしてそれをうまくやる。Uberシェーダーは、ユニフォームを使用して実行時に機能を制御するか、プリプロセッサマクロ(および/または生成されたシェーダーソース)を使用して、さまざまなシェーダーにコンパイルします。

最適なソリューションはおそらくどちらでもありませんが、何らかのハイブリッドです。場合によっては、いくつかのuber-shadersまたはuber-shadersを特殊なシェーダーと組み合わせることもあります。

小さなシェーダー

長所:

  • より高速/より最適である可能性が高い
  • あなたがやりたいことだけをする
  • 変な、カスタムのものを簡単に行うことができます

短所:

  • 特に機能の数が増えた場合、簡単に手に負えなくなる
  • シェーダーの数が非常に少ない場合を除き、おそらくより多くの作業

ユーバーシェーダー

長所:

  • 一箇所ですべて
  • よりアーティストに優しい(機能Aと機能Xを初めて使用する場合、必ずしもコーダー時間を必要としません)

短所:

  • より長いシェーダーのコンパイル時間
  • 最適でない結果(特に、ユニフォームを使用して機能のオン/オフを切り替える場合)
  • デバッグ/最適化がより困難になる場合があります

Uber-shaderこの表現では良いことではありません:)事前定義に基づいて適切なシェーダーマネージャーを作成することを提案します。したがって#ifdef、さまざまなマテリアルでトグルされる多くのsを持つuber-shaderコードを作成します。
-brigadir

2
ユーバーシェーダーのもう1つの長所は、シェーダーを切り替えるとパフォーマンスの点でコストがかかることです。したがって、切り替えの頻度が低い場合は、パフォーマンスを改善できる可能性があります。
ジェリコ
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.