JP2012503259A - レイトレーシングシェーダａｐｉのためのシステム及び方法 - Google Patents

Abstract

態様は、レイトレーシング機能を提供する他のコンポーネント及び／又はコードモジュールとシェーダをインターフェイス接続するためのＡＰＩインターフェイスを含む。例えば、ＡＰＩコールにより、識別済みの画素のためのバッファに光エネルギーを直接与えることができるようになり、単独で又は束で交差テストを行うための新たな光線を発光できるようになる。このＡＰＩは、発光コールを使用して、シェーダを通じてテストされる光線を定義する光線定義データに任意のデータを関連付けるためのメカニズムを提供することもできる。この任意のデータが、光線により交差されたものとして後から識別されたオブジェクトに関連するシェーダに提供される。このデータは、シェーダが使用することができる、又はシェーダ後に実行することができるコード、又はコードへのポインタを含むことができる。一連のシェーダを通じてこのデータを伝播することもでき、個々のシェーダ内でインスタンス化された光線にこのデータを関連付けることもできる。
【選択図】 図１２

Description

〔関連出願との相互参照〕
本出願は、２００８年９月２２日に出願された「非再帰的レイトレーシング(ray tracing)のためのシェーダ(shader)ＡＰＩ」という名称の米国仮特許出願第６１／０９９，１５２号、２００８年１０月１日に出願された同じく「非再帰的レイトレーシングのためのシェーダＡＰＩ」という名称の米国仮特許出願第６１／１０１，８５４号、及び２００９年４月２４日に出願された「非再帰的レイトレーシングのためのシェーダＡＰＩ」という名称の米国仮特許出願第６１／１７２，４５３号、及び２００９年６月２４日に出願された「レイトレーシングレンダリングのための光線を定義するシステム及び方法」という名称の米国仮特許出願第６１／２１９，８７０号からの優先権を主張するものであり、上記出願は全てその全体が引用により本明細書に組み入れられる。

以下の発明は、一般にレイトレーシングを使用して３−Ｄシーン(scene)の２−Ｄ表現をレンダリングすることに関し、より詳細には、このようなレイトレーシングのためのソフトウェアコンポーネントのプログラミングの態様及び使用方法に関する。

コンピュータグラフィクス技術では、レイトレーシングを使用して３−Ｄシーン記述からフォトリアリスティックな２−Ｄ画像をレンダリングすることが周知である。通常、レイトレーシングでは、シーン内の構造の表面を記述する、プリミティブ(primitive)と呼ぶことができる幾何学的形状で構成されたシーン記述を取得する。共通するプリミティブ形状は三角形である。

仮想光線を視点（「カメラ」）からシーン内へ追跡し、個々の光線は２−Ｄ表現のそれぞれの画素を通過するように発光され、この２−Ｄ表現に影響を与えることができる。光線をシーンプリミティブとの交差に関してテストして、個々の光線が交差したプリミティブがあれば、その最初のプリミティブを識別する。

所与の光線の交差を識別した後、そのプリミティブに関連するシェーダが、次に行うことを決定する。例えば、プリミティブが鏡の一部である場合、反射光線が発光されて光が照明器具から交差ポイントに当たっているかどうかを、或いはより複雑な状況では表面下反射を判定し、散乱をモデル化することにより、異なる光線の発光が交差テストされるようにすることができる。さらなる例によれば、オブジェクトの表面が粗く滑らかでない場合、このオブジェクトのシェーダが光線を発光して、その表面上の乱反射をモデル化することができる。このように、そのプリミティブにどの光が当たっているかをさらに特定する必要があるので、光線とプリミティブの交差を発見することは、所与の光線によって光エネルギーが画素に到達できるかどうか、及びどのような種類の光エネルギーが到達できるかを特定する上での１つのステップである。

従って、大半の従来のアルゴリズムでは、シーンをレイトレーシングする際に飛行中の光線のツリーを構築し、このツリーは、シーンを離れるまで、或いは新たな光線を発光しない照明器具にぶつかるまで個々のブランチ(branch)に沿って継続する。次に、発光オブジェクト（「照明器具」）にぶつかるこれらのブランチに関して、プリミティブ交差を介してブランチをロールアップし、個々のプリミティブ交差が、これらのプリミティブ交差に当たる光にどのような影響を与えるかを経路に沿って特定する。最終的に、最初に発光されたカメラ光線の光の色及び強度を特定してバッファに記憶することができる。

このレイトレーシング法は再帰的レイトレーシングと呼ばれ、長い間最も多く実施されてきた。この動作は説明が単純なため魅力的であり、すなわちテストする光線をプリミティブ交差に応じて再帰的に発光することによりツリーが増える一方でこれらを識別し、その後結果を上向きにフィードバックすることによりツリーが閉じられる（「ロールアップされる」）。

しかしながら、様々な理由により再帰的レイトレーシングには問題があり得る。例えば、光線の未完了のブランチに依存している個々の光線の状態が記憶されるので、ツリーの終点を識別している間に大量の光線状態を保持しなければならない。また、下流の結果を待っているときに、通常、完了できない大量のシェーダの状態がスタックに記憶される。光線が順番に追跡され、例えば子光線は親光線と同時には追跡されないので、このようなことになる。以下、このような光線の状態を記憶する必要がない非再帰的レイトレーシング法、及びプログラマ及びその他の開発者が、このような方法を実施するシステム及びソフトウェアとのインターフェイスをとるためのシステム、方法、及びコードについて説明する。

いくつかの態様は、シェーダコードモジュールを書き込むことができるとともに、シェーダコードモジュールが実行されている間に、これらのシェーダコードモジュールが規定のプログラミングセマンティックを介して出力に影響を与えることができるようにするプログラミングインターフェイスを提供することに関する。１つの好ましい例では、プログラミングセマンティックが、交差テストを受ける１又はそれ以上の光線を決定するデータ、及びコードへのポインタ、コード、画素の関連性、色ベクトル、バッファ位置識別子などのその他のデータを受け入れる光線発光コールを含む。このプログラミングセマンティックは、寄与コールを通じてバッファ位置への寄与も可能にする。実行中のシェーダモジュールは、これらのコールの何らかの組み合わせを作成した後で実行を完了し、このシェーダが使用していた状態を解放することができる。

例えば、コンピュータ実行可能シェーダコードとのインターフェイスをとる方法は、親光線の定義データ、及びオブジェクトで構成された３−Ｄシーンからレンダリングされる２−Ｄ画像の画素と親光線の関連性を、光線発光コールを介して受け入れるステップを含む。シェーダは、親光線の交差テストの結果に基づいて選択される。方法はまた、実行中に発光コールを介して選択されたシェーダからの１又はそれ以上の子光線を受け入れるステップと、子光線の各々との画素関連性を継続するステップとを含む。この方法はまた、子光線の少なくともいくつかに関する取得した交差テストの結果に基づいて１又はそれ以上のシェーダを選択するステップと、実行中に子光線のために選択されたシェーダの１又はそれ以上から、コントリビュートコールを介して画素のバッファに（単複の）寄与を直接受け入れるステップとを含む。バッファへの（単複の）寄与は、親光線のためのシェーダに再入力することなく受け入れることができる。

いくつかの実施構成では、コントリビュートコールが、画素のバッファ以外の指定されたバッファ位置への寄与のリダイレクションを受け入れることもできる。このリダイレクションはコードによって指定することができ、コントリビュートコールを介して提供することができ、或いはコントリビュートコールを介して提供されるポインタにより参照することができる。

別の態様は、シーン内で光線を追跡するためのシステムを含み、このシステムは、シーン内の交差に関して光線をテストする光線交差テストリソースと、シェーディング結果を蓄積するためのバッファとを含む。システムはまた、プログラミングインターフェイスを実現するためのコードを記憶するコンピュータ可読媒体も含む。このプログラミングインターフェイスは、シェーダが交差テストを受ける光線を指定するために使用する光線発光コールと、シェーダをバッファにインターフェイス接続するためのコントリビュートコールとを含む。バッファのインターフェイス接続は、シェーダ実行中に、バッファ内の１又はそれ以上の位置に直接寄与される結果を表すデータを受け入れることにより行うことができる。システムは、光線交差テストリソースから受け取った交差テストの結果に応答して、実行するシェーダをシステムが選択するようにするためのシェーダ実行環境を含むことができる。シェーダは、交差テストの結果内に与えられるプリミティブ識別子を使用して選択することができ、或いは交差されたプリミティブ（又は表面）が存在しない場合にはデフォルトシェーダを選択することができる。デフォルトシェーダは、シーン全体のデフォルトシェーダであってもよく、或いは交差テストの結果に関連する光線のタイプに基づいて選択してもよい。光線には、光線タイプ情報及び（他の光線への参照、コード、及び実行するコードへのポインタなどの）その他のデータを光線発光コールを介して関連付けることができる。

別の態様はシェーディングインターフェイス方法を含み、この方法は、３−Ｄシーン内で交差テストを受ける光線の起点及び方向を含むデータを第１のシェーダから受け入れるステップを含む。この方法はまた、光線に関連付けるための追加データを第１のシェーダから受け入れるステップと、この追加データを、光線を交差テストした結果に基づいて識別される第２のシェーダに通信するステップとを含む。光線を交差テストした結果は、光線により交差されたプリミティブの識別情報を含むことができ、これを第２のシェーダに関連付けることができる。第２のシェーダのためのコードがこの追加データを解釈して、第２のシェーダによって発光、反射又は屈折された光に関して第２のシェーダの挙動を修正することができる。第２のシェーダは、第２のシェーダに対して閉じた状態にあるバッファ位置に直接書き込みを行うことができる。

別の態様では、レイトレーシング法が、オブジェクトで構成された３−Ｄシーン内で交差テストするための第１の光線を定義するステップと、この第１の光線をバッファ位置に関連付けるステップとを含む。この方法はまた、シーン内の交差に関して第１の光線をテストして、（１）最も近いオブジェクト交差、又は（２）交差が存在しないことのいずれかを判定するステップも含む。方法は、（１）が判定されたか、又は（２）が判定されたかに応じて第１の光線の状態を閉じるステップを含む。（１）が判定された場合、オブジェクト交差に基づいて特定された第１のシェーダを実行することにより状態が閉じられる。第１のシェーダは、子光線の交差テストを引き起こすための第１のプログラミングセマンティック、及びバッファ位置に対して直接データ寄与を引き起こす、シェーダ実行中に使用するための第２のプログラミングセマンティックのうちの１又はそれ以上を使用するようにプログラムされる。

上記の方法例では、（２）が判定された場合、デフォルトシェーダを実行することにより状態を閉じることができる。デフォルトシェーダは、シーン全体のデフォルトシェーダ情報から決定することができる。デフォルトシェーダはまた、第１の光線に関連する光線タイプデータに基づいて決定することもでき、この光線タイプデータを、列挙された光線タイプの組として、それぞれのデフォルトシェーダをこれらの列挙された光線タイプの各々に関連付けることができる。

第１のプログラミングセマンティックを通じて任意のデータを受け入れ、オブジェクト交差に基づいて識別される第２のシェーダに提供することもできる。いくつかの例では、交差されたオブジェクトに第２のシェーダを関連付けることができる。実行のために任意のデータが選択された場合、これをデフォルトシェーダに提供することもできる。

より具体的な例では、最も近いオブジェクト交差が照明器具である場合、閉じるステップが、第２のプログラミングセマンティックを介してバッファ位置に色データを提供するステップを含むことができる。バッファ位置に提供される値は、光線に関連する色ベクトルにより、及び照明器具から発光された光の色に基づいて決定することができる。シェーダが光線発光セマンティック（上記の第１のプログラミングセマンティック）を使用することにより、第１の光線からの複数の子光線間で色ベクトルを分割することもできる。

別の態様では、レイトレーシングで使用するためのシステムがシェーダ実行環境を含み、この環境は、シェーダの実行中にこれらにインターフェイスを提供するためのコンピュータ実行可能命令で構成された計算リソースを含む。このインターフェイスは、交差テストを受ける１又はそれ以上の光線のそれぞれの起点及び方向、及びこの起点及び方向情報に加えて１又はそれ以上のデータ要素を指定するためにシェーダが使用する光線発光コールを含む。システムはまた、シェーダ実行環境にインターフェイス接続された、起点及び方向情報と１又はそれ以上のデータ要素とを受け取って記憶するためのメモリリソースも含む。シェーダ実行環境は、交差テストリソースの出力にインターフェイス接続されて、交差テストを完了した光線の交差テスト結果を示し、個々の光線交差指示のシェーディングを処理するためのそれぞれのシェーダモジュールを識別するように構成される。

シェーダ実行環境は、シェーダの実行中にこれらのシェーダが利用できるようになった寄与コールを介して画素色の寄与を受け入れるようにさらに構成できるとともに、この受け入れられた画素の寄与をバッファ内の識別済みの位置の１又はそれ以上に記憶するための複数の位置を含むバッファとさらにインターフェイス接続することができる。

さらなる態様は、再帰的シェーダコードを非再帰的シェーダコードに変換する方法を含む。この方法は、再帰的シェーダのためのコード内で、１又はそれ以上の効果を実現するための１又はそれ以上の標準パターンを記述するコードを識別するステップを含む。この方法はまた、この識別した標準パターンを、１又はそれ以上の同等の効果を得るようにまとめて実行される１又はそれ以上の非再帰的シェーダコードパターンにマップすることにより、非再帰的シェーダを生成するステップも含む。

再帰的シェーダの標準パターンはトレースレイ関数コールを含むことができ、このコールは、交差テストを受ける光線を定義し、このコールのために１又はそれ以上のダウンストリームシェーダが呼び出され、ダウンストリームシェーダの完了時に再帰的シェーダが戻された色値を受け取る。再帰的シェーダはまた、受け取った色に対して演算を行うためのコードと、出力色を戻して再帰的シェーダを完了させるためのコードとを含むことができる。

このような標準パターンのマッピングは、トレースレイ関数コールを、非再帰的シェーダに値を戻さずに光線の処理を終わらせる状態に関連する新たな光線を発光する光線発光コールと、非再帰的シェーダが指定されたバッファ位置に色を提供できるようにする寄与コールとにマッピングするステップを含むことができる。

別の態様は、プロセッサを構成するためのコンピュータ実行可能命令を記憶する有形のコンピュータ可読媒体を含み、この媒体は、効果を実現するために光線シェーダが書き込みを行うことができるシェーダランタイム環境を実現するためのコンピュータ実行可能命令と、３−Ｄシーン内で交差テストを受ける光線をランタイム環境に受け入れさせる光線発光コールを提供するランタイム環境と、３−Ｄシーンの表現の少なくとも１つの要素の色を決定する際に使用するデータを含む、バッファ位置に提供されるデータをランタイム環境に受け入れさせる寄与コールとを含む。

さらなる態様は、各々がｎ＞＝３の最大ｎ個の変数の値により定義される複数の要素を含むデータセットを記憶するメモリを含むクエリ−リゾルバシステムに関する。このシステムはまた、パラメータにより定義されるクエリを受け入れるためのクエリ発行インターフェイスをあらわにするシステムインターフェイスと、バッファに書き込まれる結果を実行コードモジュールから受け入れるためのソリューションコントリビュートインターフェイスとを含む。システムはまた、メモリにアクセスして、クエリにより定義されたパラメータを満たす要素の１又はそれ以上を検索することによりクエリを解決し、パラメータを満たす少なくとも１つの要素を見つけると、クエリを提供されるデータの１又はそれ以上及びこの要素に関連するデータに基づいて選択された１又はそれ以上の実行可能コードモジュールを実行し、解決されるさらなるクエリの１又はそれ以上を実行コードモジュールの１又はそれ以上からクエリ発行インターフェイスを介して、及びバッファに書き込まれる結果をソリューションコントリビュートインタフェースを介して受け入れるためのシステムインターフェイスを使用するためのプログラムコードで構成されたプロセッサを含む。

さらなる態様は、コンピュータ可読命令と、複数のコードモジュールを含むデータと、実行するコードモジュールを選択する方法を実施するためのコンピュータ実行可能コードとを記憶して、これらを実行するための入力を提供する有形のコンピュータ可読媒体を含む。この方法は、複数の入力を含むデータベースにクエリを使用して問い合わせるステップを含む。複数のパラメータのそれぞれの値により、コードモジュールの少なくとも１つに関連する入力の各々を指定することができる。個々のクエリは、仕様を満たすパラメータの各々の値のそれぞれの範囲に分解できる仕様と、このクエリ仕様に加えて、１又はそれ以上の識別対象コードモジュールによる入力として受け取られる少なくとも１つの追加データ項目とを含む。この方法は、クエリの仕様を満たすデータベースの１又はそれ以上の入力に個々のクエリを分解するステップも含む。この方法はまた、これらの１又はそれ以上の入力に関連する１又はそれ以上のコードモジュールをこのクエリに関して識別するステップと、少なくとも１つの追加データ項目を、これらの１又はそれ以上のコードモジュールへの入力としてこのクエリから提供するステップとを含む。

より一般的には、いくつかの態様は、コードモジュールを実行のためにスケジューリングすること、及びこのようなコードモジュールにより実行されるデータを、実行を行う処理リソースと同じ場所に配置することに関する。１つの例では、全てが入力を受け入れて出力を生成することができる複数のコードモジュールでアプリケーションを構成することができる。このアプリケーションは、複数の要素を含むデータセットを記憶するメモリへのアクセスとともに実行される。タスクを行うために、このアプリケーションは、データセットを検索してクエリを満たす１又はそれ以上の要素を識別するために使用される、指定されたパラメータを含むクエリを発行する（クエリを満たす要素が存在しない場合もあるが、この可能性については別途検討する）。識別された要素とクエリのペアリングにより、コードモジュールのうちの選択された１又はそれ以上が実行されるようになる。この選択は、クエリ自体とともに実行するためのコードを提供することにより、及び／又は要素との所定の関連性により行われる。（単複の）コードモジュールの実行中、この（単複の）コードモジュールは、ランタイム環境を通じて提供されるプログラミングインターフェイスを使用して、さらなるクエリを発行し、結果バッファに寄与することができる。これらの外部（コードモジュール自体の外部）から見える変更を実施すると、コードモジュールが完成することができる。

一方で、マルチスレッド環境が、通常いくつかの関数を呼び出すことができるコードモジュールを実行するスレッドを有し、このコードモジュールを実行するスレッドが、関数コールが完了するのを十分に待ってから値を戻す。このような環境では、コードモジュールが呼び出す全ての関数が完了して戻った後に、このコードモジュールにより最終結果が戻されて処理が終了する。一方、現行の態様では、所与のコードモジュールが開始したいくつかのクエリ又はさらなる処理が未だ完了していなくても、このコードモジュールが完了してその状態を上書きできるようにすることができる。

いずれの方法の態様も、１又はそれ以上の媒体に記憶されたコンピュータ実行可能コードにより具体化することができる。さらに、特に定めがない限り、このようなコードを実行するためのいずれかのプロセッサ又はその他のリソースを、複数の独立したコンピュータユニット、マルチスレッドコア、ＦＰＧＡ、ＡＳＩＣＳ、特殊用途及び汎用コンピュータの組み合わせ、及びチップ上のシステムで構成することができる。

本明細書に開示する態様を説明するために使用する、レイトレーシングを使用してレンダリングできるシーンを示す図である。 背景技術による再帰的レイトレーシングの実施構成のメモリ状態の態様を示す図である。 背景技術による再帰的レイトレーシングの実施構成のメモリ状態のさらなる態様を示す図である。 非再帰的レイトレーシングの実施構成におけるシェーダと他のリソースとの通信のためのプログラミングセマンティックを実施するシステムを示す図である。 図４のシステムで使用できる、光線を定義するデータ構造を示す図である。 非再帰的レイトレーシングのシェーディング態様に関するメモリ状態を示す図である。 非再帰的レイトレーシングのシェーディング態様に関するメモリ状態を示す図である。 非再帰的レイトレーシングのシェーディング態様に関するメモリ状態を示す図である。 非再帰的レイトレーシングのシェーディング態様に関するメモリ状態を示す図である。 非再帰的レイトレーシングにおけるシェーダの挙動に関する方法例を示す図である。 図４のシステム及び／又はその一部の実現において使用できるシステムの構成要素を示す図である。 説明する態様を利用できるレンダリングフローを示す図である。 自動変換処理を通じて再帰的シェーディングコードを非再帰的シェーディングコードにマップする態様を示す図である。 自動変換処理を通じて再帰的シェーディングコードを非再帰的シェーディングコードにマップする態様を示す図である。 シーン構築処理中に提出された追加データ要素をシェーダ間で受け渡すための光線データ構造を決定することに関する態様を示す図である。 光線束ＡＰＩコールを使用できるシステムアーキテクチャを示す図である。 非再帰的レイトレーシングを提供して、本明細書における例によるＡＰＩコールを使用するシステムにおいて、いかにしてシェーダ状態を維持できるかの例を示す図である。 図１６の例の間のメモリ状態の構築を示す図である。 図１６の例の間のメモリ状態のビルドを示す図である。 図１６の例の間のメモリ状態のビルドを示す図である。 図１６の例の間のメモリ状態のビルドを示す図である。 図１６の例の間のメモリ状態のビルドを示す図である。

以下は、主に３−Ｄシーンの２−Ｄ表現をレンダリングするためのメカニズムとしてレイトレーシングを使用することに関する。多くの場合、レンダリングされる３−Ｄシーンは、ビデオゲーム、動画ピクチャ、アニメ広告、産業モデル、建物などの建築上の特徴などのコンテンツの設計を行うアーティストにより作成（指定）される。アーティストは、人物、或いはオーサリングツールを使用する人物とすることができ、或いはアーティスト自体を主にソフトウェアによって動かすことさえもできる。３−Ｄシーンを記述するコンテンツを作成するために、アーティストはいくつかの問題に取り組む。一例を挙げると、アーティストは、シーンの物理的境界（表面）及びシーン内のオブジェクトを記述する。このような物理的境界の記述は詳細にわたり得る。例えば、コンピュータ支援設計（ＣＡＤ）を使用して設計される便利な車の模型には、車の構成部品の正確な仕様及びこれらの互いの空間的関係が必要である。

アーティストはまた、シーンオブジェクトの表面がどのように見え、どのように動くはずであるかも記述する。例えば、正確な車の模型では、ウィンドウガラスは、ヘッドライトガラスや塗装面とは異なるように表現される。例えば、ビデオゲームでは、アーティストは、肌の表面を髪の表面とは異なるようにモデル化し、他もまた同様である。

従って、レンダリングの分野で利用される１つの構成概念は、物理的なシーンモデルを提供し、このシーンモデルの様々な部分に表面情報を関連付けることである。例えば、シーンモデルが、人物、自動車、及び建物などのオブジェクトを含むことがある。シーンの物理的モデルでは、これらのオブジェクトの表面が、例えば、表面の境界を表すために互いに相互接続された数多くのプリミティブ形状を含むことができるワイヤフレームモデルとして表される。一般に、この物理的モデルには、オブジェクトの表面の外観に関する情報が欠如している。そこで、特定の表面及び／又は特定の表面の一部に、これらの外観を表す情報及びプログラミングが関連付けられる。このような情報が表面の質感を含むことができる一方で、表面に関連するプログラミングは、表面に当たる光に対してこの表面がどのような効果を与えるかをモデル化することを目的とすることが多い。例えば、プログラミングにより、ガラス、光沢のある表面、でこぼこの表面などをモデル化できるようになる。従って、このようなプログラミング及び情報は、これらの表面を記述する物理的モデルの部分に結びつけられ、或いは別様に関連付けられる。例えば、プログラミングを特定のプリミティブに関連付け、或いは結びつけることができる。特定のプリミティブ又はシーンオブジェクトに関するこのようなプログラミング及びその他の記述、或いはこれらの一部を、一般にそのプリミティブ又はオブジェクトの「シェーダ」と呼ぶことができる。

３−Ｄモデリング及びこのようなモデルの２−Ｄ表現を作成することは複雑な努力である。一般に、アーティストは、レンダリングサイクルの最終生産物の方をより大切にし、むしろその生産物への到達に関与する技術を抽象化する。従って、レンダリングの技術的ニュアンスの一部を抽象化するのに役立ちながらも、アーティストの望む効果及び結果を達成できるようにして、アーティストの表現を可能にするのに必要なインターフェイスを提供することが望ましい。

このような抽象化を促進できる１つの方法は、物理的シーンモデルを表すデータをアーティストがレンダラーにアップロードできるようにするとともに、シェーダがこのモデルの特定の部分に関連付けられるようにするアプリケーションプログラミングインターフェイス（ＡＰＩ）を備えることである。この結果、レンダラーがこのデータをコンパイルし、シーンモデル及びシェーダに基づいて出力の生成に着手することができる。

一般に、レンダラーは、アーティストが指定する２−Ｄ表現の個々の画素の色を（シーン設定中に）決定し、これらの画素をレンダリング生成物として出力する。異なるレンダラーが、異なる方法でこれらの画素色を決定することができる。

ラスタ化では、まずレンダラーが視程解析を行って、個々のシーンオブジェクト上の単一ポイント、又はレンダリング出力における個々の２−Ｄシーン画素のシーン背景を決定する。次に、この単一ポイントのシェーダが実行されて、スクリーン画素を何色にすべきかを決定する。一方、レイトレーシングは、２−Ｄスクリーンの画素を通じて光線を発光することにより動作し、これらの光線がシーンオブジェクトに当たった場合、これらのオブジェクトに関連するシェーダが、シーン内で交差テストを受けるさらに多くの光線を発行することを含む様々な動作を行うことができる。個々のこのような光線がさらなるオブジェクトと交差してさらなるシェーダを実行させ、以下同様に続く。

従って、以下の開示は、アーティスト（一般的にはシーンデータのソース）と、アーティストが提供するシーン記述（物理的モデル及びシェーダ）に基づきレイトレーシングを使用してレンダリングを行うように構成された計算リソースの一群との間に（ＡＰＩなどの）インターフェイスを提供することに関する。

さらに、この開示は、非再帰的レイトレーシングレンダラーとともに使用するためのＡＰＩを提供することに関する。シーンジオメトリ及びシェーダをアップロードするためのメカニズムを提供することに加え、以下で説明するように、ＡＰＩにより定義されたコールを使用するようにシェーダ自体をプログラム又は指定することができる。非再帰的レイトレーシングレンダラーのためのＡＰＩの態様をより良く説明するために、まず図１〜図３を示して、再帰的レイトレーシングレンダラーのためのＡＰＩが一般にどのように機能するかを説明する。

上述したように、再帰的レイトレーシングアルゴリズムは、カメラ光線から最終的には（単複の）光源に当たる１又はそれ以上の光線までの光線のツリーのレベルの状態を維持する。次に、この光源の影響がこのツリーを遡って伝播され、ツリーの最上位のカメラ光線がトラバースした画素の色に対するこの光源の寄与が特定される。同様に、最終的には光源に当たる最初のカメラ光線に関するその他の光線が存在する場合、これらのその他の光線のそれぞれの寄与も、画素色のツリーのそれぞれのブランチを上に伝播していく。

図１は、第１のミラー１１０、第２のミラー１１５、及び光１２０を含む玩具のシーン例１００を示している。カメラ１０５が、テスト用の光線１３０をシーン内へ送る。光線１３０は、画素で構成された、シーン１００からレンダリングされる２−Ｄ画像平面１７５を通過する。光線１３０には、画像平面１７５の画素が関連付けられる（例えば、光線１３０が平面１７５の画素の１つを通過したときにこれを見ることができる）。光線１３０は、ミラー１１０に交差した（すなわち、シーン内の光線１３０とオブジェクトの最も近い交差がミラー１１０との交差である）と判定されるまで、シーンを構成するオブジェクトとの交差をテストされる。

ミラー１１０は、ミラー１１０の挙動を記述するシェーダに関連付けられる。このようなシェーダは、挙動を実施／記述するように実行される一群のコンピュータ命令とすることができる。例えば、単純なミラーは、スネルの法則に従ってミラーに当たる全ての光を反射し、このような挙動をシェーダが記述することができる。トレーシングは、逆というよりはむしろカメラから光へ向けて行われるので、ミラー様の挙動を生み出すには、別の光線を発光して、どの光が光線１３０のミラー１１０上への入射方向により決定される反射角で交差ポイントに当たっているかを特定することが必要になる。従って、ミラーのためのシェーダは、必要時に実行される命令及びアクセスされる関連データを使用して、この物理的挙動をモデル化する。

再帰的レイトレーシングスキームでは、シェーダは、最終的に色値を戻す「トレースレイ」関数コールを呼び出すことにより光線の発光を引き起こすことができる。アルゴリズムが再帰的であるため、トレースレイ関数への他の後からのコールが完了するまで特定の関数のコールの色値が満たされず、これによりツリーを遡って供給される次の色値などを決定するためにデータを利用できるようになる。以下の表１は、再帰的レイトレーシングにおけるミラーシェーダ（すなわち、ミラー表面を有するオブジェクトのためのシェーダ）のためのいくつかの疑似コードを示している。表２は、表１のミラーシェーダとともに使用できる照明器具のためのいくつかの疑似コードを示している。表１におけるトレースレイへのコールは、オブジェクトの交差を識別するための演算を行うコードを参照したものであり、最終的には、オブジェクトに関連する（ミラーシェーダなどの）シェーダが実行される（又は「呼び出される」）ようになる。

従って、この例では、光線１３１が生成され、最も近い交差（ここでは、ミラー１１５との）を判定するまで交差テストされるようになる。次に、ミラー１１５のためのシェーダが呼び出される（ミラー１１０のためのコードと同じシェーダコードであってもよい）。シェーダ１１５は光線１３２を発光し、交差テストを行った場合、これが光１２０と交差したと判定される。

光１２０は、それ自体をシェーダに関連付けることができる。例えば、以下の表２は、光のためのシェーダの簡単な例を示している。この例では、シェーダが、シェーダ（すなわち、光エネルギーの照明器具モデルを生成するためのシェーダであり、この効果は、テストされる光線をインスタンス化する光線の発光とは逆にレイトレーシングを使用して判定される）により発光された光の色を戻す。本開示の一部では、シェーダプログラムがオブジェクトの発光率をモデル化する概念のことを発光すると称しており、シェーダは物理的な発光をモデル化できるものの、このような動詞類が物理的な発光を示すものではないことを理解されたい。

図２は、図１の状況例を追跡するための再帰的スキームのメモリ状態例を示している。図２は、プログラム状態を示す１列目及びデータのための２列目が、プログラム状態の個々の部分により戻されることを示している。「メイン」プログラム、又は何らかの同等物は、テストされる光線１３０を発光する。この「メイン」プログラムは、レイトレーシングの結果として生じる色情報が寄与できる画素を追跡することができ、また最終画素値が決定される前のブレンディング及びフィルタリングなどの様々なその他の操作を行うことができる。光線１３０が発光されたときにはこのような色情報を利用できないので、しばしば状態が後入れ先出しの待ち行列（多くの場合スタックと呼ばれる）内に保持される。矢印２０５は、光線１３０の交差テストにより（ミラー１１０の）ミラーシェーダインスタンス１がインスタンス化され、ミラーシェーダインスタンス１が光線１３１のテストを必要とすることを示しており、これにより、矢印２０６で示すように、ミラーシェーダインスタンス２がインスタンス化されるようになる。ミラーシェーダインスタンス１及び２は、両方とも色値を待ち続けたままである。最後に、矢印２０７で示すように、光線１３２のトレーシングにより光シェーダインスタンス１がインスタンス化され、この結果光の色を戻すことができる。

図３は、未解決のシェーダインスタンスのチェーンをどのように閉じることができるかを示している。矢印３２７は、光シェーダインスタンス１からの色がミラーシェーダインスタンス２に提供され、ミラーシェーダインスタンス２が、この色を使用してミラーシェーダインスタンス１に戻す色（矢印３２６）を決定することができ、さらにミラーシェーダインスタンス１が、この色を使用してメインプログラムに戻す（矢印３２５）色を決定することができ、メインプログラムが、戻された色を使用して画素色を決定できることを示している。個々のシェーダは、それぞれの色値を戻した後に完了することができる。

従って、一般に、このパラダイムのためのプログラミングは、色を戻すレイトレーシング関数を再帰的に呼び出し、この関数に再帰的に入る度に、この関数のインスタンスの状態が維持される。色が戻されると、最初のカメラ光線の色が決定されるまで関数の状態をロールアップすることができる。従って、プログラマは、シェーダからの再帰的トレースレイ関数コールを可能にすることにより、一連の光線が閉じ始めるまでこのようなシステムとやりとりする。

この再帰的レイシェーディングＡＰＩアプローチの説明の観点から、非再帰的レンダリングＡＰＩの態様をより簡単に説明することができる。

図４は、以下の説明に基づく非再帰的レイトレーシング機能を提供するシステム例４００を示している。システム４００は、交差テストリソース４０２と、レンダリングされる２−Ｄシーン表現の色情報を記憶するための２−Ｄシーンバッファ４５０とを含む。システム４００は複数のシェーダ４１０ａ〜４１０ｎも含み、シェーダ４１０ａ〜４１０ｎの１又はそれ以上のいずれかの選択をシェーディングリソース４０４内で実行することができる。シェーディング４０４及び交差テストリソース４０２は、識別済みの関数を実行するハードウェア及びソフトウェアのいずれの組み合わせであってもよく、例えばマルチスレッドプロセッサのスレッド又は複数のプロセッサなどで実行されるコードを含むことができる。

交差テストリソース４０２は、交差テストされる光線を記述するデータ４０５、２−Ｄ表現にレンダリングされる３−Ｄシーンを構成するプリミティブを記述するデータ４０３、及びこのような交差テストの加速化を促進できる加速化構造にアクセスする。シェーディング４０４はまた、（通常、加速化構造へのアクセスを必要としない）プリミティブストレージ４０３にもアクセスすることができ、レイシェーディングをサポートするためのテクスチャデータなどのデータ及びコードを記憶できるレイシェーディングデータ４０７、及び様々な種類の物理的効果をモデル化するアルゴリズムなどの、様々なシェーダが使用できるアルゴリズムにアクセスする。シェーディング４０４は、交差テスト４０２から光線／プリミティブ交差の指示を受け取ることができる。

シェーディング４０４（すなわち、シェーダ４１０ａ〜４１０ｎのいずれか）は、２−Ｄシーンバッファ４５０と通信し、また以下で説明するような、シェーダ４１０ａ〜４１０ｎが書き込まれるプログラミングセマンティック４６０を通じて交差テスト４０２へ通信する。

システム４００は、図５に示すようなデータ構造により定義される光線を使用して動作することができる。図５は、光線識別子５０５と、一例として光線起点５０６及び光線方向５０７、減衰ベクトル５０８、画素５０９、及び以下で説明するようないくつかの理由により含むことができ、様々な方法で解釈できる追加データ５１０のためのフィールドを含む光線定義データとを含む光線データ構造５００を示している。

再帰的レイトレーシングと非再帰的レイトレーシングとのいくつかの違いを示すために、図１のシーンを追跡するためのメモリ状態の例を図６〜図９に示し、図２〜図３と対比している。（視点からシーン内へと追跡すべき光線を発光するコードなどの）カメラシェーダが、光線起点５０６、方向５０７、初期化された減衰ベクトル５０８を含む、２−Ｄ表現の特定の画素５０９に関連するカメラ光線１３０（図１）を発光し、追加データフィールド５１０を満たすことができる。光線１３０の発生後、カメラシェーダは完了することができる。レイトレーシングはミラー１１０の識別に進み、ミラーシェーダのインスタンス１が設定され、（図４の交差テスト４０２とシェーディング４０４との接続などにより）画素５０９、減衰ベクトル５０８、及び存在する場合には追加データ５１０がインスタンス１に渡される。ミラーシェーダのインスタンス１は、光線がミラーに交差した重心座標、及び／又は起点５０６及び方向５０７などのその他の光線情報を受け取ることもできる。この説明による態様では、減衰ベクトルは必要な成分ではないが、例示のために使用している。

ミラーシェーダインスタンス１は、交差テストされる反射光線（光線１３１）をそれぞれの起点及び方向で作成することができる。反射光線は、入射光線（光線１３０）からの画素、及び入射光線（光線１３０）の減衰ベクトルに基づく減衰ベクトル、及び入射光線を提供されるいずれかの追加データ５１０にも関連付けられる。反射光線を生成した後、インスタンス１は完了したと見なされて終了することができる。

光線１３１がミラー１１５との交差をテストされ、次にミラーシェーダのインスタンス２が、光線１３１から減衰ベクトル、画素及び追加データを受け取り、修正した減衰ベクトルを生成して、テストに適した起点及び方向の反射光線（光線１３２）を生成することができる。ミラーシェーダのインスタンス２は、光線１３２を生成した後に終了することができる。光線１３２が交差テストされ、光１２０が交差されたと識別される。光シェーダがインスタンス化され、光線１３２から、画素、減衰ベクトル、及び（もしあれば）追加データを受け取る。光シェーダは、光１２０の質、光１２０に提供される減衰ベクトル、及び存在する場合には追加データに基づいて、画素に与える光エネルギーを決定する。光シェーダは、この光エネルギーをシーンバッファ４５０に直接与える。

このような非再帰的レイトレーシングで使用される減衰ベクトルは、図２及び図３に関して説明したように、閉じている間に戻された実際の色値を修正するのではなく、個々のシェーダが画素にもたらすあらゆる寄与を減衰ベクトル内で「外向き」方向に反射できるようにする。次に、光シェーダは、中間シェーダの効果、及びバッファ４５０に与える光エネルギーを決定するための独自のコードを含む受け取った減衰ベクトルを、以前にインスタンス化された全てのシェーダ間で光エネルギーを転送することなく使用することができる。

減衰ベクトルはまた、光線に関連する画素にこの光線の重要度を関連付けることもできる。例えば、この説明によるフレームシェーダ（例えば、画像平面から３−Ｄシーン内に光線を発光するためのカメラとしても動作するシェーダ）が１０個の光線を発光する場合（図１２を参照）、これらの光線は、この画素の光エネルギーの１０分の１が光線の各々から到来できることを表すように初期化された独自の減衰ベクトルを各々有することができる。或いは、光線のいくつかに、これらのそれぞれの減衰ベクトルによってより大きな相対的重みを割り当てることができ、すなわちこれらの光線が最終的な画素色に強く影響を与えるようにすることができる。シェーダは、このような重要度を使用又は決定／設定することに関する動作をシェーディング中に実施することができる。

上記の例は、様々な方法で単純化したものである。例えば、シェーダは、様々な理由で実行中に減衰ベクトルを修正することができる。例えば、特定の光の波長を他のオブジェクトよりも多く減衰する特性をオブジェクトに割り当てて、例えばオブジェクトが単純に色を有し、すなわち特定の光の周波数を吸収するようにすることができる。一方、完全なミラーは減衰ベクトルを修正する必要はなく、すなわち受け取った全ての光を完全に反射する。

別の単純化は、個々のシェーダが交差テストのための光線を発光する（ミラー）か、又は光エネルギーを与える（光）かのいずれかである。しかしながら、シェーダによっては、新たな光線を発すること、及び光エネルギーを与えることの両方を行えるものもある。例えば、オブジェクトは光を放つとともに、他のソースからの光を反射することもできる。

これらの例に基づくプログラミングインターフェイスの使用について説明する別の方法は、プログラミングインターフェイスに書き込まれたシェーダが、シェーダの実行中にこのプログラミングインターフェイスへの（発光及びコントリビュートコールなどの）コールを行うことができるということである。一方で、通常のシェーダの結果はシェーダ完了後に伝播される。さらなる説明として、再帰的シェーダでは、バックグラウンドのプロセスが、既に完了しているシェーダを呼び出したシェーダに完了したシェーダから値を伝達することはできるが、この説明の目的では、バックグラウンドのプロセスは、完了したシェーダの実行中にこの値を伝達しない。一方、これらの開示によるプログラミングセマンティックは、（シェーダ完了後に他のバックグラウンドのプロセスも実行されている場合でも）シェーダ実行中にいつでも出力を生じるように呼び出すことができる１又はそれ以上のプロセスを実施することができる。

ここで図４を参照すると、プログラミングセマンティック４６０は、新しい光線の発光に使用する第１のコールと、識別済みの画素のためのバッファ４５０に光エネルギーを与えるための第２のコールを提供する。このような第１のコールの例を以下の表３で使用して示しており、ここでは「光線発光」が光線の定義を受け入れ、この光線が交差テストされるようにする。これらの説明では、このような交差テストが、光線により交差されたプリミティブを判定するためのあらゆる手段に従うことができ、多くのこのような手段が存在する。上述したように、このシェーダのインスタンスは、光線が発光された後に完了することができる。

プログラミングセマンティック４６０の第２コールの例を表４に示しており、この表は、光１２０のためのシェーダのコード例を示すものである。ここでは、シェーダが、光と交差した入力光線（「ｉｎｐｕｔ_ｒａｙ」）を受け取る。シェーダは、入力光線からの減衰ベクトルに基づいて、及び様々な光の特性のいずれか、並びに存在する場合には追加データ（図５の５１０）に基づいて、及び望むように寄与を決定する。次に、シェーダは、「寄与色」の色を使用して、画素及び寄与を提供することができる。他の例では、例えば、この特定のシェーダと画素の関係を維持する他のコード又は状態が存在する場合、画素を暗示することができる。

この開示によるＡＰＩで提供できるさらなるコールは、少なくとも１つの特性又は類似性を全てが共有する光線束の放射を可能にするコールである。便宜上、このようなコールを「ＥｍｉｔＲａｙＢｕｎｄｌｅ」と名付けることができ、このコールは、個々の光線の起点及び方向を定義するデータ又は個々の光線の起点及び方向を取得できるデータ、束になった光線間で共有される属性を定義するデータ、個々の光線に一意の属性を定義するデータ、並びに光線ごとに共有される又は一意のパラメータを受け入れることができる。

例えば、ＥｍｉｔＲａｙＢｕｎｄｌｅコールは、束になった個々の光線に属する重み係数（「重み」）を受け入れることができる。１つの例では、この重みを、ＥｍｉｔＲａｙＢｕｎｄｌｅコールを実施するコンピュータコードにより（例えば、単純な分割により）、束の光線間で分割される数として表すことができる。他の例では、個々の光線を修正することなく重みの属性が決定される。

いくつかの実施構成では、光線に特定の最重要パラメータ／属性が提供されない限り、ＥｍｉｔＲａｙＢｕｎｄｌｅコールが、束の個々の光線に属するいくつかのデフォルトパラメータ及び／又は属性の仕様を可能にすることができる。例えば、ある実施構成では、１０個の光線の束の共通の起点、１０個の別の方向、及び各々に適用される（０．１などの）重みを受け入れることができる。この実施構成では、重みをさらに受け入れて、特定の光線の重みを無効にするための処理リソースを構成するためのプログラミングを提供することができる。例えば、個々の光線の起点後に重みを提供することができ、何も提供されなかった場合、この光線にデフォルトの重みが適用される。

ＥｍｉｔＲａｙＢｕｎｄｌｅコールを使用してレンダラーに（例えばシェーダから）提出された光線束を処理し、バンドルがどのように指定されたかに基づいて、これらの光線に関するデータをメモリに記憶することができる。例えば、束の光線を定義する別個の起点及び方向データをメモリに記憶し、光線のために共有される属性、パラメータ、減衰ベクトル、及び／又は重みを一旦記憶して、束になった全ての光線のために参照することができる。束の光線が起点又は方向を共有する場合、この共有される定義の態様を、束の光線間で共有されるデータによりメモリ内で表すことができる。

いくつかの光線が、同じ束の他の光線とは異なる重み又はその他のパラメータを有する場合、レンダラーが、これらの光線のデータを記憶する際に、及び／又は交差が識別されたことに応じて個々の光線をシェーディングする際に、これらの例外的な光線を独立して、或いはこれらが束の形で指定されていないかのように処理することができる。例えば、束の中の他の光線を共有パラメータ情報とともに記憶できる場合でも、このような光線の全てのパラメータを光線の定義データのためのメモリスペース内に別個に複製することができる。

上述した発光コールと同様に、ＥｍｉｔＲａｙＢｕｎｄｌｅコールも、（この場合も、所望の場合には共通パラメータ／例外アプローチを使用して）この束の光線に対していずれかの任意の追加データを指定できるようにする。この追加データは、シェーダに関連するプリミティブに交差する束の光線に基づいて識別される将来のシェーダに提供することができる。この将来のシェーダは、自己の処理において追加データを使用することができ、或いはこの追加データに基づいて自己の挙動を別様に修正することができる。

このように、第１のシェーダがプログラミングセマンティック４６０を使用して追加データを光線に関連付け（及び、この例では、光線を発光させるためのコールがこのような追加データを受け入れることができる）、その後１又はそれ以上の他のシェーダがこの追加データを受け取ることができることをいくつかの箇所で上述した。個々のシェーダは、追加データを受け取り、及び／又は以前のシェーダから発光された光線により交差されたプリミティブとの関連性に基づいて識別される後続のシェーダに追加データを渡すことができる（例えば、光線１３１がミラー１１５に交差したので、ミラーシェーダのインスタンス２がミラー１１５に関連付けられて識別されている）。

この追加データはユーザが定義することができ、またアプリケーション固有とすることができる。例えば、減衰ベクトル５０８をこのような追加データとして実装することができる（すなわち、光線起点及び光線方向は、光線を定義する中核を成すが、本明細書では、異なるレイトレーシングの構成概念を実施するために使用できるデータを異なる用途間で変化させることができる）。

この追加データを適用できる１つの特定の例は、（光エネルギーを与えることによりシェーダが光線の特定のラインを終了させることなどより）光線が閉じている最中である。例えば、この追加データを、バッファ４５０に色を与えるようにＣｏｎｔｒｉｂｕｔｅ Ｃｏｌｏｒ（）コールを使用してシェーダの挙動を修正できるコードとして解釈することができる。例えば、写真又はその他の「現実世界」のイメージングをアニメーションなどを使用してコンピュータグラフィックシーンに統合するような目的で使用できる技術であるシャドウキャッチングプレーンを実施する際に、この追加データを使用することができる。

ブレンディングによって得られる最終的な色が、結合される２つのテクスチャ間の変動比率に依存する場合、別の例がブレンディング動作を実施する。これらの２つのテクスチャは、交差テストに基づいて識別される（すなわち、それぞれの光線が、テクスチャに関連するオブジェクトに交差することが判明する）。これらのそれぞれのオブジェクトに関連するシェーダは、光線発光コールを使用してさらなる光線を発光する際に追加データとしてテクスチャ情報を含む。このようなテクスチャ情報は、個々のテクスチャの識別情報、又は記述情報を含むことができる。最終的に、これらの光線は、ブレンディング動作を実施するシェーダに関連するオブジェクトにぶつかる。このシェーダがサンプリングを行って変動比率を設定し、これを使用して別の光線からのテクスチャをブレンドし、結果としてのブレンドを与えることができる。

上記に開示したように、シェーダが（バッファ４５０などの）バッファに直接寄与できるようにＡＰＩコールを提供することができる。このような寄与は、原型的には付加的なものであるが、設定を含むこのような寄与において異なる関数を実施することもできる。また、コントリビュートコールが書き込むことができるバッファは、画素色に直接関連する色情報を記憶するバッファだけでなく、あらゆる目的に使用される中間バッファとすることができる。従って、蓄積バッファ又は別様に蓄積することは、ＡＰＩにおいて利用できるコントリビュートコールの使用から書き込み動作の効果を取り込むことを含む。

上記で紹介した図６〜図９は、非再帰的レイトレーシング中のメモリ状態例を示している。図６は、カメラシェーダが、減衰ベクトル、画素、及び任意の追加データを含む光線１３０を発光することを示している。図７は、光線１３０とミラー１１０の交差に応じてミラーシェーダのインスタンス１がロードされること、及びカメラシェーダの状態を維持する必要がないことを示している。ミラーシェーダインスタンス１は、光線１３１の減衰ベクトル（Ａｔｔ．Ｖｅｃｔｏｒ’）を形成する一方で、画素及びその他のデータも含まれる。図８は、光線１３１とミラー１１５の交差によりミラーシェーダのインスタンス２が生じ、インスタンス１の状態を維持する必要がないことを同様に示している。

同様に、インスタンス２が光線１３２の減衰ベクトル（Ａｔｔ．Ｖｅｃｔｏｒ’’）を提供する一方で、画素及び追加データが受け渡される。図９は、光線１３２と光１２０の交差に応じて、光線１３２からのＡｔｔ．Ｖｅｃｔｏｒ’’、画素、及び追加データが光シェーダインスタンス１に提供されることを示している。図９はまた、ミラーシェーダのインスタンス２を維持する必要がないことも示している。図６〜図８はまた、（例えば、上記表３の「光線発光」コールの例により）それぞれ識別される光線の発光にプログラミングセマンティック４６０も使用する。光シェーダインスタンス１は、Ａｔｔ．Ｖｅｃｔｏｒ’’に基づいて画素への寄与を生成し、バッファ４５０に寄与を伝達するためにプログラミングセマンティック４６０、及び特に上記表４の「Ｃｏｎｔｒｉｂｕｔｅ ｃｏｌｏｒ」コールなどの寄与コールを使用する。

上記の例では、個々のシェーダ（カメラ、及びミラーシェーダの２つのインスタンス）が、最初に、又は交差に応じて光線を生じた。多くの実用的な実施構成では、シェーダが複数の光線を発光し、例えばミラーシェーダが各々、テストされるいくつかの光線を発光することができる。これらの光線の各々は、これらの発光を生じた光線からの追加データ（もしあれば）、並びに減衰ベクトルの伝播、及び画素の関連性に固有のものであることが好ましい。次に、個々のこのような光線が固有の二次光線を起こし、或いは交差せずにシーンから出ることができる。最終的に、特定のカメラ光線に起因して存在する全ての光線が退出し、又は光にぶつかり、或いは選択される。プログラミングセマンティック４５０がシーンバッファ４５０への寄与を可能にするコールを使用することにより、カメラ光線に属する全ての光エネルギーを閉じることができる。

上記に開示したものの要約として、方法例１０００は、光線をインスタンス化するステップ１００５、及び光線の交差を識別するステップ１０１０を含む。方法１０００はまた、光線の交差に基づいてシェーダを識別するステップ１０１５も含む。１つの例では、光線により交差されたことが判明したプリミティブをシェーダ（又はプリミティブが一部を成すオブジェクト）に関連付けることができる。他の例では、背景と交差が生じた場合、デフォルトシェーダを識別することができる。デフォルトシェーダは、全ての光線のデフォルトシェーダとすることができ、或いは光線のグループ、又は特定のタイプの光線のデフォルトシェーダ（例えば、全てのシャドウ光線のデフォルトシェーダ）とすることができる。全ての光線のための、又は特定のタイプの光線のための単一のデフォルトシェーダなどのデフォルトシェーダを意味することができる。シェーダを、光線タイプを提供される追加情報として（例えば、実行されるコードへのポインタとして）指定することもできる。シェーダは、テストするための（単複の）二次光線を指定し１０２０、発光コールを使用してこれらの光線をテストする１０２５ことができる。これらの二次光線を交差に関してテストする１０３０ことができ、方法１０００は１０１０において続行することができる。シェーダはまた、光線により識別される画素に与える光エネルギーを計算することができ、プログラミングインターフェイスのためのコントリビュートコールを使用して、これらの光エネルギーをバッファに与える１０４０ことができる。

図１１は、システム４００及び／又はその構成要素を実現するために使用できるシステム例１１００を示している。システム１１００は、各々が計算リソース１１０１の複数の論理的及び／又は物理的に別個のサブユニットを識別するために使用される複数のコア１１０２ａ〜１１０２ｎを含む計算リソースを含み、これらを各々使用して、コンピュータ可読媒体からのコードを使用してハードコード化及び／又は構成することができる動作を実行することができる。例えば、個々のコア１１０２ａ〜１１０２ｎは、複数の計算スレッドを同時に実行することができる。計算リソース１０１は、１又はそれ以上の高速アクセスメモリ構成要素を表すとともに、共有されるコア１１０２ａ〜１１０２ｎからのそれぞれの（複数の）コアに割り当てることができる、或いは割り当てと共有の何らかの組み合わせであるキャッシュ１１１５と通信することができる。コア１１０２ａ〜１１０２ｎの各々は、固有のプライベートキャッシュを含むこともできる。Ｉ／Ｏインターフェイス１１２５は不揮発性記憶装置１１３５へのアクセスを提供し、この不揮発性記憶装置１１３５の例として、１又はそれ以上のハードディスクドライブ、フラッシュドライブ、ＤＶＤ、又は高品位記憶媒体が挙げられる。インターフェイス１１２５は、例えばイーサネット（登録商標）及び８０２．１１無線ネットワーキング機能、Ｂｌｕｅｔｏｏｔｈなどを含むことができる１又はそれ以上のネットワークインターフェイス１１４０も提供する。インターフェイス１１２５はまた、マウス、キーボード、マイク、タッチスクリーン入力などを含むことができるユーザインターフェイス１１４５へのアクセスを提供する。システム１１００はまた、計算リソース１０１と通信し、記憶装置１１３５に記憶されたコード及びデータよりも頻繁に使用されるコード及びデータを記憶するために使用することができるＲＡＭ１１３０も含む。システム１１００はまた、まとめて１１１０として識別されるディスプレイコントローラ及びディスプレイの１又はそれ以上も含む。場合によっては、コア１１０２ａ〜１１０２ｎの１又はそれ以上を他のディスプレイコントローラ論理を有するグラフィックカード上に物理的に位置付けることができ、またこれとは逆に、ディスプレイ制御論理を計算リソース１１０１と同じ場所に位置付けることができる。

場合によっては、必要時に、現在交差をテストされている光線をキャッシュ１１１５に記憶すると同時に、テストのためのプリミティブをＲＡＭ１１３０からフェッチすることが好ましい。ＲＡＭ１１３０には、シェーダをテクスチャデータとともに記憶することができる。交差テスト又はシェーディングを行うために個々のコア１１０２ａ〜１１０２ｎを割り当てることができ、又は場合によっては、これらのコアが交差及びシェーディング動作の組み合わせを実行することができる。

プログラミングセマンティック４６０（図４）を記憶装置１１３５に記憶し、これをビデオゲーム、コンピュータ支援設計又はアニメーションパッケージなどのレンダリングアプリケーションとともにＲＡＭ１１３０（又はＲＡＭ１１３０及びキャッシュ１１１５の組み合わせ）にロードすることができる。プログラミングセマンティック４６０はまた、特定のシステム実施構成に適したコード及び／又はハードウェアにアクセスして、上述した光線発光及び光寄与コールも実施する。

図１２は、上述した態様を実施できるフロー１２００のプログラマを主体にした図である。フロー１２００はデータアップロードフェーズを含み、ここでは、アプリケーションが、頂点１２１０、テクスチャ１２１１、及びレンダラーにシーンをレンダリングするためのシェーダ１２１２をアップロードすることができる。レンダラーの一部は、このデータを処理してプリミティブ１２１５ａ．．．１２１５ｎを作成することができる。プリミティブ１２１５ａ〜１２１５ｎは、例えば頂点１２１０に基づいて形成された三角形ストリップによって表すことができる。プリミティブ１２１５ａ〜１２１５ｎを、テクスチャ１２１１からの１又はそれ以上のテクスチャ及び１又はそれ以上のシェーダ１２１２にリンクすることもできる。シェーダ１２１２は、様々な異なる目的のためのものとすることができる。例えば、シェーダの中には、目に見える光の効果を処理するためのものも存在すれば、物理学的、幾何学的変形などを処理するためのものも存在することができる。従って、所与のプリミティブのためのシェーダをリンクして、連続的に又は特定の条件下でのみ実行させることができる。

いずれにせよ、テクスチャ１２１８（テクセルと呼ぶこともできる）及びシェーダコード１２１７をフレームシェーダ１２２５に提供することができる。フレームシェーダ１２２５は、所与の３−Ｄシーンからレンダリングされる２−Ｄ表現の画素ごとに実行することができる。フレームシェーダ１２２５は、テクスチャ１２１８及びシェーダコード１２１７を含む入力を使用することができ、これをプログラマが使用して、所与の画素に対してどの光線を発光すべきか、特定のフィルタリング動作を実施する必要があるかどうかを判定し、或いは凝縮又は汚れなどのテクスチャをカメラの「レンズ」に適用するようなタスクの実施において使用するために実行できるデータ（一般にテクスチャ１２１８を介して）及びコード（コード１２１７を介して）を提供することができる。従って、フレームシェーダ１２２５は、それぞれＥｍｉｔＲａｙ（）１２４１ａ及びＣｏｎｔｒｉｂｕｔｅ（）１２４２ａとして識別される発光及びコントリビュートコールの両方を使用することができる。フロー１２００はプログラマを主体にしたものであるので、ＥｍｉｔＲａｙ（）１２４１ａとレイシェーダ１２３０との間で行われる交差テストについては抽象化している（すなわち、交差テストでは、どのオブジェクトが交差されるか、従ってどのシェーダが実行されるかを判定する）。要約すれば、十分に特徴付けられたフレームシェーダ１２２５のより一般的な概念を使用して従来のレイトレーシングにおけるカメラの機能を提供し、テストのために光線をどのようにシーン内に発光すべきかに関する向上した融通性をプログラマに与える一方で、レンダリング実施の有用な抽象概念を提供することができる。

フロー１２００の別の態様では、一般に現在文献に記載されている頂点シェーダに起因する関数を実施するように頂点シェーダ１２２０を実行することができる。レイシェーダ１２３０はまた、テクスチャ情報１２３１及びシェーダコード１２３２を受け取って、フレームシェーダ１２２５と同様に、この情報をＥｍｉｔＲａｙ（）１２４１ｂコール及びＣｏｎｔｒｉｂｕｔｅ（）１２４２ｂコールの使用方法を決定する上で使用する（すなわち、コール１２４１ａ及び１２４２ａを行う関数と同じそれぞれの関数を呼び出す）。一般に、レイシェーダ１２３０は、関連するテクスチャデータ内の識別された光線／プリミティブ交差に応じて実行されるシェーダコードのインスタンス、及び光線データ構造を通じて渡され、フレームシェーダ１２２５などの潜在的な以前のシェーダにより提供される追加データを含む利用できるその他のデータを表す。

Ｃｏｎｔｒｉｂｕｔｅ（）１２４２ａ及び１２４２ｂコールの両方を使用して、フレームバッファ１２３５に色を与えることができる。同様に、ＥｍｉｔＲａｙ１２４１ａ及び１２４１ｂの両方を使用して、交差テストのための光線を発光することができる。従って、フレーム（フレームシェーダ）全体をレンダリングし、フレームのレンダリング中に実行される特定のシェーダ（シーン内の異なる材料のための異なるシェーダなど）のためのコードを書き込むという両方の観点から、カメラ機能及びシェーディング機能の両方を実施できる統一されたプログラマインターフェイスを提供することができる。

さらに示すように、ＥｍｉｔＲａｙＢｕｎｄｌｅ（）コール１２４５ａにより、フレームシェーダ１２２５が交差テストされる光線束を発光できるようになり、これらの交差テスト結果に基づいて、この束からの光線が光線シェーダ１２３０内でシェーディングされるようになる。同様に、ＥｍｉｔＲａｙＢｕｎｄｌｅ（）コール１２４５ｂにより、識別された光線／プリミティブ交差に応じて実行されるシェーダが光線束を放射できるようになり、これによりバンドル内の構成光線がテストされ、識別された交差のシェーディングが継続されるようになる。

マルチパス１２４３は、フロー１２００の全体を通じる複数のパスにより、レンダリングされるシーンの少なくとも一部にレンダリングを実施できるようにする。例えば、フロー１２００を通じたいくつかの交差のための最初のパスにより、ジオメトリモーフィングシェーダ（すなわち、シーンオブジェクトの形状を変化させるシェーダ）が実行されるようになった場合、フロー１２００はこれらの変化に従うことができる。例えば、拡散及び鏡面照明、又はブレンディングのための異なるパスを実行するための他のマルチパス技術も存在し得る。

これらの開示によるさらなる態様は、再帰的レイトレーシング法／レンダラーとともに使用するための書き込まれたシェーダコードの分析、及びこの再帰的シェーダコードを非再帰的レイトレーシングのためのシェーダコードに自動的に変換することを含むことができる。この自動変換は、非再帰的レイトレーシングレンダラーとともに使用する再帰的レイトレーシングレンダリングで使用するための書き込まれたシェーダコードを変換するのに有用となり得る。以下で説明するように、これらの例に基づく変換は、このようなコードのいくつかの変形を考慮することができる。

再帰的シェーディングのためのプログラミングモデルは、テストのための光線を発光し、この発光された光線に関して戻される色結果（関連する記述では「入力色」と呼ばれる）を待ち（上述したように、子光線を生成するための多くの後続シェーダに関与することができる）、この入力色に対していくつかの演算を実行し、その後色を戻してシェーディングを終了する（関連する記述では「出力色」と呼ばれる）ことである。シェーダが入力色に対して行う演算は、（例えば、原色の赤、黄、青などの色成分のベクトルとして表すことができる）入力色の一部を加算又は乗算するなどの演算を含むことができる。

従って、ある方法では、これらのパターンを識別して、これらのパターンで行われる演算を保持するコードを非再帰的シェーダ内で生成することにより、再帰的プログラミングモデルに書き込まれたシェーダを非再帰的モデルに翻訳する。このような識別、翻訳、及びコード生成を行う際には、システム及びコンピュータ可読媒体を使用することができる。

例えば、このような翻訳の方法は、所与のシェーダのコードに、（１）テストする光線の発光を引き起こすコードと、（２）この光線をテストすることにより戻される入力色に演算を行うためのコードと、を識別するステップを含むことができる。上述したように、再帰的レイトレーシングでは、一般に（１）のコードは（２）のコードの前に実行される。その後、このようなシェーディングを非再帰的に実施するためのシェーダコードが生成される。

非再帰的レイトレーシングは（色情報などの）情報を順方向に提供するので、実行される個々のシェーダは、その「入力された」色情報を、最終的に或る経路を移動すると判定される光にその経路がどのような影響を与えるかを追跡する形で取得する。換言すれば、光源及びこれらの発光を識別した後にシェーダがカメラに戻る方向で色入力を受け取る再帰的シェーディングとは対照的に、シェーダは、光線が光源の方向に追跡される間にこれらの色入力を取得する。

従って、このような非再帰的コードを生成するステップは、交差によりシェーダが実行されるようになる光線から取得した色情報に対して上記（２）のコードと同等の演算を行うコードを生成するステップを含むことができる。このような入力色情報は、例えば減衰ベクトルを含むことができる。色情報の転送を表すための減衰ベクトルを使用して同等の演算を行うことにより、再帰的シェーダが入力色に与える影響を表す新たな又は修正した減衰ベクトルを生成することができる。その後、上述したように光線発光コールにアクセスすることにより、テストされる子光線に減衰ベクトル及び光線定義データを提供することができる。

最終的には、一般に再帰的シェーディングコードにより色が定義されて戻される（すなわち、光にぶつかることにより、戻される色は、もはやさらなる光線テストに左右されることはない）。このような色定義コードを、（シェーダに関連するオブジェクトと交差した光線に関連する画素などの）識別した画素に寄与する色を受け入れるＣｏｎｔｒｉｂｕｔｅ（）ｃｏｌｏｒコールに翻訳することができる。

再帰的レイトレーシングのために書き込まれたシェーダを非再帰的モデルに適したシェーダに翻訳することができる、コンパイラにおいて提供できる別の特徴は、非再帰的モデル内のシェーダが使用する計算リソース、及び特定の例では、シェーダの実行時に発光された光線に対してどのメモリリソースが使用されるかを推測又は別様に推定することである。上述したように、交差テストを通じて求められた一連の光線をテストすることにより、一連のシェーダを識別することができる。多くの場合、このようなシーケンスは、個々の呼び出されたシェーダが関数コールを使用して、色変数を（レイトレースコールなどの）関数コールから得られる結果で満たそうとすることにより指定される。従って、このようなシーケンスの最後部の（テストのためにさらなる光線を発光しないことによる最後部の）シェーダは、何らかの処理後に単純に色値を戻すことができる。従って、コンパイラは、このような挙動又はコードから、このシェーダが、交差テストを待っている発光光線を記憶するメモリの利用に与える影響は比較的小さいであろうと推測することができる。コンパイラは、コンパイルされたシェーダにおける手がかりとしてこのような推測又は決定を記録することができる。例えば、シェーダは、シェーダの挙動、及び特に光線の発光に関する挙動に関する手がかりを含む様々なパラメータを設定できるようにする関数コールを追加することができる。

従って、多くの場合、再帰的シェーダコードを非再帰的シェーダコードに変換するためのシステム及び方法は、演算の順序を逆にすることにより、シェーダの影響がある場合、これらの影響が最終的にどの光エネルギーに対して作用するかが分かる前にこの計算が行われるようになる。

要約すれば、本明細書で説明する機能、特徴、及びその他の論理は、いずれも様々な計算リソースを使用して実施することができる。計算リソースは、スレッド、コア、プロセッサ、固定関数処理要素などとすることができる。また、主にこの説明の中心ではないその他の機能を、１つの計算リソースに限局できる、又は（複数の物理的計算リソースに分散された複数のスレッドなどの）複数の計算リソースに分散できる処理、スレッド又はタスクとして提供又は実装することもできる。

同様に、交差テストに使用される計算リソースが、検出された交差をシェーディングするために使用されるシェーディング処理などの他の処理をホストすることもできる。さらなる例によれば、コアが複数のスレッドをサポートできる場合、１つのスレッドをシェーディング専用とし、別のスレッドを交差処理専用とすることができる。

図１３Ａは、再帰的シェーダコード１３０５と非再帰的シェーダコード１３１０との間の概念的マッピングを示している。識別した光線／プリミティブ交差に応じてコード１３０５及び１３１０の両方を開始することができる。シェーダコード１３０５はＴｒａｃｅ Ｒａｙ（）を含み、このトレースにより生じた光線のツリーが終了するのを待ち、色を戻させ、色にシェーディング動作を行い、その後色を戻し、このようにしてツリーのそのレベルも完了する。これらの態様を、例えば図１３に示すように非再帰的コードにマップすることにより、色情報が順方向に提供され（順方向に提供できるようなこの説明に基づくその他の情報）、その順方向に提供された色情報（及び提供されるその他の情報）にシェーダ動作が行われ、出力色情報（及び提供される他の情報）が形成され、後続のシェーダが受け取るための光線発光が提供される。これらのシェーディング動作により、バッファに直接色を与えることもできる。

図１３Ｂは、本例に従うＡＰＩのためのシェーダをコンパイラがいかにして処理できるかについての方法例を示している。具体的には、再帰的シェーダコード１３２５が、起点Ｏ、及び異なる方向、Ｄ１．．．Ｄｎの光線を指定するいくつかの光線発光コールを示している。コンパイラは、このシェーダコード１３２５を読み取って、これをＥｍｉｔＲａｙＢｕｎｄｌｅを含むシェーダコード１３３０に変換することができ、この場合、起点は指定されたままであり、別の光線発光コールの一部であった個々の別個の起点をここで一連の方向としてともに指定することができる。ＡＰＩを実現するコードモジュールは、光線束発光コールを受け取り、この束を処理して、光線間で共有される起点データとともに、別の光線データ構造を生成するか、或いはこの束になった光線を定義するデータをメモリに記憶するかのいずれかを行うことができる。

再帰的を非再帰的にマッピングするステップは、様々な標準形式の再帰的シェーディングコードを識別するステップと、これらの再帰的標準形式を適当な非再帰的シェーディングコードにマッピングするステップとを含むことができる。図１３Ａは、１つのこのような標準形式例を示しており、ここでは再帰的シェーダコード１３０５によりトレースレイコール（トレース１３６５）が行われる。再帰的シェーダコード１３０５は、見返りに色１を受け取るのを待ち、この色を受け取ると条件文１３６６を実行し、指定した条件が色１に適用された場合、動作が実行される。ここでは、色１は、トレースレイ関数から戻されるいずれの値であってもよく、例えばオクルージョン情報を含むことができる。条件が維持される場合、条件を表す表現及び実行すべき動作を表すコードを添付された光線発光コール（光線発光１３６７）を使用することにより、これらの開示によるＡＰＩを使用して、この標準形式を表すことができる。注目すべきは、条件がテストされる点と、非再帰的シェーダ１３１０ではなく、発光光線をシェーディングするために呼び出されたシェーダにより（或いはこのシェーダが呼び出したコードにより）実行される動作である。

図１４は、シーンをレンダリングする準備を行うときに光線データ構造を構成することに関する態様を示している。レイトレーシングレンダラーでシーンをレンダリングする準備とは、（ワイヤフレームモデルなどの）シーンジオメトリ、ジオメトリの部分にマップされるテクスチャ、カメラ位置などのシーン定義データ、及び検出されたシーン交差に応じて実行されるコードを含むシェーダを提出することとすることができる。これらのデータをＡＰＩに提出し、このＡＰＩがシーンレンダリングの準備においてこのデータを処理することができる。これらの開示による処理の１つの態様は、コールを提供された追加データ要素の出現を、上述したＥｍｉｔＲａｙ（）コールに処理することである。個々のシェーダは１又はそれ以上のこのようなコールを有することができ、個々のこのようなコールは追加データの１又はそれ以上の項目を含むことができる。例えば、図１４は、追加データの要素ｂ．１及びｂ．２（いずれのシェーダが、所与の追加データの要素を含む光線を発光したかを文字によって識別するための表記、及び追加データの１つの項目を、所与のシェーダが発光した別の項目と区別するための任意の数字識別子）を使用した計算を含むシェーダコード１４０５ａを示している。シェーダコード１４０５ａは、追加データ要素ａ．１〜ａ．ｎを含むそれぞれの光線も発光する（すなわち、ｎ個の光線が発光される一般的な場合には、各々が追加データの１又はそれ以上の項目を有する可能性がある）。同様に、この例では、シェーダコード１４０５ｂが、データａ．１及びａ．２の追加項目を使用して様々な計算を行い、追加のデータ項目ｂ．１〜ｂ．ｎを使用して光線を発光する。最後に、シェーダコード１４０５ｎは、追加データ要素ｃ．１〜ｃ．ｎを使用して計算を行い、追加データ要素ｎ．１〜ｎ．ｎを使用してＥｍｉｔＲａｙ（）を呼び出す。従って、図１４に示す例では、任意の数のシェーダが各々、このシェーダに関連するプリミティブに光線が交差したことにより、このシェーダがいくつかの追加データを利用できるようになったときに、これらの追加データを使用して計算を行うことができる。このシェーダは、異なる追加データを有する光線、又は同じ種類の追加データに対して異なる値を有する光線を発光することもできる。

シーンビルダ１４５０は、シェーダ１４０５ａ〜１４０５ｎを入力して、これらの一群のシェーダが使用する追加データ要素を識別する。シーンビルダ１４５０は、シーンをレンダリングするために使用される光線のデータ構造１４７５（又はシーンビルダ１４５０に入力される、様々なシェーダが使用する追加データ要素のレイアウトを定義するために使用される少なくとも１つの追加データフィールド１４８４）を作成する。図１４に示すように、追加データフィールド１４８４は、入力されたシェーダが使用するあらゆる追加データ要素の構成を有することができる。例えば、追加データ要素ｂ．１が、所与のシェーダが使用する最初の要素、又は入力された最初のシェーダの最初の要素ではなくても、これを最初に配置することができる。代わりに、シーンビルダ１４５０が、追加データフィールド１４８４の構造の最適化を試みることが好ましい（コンテキストのために光線識別子１４８１、起点１４８２及び方向１４８３が追加される）。このような最適化は、例えば、異なる追加データフィールドのビットを詰め込むこと、バイト又は単語の境界などの境界にフィールドを位置合わせすることなどを含むことができる。他の例では、シェーダに加え、光線又は追加データフィールドのデータ構造を、シーンビルダ１４５０に情報として渡すことができる（すなわち、光線データ構造自体をユーザが定義することができる）。

このようにして、シーンビルダ１４５０は、レンダリングされるシーンの交差テスト中に実行するように呼び出すことができるシェーダを受け入れる。シェーダは、ＥｍｉｔＲａｙ（）コールを通じて互いにデータを受け渡すことができ、追加データの要素を引数として、又はこのような要素を含む光線データ構造を受け入れることができる。

また、光線データ構造１４７５が決定されると、シーンビルダ１４５０は、個々のシェーダが特定の追加データにアクセスできるように光線データ構造１４７５へのオフセットを正しく識別することができる。例えば、追加データ要素ｎ．ｎを、３つの色ベクトルの各々のための３バイトを有する減衰ベクトルとすることができ、データ構造１４７５の開始後にいくつかのバイトを開始するものとして指示することができる。従って、シーンビルダは、シーン全体の慣習を設定するものと見なすことができ、個々のシェーダは、データ構造に含まれるデータに正しくアクセスしてこのデータを消費することができる。実際に、所与のシェーダを実行する計算リソースは、メモリアドレスを表すことができる光線識別子、又は所与の光線に関する情報にアクセスするためにフィールド１４８１に記憶されたベースメモリアドレスからのオフセットを使用することができる。さらなるオフセットを作成して、識別された光線のデータ構造内の特定のフィールドを識別することもできる。従って、光線データ構造の追加データ要素は、一般にシェーダが使用する要素を結合したものになる。光線発光コール内に追加データ要素が提供され、いずれのシェーダもこれを使用しないという状況が存在し得る。このような場合、シーンビルダ１４５０は、この要素にスペースを割り当てないことを選択することができる。一方で、シーンビルダ１４５０がなんとかスペースを割り当てて、レンダリングが開始された後でもシェーダをシーンに拘束できる状況を考慮することができる。

シェーダコード１４０５ｎはまた、光線束コールをどのように実施及び使用できるかについてのいくつかの異なる例を示すためにも使用される。第１の光線束コール例１４２２では、束が、束になった光線の共通の起点、個々の光線の別個の方向情報、個々の光線間で分散される、又は個々の光線に割り当てられる重み、及び束の光線に属するようになる追加データを指定する。第２の光線束コール１４２３は、コール内に例外を作成できる光線束コールを示している。コール１４２３では、重みｗ１が、共有される起点及び目的地情報ｄ２によって定義された光線の特定の特異点である。重みｗ１は、ｄ２光線のデフォルトの提供済みの重みｗに優先する。そうでなければ、例外情報を含まない残りの光線に重みｗが割り当てられる。第３の光線束コール１４２４の例は、複数の異なる起点、目的地指定子、重み、及び追加情報を示している。その他の実施構成を提供することもできる。例えば、事前構成したシーン光の組を設定することができ、光線束コールがこの光の組を参照して影光線を指定することができる。この場合、コードモジュールを提供して、様々な起点を受け入れ、光の目的地に基づいて、束の個々の光線の方向を構築し、これらの起点及び方向を独立した光線として光線メモリに記憶することができる。或いは、光線をこれらの目的地への参照とともに記憶して、所与の光線の交差テスト前にそれぞれの方向を構築することができる。

図１４は、これらの例による光線発光コールに含めることができる特定の他のデータの例も示している。シェーダ１４０５ａは、（「ｐａｒｅｎｔｒａｙｒｅｆ」などの）光線参照を含むことができるＥｍｉｔＲａｙコールの変形を含む。光線参照を含めて、参照される光線から利用できる属性をこの光線から取得できるようにすることができる。このようなコールのためのＡＰＩ及び／又はコンパイラコードは、この光線を参照する全ての光線が完了するまで、参照された光線がメモリ内に保持されるようにすることができる。この保持を行うために、シーンのレンダリング中に参照回数を保持することができ、光線が完了する度にこの回数を減少させ、この光線を参照する光線が発光される度に増分することができる。典型的な例では、被参照光線を数多くの子光線の親とすることができるが、参照する（単複の）光線に被参照光線を関連付ける必要はない。

シェーダ１４０５ａは、光線発光コールを含むコードセグメントへのポインタを含む例をさらに含む。このポインタは、発光光線のデータとともに保持され、この光線に関して交差が検出された場合、この新しく検出された交差に対して実行されるシェーダ（「次の」シェーダ）にポインタを提供することができる。次のシェーダは、被参照コードを様々な目的のいずれかのために使用することができる。場合によっては、シェーダコードが完了した後に被参照コードを実行することができる。例えば、被参照コードは、デフォルトバッファとは異なるバッファ（光線に関連する画素のためのバッファなど）に色が与えられるようにすることができる。同様に、シェーダコード１４０５ａは、光線発光コールにコードを含めることができることをさらに示しており、このようなコードは同様の目的を果たし、同様の又は同じ目的を達成することができる。

図１５は、シェーダが非再帰的レイトレーシングのためのＡＰＩを使用できる全体的システムの態様を示しており、具体的には、この例は主に光線束発光コールの使用を示している。シェーディングリソース１５０９は、複数のシェーダ（図示のシェーダＡ及びシェーダＢ）を実行するように構成された計算リソースを示す。第１の光線束発光１５０８は、共有される起点ｏ１、及び複数の方向ｄ１．１〜ｄ１．ｎ、及び光線により共有される重みｗを指定する。コールに含めるための様々なパラメータを指定することができ、これらをｐ１．１〜ｐ１．ｎとして示している。同様に、起点ｏ２、複数の方向ｄ２．１．．．ｄ２．ｎ、及び光線に関連する重みｗ２を含む束を定義する第２の光線束発光１５０７も示している。光線束コール１５０８と同様に、この束も、束のために指定できる様々なパラメータを含むことができる。これらを開示することにより、光線束コールが、所与の最小又は最大数の光線、パラメータなどを指定されなければならないという意味はない。前述したように、パラメータは、デフォルトの例外を指定することができ、或いは特定のパラメータを直接指定することができる。

これらの光線束コールをＡＰＩセマンティック１５０５が提供して、シェーダがこれらのコールを使用したときに、シーンをレンダリングする準備をするコンパイラ又はその他のソフトウェアが、これらのコールをこのセマンティックに基づいて適切に解釈できるようにすることができる。

ＡＰＩは、所与のシステムに実装される場合、及びシェーダ実行中（すなわち、シーンのレンダリング中、光線束コールを実行するコードを、これを参照する実行シェーダにより起動することができる）。このような実行は、交差テストのために発光されたものの一般には未だ交差テストが完了していない光線を定義する光線データのマスタコピー１５１０を記憶するメモリと相互運用性がある。一般に、これらの光線の中には、交差テストリソース１５２５内で積極的に交差テストされているものもあれば、交差テストを待っているものもある。

光線データマスタコピー１５１０は、個々の光線の識別子、及び（起点及び方向情報などの）定義データ、及び１又は複数の光線がシェーダにより発光されたときに指定されるいずれかのパラメータ情報を含む。光線データマスタコピー１５１０は、束の光線間で共通する属性情報が束の１つの光線に対してのみ指定されるように束の光線を記憶する特定の例を示している。説明するように、パラメータを指定された光線は、このような束の光線が完了したかどうかを追跡する計数情報を含むことができ、この光線は、この束のその他の全ての光線が完了するまでメモリ内に保持されて、パラメータは利用可能なままにされる。

コントローラ１５２０は、マスタ光線データコピー１５１０を管理し、どの光線の交差テストを開始すべきかを決定し、交差テストの結果を利用できるようになったとき、及びシェーダが新たな光線を発光し続けるときにマスタコピー１５１０を更新する。

また、この特定の例では、コントローラ１５２０の制御により、光線識別子の待ち行列１５０８が投入される。交差テストリソース１５２５が交差テストを行うための新たな光線を受け入れることができる場合、交差テストリソース１５２５により待ち行列１５０８が読み取られる。一例では、待ち行列内の光線識別子によって識別される光線を定義するデータが、待ち行列１５１５内に別個に提供されて、交差テストリソース１５２５（ここには示さず）内のローカライズされたメモリに記憶される。場合によっては、待ち行列１５１５を提供する必要がなく、交差テストリソース１５２５によりアクセスされる１又はそれ以上のローカルメモリに光線定義データをＤＭＡすることができる。

交差テストリソース１５２５は、交差テスト結果を結果待ち行列１５１６に出力し、通常は、交差されたプリミティブの識別子及び光線識別子を含む。例えば、結果待ち行列１５１６は、１つの入力として、光線ＩＤ Ａ１、及びプリミティブＩＤ Ｑを含む。コントローラ１５２０（又は別の機能ブロック）は、プリミティブＱがシェーダＢにマップすること（すなわち、プリミティブＱがどのように挙動するかをシェーダＢが決定すること）を決定することができる。その後、プリミティブＱに対してシェーダＢを実行すべきかどうかの判定が行われる（１５４１）。この判定は、制御入力１５４５に一部基づいて行うことができる。このような制御入力は、光線データマスタコピー１５１０が全体として利用できるメモリ空間の現在の使用状況又は利用率などの現在のリソース使用状況の指示を含むことができる。シェーディングを行うかどうかの判定（１５４１）にもシェーダＢに関する情報を使用することができ、この情報はコンパイル時に得ることができ、或いはシェーダＢの内容に基づいて別様に推測される。判定１５４１は、光線に関連する重み、或いは光線のシーンに対する相対的重要度についての別の適当な指示に基づいて行うことができる。

特定の例では、制御入力１５４５が、現在のメモリ使用が閾値よりも大きいことを含む。この場合、この特定の光線（Ａ１）をシェーディングするか又は遅らせるかの判定１５４１を行って、記憶する必要がある新たな光線が数多く発光されることを避ける。光線Ａ１をシェーディングすることにより、新たな光線が数多く発光される可能性があるかどうかを判定するためのヒューリスティックは、光線に関連する重みを使用することができる。このような重みが高いほど、光線Ａ１のためのシェーダＱがシェーディング中に新たな光線を数多く発光する可能性が高くなる。従って、光線Ａ１が比較的高い重みを有する場合には光線Ａ１のシェーディングを遅らせることができ、このステップは、遅延通信チャンネル１５４２を使用して光線を待ち行列１５１６内のはるかに後ろのポイントに置くステップを含むことができる。当然ながら、光線ＩＤ Ａ１の入力に遅れているものとしてマーキングしたり、さらにはこの光線をスキップして、待ち行列１５１６内の現在の位置に置いたままにすることにより、このような延期を行うこともできる。このようなレイシェーディング遅延を実施するための他の方法も実施することができる。

光線バンドルＡＰＩの実施構成と密接に結びつく例では、光線に関連する重みの１つの使用法が、光線の特定の画素に対する（光線束ＡＰＩコール内のパラメータとして識別することができる）相対的重要度を追跡するためのものである。例えば、所与の画素に対して５つのカメラ光線が発光された場合、各々に０．２の重みを割り当てることができる。これらのカメラ光線の１つが、５０個の光線を発光する拡散照明シェーダを実行するシェーダに関連するプリミティブに当たった場合、これらの拡散照明光線の各々は、その親光線の重みである０．２の約１／５０の重みを有することができる。しかしながら、別のカメラ光線が、１つの光線しか発光しないミラーシェーダに当たった場合、このミラー光線は、その親光線とほぼ等しい重みを有するようになる。従って、光線束コールとの関連では、親光線が束の光線間で分割されるとすぐに、光線束コール内に親光線の重みを提供することができる。従って、多くの場合、束のためのＡＰＩコールを含んでいたシェーダを伴う光線に、この束内の光線の重みを関連付けることができる。

この例を継続して、５０個の拡散照明光線とミラー光線の両方を交差テストし、光線Ａ１が拡散照明光線の１つを表すと仮定する。この光線は、５０個の兄弟光線に分割された重みに関連付けられるので比較的重みが低くなり、適切に書き込まれたシェーダ内では数多くの追加光線が発光される可能性は低くなる。従って、メモリに記憶された光線数を減少させることが望ましい場合、この低い重みの光線は直ちにシェーディングされ、遅延されることはない。一方で、ミラー光線が交差テストを完了した場合、交差されたプリミティブに関連するシェーダは、この交差をシェーディングする際に数多くの光線を発光する可能性が高くなる。従って、シェーディング又は遅延の判定では、（マスタコピー１５１０のサイズなどの）光線の記憶装置に使用されるメモリの量を減少させるように動作する場合、このミラー光線（この光線を発光したシェーダという一般的な理由でミラー光線と呼ぶ）を遅延させるように判定される。

所与の光線交差をシェーディングする判定が肯定的なものであった場合、この光線の光線ＩＤとこの光線の関連する束との間でマッピングを行うことができる（このような束が存在する場合、光線を単独で発光できるため存在する必要がない場合、又は束コールを使用して発光された場合でも、全てを全く異なる無関係な情報とともに記憶することができる）。次に、この束の残りの光線の総数を更新することができる１５７８。光線のためのシェーダは、シェーダ計算リソース１５０９内で実行することができる。

制御入力１５４５は、システムの使用状況に関する他の様々な情報を含むことができる。例えば、制御入力１５４５は、上界及びリソース下界を含むことができ、上界よりも高い重みの光線はシェーディングを遅延され、下界よりも高い重みの光線がシェーディングに好ましい。さらなる情報として、光線データマスタコピー１５１０に現在記憶されている光線のための平均重み、このような光線重みに関するトレンド情報などを挙げることができる。

光線束コールを含む、光線発光コール内で利用できるさらなる態様に、光線発光コールにより発光される光線のタイプを定義する変数の列挙がある。光線タイプは、プログラミングセマンティックを介して利用可能になる定義された一覧から選択することができる。この一覧は、起動段階中に決定することができる。サポートが望ましい列挙されたタイプの数に応じて、光線タイプフィールドに割り当てられるビット数を選択することができる。プログラミングセマンティックは、理解がより容易な光線タイプ名と個々の光線タイプに割り当てられたビットストリングとの間でマッピングを行うことができる。光線タイプの例として、オクルージョン光線、反射光線、及び屈折光線が挙げられる。個々の光線タイプは、複数の属性を含むように定義することができる。光線タイプ情報を記憶する包括的にアクセスできるメモリ位置を提供することができ、このような光線タイプ情報をカスタマイズすることができる。光線タイプ情報は、参照される光線タイプ内で定義される属性をいくつかの光線タイプが共有する階層的なものであってもよい。個々の光線タイプに割り当てることができる１つの属性は、その光線に対して実行すべきデフォルトシェーダである。

図１６は、非再帰的レイトレーシングが、様々なオブジェクトにぶつかり、そのシェーダがさらなる光線の発光を引き起こす一連の光線をシーンのレンダリング中にどのように追跡できるかについての態様を示している。具体的には、図１６は、光線を通じて伝播されるコードをどのように使用して「ダウンストリーム」のシェーダ挙動を修正できるかについての例を示している（ここでは、ダウンストリームを、既存の光線のツリーを束ねる再帰的概念と対比することができる）。

図１６は、奇数の整数を付したシェーダを含む。この例では、シェーダが利用できるＡＰＩコールを凡例に示しており、このＡＰＩコールは、光線定義データを受け入れるとともに発光された光線の交差テストを引き起こす単純なＥｍｉｔＲａｙコールを含む。別のコールには、Ｃｏｎｔｒｉｂｕｔｅコールがあり、このコールは、バッファへの寄与を可能にし、シェーディングされる交差に関与する光線の識別された位置のデフォルトとなることができる。ＥｍｉｔＲａｙコールは、被参照コールになるように修正することができ、発光された光線の定義において使用するデータのために別の光線を参照できるようにする。このような被参照コールを光線束コール（ここでは示さず）に拡張することができる。図示の別の光線コールは、指定されたリゾルーションルーチンを実行できるようにするとともにコード又はコードへの参照を受け入れることができるＥｍｉｔＲａｙコールである。これらの基本例の組み合わせを提供することができ、例えば、リゾルブ型の光線発光コールが別の光線を参照することもでき、これにより参照型のＥｍｉｔＲａｙコールとリゾルブ型のコールとの組み合わせとすることができる。

以下、まず図１６について概要レベルで説明し、次に図１７に関してその態様についてさらに説明する。

図１６では、カメラシェーダ１６０１が実行されて光線１６０４及び１６０６を発光することを示しており、カメラシェーダが、スクリーンバッファ１６４０の位置に直接寄与できることをさらに示している。光線１６０４及び１６０６は、各々交差テストされる。光線１６０６の交差に基づいてシェーダ１６０５が識別され、このシェーダ１６０５が２つの被参照光線１６０８及び１６１０を発光していることを示している。この参照は、光線１６０６に対するものとすることができる。さらに、シェーダ１６０９及び１６１１が実行され、これらのそれぞれの実行が、スクリーンバッファ１６４０の位置への寄与１６１２及び１６１４を引き起こす。

光線１６０４のトレーシングによりシェーダ１６０３が識別されて実行され、これがＥｍｉｔＲａｙコールのリゾルブ修正の使用を通じて光線１６１６を発光する。光線１６１６が追跡されて、シェーダ１６０７が識別されるようになり、これが実行されて光線１６１８及び１６２０を発光し、これによりリゾルブ型のコールが保持され、これがさらにシェーダ１６１３及び１６１５の実行を引き起こす。

この例におけるシェーダ１６０７は、シェーダ１６０７が発光する光線をテストすることにより取得される最終的な色結果に基づいて出力を変更する効果を実現するためのコードを含む。通常、再帰的レンダラーでは、シェーダ１６０７の状態は、テストされる光線を発光した後に単純にスタックに積まれていき、光線のツリーのロールアップ中に再起動されるようになる。しかしながら、非再帰的レンダラーでは、通常、シェーダの状態は保持されない。従って、非再帰的レイトレーシングにおいてこのような機能を実行できるようにする一方で、このような状況に関与しない大多数のシェーダのためには非再帰的トレーシングの恩恵を受けることが望まれる。

光線１６１８及び１６２０が追跡されて、シェーダ１６１３及び１６１５が識別され実行されるようになり、これらについては、それぞれの寄与コール１６２２及び１６２４のみを有しさらなる光線を発光しないように示している。ところで、デフォルト例では、寄与コール１６２２及び１６２４がスクリーンバッファ１６４０に書き込みを行う。しかしながら、コード（又はコードの参照）とともにリゾルブ型のコマンドを使用することにより、これらの結果が一時バッファ１６３８に（同じコントリビュートコールを使用した）書き込まれるように寄与コールを修正又はリダイレクトすることができる。典型例では、さらに多くの光線、より多くのテストされる光線の「生成」が存在することにより、一時バッファが、リゾルブコマンドを保持するいくつかの寄与コールから寄与を蓄積できるようになる。これらが全て完了すると、再びシェーダ１６０７を呼び出すことができ、提供された（又は参照された）コードが一時バッファからシェーダ１６０７に値を戻すことができ、シェーダ１６０７は、コントリビュートコール１６２８を介してスクリーンバッファ１６４０に行われる寄与を策定する際にこの情報を使用することができる。

図１７Ａ〜Ｅは、典型的な再帰的アプローチと本例との差異を強調するために、メモリ状態の態様に関するビルドを示している。図１７Ａは、光線メモリ１７０４に記憶するための光線１６０４及び１６０６を発光するカメラシェーダ１６０１の積極的な実行、及びスクリーンバッファ１６４０の一部への寄与１６０２を示している。

さらに、図１７Ａは、状態を維持する必要があるあらゆるシェーダを保持するスタック１７６０も示している。スタック１７６０は、図１７Ａ〜図１７Ｅに別個に示していない場合、この説明に関するシェーダ状態を記憶しない。

図１７Ｂは、現在シェーダ１６０５が実行されて、各々が光線メモリ１７０４内の記憶位置を見つける光線１６０８及び１６１０を発光していることを示している。通常、（シェーダ１６０５の実行で証明されるように）テストの完了後には光線１６０６を光線メモリ１７０４から取り除くことができるが、シェーダ１６０５は、被参照コールを使用して、より具体的には参照光線１６０６に光線１６０８及び１６１０を発光する。従って、光線１６０６が参照されたので、これが維持される。

図１７Ｃは、シェーダ１６０９及びシェーダ１６１１の両方の実行１７０２を示している（実施構成に依存するので、同時に実行できるシェーダの数に制限はない）。上述したように、これらのシェーダの各々はそれぞれの寄与を行う。光線１６０８及び１６１０が交差テストを完了し、これらのそれぞれのシェーダがさらなる参照光線を発光していないので、光線１６０８、１６１０及び１６０６を全て除去することができ、又はこれらがメモリ（すなわち、自由に決定されたメモリ位置）内で上書きされるようにすることができる。

図示してはいないが、図１７Ｃと図１７Ｄの間でシェーダ１６０３及び１６０７の実行が行われる。図１７Ｄは、シェーダ１６１３及び１６１５の実行１７０２、及びシェーダ１６０７が発光した光線１６１８及び１６２０の記憶、並びにシェーダ１６０３が光線発光において参照しなかった光線１６０４の除去を示している。

シェーダ１６１３及び１６１５が、より大きなレンダリングの処理に最終的にどのように影響を与えるかが修正されるようにするためのコード又はコード参照を含むリゾルブ型のコールで発光された光線と交差したことにより、シェーダ１６１３及び１６１５が呼び出されたことについては上述した。より詳細には、リゾルブ型のコールは、これらのシェーダに関しては寄与コールがリダイレクトされるようにし、シェーダがこのコールを使用した場合、結果が一時バッファ１７６１に提供され、スクリーンバッファ１６４０には提供されないようにする。ここで、スタック１７６０がシェーダ１６０７の状態を記憶する。

図１７Ｅは、再入力されスタック１７６０から除去された解明コードの断片１７１１及びシェーダ１６０７の実行を示している。シェーダ１６０７は、バッファ１７６１から読み取りを行うことができる（或いは、解明１７１１により、このバッファのコンテンツを提供することができる）。次に、シェーダ１６０７は、寄与コール１６２８内に提供されるデータを策定することができ、ここでスタック１７６０が再び空になる。

従って、図１６及び図１７Ａ〜Ｅは、通常の状況において、非再帰的レイトレーシングではほとんどのシェーダ状態が記憶されず、ＡＰＩコール（より一般的にはＡＰＩ機能）を提供してこれらのシェーディング効果を処理することができ、このためには、ステートフルなシェーダへの再入力を行えるようにすることが有用であり又は望ましいことを示している。

開示したＡＰＩコールを通じて発光された光線で減衰ベクトルを提供できることを様々な例に開示した。減衰ベクトルの使用法は、シェーダの（単複の）創造者が確立した協定に従うことができ、これに対する動作は、一般にベクトルの成分を他の数字で乗算することに従うことができる。通常、このような乗算は１未満の数と行われて、減衰ベクトルがトレーシング中の光エネルギーの減衰を表すようになる。しかしながら、この数字は任意とすることができ、１．０未満である必要はない。

説明したように、減衰ベクトルは、説明した光線発光ＡＰＩコール（光線発光及び光線束発光など）を通じて発光された光線とともに含めることができるデータの１つの例である。このようなデータの別の例に、列挙した光線タイプ変数の使用があり、これは、標準的光線タイプを参照することによる様々なデータフィールド及び属性の組み込みを可能にする。ユーザが定義したデータを光線とともに提出することもできる。このようなデータの別の例はコードであり、さらなる例はコードへのポインタである。ＡＰＩコールは、光線に関する交差をシェーディングする必要がある状態を含む又は参照する、発光される光線を受け入れることが好ましい。

これらの開示によるＡＰＩとともに使用できるシステムアーキテクチャの１つの例では、シェーダを、（一般に上記の例及び説明による３−Ｄシーンなどの）シーン内の位置又は表面に関連付けることができる。より一般的には、このアーキテクチャを適用して、数多くのパラメータに渡って定義できる要素を含む（ｎ次元のデータ空間などの）データセットのための読み取りクエリ（すなわち、使用されるデータセットの定義部分を更新又は修正しないクエリ）を満たすことができる。例えば、データセットは、それぞれの値又は値の範囲をパラメータに割り当てることによりｎ次元のデータ空間内に配置できる別個のポイント又は表面を含むことができる。

１つの好ましい態様では、要素の各々が、実行できる１又はそれ以上のコードモジュールに関連付けられる。コードモジュールの各々は、ＡＰＩセマンティックのあらゆる部分（一般的なｎ次元のデータベースクエリの構築に適用される例に基づく、ＡＰＩコールの１又はそれ以上、関連パラメータ、シーン全体の構築など）を使用することができる。例えば、ＡＰＩセマンティックは、クエリ又はクエリの束を発行するためのコールを提供することができる。個々のコードモジュールは、包括的にアクセス可能なバッファ又はバッファセットに書き込み動作を行えるようにするコントリビュートコールを使用することもできる。本明細書で使用する包括的にアクセス可能とは、バッファの可視性の範囲がコードモジュール内に制限されないこと、及び、モジュール実行の完了時のみならず、コード実行中のあらゆる時点でバッファに値を書き込むことができることを含む。従って、寄与コールが（単複の）バッファに包括的にアクセス可能であるということを、個々の機能の完了時にインスタンス化コードモジュールに値が戻される、戻された値の再帰的ロールアップと対比させることができる。

また、個々のクエリは、クエリの基準を満たすデータセットの要素との関連性に基づいて識別されたコードモジュールが使用できる状態又はその他の情報を含むことができる。コード及び／又はコードへのポインタをクエリとともに含めて、コードモジュールが実行する動作にクエリが影響を及ぼせるようにすることもできる。このようにして、本開示による発光及び寄与コールの使用を通じた所与のコードモジュールにより、状態が転送され結果が提供される。所与のコードモジュールは、発光及びコントリビュートコールを使用してその効果を示す（その機能目的を果たす）ように書き込まれることにより、このコードモジュールに割り当てられたメモリ及び処理リソースを解放できるようになることが好ましい。一方で、再帰的プログラミングパラダイムに書き込まれたコードモジュールは、機能コールから値が戻されるのを待っている間は常駐したままとなる。通常、このコードモジュールはにスレッドが割り当てられ、このスレッドは、上記値を待っている間ストールすることができる。スレッドのコンテキストを維持し、これをアクティブモードからストールモードへ切り換え、元に戻すことにより、避けることが好ましいオーバヘッドが加えられる。

従って、上述したアーキテクチャは、複数の入力を含むデータセットを体系化するためのメカニズムを提供し、これらの入力の各々は、数多くのパラメータに渡って定義され、クエリがこの入力により満たされたときに実行されるコードモジュールに関連する。さらに、このコードモジュールはさらなるクエリを発生させ、これを全体的に見えるバッファ位置に書き込むこともできる。個々のクエリは、状態、コード及びコードへのポインタを保持することもできる。

従って、このアーキテクチャは、コードモジュールの実行順序、及びこの実行で使用される入力データ要素を決定するメカニズムを提供する。より典型的なプログラミングパラダイムは、一般に所定の条件が真であることが判明した場合、コードモジュールが、指定された１又は複数のモジュールを呼び出すなどの、他のコードモジュールとの予め定めたリンクを含むようなプログラムフローを規定する。しかしながら、本明細書では、コードモジュールが共通のＡＰＩを通じてインターフェイス接続し、データセットで作られる定義済みのパラメータを含むクエリを発行する機能を提供し、クエリを満たすデータセットの要素に基づいて、１又はそれ以上のさらなるコードモジュールが実行のために選択されることを意図している。これらの１又はそれ以上のさらなるコードモジュールを実行する元になるデータは、部分的にクエリ自体に由来することができ、またデータセット内の他のデータに由来することもできる。

シェーダを受け入れ、光線データ構造に包括される追加データ要素の光線データ構造を決定することに関する上述の態様を具体化するシステム、方法及びコンピュータ可読媒体を提供することができる。これらの場合、所与のデータ値を直接表すのではなく、論理的又は物理的なメモリ参照などの参照により追加データ要素を具体化することもできる。この参照を使用して、１又はそれ以上のメモリから対応するデータを取り出すことができる。追加データ要素は、元々（整数、フロート、ダブル、ストリングなどの）シェーダソースコードの形で定義されていた場合、これをデータタイプに関連付けることができる。光線データ構造を決定する際に、及びシェーダ間の要素を相関付けるためにシーンビルダ１４５０がこれらのデータタイプを使用することができる。上述したように、シーンビルダ１４５０は、色の寄与及び光線の発光に関するＡＰＩ態様を提供するシステム及びコード内で具体化することができる。例えば、ＡＰＩは、ランタイム中にシェーダが使用するコールに加え、シェーダコード、ジオメトリ、テクスチャなどを提出するためのコールを含むことができる。アプリケーションが、ＡＰＩを介してこのような情報を提出した後、このアプリケーションは、シーンのレンダリングの準備が整ったことを示すことができる。

追加データのアプリケーションの例として、重量又は質量又は他の物理的な属性を光線に関連付ける（単複の）減衰ベクトル、フィルタリング又はブレンディング仕様などの数学的演算、シェーダ挙動を示す又はこれに影響を与えるフラグ、実行可能コード（例えば、シーン又はシーン内のオブジェクトを修正し又はこれに影響を与えることができる手続きの形状のためのコード）などが挙げられる。

いずれかの方法のためのコードを、固体ドライブ、ハードドライブ、ＣＤ−ＲＯＭ及びその他の光学記憶手段などのコンピュータ可読媒体に、一時的に不揮発性メモリに記憶することができ、また通信信号内で具体化することができる。このようなコードが通信信号内で具体化され、この信号がコンピュータに読み取られて処理された場合、コンピュータは、この信号及びこの物理媒体をコンピュータ可読媒体として使用する。

コンピュータ実行可能命令は、例えば、汎用コンピュータ、専用コンピュータ、又は所定の機能又は機能グループを実行するための専用処理装置を生じ又は別様に構成する命令及びデータを含む。このコンピュータ実行可能命令は、例えば、バイナリ、アセンブリ言語などの中間フォーマット命令、又はソースコードとすることができる。本明細書で説明したＡＰＩのいくつかの態様を、手順、機能、又はこのような手順及び機能へのコールとして実現することができる。ソフトウェア、ハードウェア、又はこれらの混合が提供されるインターフェイスを介してこのような機能にアクセスするための能力をプログラマに提供する限り、本説明は、これらの手順又は機能を介して利用できるものとして説明した機能を実現又は提供するために使用できるプログラミング方法に関する制限を意味しない。再帰的及び非再帰的レイトレーシングの両方における特定のコード化概念に（ＴｒａｃｅＲａｙ（）、ＥｍｉｔＲａｙ（）、及びＥｍｉｔＲａｙＢｕｎｄｌｅ（）などの）様々な名前を提供した。これらの名前は、実施構成においてこれらの機能を実行するどのようなコードを呼び出す必要があるかに関する要件を意味するものではない。

上述した様々な例は例示として示したものにすぎず、限定として解釈すべきではない。例えば、レイトレーシングの挙動についての限られた例のみを示しており、実際の実施構成はより多くの光線を含み、これらのより多くの並行処理を含むことが理解されるであろう。本明細書における開示は、この見地から適用及び理解することができる。また、図示のシステムの機能的要素の独立したボックス又は図示した分離については、これらの要素間の通信を、物理的な分離を伴わずにメッセージング、機能コール、共有メモリスペースなどによって行うことができるので、このような機能を物理的に分離する必要があることを意味するものではない。より一般的には、当業者であれば、プログラミングセマンティックに関する開示を他の様々なレイトレーシング／レイシェーディングの実施構成に適用することができ、システム、方法、及びこれらの例を説明するために使用したその他の開示から、この適用に関して暗黙的な制限は存在しない。

１２００ フロー
１２１０ 頂点
１２１１ テクスチャ
１２１２ シェーダ
１２１５ａ プリミティブ
１２１５ｎ プリミティブ
１２１７ シェーダコード
１２１８ テクスチャ
１２２０ 頂点シェーダ
１２２５ フレームシェーダ
１２３０ 光線シェーダ
１２３１ テクスチャ情報
１２３２ シェーダコード
１２３５ フレームバッファ
１２４３ マルチパス

Claims (37)

1. コンピュータ実行可能シェーダコードとのインターフェイスをとる方法であって、
   親光線の定義データ、及び該親光線の、オブジェクトで構成された３−Ｄシーンからレンダリングされる２−Ｄ画像の画素に対する関連性を、光線発光コールを通じて受け入れるステップと、
   前記親光線の交差テスト結果に基づいて選択されるシェーダを選択するステップと、
   実行中に前記光線発光コールを通じて前記選択されたシェーダから１又はそれ以上の子光線を受け入れるステップと、
   前記子光線の各々との前記画素の関連性を継続するステップと、
   前記子光線の少なくともいくつかの取得した交差テスト結果に基づいて１又はそれ以上のシェーダを選択するステップと、
   実行中に前記子光線に関して選択した前記シェーダの１又はそれ以上から、前記画素のバッファ内への直接の（単複の）寄与を、コントリビュートコールを通じて受け入れるステップと、
   を含むことを特徴とする方法。
2. 前記（単複の）寄与が、前記親光線のための前記シェーダに再入力せずに受け入れられる、
   ことを特徴とする請求項１に記載の方法。
3. 前記画素の関連性が、前記１又はそれ以上の子光線のデータとともに前記光線発光コールを通じて画素関連性情報を受け取ったことに基づいて継続される、
   ことを特徴とする請求項１に記載の方法。
4. 前記寄与が、前記１又はそれ以上の子光線の受け入れとともに前記光線発光コールを通じて減衰ベクトルが受け入れられたことに少なくとも一部基づく、
   ことを特徴とする請求項１に記載の方法。
5. 前記寄与が色の寄与であり、前記第１のシェーダが、前記親光線に関連する前記光線発光コールを通じて受け取った減衰ベクトルから取得したそれぞれの減衰ベクトルを使用することにより、前記親光線の前記画素への総色寄与容量が前記複数の子光線間で分散される、
   ことを特徴とする請求項１に記載の方法。
6. 前記コントリビュートコールが、前記画素のためのバッファ以外の指定されたバッファ位置への寄与のリダイレクションを受け入れる、
   ことを特徴とする請求項１に記載の方法。
7. 前記リダイレクションがコードにより指定され、前記コントリビュートコールを通じて提供されるか、又は前記コントリビュートコールを通じて提供されるポインタにより参照されるかのいずれかである、
   ことを特徴とする請求項６に記載の方法。
8. 前記親光線の前記画素に対する関連性が、前記光線発光コールを通じてデータを識別する画素の受け入れの１つを通じて、及び前記親光線を発光するシェーダが暗示する関連性により決定される、
   ことを特徴とする請求項１に記載の方法。
9. 前記１又はそれ以上の子光線の受け入れステップが、複数の子光線を指定するデータを受け入れるステップを含み、前記データが、前記複数の子光線間で共有される属性を記述するデータを含む、
   ことを特徴とする請求項１に記載の方法。
10. 前記１又はそれ以上の子光線の受け入れステップが、値を指定するデータを光線タイプの列挙リストから受け入れるステップを含む、
    ことを特徴とする請求項１に記載の方法。
11. シーン内でレイトレーシングするためのシステムであって、
    前記シーン内の交差に関して光線をテストする光線交差テストリソースと、
    シェーディング結果を蓄積するためのバッファと、
    プログラミングインターフェイスを実現するためのコードを記憶するコンピュータ可読媒体と、
    を備え、前記プログラミングインターフェイスが、シェーダが交差テストされる光線を指定するために使用する光線発光コールと、前記バッファの１又はそれ以上の位置に直接与えられる結果を表すデータをシェーダ実行中に受け入れることにより、シェーダを前記バッファにインターフェイス接続するためのコントリビュートコールとを含む、
    ことを特徴とするシステム。
12. 前記光線交差テストリソースから受け取った交差テスト結果に応答して、実行すべきシェーダを前記システムが選択できるようにするためのコンピュータ実行可能コードを記憶するコンピュータ可読媒体をさらに備える、
    ことを特徴とする請求項１１に記載のシステム。
13. 前記システムが、交差されたオブジェクトを示す交差テスト結果に応答して、実行すべき前記オブジェクトに関連するシェーダを選択することによりシェーダを選択する、
    ことを特徴とする請求項１２に記載のシステム。
14. 前記シェーダが、前記交差テスト結果内に提供されるプリミティブ識別子を使用して選択される、
    ことを特徴とする請求項１３に記載のシステム。
15. 前記システムが、オブジェクト交差が存在しないことを示す交差テスト結果に応答して、実行すべきデフォルトシェーダを選択することによりシェーダを選択する、
    ことを特徴とする請求項１２に記載のシステム。
16. 前記デフォルトシェーダが、前記交差テスト結果に関連する光線のタイプに基づいて決定される、
    ことを特徴とする請求項１５に記載のシステム。
17. 前記シーンがオブジェクトで構成され、前記システムが、親光線の前記シーンオブジェクトとの交差テストの結果に基づいて実行すべきシェーダを識別し、前記シェーダの実行中に、前記光線発光コールを通じて交差テストされる子光線の１又はそれ以上と、前記コントリビュートコールを通じて前記バッファに与えられる結果とを受け取るようにさらに構成される、
    ことを特徴とする請求項１１に記載のシステム。
18. 前記プログラミングインターフェイスの前記光線発光コールが、光線起点及び方向を定義するあらゆる情報に加えて任意のデータも受け入れる、
    ことを特徴とする請求項１１に記載のシステム。
19. 前記システムが、前記シーン内における所与の光線の交差テストに基づいて識別されたシェーダが利用できる前記光線の任意のデータを作成する、
    ことを特徴とする請求項１８に記載のシステム。
20. 前記識別されたシェーダが、前記発光コールを使用して、前記シェーダが利用できるようになった前記任意のデータを含む子光線を発光する、
    ことを特徴とする請求項１９に記載のシステム。
21. 前記追加データが、前記発光される光線のタイプ情報を含む、
    ことを特徴とする請求項１８に記載のシステム。
22. 前記タイプ情報が、光線タイプの一覧からの選択を含む、
    ことを特徴とする請求項２１に記載のシステム。
23. 前記任意のデータが、実行すべきコードの１又はそれ以上と、前記第２のシェーダにより実行されるコードへのポインタとを含む、
    ことを特徴とする請求項１８に記載のシステム。
24. 前記任意のデータが、前記子光線が利用できる属性を取得できる元となる光線を識別する参照光線情報を含む、
    ことを特徴とする請求項１８に記載のシステム。
25. 前記任意のデータが、属性情報のために前記第１の光線を参照するいくつかの他の光線の総数を含む、
    ことを特徴とする請求項１８に記載のシステム。
26. 前記プログラミングインターフェイスが、シェーダ間で受け渡されるデータを、前記光線発光コールを使用するようにプログラムされたシェーダから光線データ構造を介して受け入れ、前記データを受け取るように選択される１又はそれ以上のシェーダが、前記光線データ構造を定義された光線を交差テストすることにより決定される、
    ことを特徴とする請求項１１に記載のシステム。
27. 前記プログラミングインターフェイスが、前記光線発光コールに、複数の光線を定義するデータを受け入れるための機能を提供する、
    ことを特徴とする請求項１１に記載のシステム。
28. 前記光線発光コールが、前記複数の光線の光線定義データを、部分的に共有される仕様データ及び部分的に異なる光線データとして受け入れる、
    ことを特徴とする請求項２７に記載のシステム。
29. 前記光線発光コールが、前記発光光線の交差テスト結果に基づいて識別されたシェーダが解釈するための追加データを受け入れて、シェーダにより発光、反射、又は屈折された光に関して前記シェーダの挙動を修正する、
    ことを特徴とする請求項１１に記載のシステム。
30. 前記光線発光コールが、該光線発光コールを通じて提供されたデータにより指定される光線束間で分散される重み係数を受け入れる、
    ことを特徴とする請求項１１に記載のシステム。
31. 前記光線発光コールが、少なくとも部分的にパラメータにより光線を定義する、
    ことを特徴とする請求項１１に記載のシステム。
32. シェーディングインターフェイス法を実施するためにコンピュータ上で実行されるコンピュータ可読命令を記憶するコンピュータ可読媒体であって、前記シェーディングインターフェイス法が、
    ３−Ｄシーン内で交差テストされる光線の起点及び方向を含む第１のシェーダからのデータを受け入れるステップと、
    前記光線に関連する追加データを前記第１のシェーダから受け入れるステップと、
    前記追加データが、前記光線の交差テストの結果に基づいて識別された第２のシェーダに通信されるようにするステップと、
    を含むことを特徴とするコンピュータ可読媒体。
33. 前記光線を交差テストした結果が、前記光線により交差されたプリミティブの指示を含み、該指示が前記第２のシェーダに関連付けられる、
    ことを特徴とする請求項３２に記載のコンピュータ可読媒体。
34. 前記コンピュータ可読媒体が、前記第２のシェーダのためのコンピュータ実行可能コードを記憶し、前記第２のシェーダのための前記コードが、前記追加データを解釈して、前記第２のシェーダにより発光、反射、又は屈折された光に関して前記第２のシェーダの挙動を修正する、
    ことを特徴とする請求項３２に記載のコンピュータ可読媒体。
35. 前記追加データが、前記第２のシェーダが使用するシェーディングコード、又は前記第２のシェーダが使用するコードへのポインタを含む、
    ことを特徴とする請求項３２に記載のコンピュータ可読媒体。
36. 前記追加データが、前記第２のシェーダの完了後に実行すべきシェーディングコード、又はシェーディングコードへのポインタを含む、
    ことを特徴とする請求項３２に記載のコンピュータ可読媒体。
37. 前記第２のシェーダが、前記第２のシェーダのための閉じた状態のバッファ位置に直接書き込むためのコンピュータ実行可能コードを含む、
    ことを特徴とする請求項３２に記載のコンピュータ可読媒体。

Images