ですから、単色のモデルにライティングを開始する必要があります。テスト アプリケーションは、最新のメソッドのみを実装するためのテスト ケースであるため、理想的にはレイ トレーシングを実装する必要があることに気付きました (理論的には、数年後にはリアルタイム グラフィックスに最適になる可能性があるため)。
しかし、どこから始めればよいのでしょうか?
古い OpenGL でライティングを行ったことがないので、推奨されていないメソッドに直接進むとします。
アプリケーションは現在、頂点バッファー オブジェクト、頂点、法線、および色の入力を適切に設定しており、モデルを空間内で単色で正しく描画および変換しています。
フラットな色の頂点から GLSL を介して適切な最終結果を得るために必要なすべての情報を取得する情報源はありますか? 理想的には、それを補完するために必要になる可能性のある他の追加の照明方法を使用します。
OpenGL で実際のレイ トレーシングを試すことはお勧めしません。そのためには多くのハックやトリックが必要であり、私に尋ねても、これを行う意味がまったくないからです。GPU でレイ トレーシングを実行する場合は、CUDA や OpenCL などの任意の GPGPU 言語を使用する必要があります。
問題をもう少し詳しく説明すると、レイトレーシングの場合、二次光線を追跡し、ジオメトリとの交差をテストする必要があります。したがって、シェーダー内で巧妙な方法でジオメトリにアクセスする必要がありますが、フラグメント シェーダー内では、ジオメトリを何らかのテクスチャに「コード化」して保存しないと、ジオメトリにアクセスできません。頂点シェーダーもこのジオメトリ情報をネイティブには提供しません。また、ジオメトリ シェーダーは隣接するシェーダーしか認識していないため、ここで問題がすでに発生しています。次に、適切なフレームレートを得るために加速データ構造が必要です。ただし、たとえばシェーダー内の Kd ツリーをトラバースすることは非常に困難であり、私の記憶が正しければ、この問題だけを取り上げた論文がいくつかあります。ただし、本当にこのルートに進みたい場合は、このトピックに関する論文がたくさんあるので、それらを見つけるのはそれほど難しくありません.
レイ トレーサーが優れたパフォーマンスを発揮するには、非常によく設計されたアクセス パターンとキャッシュが必要です。ただし、GLSL 内ではこれらをほとんど制御できず、パフォーマンスの最適化は非常に困難になる可能性があります。
もう 1 つの注意点は、少なくとも私の知る限りでは、GPU でのリアルタイム レイ トレーシングは静的シーンにほとんど限定されていることです。動的なシーンが必要な場合は、他のデータ構造 (BVH、iirc など) が必要ですが、それらを常に維持する必要があります。何も見逃していなければ、この問題だけで現在も多くの研究が進行中です。
あなたはいくつかのことを混乱させているかもしれません。
OpenGL はラスタライザーです。レイトレーシングを強制することは可能ですが、困難です。これが、レイトレーシングが「数年後のリアルタイム グラフィックスにとって理想的」ではない理由です。数年後には、ハイブリッド システムのみが実行可能になります。
したがって、3 つの可能性があります。
正確に何を達成したいですか？ニーズに応じて回答を改善できます。
とにかく、このSOの質問は非常に関連しています。この特定の実装にバグがある場合でも、それは間違いなく進むべき道です。別の可能性は openCL ですが、概念は同じです。