RedBookを読んでいる間、私はかなり混乱していました。openGLはシーン内に最大8つのライトを持つことができます（実装によって数は異なりますが、約8になるはずです）。
しかし、もっと多くのライトが必要になる状況はたくさん想像できるので、ゲーム開発ではこれを回避するためのトリックがあると思います。
たとえば、50本の懐中電灯がある非常に長い通りがある場合や、20人のチームが全員懐中電灯を使用している場合があります。これらの状況を実際にどのようにシミュレートしますか？光が光源と物体の間の円錐全体ではなく、メッシュの一部だけを照らすという問題があります。したがって、100％きれいな空気がない場合は、何らかのシミュレーションも必要です。これはどのように行われ、ゲームはスムーズに実行されますか？（8つのライトすべてを有効にするとFPSが停止する可能性があることも読みました）
8 つのライトは、固定 GL パイプラインの制限であり、それぞれを有効にし、モード、パラメーターなどを設定します。これで、ピクセル シェーダーができ、ライティングはシェーダー内で行われます。そこでは、多数の動的な(テクスチャに焼き付けられていない) ライトを使用できます。これらすべてのライトのパラメータを十分に (おそらくテクスチャで) 指定し、シェーダが処理できるライトの数をテストするだけで済みます。また、シェーダーでは、弱すぎるライト (ピクセル値への寄与が少なすぎる) または遠すぎるライトをカリングすることができます。
更新: 分岐のある複雑なシェーダーは、ライトを生成することもできます (長い通りやクリスマス ツリーを考えてみてください)。多数のパラメーターを指定するよりも効率的です。
ライティングは、コンピューター グラフィックスにおいて非常に複雑なトピックです。
もちろん、実際に重要なのはオブジェクトの照明であり、現実世界の照明やターゲットとする効果をエミュレートします。照明環境は、達成しようとしている実際の効果に近づけるために、多くのソースで構成することができます。
OpenGL ライティングの実装は動的ライトです。これは、レンダリングされた頂点 (三角形のレンダリングに使用される) に「光を当てる」(つまり、色を与える) ことを可能にするライト ポイントの抽象化です。...頂点が照らされ、各ライトの色の影響を取得します。
おっしゃったように、レンダリング プロセスには、有効にしたライトが増えるほど時間がかかります。これを最小限に抑えるには、さまざまな可能性があります。
OpenGL 固定ライティングは頂点カラーに寄与し、三角形をラスタライズするために他の頂点カラーで補間されます。ジオメトリがいくつかの三角形で構成されている場合、各三角形の内側に光円錐は見えません。これは、そのフラグメントの色が 3 つの色 (3 つの頂点) の補間の結果であるためです。
より正確なライティングを実現するために、ソフトウェアは頂点がライトによって色付けされるのと同じ方法で各フラグメント (ピクセル) の色 (ピクセル ライティング) を決定しますが、理解できるように、頂点よりも多くのピクセルが存在する可能性があります。アプローチの 1 つは、(シェーダーまたは OpenGL 拡張機能を使用して) ラスター化フェーズ中にジオメトリの各ピクセルのライトの寄与を計算するか、ディファード ライティングを使用してピクセルの色を決定することです。
ディファード ライティングは、複数のテクスチャ (ビューポートに対応) を使用して、表示される各ピクセルのライト パラメータを保存します。このようにして、イメージが生成された後にライト計算を実行し、ジオメトリ ピクセルごとに 1 回ではなく、ピクセルごとに 1 回ライトの寄与を決定します。
ゲームで使用されるトリックの1つは、テクスチャを使用して光をシミュレートすることです。
したがって、街灯の例では、「照らされた」領域は実際にはより明るいテクスチャ画像になります。正しい効果を得るために、最も近いライトのみが光源になります。
半透明のテクスチャまたは透明な円錐のあるテクスチャをシーンにオーバーレイして同じ効果を与える同様のアプローチがあります。
影などをリアルタイムで計算するということは、特定の場所での光の強度を計算するために、光の観点からシーンをレンダリングする必要があることを忘れないでください。したがって、8つのライトの場合、実際にシーンをレンダリングして表示する前に、シーン（またはシーンの一部）を最大8回レンダリングします。これがCPUではなくGPUで行われたとしても、非常に高価です。