JP4761492B2 - Colorless lighting in graphic systems - Google Patents

Description

である。ここで、Ｃ_nはライティング計算パイプラインの出力を規定し、Ｃ_materialは材質の色を規定し、Ａ_cはアンビエント色を規定し、Ｌ（ｃ）はライティング拡散または鏡面成分を規定し、Ａは距離減衰を規定する。この計算はＲＧＢの３つ組を演算する。なぜなら、本実施例におけるライティング計算パイプライン３２２は２つのこのようなライティング計算を並列に行い得るためである。この並列演算特徴のため、ライティング演算のうちの一方をあるオブジェクトのための無色ライティング効果用に用いながら、他方のライティング演算を同じオブジェクトの有色ライティング効果のために用いることができる。並列演算特徴は、漫画的なライティング効果を有するシェード付けされたポリゴン表面を生成するのに、そのような漫画的なライティング効果を有さないシェード付けされたポリゴン表面を生成するのと同じだけの処理時間しかかからないという意味において、漫画的なライティングなどの効果を「自由」にする。本実施例において、ライティング演算パイプライン３２２によって生成されるＣ_n値は、正でも負でもよい。負のライティングの場合は、バックライトライティングおよびその他の面白い効果が可能になる。
【００５７】
本実施例において、ライティング演算パイプライン３２２の出力Ｃｎは、整数アキュムレータ３２４によって累積される。本実施例において累積された出力は、変換ブロック３０８によって浮動小数点に変換され、テクスチャ座標としてテクスチャマッピング動作のためにテクスチャユニット５０２に供給される。本実施例は、テクスチャマッピング動作３０６の一部としてテクスチャフィルタリングを提供し得る。アプリケーションのプログラマは、ライティング計算３０２をテクスチャ座標を生成するとき、選択されるテクスチャフィルタリングモードに関して注意しなければならない。本実施例におけるｓ軸およびｔ軸は独立のファクタのために用いられるにも関わらずある種のテクスチャフィルタリングは両方の軸に同時に適用されるという事実に起因して、問題が起こりえる。これを回避する１つのやり方は、隣接するｔ値間の補間が最終出力に影響を及ぼさないことを確実にするために、テクスチャマップ内において各エントリをｔ軸に沿って複製することである。この結果、ｔの隣接する値に対する１次元テクスチャフィルタリングは同一になる。複数レベルのディテールをともなうミップマップフィルタリングも実行し得るが、これは、与えられた２Ｄテクスチャマップ中の１Ｄテクスチャの数を減らすようにも働き得る。
【００５８】
本実施例において、ライティング計算３０２の色値をテクスチャ座標に変換する方法に起因して、別の複雑さが発生する。例示の実施形態においてライティング計算３０２により生成される色値は、０〜２５５の範囲の８ビット整数である。変換ブロック３０８は、この整数値を２５５で除算することによって浮動小数点数値に変換する。しかし本実施例において、この値はテクスチャサイズで乗算されることによってテクスチャ座標に変換される。このプロセスは、１Ｄテクスチャを選択するためのテクスチャ座標に対してアプリケーションのプログラマが細心の注意を払わなければならないことを意味する。テクスチャサイズが２５６としかつＧＸ＿ＮＥＡＲテクスチャフィルタリングと仮定すると、これは以下のようにマッピングされる。
【表１】

【００５９】
変換プロセスのため、座標値１２８はスキップされ、色値２５４および２５５は同じ座標値にマッピングされる。テクスチャサイズが２５６としかつＧＸ＿ＬＩＮＥＡＲフィルタリングと仮定すると、以下のようなマッピングとなる。
【表２】

【００６０】
例示の実施形態においてテーブルＩＤを色値に変換するために、ｎ＊２を用いても安全である。しかし、１Ｄテクスチャを２Ｄテクスチャ内において単純でない方法で格納しなければならない。ｎ＝０のテーブルは座標０（のみ）に格納しなければならず、ｎ＝１からｎ＝６３のテーブルはｎ＊２−１およびｎ＊２に格納しなければならず、ｎ＝６４からｎ＝１２７のテーブルはｎ＊２およびｎ＊２＋１に格納しなければならない。座標１２７は、この特定の実施形態においては通常はアクセスされないため空のままにしておいてもよい。他の実施形態ではこの問題をまったく回避できるか、あるいは異なる変換問題を有する。
【００６１】
より詳細な変換ユニット３００例の説明
図１４〜２２はさらなる例として、ライティング計算３０２に用いられるライティングパイプラインを含む変換ユニット３００のより詳細な実施形態を示す。このシステム５０の実施例において、変換ユニット３００はハードウェアにおいてライティングを頂点毎の計算としてサポートする。このことは、ライティングされている頂点毎に色（ＲＧＢ）値が演算され得ること、そしてこれらの色が、各ライティングされたトライアングルの表面にわたって線形補間されることができることを意味する（グローシェーディングとして公知）。本実施例における変換ユニット３００は、拡散局所スポット光をフルにサポートし、また無限鏡面ライティングもサポートする。
【００６２】
本例における変換ユニット３００は、拡散減衰をサポートする。これは、オブジェクトの前面が側面よりも明るく、かつ背面が最も暗くなることが可能であることを意味する。変換ユニット３００は、頂点の法線をサポートすることにより、拡散減衰を提供する。各頂点について、頂点の法線をその頂点と光の位置との間のベクトルに対して比較する。
【００６３】
本実施例の変換ユニット３００はまた、局所光をサポートする。局所光は、その世界の中で位置を有し、また方向も有する可能性がある。各光は位置を有するように定義される。各頂点の位置および光の位置を用いて、変換ユニット３００は頂点毎の距離減衰を行うことができる。これはオブジェクト上で輝く光の輝度を、オブジェクトが光から遠ざかるにつれて減少させることが可能であることを意味する。
【００６４】
本実施例における変換ユニット３００はまた、指向性ライティングをサポートする。サポートは、非指向性光から弱指向性効果、そして高指向性スポット光にまでわたる。これらの効果は角度減衰によってサポートされる。従って、光の「ビーム内」に直に存在する頂点を、ビームの外側あるいは光の後ろに存在する頂点よりも明るくさせることが可能である。
【００６５】
局所拡散光は、距離減衰および角度減衰の両方を受けることができる。適切なライティング式をプログラムすることにより、アプリケーションのプログラマは、減衰値を出力色またはアルファとして（あるいはテクスチャ座標生成の場合にはテクスチャ座標として）得ることが可能である。
【００６６】
例示の実施形態において、変換ユニットは８個の物理光をサポートする。アプリケーションのプログラマは、各光の減衰パラメータ、位置、方向、および色を記述することができる。アプリケーションのプログラマはまた、ライティング式の結果を累積する、最大４個の物理カラーチャネルを制御することができる。光をチャネルと対応付けることにより、アプリケーションのプログラマは頂点毎の複数の光の効果を加算するか、あるいはそれらを後でテクスチャ環境ユニット６００において結合するかを選択することができる。テクスチャ環境ユニット６００が利用可能なチャネル数は、アプリケーションのプログラマによって設定される。場合によっては（例えばカラーチャネルを用いてテクスチャ座標を生成するとき）、ライトチャネルは演算されるが色または不透明度としては出力されない。前述のように、変換ユニット３００は２つのカラーチャネルを同時に計算するようにパイプライン化されているが、１つのカラーチャネルだけをブレンディングのために直接テクスチャ環境ユニット６００に供給してもよい。その他のカラーチャネルは、テクスチャ座標の形でテクスチャユニット５００に提供され得る。
【００６７】
各カラーチャネルは、カラーソースの選択において減衰を可能にする。光マスクが、最大８個の光をチャネルと対応付ける。図１４のチャネルを参照し、最大８個の異なる光を２つのカラーチャネルおよび２つのアルファチャネルのうちの任意のものと対応付けることにより、一方がテクスチャ座標に変換され得る２つの独立な出力が提供される例を示している。
【００６８】
図１４に示すように、本実施例における変換ユニット３００は２つのＲＧＢＡ色（色０および色１）を生成する。各出力色はＲＧＢ用に１つおよびアルファ用に１つの２つのライティング関数を有し、ポリゴン毎頂点毎につき計４つのライティング関数を有する。４個のそのような光は、例えばテクスチャリングなどの様々なライティング効果を可能にする。各関数は、変換ユニット３００が保持するグローバルアンビエント色および８個の光の状態に基づく、動作中の材質の色を含み得る。これらの式は拡散、鏡面、およびスポット光減衰を可能にする。ライティングデータパスは、好適な実施例においては局所拡散スポット光について最適であるように設計されるが、同じデータパスでテクスチャ型ライティングのための鏡面ハイライトおよび／または減衰係数を生成することも可能である。上述のように、光の色を用いてテクスチャ座標を生成することもできる。
【００６９】
ライティング計算の例
変換ユニット３００によって実行されるライティング式の例は以下の通りである。
【数２】

【００７０】
本実施例において、材質およびグローバルアンビエント色はレジスタから得てもよく、あるいはコマンドプロセッサ２００から頂点色の形で得てもよい。８個より多くの光を要求するアプリケーションは、メインプロセッサ１１０上で実行するソフトウェアに基づいて、結果が頂点色のうちの１つになるように追加的な光からの照度を演算して、その頂点色を用いるようにアンビエントソースレジスタを設定し得る。所望であれば、メインプロセッサ１１０がソフトウェアを用いてライティング計算のいずれかまたは全部を演算し、結果得られたこれらの演算出力を頂点色の形として、テクスチャ座標へ変換されるために変換ユニット３００に供給することが可能である。あるいは、メインプロセッサは演算されたテクスチャ座標を、テクスチャマッピングのためにテクスチャユニット５００に渡してもよい。
【００７１】
「ＬｉｇｈｔＦｕｎｃ」パラメータを無効にすることにより、材質の色が変更されずに変換ユニット３００を通過する。これを用いて、無色ライティング関数出力に応答して複数の１Ｄテクスチャのうちのいずれをテクスチャマッピング動作に用いるかを、メインプロセッサ１１０がアプリケーションプログラムのソフトウェア制御に基づき直接選択することを、可能にすることができる。
【００７２】
各ライティング関数において、利用可能な８個の光のいずれかまたは全部が許可され得る。光毎の照度の和は本実施例では［−１，１］にクランプされ、グローバルアンビエント項を加える前に整数２の補数に変換される。照度の総計が［０，１］にクランプされるため、材質は本実施例におけるライティングを通じては明るくなり得ない。もしこの効果が望まれる場合は、光の色を材質の色で予め乗算し、式中の材質の色を１．０に設定してもよい。他の実施形態例において、ライティングを通じて材質をより明るくすることを可能にするための他の構成が提供され得る。
【００７３】
本実施形態において、結果が単色でも十分な場合には、アルファ式を用いることができる。その結果として得られるアルファ値は、本実施例のテクスチャ環境ユニット６００ににおいて、他のＲＧＢおよびアルファ値と組み合わせられることができる。例えば、チャネル０色の色出力に拡散結果を出し、色０チャネルのアルファ出力に鏡面結果を出し、かつテクスチャ環境ユニット６００によって拡散色をテクスチャ色で乗算し、テクスチャ環境ユニット６００内の１つのステージで（白色などの）鏡面ハイライトを加えることが可能である。
【００７４】
本実施例の拡散減衰関数において、コマンド（Ｎ・Ｈ）［０，１］クランプ以上で柔軟性がもたらされる。拡散プロパティを有さないあるいは未クランプのままにされたライティング式については減衰が無効にされ得る。未クランプの内積は、光に基づくテクスチャ生成で照度を１８０°制御することを可能にする。本実施例においては照度はクランプされるため、ｃｏｌｏｒ_cおよびａｍｂ_cを適切に用いることにより、符号付きライティング関数を適切にスケーリングおよびバイアスし得る。本実施例において、１つのライティング式において使用できる拡散減衰関数が、３例提供される。すなわち、
【数３】

である。
【００７５】
本実施例における角度減衰ロジックは、光−方向ベクトルおよび光−頂点ベクトルの内積に基づく２次多項式を演算する。二乗項および線形項を外挿することにより、鋭角的なフォールオフが得られる。スポット光角度の外側の角度について外挿により負の値が発生するのを避けるため、クランピングを用いる。別の２次多項式の逆関数を用いることにより、レンジ減衰を行うことができる。距離値ｄは、頂点から光の位置までのベクトルの長さである。距離減衰だけの光の式をテクスチャ型の光に用いることによって、投影あるいはその他のテクスチャの距離に基づいた照度フォールオフを、シミュレートすることができる。
【００７６】
この同じロジックを、平行光源についての一般の鏡面減衰（Ｎ・Ｈ）^Sを近似するために用いることができる。光−頂点ベクトルおよび光−方向ベクトルのかわりに、法線および半角ベクトルをそれぞれ用いてもよい。ライティング関数において減衰を無効にすることにより、拡散および鏡面式の両方において非減衰の点（例えば全方位の）光源を用いることが可能になる。本例において、光の角度減衰係数を鏡面式に用い、そして拡散式において減衰をオフにしてもよい。本実施例の鏡面式および拡散式は、本実施例において変換ユニット３００内ではなくテクスチャ環境ユニット６００内で組み合わせられるが、他の実施形態が可能である。
【００７７】
例示の減衰関数のさらなる詳細は以下の通りである。
【数４】

【００７８】
変換ユニット３００のブロック図の実施形態例
図１５は、システム５０の変換ユニット３００の実施形態例のブロック図である。本実施例における変換ユニット３００は、
・トップオブパイプライン部３３０
・光部３３２
・ボトムオブパイプライン部３３４
の３つの主要部を有する。
【００７９】
本実施例におけるトップオブパイプライン部３３０は、光部３３２、コンテキスト行列格納３３６、入力ＦＩＦＯバッファ３３８内積ユニット３４０、投影ブロック３４２、テクスチャドット２ブロック３４６、クリッピング検出器３４８、およびバイパスＦＩＦＯブロック３５０を有する。本実施例において、トップオブパイプライン（ＴＯＰ）部３３０は、以下の例示的な関数を実行する。
・頂点変換（３つの内積）
・法線変換（３つの内積）
・テクスチャ変換（テクスチャに対して２または３つの内積）
・投影変換（単純化３つの内積）
そして光部３３２は以下のカラーチャネル関数を実行する。
・カラーチャネル０拡散演算（１つの内積Ｎ・Ｌ）
・カラーチャネル０拡散演算（光毎につき１つの内積Ｌ²）
・カラーチャネル０拡散演算（１つの内積Ｎ²）
【００８０】
さらに入力ＦＩＦＯは、例えば以下の情報を特定する頂点毎の頂点記述子を受け取る。
・図形情報ＸＹＺ、
・法線ベクトル情報Ｎ_X、Ｎ_Y、Ｎ_Z
・頂点毎につきＲＧＢＡ色０
・頂点毎につきＲＧＢＡ色１
・従法線ベクトルＴ_X、Ｔ_Y、Ｔ_Z
・従法線ベクトルＢ_X、Ｂ_Y、Ｂ_Z
・テクスチャ０データＴ₀、
・テクスチャ１からｎデータＳ_n、Ｔ_n
【００８１】
適切な頂点毎の情報が光部３３２に供給されて、ライティング演算を可能にする。
【００８２】
図１５に示す実施例における光部３３２は、ライティングパラメータメモリ３５２、法線メモリ３５４、および光データパス３５６を含んでいる。
【００８３】
光パラメータメモリ３５２は、光データパス３５６が使用する様々な光パラメータを記憶する。このように、光パラメータ３５２は様々なライティング情報（例えば光ベクトル、光パラメータなど）の全てを保持する。本実施例において、グローバル状態およびアンビエント状態の両方がこのメモリに記憶される。本実施例において各ワードは３２ビットで書かれているが、上位２０ビットのみが保持される。本実施例において、各位置は３ワード幅を有し、最小ワード書き込みサイズは３ワードである。以下に光パラメータメモリ３５２の内容例を示す。
【表３】

【００８４】
本実施例における光部３３２の全体図を図１６に示す。簡潔に言えば、光部３３２は以下の局所ライティング演算を行う。
【数５】

これは、以下の頂点毎の局所光ベクトル演算
【数６】

を必要とする。この後、
【数７】

を演算する必要がある。
【００８５】
このように、拡散減衰計算は、光ベクトルおよび視点空間法線を必要とする。例示の実施形態において、０へのクランピングは内部フラグを条件としてもよい（例えば１．０にクランプされてもまったくクランプされなくてもよい。）。拡散光が負の内積を有することを許してもよい。変換内積ユニットが幾何学的な視点空間変換を演算する一方で、ライティング内積ユニットが視点空間法線を演算してもよい。そして、ライティング内積ユニットががＮ・Ｌ、Ｌ²およびＮ²内積を演算し得る。この後、本実施例では結果を正規化することにより、正規化光ベクトル法線情報を提供する。正規化後、正規化の中間結果（例えば距離の二乗と距離とコサインＮ・Ｌと）を用いて正規化係数ならびに減衰式を演算する。そして、光アンビエントベクトルを乗算する。得られた３つ組は、光毎の減衰された拡散成分である。これを２の補数整数に変換し、得られた３つの値を整数アキュムレータに累積する。このアキュムレータは、アンビエント項と他の光からの任意の他の拡散項を加算する。最終的な和が頂点毎の色である（本実施例においては０から２５５にクランプされた８ビットＲＧＢフォーマット）。
【００８６】
図１７は、図１６に示したベクトルドット／Ｍａｄｄブロック３５７のブロック図の例を示す。Ｎおよび他の全ての内積を演算するために同じ内積ユニットを用いると、各光が同じデータパス要素を複数回再使用しなければならないため、性能がやや劣るかもしれず、光のスケジューリングが難しくなる。これは、複雑な制御問題につながる。設計を単純化するためには、第２の制限された内積ユニットを実施することで様々な演算を分離してもよい。第１の内積ユニットが変換法線を演算し、他方の内積ユニットが頂点変換を演算してもよい。次にベクトル加算が局所ライティングについての光ベクトルを演算し得る。第２の内積ユニットは、（鏡面光について）Ｎ²、Ｌ²、Ｎ・Ｌ、Ｎ・Ｈを演算し得る。本実施例においてこれは、フィードバックのない完全にパイプライン化された態様で実現することができる。図１７を参照のこと。
【００８７】
図１８は、図１６に示す正規化器３６０の実施形態の一例を示す。いったんライティングベクトル値が演算されれば、本実施例は結果を正規化し、減衰を演算する。本実施例の正規化器３６０は、以下の入力を受け付け、
・コサイン減衰：Ｌ・Ｄｉｒ、１／ｓｑｒｔ（Ｌ）
・距離減衰：Ｌ²、Ｌ
・拡散係数：Ｎ・Ｌ、Ｎ²、Ｌ²、
そして図１８に示す例示の正規化器３６０によって行われる以下のステップを用いて距離減衰を演算する。
１．Ｋ₂ｄ²を演算
２．Ｋ₂ｄ² _+K0を演算
３．ｄを演算
４．Ｋ₁ｄを演算
５．Ｄ₂Ｄ²＋Ｋ₁ｄ＋ ＫＯを演算
６．１／（Ｋ₂ｄ²＋Ｋ₁ｄ＋Ｋ０）を演算
【００８８】
図１９は、距離減衰ユニット３６２の一例を示す。例示の距離減衰器の実施形態３６２は、以下のステップ例を用いてコサイン減衰を演算する。
１．Ｃｏｓ＝Ｃｌａｍｐ０（Ｌ．Ｌｄｉｒ）を演算
２．Ｃｏｓ₂を演算
３．Ａ₂Ｃｏｓ²を演算
４．Ａ₁Ｃｏｓを演算
５．Ａ₁Ｃｏｓ＋Ａ０を演算
６．Ａ₂Ｃｏｓ²＋Ａ₁Ｃｏｓ＋Ａ０を演算
７．Ｃｌａｍｐ＿０（Ａ＋２＋Ｃｏｓ²＋Ａ₁Ｃｏｓ＋Ａ０）を演算
【００８９】
図２０は、以下を演算する光スケーラ３６４の実施形態の一例を示す。
・１／ｓｑｒｔ（Ｎ²）
・１／ｓｑｒｔ（Ｌ²）
・Ｎ・Ｌ（ｓｑｒｔ（Ｎ²）×ｓｑｒｔ（Ｌ²））
【００９０】
ユニットのうちのいくつか（例えば１／ｓｑｒｔおよび乗算器のうちのいくつか）は、図１７〜２０の様々なデータパスの実施例の間で共有することができる。従って、ある実施例がおよそ１８個の乗算器と１０個の加算器を必要とすることもある。反転および１／ｓｑｒｔは、テーブルルックアップまたは単純な１パスニュートン−ラプソン補間器またはその他の何らかのパイプライン補間器を用いて、行うことができる。アルファおよび鏡面書き込み演算は、ライティング式の変更でしかないため、本実施例において追加的なハードウェアをいっさい必要としない。
【００９１】
図２１は、整数アキュムレータ３３６の実施形態の一例を示す。各色について新しい属性が到着したとき、その色が累積される。ある色について全ての光が累積されると、アンビエントが加算され（例えば頂点色ＦＩＦＯから、あるいはレジスタから）、材質の色が乗算される。次に、最終色およびテクスチャ生成の構築により、最終ＲＧＢ／Ａ色が累積／フォーマットレジスタに累積される。色／テクスチャが演算されれば、出力ＦＩＦＯに書き込まれる。制御は以下の一般ガイドラインに従い得る。

【００９２】
図２２は、本実施例において光パイプライン３２２を制御するために用いられるステージ遷移図の一例を示す。調停ロジックが、光データパス内に送出された一連の事象を決定する。本実施例の調停器は、その事象に依存して４サイクル毎あるいは８サイクル毎にしか新しい事象を送出することができない。可能な事象のリストは、
・特定の色／アルファについての光演算
・バンプマップ演算
を含む。
【００９３】
上記の事象について、調停器は４／８サイクル毎に制御パイプライン内に属性をドロップする。これらの属性の各々は、光パイプライン３２２に入れられる事象のための実行命令を含んでいる。パイプラインの終端において、色／テクスチャが完了しているか否かを決定するために用いられる局所カウントをインクリメントするために、これらの属性が用いられる。
【００９４】
以下に、変換ユニット３００がどのように挙動してどのようにデータおよびテクスチャなどを扱うかを制御するために用いられる、制御レジスタの例を示す。
【表４】

【００９５】
アプリケーションプログラミングインターフェースの例
以下に、一実施形態例におけるライティング関数からのテクスチャ座標生成に関連する、ＡＰＩ呼び出しの例をいくつか挙げる。
【００９６】
ＧＸＳｅｔＴｅｘＣｏｏｒｄＧｅｎ
説明
この関数を用いて、テクスチャ座標がどのように生成されるかを指定する。出力テクスチャ座標は通常は入力属性（位置、法線、またはテクスチャ座標）の何らかの変換の結果である。頂点毎のライティング計算の出力カラーチャネルからも、テクスチャ座標を生成することができる。
【００９７】
Ｃ言語シンタックスにおいて、テクスチャ座標生成関数は以下のようなものになる。
ｄｓｔ＿ｃｏｏｒｄ＝ｆｕｎｃ（ｓｒｃ＿ｐａｒａｍ， ｍｔｘ）；
【００９８】
ＡＰＩ関数呼び出し例の用法の一例は、

である。
【００９９】
ＧＸＳｅｔＶｔｘＤｅｓｃによって設定される現在の頂点記述子は、グラフィックスプロセッサへのデータ入力を記述する。ＧＸＳｅｔＴｅｘＣｏｏｒｄＧｅｎを用いることにより、アプリケーションは入力データから新しい出力テクスチャ座標を作成することができる。ｄｓｔ＿ｃｏｏｒｄパラメータは、出力テクスチャ座標に名前を与えるために用いられる。このテクスチャ座標は、ＧＸＳｅｔＴｅｖＯｒｄｅｒを用いてテクスチャに結びつけることができる。関数ＧＸＳｅｔＮｕｍＴｅｘＧｅｎｓは、ＧＸＳｅｔＴｅｖＯｒｄｅｒ関数で利用可能なＧＸ＿ＴＥＸＣＯＯＲＤ０から開始する連続する複数のテクスチャ座標を指定する。
【０１００】
入力テクスチャ座標は、テクスチャ座標生成ハードウェアを通る。ＧＸＩｎｉｔは、ハードウェアを（このＡＰＩを呼び出して）初期化することにより、ＧＸ＿ＩＤＥＮＴＩＴＹ行列によって変換される全てのテクスチャ座標が、入力座標が変更されずにテクスチャハードウェアを通されたかのように見えるように変換される。
【０１０１】
列挙ＧＸＴｅｘＭｔｘは、ｍｔｘとして供給され得るテクスチャ行列名のデフォルトのセットを定義する。行列名は実際には、マトリクスメモリ中のロードされた行列の第１行目を示す行アドレス（１行につき４フロート）である。モデルビュー行列およびテクスチャ行列は、本実施例においてマトリクスメモリを共有する。
【０１０２】
例：頂点ライティング計算からのテクスチャ座標生成
このタイプのテクスチャ座標生成は、漫画的なライティング効果を創出するために用いることができる。カラーチャネル結果のうちの１つをテクスチャ座標に変換する。
【０１０３】
ＧＸ＿ＴＧ＿ＳＲＴＧ
座標ｓはチャネルの８ビット赤成分と等しく設定される。座標ｔはカラーチャネルの８ビット緑成分と等しく設定される。漫画的なライティングにおいて座標ｓは光の強度を表し、強度を色に変換するために任意の１Ｄテクスチャルックアップに入力される。座標ｔは材質の色を表すために用いられ、２Ｄテクスチャから１Ｄテーブルを選択するために用いられる。ＧＸ＿ＴＧ＿ＳＲＴＧ関数を用いて生成されるテクスチャ座標は、変換（ＧＸ＿ＴＧ＿ＭＴＸ２×４またはＧＸ＿ＴＧ＿ＭＴＸ３×４）およびバンプマップ関数（ＧＸ＿ＴＧ＿ＢＵＭＰ０−３）によって生成される任意の座標の後に生成されなければならない。
【０１０４】
１Ｄの強度−色テーブルの配列を表すテクスチャは、本実施例において注意深く構築されなければならない。各テーブル（行）は二重に記述されなければならない。座標ｓおよび座標ｔは８ビット色から生成されるため、２５６×２５６の最大テクスチャを用いることができる。このテクスチャサイズにおいて、１２７個のテーブルが利用可能である（（２５６−１）／２）。
【０１０５】
２行テーブル中で正しく中央に位置される座標ｔを作成する、緑チャネル色を生成するためのルールの一例は、

である。
【０１０６】

【０１０７】
機能順序付け
本実施例において、テクスチャ座標は機能順に生成される。すなわち、まず全ての変換（ＧＸ＿ＴＧ＿ＭＴＸ２×４またはＧＸ＿ＴＧ＿ＭＴＸ３×４）、次にバンプマップ（ＧＸ＿ＴＧ＿ＢＵＭＰ０〜３）、そして次にライティングからのテクスチャ座標生成（ＧＸ＿ＴＧ＿ＳＲＴＧ）である。
【０１０８】
ＧＸＳｅｔＮｕｍＴｅｘＧｅｎｓ
説明
この関数は、テクスチャ環境（ＴＥＶ）ステージにおいて生成され利用可能であるテクスチャ座標の数を設定する。テクスチャ座標は、ＧＸＳｅｔＴｅｘＣｏｏｒｄＧｅｎにより記述される入力データから生成される。生成されたテクスチャ座標は、ＧＸＳｅｔＴｅｖＯｒｄｅｒを用いて特定のテクスチャおよび特定のテクスチャ環境（ＴＥＶ）ステージにリンクされる。
【０１０９】
ＧＸ＿ＴＥＸＣＯＯＲＤ０から開始して連続する複数のテクスチャ座標を生成することができる。最大８個のテクスチャ座標を生成し得る。ｎＴｅｘＧｅｎｓが０に設定されると、テクスチャ座標は生成されない。この場合、少なくとも１つのカラーチャネルが出力されなければならない。ＧＸＳｅｔＮｕｍＣｈａｎｓを参照のこと。
引数
ｎＴｅｘＧｅｎｓは生成されるテクスチャ座標の数である。
用法例
ｖｏｉｄ ＧＸＳｅｔＮｕｍＴｅｘＧｅｎｓ（ｕ８ ｎＴｅｘＧｅｎｓ）；
【０１１０】
ＧＸＳｅｔＮｕｍＣｈａｎｓ
説明
この関数は、テクスチャ環境（ＴＥＶ）ステージに出力されるライティングカラーチャネルの数を設定する。カラーチャネルは、頂点毎のライティング効果を演算するために用いられるメカニズムである。カラーチャネルは、ＧＸＳｅｔＣｈａｎＣｔｒｌを用いて制御される。カラーチャネルは一般に、特定のテクスチャ環境（ＴＥＶ）ステージにリンクされる。
【０１１１】
この関数は基本的に、ラスタライズされる頂点毎の色の数を定義する。ｎＣｈａｎｓが０に設定された場合、少なくとも１つのテクスチャ座標が生成されなければならない。ＧＸＳｅｔＮｕｍＴｅｘＧｅｎｓを参照。ｎＣｈａｎｓが１に設定されると、チャネルＧＸ＿ＣＯＬＯＲ０Ａ０がラスタライズされる。ｎＣｈａｎｓが２（最大値）に設定されると、ＧＸ＿ＣＯＬＯＲ０Ａ０またはＧＸ＿ＣＯＬＯＲ１Ａ１がラスタライズされる。
引数
ｎＣｈａｎｓはラスタライズされるカラーチャネルの数である。
用法例
ｖｏｉｄ ＧＸＳｅｔＮｕｍＣｈａｎｓ（ｕ８ ｎＣｈａｎｓ）；
【０１１２】
ＧＸＳｅｔＣｈａｎＣｔｒｌ
説明
この関数は、あるカラーチャネルについてのライティングコントロールを設定する。カラーチャネルは、対応して１つ以上（最高８個）の光を有することができ、これはｌｉｇｈｔ＿ｍａｓｋを用いて設定される。ｄｉｆｆ＿ｆｎおよびａｔｔｎ＿ｆｎパラメータは、このチャネルに対応付けられた全ての光についてのライティング計算を制御する。ａｍｂ＿ｓｒｃおよびｍａｔ＿ｓｒｃは、入力ソース色がレジスタ色由来であるか頂点色由来であるかを選択するために用いられ得る。チャネル使用可能がＧＸ＿ＦＡＬＳＥに設定されると、材質のカラーソース（ｍａｔ＿ｓｒｃにより設定される）はチャネルの出力色としてそのまま渡される。チャネル使用可能がＧＸ＿ＴＲＵＥに設定されると、出力色は他のコントロールの設定（すなわちライティング式）に依存する。ＧＸＩｎｉｔは、全てのチャネルについての許可をＧＸ＿ＦＡＬＳＥへに設定する。ＧＸＳｅｔＣｈａｎＣｔｒｌはライティングチャネルをコンフィギュレーションする。チャネル演算の結果を出力するためには、関数ＧＸＳｅｔＮｕｍＣｈａｎｓを用いる。
【０１１３】
チャネルＧＸ＿ＣＯＬＯＲ０およびＧＸ＿ＡＬＰＨＡ０はライティングのために別々に制御されるが、これらは１つのＲＧＢＡ色（実効的にＧＸ＿ＣＯＬＯＲ０Ａ０）として一緒にラスタライズされる。同じことがＧＸ＿ＣＯＬＯＲ１およびＧＸ＿ＡＬＰＨＡ１にも言え、これらは実効的にＧＸ＿ＣＯＬＯＲ１Ａ１としてラスタライズされる。グラフィックスハードウェアには色用ラスタライザが１つしかないため、アプリケーションは、テクスチャ環境ユニット（Ｔｅｖ）内の各ステージに対してどの色をラスタライズするかを選択する。これはＧＸＳｅｔＴｅｖＯｒｄｅｒ関数を用いて達成される。
【０１１４】
チャネルＧＸ＿ＣＯＬＯＲ１Ａ１において頂点色を用いるために、頂点毎につき２つの色が供給される。すなわち、現在の頂点記述子中でＧＸ＿ＶＡ＿ＣＬＲ０およびＧＸ＿ＶＡ＿ＣＬＲ１の両方が許可される。現在の頂点記述子中でＧＸ＿ＶＡ＿ＣＬＲ０かＧＸ＿ＶＡ＿ＣＬＲ１かのいずれか一方のみが許可される場合、頂点色はチャネルＧＸ＿ＶＡ＿ＣＯＬＯＲ０Ａ０に渡される。
【０１１５】
ａｍｂ＿ｓｒｃがＧＸ＿ＳＲＣ＿ＲＥＧに設定されると、ＧＸＳｅｔＣｈａｎＡｍｂＣｏｌｏｒにより設定される色がアンビエント色として用いられる。ｍａｔ＿ｓｒｃがＧＸ＿ＳＲＣ＿ＲＥＧの場合、ＧＸＳｅｔＣｈａｎＭａｔＣｏｌｏｒにより設定される色が材質の色として用いられる。
引数
【表５】

【０１１６】
例：局所拡散スポット光
本例では、どのようにＧＸ＿ＣＯＬＯＲ０チャネルをコンフィギュレーションして頂点色を局所拡散スポット光でライティングするかを示す。関数ＧＸＩｎｉｔＬｉｇｈｔＰｏｓおよびＧＸＩｎｉｔＬｉｇｈｔＤｉｒを用いて、光の位置および方向を初期化する。光の位置および方向は、光オブジェクトの設定以前に視点空間に変換されているものとする。拡散ライティングを許可するために、ｄｉｆｆ＿ｆｎがＧＸ＿ＤＦ＿ＣＬＡＭＰに設定される。これはスポット光であるため、ａｔｔｎ＿ｆｎがＧＸ＿ＡＦ＿ＳＰＯＴに設定される。スポット光の角度減衰関数のタイプは光で決定され、ここでＧＸＩｎｉｔＬｉｇｈｔＳｐｏｔにより設定される。距離減衰関数がＧＸＩｎｉｔＬｉｇｈｔＤｉｓｔＡｔｔｎを用いて設定される。
【表６】

【０１１７】
例：鏡面光
本例では、鏡面光用にどのようにＧＸ＿ＣＯＬＯＲ０を設定するかを示す。ＧＸＩｎｉｔＳｐｅｃｕｌａｒＤｉｒ関数を、光の方向を設定するために用いる。光オブジェクトの初期化以前に、方向は視点空間に変換されなければならない。鏡面光は無限遠にあると考えられるので、位置パラメータは不要である。角度減衰関数および距離減衰関数を用いて、鏡面光に対する指数減衰関数を近似する。ＧＸＩｎｉｔＬｉｇｈｔＳｈｉｎｉｎｅｓｓを呼び出し、ライティングされた材質がどれくらい輝いて見えるかを制御する（減衰パラメータを設定する）。ａｔｔｎ＿ｆｎがＧＸ＿ＡＦ＿ＳＰＥＣに設定され、鏡面演算を許可する。
【表７】

【０１１８】
例：平行指向性拡散光
ハードウェアは平行指向性拡散光をサポートしないが、ライティングされるべき全オブジェクトから光を非常に遠く置くことにより、「ほぼ平行な」光を得ることは可能である。光の位置がオブジェクトから非常に遠ければ、全ての光線は平行であると見なし得る。
【表８】

【０１１９】
光は拡散チャネルおよび鏡面チャネルの両方に用いることが可能
局所拡散あるいは鏡面のいずれの計算がチャネルにおいて実行されるかは、チャネルコントロールによって決定される。（チャネルに対応付けられた）光のパラメータは、通常はこれらの演算のうちの１つを想定して設定される。例えば、アプリケーションは局所拡散光（拡散チャネルで用いられる）に対しては位置および方向を設定し、鏡面光（鏡面チャネルで用いられる）に対しては方向のみを設定する。しかし、アプリケーションが指向性の拡散光のみを必要とする場合（光の位置が非常に遠いために光の全ての光線が平行であると見なし得る）、同じ光のパラメータを鏡面チャネルと拡散チャネルとの両方に用いることができる。この場合、ＧＸＩｎｉｔＳｐｅｃｕｌａｒＤｉｒを用いて光のパラメータを初期化する。
【０１２０】
例：ライティング前を考慮した頂点毎の光
本例では、頂点毎ＧＸ＿ＶＡ＿ＣＬＲ０として供給される（ＧＸＳｅｔＶｔｘＤｅｓｃを参照）ライティング前の色（例えばアートツールで演算される）を、拡散局所光の結果に対して加える。この例において、以下の式を実施すればよい。
【数８】

【０１２１】
アンビエントスケールは、光がオブジェクトに当たっていない時のライティング前の色の最小量を定義する。ａｍｂ＿ｓｃａｌｅとｄｉｆｆ＿ｓｃａｌｅとの和は１．０に等しいはずなので、オブジェクトが最も明るい光の中にあるとき、頂点色はライティング前の色に等しい。
【０１２２】
材質の色は、頂点毎の色（ライティング前の色）であるようにコンフィギュレーションされる。アンビエント色レジスタはａｍｂ＿ｓｃａｌｅに等しく設定される。光の色はｄｉｆｆ＿ｓｃａｌｅによってスケーリングされる。
【表９】

【０１２３】
例：４つの投影光に対する減衰
この例では、４つの投影テクスチャ光に対してどのように局所光減衰値を計算するかを示す。頂点毎に提供される色はない。材質の色はチャネルマテリアルレジスタから入来し、減衰をパスするように設定される（１．０で乗算）。アンビエント色からの寄与はない。各チャネルは、テクスチャ環境（Ｔｅｖ）ユニットにおいて投影テクスチャを減衰するために用いられ得る。
【表１０】

【０１２４】
ＧＸＳｅｔＣｈａｎＭａｔＣｏｌｏｒ
説明
この関数は、カラーチャネルｃｈａｎに対する材質の色レジスタを設定する。材質の色は、ＧＸＳｅｔＣｈａｎＣｔｒｌにより設定される材質のソースがＧＸ＿ＳＲＣ＿ＲＥＧならば使用される。

【０１２５】
説明に役立つ実例
以下の例におけるアプリケーションプログラミングインターフェース関数および関連するパラメータは、非クランプの拡散ライティング関数を用いてテクスチャ座標を生成するために用いることができ、あるいは、各頂点の光の色の赤色成分において１次元テクスチャマップをルックアップするためのテクスチャ座標を生成するために用いられ、第２のテクスチャ座標が緑色成分によって生成され、２次元テクスチャマップから１次元テクスチャラインを選択するために用いられ得る。
【表１１】

【０１２６】
他の互換性のある実施例
上述のシステム要素５０のうちのいくつかは、上述の家庭用ビデオゲームコンソール構成以外としても実施可能である。例えば、システム５０用に書かれたグラフィックスアプリケーションまたはその他のソフトウェアを、システム５０をエミュレートするなどして互換性を有する異なる構成を持ったプラットフォーム上で実行することができる。もしその別のプラットフォームがシステム５０のハードウェアおよびソフトウェアリソースの一部または全部をうまくエミュレート、シミュレートおよび／または提供することができれば、その別のプラットフォームは、ソフトウェアを首尾よく実行することができる。
【０１２７】
一例として、エミュレータは、システム５０のハードウェアおよび／またはソフトウェア構成（プラットフォーム）とは異なるハードウェアおよび／またはソフトウェア構成（プラットフォーム）を提供し得る。このエミュレータシステムは、アプリケーションソフトウェアが書かれたシステムのハードウェアおよび／またはソフトウェア要素の一部または全部をエミュレートまたはシミュレートする、ソフトウェアおよび／またはハードウェア要素を有し得る。例えば、エミュレータシステムは、システム５０のハードウェアおよび／またはファームウェアをシミュレートするソフトウェアエミュレータプログラムを実行するパーソナルコンピュータなどの汎用のデジタルコンピュータからなっていてもよい。
【０１２８】
汎用デジタルコンピュータのいくつか（例えばＩＢＭまたはマッキントッシュのパーソナルコンピュータおよび互換機）は現在、ＤｉｒｅｃｔＸまたはその他の標準的な３ＤグラフィックスコマンドＡＰＩと適合する３Ｄグラフィックスパイプラインを提供する３Ｄグラフィックスカードを備えている。また、標準的な音声コマンドのセットに基づいて高品質なステレオ音を提供するステレオサウンドカードを備えている場合もある。このようなマルチメディア−ハードウェアを備えたパーソナルコンピュータがエミュレータソフトウェアを実行すれば、システム５０のグラフィックスおよびサウンド性能に匹敵する十分な能力を有し得る。エミュレータソフトウェアは、ゲームプログラマがゲームソフトウェアを書いた対象である家庭用ビデオゲームコンソールプラットフォームの処理、３Ｄグラフィックス、音声、周辺およびその他の機能をシミュレートするように、パーソナルコンピュータプラットフォーム上のハードウェアリソースを制御する。
【０１２９】
図２３は、ホストプラットフォーム１２０１、エミュレータ要素１３０３、および記憶媒体６２上に記憶されたゲームソフトウェア実行可能２値画像を用いたエミュレーション処理の全体例を示す。ホスト１２０１は、例えばパーソナルコンピュータ、ビデオゲームコンソール、または十分な演算能力を有する任意のその他のプラットフォームなどの、汎用あるいは専用のデジタル演算装置であり得る。エミュレータ１３０３は、ホストプラットフォーム１２０１上で稼働し、記憶媒体６２からのコマンド、データおよびその他の情報の、ホストによって処理される形式へのリアルタイム変換を提供するソフトウェアおよび／またはハードウェアであり得る。例えば、エミュレータ１３０３は、システム５０によって実行されることが意図される「ソース」２値画像プログラム命令を記憶媒体６２から取り込み、これらのプログラム命令を、ホスト１２０１によって実行その他の処理を行われ得る対象形式に変換する。
【０１３０】
一例として、ソフトウェアが、ＩＢＭ ＰｏｗｅｒＰＣまたはその他の特定のプロセッサを用いたプラットフォーム上で実行されるように書かれており、ホスト１２０１が異なる（例えばインテルの）プロセッサを用いたパーソナルコンピュータである場合は、エミュレータ１３０３は、１つまたは一連の２値画像プログラム命令を記憶媒体６２から取り込み、これらのプログラム命令を、１つ以上の同等なインテルの２値画像プログラム命令に変換する。エミュレータ１３０３はまた、グラフィックスおよび音声プロセッサ１１４によって処理されることを意図されたグラフィックスコマンドおよび音声コマンドを取り込みおよび／または生成し、これらのコマンドを、ホスト１２０１上において利用可能であるハードウェアおよび／またはソフトウェアグラフィックスおよび音声処理リソースによって処理され得る単数または複数のフォーマットに変換する。一例として、エミュレータ１３０３は、これらのコマンドを、ホスト１２０１の特定のグラフィックスおよび／または音声ハードウェアによって処理され得るコマンドに変換し得る（例えば、標準的なＤｉｒｅｃｔＸ、ＯｐｅｎＧＬ、および／または音声ＡＰＩを用いて）。
【０１３１】
上述のビデオゲームシステムの一部または全ての特徴を提供するために用いられるエミュレータ１３０３には、また、そのエミュレータを用いて実行されるゲームの様々なオプションやスクリーンモードの選択を単純化あるいは自動化するグラフィックスユーザインターフェース（ＧＵＩ）が備えられてもよい。一例において、そのようなエミュレータ１３０３は、また、ソフトウェアが本来意図されたホストプラットフォームに比較して、より高度な機能性をさらに含んでもよい。
【０１３２】
図２４は、エミュレータ１３０２とともに適切に用いられるエミュレーションホストシステム１２０１を示す。システム１２０１は、処理ユニット１２０３およびシステムメモリ１２０５を有する。システムバス１２０７が、システムメモリ１２０５を含む様々なシステム要素を、処理ユニット１２０３に接続する。システムバス１２０７は、メモリバスまたはメモリコントローラを含む数種のタイプのバス構造、周辺バス、および様々なバスアーキテクチャのうちのいずれかを用いた局所バスのうちのいずれでもよい。システムメモリ１２０７は、リードオンリーメモリ（ＲＯＭ）１２５２およびランダムアクセスメモリ（ＲＡＭ）１２５４を有する。パーソナルコンピュータシステム１２０１内の要素間の情報の転送（例えばスタートアップ中など）に役立つ基本的なルーチンを含んだ基本入力／出力システム（ＢＩＯＳ）１２５６が、ＲＯＭ１２５２に格納されている。システム１２０１はさらに、様々なドライブおよび関連するコンピュータ可読性の媒体を有する。ハードディスクドライブ１２０９は、（典型的には固定の）磁気ハードディスク１２１１から読み出し、またこれに対して書き込む。追加的な（可能なオプションである）磁気ディスクドライブ１２１３は、着脱可能な「フロッピー」またはその他の磁気ディスク１２１５から読み出し、また、これに対して書き込む。光ディスクドライブ１２１７は、ＣＤ ＲＯＭまたはその他の光メディアなどの着脱可能な光ディスク１２１９から読み出し、また、いくつかの構成においては、これに対して書き込む。ハードディスクドライブ１２０９および光ディスクドライブ１２１７は、それぞれハードディスクドライブインターフェース１２２１および光ドライブインターフェース１２２５によって、システムバス１２０７に接続されている。そのドライブおよびそれに対応するコンピュータ可読性媒体は、コンピュータ可読性の命令、データ構造、プログラムモジュール、ゲームプログラムおよびパーソナルコンピュータシステム１２０１のためのその他のデータを、不揮発的に記憶する。その他の構成において、コンピュータによりアクセス可能なデータを格納することができる他のタイプのコンピュータ可読性媒体、例えば、磁気カセット、フラッシュメモリカード、デジタルビデオディスク、ベルヌーイ（Ｂｅｒｎｏｕｌｌｉ）カートリッジ、ランダムアクセスメモリ（ＲＡＭ）リードオンリーメモリ（ＲＯＭ）などもまた使用され得る。
【０１３３】
エミュレータ１３０３を含む複数のプログラムモジュールは、ハードディスク１２１１、着脱式磁気ディスク１２１５、光ディスク１２１９、および／またはシステムメモリ１２０５のＲＯＭ１２５２および／またはＲＡＭ１２５４上に記憶され得る。このようなプログラムモジュールは、グラフィックスおよび音声ＡＰＩを提供するオペレーティングシステム、１つ以上のアプリケーションプログラム、その他のプログラムモジュール、プログラムデータおよびゲームデータを含んでもよい。ユーザは、キーボード１２２７、ポインティング装置１２２９、マイク、ジョイスティック、ゲームコントローラ、衛星放送用アンテナ、スキャナなどの入力装置を介して、コマンドおよび情報を、パーソナルコンピュータシステム１２０１に入力し得る。これらおよびその他の入力装置は、システムバス１２０７に接続されたシリアルポートインターフェース１２３１を介して処理ユニット１２０３に接続されることができるが、パラレルポート、ゲームポートファイヤワイヤバスまたはユニバーサルシリアルバス（ＵＳＢ）などの他のインターフェースによって接続されてもよい。また、モニタ１２３３またはその他のタイプの表示装置が、ビデオアダプタ１２３５などのインターフェースを介して、システムバス１２０７に接続される。
【０１３４】
システム１２０１は、インターネットなどのネットワーク１１５２を介して通信を確立するための、モデム１１５４やその他のネットワークインターフェース手段を有し得る。内部でも外部でもよいモデム１１５４が、シリアルポートインターフェース１２３１を介してシステムバス１２３に接続されている。また、システム１２０１が、局所エリアネットワーク１１５８を介してリモート演算装置１１５０（例えば、別のシステム１２０１）と通信することを可能にするために、ネットワークインターフェース１１５６が提供され得る（あるいはこのような通信は、広域ネットワーク１１５２またはダイヤルアップやその他の通信手段などの他の通信パスを介して行われてもよい）。システム１２０１は典型的には、プリンタその他の標準的な周辺デバイスなどの、他の周辺出力デバイスを有し得る。
【０１３５】
一例において、ビデオアダプタ１２３５は、マイクロソフトのＤｉｒｅｃｔＸ７．０または他バージョンなどの標準的な３Ｄグラフィックスアプリケーションプログラマインターフェースに基づいて発せられる３Ｄグラフィックスコマンドに応答して、高速な３Ｄグラフィックスレンダリングを提供する３Ｄグラフィックスパイプラインチップセットを有し得る。また１組のステレオスピーカ１２３７が、従来の「サウンドカード」などのサウンド発生インターフェースを介してシステムバス１２０７に接続されていることにより、バス１２０７によって供給される音声コマンドに基づいて高品質なステレオ音声を生成するためのハードウェアおよび埋め込みソフトウェアサポートを提供する。これらのハードウェア能力は、システム１２０１が、記憶媒体６２に格納されたソフトウェアをプレイするために十分なグラフィックスおよびサウンド速度能力を提供することを可能にする。
【０１３６】
上記参照した全ての文献を、本明細書において参考のために援用する。
【０１３７】
以上、本発明を、最も実用的で好ましい実施形態であると現時点で判断される内容について説明してきたが、本発明は、開示された実施形態にのみ制限されるべきものではなく、反対に記載したクレームの範囲内において、様々に変更、および同等な内容が適用されるものとする。例えば、特定の漫画的なライティングの例を本明細書において開示したが、本発明は漫画的なライティングに限定されるものではなくむしろ、無色ライティングパラメータを用いて達成し得る様々な写実的および非写実的そしてテクスチャ型および非テクスチャ型の、アプリケーションおよび効果を包含することが理解されるであろう。
【図面の簡単な説明】
【図１】対話式コンピュータグラフィックスシステムの一例の全体図である。
【図２】図１の例のコンピュータグラフィックスシステムのブロック図である。
【図３】図２に示す例のグラフィックスおよび音声プロセッサのブロック図である。
【図４】図３に示す例の３Ｄグラフィックスプロセッサのブロック図である。
【図５】図４のグラフィックスおよび音声プロセッサの、論理フロー図例である。
【図６】本発明により提供される高レベル画像生成処理の例を示す図である。
【図７】本発明により提供される無色ライティングパラメータに基づくテクスチャリングを用いたより具体的な画像生成処理の例を示す図である。
【図８】テクスチャ関数の例を示す図である。
【図９】１次元テクスチャマップの例を示す図である。
【図１０】テクスチャマッピング手順の例を示す図である。
【図１１】２次元テクスチャマップの例を示す図である。
【図１２】２次元テクスチャマップのさらなる例を示す図である。
【図１３】ライティングパイプライン実施形態の例を示す図である。
【図１４】光のカラーチャネルとの対応付けの例を示す図である。
【図１５】変換ユニットの実施形態の例を示す図である。
【図１６】ライティングパイプラインの実施形態の例を示す図である。
【図１７】ベクトルドット／加算ユニットの実施形態の例を示す図である。
【図１８】正規化器の実施形態の例を示す図である。
【図１９】距離減衰器の実施形態の例を示す図である。
【図２０】光スケール器の実施形態の例を示す図である。
【図２１】整数アキュムレータの実施形態の例を示す図である。
【図２２】状態遷移図例である。
【図２３】別の互換的な実施例を示す図である。
【図２４】別の互換的な実施例を示す図である。[0001]
BACKGROUND OF THE INVENTION
  The present invention relates to computer graphics, and more particularly to interactive graphics systems such as home video game platforms.ToRelated. More particularly, the present invention relates to improved graphics processing that uses lighting functions to generate parameters that are used later to change color or opacity. More particularly, the present invention relates to a 3D graphics system in which lighting calculations define parameters such as distance or angle applied to additional functions (eg, texturing) and the like.
[0002]
[Prior art]
Many of us have seen movies that include surprisingly realistic dinosaurs, aliens, animated toys, and other fantastic creatures. Such animation is made possible by computer graphics. Using these techniques, computer graphics artists can specify how each object should look and how its appearance should change over time, and the computer models the objects On a display such as a television or computer screen. Based on the position and orientation of each object in the scene, the direction in which light appears to be incident on each object, the surface texture of each object, and other factors, the computer Responsible for performing many of the processes necessary to ensure that it is correctly colored and shaped.
[0003]
Due to the complexity of computer graphics generation, only a few years ago computer-generated 3D graphics was largely limited to expensive dedicated flight simulators, high-end graphics workstations, and supercomputers. . The public has seen some of the images generated by these computer systems in movies and expensive television advertisements, but most of us cannot actually touch the computers that generate the graphics. There wasn't. All of this has changed with the availability of relatively inexpensive 3D graphics platforms such as Nintendo 64® and various 3D graphics cards currently available on personal computers. It is now possible to come in contact with exciting 3D animations and simulations on a relatively inexpensive computer graphics system at home or in the office.
[0004]
It has long been known to perform lighting calculations based on various parameters (eg distance attenuation, angle, beam lighting, etc.) in 3D graphics systems. Traditionally, the results of such lighting calculations have been used to change the color and / or opacity of the displayed object. This is described in various standard references on computer graphics (eg, Chapter 16 (“Illumination and Shading”) of Foley et al., Computer Graphics Principles and Practice (2d. Ed. 1990)); and Moller et al., Section 4.3 or later of Real time Rendering (AK Peters 1999) (“Lighting and Shading”); Rogers et al., Procedural Elements for Computer Graphics (2d Ed. McGraw-Hill 19); eider, et al., Open GL Programming Guide Chapter6 ( "Lighting") of (Addison-Wesley 1993); see and Kovach, Inside Direct3D of (Microsoft Press 2000) Chapter5 ( "Direct3D Vertices and the Transformation and Lighting Pipeline")). For example, techniques known as Gouraud shading and Phong shading change the color of the displayed surface depending on the lighting effect modeled by the lighting formula. As an example, shining a bright spot light on a glossy surface can have the effect of whitening the surface color at the point where the light shines. In conventional graphics systems, this often causes the rasterizer to determine the color of each pixel displayed on the surface of a primitive based on the color of the primitive (often defined per vertex) and the result of the lighting expression. Is achieved.
[0005]
[Problems to be solved by the invention]
One problem faced by graphics system designers in the past has been how to efficiently create non-realistic images such as cartoon characters. Over the years, much of the work in the graphics field has been devoted to creating images as realistic as photographs. Recently, however, there has been interest in non-realistic imaging.
[0006]
One type of non-realistic imaging that has recently gained interest is the process of automating the imaging of cartoon characters. During the heyday of handwritten comics in the 1930s and 1940s, artists created amazing comic characters that dynamically changed from frame to frame. These handwritten comics have become the standard for comic rendering in many ways. The comic was not intended to look real. Conversely, comics were designed to look like caricatures. For example, in such comics, a person's face may have a rosy cheek with a pink or reddish pink shade on a white spot. As the artist colored each frame by hand, the color of the cheeks could change dynamically as the character moved through the scene. Such dynamic effects are attractive to watch and add interest to the cartoon image.
[0007]
Unfortunately, the art of handwritten comics in the 1930s and 1940s was very time consuming and expensive. And now people want to use video games and computer games to come in contact with cartoon characters. Although video games have been successful for years in dynamically rendering cartoon characters interactively, they have not achieved the fine arts of handwritten art in modern-day handwritten cartoons. Although much research has been done on high-end type systems for the creation of comics and other non-realistic images, further improvements are possible and desirable.
[0008]
The present invention provides improvements in non-photorealistic and other imaging effects that can be achieved using low cost graphics systems such as home video game platforms or personal computer graphics accelerators.
[0009]
[Means for Solving the Problems and Effects of the Invention]
According to one aspect provided by the present invention, parameters other than color are generated using a type of lighting function typically used to illuminate objects in a scene. Such parameters are used to change the color or opacity of the object.
[0010]
According to another aspect provided by the present invention, the lighting calculation provides a conventional color component output by performing per-vertex lighting. The color component output is input to a texturing function that processes the color component as a colorless parameter. The output of the texturing function provides a visualization effect (eg, color and / or opacity that is changed based on a colorless parameter) that is used to contribute to the visualization of the rendered scene.
[0011]
According to yet another aspect provided by the present invention, the output of the lighting calculation provides three color components, one of which is discarded. The remaining two color components are converted into texture coordinates and used for the texture mapping operation. One texture coordinate selects a one-dimensional texture map in a two-dimensional table. The other texture coordinate selects a particular texel in the selected one-dimensional texture map. The resulting selected texel provides color and / or alpha information that is added to the surface defined by the vertex.
[0012]
According to yet another aspect provided by the present invention, the use of lighting calculations to generate parameters other than color and opacity results in non-realistic cartoon lighting effects in real-time 3D graphics systems. Provided. A one-dimensional texture map can be defined that specifies different brush strokes as a function of this parameter. Using the conventional texture mapping operation, the one-dimensional texture map can be mapped to the polygon surface based on the parameters.
[0013]
More particularly, the system of the present disclosure may provide conventional lighting-type shading (as described above) as part of the overall operation, but using lighting formulas, texture coordinates (ie, other parameters other than color and opacity) Further improvements are provided that make it possible to generate This other parameter can be input into a further function (such as a look-up table stored as a texture) to provide further results (which may change the color / opacity of the object). Traditional approach using lighting expression output to directly affect the surface color of the primitive through this intermediate step that causes the lighting calculation to only indirectly affect the color and / or opacity of the displayed object More flexibility beyond that is provided.
[0014]
In one particular embodiment, a lighting expression result is used to select a one-dimensional texture from a plurality of textures. As an example, two different one-dimensional textures may be defined to display a tree trunk, a texture having a silver range and a texture having a brown range. A lighting formula is used to determine the angle at which the light source is incident on the trunk of the tree, and two textures can be selected depending on the result. The trunk of the tree can be colored by a different silver range from the bevel (using conventional texture mapping) and in the brown / black range when light is incident directly in front. In such a case, the lighting expression selects a one-dimensional texture (ie, functions as a parameter other than color and opacity—in this case, selecting two different textures).
[0015]
In certain embodiments disclosed herein, improvements are made to the transformation and lighting (“T & L”) pipeline, which allows the pipeline to generate texture coordinates based on lighting expressions. . Transformation and lighting produces a lighting expression output, but does not provide it directly to change the pixel color / opacity generated by the rasterizer, but provides the result as texture coordinates to the texture unit. In the disclosed embodiment, the output of the texture unit is a conventional shading algorithm, such as glow or von shading, based on the same or different lighting expressions, depending on the primitive color / opacity of the object (eg, transformation and lighting pipeline and rasterizer). Color or opacity that provides the display with a modified color / opacity value by being blended with.
[0016]
DETAILED DESCRIPTION OF THE INVENTION
FIG. 1 shows an example of an interactive 3D computer graphics system 50. System 50 can be used to play interactive 3D video games with interesting stereo sounds. It can also be used in various other applications.
[0017]
In this example, the system 50 can interactively process a digital representation or model of a three-dimensional world in real time. The system 50 can display some or all of the world from any arbitrary viewpoint. For example, the system 50 can interactively change the viewpoint in response to real-time input from a handheld controller 52a, 52b or other input device. This allows game players to see the world through the eyes of people inside or outside the world. The system 50 can be used in applications that do not require real-time 3D interactive display (eg, 2D display generation and / or non-interactive display), but has the ability to display high quality 3D images very quickly. It can be used to create real and exciting game play or other graphical interactions.
[0018]
To play a video game or other application using the system 50, a user first connects the main unit 54 to his or her color television 56 or other display device by connecting a cable 58 between them. Connecting. The main unit 54 generates both a video signal and an audio signal for controlling the color television 56. The video signal controls an image displayed on the television screen 59, and the audio signal is reproduced as sound through the stereo speakers 61L and 61R of the television.
[0019]
The user also needs to connect the main unit 54 to a power source. This power source may be a conventional AC adapter (not shown) that converts to a suitable lower DC voltage signal to connect to a standard household electrical outlet to power the household current to the main unit 54. . As another embodiment, a battery may be used.
[0020]
The user can use the hand controllers 52 a and 52 b to control the main unit 54. The control 60 can be used, for example, to specify the direction (up / down, left / right, close or far) in which the character displayed on the television 56 should move in the 3D world. The control 60 also provides input for other applications (eg, menu selection, pointer / cursor control, etc.). The controller 52 can take a variety of forms. In this example, the illustrated controller 52 includes controls 60 as joysticks, push buttons, and / or directional switches, respectively. The controller 52 can be connected to the main unit 54 via a cable or wirelessly via electromagnetic (eg, high frequency or infrared) waves.
[0021]
In order to play an application such as a game, the user selects an appropriate storage medium 62 that stores a video game or other application that the user wants to play, and inserts the storage medium into the slot 64 of the main unit 54. . The storage medium 62 may be, for example, a dedicated encoded and / or encrypted optical and / or magnetic disk. The user can operate the power switch 66 to turn on the main unit 54 and cause the main unit to start executing a video game or other application based on software stored in the storage medium 62. The user can operate the controller 52 to supply input to the main unit 54. For example, a game or other application can be started by operating the control 60. By moving other controls 60, the animated character can be moved in different directions and the user's viewpoint in the 3D world can be changed. Depending on the particular software stored on the storage medium 62, the various controls 60 on the controller 52 can perform different functions at different times.
[0022]
Electronic circuit example of the entire system
FIG. 2 shows a block diagram of example elements of the system 50. The main elements include:
A main processor (CPU) 110,
Main memory 112, and
Graphics and audio processor 114
[0023]
In this example, main processor 110 (eg, enhanced IBM Power PC 750) receives input from handheld controller 108 (and / or other input devices) via graphics and processor 114. The main processor 110 interactively responds to user input and executes a video game or other program supplied from the external storage medium 62 via a mass storage access device 106 such as an optical disk drive, for example. As an example, for video game play, the main processor 110 can perform collision detection and animation processing in addition to various interactive and control functions.
[0024]
In this example, the main processor 110 generates 3D graphics commands and audio commands and sends them to the graphics and audio processor 114. The graphics and audio processor 114 processes these commands to generate an interesting visual image on the display 59 and an interesting stereo sound on the stereo speakers 61R, 61L or other suitable audio generating device.
[0025]
The exemplary system 50 receives image signals from the graphics and audio processor 114 and analog and / or digital video suitable for display on a standard display device such as a computer monitor or home color television 56. A video encoder 120 is provided for converting the signal. The system 50 also has an audio codec (compressor / decompressor) 122 that compresses and decompresses the digitized audio signal and converts between digital and analog audio signal formats as needed. The audio codec 122 receives audio inputs via the buffer 124 and processes them into the graphics and audio processor 114 (eg, generated by the processor and / or received via the audio streaming output of the mass storage access device 106). For mixing with other audio signals). The graphics and audio processor 114 in this example may store audio related information in the audio memory 126 that is available for audio tasks. The graphics and audio processor 114 supplies the resulting audio output signal to the audio codec 122 for decompression and conversion to an analog signal (eg, via buffer amplifiers 128L, 128R), thereby providing the speaker 61L. , 61R.
[0026]
Graphics and audio processor 114 has the ability to communicate with various additional devices that may be present in system 50. For example, parallel digital bus 130 may be used to communicate with mass storage access device 106 and / or other elements. The serial peripheral bus 132 is, for example,
Programmable read-only memory and / or real-time clock 134,
A modem 136 or other networked interface (which may connect the system 50 to a communication network 138 such as the Internet or other digital network from which program instructions and / or data can be downloaded or uploaded), and
-Flash memory 140
May contact various peripheral devices or other devices, including An additional external serial bus 142 may be used to communicate with additional expansion memory 144 (eg, a memory card) and other devices. Connectors may be used to connect various devices to the buses 130, 132, 142.
[0027]
Graphics and audio processor examples
FIG. 3 is a block diagram of an example of the graphics and audio processor 114. In one example, the graphics and audio processor 114 may be a single chip ASIC (application specific integrated circuit). In this example, graphics and audio processor 114 includes:
Processor interface 150
Memory interface / controller 152
3D graphics processor 154
Audio digital signal processor (DSP) 156
-Voice memory interface 158
Audio interface and mixer 160
The peripheral controller 162, and
Display controller 164
[0028]
The 3D graphics processor 154 performs graphics processing tasks. The audio digital signal processor 156 performs audio processing tasks. Display controller 164 accesses the image information from main memory 112 and provides it to video encoder 120 for display on display device 56. Audio interface and mixer 160 interfaces with audio codec 122 and also audio from different sources (eg, audio streaming from mass storage access device 106, output of audio DSP 156, and external audio input received via audio codec 122). Can be mixed. The processor interface 150 provides a data and control interface between the main processor 110 and the graphics and audio processor 114.
[0029]
Memory interface 152 provides a data and control interface between graphics and audio processor 114 and memory 112. In this example, the main processor 110 accesses the main memory 112 via a processor interface 150 and a memory interface 152 that are part of the graphics and audio processor 114. Peripheral controller 162 provides a data and control interface between graphics and audio processor 114 and the various peripherals described above. The audio memory interface 158 provides an interface with the audio memory 126.
[0030]
Graphics pipeline example
FIG. 4 shows a more detailed view of an example of the 3D graphics processor 154. The 3D graphics processor 154 includes a command processor 200 and a 3D graphics pipeline 180, among others. Main processor 110 communicates a stream of data (eg, a graphics command stream and a display list) to command processor 200. The main processor 110 has a two-level cache 115 to minimize memory latency and a write collection buffer 111 for a non-cached data stream intended for the graphics and audio processor 114. The write collection buffer 111 collects partial cache lines into a complete cache line and sends data to the graphics and audio processor 114 one cache line at a time to maximize bus utilization.
[0031]
The command processor 200 receives and analyzes display commands from the main processor 110 (any additional data needed to process them is obtained from the shared memory 112). Command processor 200 provides a stream of vertex commands to graphics pipeline 180 for 2D and / or 3D processing and rendering. The graphics pipeline 180 generates an image based on these commands. The resulting image information can be transferred to the main memory 112 for access by the display controller / video interface unit 164 (which displays the frame buffer output of the pipeline 180 on the display 56).
[0032]
FIG. 5 is a logic flow diagram of the graphics processor 154. Main processor 110 may store graphics command stream 210, display list 212, and vertex array 214 in main memory 112 and may pass pointers to command processor 200 via bus interface 150. The main processor 110 stores graphics commands in one or more graphics first-in first-out (FIFO) buffers 210 allocated in the main memory 112. The command processor 200
A command stream from the main memory 112 via an on-chip FIFO memory buffer 216 that receives and buffers graphics commands for synchronization / flow control and load balancing;
The display list 212 from the main memory 112 via the on-chip call FIFO memory buffer 218, and
Vertex attributes from the command stream and / or from the vertex array 214 in the main memory 112 via the vertex cache)
Capture.
[0033]
The command processor 200 performs a command processing operation 200a that converts the attribute type to floating point format and passes the resulting complete vertex polygon data to the graphics pipeline 180 for rendering / rasterization. Programmable memory arbitration circuit 130 (see FIG. 4) arbitrates access to shared main memory 112 among graphics pipeline 180, command processor 200, and display controller / video interface unit 164.
[0034]
FIG. 4 illustrates that the graphics pipeline 180 may include:
・ Conversion unit 300
Setup / rasterizer 400
-Texture unit 500
A texture environment unit 600, and
・ Pixel engine 700
[0035]
The conversion unit 300 performs various 2D and 3D conversions and other operations 300a (see FIG. 5). The conversion unit 300 may have one or more matrix memories 300b for storing matrices used in the conversion process 300a. The conversion unit 300 converts the received figure from object space to screen space for each vertex, and converts the received texture coordinates to generate projected texture coordinates (300c). The conversion unit 300 may also perform polygon clipping / decimation 300d. The lighting process 300e, also performed by the transform unit 300b, provides per-vertex lighting operations for up to eight independent lights in one embodiment. The conversion unit 300 can also perform texture coordinate generation (300c) for an embossed bump mapping effect in addition to polygon clipping / thinning operation (300d).
[0036]
The setup / rasterizer 400 has a setup unit that receives vertex data from the transform unit 300 and sends triangle setup information to one or more rasterizer units (400b) that perform boundary rasterization, texture coordinate rasterization, and color rasterization.
[0037]
A texture unit 500 (which may include an on-chip texture memory (TMEM 502)) performs various processing related to texturing. For example,
Extracting the texture 504 from the main memory 112,
-Texture processing (500a), including, for example, multi-texturing, post-cache texture decompression, texture filtering, embossing, shading and shading through the use of projected textures, and Blit with alpha transparency and depth,
Bump map processing for computing texture coordinate displacements for bump mapping, pseudo-texture, and texture tiling effects (500b), and
・ Indirect texture processing (500c)
Is included.
[0038]
The texture unit 500 outputs the filtered texture value to the texture environment unit 600 for texture environment processing (600a). Texture environment unit 600 may blend polygons and texture colors / alpha / depth and perform texture fog processing (600b) to achieve a reverse range fog effect. Texture environment unit 600 may provide multiple stages for performing various other interesting environment-related functions based on, for example, color / alpha modulation, embossing, detailed texturing, texture swapping, clamping, and depth blending. .
[0039]
The pixel engine 700 performs depth (z) comparison (700a) and pixel blending (700b). In this example, the pixel engine 700 stores data in an embedded (on-chip) frame buffer memory 702. Graphics pipeline 180 may have one or more embedded DRAM memories 702 for storing frame buffer and / or texture information locally. The z comparison 700a ′ can also be performed earlier in the graphics pipeline 180 depending on the currently enabled rendering mode (eg, if alpha blending is not required, the z comparison is performed earlier). Can be broken). The pixel engine 700 includes a copy operation 700 c that periodically writes the on-chip frame buffer 702 to the main memory 112 for access by the display / video interface unit 164. This copy operation 700c can also be used to copy the contents of the embedded frame buffer 702 to the texture in the main memory 112 to obtain a dynamic texture synthesis effect. Anti-aliasing and other filtering can be performed during the copy-out operation. The frame buffer output of the graphics pipeline 180 (which is ultimately stored in the main memory 112) is read by the display / video interface unit 164 for each frame. Display controller / video interface unit 164 provides digital RGB pixel values for display on display 102.
[0040]
Colorless lighting function example
As described above, the conversion unit 300 in this embodiment performs lighting in addition to geometric conversion, polygon clipping, thinning, and other functions. In this embodiment, the conversion unit 300 supports lighting as a calculation for each vertex in hardware. This means that color values (RGB) can be computed for each illuminated vertex, and that these colors can be linearly interpolated across the surface of each illuminated triangle. This is known as glow shading. Further details regarding an example lighting embodiment are described below in connection with FIG.
[0041]
The conversion unit 300 of this example provides additional uses of the lighting function 302 that are not available in conventional graphics systems. In general, the output of a lighting function in a conventional graphics system is a color used for polygon shading. Some graphics systems provide alpha (eg, transparency) values based on lighting functions. In an embodiment provided by the present invention, a lighting function is used to generate a colorless parameter (ie, something other than color or alpha) that is used later to change color and / or opacity. .
[0042]
FIG. 6 is a block diagram illustrating such a configuration, where the lighting function 302 provides colorless parameters that are used in a subsequent process 304 to change color or opacity. The result of the change is displayed on a display device such as the display 56. In this context, the term “lighting function” generally refers to a mathematical function of surface position, surface orientation, eye point position, and possibly light source position. A lighting function can be defined as any combination of these coordinates.
[0043]
In this embodiment, the colorless parameter output by the lighting function 302 is processed by the texture function 306 as shown in FIG. At a very simple level, texturing an object means “pasting” an image to the object. More specifically, texturing is generally accomplished by changing the values used in the lighting function 302. For example, in the typical case, the lighting function 302 is used to determine the color and illuminance of the polygon surface, and the texturing function can add additional effects (eg, bricks) by changing its color / illuminance. Used to create the appearance of a wall or grain, or to provide a surface that appears uneven, mirrored, or distorted). In contrast to the embodiment shown in FIG. 7, the output of the lighting function 302 is a generalized parameter (eg, texture coordinates) for the texturing function 306 rather than a color or transparency value. The texturing function creates color and / or opacity information that is used to change (eg, blend) with primitive color and / or opacity for display on display device 56.
[0044]
FIG. 8 shows an example of the texture function 306. In this example, the lighting function 302 generates a colorless output parameter S that parameterizes the example texture function 306. The texture function 306 illustrated in the example of FIG. 8 selects one of three colors (C1, C2, C3) or opacity depending on the value of the parameter S. As a result, the specific color or opacity output from the texture function 306 is determined as a function of the parameter S output from the lighting function 302. Since the lighting function 302 provides the parameter S, which color or opacity to output from the texture function 306 depends on any of the various factors used to calculate the lighting function. Can do. These factors are for example:
·distance,
・ Attenuation,
·angle,
·vector,
・ Cosine,
・ Polynomial,
・ Light source type,
・ Other factors
including.
[0045]
Although the texture function 306 can be implemented in a variety of different ways, one cost-effective approach is to store the output values of the texture function 306 in a texture lookup table or map, and use texture coordinates to store these values. Is to access. FIG. 9 shows an example of a one-dimensional texture map 308 that is indexed by the output parameter S of the lighting function 302. The advantage of using a conventional texture mapping function in this embodiment is that the texture function 306 can be implemented using the texture mapping hardware available in general texturing or other functions along with the lighting function 302. That is.
[0046]
FIG. 10 shows a more detailed example that includes a two-dimensional texture mapping operation 306. In this example, lighting calculation 302 is performed based on vertex identification and lighting definitions. The output of lighting calculation 302 in this example includes a color per vertex (eg, red, green, blue) and / or transparency (ie, alpha). This embodiment typically uses the color output of these lighting calculations 302 for glow shading of the polygon surface. However, in this mode of operation, one of the color channels (eg, blue) is discarded and the other two color channels (ie, red, green) are converted to texture coordinates s, t using conversion operation 308. The texture coordinates s, t are provided to one or more texture mapping operations 306a, 306b, etc. to provide a color / transparency output texel. A blending operation 602 blends these texels with surface color information (which can be derived based on the same or different lighting calculations using conventional shading techniques) to display shaded textured polygons for display. Can be provided.
[0047]
In this embodiment, the texture mapping operation 306 provides a two-dimensional texture mapping as shown in FIG. In this example, the texture coordinate t is generated based on the green color channel output of the lighting calculation 302 and is used to select one of the n one-dimensional texture maps in the two-dimensional texture map 310. The other texture coordinate s is created based on the red color channel output of the lighting calculation 302 and is used to select a particular texel in the one-dimensional texture selected by the coordinate t. Of course, in other embodiments, a texture coordinate s may select a 1-D map and a coordinate t may select one particular texel and / or different texture coordinates using different colors and / or opacity. May be generated. If desired, texels in the 3D texture may be selected using three texture coordinates.
[0048]
FIG. 12 is an illustrative example of a two-dimensional texture map 310 that includes a plurality of one-dimensional texture maps 308. The specific two-dimensional texture map shown in FIG. 12 is particularly suitable for cartoon-like lighting effects. The illustrated example includes a plurality of one-dimensional texture maps, each including four maps 308 (1) -308 (4), each containing two different types of texels (eg, purple texels and blue texels). Yes. One of the texture coordinates (eg, t) makes a selection between these different texture maps, and the other texture coordinate (eg, s) selects a particular texel (ie, blue or purple). The various 1D texture maps 308 (1) -308 (4) provide different brush strokes or other effects by providing different mappings between texture coordinates and blue or purple texels.
[0049]
As another example, the 1D texture map 308 (6) shown in FIG. 12 includes four different types of texels (yellow, orange, red and brown). Using these different colors, for example, bold cartoon lighting where the angle of directional light to an object or the distance of the object from the light source determines the color obtained from the output of the texture mapping operation 306 An effect can be obtained. Such visualization can have a variety of interesting applications, especially in non-realistic real-time rendering such as dynamically generated cartoon animation. For example, it is possible to define a virtual cartoon light that lights an object. The rendered visualization of the object will depend on the vertex position, the local cartoon light position and other factors that the lighting calculation 302 considers (specular or diffuse operations, distance attenuation, etc.). In one example, a specific texel value in a 1D texture that defines a set of brush strokes can be specified by setting the red color channel to zero and letting the lighting calculation 302 compute the green channel. The material colors that the main processor 110 can typically provide for the lighting calculations 302 can be used to specify which 1D texture in the 2D texture map to select. The lighting calculation 302 calculates which brush stroke to select on a per vertex basis (without the additional cost of supplying one index per vertex).
[0050]
The example shown in FIG. 10 is particularly useful for comic writing, but can also be used for many other applications. As an example, the lighting function 302 can be used to calculate shadow solids or surfaces. A lighting calculation 302 based on a given vertex can generate a shadow solid defined in the texture coordinates used for the texture mapping operation 306. Many other applications are possible. For example, one interesting application is projected textures. One undesirable feature of the projected texture is typically projecting forward or backward from the camera. The techniques disclosed herein provide for attenuation (eg, to eliminate backward-facing lighting) and / or distance attenuation (eg, as seen when projecting an image using a real slide projector) Projected texture coordinate generation can be provided based on a lighting function that provides (to attenuate the projected texture based on how far it is projected). The combination of such projection texturing with the colorless lighting function described herein provides many interesting image and imaging effects.
[0051]
The conventional operation 306 shown in FIG. 10 is not necessary in all embodiments. In this example, the lighting function 302 generates an integer output that is converted by the conversion block 308 into a floating point representation suitable for the texture coordinates used in subsequent texture mapping operations 306. However, such integer-to-floating point conversions are not required in other embodiments, or different types of conversions can be used in other embodiments as desired.
[0052]
In the embodiment shown in FIG. 10, the lighting function 302 need not calculate both texture coordinates s and t. In this embodiment, since only one texture coordinate is used as a parameter to select which particular texel was used in the one-dimensional texture map to be applied to the primitive surface, the preferred embodiment Then, the lighting calculation 302 is preferably used to calculate the texture coordinates (or as an intermediate value from which the texture coordinates are derived). However, depending on the application, it may be desirable for the application program rather than the lighting calculation 302 to specify different texture coordinates that are used to select from multiple one-dimensional textures 308 (in this example). . As an example, an application program running on the main processor 110 can specify values for any or all of the color channel outputs of the lighting calculations 302 via lighting definitions applied to the lighting calculation inputs. . In some applications, it may be desirable for main processor 110 to specify the content of, for example, a green color channel, and thus a specific one-dimensional texture to be used for texture mapping operation 306. This provides new control for the programmer of the application while still allowing the lighting calculation 302 to dynamically generate the texture coordinates s based on the variables that the lighting calculation unit 302 evaluates. By truncating the floating point value sent from the main processor 110 to the conversion unit 300 in the form of RGB8, the calculation can be performed with high accuracy.
[0053]
In this embodiment, there is no reason that the lighting calculation 302 cannot generate a negative output value. In the example shown in FIG. 10, this corresponds to illuminating the object with a backlight. Therefore, in this embodiment, it is possible to obtain negative or backlit cartoon lighting. This can be useful to provide an effect when information is present on the back side of the object. In the preferred embodiment, the lighting unit always outputs a positive color (value). The preferred embodiment supports negative types of lighting calculations, but it is up to the application to add scale and / or bias so that the final value is positive. For example, the output of the lighting calculation can be mapped between −1 to 0 and +1 to 1 before being converted to texture coordinates. In the embodiment, negative values are not clamped but simply mapped to positive numbers. Here the application shall take care to ensure that these positive values are properly interpreted. Of course, negative lighting values may be directly supported if desired in other embodiments.
[0054]
The texture mapping operation 306 and blending operation 602 shown in FIG. 10 can be arbitrarily combined. For example, it is possible to blend with alpha. As another example, two separate color channels output from lighting calculation 302 may be used for two different texture mapping operations and then blended by blender 602. Since the texture mapper 500 and the texture environment unit 600 in this embodiment are both multitask / multistage operations, providing a series of direct / indirect operations based on the output of the lighting calculation 302 provides various interesting and complex operations. Effects can be obtained. For example, co-pending provisional application no. 60 / 226,891 (filed on August 23, 2000) and the corresponding utility patent application no. 09 / 722,382 (filed on Nov. 28, 2000) (patent attorney's reception number 723-961, both of which have the same name as “Method And Apparatus For Direct Indirect Texture Processing In A Graphics System”) Provisional application no. 60 / 226,888 (filed on August 23, 2000) and the corresponding utility patent application no. 09 / 722,367 (filed Nov. 28, 2000) (patent attorney acceptance number 723-968, both having the name of “Recirculating Shade Blender For A Graphics System”). All of which are incorporated herein by reference.
[0055]
Example embodiment of a lighting pipeline
FIG. 13 shows an example block diagram of the lighting calculation 302. In this example, the lighting calculation 302 is performed by the conversion unit 300 in response to information received from the command processor 200. This information can be obtained from a variety of sources including main processor 110 and main memory 112 (see FIG. 4).
[0056]
In this embodiment, the conversion unit 300 includes a master control unit 320, a lighting operation pipeline 322, an accumulator 324, and an integer-floating point converter 308 for texture generation. Master controller 320 receives lighting definitions and vertex definitions from command processor 200 and provides relevant information to lighting calculation pipeline 322 after appropriate storage / buffering. The lighting pipeline 322 performs the lighting operation in the following basic form. That is,
[Expression 1]

It is. Where C_nDefines the output of the lighting calculation pipeline, C_materialDefines the color of the material and A_cDefines ambient color, L (c) defines lighting diffusion or specular component, and A defines distance attenuation. This calculation calculates a triplet of RGB. This is because the lighting calculation pipeline 322 in this embodiment can perform two such lighting calculations in parallel. Because of this parallel computing feature, one of the lighting operations can be used for a colorless lighting effect for an object while the other lighting operation can be used for a colored lighting effect for the same object. The parallel computing feature is as much as generating a shaded polygon surface with no comical lighting effect to generate a shaded polygon surface with such a comical lighting effect. In the sense that it only takes processing time, effects such as comic writing are made “free”. In this embodiment, C generated by the lighting operation pipeline 322_nThe value may be positive or negative. For negative lighting, backlighting and other interesting effects are possible.
[0057]
In this embodiment, the output Cn of the lighting operation pipeline 322 is accumulated by the integer accumulator 324. The accumulated output in this embodiment is converted to floating point by the conversion block 308 and supplied to the texture unit 502 for texture mapping operations as texture coordinates. This example may provide texture filtering as part of the texture mapping operation 306. The application programmer must be careful about the texture filtering mode selected when generating the texture coordinates for the lighting calculations 302. Problems can arise due to the fact that some texture filtering is applied to both axes simultaneously, even though the s and t axes in this embodiment are used for independent factors. One way to avoid this is to replicate each entry along the t axis in the texture map to ensure that the interpolation between adjacent t values does not affect the final output. As a result, the one-dimensional texture filtering for adjacent values of t is the same. Mipmap filtering with multiple levels of detail may also be performed, but this may also work to reduce the number of 1D textures in a given 2D texture map.
[0058]
In this embodiment, another complexity arises due to the method of converting the color values of the lighting calculation 302 into texture coordinates. In the exemplary embodiment, the color value generated by lighting calculation 302 is an 8-bit integer in the range of 0-255. Conversion block 308 converts this integer value to a floating point value by dividing by 255. However, in this embodiment, this value is converted to texture coordinates by multiplying by the texture size. This process means that the application programmer must pay close attention to the texture coordinates to select the 1D texture. Assuming a texture size of 256 and GX_NEAR texture filtering, this is mapped as follows:
[Table 1]

[0059]
Because of the conversion process, coordinate value 128 is skipped and color values 254 and 255 are mapped to the same coordinate value. If the texture size is 256 and GX_LINEAR filtering is assumed, the mapping is as follows.
[Table 2]

[0060]
In the exemplary embodiment, it is safe to use n * 2 to convert the table ID to a color value. However, 1D textures must be stored in a non-simple manner within 2D textures. The n = 0 table must be stored at coordinate 0 (only), the n = 1 to n = 63 tables must be stored in n * 2-1 and n * 2, and from n = 64 The table with n = 127 must be stored in n * 2 and n * 2 + 1. Coordinate 127 may be left empty because it is not normally accessed in this particular embodiment. Other embodiments can avoid this problem altogether or have a different conversion problem.
[0061]
More detailed description of 300 example conversion units
FIGS. 14-22 show, as a further example, a more detailed embodiment of a transform unit 300 that includes a lighting pipeline used for lighting calculations 302. In this system 50 embodiment, the transform unit 300 supports lighting as a per-vertex calculation in hardware. This means that color (RGB) values can be computed for each vertex being illuminated, and that these colors can be linearly interpolated across the surface of each illuminated triangle (as glow shading). Known). The conversion unit 300 in this embodiment fully supports diffuse local spot light and also supports infinite specular lighting.
[0062]
The conversion unit 300 in this example supports diffusion attenuation. This means that the front of the object can be brighter than the side and the back can be darkest. Transform unit 300 provides diffusion attenuation by supporting vertex normals. For each vertex, compare the vertex normal to the vector between that vertex and the position of the light.
[0063]
The conversion unit 300 of this embodiment also supports local light. Local light has a position in the world and may also have a direction. Each light is defined to have a position. Using the position of each vertex and the position of light, the conversion unit 300 can perform distance attenuation for each vertex. This means that the brightness of light shining on the object can be reduced as the object moves away from the light.
[0064]
The conversion unit 300 in this embodiment also supports directional lighting. Support ranges from non-directional light to weak directional effects and highly directional spotlights. These effects are supported by angular attenuation. Therefore, it is possible to make a vertex directly present “in the beam” of light brighter than a vertex existing outside the beam or behind the light.
[0065]
Locally diffused light can be subject to both distance attenuation and angular attenuation. By programming an appropriate lighting expression, the application programmer can obtain the attenuation value as an output color or alpha (or as texture coordinates in the case of texture coordinate generation).
[0066]
In the exemplary embodiment, the conversion unit supports 8 physical lights. The application programmer can describe the attenuation parameters, position, direction, and color of each light. The application programmer can also control up to four physical color channels that accumulate lighting results. By associating light with a channel, the application programmer can choose to add the effects of multiple lights per vertex, or combine them later in the texture environment unit 600. The number of channels available to the texture environment unit 600 is set by the application programmer. In some cases (eg, when generating texture coordinates using a color channel), the light channel is computed but not output as color or opacity. As previously described, the transform unit 300 is pipelined to calculate two color channels simultaneously, but only one color channel may be provided directly to the texture environment unit 600 for blending. Other color channels may be provided to the texture unit 500 in the form of texture coordinates.
[0067]
Each color channel allows attenuation in the selection of the color source. A light mask associates up to eight lights with the channel. Referring to the channel of FIG. 14, associating up to 8 different lights with any of the two color channels and the two alpha channels provides two independent outputs, one of which can be converted to texture coordinates. An example is shown.
[0068]
As shown in FIG. 14, the conversion unit 300 in this embodiment generates two RGBA colors (color 0 and color 1). Each output color has two lighting functions, one for RGB and one for alpha, for a total of four lighting functions per polygon per vertex. Four such lights allow various lighting effects such as texturing. Each function may include the color of the active material based on the global ambient color held by the conversion unit 300 and the eight light states. These equations allow diffusion, specularity, and spot light attenuation. The lighting data path is designed to be optimal for locally diffuse spotlight in the preferred embodiment, but it is also possible to generate specular highlights and / or attenuation factors for textured lighting in the same data path It is. As described above, texture coordinates can also be generated using the color of light.
[0069]
Lighting calculation example
An example of a lighting expression executed by the conversion unit 300 is as follows.
[Expression 2]

[0070]
In this embodiment, the material and the global ambient color may be obtained from a register or may be obtained from the command processor 200 in the form of a vertex color. An application that requires more than eight lights calculates the illuminance from the additional light based on software running on the main processor 110 so that the result is one of the vertex colors, and The ambient source register can be set to use the vertex color. If desired, the main processor 110 computes any or all of the lighting calculations using software, and the resulting computed output is converted to texture coordinates as vertex color shapes for conversion unit 300. Can be supplied. Alternatively, the main processor may pass the computed texture coordinates to the texture unit 500 for texture mapping.
[0071]
By invalidating the “LightFunc” parameter, the color of the material passes through the conversion unit 300 without being changed. This allows the main processor 110 to directly select which of a plurality of 1D textures to use for the texture mapping operation in response to the colorless lighting function output based on software control of the application program. be able to.
[0072]
In each lighting function, any or all of the eight available lights may be allowed. In this embodiment, the sum of the illuminances for each light is clamped to [−1, 1] and converted to an integer 2's complement before adding the global ambient term. Since the total illuminance is clamped at [0, 1], the material cannot be brightened through the lighting in this embodiment. If this effect is desired, the light color may be pre-multiplied by the material color and the material color in the equation may be set to 1.0. In other example embodiments, other configurations may be provided to allow the material to be brighter through lighting.
[0073]
In this embodiment, when the result is sufficient even for a single color, the alpha formula can be used. The resulting alpha value can be combined with other RGB and alpha values in the texture environment unit 600 of the present example. For example, a diffusion result is output to the color output of channel 0 color, a specular result is output to the alpha output of color 0 channel, and the diffusion color is multiplied by the texture color by the texture environment unit 600. It is possible to add specular highlights (such as white).
[0074]
In the diffusion attenuation function of the present embodiment, flexibility is provided by a command (N · H) [0, 1] clamp or more. Attenuation can be disabled for lighting expressions that do not have diffuse properties or are left unclamped. The unclamped inner product makes it possible to control the illuminance by 180 ° with light-based texture generation. In this embodiment, since the illuminance is clamped,_cAnd amb_cCan be used to properly scale and bias the signed lighting function. In this embodiment, three examples of diffusion decay functions that can be used in one lighting formula are provided. That is,
[Equation 3]

It is.
[0075]
The angle attenuation logic in this embodiment calculates a second order polynomial based on the inner product of the light-direction vector and the light-vertex vector. By extrapolating the square and linear terms, an acute falloff is obtained. Clamping is used to avoid the generation of negative values due to extrapolation for angles outside the spot light angle. Range attenuation can be performed by using an inverse function of another second-order polynomial. The distance value d is the length of the vector from the vertex to the light position. Illumination falloff based on projection or other texture distances can be simulated by using a distance attenuation-only light equation for texture-type light.
[0076]
This same logic is used for general specular attenuation (N · H) for parallel light sources.^SCan be used to approximate Instead of the light-vertex vector and the light-direction vector, normal and half-angle vectors may be used, respectively. By disabling attenuation in the lighting function, it is possible to use a non-attenuating point (eg omnidirectional) light source in both diffuse and specular. In this example, the angular attenuation coefficient of the light may be used in the specular formula, and attenuation may be turned off in the diffusion formula. The specular and diffusion types of this example are combined in the texture environment unit 600 instead of in the conversion unit 300 in this example, but other embodiments are possible.
[0077]
Further details of an exemplary attenuation function are as follows.
[Expression 4]

[0078]
Embodiment of block diagram of conversion unit 300
FIG. 15 is a block diagram of an example embodiment of a conversion unit 300 of the system 50. The conversion unit 300 in this embodiment is
・ Top of pipeline part 330
・ Optical section 332
・ Bottom of pipeline part 334
It has three main parts.
[0079]
The top-of-pipeline unit 330 in this embodiment includes an optical unit 332, a context matrix storage 336, an input FIFO buffer 338 inner product unit 340, a projection block 342, a texture dot 2 block 346, a clipping detector 348, and a bypass FIFO block 350. Have. In the present embodiment, the top-of-pipeline (TOP) unit 330 performs the following exemplary functions.
・ Vertex transformation (three inner products)
Normal conversion (three inner products)
Texture conversion (2 or 3 inner products for texture)
Projection transformation (simplified three inner products)
The light unit 332 executes the following color channel function.
Color channel 0 diffusion operation (one inner product N · L)
Color channel 0 diffusion calculation (one inner product L per light²)
Color channel 0 diffusion operation (one inner product N²)
[0080]
Further, the input FIFO receives a vertex descriptor for each vertex specifying, for example, the following information.
・ Graphic information XYZ,
・ Normal vector information N_X, N_Y, N_Z
・ RGBA color 0 per vertex
・ RGBA color 1 per vertex
-Normal vector T_X, T_Y, T_Z
・ Secondary vector B_X, B_Y, B_Z
・ Texture 0 data T₀,
・ Texture 1 to n data S_n, T_n
[0081]
Appropriate information for each vertex is supplied to the light unit 332 to enable lighting calculations.
[0082]
The light unit 332 in the embodiment shown in FIG. 15 includes a lighting parameter memory 352, a normal memory 354, and an optical data path 356.
[0083]
The optical parameter memory 352 stores various optical parameters used by the optical data path 356. Thus, the light parameter 352 holds all of various lighting information (for example, light vector, light parameter, etc.). In this embodiment, both global and ambient states are stored in this memory. In this embodiment, each word is written in 32 bits, but only the upper 20 bits are retained. In this embodiment, each position has a width of 3 words, and the minimum word write size is 3 words. An example of the contents of the optical parameter memory 352 is shown below.
[Table 3]

[0084]
An overall view of the light section 332 in this embodiment is shown in FIG. In short, the light unit 332 performs the following local lighting operation.
[Equation 5]

This is the following local light vector calculation for each vertex:
[Formula 6]

Need. After this,
[Expression 7]

Need to be calculated.
[0085]
Thus, diffusion attenuation calculations require a light vector and a viewpoint space normal. In the illustrated embodiment, clamping to 0 may be conditional on an internal flag (eg, it may be clamped to 1.0 or not clamped at all). The diffused light may be allowed to have a negative inner product. The lighting dot product unit may calculate the viewpoint space normal while the conversion dot product unit calculates the geometric viewpoint space conversion. And the lighting inner product unit is NL, L²And N²An inner product can be computed. Thereafter, in the present embodiment, normalized light vector normal information is provided by normalizing the result. After normalization, a normalization coefficient and an attenuation expression are calculated using an intermediate result of normalization (for example, the square of distance, distance, and cosine N · L). Then, the optical ambient vector is multiplied. The resulting triplet is an attenuated diffuse component for each light. This is converted to a two's complement integer and the three values obtained are accumulated in an integer accumulator. This accumulator adds the ambient term and any other diffusion term from other light. The final sum is the color for each vertex (in this example, an 8-bit RGB format clamped from 0 to 255).
[0086]
FIG. 17 shows an example of a block diagram of the vector dot / Madd block 357 shown in FIG. Using the same dot product unit to compute N and all other dot products, each light must reuse the same data path element multiple times, so performance may be somewhat inferior and light scheduling becomes difficult . This leads to complex control problems. To simplify the design, various operations may be separated by implementing a second limited dot product unit. The first inner product unit may calculate the transformation normal, and the other inner product unit may compute the vertex transformation. Vector addition can then compute the light vector for local lighting. The second inner product unit is N (for specular light)², L², N · L, N · H can be calculated. In this embodiment this can be realized in a completely pipelined manner without feedback. See FIG.
[0087]
FIG. 18 shows an example of an embodiment of the normalizer 360 shown in FIG. Once the lighting vector value is computed, this example normalizes the result and computes the attenuation. The normalizer 360 of this embodiment accepts the following inputs:
Cosine decay: L · Dir, 1 / sqrt (L)
・ Distance attenuation: L², L
・ Diffusion coefficient: N ・ L 、 N², L²,
The distance attenuation is then calculated using the following steps performed by the exemplary normalizer 360 shown in FIG.
1. K₂d²Calculate
2. K₂d² _{+ K0}Calculate
3. Calculate d
4). K₁Calculate d
5. D₂D²+ K₁Calculate d + KO
6.1 / (K₂d²+ K₁d + K0)
[0088]
FIG. 19 shows an example of the distance attenuation unit 362. The exemplary distance attenuator embodiment 362 computes cosine attenuation using the following example steps.
1. Calculate Cos = Clamp0 (L.Ldir)
2. Cos₂Calculate
3. A₂Cos²Calculate
4). A₁Calculate Cos
5. A₁Calculate Cos + A0
6). A₂Cos²+ A₁Calculate Cos + A0
7). Clamp — 0 (A + 2 + Cos²+ A₁Calculate Cos + A0)
[0089]
FIG. 20 shows an example of an embodiment of an optical scaler 364 that calculates:
・ 1 / sqrt (N²)
1 / sqrt (L²)
・ N ・ L (sqrt (N²) × sqrt (L²))
[0090]
Some of the units (eg, 1 / sqrt and some of the multipliers) can be shared between the various data path embodiments of FIGS. Thus, some embodiments may require approximately 18 multipliers and 10 adders. Inversion and 1 / sqrt can be done using a table lookup or a simple 1-pass Newton-Raphson interpolator or some other pipeline interpolator. Since the alpha and specular writing operations are only changes in the lighting formula, no additional hardware is required in this embodiment.
[0091]
FIG. 21 shows an example of an embodiment of an integer accumulator 336. As new attributes arrive for each color, the color is accumulated. When all the light has accumulated for a certain color, the ambient is added (eg from the vertex color FIFO or from the register) and multiplied by the material color. The final RGB / A color is then accumulated in the accumulation / format register by building the final color and texture generation. Once the color / texture is computed, it is written to the output FIFO. Control may follow the following general guidelines:

[0092]
FIG. 22 shows an example of a stage transition diagram used for controlling the optical pipeline 322 in this embodiment. Arbitration logic determines the sequence of events sent out in the optical data path. The arbiter of this embodiment can send a new event only every 4 or 8 cycles depending on the event. The list of possible events is
・ Light calculation for specific color / alpha
・ Bump map calculation
including.
[0093]
For the above event, the arbiter drops an attribute in the control pipeline every 4/8 cycle. Each of these attributes includes an execution instruction for an event that is entered into the light pipeline 322. These attributes are used to increment the local count used to determine whether the color / texture is complete at the end of the pipeline.
[0094]
The following is an example of a control register used to control how the conversion unit 300 behaves and how it handles data, textures, etc.
[Table 4]

[0095]
Application programming interface example
The following are some examples of API calls related to generating texture coordinates from a lighting function in an example embodiment.
[0096]
GXSetTexCoordGen
Explanation
This function is used to specify how texture coordinates are generated. The output texture coordinates are usually the result of some transformation of input attributes (position, normal, or texture coordinates). Texture coordinates can also be generated from the output color channel of lighting calculation for each vertex.
[0097]
In the C language syntax, the texture coordinate generation function is as follows.
dst_coord = func (src_param, mtx);
[0098]
An example usage of the API function call example is

It is.
[0099]
The current vertex descriptor set by GXSetVtxDesc describes the data input to the graphics processor. By using GXSetTexCoordGen, the application can create new output texture coordinates from the input data. The dst_coord parameter is used to give a name to the output texture coordinates. This texture coordinate can be tied to the texture using GXSetTevOrder. The function GXSetNumTexGens specifies a plurality of consecutive texture coordinates starting from GX_TEXCOORD0 available with the GXSetTevOrder function.
[0100]
Input texture coordinates pass through texture coordinate generation hardware. GXInit initializes the hardware (by calling this API) so that all texture coordinates transformed by the GX_IDENTITY matrix appear to have passed through the texture hardware without changing the input coordinates. Converted.
[0101]
The enumeration GXTexMtx defines a default set of texture matrix names that can be supplied as mtx. The matrix name is actually a row address (4 floats per row) indicating the first row of the loaded matrix in the matrix memory. The model view matrix and the texture matrix share a matrix memory in this embodiment.
[0102]
Example: Generating texture coordinates from vertex lighting calculation
This type of texture coordinate generation can be used to create cartoon-like lighting effects. Convert one of the color channel results to texture coordinates.
[0103]
GX_TG_SRTG
The coordinate s is set equal to the 8-bit red component of the channel. The coordinate t is set equal to the 8-bit green component of the color channel. In cartoon lighting, the coordinate s represents the intensity of light and is input to an arbitrary 1D texture lookup to convert the intensity into color. The coordinate t is used to represent the color of the material and is used to select a 1D table from the 2D texture. Texture coordinates generated using the GX_TG_SRTG function must be generated after any coordinates generated by the transformation (GX_TG_MTX2 × 4 or GX_TG_MTX3 × 4) and the bump map function (GX_TG_BUMP0-3).
[0104]
The texture representing the array of 1D intensity-color tables must be carefully constructed in this example. Each table (row) must be described twice. Since coordinates s and t are generated from 8-bit color, a 256 × 256 maximum texture can be used. In this texture size, 127 tables are available ((256-1) / 2).
[0105]
An example of a rule for generating a green channel color that creates a correctly centered coordinate t in a two-row table is:

It is.
[0106]

[0107]
Functional ordering
In this embodiment, the texture coordinates are generated in order of function. That is, all conversions (GX_TG_MTX2 × 4 or GX_TG_MTX3 × 4), then bump maps (GX_TG_BUMP0 to 3), and then texture coordinate generation from lighting (GX_TG_SRTG).
[0108]
GXSetNumTexGens
Explanation
This function sets the number of texture coordinates that are generated and available in the texture environment (TEV) stage. Texture coordinates are generated from input data described by GXSetTexCoordGen. The generated texture coordinates are linked to a specific texture and a specific texture environment (TEV) stage using GXSetTevOrder.
[0109]
A plurality of continuous texture coordinates can be generated starting from GX_TEXCOORD0. A maximum of 8 texture coordinates can be generated. When nTexGens is set to 0, no texture coordinates are generated. In this case, at least one color channel must be output. See GXSetNumChans.
argument
nTexGens is the number of texture coordinates to be generated.
Example usage
void GXSetNumTexGens (u8 nTexGens);
[0110]
GXSetNumChans
Explanation
This function sets the number of lighting color channels output to the texture environment (TEV) stage. The color channel is a mechanism used to calculate the lighting effect for each vertex. The color channel is controlled using GXSetChanCtrl. The color channel is typically linked to a specific texture environment (TEV) stage.
[0111]
This function basically defines the number of colors per vertex to be rasterized. If nChans is set to 0, at least one texture coordinate must be generated. See GXSetNumTexGens. When nChans is set to 1, channel GX_COLOR0A0 is rasterized. When nChans is set to 2 (maximum value), GX_COLOR0A0 or GX_COLOR1A1 is rasterized.
argument
nChans is the number of color channels to be rasterized.
Example usage
void GXSetNumChans (u8 nChans);
[0112]
GXSetChanCtrl
Explanation
This function sets the lighting control for a color channel. A color channel can correspondingly have one or more (up to 8) lights, which are set using light_mask. The diff_fn and attn_fn parameters control the lighting calculations for all lights associated with this channel. amb_src and mat_src may be used to select whether the input source color is derived from a register color or a vertex color. When channel availability is set to GX_FALSE, the color source of the material (set by mat_src) is passed as is as the channel output color. When channel availability is set to GX_TRUE, the output color depends on other control settings (ie lighting formulas). GXInit sets permission for all channels to GX_FALSE. GXSetChanCtrl configures the lighting channel. The function GXSetNumChans is used to output the channel calculation result.
[0113]
Channels GX_COLOR0 and GX_ALPHA0 are controlled separately for lighting, but they are rasterized together as one RGBA color (effectively GX_COLOR0A0). The same is true for GX_COLOR1 and GX_ALPHA1, which are effectively rasterized as GX_COLOR1A1. Since the graphics hardware has only one color rasterizer, the application chooses which color to rasterize for each stage in the texture environment unit (Tev). This is achieved using the GXSetTevOrder function.
[0114]
In order to use vertex colors in channel GX_COLOR1A1, two colors are supplied per vertex. That is, both GX_VA_CLR0 and GX_VA_CLR1 are allowed in the current vertex descriptor. If only one of GX_VA_CLR0 or GX_VA_CLR1 is allowed in the current vertex descriptor, the vertex color is passed to channel GX_VA_COLOR0A0.
[0115]
When amb_src is set to GX_SRC_REG, the color set by GXSetChanAmbColor is used as the ambient color. When mat_src is GX_SRC_REG, the color set by GXSetChanMatColor is used as the material color.
argument
[Table 5]

[0116]
Example: Local diffuse spot light
This example shows how to configure the GX_COLOR0 channel to illuminate the vertex color with local diffuse spot light. The functions GXInitLightPos and GXInitLightDir are used to initialize the position and direction of the light. It is assumed that the position and direction of light have been converted to the viewpoint space before setting the light object. In order to allow diffuse lighting, diff_fn is set to GX_DF_CLAMP. Since this is a spot light, attn_fn is set to GX_AF_SPOT. The type of the angular attenuation function of the spot light is determined by the light and is set here by GXInitLightSpot. A distance decay function is set using GXInitLightDistAttn.
[Table 6]

[0117]
Example: Specular light
This example shows how to set GX_COLOR0 for specular light. The GXInitSpecularDir function is used to set the direction of light. Prior to the initialization of the light object, the direction must be converted to viewpoint space. Since the specular light is considered to be at infinity, no position parameter is required. An exponential decay function for specular light is approximated using an angular decay function and a distance decay function. Call GXInitLightShinness to control how bright the illuminated material appears (set attenuation parameters). attn_fn is set to GX_AF_SPEC to allow specular calculation.
[Table 7]

[0118]
Example: Parallel directional diffused light
Although the hardware does not support collimated directional diffuse light, it is possible to obtain "almost parallel" light by placing the light very far from all objects to be lit. If the position of the light is very far from the object, all the rays can be considered parallel.
[Table 8]

[0119]
Light can be used for both diffuse and specular channels
Whether local diffusion or specular calculations are performed in the channel is determined by channel control. The optical parameters (corresponding to the channel) are usually set assuming one of these operations. For example, the application sets the position and direction for local diffused light (used in the diffuse channel) and sets only the direction for specular light (used in the specular channel). However, if the application requires only directional diffused light (it can be considered that all rays of light are parallel because the position of the light is very far), the same light parameters can be used for the specular channel and the diffused channel. It can be used for both. In this case, the light parameters are initialized using GXInitSpecialDir.
[0120]
Example: Light per vertex considering pre-lighting
In this example, the pre-lighting color (e.g., computed by the art tool) supplied as per-vertex GX_VA_CLR0 (see GXSetVtxDesc) is added to the diffuse local light result. In this example, the following equation may be implemented.
[Equation 8]

[0121]
The ambient scale defines the minimum amount of color before lighting when light is not hitting the object. Since the sum of amb_scale and diff_scale should be equal to 1.0, the vertex color is equal to the color before lighting when the object is in the brightest light.
[0122]
The color of the material is configured to be the color for each vertex (the color before lighting). The ambient color register is set equal to amb_scale. The light color is scaled by diff_scale.
[Table 9]

[0123]
Example: Attenuation for four projection lights
This example shows how to calculate local light attenuation values for four projected texture lights. There is no color provided per vertex. The material color comes from the channel material register and is set to pass attenuation (multiply by 1.0). There is no contribution from ambient color. Each channel may be used to attenuate the projected texture in a texture environment (Tev) unit.
[Table 10]

[0124]
GXSetChanMatColor
Explanation
This function sets the material color register for the color channel chan. The color of the material is used if the source of the material set by GXSetChanCtrl is GX_SRC_REG.

[0125]
Examples to help explain
The application programming interface functions and associated parameters in the following examples can be used to generate texture coordinates using an unclamped diffuse lighting function, or a one-dimensional texture in the red component of the light color at each vertex. Used to generate texture coordinates for looking up the map, a second texture coordinate can be generated by the green component and used to select a one-dimensional texture line from the two-dimensional texture map.
[Table 11]

[0126]
Other compatible embodiments
Some of the system elements 50 described above can be implemented other than the home video game console configuration described above. For example, a graphics application or other software written for the system 50 can be run on a platform with a different compatible configuration, such as by emulating the system 50. If the other platform can successfully emulate, simulate and / or provide some or all of the hardware and software resources of the system 50, the other platform can successfully execute the software. .
[0127]
As an example, the emulator may provide a hardware and / or software configuration (platform) that is different from the hardware and / or software configuration (platform) of the system 50. The emulator system may have software and / or hardware elements that emulate or simulate some or all of the hardware and / or software elements of the system in which the application software is written. For example, the emulator system may comprise a general purpose digital computer such as a personal computer that executes a software emulator program that simulates the hardware and / or firmware of the system 50.
[0128]
Some general purpose digital computers (eg, IBM or Macintosh personal computers and compatibles) now have a 3D graphics card that provides a 3D graphics pipeline that is compatible with DirectX or other standard 3D graphics command APIs. . Others may have a stereo sound card that provides high quality stereo sound based on a standard set of voice commands. If a personal computer with such multimedia hardware executes emulator software, it may have sufficient capability to match the graphics and sound performance of the system 50. Emulator software is a hardware resource on a personal computer platform that simulates the processing, 3D graphics, audio, peripherals, and other functions of the home video game console platform that the game programmer wrote the game software for. To control.
[0129]
FIG. 23 shows an example of the entire emulation process using the game software executable binary image stored on the host platform 1201, the emulator element 1303, and the storage medium 62. Host 1201 may be a general purpose or dedicated digital computing device such as, for example, a personal computer, a video game console, or any other platform with sufficient computing power. The emulator 1303 may be software and / or hardware that runs on the host platform 1201 and provides real-time conversion of commands, data, and other information from the storage medium 62 into a form processed by the host. For example, the emulator 1303 retrieves “source” binary image program instructions intended to be executed by the system 50 from the storage medium 62 and executes these program instructions by the host 1201 for other processing. Convert to format.
[0130]
As an example, if the software is written to run on a platform using an IBM PowerPC or other specific processor and the host 1201 is a personal computer using a different (eg Intel) processor, The emulator 1303 takes one or a series of binary image program instructions from the storage medium 62 and converts these program instructions into one or more equivalent Intel binary image program instructions. The emulator 1303 also captures and / or generates graphics commands and audio commands that are intended to be processed by the graphics and audio processor 114, and the hardware and hardware available on the host 1201. Convert to one or more formats that can be processed by software graphics and audio processing resources. As an example, emulator 1303 may convert these commands into commands that can be processed by host 1201's specific graphics and / or audio hardware (eg, standard DirectX, OpenGL, and / or audio APIs). make use of).
[0131]
The emulator 1303 used to provide some or all of the features of the video game system described above also simplifies or automates the selection of various options and screen modes for games executed using the emulator. A graphics user interface (GUI) may be provided. In one example, such an emulator 1303 may also include more advanced functionality compared to the host platform for which the software was originally intended.
[0132]
FIG. 24 shows an emulation host system 1201 suitably used with the emulator 1302. The system 1201 includes a processing unit 1203 and a system memory 1205. A system bus 1207 connects various system elements including the system memory 1205 to the processing unit 1203. The system bus 1207 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. The system memory 1207 includes a read only memory (ROM) 1252 and a random access memory (RAM) 1254. Stored in ROM 1252 is a basic input / output system (BIOS) 1256 that includes basic routines useful for transferring information between elements in personal computer system 1201 (eg, during startup). The system 1201 further includes various drives and associated computer readable media. The hard disk drive 1209 reads from and writes to a (typically fixed) magnetic hard disk 1211. An additional (possible option) magnetic disk drive 1213 reads from and writes to a removable “floppy” or other magnetic disk 1215. Optical disk drive 1217 reads from and writes to removable optical disks 1219, such as CD ROM or other optical media. The hard disk drive 1209 and the optical disk drive 1217 are connected to the system bus 1207 by a hard disk drive interface 1221 and an optical drive interface 1225, respectively. The drive and the corresponding computer readable media store computer readable instructions, data structures, program modules, game programs, and other data for the personal computer system 1201 in a nonvolatile manner. In other configurations, other types of computer-readable media capable of storing computer-accessible data, such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, random access memory (RAM) Read only memory (ROM) or the like may also be used.
[0133]
A plurality of program modules including the emulator 1303 can be stored on the hard disk 1211, the removable magnetic disk 1215, the optical disk 1219, and / or the ROM 1252 and / or the RAM 1254 of the system memory 1205. Such program modules may include an operating system that provides graphics and audio APIs, one or more application programs, other program modules, program data, and game data. A user may input commands and information into the personal computer system 1201 via input devices such as a keyboard 1227, a pointing device 1229, a microphone, a joystick, a game controller, a satellite broadcasting antenna, and a scanner. These and other input devices can be connected to the processing unit 1203 via a serial port interface 1231 connected to the system bus 1207, such as a parallel port, a game port firewire bus or a universal serial bus (USB). It may be connected by other interfaces. A monitor 1233 or other type of display device is also connected to the system bus 1207 via an interface, such as a video adapter 1235.
[0134]
System 1201 may include a modem 1154 and other network interface means for establishing communications over a network 1152, such as the Internet. A modem 1154, which may be internal or external, is connected to the system bus 123 via the serial port interface 1231. A network interface 1156 may also be provided to allow the system 1201 to communicate with a remote computing device 1150 (eg, another system 1201) via the local area network 1158 (or such communication may be Or via other communication paths such as wide area network 1152 or dial-up or other communication means). System 1201 may typically have other peripheral output devices, such as a printer or other standard peripheral device.
[0135]
In one example, video adapter 1235 provides fast 3D graphics rendering in response to 3D graphics commands issued based on a standard 3D graphics application programmer interface such as Microsoft's DirectX 7.0 or other versions. You can have a 3D graphics pipeline chipset. In addition, a pair of stereo speakers 1237 is connected to the system bus 1207 via a sound generation interface such as a conventional “sound card”, so that high-quality stereo audio can be obtained based on the audio commands supplied by the bus 1207. Provides hardware and embedded software support for generating These hardware capabilities allow system 1201 to provide sufficient graphics and sound speed capabilities to play software stored on storage medium 62.
[0136]
All documents referred to above are incorporated herein by reference.
[0137]
While the present invention has been described in terms of what is currently determined to be the most practical and preferred embodiment, the present invention should not be limited to the disclosed embodiment, but described in reverse. Various modifications and equivalents shall apply within the scope of the claimed claims. For example, although specific comical lighting examples have been disclosed herein, the present invention is not limited to comical lighting, but rather various realistic and non-realistics that can be achieved using colorless lighting parameters. It will be understood to encompass photorealistic and textured and non-textured applications and effects.
[Brief description of the drawings]
FIG. 1 is an overall view of an example of an interactive computer graphics system.
FIG. 2 is a block diagram of the computer graphics system of the example of FIG.
FIG. 3 is a block diagram of the example graphics and audio processor shown in FIG.
4 is a block diagram of the example 3D graphics processor shown in FIG. 3;
5 is an example logic flow diagram of the graphics and audio processor of FIG.
FIG. 6 is a diagram showing an example of high-level image generation processing provided by the present invention.
FIG. 7 is a diagram illustrating an example of a more specific image generation process using texturing based on colorless lighting parameters provided by the present invention.
FIG. 8 is a diagram illustrating an example of a texture function.
FIG. 9 is a diagram illustrating an example of a one-dimensional texture map.
FIG. 10 is a diagram illustrating an example of a texture mapping procedure.
FIG. 11 is a diagram illustrating an example of a two-dimensional texture map.
FIG. 12 is a diagram showing a further example of a two-dimensional texture map.
FIG. 13 is a diagram illustrating an example of a lighting pipeline embodiment.
FIG. 14 is a diagram illustrating an example of association with a light color channel;
FIG. 15 is a diagram illustrating an example of an embodiment of a conversion unit.
FIG. 16 illustrates an example embodiment of a lighting pipeline.
FIG. 17 shows an example of an embodiment of a vector dot / adder unit.
FIG. 18 is a diagram illustrating an example of an embodiment of a normalizer.
FIG. 19 is a diagram illustrating an example of an embodiment of a distance attenuator.
FIG. 20 is a diagram showing an example of an embodiment of an optical scale device.
FIG. 21 illustrates an example embodiment of an integer accumulator.
FIG. 22 is an example of a state transition diagram.
FIG. 23 shows another compatible embodiment.
FIG. 24 illustrates another compatible embodiment.

Claims (1)

A graphics system,
A lighting data pipeline including at least first and second channels;
A texture unit coupled to the lighting data pipeline;
A blender coupled to the lighting data pipeline and the texture unit;
The lighting data pipeline receives per-vertex information and lighting definitions, calculates the vertex parameters to be lit in response to the per-vertex and lighting definitions,
The texture unit performs at least one texture mapping operation using at least one of the outputs of the lighting data pipeline as at least one texture coordinate;
The graphics system, wherein the blender provides a rendered image by blending color and / or opacity information obtained from the lighting data pipeline with texels obtained from the texture unit.

Images