(57)【要約】      （修正有）【課題】３Ｄグラフィックスハードウェアを利用する、陰影付け言語命令を含むグラフィックスアプリケーションプログラムを高速で実行する。【解決手段】グラフィックス計算をプラットフォーム独立型手続き型陰影付け式で表し、この式をツリーなどの中間表現に変換した後、パラメトリック陰影付け式のシーケンスに変換することが含まれる。別法として、ｉｂｕｒｇなどのコストベースのツリー文法認識プログラムを使用して、中間ツリー表現を処理することができる。その結果として、グラフィックス計算を実現する、基礎となるハードウェアに関してプラットフォーム特有で最低コストの、パラメトリック陰影付け式のシーケンスが得られ、プラットフォーム独立型のＲｅｎｄｅｒＭａｎ（登録商標）シェーディング言語プログラムを、高速で実行するプラットフォーム特有のＯｐｅｎＧＬ（登録商標）またはＤｉｒｅｃｔ３Ｄ（登録商標）実行可能コードに変換する。【選択図】図２
2011022999.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータにおいて、陰影付け言語命令のシーケンスを含むグラフィックスアプリケーションプログラムを高速で実行するための方法であって、
前記コンピュータは、
グラフィックス装置コマンドジェネレータを格納したメモリと、
前記メモリから前記グラフィックス装置コマンドジェネレータをロードして実行するプロセッサと、
を備え、
前記プロセッサが前記グラフィックス装置コマンドジェネレータを実行して以下のステップの処理を実現することを特徴とする方法。
（１）特定のグラフィック計算を受け取って、該受け取ったグラフィックス計算をシェーディング言語関数
および手続呼び出しを使用してプラットフォーム独立型の抽象表現で表すステップ、
（２）前記抽象表現を解析技法によりツリー表現に変換するステップ、
（３）前記ツリー表現をコスト処理するステップ、
（４）プラットフォーム独立型グラフィックスアプリケーションプログラムインタフェースによって前記抽象表現を実現する、手順および関数呼び出しのプラットフォーム依存型の最低コストの前記シーケンスを決定するステップであって、
前記手順および関数呼び出しのプラットフォーム依存型の最低コストの前記シーケンスは、前記プラットフォーム独立型グラフィックスアプリケーションプログラムインタフェースによってインタフェースされる基本的なハードウェアのための前記手順および関数呼び出しの最低コストの前記シーケンスを生成するために、前記プラットフォーム独立型グラフィックスアプリケーションプログラムインタフェースを利用する、ステップ。
【請求項２】
前記抽象表現が、プログラミング言語で書かれたシェーダーであることを特徴とする請求項１に記載の方法。
【請求項３】
前記プログラミング言語が、Ｃプログラミング言語であることを特徴とする請求項２に記載の方法。
【請求項４】
前記プログラミング言語が、Ｃ＋＋プログラミング言語であることを特徴とする請求項２に記載の方法。
【請求項５】
前記抽象表現が陰影ツリーであることを特徴とする請求項１に記載の方法。
【請求項６】
前記抽象表現が閉路なし有向グラフであることを特徴とする請求項１に記載の方法。
【請求項７】
コンピュータにおいて、陰影付け言語命令のシーケンスを含むグラフィックスアプリケーションプログラムを高速で実行するためのシステムであって、
前記コンピュータは、
グラフィックス装置コマンドジェネレータを格納したメモリと、
前記メモリから前記グラフィックス装置コマンドジェネレータをロードして実行するプロセッサと、
を備え、
前記プロセッサは前記グラフィックス装置コマンドジェネレータを実行して以下のステップの処理を実現することを特徴とするシステム。
（１）特定のグラフィック計算を受け取って、該受け取ったグラフィックス計算をシェーディング言語関数および手続呼び出しを使用してプラットフォーム独立型の抽象表現で表すステップ、
（２）前記抽象表現を解析技法によりツリー表現に変換するステップ、
（３）前記ツリー表現をコスト処理するステップ、
（４）プラットフォーム独立型グラフィックスアプリケーションプログラムインタフェースによって前記抽象表現を実現する、手順および関数呼び出しのプラットフォーム依存型の最低コストの前記シーケンスを決定するステップであって、
前記手順および関数呼び出しのプラットフォーム依存型の最低コストの前記シーケンスは、前記プラットフォーム独立型グラフィックスアプリケーションプログラムインタフェースによってインタフェースされる基本的なハードウェアのための前記手順および関数呼び出しの最低コストの前記シーケンスを生成するために、前記プラットフォーム独立型グラフィックスアプリケーションプログラムインタフェースを利用する、ステップ。
【請求項８】
前記抽象表現が、プログラミング言語で書かれたシェーダーであることを特徴とする請求項７に記載のシステム。
【請求項９】
前記プログラミング言語が、Ｃプログラミング言語であることを特徴とする請求項８に記載のシステム。
【請求項１０】
前記プログラミング言語が、Ｃ＋＋プログラミング言語であることを特徴とする請求項８に記載のシステム。
【請求項１１】
前記抽象表現が陰影ツリーであることを特徴とする請求項７に記載のシステム。
【請求項１２】
前記抽象表現が閉路なし有向グラフであることを特徴とする請求項７に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般にコンピュータグラフィックスの分野に関し、さらに具体的に言えば、プラットフォーム独立型陰影付け（ｓｈａｄｉｎｇ：シェーディング）言語命令を含む、プラットフォームの効率の良いグラフィックスアプリケーションプログラムを実行するためのシステムおよび方法を提供することに関する。
【背景技術】
【０００２】
高品質の（写真写実的に）陰影付けされたレンダリングを要求するグラフィックスアプリケーション（たとえば、エンターテイメント（娯楽）業界のアプリケーション）は、典型的には陰影付け言語を使用して書かれる。陰影付けされたレンダリングは、あるシーンの合成グラフィカルイメージ（画像）を、そのシーン（情景、場面）の数学的（すなわち幾何学的および他の特徴の）モデルから生成するプロセスに関わり、陰影付けは、自己放出または伝搬のいずれかによってある地点から出る光を計算するプロセスに関わるものである。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
陰影付けモデルは、表面上または空間内の特定の点を出る光を特徴付ける数学的関数である。初期の開発では、その式のセットによって特徴付けられた特定モデルを選択し、レンダリングを達成するためにパラメータを選択する必要があった。ユーザは、モデルについて詳細に知り、首尾良くいくようにパラメータを微調整する必要があった。したがって、これらのモデルはラベル付きパラメトリック陰影付けモデルであった（それの式はラベル付きパラメトリック陰影付け式であった）。
【０００４】
陰影付け言語はカスタム陰影付けモデル（すなわち「シェーダー」）を利用する必要から発展した。カスタマイズされたシェーダーを構築するための高水準の陰影ツリーアーキテクチャは、ＣｏｏｋのＨ．Ｃｈｒｉｓｔｉａｎｓｅｎ（編集）による「Ｓｈａｄｅ  Ｔｒｅｅｓ」Ｃｏｍｐｕｔｅｒ  Ｇｒａｐｈｉｃｓ（ＳＩＧＧＲＡＰＨ  ’８４  Ｐｒｏｃｅｅｄｉｎｇｓ）」Ｖｏｌ．１８、Ｎｏ．３、ｐ．２２３〜２３１（１９８４年７月）に最初に記載された。Ｃｏｏｋは、陰影付けプロセスがツリー状構造に、一般には閉路なし有向グラフ（ＤＡＧ）に編成できるいくつかの基本操作に分けられているアーキテクチャについて記載している。各ツリーノードは基本的に関数呼出しであり、陰影ツリー言語プログラムは、パラメータの標準リストを陰影ツリーに渡し、それをポスト順に走査して、ツリーのルーフから戻される最終的なカラーおよび不透明度の値を予測する。
【０００５】
Ｐｅｒｌｉｎの「Ａｎ  Ｉｍａｇｅ  Ｓｙｎｔｈｅｓｉｚｅｒ」Ｃｏｍｐｕｔｅｒ  Ｇｒａｐｈｉｃｓ（ＳＩＧＧＲＡＰＨ  ’８５  Ｐｒｏｃｅｅｄｉｎｇｓ）」Ｖｏｌ．１９、Ｎｏ．３、ｐ．２８７〜２９６（１９８５年７月）では、事前に計算された可視性情報から任意の式がピクチャを生成する、陰影付けするための同じ様な言語ベースの方法が示された。このＣｏｏｋおよびＰｅｒｌｉｎの考えが、Ｈａｎｒａｈａｎ等の「Ａ  Ｌａｎｇｕａｇｅ  ｆｏｒ  Ｓｈａｄｉｎｇ  ａｎｄ  Ｌｉｇｈｔｉｎｇ  Ｃａｌｃｕｌａｔｉｏｎｓ」Ｃｏｍｐｕｔｅｒ  Ｇｒａｐｈｉｃｓ（ＳＩＧＧＲＡＰＨ  ’９０  Ｐｒｏｃｅｅｄｉｎｇｓ）、Ｆ．Ｂａｓｋｅｔｔ（編集）、Ｖｏ．２４、Ｎｏ．４、ｐ．２８９〜２９８（１９９０年８月）で結合された。その結果が、関連する技術分野でよく知られたＲｅｎｄｅｒＭａｎ（商標）のシェーディング言語（陰影付け言語）となった。ＲｅｎｄｅｒＭａｎ（商標）については、Ｕｐｓｔｉｌｌの「Ｔｈｅ  ＲｅｎｄｅｒＭａｎ（商標）Ｃｏｍｐａｎｉｏｎ」Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ  Ｐｕｂｌｉｓｈｉｎｇ  Ｃｏ．（ＵＳＡ  １９９０年）に詳細に記載されている。
【０００６】
陰影付け言語は、これまで常にプラットフォームに依存しないものであることが望ましかった。言い換えれば、それらの設計の目標は、陰影付け言語命令のソースコードバージョンをほとんど書き換えずに、異なるハードウェアプラットフォーム間で陰影付けされたレンダリングアプリケーションを幾分か移植（ｐｏｒｔ）しやすくすることであった。プラットフォームへの独立を達成するため、典型的に、陰影付け言語命令は、高水準のプラットフォーム独立プログラミング言語（たとえば「Ｃ」または「Ｃ＋＋」プログラミング言語）で書かれたソフトウェアライブラリに、アプリケーションをコンパイルおよびリンクすることによって、あるいは同様に高水準言語で書かれたランタイム（実行時）ソフトウェア解釈プログラム（ｉｎｔｅｒｐｒｅｔｅｒ）を使用することによって処理される。
【０００７】
典型的に陰影付け言語は、それらの抽象化高水準手続き型陰影付け式（ｐｒｏｃｅｄｕｒａｌ  ｓｈａｄｉｎｇ  ｅｘｐｒｅｓｓｉｏｎ）を介して、柔軟かつ強力な方法で、プログラマが所与の表面内で、点の表示カラーおよび不透明度を制御できるようにするものである。たとえば、一定の不透明度およびカラーでレンダリングされる表面の、典型的なＲｅｎｄｅｒＭａｎ（商標）シェーディング言語命令のセットを表１に示す。
【０００８】
【表１】
2011022999.tif 000003
【０００９】
この表面シェーダーの単純な例示では、変数Ｏｉは表面の不透明度を表し、一定値Ｏｓに設定される。Ｃｉは出力カラーを表し、定数Ｃｓ（表面の反射率）とＯｓの積に設定される。
【００１０】
表２に示した他の例では、より複雑なＲｅｎｄｅｒＭａｎ（商標）の陰影付け命令のシリーズを介して、「プラスチック」表面が指定されるが、これには、様々なライティングベースの計算（たとえば拡散、鏡面、周囲など）を行い、これらを数学的に結合する必要がある。
【００１１】
【表２】
2011022999.tif 000004
【００１２】
これらの命令が合わさって、その中に微細な色付けされた粒子が浮遊している固体媒体としてプラスチック表面をモデリングする。鏡面のハイライトは表面で直接反射すると仮定され、表面のカラーは媒体内に入り、浮遊粒子で反射して、再度出現する光によるものと仮定される。
【００１３】
任意のイベント（事象）では、表１および表２に含まれる例が、関連分野の技術者であれば容易に理解される、ＲｅｎｄｅｒＭａｎ（商標）シェーディング言語での標準的なシェーダーである。
【００１４】
陰影付けされたレンダリングによってアプリケーションを実行する場合の現在の制約は、これらが非常に遅いことである。従来のグラフィックスハードウェアシステムでは、平均的な複雑さの３次元シーン用に単一の完全に陰影付けされたイメージフレームをレンダリングするのに、有に数時間以上かかる。これは現在、ＩｎｆｉｎｉｔｅＲｅａｌｉｔｙグラフィックスを備え、最先端技術を用いたＳｉｌｉｃｏｎ  Ｇｒａｐｈｉｃｓ，Ｉｎｃ．のＯｎｙｘ２（商標）ワークステーションなどの特別用途向け３Ｄグラフィックスハードウェアを含む、最高級のコンピュータグラフィックスシステムであっても同様である。陰影付け言語命令は、典型的には高水準のプラットフォーム独立型プログラミング言語を使用してコンパイルおよびリンクされているので、正味の効果は、各陰影付けルーチンに必要な演算が最終的にユーザのコンピュータシステム内にある汎用マイクロプロセッサによって処理されることである。Ｏｎｙｘ２（商標）システムなどの特殊用途向けグラフィックスハードウェア資源は、簡単に取付けられない。
【００１５】
さらに、陰影付け言語およびグラフィックスアプリケーションプログラムインターフェース（ＡＰＩ）は、一般に、表面上は装置に依存しない様式でグラフィック計算を指定するために、広範な基本命令のセットを提供する。ただし、このようなＡＰＩの制約は、別個のものであるが機能的には同等の多くの基本命令シーケンスが、所与の計算を実行できるようにする場合がしばしばあることである。全体的な実行時間およびシステム資源の利用に関して、機能的に同等なシーケンスのセットの中で最適な選択は、ＡＰＩの基礎となるハードウェアまたはソフトウェアの実施に強く依存している。最適な性能を達成するためには、プログラマがそれぞれの独特なグラフィック装置に対して独特なシーケンスを構築しなければならないので、この事実が、装置抽象化（ｄｅｖｉｃｅ  ａｂｓｔｒａｃｔｉｏｎ）としてのＡＰＩの利用を根底から揺るがすことになる。
【００１６】
前述の制約を考えると、陰影付けされたレンダリングアプリケーションを効率的に実行しながら、このようなアプリケーションの相対的なプラットフォーム独立性を維持していくためには、特殊用途向けグラフィックスハードウェア資源を利用する方法が必要となる。さらに、グラフィックス装置コマンドの効率的なシーケンスを、抽象的な装置独立型計算式から生成するための、コストベースのランタイムコンパイルシステムも必要である。
【課題を解決するための手段】
【００１７】
本発明は、陰影付け言語命令（シェーディング言語命令）を含むグラフィックスアプリケーションプログラムを、高速で実行するためのシステムおよび方法である。この方法には、グラフィックス計算をプラットフォーム独立型手続き型陰影付け式で表すステップと、これをツリーなどの中間表現に変換するステップと、グラフィックス計算を実現するパラメトリック陰影付け式のシーケンスを取得するステップが含まれる。好ましい実施形態では、本発明の方法は、ｉｂｕｒｇなどのコストベースのツリー文法（木文法）認識プログラム（ｔｒｅｅ−ｇｒａｍｍａｒ  ｒｅｃｏｇｎｉｚｅｒ）を使用して、グラフィックス計算の中間ツリー表現を処理する。これによって、さらに本発明の方法は、グラフィックス計算を実現するプラットフォーム依存型の基本コマンドの効率的なシーケンスを取得することができる。
【００１８】
本発明の一つの利点は、１つのあるグラフィックスＡＰＩで書かれたプログラムを、他のグラフィックスＡＰＩで書かれたプログラムに変換する際に使用できることである。より具体的に言えば、本発明は、プラットフォーム独立型ＲｅｎｄｅｒＭａｎ（商標）のシェーディング言語プログラムをより速く実行するために、プラットフォーム特有のＯｐｅｎＧＬ（商標）またはＤｉｒｅｃｔ３Ｄ（商標）プログラムに変換できるようにするものである。
【００１９】
本発明の他の利点は、その方法が解釈・実行されるのではなくコンパイルされることである。これは、他の言語ベースのグラフィックス環境とは異なる。したがって、本発明は、新しい目標を、別のハードウェア／ソフトウェアの実施および別の低水準ＡＰＩに向けることができる。
【００２０】
さらに本発明の他の利点は、従来の特別なグラフベースの最適化とは異なることである。本発明の好ましい実施形態では、ｉｂｕｒｇがコストベースのツリー文法認識プログラムとして使用される。これによって、首尾良く定義されたコスト関数を使用する、基本コマンドの効率の良い（またはコストが最低の）シーケンスの系統的な検索が可能になる。さらにこれによって、新しいプラットフォームへの半自動化された移植（すなわち自己校正手続）を可能にし、ユーザ定義された最適化を追加する機構を可能にする。  本発明の他の特徴および利点、ならびに本発明の様々な実施形態の構造および動作について、添付の図面を参照しながら下記に詳細に説明する。
【図面の簡単な説明】
【００２１】
添付の図面を参照しながら本発明について説明する。
【図１】本発明の好ましい一実施形態の全体的なアーキテクチャを表す流れ図である。
【図２】本発明の好ましい一実施形態による全体的な動作を表す流れ図である。
【図３】本発明の好ましい一実施形態による、グラフィックス計算のツリー表現を示す図である。
【図４】本発明の好ましい一実施形態による処理を実行した後の、図３のツリー表現を示す図である。
【図５】本発明の実施に役立つ例示的コンピュータシステムの構成図である。
【図６】本発明の好ましい一実施形態による方法のステップを示す、例示的プログラミング式の解析ツリーである。
【発明を実施するための形態】
【００２２】
概要
本発明は、プラットフォーム独立型陰影付けされたレンダリングアプリケーションの実行において、新しいアーキテクチャを介して有意な高速化を提供する。この発明の手法は、グラフィックスアプリケーションプログラムを実行する場合に、高品質の陰影付け言語呼出し（すなわち手続き型陰影付け式）を含み、任意の有意なハードウェアコストが追加されずに、事実上１００〜１０００倍に高速化するための潜在性を提供する。手続き型陰影付け言語命令は、ハードウェア抽象層のレベルで中間コードを出力する、初期コンパイル／変換ステップを介して処理される。この中間コードは、パラメトリック陰影付け式の形を取ることができる。
【００２３】
パラメトリック陰影付け式は、典型的には、ＯｐｅｎＧＬ（商標）ＡＰＩなどの、マシン独立型３Ｄグラフィックス言語（すなわち、パラメトリック陰影付け式を含む言語）を使って実施される。ＯｐｅｎＧＬ（商標）はグラフィックス・システムへのソフトウェアインターフェースであって、関連技術分野ではよく知られており、Ｗｏｏ等による「ＯｐｅｎＧＬ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｇｕｉｄｅ：Ｔｈｅ  Ｏｆｆｉｃｉａｌ  Ｇｕｉｄｅ  ｔｏ  Ｌｅａｒｎｉｎｇ  ＯｐｅｎＧＬ，Ｖｅｒｓｉｏｎ  １．１」Ｓｉｌｉｃｏｎ  Ｇｒａｐｈｉｃｓ，Ｉｎｃ．，Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ  Ｐｕｂｌｉｓｈｉｎｇ  Ｃｏ．（ＵＳＡ  １９９７年）で詳細に説明されている。
【００２４】
代替の一実施形態では、本発明はＤｉｒｅｃｔ３Ｄ（商標）のマシン独立型グラフィックス言語の中間コード（ＯｐｅｎＧＬ（商標）と同様のグラフィックスシステムへの他のソフトウェアインターフェース）を出力する。Ｄｉｒｅｃｔ３Ｄ（商標）も関連技術分野ではよく知られており、Ｇｌｉｄｄｅｎの「Ｇｒａｐｈｉｃｓ  Ｐｒｏｇｒａｍｍｉｎｇ  ｗｉｔｈ  Ｄｉｒｅｃｔ３Ｄ：Ｔｅｃｈｎｉｑｕｅｓ  ａｎｄ  Ｃｏｎｃｅｐｔｓ，Ｍｉｃｒｏｓｏｆｔ  Ｃｏｒｐ．」Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ  Ｐｕｂｌｉｓｈｉｎｇ  Ｃｏ．（ＵＳＡ  １９９７年）で詳細に説明されている。
【００２５】
他の代替の一実施形態では、ＯｐｅｎＧＬ（商標）コード、Ｄｉｒｅｃｔ３Ｄ（商標）コード、または同様のもの（たとえばＯｐｅｎＧＬ（商標）またはＤｉｒｅｃｔ３Ｄ（商標）コードを起動するＩＲＩＳ  Ｐｅｒｆｏｒｍｅｒ（商標）などのシーングラフライブラリ）が、プラットフォーム特有の環境（たとえばＯｐｅｎＧＬ（商標）またはＤｉｒｅｃｔ３Ｄ（商標）ライブラリを備えた任意のマシン）でコンパイルできるので、高品質陰影付け言語と、多彩なコンピュータプラットフォームとの互換性と、特定プラットフォーム用の最適化とを組み合わせた利点をすべて享受することができる。
【００２６】
現在、一方の手続き型陰影付け言語命令（たとえばＲｅｎｄｅｒＭａｎ（商標））と、他方の中間レベルの対話式３Ｄグラフィックスプログラミング言語（ＯｐｅｎＧＬ（商標））との間に、直接的な１対１マッピングは存在しない。
【００２７】
Ｃｏｏｋ、Ｐｅｒｌｉｎ、およびＨａｎｒａｈａｎ等では、陰影付けは、いくつかの算術演算、ベクトル演算、論理演算、および数学演算に分類される。任意の陰影付け式は、これらの原子ビルディングブロックをさまざまな方法で結合することによって計算できる。これら以前の方式では、パラメトリック陰影付け式は任意の陰影付け式のサブセットとみなされるので、原子演算を互いに継ぎ合わせることによっても計算された。たとえばＰｅｒｌｉｎの２８７ページでは、彼の言語でベクトルドット積がどのような組込み関数であるかについて説明され、通常のベクトル、光ベクトル、ドット積演算、および赤色からなるピースを利用することによって、パラメトリック・ランベルト（拡散）照明モデルの計算例が示されている。同様に、表２では、プラスチックルックを計算するＲｅｎｄｅｒＭａｎ（商標）シェーダーを示している。同等の計算は、陰影付け言語のないグラフィックスシステムでは一般にパラメトリック陰影付け式として表される。ただし、ＲｅｎｄｅｒＭａｎ（商標）の実施では、このプラスチックシェーダーを、任意の他の陰影付け式を実行し、これを原始的構成要素および演算に分割し、これらのピースを汎用プロセッサで実行するときと同様に扱う。Ｐｅｒｌｉｎの場合と同様に、陰影付け式は、ＯｐｅｎＧＬ（商標）またはＤｉｒｅｃｔ３Ｄ（商標）で見られるようなパラメトリック陰影付け式に変換されない。本発明は、多重パスＯｐｅｎＧＬ（商標）レンダリングプロセスに関して望ましい陰影付けルーチンを再実施することが好ましい、中間レベルコードへの変換を提供する。さらにこの変換は、コンパイラ／変換プログラムによって自動的に実行されることが好ましい。
【００２８】
そこで、本発明は、基礎となるグラフィックス装置（すなわちハードウェア）にかかわらず、最適な性能を達成するグラフィックＡＰＩ手順および関数（すなわちソフトウェアコード）の効率的なシーケンスを見い出した。所与のグラフィックスＡＰＩに関して直接プログラミングするのではなく、プログラミング言語式、陰影ツリー、ＤＡＧなどのような抽象表現を使用して、特定のグラフィックス計算が表される。コンパイルシステムは、標準解析技法を使用して、抽象式をツリー表現などの中間表現に変換する。
【００２９】
次いでこのツリーは、新規なコストベースのツリー文法認識プログラムを使用して処理することができる。このツリー文法ベースで処理した結果によって、基礎となるグラフィックスＡＰＩに関して抽象計算を実現する基本コマンドの効率的なシーケンスを決定する。ツリー文法に組み込まれたコストは、結果として生じる基本コマンドシーケンスの評価コスト（実行時間および資源利用に関する）に直接対応するように較正される。次いでこのシーケンスは、シーケンスをコンパイルし、これを適切な３Ｄグラフィックスのプログラミング言語ライブラリとリンクさせることによって、効率的および反復的に実行することができる。他の実施形態では、ツリー文法ベースの処理が、最低コストのシーケンスである基本コマンドの効率的シーケンスを決定する。このシーケンスが、実行時間および資源利用に関して最低コストの（すなわち最も効率の良い）抽象計算を実現することになる。
【００３０】
本発明は、上記の例に関して説明される。これは便宜上であって、本発明の適用範囲を制限することを意図するものではない。実際に、当分野の技術者が以下の説明を読めば、代替実施形態で以下の発明をどのように実施するかが明らかになろう。
【００３１】
システムアーキテクチャ  上記で説明したように、陰影付け言語命令は、典型的に、最終的に汎用マルチプロセッサを使用して実行する高水準のプラットフォーム独立型プログラミング言語を使用して、コンパイルおよびリンクされる。こうしたコードを高速化するために、本発明は、特有のプラットフォームが、ユーザ（すなわちアプリケーションプログラマ）が使用可能な任意の特殊用途向けグラフィックスハードウェア資源を利用することを対象とする。
【００３２】
図１を参照すると、プラットフォームに有効なグラフィックスアプリケーションプログラムジェネレータ１００が、本発明全体のアーキテクチャを表す。ジェネレータ１００は、ステップ１１０から始まり、ここでグラフィックス計算は、手続き型陰影付け式として表される。このような式は、典型的に、陰影付け言語（たとえばＲｅｎｄｅｒＭａｎ（商標））の手順および関数（すなわち基本命令）を使用して、高水準言語（たとえば「Ｃ」プログラミング言語）で書かれたプラットフォーム独立型ユーザアプリケーションプログラムにある。このようなプログラムは、表１および表２に示されたものと非常によく似たものとなる。
【００３３】
ステップ１２０では、アプリケーションプログラムがピース（ｐｉｅｃｅｓ）にコンパイルされる。「ピース」という用語を使用するのは、ユーザアプリケーションプログラムが第１に解析（パーズ）された後、変換可能になるという事実を単に言い表すものである。当分野の技術者であれば、「ステートメント」、「式」、および「識別子」などのカテゴリ（すなわちピース）に関して、プログラムのコンパイラ／変換プログラム内部表現が、典型的には抽象構文によって指定されるものであることを理解されよう。
【００３４】
コンパイルの結果、アプリケーションプログラムが、ステップ１３０でピースを使用してパラメトリック陰影付け式のシーケンスに変換される。このようなシーケンスは、典型的には、プラットフォーム独立型３Ｄグラフィックス言語（たとえばＯｐｅｎＧＬ（商標）またはＤｉｒｅｃｔ３Ｄ（商標））コードまたは任意の他のコードにあり、このようなプラットフォーム独立型３Ｄグラフィックス言語に（直接または間接的に）対応するか、あるいはこれを起動する。ＯｐｅｎＧＬ（商標）またはＤｉｒｅｃｔ３Ｄ（商標）コードは、任意のグラフィックコンピュータシステム上で動作する中間レベルコードである。次いでステップ１４０では、プラットフォーム独立型ＯｐｅｎＧＬ（商標）コードの目標が、特定のハードウェアプラットフォームに向けられる。これがステップ１５０で、ステップ１１０の高水準コードと同じ機能性を備えた実行可能コードを生成する。
【００３５】
ジェネレータ１００の正味の効果は、高水準ＲｅｎｄｅｒＭａｎ（商標）コードの目標が特定のプラットフォームに向けられ、高速化されることである。さらにＲｅｎｄｅｒＭａｎ（商標）および高水準陰影付け言語は、一般に、非常に柔軟性があるので、アプリケーションプログラマはこれらをより迅速に実行させることができない。グラフィックスアーキテクチャおよびシステムは非常に首尾良く動作するので、これらの陰影付け言語は「こちらを見て何も質問しないようにさせる」方法で動作する、すなわち装置抽象化ユーティリティである。したがって、ＯｐｅｎＧＬ（商標）、Ｄｉｒｅｃｔ３Ｄ（商標）などのようなパラメトリック陰影付け式へのトランスクリプション（表現形式）を有することで、陰影付け言語をより迅速に実行させるようにすることができる。
【００３６】
ジェネレータシステム１００の詳細な例  図２を参照すると、グラフィックス装置コマンドジェネレータ２００は、本発明の（図１に示されたアーキテクチャ内で動作する場合の）動作の詳細な例を示す。図２は、プラットフォーム独立型ＲｅｎｄｅｒＭａｎ（商標）コードを高速で実行されるプラットフォーム依存型ＯｐｅｎＧＬ（商標）コードに変換する際の、本発明の有用性も強調している。
【００３７】
グラフィックス装置コマンドジェネレータ２００は、ステップ２０２で始まり、制御を即時にステップ２０４に渡す。ステップ２０４では、特定のグラフィックス計算が第１に受け取られる。たとえば、鉛筆の消しゴムを含むシーンをレンダリングするルーチン、すなわち「ｓｕｒｆａｃｅ  ｒｕｂｂｅｒ（）」ルーチンである。ステップ２０６では、「ｓｕｒｆａｃｅ  ｒｕｂｂｅｒ（）」グラフィックス計算は、装置独立型の抽象表現（たとえば、プログラミング言語式）を使用して表される。表３は、このようなグラフィックス計算を例示する。
【００３８】
【表３】
2011022999.tif 000005
【００３９】
グラフィックス計算は、当分野の技術者であれば明らかなように、ＲｅｎｄｅｒＭａｎ（商標）のシェーディング言語関数および手続呼出し（すなわち、表３に太字で示されたＲｅｎｄｅｒＭａｎ（商標）基本命令）を使用して、プラットフォーム独立型ユーザアプリケーションプログラム（すなわち高水準「Ｃ」プログラミング言語）で書かれる。
【００４０】
「ｓｕｒｆａｃｅ  ｒｕｂｂｅｒ（）」ルーチンによってレンダリングされたシーンは、消しゴムが典型的にはほとんど赤またはピンクであるが、白い斑点も少し含まれており、そこから使用されたという事実を反映することになる。このルーチンは２つのカラーを結合するために混合コマンドを使用する。１つのカラーは一定、すなわちピンクの消しゴムカラーである。第２のカラーは１．０、すなわち白である。「ｍｉｘ（）」関数は、次いでピンクの消しゴムカラーと白をランダムな方法で一緒に混合する。このランダムさはテクスチャマップファイル「ｎｏｉｓｅ．ｂｗ」をサンプリングし、０から１の間の値を返す、「ｔｅｘｔｕｒｅ（）」関数を介して達成される。これが０の場合はピンクになる。１の場合は白になる。したがって、表面上のすべての光源を合計する「ｄｉｆｆｕｓｅ（）」関数を使用したパターンになる。このパターンは、消しゴムの端をランダムに横切り、一部分はピンクで一部分は白になる。
【００４１】
ステップ２０８では、標準解析技法を使用して、ステップ２０６からの抽象表現がツリー表現に変換される。これは図３に示されている。関連技術分野でよく知られているように、（典型的には「抽象構文」または「解析」ツリーと呼ばれる）ツリー表現とは、解析された何かを表すデータ構造である。これは、プログラムのコンパイラ／解釈プログラム（インタプリタ）の内部表現として使用されると同時に最適化され、ここからコード生成が実行されることが多い。たとえば、プログラミング言語式「ｐ＝ｔ＋ｃｏｎｖ（ｍ）」の解析ツリーを図６に示す。
【００４２】
図２に戻ると、ステップ２１０では、コストベースのツリー文法認識プログラムを使用して、ツリー表現が処理される。好ましい一実施形態では、使用されるコストベースのツリー文法認識プログラムはｉｂｕｒｇである。ｉｂｕｒｇは、Ｆｒａｓｅｒ等による「Ｅｎｇｉｎｅｅｒｉｎｇ  ａ  Ｓｉｍｐｌｅ，Ｅｆｆｉｃｉｅｎｔ  Ｃｏｄｅ  Ｇｅｎｅｒａｔｏｒ  Ｇｅｎｅｒａｔｏｒ」ＡＣＭ  Ｌｅｔｔｅｒｓ  ｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｌａｎｇｕａｇｅｓ  ａｎｄ  Ｓｙｓｔｅｍｓ（ＵＳＡ  １９９２年９月）に最初に記載された、「コードジェネレータジェネレータ」である。
【００４３】
ｉｂｕｒｇは、関連技術分野でよく知られている。ただし、完璧にするためには、関連付けられたコストと共にバッカス−ナウア記法（ＢＮＦ：Ｂａｃｋｕｓ−Ｎａｕｒ  Ｆｏｒｍ）で文法のツリーパターンを受け入れる、Ｃ言語プログラムとして最も良く説明することができる。本発明でｉｂｕｒｇは、プロセッサの命令セットではなくグラフィックスＡＰＩに適用されるため、これをコストベースのツリー文法認識プログラムとして使用することは新規である。この場合、コストとは、その結果得られる、目標となるプラットフォームに基づいたグラフィックスＡＰＩ基本コマンドの実行時間および資源利用である。
【００４４】
関連技術分野でよく知られているように、ＢＮＦは、プログラミング言語、コマンドセットなどの構文を指定する場合に最も一般的に使用される、メタ構文表記法（ｍｅｔａｓｙｎｔａｔｉｃ  ｎｏｔａｔｉｏｎｓ）の１つである。規則は末端でも非末端でもよい。たとえば、２進数の構文は、以下のように表すことができる。
【００４５】
規則１：ｂｉｎａｒｙ＿ｎｕｍｂｅｒ＝ｂｉｔ［ｂｉｎａｒｙ＿ｎｕｍｂｅｒ］
規則２：ｂｉｔ＝「０」｜「１」
規則１は、２進数（非末端規則）が１ビット（末端規則）であり、その後に任意選択で２進数が続くことを表す。規則２は、１ビットがリテラル０（「０」）または１（「１」）数であることを表す。したがって、規則１および規則２を組み合わせて使用し、任意の２進数を構築することができる。同様に、ＲｅｎｄｅｒＭａｎ（商標）コマンドセットまたは任意の他のグラフィックスＡＰＩ、陰影付け言語などをＢＮＦ形式で指定し、コマンドジェネータ２００を適切に動作させることができる。
【００４６】
次いでｉｂｕｒｇは、ツリーパターンマッチングを実行し、コンパイル時に動的プログラミングを実行するハードコードを生成する。本発明は、以下で説明するように性能を向上させるために、ｉｂｕｒｇのコスト処理を変更する。任意のイベントでｉｂｕｒｇによって処理された図３のツリーを図４に示す。図４のツリー表現は、ツリー上での標準解析技法とラベルとの積が、最低コストの変換を発行するのに使用できるｉｂｕｒｇからの最低コストラベリングを識別することを反映している。したがってプラットフォーム依存型の目標設定（図１のステップ１４０に示す）は、ＲｅｎｄｅｒＭａｎ（商標）にＢＮＦを指定するときおよびｉｂｕｒｇを処理するときに定義されたコストを使用することによって達成される。例示的プラットフォームに関連付けられたコストを伴うｉｂｕｒｇへの入力が付録Ａに示され、変換を実行させるＣコード表現が付録Ｂに示されている。
【００４７】
図２に戻ると、ステップ２１２では、ステップ２１０の処理の結果、基礎となるグラフィックスＡＰＩに関して抽象計算を実現する、手順および関数呼出しの効率的なシーケンス（すなわち基本命令）が得られる。好ましい一実施形態では、基礎となるグラフィックスＡＰＩは、ＲｅｎｄｅｒＭａｎ（商標）からＯｐｅｎＧＬ（商標）への変換を完了するためのＯｐｅｎＧＬ（商標）である。付録Ｃでは、結果としてステップ２１２で表３に示されたオリジナルのＲｅｎｄｅｒＭａｎ（商標）コードから得られる、例示的なプラットフォーム特有の高速実行ＯｐｅｎＧＬ（商標）ソースコードを示す。代替の一実施形態では、ステップ２１２は手順および関数の効率的なシーケンスを生成するだけでなく、ｉｂｕｒｇのコスト関数を利用することで、最低コストのシーケンスも生成する。
【００４８】
最後にステップ２１４では、Ｃコンパイラを介して付録Ｃからのテキストを実行し、これを適切なＯｐｅｎＧＬ（商標）ライブラリとリンクさせることで、手順および関数のシーケンスが実行される。したがって、グラフィックス計算（すなわち「ｓｕｒｆａｃｅ＿ｒｕｂｂｅｒ（）」ルーチン）が達成され、ステップ２１６でグラフィックス装置コマンドジェネレータ２００が終了する。
【００４９】
変換の詳細
上記で、グラフィックス装置コマンドジェネレータ２００（図２に表示）は、ＲｅｎｄｅｒＭａｎ（商標）陰影付け言語コードがパラメトリックＯｐｅｎＧＬ（商標）コードにどのように変換されるかを例示している。より具体的に言えば、付録Ｂのコードは、表３の入力を使用して、付録Ａのｉｂｕｒｇ制御ファイルから付録Ｃの出力を生成する。次に、変換（すなわちステップ２０８〜２１２）をより詳細に説明する。
【００５０】
第１に、図３に示すように、付録Ａからのテキストが解析ツリーデータ構造に解析される。このステップは、高水準Ｃプログラミング言語の「ｍａｉｎ（）」制御関数から呼び出された「ｒｅａｄｑｕａｄｓ（ａｒｇｖ［１］，＆ｓ）」関数によって完了される。任意の標準解析技法を使用することができる。一般的な解析ツールには、ｙａｃｃ（たいていのＵｎｉｘシステムに見られる）またはｂｉｓｏｎ（ｙａｃｃのＧＮＵバージョン）が含まれ、これらはどちらも関連技術分野でよく知られているものである。
【００５１】
この時点で、任意の典型的な他の解析作業が実行できる。この例では、変数使用法情報が、「ｎｅｘｔｕｓｅ（）」関数の参照を、ツリーの各ノード上で先行順（ｐｒｅ−ｏｒｄｅｒ）で起動される「ｗａｌｋｐｒｅｏｒｄｅｒ」関数に渡すことで計算される。このステップは、ｉｂｕｒｇまたはよりナイーブな変換技法が採用された場合に実行される。
【００５２】
次に、ｉｂｕｒｇ方法が実行されることによって計算が必要になる。これにより、図３に示された解析ツリーデータ構造に注釈が付けられ、図４に示された解析ツリーデータ構造を生成する。解析ツリーデータ構造のラベリングは、Ｆｒａｓｅｒ等で提案されたように、「ｂｕｒｍ＿ｌａｂｅｌ（）」関数を呼び出すだけの「ｌａｂｅｌ（）」関数によって計算される。これは「ｃｏｖｅｒ」の計算として知られる。ここで、解析ツリーデータ構造内に各ノードに関連付けられた規則があり、これらはＦｒａｓｅｒ等で詳細に記載されたようにテーブルベースの形式であるが、これらにアクセスできる方法は、トップダウン（すなわち順序（ｉｎ−ｏｒｄｅｒ））走査のみである。
【００５３】
適切な出力を発行するには、出力生成段階でツリーが後順で走査され、各ノードの規則情報にアクセスしなければならない。これを実行するにはいくつかの方法がある。好ましい一実施形態では、解析ツリーは「ｒｅｄｕｃｅ（）」関数を使って先行順様式で走査されると同時に、ノードに関連付けられたデータを解析ツリー内に格納する。先行順の「ｒｅｄｕｃｅ（）」関数についても、Ｆｒａｓｅｒ等に詳細に説明されている。
【００５４】
次に、出力シェーダー用のヘッダ情報が計算される。これは、すべての出力が共用する情報である。次いで、図４に示された注釈を付けられた解析ツリーが後順で走査され、各ノード用に「ｖｉｓｉｔ（）」関数が呼び出される。ノードと共に格納された規則が顧慮され、その後適切な出力が印刷される。最後に、出力用のトレーラ（後書き）が印刷される。この情報も、すべての出力が共用する。この段階で、出力は、ＯｐｅｎＧＬ（商標）への呼出しを備えたＣプログラミング言語関数からなり、この呼出しが、付録Ｃに表示されたパラメトリック陰影付け基本命令と共に表３にリストされた手続き型陰影付け記述を実施する。
【００５５】
付録Ｄには、比較の目的で、どのようなｉｂｕｒｇ技法も使用しないナイーブな変換プログラムから生成された出力が示されている。これは、特に「ｍｉｘ（）」演算子用にかなり多くのＯｐｅｎＧＬ（商標）コードを生成するため、関連技術分野の技術者であれば理解されるように、効率が悪い。このようなプログラムは、解析ツリー内でノードがどのように表されるか、またはもっと効率の良い符号化が存在するかどうかという所与の情報にかかわらず、解析ツリーの各ノードが計算されるときに単にこれに対してコードを発行するだけである。付録Ｃのドローイングパス（作図パス）の数は２であるが、付録Ｄのドローイングパスの数は１４である。
【００５６】
本発明を実施するためのｉｂｕｒｇの変更
第１に、本発明でｉｂｕｒｇを使用すると、単にグラフィックス装置コマンドジェネレータ２００が機能強化されることに留意することが重要である。ｉｂｕｒｇを使用すると、変換時に「廉価な」（すなわち基礎となるハードウェアに関してコストが低くなる）ＯｐｅｎＧＬ（商標）コマンドを選ぶことができるので、ステップ２１２で、効率の良い（または最もコストの低い）シーケンスを取得することができる。ただし、グラフィックス装置コマンドジェネレータ２００は、他を介して常にある一定の基本コマンドを選び、その結果ｉｂｕｒｇをまったく使用しないように構成できる。この結果として、ステップ２１２でＯｐｅｎＧＬ（商標）の手順および関数呼出しのシーケンスが得られ、これはＲｅｎｄｅｒＭａｎ（商標）で表されるレンダリングを達成するが、最低コストであったり効率的であったりする必要はない（たとえば付録Ｄ）。
【００５７】
前述のように、本発明は、性能を向上させるために標準のｉｂｕｒｇを変更する。ｉｂｕｒｇは、コストを伴うツリー文法解析である。このコストは、入力ツリーの複数のあいまいなラベリング（解析）の中から選択するのに使用される。付録Ａを参照すること。ｉｂｕｒｇは、一定で整数値のコストのみが可能である。したがって、ｉｂｕｒｇ規則は、以下のようになる。
【００５８】
ｎｏｎ−ｔｅｒｍｉｎａｌ：ｔｒｅｅ  ｒｕｌｅＮｕｍｂｅｒ（ｃｏｓｔ）；
コスト項は負でなく、暗黙に増分する。すなわち以下のようになる。
【００５９】
ｃｏｓｔ（ｎｏｎ−ｔｅｒｍｉｎａｌ）＝ｃｏｓｔ＋ｃｏｓｔ（ｔｒｅｅ）  
本発明は、増分コストを規則の右側要素の関数およびその属性にできるようにｉｂｕｒｇを修正する（または異なるアルゴリズムを使用することができる）。これには２つの理由があり、１つは利便性のため、もう１つは必要性のためである。
【００６０】
第１に、利便性のための場合、規則の総数も性能に影響を与えるので、これをできる限り少なく維持することが望ましい。一定コストのｉｂｕｒｇが使用される場合、たとえば、すべての異なるピクセルパイプ構成のコストを表すために、結果的に規則の組み合わせが爆発的に増加する。この代わりに、コストが右側要素の関数であれば、ピクセルパイプを表す規則の数を（２number of stagesではなく）ピクセルパイプ内の段階数まで減少させることができる。次いで、ピクセルパイプ内の特定の段階を使用可能にするコストは、すでに使用可能化された段階の関数として表される。
【００６１】
第２に、必要性のための場合、コストはタイルサイズ、データタイプその他などの実行時属性の関数でなければならない。これが実行されないと、ハードウェアを介して最低コストが保証されたパスを選択することはできず、代わりにある種の最低平均コストパスが選択されることになる。多くのグラフィックス装置（ハードウェア）でのピクセル操作の実行速度は非常に変化しやすく、タイルサイズなどの実行持続性に依存しているので、最低平均コスト評価は操作の真のコストを表すものとは言えない。
【００６２】
環境
本発明は、ハードウェア、ソフトウェア、またはこれらの組み合わせを使用して実施することが可能であり、コンピュータシステムまたは他の処理システム内で実施することが可能である。実際に一実施形態では、本発明は、本明細書に記載された機能を実行できるコンピュータシステムを対象としている。コンピュータシステム５００の一例が、図５に示されている。コンピュータシステム５００には、プロセッサ５０４などの１つまたは複数のプロセッサが含まれる。プロセッサ５０４は、通信バス５０６に接続される。この例示的コンピュータシステムに関して、様々なソフトウェアの実施形態が記載されている。関連技術分野の技術者が本明細書を読めば、他のコンピュータシステムおよび／またはコンピュータアーキテクチャを使用して本発明を実施する方法が明らかになるであろう。
【００６３】
コンピュータシステム５００には、主メモリ５０８、好ましくはランダムアクセスメモリ（ＲＡＭ）も含まれており、２次メモリ５１０も含むことができる。２次メモリ５１０は、たとえばハードディスクドライブ５１２、および／またはフロッピィディスクドライブ、磁気テープドライブ、光ディスクドライブなどを表す取外し可能記憶ドライブ５１４を含むことができる。取外し可能記憶ドライブ５１４は、取外し可能記憶ユニット５１８との間で読取りおよび／または書込みをよく知られた方式で実行する。取外し可能記憶ユニット５１８は、フロッピィディスク、磁気テープ、光ディスクなどを表し、取外し可能記憶ドライブ５１４によって読み取られ、そこへ書き込まれる。取外し可能記憶ユニット５１８が、コンピュータソフトウェアおよび／またはデータが格納されたコンピュータ使用可能記憶媒体を含むことは明らかであろう。
【００６４】
代替実施形態では、２次メモリ５１０が、コンピュータプログラムまたは他の命令をコンピュータシステム５００にロードできるようにするための、他の同様の手段を含むことができる。このような手段は、たとえば取外し可能記憶ユニット５２２およびインターフェース５２０を含むことができる。このような例には、（ビデオゲーム装置に見られるような）プログラムカートリッジおよびカートリッジインターフェース、（ＥＰＲＯＭまたはＰＲＯＭなどの）取外し可能メモリチップおよび関連付けられたソケット、ならびに、ソフトウェアおよびデータを取外し可能記憶ユニット５２２からコンピュータシステム５００に転送できるようにする、他の取外し可能記憶ユニット５２２およびインターフェース５２０を含むことができる。
【００６５】
コンピュータシステム５００は、通信インターフェース５２４も含むことができる。通信インターフェース５２４は、ソフトウェアおよびデータをコンピュータシステム５００と外部装置との間で転送できるようにするものである。通信インターフェース５２４の例には、モデム、ネットワークインターフェース（イーサネットカードなど）、通信ポート、ＰＣＭＣＩＡスロットおよびカードなどを含むことができる。通信インターフェース５２４を介して転送されるソフトウェアおよびデータは、通信インターフェース５２４が受け取ることのできる形式の信号５２８であり、電子信号、電磁信号、光信号、または他の信号が可能である。これらの信号５２８は、通信パス（すなわちチャネル）５２６を介して通信インターフェース５２４に送られる。このチャネル５２６は信号５２８を搬送し、ワイアまたはケーブル、光ファイバ、電話回線、携帯電話リンク、ＲＦリンクおよび他の通信チャネルを使用して実施することができる。
【００６６】
本文書では、「コンピュータプログラム媒体」および「コンピュータ使用可能媒体」という用語は、一般に取外し可能記憶ドライブ５１４、ハードディスクドライブ５１２にインストールされたハードディスク、および信号５２８などの媒体を言い表すのに使用される。これらのコンピュータプログラム製品は、ソフトウェアをコンピュータシステム５００に提供するための手段である。
【００６７】
コンピュータプログラム（コンピュータ制御論理とも呼ばれる）は、主メモリ５０８および／または２次メモリ５１０に格納される。コンピュータプログラムは、通信インターフェース５２４を介しても受け取ることができる。このようなコンピュータプログラムが実行されると、本明細書で論じたように、コンピュータシステム５００に本発明の特徴を実行させることができる。具体的に言えば、コンピュータプログラムが実行されると、プロセッサ５０４に本発明の特徴を実行させることができる。したがって、このようなコンピュータプログラムは、コンピュータシステム５００の制御装置を表す。
【００６８】
ソフトウェアを使用して本発明が実施される一実施形態では、ソフトウェアは、取外し可能記憶ドライブ５１４、ハードドライブ５１２、または通信インターフェース５２４を使用して、コンピュータプログラム製品内に格納され、コンピュータシステム５００にロードされる。制御論理（ソフトウェア）はプロセッサ５０４によって実行されると、本明細書に記載されたように、プロセッサ５０４に本発明の関数を実行させる。
【００６９】
他の実施形態では、本発明は、たとえば特定用途向け集積回路（ＡＳＩＣ）などのハードウェア構成要素を使用して、主としてハードウェア内で実施される。本明細書に記載された関数を実行するようにハードウェア状態マシンを実施することは、関連技術分野の技術者には明らかであろう。
【００７０】
他の実施形態では、本発明はハードウェアとソフトウェアの両方を組み合わせて使用することで実施される。
【００７１】
結論
適切なＲｅｎｄｅｒＭａｎ（商標）およびＯｐｅｎＧＬ（商標）ライブラリを含むコンピュータシステム５００は、本発明をサポートできる単なる一例として記載されている。もちろん、このようなＯｐｅｎＧＬ（商標）グラフィックスＡＰＩアーキテクチャシステムは、動作するために本発明を含む必要はない。言い換えれば、ＯｐｅｎＧＬ（商標）グラフィックスＡＰＩアーキテクチャは、本明細書に記載したような本発明の利点を使用せずに、レンダリングを提供することができる。したがって、ＯｐｅｎＧＬ（商標）のライセンス保有者は、そのライセンス契約の下で、本発明を使用する権利が自動的に与えられるものではない。
【００７２】
以上、本発明の様々な実施形態について説明してきたが、これらは例示のために示したものであって、本発明を限定するものではないことを理解されよう。本発明の精神および範囲を逸脱することなく、形式および細部の様々な変更を実行できることが、関連分野の技術者には明らかであろう。したがって本発明は、前述のどのような例示的実施形態によっても制限されるものではなく、特許請求の範囲およびこれの均等物によってのみ規定されるものである。
【００７３】
2011022999.tif 000006
【００７４】
2011022999.tif 000007
【００７５】
2011022999.tif 000008
【００７６】
2011022999.tif 000009
【００７７】
2011022999.tif 000010
【００７８】
2011022999.tif 000011
【００７９】
2011022999.tif 000012
【００８０】
2011022999.tif 000013
【００８１】
2011022999.tif 000014
【００８２】
2011022999.tif 000015
【００８３】
2011022999.tif 000016
【００８４】
2011022999.tif 000017
【００８５】
2011022999.tif 000018
【００８６】
2011022999.tif 000019
【００８７】
2011022999.tif 000020
【図１】
2011022999.tif 000021
【図２】
2011022999.tif 000022
【図３】
2011022999.tif 000023
【図４】
2011022999.tif 000024
【図５】
2011022999.tif 000025
【図６】
2011022999.tif 000026