OpenGL ES 2.0で遅延レンダリング/シェーディングは可能ですか？

StackOverflowでこれを尋ねましたが、ここではもっと意味があるかもしれません：

OpenGL ES 2.0で遅延レンダリング/シェーディングを実装している人はいますか？MRTをサポートしていないため、1つのカラーバッファーだけでは、「通常の」方法で実装できるものではありません。

具体的には、iPad、iPhone4（maaaybe iPhone 3gs）、およびAndroidで調査しています。iPad / iPhone4 / iPhone3gsのGLESViewアプリにはGL_OES_RGB8_RGBA8拡張が存在し、まだ深く見ていませんが、8ビット/チャネルでは、このアイデアは興味深いです：http ://www.gamedev.net/topic/ 562138-opengl-es-20-and-deferred-shading /

他のアイデアはありますか？パフォーマンス面でも、やりがいがありますか？

はい、可能です。ただし、特に価値はありません。

まず、NV_draw_buffers拡張機能にアクセスできない限り（名前が示すとおり、NVIDIA専用です。Tegraで実行しているのでなければ、それはありません）、ES 2.0のフレームバッファーオブジェクトは1つの画像にしかレンダリングできません。一度に。したがって、Gバッファを生成するには、シーンを複数回レンダリングする必要があります。そのため、遅延レンダリングの利点の1つを奪います。

第二に、モバイルプラットフォームの帯域幅は、ミッドグレードGPUで得られる帯域幅と同じではありません。また、帯域幅は、（多くのライトの）遅延レンダリングを価値のあるものにするために重要です。その帯域幅がなければ、光の通過はパフォーマンスの面で実際に傷つきます。

第三に、PowerVRハードウェアは、この種のことを目的として設計されていません。タイルベースのレンダリングハードウェアでレンダリングを最適化します。そのため、その上での遅延レンダリングは、従来のスキャン変換アーキテクチャよりも有用性が低くなります。

主な問題はFillrateです。モバイルGPUでは、フィルレートが低く、ネイティブ解像度ではリアルタイムで遅延シェーディングを実行できません。

iPhone 4とiPad 1では、塗りつぶしはばかげています。良好なフィルレートを備えた唯一のデバイスIOSはiPad 2ですが、十分ではないと思います... Androidでは、MRTを使用するGL_NV_draw_buffersを持っているのはTegraデバイスのみですが、フィルレートも非常に低くなっています。Mali 400には最高の充填率があるようです。泣きたい場合は、フルスクリーン解像度で色の長方形を4回塗りつぶしてみてください。多くのデバイスでは60 fpsで実行できません。

デスクトップGPUでは、モバイルGPUとして10倍（またはそれ以上）のフィルレートがあります。モバイルGPUはCPUと同じメモリを使用し、専用メモリがないことを忘れないでください。

WebGL（同じAPI）にはいくつかの例があるため、これはAPIの制限ではありません。

実際、遅延レンダラーに必要な絶対最小値を考慮する必要があります。遅延照明にフォールバックすると、GBufferに保存する必要のあるデータの量が減ります。実際には、シーンの半分を3回以上レンダリングして低光量をサポートするよりもはるかに安価です。

私は次のGBufferフォーマットに行きます：

• 照明パスに深度バッファーを再利用します。これがモバイルデバイスでどの程度サポートされているかはわかりませんが、無料の深度テクスチャーです。
• 単一のGBufferテクスチャ、その中に保存します：Normal U、Normal V、Param 0、Param1。Lambert-Azimuthalエンコーディングは、法線には本当に見栄えがよく、2つのコンポーネントに圧縮します。
• 照明変数の2つのパラメーターは非常に多く、ハードウェアが動的分岐で適切に機能する場合、1つを複数の照明機能の列挙として使用できます。

遅延ライティングは、シーンを2回レンダリングすることを除いて、遅延レンダリングと似ています。

1. ジオメトリの深さ、法線、照明パラメータをGBufferにレンダリングします。
2. ライトをアキュムレーションバッファにレンダーします。
3. マテリアルシェーダーでジオメトリをレンダリングし、ここでも照明を合成します。照明方程式の逆演算子をうまく処理することができれば、このステップで非常にクールなことができます。
4. 余裕のある後処理を行います。効率を上げるために、ここで深度と通常のテクスチャを乱用してください。

照明結果の保存について。拡散バッファーと鏡面輝度を保存するのが好きになったので、蓄積バッファーは標準の32ビットカラーテクスチャのみで十分です。拡散色の彩度を計算し、それを鏡面輝度と組み合わせることにより、鏡面色を推定できます。

ただし、最も重要な部分は、深度ステンシルバッファーを最大限に使用することです。必要のない照明コードをレンダリングしないようにしてください。デバイスの表示可能範囲（通常は1e-3が安全なカットオフ）を下回る光の可視性を低下させる条件で、一部の廃棄ステートメントをフラグメントシェーダーに追加することさえします。

据え置き照明を検討してください。簡単に言えば、遅延照明は、スクリーンシェードライトマップを計算するために遅延シェーディングの縮小バージョンを使用する手法です。2番目のパスでは、スクリーンスペースライトマップを照明情報として使用して、ジオメトリが再度レンダリングされます。

この手法は、必要な属性が少ないため、Gバッファーのサイズを小さくするために使用されます。また、G-Bufferとスクリーンスペースライトマップの解像度が画面よりも低くなるという利点もあります。

私は厳密なGLES 2.0ベースのレンダラー（実験的なものではありますが）を実装し、G-Bufferを1つのRGBAテクスチャにまとめることができました（はい、レンダーバッファーの代わりにtexture2Dを使用しました）。画面スペースの法線マップ+アルファチャネル内の深度バッファー（これまで覚えていた限り、対数を使用して圧縮されていました）が含まれていました。

位置属性（ここではワールドと呼ばれます）は、透視投影では.xyが.zによって提供されるという事実を使用して、ライティングパス中に計算できます。

以下を実行して、位置属性のxyを近似しました。

注：投影マトリックスの設定に応じて、さらに調整する必要がありました。

また、注目に値するのは、法線ベクトルの.zコンポーネントを省略することができたことです。これは、法線ベクトルが次のように正規化されているため、.xyから.zを再構築できるためです。

この手法を使用して、RGBA G-Buffer内の別のチャネルを解放し、これを使用して画面スペースのスペキュラーマップ（または、必要に応じて光沢）を保存しました。

はい、絶対に可能です。モバイルグラフィックチップは非常に高解像度の画面を処理するように設計されているため、充填率はそれほど問題ではありません。実際、ライティングの計算はシーンの複雑さから独立しているため、遅延レンダリングはこれに役立ちます。したがって、オーバードローはスローダウンを引き起こしません。以下は、第4世代iPadでの実装です。http： //www.youtube.com/watch？v = K4X1oF6b4V8

4倍のパフォーマンスが必要な場合は、レンダリングするテクスチャの解像度の半分だけにします。とにかく、網膜スクリーンでの3Dグラフィックスの違いはほとんどありません。

モバイルグラフィックチップは、レンダリングからテクスチャへの処理方法が優れているため、遅延レンダリングに非常に適しています。通常、ウィンドウコンテキストの代わりにテクスチャへのレンダリングを開始すると大きなパフォーマンスヒットが発生するPCグラフィックカードとは異なり、モバイルグラフィックはパフォーマンスヒットなしでこれを行うように設計されています。したがって、デスクトップグラフィックスカードで最初に発生するパフォーマンスの低下なしに、遅延レンダラーのスケーラビリティを得ることができます。

実装の時点では、OpenGLESには複数のターゲットへのレンダリングがなかったため、画面の色と法線を別々のパスで描画する必要がありました。これはOpenGLESの最近のバージョンで修正される可能性がありますが、ソリューションがコンシューマーモバイルハードウェアでまだ利用可能かどうかわかりません。