JP2005521179A - シェーダプログラムを発生するシステム、方法およびコンピュータプログラム製品 - Google Patents

Abstract

シェーダプログラム160を発生する（図１Ａ−１）ための方法およびコンピュータプログラム製品202が提供される。最初に、グラフィックス効果と関連付けられたファイル202が選択される。その後、このようなファイル202が読出されて処理される。続いてこのファイルの処理に基づいて、シェーダプログラム160が発生され、そのグラフィックス効果をオブジェクトに適用する。

Description

本発明は、コンピュータグラフィックスに関し、とくに、グラフィックスパイプライン内におけるシェーディング操作に関する。

３Ｄグラフィックスの描写および表示は、典型的に、多くの計算およびコンピュータ操作を必要とする。たとえば、３Ｄオブジェクトを描写するために、描写されるオブジェクトを規定する座標点または頂点のセットが形成されなければならない。頂点は線で結ばれ、描写され、表示されるべきオブジェクトの表面を規定する多角形を形成することができる。オブジェクトを規定する頂点が形成されると、その頂点はオブジェクトまたはモデル基準系からワールド基準系に、および最終的には、モニタのような平坦な表示装置上に表示されることのできる２Ｄ座標に変換されなければならない。頂点は可視領域外に位置しているため、それらは途中で回転、スケール、削除、あるいはクリップを行われ、種々の照明方式および照明源によって照明され、彩色等をされてもよい。３Ｄオブジェクトを描写し、表示するのに必要とされるプロセスは、計算集中的なものに
なる可能性が高く、非常に多くの頂点を必要とする可能性がある。

３Ｄコンピュータグラフィック表示を生成するために、第１のステップは、描かれることとなるオブジェクトをコンピュータ内で数学的モデルとして表現することである。３Ｄモデルは、ｘ、ｙおよびｚ軸からなる座標系内の幾何学的な点から構成され、これらの軸は幅、高さおよび深さにそれぞれ対応している。オブジェクトは、一連の、頂点と呼ばれる点によって規定されている。ある点、すなわち、頂点の位置は、そのｘ、ｙおよびｚ座標によって規定される。これらの点の３個以上のものが線で結ばれたとき、ある多角形が形成される。最も簡単な多角形は、三角形である。

３Ｄ形状は、多数の２Ｄ多角形を線で結びつけることにより生成される。曲面は多数の小さい多角形を結びつけることによって表される。多角形のアウトラインから構成された３Ｄ形状のビューは、ワイヤフレームビューと呼ばれる。要するに、コンピュータは多数の２Ｄ多角形を結びつけることにより３Ｄオブジェクトを生成する。しかしながら、３Ｄオブジェクトが最終的に２Ｄ表示スクリーン上に描写される前に、非常に複雑なグラフィックスオブジェクトのデータは、著しく専用化された方程式および３Ｄ表現に特有の処理を含む多数の異なった数学的変換を行われなければならない。

３Ｄ描写（レンダリング）システムは、かなり前からオブジェクトの“外観”をパラメータにしたがって描写することができている。これらおよびもっと新しい方法は、オブジェクトの表面の位置および向きならびにそれを照明する光源に基づいて、そのオブジェクトの知覚された色のパラメータ化を行う。それを行っているときに、それらからオブジェクトの外観が計算される。パラメータはさらに、拡散色、鏡面反射係数、鏡面の色、反射率、およびオブジェクトの材料の透明度のような値を含んでいる。このようなパラメータは、まとめて、オブジェクトのシェーディングパラメータと呼ばれている。

初期のシステムは、ある単一の値をシェーディングパラメータに属するものと考えることしかできず、したがって、それらはオブジェクトの表面全体にわたって一定不変で均一なままであった。後期のシステムは、オブジェクトの種々の部分に対して種々の値を有する可能性のある均一でないパラメータ（たとえば、透明度）の使用を考慮に入れた。２つの重要で明確な技術である手続き的シェーディングおよびテクスチャマッピングは、オブジェクトの表面の種々の部分に関してこれらの均一でないパラメータによりとられる値を描写するために使用されている。テクスチャマッピングは画素ベースであり、また、解像度依存性である。

手続き的シェーディングは、１Ｄ、２Ｄまたは３Ｄ空間の任意の地点における材料の外観を、この空間中においてある機能（しばしば、手続き的シェーダと呼ばれる）を規定することによりシェーディングパラメータ空間中に描写する。オブジェクトは元の１Ｄ、２Ｄまたは３Ｄ空間に“埋め（ｉｍｍｅｒｓｅ）られ”、そのオブジェクトの表面の所定の点におけるシェーディングパラメータの値は、この点における手続き的シェーディング機能の結果として定義される。たとえば、樹木、大理石または別の天然素材の外観を近似する手続き的シェーダが開発されており、文献に記載されている。

コンピュータシステム中でのグラフィックスデータの描写はリソース集中プロセスの集まりである。シェーディングのプロセス、すなわち、グラフィックスデータ構造に関連した色等のあるプリミティブの値を決定するために使用される専用化されたグラフィックスデータ構造のセットに関する複雑な技術を行うプロセスは、このような計算集中的で複雑なプロセスを例示する。各アプリケーション開発者が開発された各プログラム対してこれらのシェーディング技術を設計し、および、または潜在的にさまざまである第３パーティのグラフィックスハードウェアに対して各プログラムを設計することは非常に困難な作業であり、矛盾が生じる。

当然の結果として、一般に、シェーディングのプロセスは、ある程度正規化されている。シェーダと共に動作するように設計されたソースコードをアプリケーションに送ることにより、シェーダは、そのアプリケーションが複雑なビデオグラフィックスの効率的な描写を容易にするために生成する／使用することのできるオブジェクトになる。頂点シェーダと画素シェーダがこのようなシェーダの例である。

現在の専用化されたハードウェアチップにおける構成の前には、頂点および画素は時として完全にまたはほぼソフトウェアコードとして構成され、また、時にはハードウェアのもっと堅牢な部分とそのハードウェアを制御するソフトウェアの組合せとして構成された。これらの構成はＣＰＵを含むか、あるいはシステムのＣＰＵを使用するものの存在をエミュレートすることが多かった。たとえば、ハードウェア構成は、シェーディングタスクの必要とされる処理機能を行うためにＣＰＵチップをそれらの設計中に直接集積した。標準的な処理チップが提供する機能の範囲のために、ＣＰＵは多くのフレキシビリティをシェーディングプロセスに付加するが、ＣＰＵの組込みはオーバーヘッドを専用化されたシェーディングプロセスに付加する。しかしながら、今日のような最新のハードウェア技術が存在しなかったために、選択肢はほとんどなかった。

しかし、ハードウェアテクノロジーにおける現在の進歩は、前にソフトウェアで実施された機能を専用化されたハードウェアに移動する能力を促進している。結果的に、今日の画素および頂点シェーダは、専用化されたプログラム可能なハードウェアチップとして構成されている。

残念ながら、新しい頂点および画素エンジンのようなプログラミングは、これまで要求されたことのないアートおよびコードリソースの組合せを必要とする。いくつかのデジタル内容生成（ＤＣＣ）アプリケーションは、それらが進行する限り、頂点および画素シェーダをサポートする優れたジョブを行っているが、しかし、アーティストを一人前のシェーダプログラマーにすることなく、種々のシェーデイングオプションでプレイすることを可能にする方法は明らかになっていない。

シェーダプログラムを発生するための方法およびコンピュータプログラム製品が提供される。最初に、グラフィックス効果と関連付けられたファイルが選択される。その後、このようなファイルが読出されて処理される。シェーダプログラムは、それに続いてこのファイルの処理に基づいて発生され、そのグラフィックス効果をオブジェクトに適用する。したがって、シェーダプログラムは、表示または別の目的のためにオブジェクトに対して適当に適用されてもよい。

１実施形態において、ファイルは、特有のグラフィックス効果にそれぞれ関連付けられたファイルのライブラリから選択されることができる。さらに、ファイルは、種々のグラフィックスアプリケーションプログラムインターフェースに対してシェーダプログラムを発生するように処理されることのできるインターフェースデータを含んでいてもよい。同様に、ファイルは、種々のハードウェアグラフィックスパイプラインプラットホームに対してシェーダプログラムを発生するように処理されることのできるインプリメンテーションデータを含んでいてもよい。したがって、ファイルは、種々の異なったグラフィックスアプリケーションプログラムインターフェース［すなわち、ＯｐｅｎＧＬ（Ｒ）、Ｄｉｒｅｃｔ３Ｄ（登録商標）、等］および種々のプラットホーム（すなわち、種々の企業によって製造されているハードウェアグラフィックスチップ）と協力して動作するシェーダプログラムを発生するやり方で処理されてもよい。

別の実施形態において、ファイルは、拡張可能なマークアップ言語（ＸＭＬ）で書込まれてもよい。さらに、ファイルはテキストファイルを含んでいてもよい。またさらに、選択、読出し、処理および発生は、インターフェース［すなわち、コンポーネントオブジェクトモデル（ＣＯＭ）］、プラグイン等を使用して行われてもよい。

オプションとして、ファイルは、そのファイルに関連付けられたグラフィックス効果を識別する本文描写オブジェクトを有するデータ構造の形態をとってもよい。さらに、シェーダプログラムを発生するために必要な要求を識別する要求オブジェクトが設けられていてもよい。

したがって、ファイルは要求を含んでおり、その要求に基づいてシェーダプログラムが発生されてもよい。一般に、要求は、随意に注文にしたがって変更されることのできる要求の省略時セットを含んでいてもよい。随意で、その要求はコールバック機能を含んでいてもよい。

ファイルはさらに、複数の動作環境（すなわち、プラットホームインプリメンテーション、インターフェース等）においてグラフィックス効果を実行することができる複数のシェーダコードセグメントとを含んでいてもよい。このようなシェーダコードセグメントは、種々の動作環境に関して編成されることができる。したがって、この実施形態は、随意に、所望のシェーダコードセグメントを得るための基準として使用されることができる。

１つの特定の実施形態の動作中、インターフェースを初期化することが処理に含まれてもよい。このような処理にはさらに、注文タイプおよび、または注文機能を登録することが含まれてもよい。したがって、シェーダプログラムは、登録された注文タイプおよび、または注文機能に基づいて発生されることができる。この特徴により、この実施形態は、ユーザが結果的に得られるしぇーだプログラムをカストマイズすることを可能にする。

さらに、複数のオブジェクトを設定し、オブジェクトの１つを選択し、複数のグラフィックス効果の１つを選択し、描写パスを選択し、描写パスを設定し、選択されたグラフィックスオブジェクトによりオブジェクトを描くことが処理に含まれてもよい。オプションとして、描写パスは、シェーダプログラムがパラメータに基づいて発生されるようにそのパラメータを指示することによって設定されてもよい。さらに、オブジェクトは選択されたグラフィックス効果によってアプリケーションにより提供された属性を使用して描かれてもよい。

レンダリングパスの期間中、描写パスがもっと存在するか否かが決定され、描写パスがもっと存在する場合は別の描写パスが選択されてもよい。さらに、オブジェクトがもっと存在するか否かが決定され、オブジェクトがもっと存在する場合は別のオブジェクトが選択されてもよい。またさらに、グラフィックス効果がもっと存在するか否かが決定され、グラフィックス効果がもっと存在する場合は別のグラフィックス効果が選択されてもよい。

上述した機能を行うために使用されることのできる１例のシステムは、インターフェースと、ファイルを処理するために協力するアプリケーションプログラムとを備えていてもよい。したがって、オブジェクトにグラフィックス効果を適用するために、シェーダプログラムはファイルの処理に基づいて発生される。

最初に述べたように、処理には、複数のオブジェクトを設定することが含まれる。このシステム実施形態に関連した適用から見ると、これは、グラフィックス効果に関連したファイルを選択し、グラフィックスアプリケーションプログラムインターフェースを選択し、この選択に基づいて複数の種々のハードウェアグラフィックスパイプラインプラットホームを表現するインプリメンテーションデータを受取ることによって行われてもよい。次に、インプリメンテーションデータに基づいてパラメータが受取られる。さらに、どのハードウェアグラフィックスパイプラインプラットホームを使用すべきかが少なくとも部分的にパラメータに基づいて決定されてもよい。この決定により、シェーダプログラムは、適切なハードウェアグラフィックスパイプラインプラットホームにより使用されるために発生される。

オプションとして、どのハードウェアグラフィックスパイプラインプラットホームが使用されるかに関する決定は、パラメータが提供されることができるか否かに基づいてもよい。さらに、どのハードウェアグラフィックスパイプラインプラットホームが使用されるかに関する決定は、パラメータがアプリケーションによって理解された（すなわち、正しく解釈されることができる）か否かに基づいている。このような決定がなされると、オブジェクトの属性がパラメータにマップされる。

このシステム実施形態に関連したインターフェースから見ると、オブジェクトは複数の異なったハードウェアグラフィックスパイプラインプラットホームを表現するインプリメンテーションデータを発生することにより設定される。その後、そのインプリメンテーションデータに基づいて、パラメータが発生される。さらに、インターフェースはアプリケーションと協力して、どのハードウェアグラフィックスパイプラインプラットホームが使用されるべきかに関する決定をパラメータに基づいて行う。

随意選択に、インプリメンテーションデータは、種々のハードウェアグラフィックスパイプラインプラットホームが複数の要求を満足させるか否かを決定することにより発生されてもよい。インプリメンテーションデータはさらに、要求を満たす種々のハードウェアグラフィックスパイプラインプラットホームを分類することにより発生されてもよい。

ライセンス契約を発生するコンピュータ実施方法は上述したフレームワークに関連付けられる。最初に、メモリ中に記憶されたライセンス契約が識別される。次に、このライセンス契約に関連付けられたファイルが識別される。その後、１以上のファイルが分配可能であるか否かが決定される。１以上のファイルが分配可能でないことが決定された場合、非公開項がライセンス契約中に含まれる。

ファイルが分配可能であるか否かを決定する別のコンピュータ実施方法が提供される。このような方法は、メモリ中に記憶されたファイルを識別し、ファイルが分配可能であるか否かを決定し、ファイルが分配可能であるか否かを単に示すことを含んでいてもよい。

ユーザがシェーダプログラムを視覚的に実験して使用することを可能にするために、オプションのグラフィックユーザインターフェースが提供される。使用において、上述のグラフィックス効果はこのようなグラフィックユーザインターフェースを使用して表示されてもよい。さらに、グラフィックス効果は、ユーザによりそのグラフィックユーザインターフェースを使用して変更されることが可能であってもよい。とくに、グラフィックス効果は、パラメータを変更することにより変更されることが可能であってよく、また、この変更されたパラメータに基づいてシェーダプログラムが発生されてもよい。このようなパラメータは、上述したファイルをツイーク（ｔｗｅａｋ）することによって変更されてもよい。

また、ユーザが１つのグラフィックス効果を選択することを可能にするために複数のグラフィックス効果が表示される別のグラフィックユーザインターフェースが提供されることができる。このような選択されたグラフィックス効果は、その後オブジェクトに適用されたときにファイルを使用して表示される。さらに、そのファイルはユーザ入力に基づいて修正され、このファイルは処理される。このようにして、シェーダプログラムはファイルの処理に基づいて発生されてもよい。

さらにオプションとして、インターフェースはプリミティブを発生することができる。さらに、ファイルは名称、タイプおよび内容を含む構文を含んでいてもよい。またさらに、ファイルは、コンパイルされたコードとコンパイルされていないコードの両者を参照とすることが可能であってもよい。

本発明のこれらおよびその他の利点は、以下の詳細な説明および添付図面から明らかになるであろう。

上記およびその他の特徴および利点は、本発明の好ましい実施形態の以下の詳細な説明から図面を参照とすることによりさらによく認識される。
図１Ａは、１実施形態によるデジタル処理システムのブロック図である。図１Ａを参照とすると、コンピュータ10を使用して構成されることのできるコンピュータグラフィックスシステムが提供される。コンピュータ10は、通信バス12に接続されたプロセッサ11のような１以上のプロセッサを備えている。バス12は１以上の集積回路により構成され、ある論理機能を行うことが可能であり、たとえば、典型的なパーソナルコンピュータはノースブリッジ（ｎｏｒｔｈ ｂｒｉｄｇｅ）およびサウスブリッジ（ｓｏｕｔｈ ｂｒｉｄｇｅ）チップとして知られているチップを備えている。コンピュータ10はまた、主メモリ14を備えている。制御論理（ソフトウェア）およびデータは、ランダムアクセスメモリ（ＲＡＭ）の形態をとってもよい主メモリ14中に記憶される。コンピュータはまたハードウェアグラフィックスパイプライン18と、および表示装置20、すなわち、コンピュータモニタとを備えている。

コンピュータ10はまた、補助記憶装置16を備えている。補助記憶装置16は、たとえば、フロッピーディスクドライブ、磁気テープドライブ、コンパクトディスクドライブ等を代表するハードディスクドライブおよび、または取外し可能な記憶装置ドライブを備えている。取外し可能な記憶装置ドライブは、取外し可能な記憶装置からの読出しおよび、またはそれに対する書込みをよく知られているやり方で行う。コンピュータプログラム、またはコンピュータ制御論理アルゴリズムは主メモリ14および、または補助記憶装置16中に記億されている。このようなコンピュータプログラムは、実行されたときに、コンピュータ10が種々の機能を行うことを可能にする。したがって、メモリ14および記憶装置16はコンピュータ読出し可能な媒体の例である。

１実施形態において、以下に説明される技術は、ハードウェアの形態をとることのできるハードウェアグラフィックスパイプライン18により行われる。このようなハードウェア構成は、マイクロ制御装置または任意の別のタイプの注文または特定用途向け集積回路（ＡＳＩＣ）を備えていてもよい。さらに別の実施形態においては、本発明の方法は、コンピュータ10の主メモリ14および、または補助記憶装置16中に記億されたコンピュータプログラムによりプロセッサ11上で部分的に行われることができる。以下、図１Ａ−１を参照としてハードウェアグラフィックスパイプライン18に対する１つの例示的なアーキテクチャを説明する。

図１Ａ−１は、図１Ａのハードウェアグラフィックスパイプライン18の例示的な１実施形態の内部構造を示すさらに詳細な図を示している。示されているように、プリミティブをスクリーン整列座標系に変換する幾何学ステージ151が提供される。この幾何学ステージ151によって、プリミティブを描く各頂点の視覚プロパティ（たとえば、色、曲面法線、テクスチャ座標）を決定する照明のような別の計算が行われてもよい。

変換された頂点は、ラスター化装置152に対する入力を形成する。このラスター化装置152は、各プリミティブによってカバーされた各画素に対するフラグメントを計算する。フラグメントと共に記憶されているカバレージマスクは、そのフラグメントが画素のどの部分をカバーするかを示す。

たとえば、テクスチャマップまたはシェーダプログラムをフラグメントに適用すること等により最終的なフラグメントを計算するシェーダ153もまた含まれている。このようなシェーダプログラムは種々の方法で発生されることができる。以下、シェーダプログラムを発生する１つのシステムおよび方法を詳細に説明する。この説明においては、シェーダプログラムは、頂点シェーダプログラム、画素シェーダプログラム、、またはシェーディングを行うことのできる任意の別のタイプのプログラムを指すことができることを認識すべきである。オプションのサンプル拡張ステージ154は各フラグメントに対する多数のサンプルを発生する。

図１Ａ−１を引き続き参照とすると、マルチサンプリング後、個々のサンプルは、それらがまるで正規のフラグメントであるかのようにラスタープロセッサ（ＲＯＰ）155に送られる。ラスタープロセッサ155は、ｚ／ステンシルテストおよびカラーまたはアルファブレンドを行うことを含む種々の操作をフラグメントに関して行う。これは、ラスタープロセッサ155があて先Ｚまたはあて先カラーを検索するためにフレームバッファメモリ156を読出すことを必要とする可能性がある。その後、最終的な画素カラーおよびＺは、フレームバッファメモリ156に戻されて書込まれる。

情景中の全てのプリミティブがこの方法で描写されたとき、フレームバッファメモリ156の内容はビデオリフレッシュ装置157によって走査され、表示装置20に送られる。

１実施形態において、フレームバッファメモリ156（および、おそらく、テクスチャメモリのような別のメモリ）を除くグラフィックスシステム106の上述したコンポーネントの全てが単一の半導体プラットホーム上に配置されてもよい。当然ながら、種々のモジュールもまた、ユーザの所望にしたがって別々に、あるいは半導体プラットホームの種々の組合せで配置されてもよい。

図１Ａおよび１Ａ−１に示された種々のコンポーネントと協力するインターフェースが使用されてもよい。１実施形態において、このようなインターフェースは少なくとも部分的に、Ｏｐｅｎ Ｇｒａｐｈｉｃｓ Ｌｉｂｒａｒｙ［Ｏｐｅｎ ＧＬ（Ｒ）］、Ｄｉｒｅｃｔ３Ｄ（登録商標）アプリケーションプログラムインターフェース（ＡＰＩ）、プロプラエタリアプリケーションプログラムインターフェース等を備えていてもよい。

使用において、図１Ａ−１に示されているシェーダ153により使用されるためにシェーダプログラムが発生されてもよい。最初に、あるグラフィックス効果と関連付けられた単一のファイルが選択される。その後、このようなファイルは読出されて処理される。この説明に関連して、あるファイルは、情報を通信することのできる任意のタイプのデータ構造、データ流、ネットワーク接続等を含んでいてもよい。グラフィックス効果をオブジェクトに適用するために、シェーダプログラムが続いてファイルの処理に基づいて発生される。以下、このような機能を行うときの種々の例示的な技術をさらに詳細に説明する。

図１Ａ−２は、１実施形態にしたがってシェーダプログラムを発生するために使用されることのできる例示的なファイル160を示している。このファイル160は、図１Ａおよび１Ａ−１の上述したアーキテクチャにおいて、あるいは所望される任意の別のアーキテクチャにおいてシェーダプログラムを発生するために使用されてもよいことを認識すべきである。

例示的なファイル160は付録Ａに示されている。付録Ａ中の行は参照のために番号を付けられている。

１実施形態において、ファイル160は、特有のグラフィックス効果とそれぞれ関連付けられたファイルのライブラリから選択されてもよい。内部的に、このようなライブラリは特定のクラスを使用してもよい。このようなクラスは、ファイルシステムに非常によく似た階層データベースであってもよい。それはリンクと機能をサポートし、ユーザ定義タイプおよび機能が既存の機能と置き換わり、混合することを可能にしてもよい。正規の機能と同じ構造を有する揮発性機能を含む別の機能もまた含まれていてもよいが、しかしながら、揮発性機能は常に実行される。さらに、正規の機能の場合のように、パラメータ依存性が変化したか否かをチェックするのに時間は費やされない。揮発性機能と呼ばれる機能はいずれも、その機能の継続期間中は揮発性のものとして扱われる。クラスは、ファイル160が実行時に記憶およびアクセスされることのできる場所である。さらに、クラスは、デバッグおよびアーカイビングを容易にするためにテキストに何時でもダンプされることができる。

オプションとして、クラスは、リンクが同じタイプの有効フィールドを指示していること、および機能が十分に形成されていることを確認するためにコンパイルされてもよい。オプションとして、機能ストリングは内部バイトコードスタイル表現にコンパイルされてもよい。クラスはまた、ある機能が呼出されない場合にはそれが決してコンパイルされないように、ジャストインタイムコンパイレーションをサポートすることができる。リンクおよび機能が正しく、かつ完全に特定されていることを確実にすることが必要とされたとき、クラスのサブツリーがコンパイルされてもよい。

別の実施形態において、ファイル160は、拡張可能なマークアップ言語（ＸＭＬ）で書込まれてもよい。さらに、ファイル160はテキストファイルを含んでいてもよい。付録Ａに示されている例示的なファイル160はＸＭＬで書込まれたものである。

オプションとして、ファイル160は、種々のハードウェアグラフィックスパイプラインプラットホームに対するシェーダプログラムを発生するように処理されることのできるインプリメンテーションデータ161を含んでいてもよい。たとえば、インプリメンテーションデータ161は種々のプラットホーム（すなわち、種々の目的のための、種々のグラフィックス社製のハードウェアグラフィックスチップ）を表現することができる。

さらに、ファイル160は、種々のグラフィックスアプリケーションプログラムインターフェースに対するシェーダプログラムを発生するように処理されることのできるインターフェースデータ162を含んでいてもよい。とくに、ファイル160は、種々の異なったグラフィックスアプリケーションプログラムインターフェース［すなわち、Ｏｐｅｎ ＧＬ（Ｒ）、Ｄｉｒｅｃｔ３Ｄ（登録商標）等］と協力して動作するシェーダプログラムを発生するやり方で処理されてもよい。付録Ａにおいて、３０行目のタグ“＜ｉｍｐｓ＞”はインプリメンテーションを示し、３１行目および３７８行目のタグ“＜ｉｍｐｓ＞”はＤｉｒｅｃｔＸ（登録商標）８およびＯｐｅｎ ＧＬ（Ｒ）のインプリメンテーションの開始をそれぞれ示している。

引き続き図１Ａ−２を参照とすると、ファイルと関連付けられたグラフィックス効果を、直観的に分かるテキストを使用して識別する本文描写オブジェクト164が提供される。たとえば、グラフィックス効果は、図１Ａ−２および付録Ａの２および３行目に示されているように“ｓｈｉｎｙ”特性を含んでいてもよい。もちろん、任意の別のタイプの視覚効果（すなわち、モーションブラー等）が本文描写オブジェクト164によって描写されてもよい。このような本文描写オブジェクト164は、発生されるべきシェーダプログラムに関連付けられたグラフィックス効果が直観的に識別されることを可能にすることが理想的である。

さらに、シェーダプログラムを発生するために必要な要求を識別するために少なくとも１つの要求オブジェクト166が提供される。示されているように、種々の要求は、パス識別子168によって識別された複数の描写パスのそれぞれに対して示されている。たとえば、各描写パスは、タンジェントスペース要求、テクスチャタイプ要求、またはシェーダプログラムを正しく表示するために必要とされる任意の他のタイプの機能だけでなく、要求された種々のテクスチャ、描写状態、マルチパス効果、およびＬベクトルのソースもまた有していてもよい。随意的に、要求はコールバック機能を含することさえ可能である。

付録Ａにおいて、ＤｉｒｅｃｔＸ８に対する要求は、示されている３つのインプリメンテーションに対して潜在的に異なっている：（１）３２行目から始まるインプリメンテーション１は、３７乃至５０行に示された要求を有している；（２）１８５行目から始まるインプリメンテーション２は、１９０乃至１９９行に示された要求を有している；（３）２８２行目から始まるインプリメンテーション３は、２８７乃至２９６行に示された要求を有している。インプリメンテーション２および３は同じ要求を有しているが、しかしインプリメンテーション１は別の要求を有していることに注意されたい。

一般に、要求は、随意に注文にしたがって変更されることのできる要求の省略時セットを含んでいてもよい。このような注文に応じて変更可能な要求、すなわち“ツイーカブルズ（ｔｗｅａｋａｂｌｅｓ）”は、アーティストにより制御可能な特定シェーダ項に対するパラメータを表現する。ツイーカブルズはシェーダプログラムによって要求されるが、必ずしも標準的なツール路を通って公表されるとは限らない。シェーダプログラムの著者は、ショーダプログラムのどの部分をアーティスト操作にさらすべきかを決定してもよい。ツイーカブルズは、透明度ファクタからアルファブレンドファクタまでを範囲とする任意の要求を示すことができる。表１は、図１Ａ−１のファイル160との関連において例示的なツイーカブルズを示している。

付録Ａにおいて、ツイーカブルズは１４乃至２９行に示されている。ツイーカブルズは一般に全てのインプリメンテーションに適応するため、それらは一般にインプリメンテーションの任意のものの指定外である。この例においては、最小値（２２および２３行目）、最大値（２４および２５行目）、ならびにステップサイズ（２６および２７行目）が含まれている。

さらに、複数の動作環境においてグラフィックス効果を実行することのできる複数のシェーダコードセグメント170はファイル160を提供される。示されているように、このようなシェーダコードセグメント170は、名称、タイプおよび内容を含む構文を含んでいる。さらに、ファイルはコンパイルされたシェーダプログラムコードとコンパイルされていないシェーダプログラムコードの両者を参照とすることが可能であってもよい。

図１Ａ−２に示されているように、シェーダコードセグメント170は、種々の動作環境に関して編成されることができる。したがって、この実施形態は随意に、所望のシェーダコードセグメント170を獲得するための基準として使用されてもよい。

付録Ａにおいて、シェーダコードの一例は６０乃至８８行に示されている。
表２は、Ｄｉｒｅｃｔ３Ｄ（Ｒ）８における１つの例示的なシェーダインプリメンテーションの種々のエレメントの要約を示している。

表 ２
１．プリアンブル／宣言：これらのエレメントは、特定のインプリメンテーション／インターフェースに対して優先権を与え、そのインプリメンテーション／インターフェースのストリング描写を行う。
２．要求：これらは、インプリメンテーション／インターフェースが正しく実行するための種々の要求を特定する。とくに、それらは、シェーダに対して必要とされるＤ×８の大文字を含んでいる。全ての要求は、タイプ“ｂｏｏｌ”まで評価を行う。
３．テクスチャハンドル：これらは、テクスチャファイル（すなわち、ｐｎｇ、ｄｄｓ、ｔｇａ等）中のデータから、あるいは正規化立方マップのような発生されたテクスチャから生成されたテクスチャハンドルを示している。このハンドルはファイルの後続するセクションにおいて参照されることができ、また、描写パスまたはテクスチャ装置とは無関係である。
４．頂点シェーダ＆画素シェーダハンドル：これらは、コンパイルされたシェーダストリングから、あるいは予めコンパイルされたシェーダファイルから生成されたｄ×８の提供されたハンドルである。ハンドルはファイルの後続するセクションにおいて参照されることができ、また、描写パスまたはテクスチャ装置とは無関係である。頂点シェーダが適用されることをユーザが所望しない場合、ハンドルは、使用されているＦＶＦコードに設定されてもよい。ユーザがパスとして画素シェーダを指定しなかった場合、それはゼロに設定され、それによって画素シェーディングがオフに切替えられる。
５．頂点マッピング：このセクションは、強く勧告され、奨励されているが、しかし随意である。これは、種々の頂点属性（ｖ０，ｖ１，ｖ５のような）の意味がシェーダプログラムにおいて特定される可能性がある場合である。マッピングを特定し、シェーダプログラムをストリング形式で公表することにより、種々の幾何学レイアウトを有するアプリケーションは、そのシェーダプログラムが新しい幾何学フォーマットにより書き直されることができる。
６．シェーダインプリメンテーションは、それぞれが特有の描写状態、テクスチャステージ状態、頂点マッピング、画素および頂点シェーダを有する多くの描写パスを含んでいることができる。
７．システムの省略時描写およびテクスチャステージ状態を表現するファイルが存在してもよい。描写状態またはテクスチャステージ状態がシェーダプログラムのパスにおいて指定されなかった場合、それはファイルにおいて省略時状態にリセットされる。そのファイルを使用することにより、同じファイルを使用するシェーダプログラムの共同利用性が改善されることができる。変更を行うことが所望されない場合、そのようにすることは可能であるが、しかし描写状態の変化を反映するようにシェーダを更新しなければならないという犠牲を伴なう。

表３は、ＯｐｅｎＧＬ（Ｒ）における例示的なシェーダインプリメンテーションの種々のエレメントの要約を示している。
表 ３
１．プリアンブル／宣言：これらのエレメントは、インプリメンテーション／インターフェースに対して優先権を与え、そのインプリメンテーション／インターフェースのストリング描写を行う。
２．要求：これらは、インプリメンテーション／インターフェースが正しく実行するための種々の要求を特定する。とくに、それらは、シェーダに対して必要とされるＯｐｅｎＧＬ（Ｒ）拡張子を含んでいる。これらが利用できない場合、ＯｐｅｎＧＬインプリメンテーションはシェーダプログラムをロードすることができない。
３．テクスチャハンドル：これらは、テクスチャファイル（すなわち、ｐｎｇ、ｄｄｓ、ｔｇａ等）中のデータから、あるいは正規化立方マップのような発生されたテクスチャから生成されたテクスチャハンドルを示している。ハンドルはファイルの後続するセクションにおいて参照されることができ、また、描写パスまたはテクスチャ装置とは無関係である。
４．シェーダインプリメンテーションは、それぞれが特有の頂点プログラム、テクスチャシェーダおよびレジスタ結合装置定義を有する多くの描写パスを含んでいることができる。

図１Ｂは、１実施形態によるシェーダプログラムを発生する方法1000を示している。この方法1000は、一般に、１以上の３次元オブジェクトでイメージを描写するアプリケーションプログラムの制御下において行われる。この方法1000は上述した図面のフレームワークにより実施されてもよいが、それは任意の所望のアーキテクチャおよびデータ構造により容易に実施されることができる。オプションとして、インターフェース［すなわち、コンポーネントオブジェクトモデル（ＣＯＭ）］、プラグイン等を使用して種々の動作が行われることができる。さらに、シェーダプログラムを発生するために必要とされる処理の過程中、種々のステップが随意に除外され、および、または再追加されることができる。

最初に、動作1020においてインターフェースを初期化することが処理に含まれてもよい。好ましい実施形態において、インターフェースは、効果のライブラリへのＡＰＩであり、プラグインとして構成されることができる。次に、動作1040において、任意の数の注文タイプおよび注文機能が登録される。したがって、シェーダプログラムは登録された注文タイプおよび、または注文機能に基づいて発生されることができる。この特徴により、この実施形態は、ユーザが結果的に得られるシェーダプログラムをカストマイズすることを可能にする。

次に、描写されるオブジェクトの１つが動作1060において選択され、その後、動作1080においてこのようなオブジェクトが設定される。この設定プロセスは、決定1090によって示されているように、描写される複数のオブジェクトのそれぞれに対して行われる。このようにして、複数のオブジェクトが設定される。この処理は、シェーダプログラムが使用される環境と関連付けられたインプリメンテーションおよびインターフェースに関する種々の情報を採取することによりシェーダプロセッサの発生を容易にする。以下では、このような設定動作の例示的な実施形態が図２乃至４を参照として詳細に説明される。

引き続き図１Ｂを参照とすると、オブジェクトの１つが複数のグラフィックス効果の１つおよびある描写パスと共に選択される。これは、動作1100乃至1140で示されている。その後、選択された描写パスは動作1160において設定され、その後、動作1180により示されているように、選択されたオブジェクトが選択されたグラフィックス効果により描かれる。オプションとして、パラメータを指示することにより描写パスが設定されてもよい。その後、そのパラメータに基づいて、シェーダプログラムが発生されてもよい。さらに、オブジェクトは選択されたグラフィックス効果によりあるアプリケーションよって提供された属性を使用して描かれてもよい。描写パス設定1160の期間中にパスされないパラメータは、一般に、ファイル160において提供された省略時値を使用する。パラメータは任意の順序で提供されることができ、また、パラメータへのポインタを使用することにより、パラメータが複数のオブジェクトの間で共用されるメカニズムが提供される。

レンダリングパスの期間中、決定1200により示されているように、描写パスがもっと存在しているか否かが決定されてもよく、描写パスがもっと存在している場合、別の描写パスが選択される。さらに、決定1220により示されているように、グラフィックス効果がもっと存在しているか否かが決定されてもよく、グラフィックス効果がもっと存在している場合、別のグラフィックス効果が選択される。またさらに、決定1240により示されているように、オブジェクトがもっと存在しているか否かが決定されてもよく、オブジェクトがもっと存在している場合、別のオブジェクトが選択される。

ボックス1300の中に含まれている種々の動作は、どの順序で行われてもよいことを認識しなければならない。たとえば、図１Ｃを参照とされたい。当然ながら、動作の任意の可能な置換が使用されることができる。

図２は、図１Ｂおよび１Ｃの動作1080にしたがってオブジェクトが設定される“効果バインディング”方法200を示している。このような方法200は、ファイルを処理するために協力して動作するインターフェース204およびアプリケーションプログラム202を備えた例示的なシステムにおいて行われる。したがって、シェーダプログラムは、グラフィックス効果をオブジェクトに適用するためにファイルの処理に基づいて発生される。もちろん、この方法200は任意の所望のシステムにおいて実施されることができる。

はじめに述べたように、処理には、複数のオブジェクトを設定することが含まれる。このシステム実施形態におけるアプリケーションプログラム202から見ると、これは、動作206において所望のグラフィックス効果と関連付けられたファイルを選択することにより行われてもよい。１実施形態においては、ファイルを読出すために.dllファイルがツールまたはグラフィックスエンジンによって使用されてもよい。

次に、動作208において、グラフィックスアプリケーションプログラムインターフェースが選択される。その後、動作210により示されているように、インターフェース204が呼出される。このような呼出しに応答して、複数の種々のハードウェアグラフィックスパイプラインプラットホームを表現するインプリメンテーションデータは、特定のグラフィックスアプリケーションプログラムインターフェースの選択に基づいて受取られる。１実施形態において、選択されたグラフィックスアプリケーションプログラムインターフェースをサポートするどのプラットホームも、インプリメンテーションデータによって表現されることができる。

次に、動作214によって示されているように、インプリメンテーションデータに基づいてパラメータがリクエストされ、受取られる。さらに、動作218において、どのハードウェアグラフィックスパイプラインプラットホームを使用すべきかがパラメータに基づいて決定されることができる。すぐに明らかになるように、この決定は、インターフェース204と共にアプリケーションプログラム202を使用して行われてもよい。以下には、図４を参照としてこのような決定がさらに詳細に説明される。

このシステム実施形態においてインターフェース204から見ると、動作210の呼出しに応答して、複数の種々のハードウェアグラフィックスパイプラインプラットホームを表現するインプリメンテーションデータを発生することによりオブジェクトが設定される。動作212に注意されたい。以下には、１実施形態にしたがってこれがどのようにして行われるかが、図３を参照としてさらに詳細に説明される。その後、動作216においてインプリメンテーションデータに基づいてパラメータが発生される。はじめに述べたように、動作218においてインターフェース204はアプリケーション202と協力して動作し、どのハードウェアグラフィックスパイプラインプラットホームを使用すべきかを、パラメータに基づいて決定する。

オプションとして、インターフェース204はプリミティブを発生することが可能であってもよい。たとえば、球体はある点と半径から発生されることができる。これは、画素シェーダ（タグ“＜ｐｉｘｅｌｓｈａｄｅｒ＞”により示されている）または頂点シェーダ（タグ“＜ｖｅｒｔｅｘｓｈａｄｅｒ＞”により示されている）に類似している幾何学的生成器（たとえば、タグ“＜ｇｅｏｇｅｎｅｒａｔｏｒ＞”を有する）を規定することによって行われることができる。このプリミティブ発生技術は、多くの状況において有用である可能性がある。たとえば、それは、草または別の類似したオブジェクトを発生するときに使用されることができる。

図３は、図２の動作212にしたがって複数の異なったハードウェアグラフィックスパイプラインプラットホームを表現するインプリメンテーションデータを発生する方法300を示している。この方法300は、インターフェース204内で行われる。この方法300は単なる例示に過ぎず、何等制限を課すものではないと解釈されなければならないことを認識すべきである。

図３に示されているように、動作302においてインプリメンテーションデータが検索され、それによって、たとえば、ファイル160中の全てのインプリメンテーション（付録Ａの３０行目に示されている名称“＜ｉｍｐｓ＞”内の）が発見される。次に、インプリメンテーションデータが現在のファイル中の適切なグラフィックスアプリケーションプログラムインターフェースの下で概略的に示された要求を満たすか否かが決定される。決定304において、要求は満たされることが決定された場合、動作306においてインプリメンテーションデータがあるリスト中で記憶される。これは、ユーザにより提供される浮動小数点優先度を使用して行われてもよい。このプロセスは、選択されたグラフィックスアプリケーションプログラムインターフェースに関連した全てのインプリメンテーションデータに対して続けられる。決定308に注意されたい。

図４は、図２の動作218にしたがってどのハードウェアグラフィックスパイプラインプラットホームを使用すべきかが決定されることができる例示的な方法400を示している。一般に、この方法400はアプリケーション202によって行われる。再び、この方法400は単なる例示に過ぎず、何等制限を課すものではないと解釈されなければならないことを認識すべきである。

最初に動作402において、特定のインプリメンテーションに関連したパラメータが識別される。これは、インターフェースを呼出し、あるインプリメンテーションに対するパラメータのリストをリクエストすることによって行われる。再び、各インプリメンテーションは特定のプラットホーム（すなわち、種々のグラフィックス製造会社により製造されたハードウェアグラフィックスチップ）に対応している。

その後、決定404において、インターフェースによって提供されたパラメータがアプリケーションにより理解されるか否か（すなわち、パラメータ名がアプリケーションにより正しく解釈されるか否か）が決定される。さらに、決定406に示されているように、パラメータがアプリケーションによって提供されることができるか否かが決定される。このインプリメンテーションがそのアプリケーションプログラムにより使用される場合、これらの決定は共に肯定的な応答を与えなければならない。オプションとして、現在の決定はそのアプリケーションプログラム以外のある場所で行われることができる。

次に、動作408においてデータが整合しているか否かが決定される。否である場合、動作407において整合していないデータが補正される。補正動作407には、たとえば、データの順序を入れ換え、および、または、必要とされているデータを既存のデータから形成することが含まれる。前の決定とは異なり、この決定408はインターフェースによって随意に行われることができる。

動作410に示されているように、利用可能なインプリメンテーションのそれぞれに対して上述の決定がなされる。次に、動作412においてグラフィックス効果がオブジェクトに割当てられる。一般に、アプリケーションは、動作402において保存されたインプリメンテーションから選択をする。

ユーザが視覚的に実験してシェーダプログラムを使用することを可能にするために、オプションのグラフィックユーザインタフェースが提供される。使用において、上述されたグラフィックス効果は、グラフィックユーザインターフェースを使用して表示されることができる。さらに、グラフィックス効果は、ユーザがグラフィックユーザインターフェースを使用することにより変更されることが可能であってもよい。とくに、グラフィックス効果は、パラメータ（すなわち、ツイーカブルズ）を変更することにより変更されることが可能であってもよく、シェーダプログラムはその変更されたパラメータに基づいて発生されてもよい。これは、スライダ、編集ボックス等によって行われてもよい。パラメータは関連したファイルをツイークすることにより変更されてもよい。

また、ユーザが１つのグラフィックス効果を選択することを可能にするために複数のグラフィックス効果が表示される別のグラフィックユーザインターフェースが提供されてもよい。その後、このような選択されたグラフィックス効果は、ファイルを使用してオブジェクトに適用されるものとして表示される。さらに、そのファイルはユーザ入力に基づいて修正され、ファイルが処理される。したがって、シェーダプログラムは、ファイルの処理に基づいて発生されることができる。

図５は、本発明に関連した取引方法500を示している。使用において、ファイル（すなわち、図１Ａ−１参照）はライセンス契約により販売されるか、あるいはその他の方法で分配されることができる。このファイル中の種々のシェーダプログラムまたはその一部は、１つのまたは別の理由のために大衆に分配可能であってもよく、あるいは分配可能であってはならない。このコンピュータ実施取引方法500は、分配可能ではないシェーダプログラムが許可される特定のファイル中に存在しているか否かを考慮したライセンス契約の自動化された発生を可能にする。

最初に動作502において、メモリ中に記憶されたライセンス契約が識別される。さらに、このライセンス契約に関連したファイルが識別される。

その後、動作504に示されているように、ファイルの１以上のものが少なくとも部分的に分配可能でないか否かが決定される。これは、とくに、分配可能ではないコードにタグを付けるか、あるいはファイルの内容を既知の分配可能ではないコードのデータベースと比較することにより行われてもよい。

１以上のファイルが分配可能でないことが決定504において決定された場合、非公開項がそのライセンス契約中に含まれる。この非公開項はボイラープレート特性のものであってもよく、当業者によく知られている任意の別の方法でライセンス契約に自動的に組込まれていてもよい。動作506を参照とされたい。

簡単化された関連したコンピュータ実施方法において、ファイルが分配可能であるか否かを決定するための技術が提供される。このような方法には、メモリ中に記憶されたファイルを識別し、そのファイルが分配可能であるか否かを決定し、ファイルが分配可能であるか否かを単に表示することが含まれてもよい。

以上、種々の実施形態を説明してきたが、それらは単なる例示に過ぎず、何等制限を課すものではないことを認識すべきである。したがって、好ましい実施形態の技術的範囲は上述の例示的な実施形態により制限されるものではなく、添付された請求の範囲およびそれらと等価なものによってのみ制限される。請求の範囲における素子の順序は、ステップまたは動作の特定の順序を示すものではない。

１実施形態によるデジタル処理システムのブロック図。 図１Ａのハードウェアグラフィックスパイプラインの例示的な１実施形態の内部構造を示す詳細図。 １実施形態にしたがってシェーダプログラムを発生するために使用されることのできる例示的なファイルの説明図。 １実施形態によるシェーダプログラムの発生方法を示すフロー図。 １実施形態によるシェーダプログラムの発生方法を示すフロー図。 図１Ｂおよび１Ｃの動作1080にしたがってオブジェクトが設定される“効果バインディング”方法を示す概略図。 図２の動作212にしたがって複数の種々のハードウェアグラフィックスパイプラインプラットホームを表現するインプリメンテーションデータを発生する方法を示すフロー図。 図２の動作218にしたがってどのハードウェアグラフィックスパイプラインプラットホームを使用すべきかが決定されることができる例示的な方法を示すフロー図。 本発明に関連した取引方法を示すフロー図。

Claims (47)

1. グラフィックス効果と関連付けられたファイルを選択し、
   そのファイルを読出し、
   そのファイルを処理し、
   このファイルの処理に基づいてシェーダプログラムを発生してグラフィックス効果をオブジェクトに適用するステップを含んでいるシェーダプログラムを発生する方法。
2. ファイルは、特有のグラフィックス効果にそれぞれ関連付けられたファイルのライブラリから選択される請求項１記載の方法。
3. ファイルは、種々のグラフィックスアプリケーションプログラムインターフェースに対してシェーダプログラムを発生するように処理されることのできる複数のインターフェースデータを含んでいる請求項１記載の方法。
4. ファイルは、種々のハードウェアグラフィックスパイプラインプラットホームに対してシェーダプログラムを発生するように処理されることのできる複数のインプリメンテーションデータを含んでいる請求項１記載の方法。
5. ファイルは、拡張可能なマークアップ言語（ＸＭＬ）で書込まれる請求項１記載の方法。
6. ファイルは、テキストファイルを含んでいる請求項１記載の方法。
7. 選択、読出し、処理および発生は、プラグインを使用して行われる請求項１記載の方法。
8. 選択、読出し、処理および発生は、インターフェースを使用して行われる請求項１記載の方法。
9. インターフェースは、コンポーネントオブジェクトモデル（ＣＯＭ）インターフェースを含んでいる請求項８記載の方法。
10. 処理は、インターフェースの初期化を含んでいる請求項８記載の方法。
11. 処理は注文タイプおよび注文機能の少なくとも１つの登録を含んでおり、その登録された注文タイプおよび注文機能の少なくとも１つに基づいてシェーダプログラムが発生される請求項１記載の方法。
12. 処理は、複数のオブジェクトを設定することを含んでいる請求項１記載の方法。
13. 処理は、オブジェクトの１つを選択することを含んでいる請求項１２記載の方法。
14. 処理は、複数のグラフィックス効果の１つを選択することを含んでいる請求項１３記載の方法。
15. 処理は、描写パスを選択することを含んでいる請求項１４記載の方法。
16. 処理は、描写パスを設定することを含んでいる請求項１５記載の方法。
17. 描写パスはパラメータを指示することにより設定され、シェーダプログラムはそのパラメータに基づいて発生される請求項１６記載の方法。
18. 処理は、選択されたグラフィックス効果によりオブジェクトを描くことを含んでいる請求項１６記載の方法。
19. オブジェクトは、選択されたグラフィックス効果によりあるアプリケーションによって提供される属性を使用して描かれる請求項１８記載の方法。
20. 処理は、描写パスがもっと存在するか否かを決定し、描写パスがもっと存在する場合は別の描写パスを選択することを含んでいる請求項１８記載の方法。
21. 処理は、オブジェクトがもっと存在するか否かを決定し、オブジェクトがもっと存在する場合は別のオブジェクトを選択することを含んでいる請求項１８記載の方法。
22. 処理は、グラフィックス効果がもっと存在するか否かを決定し、グラフィックス効果がもっと存在する場合は別のグラフィックス効果を選択することを含んでいる請求項１８記載の方法。
23. ファイルは要求を含んでおり、その要求に基づいてシェーダプログラムが発生される請求項１記載の方法。
24. 要求は、要求の省略時セットを含んでいる請求項２３記載の方法。
25. グラフィックス効果は、グラフィックユーザインターフェースを使用して表示される請求項１記載の方法。
26. グラフィックス効果は、ユーザによりグラフィックユーザインターフェースを使用して変更されることが可能である請求項２５記載の方法。
27. グラフィックス効果は、パラメータを変更することにより変更されることが可能である請求項２６記載の方法。
28. 変更されたパラメータに基づいてシェーダプログラムが発生される請求項２７記載の方法。
29. シェーダプログラムはファイルをツイーク（ｔｗｅａｋ）することにより変更されることができる請求項１記載の方法。
30. インターフェースはプリミティブを発生することが可能である請求項８記載の方法。
31. ファイルは、名称、タイプおよび内容を含む構文を含んでいる請求項１記載の方法。
32. ファイルは、コンパイルされたコードとコンパイルされていないコードの両者を参照とすることができる請求項１記載の方法。
33. インターフェースと、
    ファイルを処理するようにインターフェースと協力して動作するアプリケーションプログラムとを備えており、
    シェーダプログラムはこのファイルの処理に基づいて発生されてグラフィックス効果をオブジェクトに適用するシェーダプログラムの発生システム。
34. グラフィックス効果と関連付けられたファイルを選択する手段と、
    ファイルを読出す手段と、
    ファイルを処理する手段と、
    ファイルの処理に基づいてシェーダプログラムを発生してグラフィックス効果をオブジェクトに適用する手段とを備えているシェーダプログラムの発生システム。
35. グラフィックス効果と関連付けられたファイルを選択するコンピュータコードと、
    ファイルを読出すコンピュータコードと、
    ファイルを処理するコンピュータコードと、
    ファイルの処理に基づいてシェーダプログラムを発生してグラフィックス効果をオブジェクトに適用するコンピュータコードとを備えているシェーダプログラムを発生するコンピュータプログラム製品。
36. ファイルを備えており、このファイルは、
    そのファイルに関連付けられたグラフィックス効果を識別する本文描写オブジェクトと、
    シェーダプログラムを発生するために必要なシェーダプログラムに対する要求を識別する要求オブジェクトとを含んでおり、
    シェーダプログラムはファイルのオブジェクトに基づいて発生されることが可能である、シェーダプログラムを発生するメモリ中に記憶されたデータ構造。
37. グラフィックス効果と関連付けられたファイルを選択し、
    グラフィックスアプリケーションプログラムインターフェースを選択し、
    この選択に基づいて複数の種々のハードウェアグラフィックスパイプラインプラットホームを表現するインプリメンテーションデータを受取り、
    インプリメンテーションデータに基づいてパラメータを受取り、
    どのハードウェアグラフィックスパイプラインプラットホームを使用すべきかをパラメータに基づいて決定するステップを含んでおり、
    シェーダプログラムは、ハードウェアグラフィックスパイプラインプラットホームにより使用されるために発生される、アプリケーションを使用してシェーダプログラムを発生する方法。
38. どのハードウェアグラフィックスパイプラインプラットホームが使用されるかに関する決定は、パラメータが提供されることができるか否かに基づいている請求項３７記載の方法。
39. どのハードウェアグラフィックスパイプラインプラットホームが使用されるかに関する決定は、パラメータが理解されたか否かに基づいている請求項３７記載の方法。
40. あるオブジェクトの属性をパラメータにマップするステップをさらに含んでいる請求項３７記載の方法。
41. 複数の種々のハードウェアグラフィックスパイプラインプラットホームを表現するインプリメンテーションデータを発生し、
    このインプリメンテーションデータに基づいてパラメータを発生し、
    どのハードウェアグラフィックスパイプラインプラットホームが使用されるかをパラメータに基づいて決定するステップを含んでおり、
    シェーダプログラムは、ハードウェアグラフィックスパイプラインプラットホームにより使用されるために発生される、インターフェースを使用してシェーダプログラムを発生する方法。
42. インプリメンテーションデータは、種々のハードウェアグラフィックスパイプラインプラットホームが複数の要求を満足させるか否かを決定することにより発生される請求項４１記載の方法。
43. インプリメンテーションデータはさらに、要求を満たす種々のハードウェアグラフィックスパイプラインプラットホームを分類することにより発生される請求項４２記載の方法。
44. インターフェースを初期化し、
    注文タイプおよび注文機能の少なくとも１つを登録し、
    複数のオブジェクトを設定し、
    オブジェクトの１つを選択し、
    複数のグラフィックス効果の１つを選択し、
    描写パスを選択し、
    パラメータを指示することにより描写パスを設定し、
    選択されたグラフィックスオブジェクトによりオブジェクトを描き、
    描写パスがもっと存在するか否かを決定し、
    描写パスがもっと存在する場合は別の描写パスを選択し、
    グラフィックス効果がもっと存在するか否かを決定し、
    グラフィックス効果がもっと存在する場合は別のグラフィックス効果を選択し、
    オブジェクトがもっと存在するか否かを決定し、
    オブジェクトがもっと存在する場合は別のオブジェクトを選択するステップを含んでいるシェーダプログラムの発生方法。
45. メモリ中に記憶されたファイルを識別し、
    ファイルが分配可能であるか否を決定し、
    ファイルが分配可能であることを示すステップを含んでいる、ファイルが分配可能であるか否かを決定するコンピュータ実施方法。
46. ファイルを備えており、このファイルは、
    そのファイルに関連付けられたグラフィックス効果を識別する本文描写オブジェクトと、
    複数の動作環境においてグラフィックス効果を実行することができる複数のシェーダコードセグメントとを含んでおり、
    シェーダコードセグメントは種々の動作環境に関して編成される、シェーダプログラムを識別するメモリ中に記憶されたデータ構造。
47. ユーザが１つのグラフィックス効果を選択することを可能にするために複数のグラフィックス効果を表示し、
    その選択されたグラフィックス効果を、オブジェクトに適用されたときにファイルを使用して表示し、
    ユーザ入力に基づいてそのファイルを修正し、
    そのファイルを処理し、
    そのファイルの処理に基づいてシェーダプログラムを発生するステップを含んでいる、グラフィックユーザインターフェースを使用してシェーダプログラムを発生する方法。

Images