M. PharrとG. HumphreysによってPBRTを研究した後、物理ベースのパストレーサーを実装しました。今、OpenGL ESを使用して（iPhoneアプリケーションで）物理ベースのレンダリングをリアルタイムグラフィックスに適用しようとしています。
Oren-NayarとCook-Torranceを拡散反射鏡BRDFとして使い始めたいのですが、問題があります：間接照明をどのようにモデル化すればよいですか？
（pbrtに含まれるような）パストレーサーでは、直接/間接照明を考慮して光線の経路をたどるので、間接/周囲光はパストレーシングアルゴリズムから「自動的に」与えられます。
OpenGL ESで記述された物理ベースのレンダリングで間接照明をモデリングするにはどうすればよいですか？リアルタイムコンピューターグラフィックスを使用して？
回答:
リアルタイムグラフィックスはさまざまな近似を展開して、間接照明のシミュレーションの計算コストに対処し、実行時のパフォーマンスと照明の忠実度をトレードオフします。これは活発な研究分野であり、新しい技術が毎年登場しています。
範囲の最も単純な端では、アンビエント照明を使用できます。これは、実際の光源やローカルの可視性に関係なく、シーン内のすべてのオブジェクトに適用されるグローバルな全方向光源です。これはまったく正確ではありませんが、非常に安価で、アーティストが簡単に調整でき、シーンや目的の視覚スタイルに応じて大丈夫に見える場合があります。
基本的なアンビエント照明の一般的な拡張には次のものがあります。
いわば、技術が伴うの次の「レベル」、ベーキング（オフラインプリコンピューティング）シーンにおける間接照明のいくつかの表現を。ベイク処理の利点は、すべての難しい部分がベイク処理で行われるため、リアルタイムの計算コストをほとんどかけずに、非常に高品質の結果を得ることができることです。トレードオフは、焼き付けプロセスに必要な時間がレベル設計者の反復率を損なうことです。事前計算されたデータを保存するには、より多くのメモリとディスク容量が必要です。照明をリアルタイムで変更する機能は非常に限られています。また、ベイク処理では静的レベルジオメトリからの情報のみを使用できるため、キャラクターなどの動的オブジェクトからの間接照明効果は失われます。それでも、ベイクドライティングは、今日のAAAゲームで非常に広く使用されています。
ベイク処理では、パストレース、ラジオシティ、ゲームエンジン自体を使用したキューブマップ（またはヘミキューブ）のレンダリングなど、任意のレンダリングアルゴリズムを使用できます。
結果は、レベルの静的ジオメトリに適用されるテクスチャ（ライトマップ）に保存できます。また、SHに変換し、放射量ボリューム（各テクセルがSHプローブを保存するボリュームテクスチャ）などのボリュームデータ構造に保存することもできます。または四面体メッシュ。その後、シェーダーを使用して、そのデータ構造から色を検索および補間し、レンダリングされたジオメトリに適用できます。ボリュメトリックアプローチにより、ベイクドライティングを静的オブジェクトだけでなく動的オブジェクトにも適用できます。
ライトマップなどの空間解像度は、メモリやその他の実用的な制約によって制限されるため、ベイク処理されたライティングにいくつかのAOテクニックを追加して、ベイク処理されたライティングでは提供できない高周波の詳細を追加し、動的オブジェクトに応答することができます（動くキャラクターや乗り物の下で間接照明を暗くするなど）。
事前計算放射輝度転送（PRT）と呼ばれる手法もあります。これは、より動的な照明条件を処理するためにベイク処理を拡張します。PRTでは、間接照明自体をベイク処理する代わりに、ある光源（通常は空）からシーン内の間接照明に伝達関数をベイク処理します。伝達関数は、各ベイクサンプルポイントでソースからデスティネーションのSH係数に変換する行列として表されます。これにより、照明環境を変更でき、シーン内の間接照明がもっともらしい反応を示します。Far Cry 3および4は、この手法を使用して、昼夜の連続サイクルを可能にし、間接照明は1日の各時間の空の色に基づいて変化します。
ベイク処理についてのもう1つのポイント：拡散反射光と鏡面反射光に別々のベイク処理データがあると便利です。キューブマップは、鏡面反射光に対してSHよりもはるかに機能します（キューブマップはより多くの角度の詳細を持つことができるため）が、より多くのメモリを消費するため、SHサンプルほど密に配置する余裕はありません。視差補正を使用すると、キューブマップをヒューリスティックにワープして、その反射が周囲のジオメトリによりしっかりと固定されているように感じさせることで、それをいくらか補うことができます。
最後に、GPUで完全に動的な間接照明を計算することができます。照明またはジオメトリの任意の変更にリアルタイムで応答できます。ただし、実行時のパフォーマンス、照明の忠実度、シーンサイズの間にはトレードオフがあります。これらの手法の中には、機能するために強力なGPUを必要とするものがあり、限られたシーンサイズでのみ実現可能です。また、通常、間接光の単一バウンスのみをサポートします。
これらのテクニックのほとんどは、現実的なシーンサイズへのスケールアップの問題やその他の制限のため、今日のゲームでは広く使用されていません。例外はスクリーンスペースリフレクションであり、これは非常に人気があります（通常、スクリーンスペース部分が失敗する領域のフォールバックとしてキューブマップで使用されます）。
ご覧のとおり、リアルタイムの間接照明は大きなトピックであり、この（かなり長い！）答えでさえ、10,000フィートの概要と詳細なコンテキストを提供するだけです。どのアプローチが最適であるかは、特定のアプリケーションの詳細、どのような制約を受け入れたいか、どのくらいの時間をかける必要があるかに大きく依存します。
これは、リアルタイムCGに残っている主要な「難しい」問題であり、それを解決するための多くの研究が進行中です。
最大のハードルは、ラスターグラフィックスでは、シーンの各コンポーネントが「真空」でレンダリングされることです。各三角形は、シーン内の他の三角形を参照せずにレンダリングされ、レイトレーシングアプローチとは対照的にピクセルでも同じです。各レイはメモリ内のシーン全体にアクセスできます。そのため、リアルタイムプログラマーは、反射や影などの処理を行うために、ハッキングトリックを使用する必要があり、同じことがグローバルイルミネーションにも当てはまります。
安価なランタイムメソッドは、ベイクドライトマップを使用することです。この場合、ラジオシティやパストレーシングなどの低速だが素晴らしいものを最初に実行し、次に通常の頂点データとともに照明情報を保存します。これは静的ジオメトリには最適ですが、移動オブジェクトを追加するとすぐに問題になります。Michal Iwanickiは、「The Last of Us」でこれをどのように解決したかについて良いプレゼンテーションを行いました。
球面調和関数は、間接光を表すためにゲームエンジンで多く使用されます。これらは基本的に球体の表面を横断するフーリエ変換であり、高周波成分を破棄することで、視覚的に心地よく、色ごとにわずか9つの係数で正確な環境照明を得ることができます。たとえば、UnityはSHを使用してシーンのさまざまなポイントで「ライトプローブ」をベイク処理し、移動するオブジェクトが近くのプローブ間を補間して、その位置の間接光の近似値を取得します。ロビン・グリーンの論文は基本的にこのテクニックのバイブルですが、かなり重いです。
現時点でのホットなテクニックは、ボクセルコーントレーシングのようです。これには、プリベークステップは含まれません。私はあまり慣れていませんが、理解しているように、シーンを低解像度のMinecraftスタイルの世界にボクセル化し、ボクセルを八分木のような素早く通過可能な空間構造に配置してから、いくつかのワイド各ポイントからの光線（コーン）と、どのボクセルがヒットしたかをチェックして、バウンス照明を収集します。NVidiaは現在これをかなり強く推し進めており、こことここに論文があります。
それが役立つことを願っています:)
パストレースは非常に計算量の多いアルゴリズムであり、リアルタイムには適していません。PBRTのアーキテクチャはリアルタイムにも適していません。PBRTの主な目標は、不偏モンテカルロ統合を使用してレンダリング方程式を解くことです。詳細については、https：//en.wikipedia.org/wiki/Unbiased_renderingを参照してください。
多くの最適化と制約がなければ、モバイルデバイスで適切なパフォーマンスを達成できるとは思えません。
いずれにしても、パストレースはOpenGLで実装できます。非常に強力な計算シェーダーを検討することをお勧めします。OpenGL ES 3.1は、Desktop GLとは対照的に、いくつかの小さな制限のある計算シェーダーをサポートします。
詳細については、このページをご覧ください：https : //github.com/LWJGL/lwjgl3-wiki/wiki/2.6.1.-Ray-tracing-with-OpenGL-Compute-Shaders-(Part-I）
幸運を祈ります！