(57)【要約】種々のシェイディングアプリケーションを、単一の言語のもとで統合する方法とシステムが記載され、それにより、シェイダーの簡単な再使用および再目的化が可能になり、コンピュータプログラミングの必要なくシェイダーの設計および構築が促進され、シェイダーのグラフィカルなデバッグが可能になる。【選択図】図１６
2009500730.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも１つのインスタンス化されたフェノメノンが付加された表現から、シーンのイメージを生成するコンピュータグラフィックシステムにおいて、前記インスタンス化されたフェノメノンは、少なくとも１つのシェイダーノードを備えるカプセル化されたシェイダーDAGを備え、前記システムの改良は、
メタノードの作成のために作動可能で、メタノードが、ネットワークにおいてより複雑なシェイダーを構築するために組み合わせることができる構成要素シェイダーを備えるメタノード環境と、
前記メタノード環境と連絡状態にあり、ユーザーが前記メタノード環境を使用してシェイダーグラフおよびフェノーミナを構築できるようにするために、前記メタノード環境を管理するグラフィカルユーザーインタフェース（GUI）と、を備える、ことを特徴とする、コンピュータグラフィックシステム。
【請求項２】
前記改良は、
人間のオペレータにより使用可能で、前記メタノード環境を管理し、シェイダーを実装し、分離シェイディングアプリケーションを統合するソフトウェア言語を更に備える、ことを特徴とする、請求項１記載のコンピュータグラフィックシステム。
【請求項３】
前記改良は、
前記メタノード環境と連係して、シェイダーグラフとフェノーミナとを構築するGUIを生成するために使用可能な少なくとも１つのGUIライブラリを更に備える、ことを特徴とする、請求項１記載のコンピュータグラフィックシステム。
【請求項４】
更なる前記改良において、
前記ソフトウェア言語は、選択されたハードウェアプラットフォームに対する複数の選択されたシェイダー言語のスーパーセットとして構成可能であり、かつ、
前記ソフトウェア言語は、コンパイラ機能が、前記ソフトウェア言語において表現されたフェノメノンの再使用可能な単一の記述から、選択されたシェイダー言語において選択されたハードウェアプラットフォームに対して最適化されたソフトウェアコードを生成することを可能にする、ことを特徴とする、請求項２記載のコンピュータグラフィックシステム。
【請求項５】
前記改良は、
前記選択されたシェイダー言語に対する固有のコンパイラ機能を使用して、前記選択されたハードウェアプラットフォーム及び前記選択されたシェイダー言語に対する前記最適化ソフトウェアコードを、前記選択された集積回路インスタンス化に対するマシン語に変換することを更に含む、ことを特徴とする、請求項４記載のコンピュータグラフィックシステム。
【請求項６】
前記改良は、
前記GUIと連絡状態にあり、（１）前記ユーザーが、シェイダーにおける可能性のある欠陥を検出して補正できるようにし、（２）テスト中のシェイダー、メタノード、またはフェノメノンによるテストシーンが常にレンダリングされるビューイングウィンドウを提供する、対話式で、視覚的なリアルタイムデバッグ環境を更に備える、ことを特徴とする、請求項１記載のコンピュータグラフィックシステム。
【請求項７】
前記改良は、
前記GUIと連絡状態にあり、（１）前記ユーザーが、シェイダーにおける可能性のある欠陥を検出して補正できるようにし、（２）テスト中のシェイダー、メタノード、またはフェノメノンによるテストシーンが常にレンダリングされるビューイングウィンドウを提供する、対話式で、視覚的なリアルタイムデバッグ環境を更に備える、ことを特徴とする、請求項２記載のコンピュータグラフィックシステム。
【請求項８】
オペレータが、少なくとも１つのシェイダーノードを備える、カプセル化されたシェイダーDAGを備えるフェノメノンを作成することを可能とするコンピュータグラフィックシステムにおいて、前記コンピュータグラフィックシステムは、（Ａ）シェイダーを含む複数の基本シェイダーノードを格納するように構成された基本シェイダーノードデータベースと、（Ｂ）前記オペレータが、前記基本シェイダーノードデータベースからの前記基本シェイダーノードを、DAGに相互接続できるように構成されたフェノメノンクリエータであって、前記オペレータにより提供された前記基本シェイダーノード間の相互接続がDAGを備えることを検証する前記フェノメノンクリエータと、を備え、前記システムの改良において、
前記フェノメノンクリエータが、
ネットワークにおいてより複雑なシェイダーを構築するために組み合わせることができる要素シェイダーを備えるメタノードの作成を実施可能なメタノード環境と、
前記メタノード環境と連絡状態にあり、ユーザーが、前記メタノード環境を使用して、シェイダーグラフとフェノーミナとを構築できるように、前記メタノード環境を管理するグラフィカルユーザーインタフェース（GUI）と、
前記オペレータにより使用可能で、前記メタノード環境を管理し、シェイダーを実装し、分離シェイディングアプリケーションを統合し得るソフトウェア言語であって、選択されたハードウェアプラットフォームに対する複数の選択されたシェイダー言語のスーパーセットとして構成可能で、コンパイラ機能が、ソフトウェア言語において表現されたフェノメノンの、再使用可能な単一の記述から、選択されたシェイダー言語における選択されたハードウェアプラットフォームに対する最適化されたソフトウェアコードを生成することを可能にするソフトウェア言語と、を備える、ことを特徴とする、コンピュータグラフィックシステム。
【請求項９】
更なる前記改良において、前記フェノメノンクリエータは、フェノメノンデータベースにおいて、前記オペレータにより作成された前記フェノメノンを格納する、ことを特徴とする、請求項８記載のコンピュータグラフィックシステム。
【請求項１０】
更なる前記改良において、前記フェノメノンクリエータは、前記オペレータが、複数の協働するDAGを備えるフェノーミナにおいて、前記基本シェイダーノードを相互接続できるように更に構成され、前記協働するDAGの１つにおけるシェイダーノードは、シーンのイメージのレンダリングの間に使用されると、前記協働するDAGの別の１つと連係して使用される少なくとも１つの値を提供する、ことを特徴とする、請求項８記載のコンピュータグラフィックシステム。
【請求項１１】
オペレータが、少なくとも１つのシェイダーノードを有する少なくとも１つのシェイダーDAGを備える、カプセル化されたシェイダーDAGを備えるフェノメノンから、インスタンス化されたフェノメノンを生成することを可能とするコンピュータグラフィックシステムにおいて、前記コンピュータグラフィックシステムは、（Ａ）前記フェノメノンを格納するように構成されたフェノメノンデータベースと、（Ｂ）前記オペレータが前記フェノメノンを選択し、前記少なくとも１つのシェイダーノードと関連する少なくとも１つのパラメータに対する値を提供することを可能にするように構成されたフェノメノンエディタと、を備え、前記システムの改良において、
前記フェノメノンエディタが、
ネットワークにおいてより複雑なシェイダーを構築するために組み合わせることができる構成要素シェイダーを備えるメタノードの作成を実施可能なメタノード環境と、
前記メタノード環境と連絡状態にあり、ユーザーが、前記メタノード環境を使用して、シェイダーグラフとフェノーミナとを構築できるように、前記メタノード環境を管理するグラフィカルユーザーインタフェース（GUI）と、
前記オペレータにより使用可能で、前記メタノード環境を管理し、シェイダーを実装し、分離シェイディングアプリケーションを統合し得るソフトウェア言語であって、選択されたハードウェアプラットフォームに対する複数の選択されたシェイダー言語のスーパーセットとして構成可能で、コンパイラ機能が、ソフトウェア言語において表現されたフェノメノンの、再使用可能な単一の記述から、選択されたシェイダー言語における選択されたハードウェアプラットフォームに対する最適化されたソフトウェアコードを生成することを可能にするソフトウェア言語と、を備える、ことを特徴とする、コンピュータグラフィックシステム。
【請求項１２】
少なくとも１つのシェイダーノードを備えるカプセル化されたシェイダーDAGを備える少なくとも１つのインスタンス化されたフェノメノンが付加された表現から、シーンのイメージを生成するコンピュータグラフィックシステムにおいて、前記コンピュータグラフィックシステムは、（Ａ）前記少なくとも１つのインスタンス化されたフェノメノンが、前記表現に関連する前処理が必要かどうかを判定し、必要な場合は、前記前処理を実行して、前記シーンの前処理表現を生成するように構成されたプリプロセッサと、（Ｂ）前記シーンの前記前処理された表現からレンダリングされたイメージを生成するように構成されたレンダラーと、を備え、前記システムの改良は、
ネットワークにおいてより複雑なシェイダーを構築するために組み合わせることができる要素シェイダーを備えるメタノードの作成を実施可能なメタノード環境と、
前記メタノード環境と連絡状態にあり、ユーザーが、前記メタノード環境を使用して、シェイダーグラフとフェノーミナとを構築できるように、前記メタノード環境を管理するグラフィカルユーザーインタフェース（GUI）と、
前記オペレータにより使用可能で、前記メタノード環境を管理し、シェイダーを実装し、分離シェイディングアプリケーションを統合し得るソフトウェア言語であって、選択されたハードウェアプラットフォームに対する複数の選択されたシェイダー言語のスーパーセットとして構成可能で、コンパイラ機能が、ソフトウェア言語において表現されたフェノメノンの、再使用可能な単一の記述から、選択されたシェイダー言語における選択されたハードウェアプラットフォームに対する最適化されたソフトウェアコードを生成することを可能にするソフトウェア言語と、を備える、ことを特徴とする、コンピュータグラフィックシステム。
【請求項１３】
更なる前記改良において、シェイダーノードの少なくとも１つのタイプは、幾何学的シェイダーノードタイプであり、前記プリプロセッサは、前記少なくとも１つのシェイダーノードが、前記幾何学的シェイダーノードタイプの場合は、前記シーンに対して幾何学的図形を定義するために前記前処理操作を実行するように構成されている、ことを特徴とする、請求項１２記載のコンピュータグラフィックシステム。
【請求項１４】
更なる前記改良において、シェイダーノードの少なくとも１つのタイプは、フォトンシェイダーノードタイプであり、前記更なる改良において、前記プリプロセッサは、前記少なくとも1つのシェイダーノードが、前記フォトンシェイダーノードタイプの場合は、前記シーンにおけるフォトンの経路と、フォトンの、前記シーンにおけるオブジェクトの表面との相互作用の特徴とを制御するために前記前処理操作を実行するように構成されている、ことを特徴とする、請求項１２記載のコンピュータグラフィックシステム。
【請求項１５】
更なる前記改良において、シェイダーノードの少なくとも１つのタイプは、フォトンエミッタ・シェイダー・ノード・タイプであり、前記プリプロセッサは、前記少なくとも１つのシェイダーノードが、前記フォトンエミッタ・シェイダー・ノード・タイプの場合は、前記前処理操作を実行して、前記シーンを照明する光源によりフォトン生成をシミュレートするように構成されている、ことを特徴とする、請求項１２記載のコンピュータグラフィックシステム。
【請求項１６】
更なる前記改良において、シェイダーノードの少なくとも１つのタイプは、フォトンボリューム・シェイダー・ノード・タイプであり、前記プリプロセッサは、前記少なくとも１つのシェイダーノードが、前記フォトンボリューム・シェイダー・ノード・タイプの場合は、前記前処理操作を実行して、光源からのフォトンと、前記シーンにおける空間の三次元ボリュームとの相互作用をシミュレートするように構成されている、ことを特徴とする、請求項１２記載のコンピュータグラフィックシステム。
【請求項１７】
前記改良は、前記少なくとも１つのインスタンス化されたフェノメノンが、前記表現に関連して後処理操作が必要かを判定し、必要な場合は、前記後処理操作を実行するように構成されているポストプロセッサを更に備える、ことを特徴とする、請求項１２記載のコンピュータグラフィックシステム。
【請求項１８】
更なる前記改良において、前記少なくとも１つのシェイダーノードは出力シェイダーノードタイプであり、前記ポストプロセッサは、前記少なくとも１つのシェイダーノードが前記出力シェイダーノードタイプの場合は、前記後処理操作を実行するように構成されている、ことを特徴とする、請求項１２記載のコンピュータグラフィックシステム。
【請求項１９】
更なる前記改良において、前記レンダリングされたイメージは、それぞれがピクセル値に関連付けられた複数のピクセルを備え、前記ポストプロセッサは、前記ピクセル値との関連で、前記後処理操作を実行するように構成されている、ことを特徴とする、請求項１８記載のコンピュータグラフィックシステム。
【請求項２０】
少なくとも１つのシェイダーノードを備えるカプセル化されたシェイダーDAGを備える少なくとも１つのインスタンス化されたフェノメノンが付加された表現から、シーンのイメージを生成するコンピュータグラフィックシステムにおいて、前記システムの改良が、
ネットワークにおいてより複雑なシェイダーを構築するために組み合わせることができる構成要素シェイダーを備えるメタノードの作成を実施可能なメタノード環境と、
前記メタノード環境と連絡状態にあり、ユーザーが、前記メタノード環境を使用して、シェイダーグラフとフェノーミナとを構築できるように、前記メタノード環境を管理するグラフィカルユーザーインタフェース（GUI）と、
前記オペレータにより使用可能で、前記メタノード環境を管理し、シェイダーを実装し、分離シェイディングアプリケーションを統合し得るソフトウェア言語であって、選択されたハードウェアプラットフォームに対する複数の選択されたシェイダー言語のスーパーセットとして構成可能で、コンパイラ機能が、ソフトウェア言語において表現されたフェノメノンの、再使用可能な単一の記述から、選択されたシェイダー言語における選択されたハードウェアプラットフォームに対する最適化されたソフトウェアコードを生成することを可能にするソフトウェア言語と、
前記メタノード環境と連係して使用可能で、シェイダーグラフおよびフェノーミナを構築するGUIを生成するための少なくとも１つのGUIライブラリと、
前記GUIと連絡状態にあり、対話的で、視覚的で、かつリアルタイムなデバッグ環境であって、（１）前記ユーザーがシェイダーにおける可能性のある欠陥を検出して補正できるようにし、（２）テスト中のシェイダー、メタノード、またはフェノメノンによるテストシーンが常にレンダリングされるビューイングウィンドウを提供するデバッグ環境と、
前記コンパイラ機能と連絡状態にある機器であって、前記選択されたハードウェアプラットフォーム及び選択されたシェイダー言語に対する最適化されたソフトウェアコードを、前記選択されたシェイダー言語に対する固有のコンパイラ機能を使用して、選択された集積回路のインスタンス化に対するマシン語に変換する機器と、を備える、ことを特徴とする、コンピュータグラフィックシステム。
【請求項２１】
少なくとも１つのシェイダーノードを備えるカプセル化されたシェイダーDAGを備える少なくとも１つのインスタンス化されたフェノメノンが付加された表現から、シーンのイメージを生成するコンピュータグラフィックシステムにおいて、シーンのイメージの生成を可能にする方法であって、
より複雑なシェイダーを構築するために、ネットワークにおいて組み合わせることができる構成要素シェイダーを備えるメタノードを作成するために作動可能なメタノード環境を構成することと、
前記メタノード環境と連絡状態にあり、前記メタノード環境を管理して、ユーザーが、前記メタノード環境を使用してシェイダーグラフおよびフェノーミナを構築できるようにするグラフィカルユーザーインタフェース（GUI）を構成することと、
インタフェースとして人間のオペレータにより使用可能で、前記メタノード環境を管理し、シェイダーを実装し、分離シェイディングアプリケーションを統合し得るソフトウェア言語であって、選択されたハードウェアプラットフォームに対する複数の選択されたシェイダー言語のスーパーセットとして構成可能で、コンパイラ機能が、ソフトウェア言語において表現されたフェノメノンの、再使用可能な単一の記述から、選択されたシェイダー言語における選択されたハードウェアプラットフォームに対する最適化されたソフトウェアコードを生成するソフトウェア言語を提供することと、
前記メタノード環境と連係して使用でき、シェイダーグラフおよびフェノーミナを構築するGUIを生成する少なくとも１つのGUIライブラリを提供することと、
前記GUIと連絡状態にあり、対話的で、視覚的で、かつリアルタイムなデバッグ環境であって、（１）前記ユーザーがシェイダーにおける可能性のある欠陥を検出して補正できるようにし、（２）テスト中のシェイダー、メタノード、またはフェノメノンによるテストシーンが常にレンダリングされるビューイングウィンドウを提供するデバッグ環境を構成することと、
前記コンパイラ機能と連絡状態にある機器であって、前記選択されたハードウェアプラットフォーム及び選択されたシェイダー言語に対する最適化されたソフトウェアコードを、前記選択されたシェイダー言語に対する固有のコンパイラ機能を使用して、選択された集積回路のインスタンス化に対するマシン語に変換する機器を構成することと、を含む、ことを特徴とする、方法。
【請求項２２】
前記改良は、
前記GUI上のグラフィカル表現を含むプロファイリングを介しての、シェイダーの性能分析を更に含む、ことを特徴とする、請求項８記載のコンピュータグラフィックシステム。
【請求項２３】
更なる前記改良において、所与のノードに対するシェイダー性能は、前記ノードが常駐するシェイダーグラフに対して、前記性能結果が、前記ノードを駆動する入力値に対して相対的であるように分析できる、ことを特徴とする、請求項２２記載のコンピュータグラフィックシステム。
【請求項２４】
更なる前記改良において、プロファイリング情報が、グラフまたはフェノメノンの一部であるノードに対するノードレベルにおいて、およびメタノードに含まれるコンピュータ言語ソフトウェアコードに対するステートメントレベルにおいて提供される、ことを特徴とする、請求項２２記載のコンピュータグラフィックシステム。
【請求項２５】
更なる前記改良において、所与の詳細レベルでの性能情報は、ノードの全体性能コスト、関連付けられたシェイダー、または複数のシェイダーによりシーン全体のレンダリングを行なうときのコストに対して正規化される、ことを特徴とする、請求項２２記載のコンピュータグラフィックシステム。
【請求項２６】
更なる前記改良において、メタノード内のコンピュータ・ソフトウェア・コード・ステートメントの実行時間は、前記メタノードがグラフのメンバーの場合は、前記メタノードの合計実行時間、または前記シェイダー全体の合計実行時間の百分率として表現できる、ことを特徴とする、請求項２２記載のコンピュータグラフィックシステム。
【請求項２７】
更なる前記改良において、性能のグラフィカル表現は、複数の視覚化方法を使用して提供できる、ことを特徴とする、請求項２２記載のコンピュータグラフィックシステム。
【請求項２８】
更なる前記改良において、１つの方法は、正規化された性能コスト情報に関連付けられた百分率を、カラー勾配にマッピングすることにより、前記正規化された性能コスト情報を提示する、ことを特徴とする、請求項２７記載のコンピュータグラフィックシステム。
【請求項２９】
更なる前記改良において、前記マッピングは、評価されるそれぞれのコンピュータ・ソフトウェア・コード・ステートメントに隣接して、オペレータが識別できるカラーバーを提示することを含む、ことを特徴とする、請求項２８記載のコンピュータグラフィックシステム。
【請求項３０】
更なる前記改良において、前記性能結果の前記グラフィカル表現は、動画シーンの進行に従って、動的に更新される、ことを特徴とする、請求項２７記載のコンピュータグラフィックシステム。
【請求項３１】
更なる前記改良において、前記視覚化方法は、所与の入力パラメータの値の範囲に関する性能結果のグラフを表示することを含む、ことを特徴とする、請求項２７記載のコンピュータグラフィックシステム。
【請求項３２】
更なる前記改良において、前記視覚化方法は、性能結果を表形式で表示することを含む、ことを特徴とする、請求項２７記載のコンピュータグラフィックシステム。
【請求項３３】
更なる前記改良において、前記視覚化方法は、シェイダー全体の前記全体性能コストに関して、フェノメノンの各ノードの性能タイミングを表示することを含む、ことを特徴とする、請求項２７記載のコンピュータグラフィックシステム。
【請求項３４】
更なる前記改良において、前記シェイダーの１つは、表面照明モデルを、抽象化およびレンダリングできるようにする、双方向反射分布機能（BRDF）シェイダータイプである、ことを特徴とする、請求項８記載のコンピュータグラフィックシステム。
【請求項３５】
前記改良は、複数のBRDFノードのそれぞれにより表現された複数の照明モデルを採用することを更に含む、ことを特徴とする、請求項３４記載のコンピュータグラフィックシステム。
【請求項３６】
前記改良は、スカラーまたはカラーによりBRDF値のスケーリングを可能にすることを更に含む、ことを特徴とする、請求項３５記載のコンピュータグラフィックシステム。
【請求項３７】
前記改良は、複数のBRDFノードのそれぞれにより表現された複数の照明モデルの前記混合を可能にすることを更に含む、ことを特徴とする、請求項３６記載のコンピュータグラフィックシステム。
【請求項３８】
前記改良は、感知装置により生成されたデータにより表現される取得されたBRDFの前記利用を更に含む、ことを特徴とする、請求項３４記載のコンピュータグラフィックシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的には、コンピュータグラフィック、コンピュータ支援デザインなどの分野に関し、特に、シェイダー（shader）システムを生成し、そのようにして生成されたシェイダーシステムを、シーンのイメージのレンダリングに使用するシステムと方法に関する。本発明は、特に、コンピュータグラフィックシステムにおいて有用な新しいタイプの構成要素を提供し（それはここでは「フェノメノン（phenomenon）」として識別され）、パッケージ化およびカプセル化されたシェイダーDAG（「有向非循環グラフ（directed acyclic graph）」）または協働（cooperating）シェイダーDAGのセットを含むシステムを備え、そのそれぞれは１つまたは２つ以上のシェイダーを含むことができ、シェイダーが正確にレンダリング中に協働できることを保証するような方法で、シーンの少なくとも一部を規定することを支援するために生成されカプセル化される。
【背景技術】
【０００２】
コンピュータグラフィック、コンピュータ支援幾何学デザインなどにおいては、アーティスト、製図家、または他のユーザー（一般的にはここでは「オペレータ」と称される）は、コンピュータにより維持されるように、あるシーンにおけるオブジェクトの三次元表現を生成し、その後、当該シーンにおける前記オブジェクトの各二次元イメージを、１つまたは２つ以上の方向からレンダリングしようとする。第１の表現生成フェーズにおいては、従来は、コンピュータグラフィックシステムが、例えば、シーンにおけるオブジェクトの輪郭および／また断面を含む種々の二次元線画から三次元表現を生成し、そのような線画に対して数多くの操作を施して、三次元空間における二次元表面を生成し、それに続くパラメータおよびそのような表面のコントロール点の修正により、オブジェクトの表現結果の形状を補正または修正する。
【０００３】
この工程の間、オペレータは、オブジェクト表面の種々の特質、シーンを照明する光源の構造および特性、およびイメージを生成する１台または２台以上のシミュレートされたカメラの構造および特性も定義する。シーン、光源、およびカメラの構造および特性が定義された後、第２フェーズにおいて、オペレータは、特別な視点方向からのシーンのイメージをコンピュータがレンダリングできるようにする。
【０００４】
シーンにおけるオブジェクト、光源、およびカメラは、第１シーン定義フェーズにおいて、少なくとも３つの空間次元を、そしておそらく１つの時間次元を含む、個々の複次元数学的表現により定義される。数学的表現は、典型的には、ツリー構造化されたデータ構造に格納される。オブジェクトの表面の特質は、その結果、「シェードツリー（shade trees）」により定義され、そのそれぞれは、１つまたは２つ以上のシェイダーを含み、そのシェイダーは、第２シーンレンダリングフェーズの間に、コンピュータが個々の表面のレンダリングできるようにし、実際には、個々の表面のカラーを表現するカラー値を提供する。シェードツリーのシェイダーは、オペレータにより生成されるか、コンピュータグラフィックシステムにより、共に第２シーンレンダリングフェーズにおいて個々の表面のイメージをコンピュータにレンダリングさせることができるCまたはC++のような高レベル言語により演繹的に提供される。
【０００５】
コンピュータグラフィック機構において典型的にもたらされるように、シェイダーおよびシェードツリーの生成および使用からは数多くの問題が発生する。第１に、シェイダーは、一般的に、そうするようにプログラムされない限り、お互いに協働することはできない。典型的には、シェイダーに提供される入力値は定数値であり、それにより、シェイダーの柔軟性、および、興味ある実写のような方法での特徴のレンダリング機能に制限を与えてしまう。更に、その入力値を共通のソースから得ることができる協働シェイダーのシステムを設定することは一般的に難しい。
【０００６】
そのような問題に解決法を提供するために、上記に引用した米国特許第６，４９６，１９０号明細書は、「フェノメノン」と称される新しいタイプのエンティティを作成でき、インスタンス化でき、シーンのイメージのレンダリングにおいて使用できるコンピュータグラフィックシステムを記載している。フェノメノンは、１つまたは２つ以上のノードを備えるカプセル化シェイダーDAG（「有向非循環グラフ」）であり、それぞれのノードはシェイダーまたは、協働するように相互接続され、インスタンス化されて、シーンにおけるエンティティに付加されるそのようなDAGのカプセル化されたセットを備える。ここにおいて、エンティティは、シーンにおけるオブジェクトの表面のカラーおよびテクスチャ特性を含む、シーンの多様なタイプの特性、シーンにおけるボリュームおよび幾何学的図形の特性、シーンを照明する光源の特徴、レンダリング中にシミュレートされるシミュレートされたカメラの特性、およびレンダリングにおいて有効な他の多くの特徴を定義するための、シーン定義処理の間に作成される。
【０００７】
オペレータにより、シーンとの関連において使用するために選択されたフェノーミナは、予め定義することができ、または、オペレータがフェノメノンクリエータを使用して、基本シェイダーノードから構築することもできる。フェノメノンクリエータは、DAGまたは協働DAGにおけるシェイダーが、シーンのイメージのレンダリング中に正しく協働できるように、フェノーミナが構築されることを保証する。
【０００８】
シーンに付加される前に、フェノメノンエディタを使用して、フェノメノンのパラメータのそれぞれに対して値を定義するために使用される値、または関数を提供することによりフェノメノンはインスタンス化される。
シーンの表現が定義され、フェノーミナが付加された後、シーンイメージジェネレータは、シーンのイメージを生成できる。その操作において、シーンイメージジェネレータは、前処理フェーズ，レンダリングフェーズ，及び後処理フェーズを含む、一連のフェーズにおいて作動する。前処理フェーズの間に、シーンイメージジェネレータは、シャドウ（shadow）およびフォトンマッピング（photon mapping）、多重継承分析（multiple inheritance resolution）のような前処理を実行できる。シーンイメージジェネレータは、例えば、シーンに付加されたフェノメノンが、それによりシーンに対して定義された幾何学的図形を生成する幾何学的シェイダーを含む場合は、前処理操作を実行できる。レンダリングフェーズの間、シーンイメージジェネレータはイメージのレンダリングを行なう。後処理フェーズの間、シーンイメージジェネレータは、シーンに付加されたフェノメノンが、例えば、被写界深度または、レンダリングされたイメージの各ピクセル値に関連して格納されている速度および深度情報に依存する動きによるブレ計算のような後処理操作を定義するシェイダーを含む場合は、後処理操作を実行できる。
【０００９】
米国特許第６，４９６，１９０号明細書に記載されたフェノーミナシステムは、非常に有効である。しかし、近年、多くのシェイディングプラットフォームおよび言語が開発され、そのため、ビデオゲームのシェイディングを行なうハードウェアであれ、動画の視覚的効果のためのシェイディングを行なうソフトウェアであれ、現存のシェイダー言語は、特別なプラットフォームおよびアプリケーションに、より狭い範囲で焦点をおいたものとなっている。この、従来のシェイダーシステムおよび言語に典型的なプラットフォームへの依存性は、大きな制限となり得る。
【００１０】
プラットフォームに依存せず、種々のシェイディングツールおよびアプリケーションを、単一の言語またはシステム構成概念のもとで統合できるシェイダーの方法およびシステムを提供することが望ましい。
また、効率的で簡単な、シェイダーの再使用と再目的化を可能にし、頻繁に普通に発生する（例えば、Lara Croft-Tomb Raider）、ビデオゲームおよび特作映画の統合に有効である方法とシステムを提供することも望ましい。
【００１１】
また、アーティストにとっては有効な、コンピュータプログラミングの必要がなく、シェイダーの設計および構築を容易にする方法およびシステムを提供することも望ましい。
更に、シェイダーのグラフィカルデバッグを可能にし、シェイダークリエータが、シェイダーにおける欠陥を見つけて解決できるようにする方法とシステムを提供することが望ましい。
【発明の開示】
【００１２】
本発明は、その種々の形態は、ここでは集合的に「メンタルミル（Mental Mill）」と称されるが、従来技術の上記の制限に取り組み、種々のシェイディングアプリケーションを単一の言語（ここでは「MetaSLシェイディング言語（MetalSL shading language）」と称される）のもとで統合でき、シェイディングの簡単な再使用および目的変更を可能にし、コンピュータプログラミングの必要なく、シェイダーの設計および構築を容易にし、シェイダーのグラフィカルデバッグを可能にし、多くの他の機能を達成する、プラットフォームに依存しない方法およびシステムを提供する。
【００１３】
本発明の１つの形態は、シェイダーネットワークにおいて、組み合わせて、より複雑かつ視覚的に興味あるシェイダーを構築できる、簡単かつコンパクトな構成要素化シェイダー（ここではメタノード（Metanode）と称される）の作成を容易にする方法とシステムに関連する。
本発明の更なる形態は、ここではMetaSL（Meta Shading Language）と称される、メンタルミルシェイディング言語である。MetaSLは、簡単ではあるが、特にシェイダーを実装するための表現豊かな言語として設計されている。MetaSLは、また、以前は特別なプラットフォームおよび状況（例えば、ゲームためのハードウェアによるシェイディング、特作映画の視覚効果のためのソフトウェアによるもの）に焦点が置かれていた既存のシェイディングアプリケーションを、単一の言語および管理構造の下で統合するようにも設計されている。
【００１４】
メンタルミルは、このようにMetaSLで書かれたメタノード（つまり、シェイダーブロック（shader block））の作成を可能にし、それを洗練されたシェイダーグラフおよびフェノーミナを形成するために付加し組み合わせることができる。
シェイダーグラフは、シェイダーを作成するための、直感的なグラフィカルユーザーインタフェースを提供し、それは、シェイダーソフトウェアコードを書くための技術的専門知識がないユーザーにとってもアクセス可能である。
【００１５】
本発明の別の形態は、シェイダー作成を管理するAPIのライブラリに関する。
本発明の更なる形態においては、メンタルミルGUIライブラリは、シェイダーグラフパラダイムを利用して、シェイダーグラフおよびフェノーミナを構築するための完全なGUIを提供する。
本発明の別の形態においては、MetaSLシェイディング言語は、特別なハードウェアプラットフォームに対する、現存および将来のシェイディング言語すべてのスーパーセットとして効果的に構築でき、そのため、特別な目的のグラフィックハードウェアのそのようなインスタンス化には依存しないので、単一の、再使用可能なフェノメノンのMetaSL記述（結果としてMetaSLにおけるメタノードから構成される）から、特別な目的のシェイダー言語（Cg、HLSLなど）における特別な目的のプラットフォームに対する、最適化されたソフトウェアコードを生成するメンタルミルシステムにおける専用コンパイラの使用が可能になる。
【００１６】
特別な目的のプラットフォーム／言語に対し、プラットフォーム／言語に関して最適化されたコードは、問題のシェイディング言語に対する固有のコンパイラにより、特別なハードウェア（集積回路チップ）のインスタンス化に対するマシン語に変換できる。（固有コンパイラは、メンタルミルの一部である必要はなく、一般的な場合もそうでない）。これは、例えば、ある所与の時期において特別なチップが利用できるが、すぐにそのチップの次世代版により置き換えられてしまう場合に特に有効である。
【００１７】
この点に関して、複雑な視覚効果、つまりフェノーミナを、Cgのようなシェイディング言語で表現する従来の試みは、マシン語へのコンパイル処理に対して最適でないコードという結果になったことに注意されたい。そしてそのような場合、コンパイル処理は極端に遅く、それにより、所望のリアルタイム性能を頓挫させ、またはハードウェアレベルのシェイダーコードはそれが可能なほどには効率的でなく、従ってコードは非常に緩慢に実行された。本発明の前記の形態は、そのような従来の試みに関するこの問題に対処し解決する。
【００１８】
本発明の更なる形態は、フェノメノン作成環境における、シェイダープログラマ／ライター（つまり、MetaSLシェイディング言語におけるプログラマ）に対しての、新しく、相互作用的、視覚的、そしてリアルタイムなデバッガに関する。このデバッガは、下記に詳細に記述されるが、コードのわずか１行における変更の効果さえも、開発中のシェイダー、メタノード、すなわちフェノメノンによるテストシーンが常にレンダリングされる、「ビューポート（viewport）」において、視覚的フィードバックにより即座に明白にする。
【００１９】
本発明の更なる形態、例、詳細、実施形態、および実践は、下記の「発明の詳細な説明」で記載される。
本発明は、付随する請求項における特殊性により指定される。本発明の上記の更なる利点は、添付された図面との連係における下記の記述を参照することにより、更に理解される。
【発明を実施するための最良の形態】
【００２０】
・関連出願への相互参照
本特許出願は、同一所有されている、２００２年１２月１７日付けで特許公開された、米国特許第６，４９６，１９０号明細書（「コンピュータグラフィックシステムにおいて使用される、協働およびカプセル化シェイダーとシェイダーDAGのシステムの生成および使用のためのシステムと方法」）を、参考文献として参照により本願明細書に引用したものとする。また、共有されている、２００５年７月１日付けで出願した、米国仮出願第６０／６９６，１２０号明細書（「コンピュータグラフィックシェイダーシステムおよび方法」（弁理士審理予定表番号MNTL-103-PR））、及び、２００５年８月１１日付けで出願した、米国仮出願第６０／７０７，４２４号明細書（「改善されたコンピュータグラフィックシェイダーシステムおよび方法」（弁理士審理予定表番号MNTL-105-PR））の利益を主張するものであって、参照により本願明細書に引用したものとする。
【００２１】
本発明は、参考文献として本明細書に取り込まれた、共有の米国特許第６，４９６，１９０号明細書に記載された、「フェノメノン」と称されるコンピュータグラフィックエンティティに対する改良を提供する。従って、下記の第Ｉ節においては、米国特許第６，４９６，１９０号明細書に記載されたコンピュータグラフィック「フェノメノン」の種々の形態を検討し、次に、４つの項に分割された第ＩＩ節において、フェノメノンエンティティに対する本改良を検討する。
【００２２】
第Ｉ節  コンピュータグラフィック「フェノーミナ」
米国特許第６，４９６，１９０号明細書は、シェイダーDAGにおけるシェイダーが、レンダリングの間に正しく協働できることを保証するような方法で生成された、１つまたは２つ以上のシェイダーをそれぞれ含むことができる、パッケージ化およびカプセル化されたシェイダーDAGの生成を容易にすることで、シェイダー間の強化された協働を提供する、新しいコンピュータグラフィックシステムおよび方法を記載している。
【００２３】
要約すると、「フェノメノン」と称されるエンティティの新しいタイプが作成でき、インスタンス化でき、シーンのイメージのレンダリングに使用できる、コンピュータグラフィックシステムが提供される。フェノメノンは、それぞれがシェイダーを備える1つまたは2つ以上のノードを備えるカプセル化されたシェイダーDAG、または、協働するように相互接続され、インスタンス化されて、シーンにおける、シーン定義処理の間に作成されて、シーンにおけるオブジェクトの表面のカラーおよびテクスチャの特徴、シーンにおけるボリュームおよび幾何学的図形の特性、シーンを照明する光源の特徴、レンダリング中にシミュレートされるシミュレートされたカメラの特徴、およびレンダリングに有効な他の多数の特徴を含む、シーンの多様なタイプの特徴を定義するエンティティに付加されるそのようなDAGのカプセル化されたセットである。
【００２４】
オペレータにより使用のために選択された、シーンと関連するフェノーミナは、前もって定義してもよく、または、オペレータがフェノメノンクリエータを使用して、基本シェイダーノードから構築してもよい。フェノメノンクリエータは、DAGまたは協働するDAGにおけるシェイダーが、シーンのイメージのレンダリング中に正確に協働できるようにフェノーミナが構築されることを保証する。
【００２５】
シーンに付加される前に、フェノメノンは、フェノメノンエディタを使用して、フェノメノンのパラメータのそれぞれに対して、値を定義するために使用される値、または関数を提供することによりインスタンス化される。
シーンの表現が定義され、フェノーミナが付加された後、シーンイメージジェネレータは、シーンのイメージを生成できる。その操作において、シーンイメージジェネレータは、前処理フェーズ、レンダリングフェーズ、および後処理フェーズを含む、一連のフェーズにおいて作動する。前処理フェーズにおいては、シーンイメージジェネレータは、シャドウ（shadow）およびフォトンマッピング（photon mapping）、多重継承分析（multiple inheritance resolution）などの前処理操作を実行できる。シーンイメージジェネレータは、例えば、シーンに付加されたフェノメノンが、シーンに対して、それにより定義される幾何学的図形を生成する幾何学シェイダーを含む場合は、前処理操作を実行できる。レンダリングフェーズの間、シーンイメージジェネレータはイメージのレンダリングを行なう。後処理フェーズの間、シーンイメージジェネレータは、例えば、シーンに付加されたフェノメノンが、レンダリングされるイメージにおける各ピクセル値と関連して格納されている速度および深度情報に依存する被写界深度または動きによるブレの計算のような、後処理操作を定義するシェイダーを含むならば、後処理操作を実行できる。
【００２６】
図１は、本発明に従って構築されるコンピュータグラフィックシステム１０を備える構成要素を示している。コンピュータグラフィックシステム１０は、レンダリングで使用されるシーンの特徴を定義するために使用される、ここでは「フェノメノン（単数）」または「フェノーミナ（複数）」と称される、新しいコンピュータグラフィック構成要素の生成を容易にすることにより、シェイダー間の強化された協働を提供する。フェノメノンは、1つまたは2つ以上のシェイダーを備えるパッケージ化およびカプセル化されたシステムであり、シェイダーは、1つまたは2つ以上のシェイダーを含む各DAGと、1つまたは2つ以上の有向非循環グラフ（「DAG」）の形式で組織化および相互接続される。コンピュータグラフィックシステム１０により生成されたフェノーミナは、各シェイダーDAGにおけるシェイダー（または複数のシェイダー）が、現実的なまたは複雑な視覚効果のレンダリングを容易にするために、レンダリング中に正しく協働できることを保証するような方法で生成されている。更に、複数の協働するシェイダーDAGを備えるフェノーミナに対して、コンピュータグラフィックシステム１０は、シェイダーDAGすべてにおけるシェイダーが、進行する現実的なまたは複雑な視覚効果のレンダリングを容易にするために、レンダリング中に正しく協働できるようにフェノーミナを生成する。
【００２７】
図１を参照すると、１つの実施形態におけるコンピュータグラフィックシステム１０は、プロセッサモジュール１１と、キーボード１２Ａおよび／またはマウス１２Ｂ（一般的には、オペレータ入力要素１２と特定される）のようなオペレータ入力構成要素を備えるオペレータインタフェース要素と、ビデオディスプレイ装置１３のようなオペレータ出力要素を含むコンピュータを含む。例示されているコンピュータシステム１０は、従来のプログラム格納コンピュータアーキテクチャのタイプである。プロセッサモジュール１１は、例えば、プロセッサ、メモリ、および、そこに提供されるデジタルデータと連係しての処理および格納操作を行なうディスクおよび／またはテープ格納要素（分離しては示していない）のような大容量格納装置を含む。オペレータ入力要素１２は、オペレータが処理のための情報を入力するために設けられる。ビデオディスプレイ装置１３は、プロセッサモジュール１１により生成された出力情報を、オペレータのためにスクリーン１４上に表示するために設けられ、オペレータが処理のために入力するデータ、処理を制御するためにオペレータが入力する情報が、処理中に生成された情報と共に含まれる。プロセッサモジュール１１は、いわゆる「グラフィカルユーザーインタフェース（「GUI」）」を使用して、ビデオディスプレイ装置１３による表示のための情報を生成し、種々のアプリケーションプログラムに対する情報が、種々の「ウィンドウ」を使用して表示される。コンピュータシステム１０は、オペレータから入力情報を受け取るためのキーボード１２Ａおよびマウス１２Ｂと、オペレータへの出力情報を表示するためのビデオディスプレイ装置１３のような特別な構成要素を備えるように示されているが、コンピュータシステム１０は、図１に示された構成要素に加えて、あるいはその代わりに種々の構成要素を含んでもよい。
【００２８】
更に、プロセッサモジュール１１は、一般的に参照番号１４で特定され、コンピュータシステム１０をコンピュータネットワーク内で接続する通信リンクに接続された１つまたは２つ以上のネットワークポートを含んでもよい。ネットワークポートにより、コンピュータシステム１０は、ネットワーク内の他のコンピュータシステムおよび他の装置へ情報を送信、およびそれらから情報を受信できるようになる。例えば、クライアント−サーバーパラダイムにより構成された典型的ネットワークにおいては、ネットワークにおけるあるコンピュータシステムは、サーバーとして指定され、他のクライアントコンピュータシステムによる処理のためにデータおよびプログラム（一般的には「情報」）を格納し、それにより、クライアントコンピュータシステムは便利に情報を共有できる。特別なサーバーにより維持された情報へアクセスする必要のあるクライアントコンピュータシステムは、サーバーがネットワークを介してそこに情報をダウンロードできるようにする。データの処理後は、クライアントコンピュータシステムは、また、処理されたデータを格納のためにサーバーに戻す。コンピュータシステム（上記のサーバーおよびクライアントを含む）に加えて、ネットワークはまた、例えば、プリンタ、ファクシミリ装置、デジタルオーディオまたはビデオ格納装置および配布装置など、ネットワーク内で接続された種々のコンピュータシステム間で共有できる装置を含んでもよい。ネットワーク内でコンピュータシステムを相互接続する通信リンクは、従来のように、コンピュータシステム間で信号を搬送するためのワイヤ、光ファイバー、または他の媒体を含む、任意の便利な情報搬送媒体を備えてもよい。コンピュータシステムは、通信リンクを介して転送されるメッセージにより、ネットワーク上で情報を転送し、各メッセージは、情報と、そのメッセージを受信する装置を特定する識別子を含む。
【００２９】
上述したように、コンピュータグラフィックシステム１０は、パッケージ化およびカプセル化されたシェイダーDAGまたは協働シェイダーDAGを備えるフェノーミナの生成を容易にすることによりシェイダー間の強化された協働を提供し、各シェイダーDAGは、少なくとも１つのシェイダーを備え、それは三次元シーンの特徴を規定する。フェノーミナはシーンの種々の特徴を規定するために使用でき、それには、シーンにおけるオブジェクトの表面のカラー、テクスチャの特徴、シーンにおけるボリュームおよび幾何学的図形の特性、シーンを照明する光源の特徴、レンダリング中にシミュレートされるシミュレートされたカメラまたは他のイメージ記録装置の特徴、および下記の記述から明白になる、レンダリングにおいて有効な数多くの他の特徴が含まれる。フェノーミナは、シーンのイメージのレンダリング中に、DAGまたは協働DAG内のシェイダーが正確に協働できることを保証するように構築される。
【００３０】
図２は、本発明の１つの実施形態において使用されるコンピュータグラフィックシステム１０の機能ブロック図を示している。図２に示されるように、コンピュータグラフィックシステム１０は、２つの一般的な部分、つまり、シーン構造生成部２０と、シーンイメージ生成部２１を含む。シーン構造生成部２０は、アーティスト、製図者など（一般的に、「オペレータ」）により、種々の要素の表現を生成するシーンエンティティ生成フェーズ中に使用され、この表現はシーンのレンダリングにおいてシーンイメージ生成部２１により使用され、例えば、シーンにおけるオブジェクトおよびその表面の特性、シーンを照明する光源またはソースの構造と特性、および、イメージのレンダリング中に、イメージを生成する際にシミュレートされるカメラのような特別な装置の構造と特性を含む。シーン構造生成部２０により生成された表現は数学的表現であり、シーンオブジェクトデータベース２２に格納される。数学的表現は、オペレータへの表示のためにイメージレンダリング部２１により評価される。シーン構造生成部２０とシーンイメージ生成部２１は、同一のコンピュータ上に常駐でき、その一部を形成してもよく、その場合、シーンオブジェクトデータベース２２もまた、同じコンピュータ上に常駐してもよく、またはコンピュータ２０がクライアントであるサーバー上に常駐してもよい。または、シーン構造生成部２０とシーンイメージ生成部２１は、異なるコンピュータ上に常駐し、その一部を形成してもよく、その場合は、シーンオブジェクトデータベース２２は、コンピュータか両者のコンピュータのサーバーのいずれかに常駐してよい。
【００３１】
より特別には、シーン構造生成部２０は、オペレータにより使用されて、シーンにおけるオブジェクトの幾何学的構造、シーンを照明する光源の幾何学的特性、およびレンダリングされるイメージの生成の際にシミュレートされるカメラの位置、幾何学的および光学的特性を定義する数学的表現を生成する。数学的表現は、好ましくは３つの空間的寸法を定義し、それによりシーンにおけるオブジェクトの位置、およびオブジェクトの特徴を特定する。オブジェクトは、三次元空間に埋め込まれた直線または曲線、三次元空間に埋め込まれた二次元表面、１つまたは２つ以上の区切られたおよび／または閉じた三次元表面、またはそれらの任意の組み合わせを含む、一次、二次、または三次元の特徴で定義されてもよい。更に、数学的表現はまた、オブジェクトおよびそれらの個々の特徴が、時間の関数として動くと考えられるコンピュータアニメーションに関連して特に有効である時間的な寸法を定義する。
【００３２】
レンダリングされる、シーンにおけるオブジェクトの幾何学的構造の数学的表現に加えて、数学的表現は、更に、シーンとカメラを照明する１つまたは２つ以上の光源を定義する。光源の数学的表現は、特に、シーンに関しての光源の位置および／または方向、光源が点光か、直線または曲線か、平坦か曲面かなどを含む、光源の構造的特徴を定義する。カメラの数学的表現は、特に、レンズが１つか複数か、焦点距離、撮像面の向きなどを含む、従来のカメラパラメータを定義する。
【００３３】
シーン構造生成部２０はまた、下記に詳細を記載するフェノーミナの生成、およびシーンの個々の要素に関してのフェノーミナの関連付けを容易にする。フェノーミナは、概ね、レンダリングに使用されるシーンの定義の完成に必要な他の情報を定義する。この情報には、それに制限されることはないが、カラー、テクスチャなどの特性、シーン構造生成部２０により定義された幾何学的エンティティの表面の特性が含まれる。フェノメノンは、数学的表現または他のオブジェクトを含んでもよく、それらは、レンダリング操作の間に評価される時、レンダリングされたイメージを生成するコンピュータが、所望の方法で個々の表面を表示することを可能にする。オペレータの制御のもとで、シーン構造生成部２０は、フェノーミナを、それと共に使用される個々の要素（つまり、オブジェクト、表面、ボリュームなど）に対する数学的表現と関連付け、フェノーミナを個々の要素に効率よく「付加する」。
【００３４】
数学的表現がシーン構造生成部２０により生成され、シーン表現データベース２２に格納された後、シーンイメージ生成部２１が、オペレータによりレンダリングフェーズの間に使用されて、例えば、ビデオディスプレイ装置１３（図１）上のシーンのイメージを生成する。
シーン構造生成部２０は、いくつかの要素を含み、エンティティ幾何学的表現ジェネレータ２３、フェノメノンクリエータ２４、フェノメノンデータベース２５、フェノメノンエディタ２６、基本シェイダーノードデータベース３２、フェノメノンインスタンスデータベース３３、およびシーンアセンブラ３４を含み、これらはすべてオペレータインタフェース２７を介して入力されたオペレータ入力情報の制御のもとで作動する。オペレータインタフェース２７は、一般的に、図１と関連して上記したように、コンピュータグラフィックシステム１０のオペレータ入力装置１２及びビデオディスプレイ装置１３を含んでもよい。エンティティ幾何学的表現ジェネレータ２３は、オペレータインタフェース２７からのオペレータ入力の制御のもとで、上記のように、シーンにおけるオブジェクト，光源及びカメラの数学的表現の生成を容易にする。フェノメノンクリエータ２４は、それによりオペレータがオペレータインタフェース２７と基本シェイダーノードデータベース３２からの基本シェイダーノードを使用して、シーンと関連して、あるいは他の方法で（下記に記載するように）使用できるフェノーミナを生成できる機構を提供する。フェノメノンが、フェノメノンクリエータ２４により生成された後、それは（つまり、フェノメノンは）フェノメノンデータベース２５に格納される。フェノメノンがフェノメノンデータベース２５に格納された後は、フェノメノンのインスタンスをフェノメノンエディタ２６により作成できる。その操作において、オペレータはフェノメノンエディタ２６を使用して、フェノメノンの種々のパラメータ（もしあれば）に対して値を提供する。例えば、オペレータからの入力に基づいて、付加するとき、またはそれ以降に、確立、調整、または修正されるフェノメノンがカラーバランス、テクスチャの粗さ、光沢のような特徴を提供するように作成されると、フェノメノンエディタ２６により、オペレータはオペレータインタフェース２７を介して、特別な特徴の確立、調整、または修正が可能となる。パラメータに対する値は、固定または、変数（例として、時間）の関数に従って変化してもよい。オペレータは、シーンアセンブラ３４を使用して、フェノメノンエディタ２６を使用して生成されたフェノメノンインスタンスを、エンティティ幾何学的表現ジェネレータ２３により生成されたように、シーンの要素に付加できる。
【００３５】
フェノメノンエディタ２６が、フェノメノンデータベース２５から、コンピュータグラフィックシステム１０のシーン構造生成部２０のフェノメノンクリエータ２４により生成されたフェノメノンを検索するように記載したが、コンピュータグラフィックシステム１０において提供されたフェノーミナの１つまたは２つ以上、そしておそらくそのすべてを、他の装置（図示せず）により予め定義して作成し、フェノメノンエディタ２６による使用のために、フェノメノンデータベース２５に格納してもよい。そのような場合は、オペレータは、オペレータインタフェース２７を介してフェノメノンエディタを制御して、シーンへの付加のために適切な、予め規定されたフェノーミナを選択できる。
【００３６】
シーンイメージ生成部２１は、イメージジェネレータ３０とオペレータインタフェース３１とを含むいくつかの構成要素を含む。シーンイメージ生成部２１が、シーン構造生成部２０と同じコンピュータの一部を形成する場合、オペレータインタフェース３１は、その必要はないが、オペレータインタフェース２７と同じ構成要素を含んでもよい。他方、シーンイメージ生成部２１が、異なるコンピュータの一部を形成する場合は、その２つのオペレータインタフェース３１と２７の構成要素は類似しているが、オペレータインタフェース３１は、オペレータインタフェース２７として異なる構成要素を一般的に備える。イメージジェネレータ３０は、オペレータインタフェース３１の制御のもとで、レンダリングされるシーンの表現をシーン表現データベース２２から検索して、オペレータインタフェース３１のビデオディスプレイ装置上の表示のためのレンダリングされたイメージを生成する。
【００３７】
先に進む前に、本発明において使用される「フェノメノン」を更に説明することは有益であろう。フェノメノンは、エンティティ幾何学的表現ジェネレータ２３により生成された数学的表現に加えて、それに制限されることはないが、シーン構造生成部２０により定義された幾何学的エンティティの表面のカラー、テクスチャ、閉じたボリュームなどの特徴を含むレンダリングに使用されるシーンの定義を完全なものにするために使用される情報を提供する。フェノメノンは、有向非循環グラフ（DAG）または複数の協働DAGの形式で相互接続された１つまたは２つ以上のノードを備える。ノードの１つは主要ルートノードであり、シーンにおけるエンティティへ、より具体的には、エンティティの数学的表現にフェノメノンを付加するために使用される。フェノメノンにおいて使用できる他のタイプのノードは、オプションのルートノードおよびシェイダーノードからなる。シェイダーノードは、従来の単純なシェイダーを含めて、従来の複数のシェイダーの任意のものを備えることができ、同時に、テクスチャシェイダー、マテリアルシェイダー、ボリュームシェイダー、環境シェイダー、シャドウシェイダー、変位シェイダー、およびレンダリングされる表現の生成と関連して使用されるマテリアルシェイダーを備えることができる。更に、フェノメノンには、多数の他のタイプのシェイダーノードを使用することが可能で、それらには次のものが含まれる。（i）シーンに幾何学的オブジェクトを追加するのに使用可能な幾何学的シェイダー。幾何学的シェイダーは、本質的に、三次元空間における、前もって定義された静的な、または手順化可能なエンティティの数学的表現を備え、それは、シーンにおいてエンティティと関連してエンティティ幾何学的表現ジェネレータ２３により生成される表現と類似しているが、それらが前処理時に、例えば、個々のフェノメノンにおいて使用された他のシェイダーの限界が定められる個々の領域を定義するために提供できることが異なる。幾何学的シェイダーは、本質的に、エンティティ幾何学的表現ジェネレータ２３のエンティティのシーン構築要素へのアクセスを有しており、それにより、それは、例えば、静的または手順化可能な方法で、シーンの新しい幾何学的要素を修正または作成するために、シーンオブジェクトデータベースに格納されるときに、シーン表現を変更できる。その全体が幾何学的シェイダーDAGまたは協働幾何学的シェイダーDAGのセットから構成されているフェノメノンは、手順化可能な方法でシーンにおけるオブジェクトを表現するために使用できるとういうことに留意されたい。これは、人間のオペレータにより、コンピュータにおけるオブジェクトの所望する表現を得るために、一連のモデル化操作を行なうことによるモデル化において達成される、典型的モデル化とは対照的である。そのため、本質的には、幾何学的フェノメノンは、カプセル化され、自動化され、パラメータ化された抽象的モデル化操作を表現する。幾何学的フェノメノンのインスタンス（つまり、固定の、または、時間などと共に所定の方法で変化するパラメータ値のセットに関連する幾何学的フェノメノン）は、それが、前処理フェーズの間の起動時にシーンイメージジェネレ��タ３０により評価されるときに、特別な幾何学的シーンの拡張という結果になる。（ii）シーンにおけるフォトンの経路と、吸収、反射などの、シーンにおけるオブジェクトの表面とのフォトンの相互作用の特徴を制御するために使用できるフォトンシェイダー。フォトンシェイダーにより、レンダリングに関連する全体的な照明と火線の物理的補正シミュレーションを容易にする。１つの実施形態において、フォトンシェイダーは、前処理操作の間に、シーンイメージジェネレータ３０により、レンダリング中に使用される。（iii）フォトンシェイダーと類似しているが、オブジェクトの表面上の代わりに、シーンの空間の三次元体積と関連して作動することが異なる、フォトンボリュームシェイダー。これにより、ボリュームにまで拡張され、空気中の埃または霧粒子、または雲などの中の水蒸気によるフォトンの散乱のような、閉じた介在媒体を伴う、火線と全体照明のシミュレーションが可能になる。（iv）フォトンシェイダーに類似しているが、それらが光源に関連し、そのためフォトンの放射に関連しているところが異なる、フォトンエミッタシェイダー。フォトンエミッタシェイダーに関連して放射がシミュレートされるシミュレートされたフォトンは、シミュレートされたフォトンの経路および表面相互作用の特徴をシミュレートするために使用できるフォトンシェイダーと、特に個々の経路に沿って、三次元ボリュームにおける経路および他の特徴をシミュレートするために使用できるフォトンボリュームシェイダーと関連して処理してもよい。（v）レンダリング中に輪郭線の生成と関連して使用される、輪郭シェイダー。１つの実施形態においては、輪郭シェイダーの３つのサブタイプがあり、それは、輪郭格納シェイダーと、輪郭コントラストシェイダーと、輪郭生成シェイダーである。輪郭格納シェイダーは、例えば、表面に対する輪郭サンプリング情報を収集するために使用される。輪郭コントラストシェイダーは、輪郭格納シェイダーの使用により収集されたサンプリング情報の２つのセットを比較するために使用される。最後に、輪郭生成シェイダーは、バッファーへの格納のための生成輪郭ドット情報に使用され、それは輪郭線の生成の際に出力シェイダー（下記に記載）により使用される。（vi）レンダリング中に、シーンイメージジェネレータ３０により生成された、バッファー内の情報を処理するために使用される、出力シェイダー。出力シェイダーは、レンダリング中に生成されたピクセル情報にアクセスでき、１つの実施形態においては、構成操作、複雑変動、および上述したように、輪郭生成シェイダーにより生成された輪郭ドット情報からの輪郭線描画を行なう。（vii）シーンにおいて空の三次元空間の一部またはその全体を、光または他の可視光線などがどのように通過するかを制御するために使用される、三次元ボリュームシェイダー。三次元ボリュームシェイダーは、例えば、霧を含むボリューム効果、および煙、炎、毛、および粒子性雲のような手順化可能効果の多くの中からのいずれに対しても使用できる。更に、三次元ボリュームシェイダーは、光との関連において使用されるので、それらは、手順化可能効果に起因するシャドウとの関連においてもまた有効である。（viii）例えば、カラー、方向、および減衰の特徴であって、個々の光源の形状、テクスチャの突起、シャドウイング（shadowing）および他の光の特質のような特質に起因する特徴を含む、光源の放射特徴を制御するために使用される、。
【００３８】
シーンの定義に関連して有効であるシェイダーの他のタイプもまたフェノメノンにおいて使用できる。
フェノメノンは下記により定義される。（i）フェノメノンの外部制御可能なパラメータの記述、（ii）１つの主要ルートノードおよび、随意的に、１つまたは２つ以上のオプショナルルートノード、（iii）ノードとして使用されるシェイダーと、それがどのようにしてDAGまたは複数の協働DAGを形成するように相互接続されるかの特定を含む、フェノメノンの内部構造の記述、（iv）随意的に、フェノメノンエディタ２６による使用のために、フェノメノンにより定義されて、オペレータが、個々のフェノメノンの評価に使用されるパラメータまたは特質の値を提供できるようになる、ダイアログボックスなどの記述。更に、フェノメノンは、プログラミングでは標準である、外部宣言文およびライブラリからの、リンクで実行可能なコードを含むことができる。
【００３９】
上記したように、フェノメノンは、複数の協働DAGを含むことができる。そのようなフェノメノンにおいては、レンダリング中に、フェノメノンにおける第１DAGの１つまたは２つ以上のノードの処理により生成される情報が、フェノメノンにおける第２DAGの１つまたは２つ以上のノードと関連する処理に使用できる。２つのDAGは、それにも拘わらず、独立して処理され、レンダリング処理における異なるステージで処理できる。第２DAGにおけるノードと「協働」できる（つまり、その処理において、第２DAGにおけるノードにより使用できる）第１DAGにおける個々のノードにより生成される情報は、第１DAGにおける個々のノードから、第２DAGにおけるノードへ、そのために割り当てることができるバッファーのような、任意の都合のよい通信チャネルを介して転送できる。単一のフェノメノンにおいて上記の方法で協働する必要のあるすべてのDAGを提供することにより、協働のためのすべての条件が満たされる。この条件は、DAGが別個のフェノメノンまたは他のエンティティにおいてカプセル化されず、また分離もされずに提供される場合には満たされない。
【００４０】
いくつかの協働DAGを含むフェノメノンの例として、フェノメノンは、マテリアルシェイダーDAG，出力シェイダーDAG及びラベルフレームバッファーを生成するための指令を含む、いくつかのDAGを含む。マテリアルシェイダーDAGは、材料に対するカラー値を生成するための少なくとも１つのマテリアルシェイダーを含み、ラベルフレームバッファー生成指令の処理と関連して確立されるラベルフレームバッファーにおけるマテリアルシェイダーDAGの処理の間に遭遇するオブジェクトについてのラベル情報の格納も行なう。出力シェイダーDAGは、その結果として、少なくとも１つの出力シェイダーを含み、出力シェイダーは、ラベルフレームバッファーからラベル情報を検索して、オブジェクト特有な合成操作の実行を容易にする。ラベルフレームバッファー生成指令に加えて、フェノメノンは、両者のDAGが機能して協働できるように、シーンイメージジェネレータ３０の操作モードを制御する指令も有することができる。例えば、そのような指令は、評価される２つのDAGに対して要求される最小サンプル密度を制御できる。
【００４１】
複数の協働シェイダーDAGを含むフェノメノンの第２の例として、材料フェノメノンは、少なくとも１つのフォトンシェイダーを含むフォトンシェイダーDAGと、少なくとも１つのマテリアルシェイダーを含むマテリアルシェイダーDAGの両者によりシミュレートされる材料を表現できる。レンダリング中、フォトンシェイダーDAGは、火線および全体照明前処理の間に評価され、マテリアルシェイダーDAGは、後のイメージのレンダリングの間に評価される。フォトンシェイダーDAGの処理中に、シミュレートされたフォトンを表現する情報は、それが後のマテリアルシェイダーDAGの領域表現に使用できて、火線または全体照明前処理段階からの照明の貢献を追加するように格納される。１つの実施形態においては,フォトンシェイダーDAGは、フォトンマップにシミュレートされたフォトン情報を格納し、フォトンシェイダーDAGはそれを使用してシミュレートされたフォトン情報をマテリアルシェイダーDAGに送信する。
【００４２】
複数の協働シェイダーDAGを含むフェノメノンの第３の例として、フェノメノンは、少なくとも１つの輪郭シェイダータイプのシェイダーを含む輪郭シェイダーDAGと、少なくとも１つの出力シェイダーを含む出力シェイダーDAGを含むことができる。輪郭シェイダーDAGは、選択されたカラーの「ドット」、透明度、幅、および他の属性を格納することにより、輪郭線をどのように描くかを決定するために使用される。出力シェイダーDAGは、レンダリング中に作成されたすべてのセルの収集に使用され、レンダリングが完了したときに、それらを輪郭線に結合する。輪郭シェイダーDAGは、輪郭格納シェイダーと、輪郭コントラストシェイダーと、輪郭生成シェイダーを含む。輪郭格納シェイダーは、輪郭コントラストシェイダーによる後の使用のためのサンプリング情報を収集するために使用される。輪郭コントラストシェイダーは、その結果、輪郭格納シェイダーにより収集されたサンプリング情報が、輪郭ドットがイメージ内に置かれるようなものかどうかを判定するために使用され、もしそうであれば、輪郭生成シェイダーは実際に輪郭ドットを置く。この例としてのフェノメノンは、（１）サンプリング情報が（輪郭格納シェイダーにより）収集される第１ステージ、（２）輪郭セルを置くかどうかの決定が（輪郭コントラストシェイダーにより）なされる第２ステージ、（３）輪郭ドットが（輪郭生成シェイダーにより）作成される第３ステージ、および、（４）作成された輪郭ドットが（出力シェイダーDAGにより）作成される第４ステージを含む、４つのステージの協働を例示している。
【００４３】
いずれのステージにおいても、シェイダーは別のステージの別のシェイダーを利用することはなく、異なる時間において、個々に処理され、評価されるが、最終結果の生成を可能にするために協働する。
複数の協働シェイダーDAGを含むフェノメノンの第４の例として、フェノメノンは、ボリュームシェイダーDAGと幾何学的シェイダーDAGを含むことができる。ボリュームシェイダーDAGは、例えば、区切られたボリューム内の毛をシミュレートする毛シェイダーのような、区切られたボリュームの特質を定義する、少なくとも１つのボリュームシェイダーを含む。幾何学的シェイダーDAGは、外部境界表面を、新しい幾何学図形としてレンダリングが始まる前にシーンに含むために使用される少なくとも１つの幾何学的シェイダーを含み、適切な材料およびボリュームシェイダーDAGが外部境界表面に付加されて、元のボリュームシェイダーDAGに関連する毛に関連して実行される計算を定義する。この例示されたフェノメノンにおいて、協働は、幾何学的シェイダーDAGとボリュームシェイダーDAGの間で行なわれ、幾何学的シェイダーDAGは、幾何学的シェイダーDAGがボリュームシェイダーDAGをサポートする手順に従う幾何学図形を導入する。ボリュームシェイダーDAGは、この幾何学図形を利用するが、幾何学図形はレンダリングに先立ち前処理操作の間に幾何学的シェイダーDAGを使用して生成され、一方、ボリュームシェイダーDAGはレンダリング中に使用されるので、ボリュームシェイダーDAGは、幾何学図形それ自身を作成することはできない。この第４の例示的な例と関連して例示された協働は、幾何学的シェイダーを備えるシェイダーまたは複数のシェイダーは、ボリュームシェイダーDAGによる使用される要素を手順に従うように提供するが、第１から第３の例示の例との関連における協働のようにデータを格納することはしないので、第１から第３の例示的な例と関連して例示されたものとは異なる。
【００４４】
これらすべての例は、シーンのイメージが、単一のフェノメノンに束ねられ、カプセル化された複数の協働する、しかし独立しているシェイダーDAGを使用してレンダリングができるというコンピュータグラフィック効果を例示している。
このような背景により、フェノメノンクリエータ２４とフェノメノンエディタ２６と関連して実行される操作は、図３と図５それぞれに関連して記載される。更に、フェノメノンクリエータ２４と関連して作成される例示的なフェノメノンは、図４と関連して記載され、図４と関連して示されるフェノメノンと関連するフェノメノンエディタ２６により実行される操作の詳細は、図６Ａと図６Ｂと関連して記載される。図３は、フェノメノンクリエータウィンドウ４０を示し、フェノメノンクリエータ２４が、オペレータインタフェース２７にこのウィンドウをオペレータに表示できるようにし、それによりオペレータは、新しいフェノメノンを定義し、既存のフェノメノンの定義を修正できる。フェノメノンクリエータウィンドウ４０は、複数のフレーム、つまり、シェルフフレーム４１，サポートされたグラフノードフレーム４２，制御フレーム４３及びフェノメノングラフキャンバス・フレーム４４を含む。シェルフフレーム４１は、１つまたは２つ以上のフェノメノンアイコンを含むことができ、それらのアイコンはまとめて参照番号４５により特定され、それぞれは、シーン構造生成部２０における使用のために少なくとも部分的に定義されたフェノメノンを表現している。サポートされたグラフノードフレーム４２は、１つまたは２つ以上のアイコンを含み、それらのアイコンはまとめて参照番号４６により特定され、インタフェース、フェノメノンにおいて使用できる種々のタイプのシェイダーなど、オペレータがフェノメノンにおける使用のために選択できるエンティティを表現している。下記に記載されるように、サポートされたグラフノードフレーム４２に示されるアイコンは、オペレータが、作成または修正されるフェノメノンを定義する有向非循環グラフのノードを形成するために使用することができる。１つの実施形態においては、多数のタイプのノードがあり以下のものを含む。（i）有向非循環グラフのルートを形成し、シーンへの接続を形成し、典型的にはレンダリング中にカラー値を提供する、主要ルートノード。（ii）フェノメノンDAGにおけるアンカーポイントとして使用でき、主要ルートノード（上記の（i）項）を支援する、いくつかのタイプのオプショナルルートノード。オプショナルルートノードの例示的なタイプとしては以下のものが含まれる。（a）レンズシェイダーまたはレンズシェイダーDAGを、レンダリング中の使用のためにカメラに挿入するために使用できる、レンズルートノード。（b）グローバルボリューム（または雰囲気）シェイダーまたはシェイダーDAGを、レンダリング中の使用のためにカメラに挿入するために使用できる、ボリュームルートノード。（c）グローバル環境シェイダーまたはシェイダーDAGを、レンダリング中の使用のためにカメラに挿入するために使用できる、環境ルートノード。（d）レンダリング中に前処理でき、シーンの手順に従うサポート幾何学図形または他の要素をシーンデータベースに追加可能にする幾何学的シェイダーまたはシェイダーDAGを指定するために使用できる、幾何学ルートノード。（e）輪郭格納シェイダーを、シーンオプションデータ構造に挿入するために使用できる、輪郭格納ルートノード。（f）レンダリングフェーズの後、��工程と関連して使用できる、出力ルートノード。そして、（g）輪郭コントラストシェイダーを、シーンオプションデータ構造に挿入するために使用できる、輪郭コントラストルート。（iii）シェイダー、つまり、CまたはC++のような高級言語で記述される関数を表現する、シェイダーノード。（iv）光源と連係して使用される。光ノードは光源に、光シェイダー、カラー、強度、原点および／または方向、およびオプションとしてフォトンエミッタシェイダーを提供する、光ノード。（v）表面と連係して使用される。材料ノードは表面に、カラー値を提供し、表面が不透明かどうかを示す不透明表示、材料、ボリューム、環境、シャドウ、変位、フォトン、フォトンボリューム、および輪郭シェイダーに対する入力を有する、材料ノード。（vi）フェノメノンのインスタンスである、フェノメノンノード。（vii）他の任意のノードへの入力である、一定値を提供する、一定ノード。一定値は、シェイダーのようなエンティティに対して使用されるプログラミング言語のほとんどのデータタイプであってよく、スカラー、ベクトル、ロジック（ブーリアン（Boolean））、カラー、変換などのような他のノードのいずれによっても表現できる。（viii）フェノメノンエディタ２６によりオペレータに表示できるダイアログボックスを表現し、オペレータが使用して、レンダリングの前またはその最中にフェノメノンを制御するための入力情報を提供できる、ダイアログノード。ダイアログノードは、フェノメノンエディタ２６がプッシュボタン、スライダ、ホイールなどを表示できるようにして、オペレータが、例えば、ダイアログノードを含むフェノメノンが接続されている表面と関連して使用されるカラーおよび他の値を指定できるようにすることが可能である。図３に示されるように、シェルフフレーム４１およびサポートされたグラフノードフレーム４２は両者とも、まとめて参照番号４７として特定される、左および右矢印を含み、それにより、個々のフレームに示されるアイコンが、左または右へシフトでき（図３に示すように）、一度に表示できる以上のエンティティがある場合は、アイコンをシフトしてフェノメノンクリエータウィンドウ４０に表示されるようにできる。
【００４５】
制御フレーム４３は、オペレータが、例えば、シェルフフレーム４１またはサポートされたグラフノードフレーム４２におけるノードを消去または複製、新しいフェノメノンの構築の開始、オンラインヘルプシステムの開始、フェノメノンクリエータ２４の終了などの制御操作を行なうために使用できるボタンを表現するアイコン（図示せず）を含む。
フェノメノングラフキャンバス４４は、フェノメノンがオペレータにより作成または修正できる領域を提供する。オペレータが既存のフェノメノンを修正したいと所望するときは、オペレータはマウスのようなポインティングデバイスを使って、「ドラッグアンドドロップ」の方法によりアイコン４５を選択して、フェノメノンを表現しているシェルフフレーム４１から、フェノメノングラフキャンバス４４にドラッグできる。修正されるフェノメノンに関連する、選択されたアイコン４５がフェノメノングラフキャンバス４４にドラッグされた後、オペレータは、アイコン４５を、矢印により相互接続され、フェノメノンを定義するグラフを表現している、１つまたは２つ以上のノードを示すように拡張することができる。例示的なフェノメノンを表現しているグラフ５０は、図３に示されている。図３に示すように、グラフ５０は、複数のグラフノードを含み、円およびブロックを備え、それぞれは、フェノメノンにおいて使用できるエンティティと関連しており、ノードは、矢印により相互接続され、フェノメノンに関連するグラフを定義する。
【００４６】
フェノメノングラフキャンバス４４にドラッグされたアイコン４５に関連するグラフが拡張されてアイコン４５に関連するフェノメノンを定義するグラフを示すようになった後、オペレータは、フェノメノンを定義するグラフを修正できる。その操作において、オペレータは、対応する「ドラッグアンドドロップ」の方法を使用して、アイコン４６を選択して、グラフに追加されるエンティティを表現するサポートされるグラフノードフレーム４２から、フェノメノングラフキャンバス４４へドラッグして、それにより、グラフの新しいノードが確立される。新しいノードが確立された後、オペレータは、適切な方法で、両者のノードをクリックして、その間に矢印が表示されるようにして、それを既存のグラフにおけるノードに相互接続できる。グラフにおけるノードはまた、個々のノードの間に延伸する矢印を削除することにより、他のノードから切離すことも、制御フレーム４３にある削除プッシュボタンの適切な起動によりグラフから削除することもできる。
【００４７】
同様に、オペレータが新しいフェノメノンを作成したいときは、オペレータは、対応する「ドラッグアンドドロップ」の方法を使用して、アイコン４６を選択して、グラフに追加されるエンティティを表現するサポートされるグラフノードフレーム４２から、フェノメノングラフキャンバス４４へドラッグすることにより、作成すべきグラフに対して新しいノードを確立できる。新しいノードがフェノメノングラフキャンバス４４に確立された後は、オペレータは、適切な方法で、両者のノードをクリックして、その間に矢印が表示されるようにして、それを既存のグラフにおけるノードに相互接続できる。グラフにおけるノードはまた、個々のノードの間に延伸する矢印を削除することにより、他のノードから切離すことも、制御フレーム４３にある削除プッシュボタンの適切な起動によりグラフから削除することもできる。
【００４８】
オペレータがフェノメノンのためのDAGまたは協働DAGのセットを指定した後、新しいフェノメノンまたは修正されたフェノメノンのいずれかに対して、グラフにより表現されているフェノメノンがフェノメノンデータベース２５に格納される前に、フェノメノンクリエータ２４は、それが矛盾のない、レンダリング中に処理できるかどうかを検証するためにフェノメノングラフを調べる。その操作において、フェノメノンクリエータ２４は、グラフノード間の相互接続が、循環を形成しないことを確実にし、それにより、フェノメノンに関連するグラフまたは複数のグラフが有向非循環グラフを形成することを確実にし、グラフノード間の相互接続が、矛盾のない個々の入力および出力データタイプを表現していることを確実にする。フェノメノンクリエータ２４が、グラフノードは循環を形成すると判定すると、フェノメノンは本質的に、一般的には適切に処理できないエンドレスループを形成する。これらの操作により、そのように作成または修正されたフェノメノンが、フェノメノンが付加されたシーンのイメージがレンダリングされるときに、シーンイメージ生成部により処理できることが保証される。
【００４９】
オペレータがフェノメノンを作成または修正した後、それはフェノメノンデータベース２５に格納される。
図４は、図３に関連して記載したフェノメノンクリエータウィンドウを使用して生成できるフェノメノンクリエータ２４に関連して作成されたフェノメノンの例を示す。図４に示されるフェノメノンの例は、参照番号６０で特定され、木材料の表面の特徴に対して使用できる１つである。図４を参照すると、フェノメノン６０は、参照番号６１で特定される１つのルートノードを含み、それはフェノメノン６０をシーンの要素に付加するために使用される。グラフにおける他のノードには、マテリアルシェイダーノード６２、テクスチャシェイダーノード６３、コヒーレントノイズシェイダー・ノード６４が含まれ、それぞれマテリアルシェイダー、テクスチャシェイダー、およびコヒーレントノイズシェイダーを表現し、そしてダイアログノード６５が含まれる。ダイアログノード６５は、フェノメノンエディタ２６により表示され、オペレータが、イメージがレンダリングされるときにフェノメノンと共に使用される入力情報を提供できるダイアログボックスを表現する。
【００５０】
マテリアルシェイダー、テクスチャシェイダー、およびコヒーレントノイズシェイダーの詳細は、この技術に精通した者には知られており、ここではこれ以上の記載はしない。一般的に、マテリアルシェイダーは、１つまたは２つ以上の、「結果」により表現される出力を有し、これはルートノード６１に提供される。マテリアルシェイダーは、その結果、「光沢度」入力、「周囲」カラー入力、「拡散」カラー入力、「透明度」入力、および「照明」入力を含むいくつかの入力を有し、それにより表現されるマテリアルシェイダーノード６２が、それらに対する入力をダイアログノード６５（光沢度入力の場合）から、テクスチャシェイダーノード６３（周囲および拡散カラー入力の場合）から、ハードワイヤード定数（透明度入力の場合）から、そして照明リスト（照明入力の場合）から受け取るものとして示されている。「０.０」と表示され、透明度入力に提供されるハードワイヤード定数値は、材料が不透明であることを示している。「光沢度」入力は、ダイアログノード６５により提供される「光沢度」出力に接続され、ノード６２により表現されるマテリアルシェイダーがレンダリング中に処理されるときに、それに対する光沢度入力値を、ダイアログノードにより表現されるダイアログボックスから取得し、この様子は図６Ａと図６Ｂにより、下記に記載する。
【００５１】
ノード６２により表現されるマテリアルシェイダーの周囲および拡散入力は、ノード６３の「結果」出力の、ノード６２の個々の入力への接続により示されているように、テクスチャシェイダーの出力により提供される。木材料フェノメノン６０が、レンダリング操作中に処理されるとき、そして特に、ノード６２により表現されるマテリアルシェイダーが処理されるときは、処理されるノード６３により表現されるテクスチャシェイダーが、周囲および拡散カラー入力値を提供することを可能にする。その結果、テクスチャシェイダーは、ノード６３上に示される「カラー１」および「カラー２」入力で表現される周囲および拡散カラー入力と、「混合」入力を含む、３つの入力を有することになる。周囲および拡散カラー入力に対する値は、ダイアログノード６５からのそれぞれの拡散および周囲カラー出力から、図４のテクスチャシェイダーノード６３への接続により表現されるように、オペレータが、ダイアログノード６５により表現されるダイアログボックスを使用することにより提供される。
【００５２】
更に、ノード６３により表現されるテクスチャシェイダーの入力に対する入力値は、ノード６４により表現されるコヒーレントノイズシェイダーにより提供される。このように、ノード６３により表現されるテクスチャシェイダーが、レンダリング操作中に処理されるとき、処理されるノード６４により表現されるコヒーレントノイズシェイダーが、混合入力値を提供することが可能になる。コヒーレントノイズシェイダーは、「乱流（turbulence）」入力と「円柱形（cylindrical）」入力を含む２つの入力を有する。乱流入力に対する値は、ダイアログノード６５からの乱流出力から、コヒーレントノイズシェイダー・ノード６４への接続で表現されるように、ダイアログノード６５により表現されるダイアログボックスを使用して、オペレータにより提供される。ロジック値「真」で示される、円柱形入力に対する入力値は、フェノメノン６０へハードワイヤードされている。
【００５３】
フェノメノンエディタ２６により実行される操作を図５により記載する。図５は、フェノメノンエディタウィンドウ７０を示し、それはフェノメノンエディタ２６が、オペレータインタフェース２７により表示できるようにし、本発明の１つの実施形態においては、オペレータはそれを使用して、シーンに付加されたフェノメノンに対する入力値を確立および調整する。特に、オペレータは、フェノメノンエディタウィンドウを使用して、図３で上述したように、作成または修正中に個々のフェノメノンに対して確立された、ダイアログノード６５（図４）のようなダイアログノードに関連するダイアログボックスにより提供されるフェノメノン用の値を確立することができる。フェノメノンエディタウィンドウ７０は、シェルフフレーム７１および制御フレーム７２を含む複数のフレームを含み、また、フェノメノンダイアログウィンドウ７３とフェノメノンプレビューウィンドウ７４を含む。シェルフフレーム７１は、シーンに付加するために使用できる種々のフェノメノンを表現するアイコン８０を示す。フェノメノンクリエータウィンドウ４０（図３）と同様に、シェルフフレームは、まとめて参照番号８１として特定される、左および右矢印アイコンを含み、それにより、個々のフレームに示されるアイコンが、左または右へシフトでき（図３に示すように）、一度に表示できる以上のアイコンがある場合は、アイコンをシフトしてフェノメノンエディタウィンドウ７０に表示されるようにできる。
【００５４】
制御フレーム７３は、オペレータが、シェルフフレーム７１におけるノードを消去または複製、オンラインヘルプシステムの開始、フェノメノンエディタ２６の終了などの制御操作を行なうために使用できるボタンを表現するアイコン（図示せず）を含む。
オペレータは、そのパラメータ値が、フェノメノンのインスタンスを作成するために、マウスのようなポインティングデバイスを適切に操作することにより確立されるフェノメノンを選択できる。（フェノメノンのインスタンスはそのパラメータ値が固定されたフェノメノンに対応する。）オペレータがフェノメノンを選択した後、フェノメノンエディタ２６は、オペレータインタフェース２７が、そのダイアログノードに関連するダイアログボックスを、フェノメノンダイアログウィンドウに表示できるようにする。図４に関して上述した木材料フェノメノン６０の１つの実施形態と関連して使用される例としてのダイアログボックスは、図６Ａと図６Ｂにより下記に記載される。オペレータが、ダイアログボックスを介して提供できる入力値を提供および調整すると、フェノメノンエディタ２６は、効率的にフェノメノンを処理して結果としての出力をフェノメノンプレビューウィンドウ７４に表示する。このように、オペレータは、フェノメノンエディタウィンドウ７０を使用して、フェノメノンダイアログウィンドウに表示されたダイアログボックスを介して利用できる入力を使用してオペレータが確立する値の結果を見ることができる。
【００５５】
図６Ａと６Ｂは、図４に示された木材料フェノメノン６０に関連して使用される、ダイアログノード（図６Ａの場合）と、例としての関連するダイアログボックス（図６Ｂの場合）の詳細を示している。図４において参照番号６５で特定されるダイアログノードは、オペレータが、フェノメノンクリエータ２４を使用して、それに関連付けられる特別なフェノメノンの作成または修正の処理中にオペレータにより定義および作成される。図６Ａを参照すると、ダイアログボックス６５は、複数のタイル、つまり、周囲カラータイル９０と、拡散カラータイル９１と、乱流タイル９２と、光沢度タイル９３を含む。図４で上述したように、個々のタイル９０から９３は、ダイアログノード６５により提供された周囲、拡散、乱流、および光沢度出力値それぞれに関連しているということは理解されよう。周囲および拡散カラータイルは、カラー値に関連付けられ、従来の赤／緑／青／アルファ、または「ＲＧＢＡ」のカラー／透明度仕様を使用して指定することができ、このようにして、各カラータイルは、それぞれがカラー表現における赤、緑、および青色と、透明度（アルファ）に対して、複数の入力値に実際には関連付けられる。他方、乱流と光沢度タイル９２と９３のそれぞれは、スカラー値に関連付けられる。
【００５６】
図６Ｂは、フェノメノンエディタ２６の制御のもとでオペレータインタフェース２７により表示されるように、ダイアログノード６５（図６Ａ）に関連する例としてのダイアログボックス１００を示している。ダイアログボックス１００において、ダイアログノード６５の周囲および拡散カラータイル９０と９１のそれぞれは、オペレータインタフェース２７により、全体として参照番号１０１と１０２で特定される個々のスライダセットとしてそれぞれ表示され、その各々は、レンダリング中に関連するフェノメノンの処理中に使用されるカラー表現のカラーの１つに関連付けられる。更に、ダイアログノード６５の乱流および光沢度タイル９２と９３はそれぞれ、オペレータインタフェースにより個々のスライダ１０３と１０４として表示される。個々のスライダセット１０１と１０２におけるスライダは、従来の方法で、マウスのようなポインティングデバイスを使用して、オペレータにより操作され、それにより、フェノメノンエディタ２６が、ダイアログノード６５によりフェノメノン６０（図４）の他のノードに関連するシェイダーに提供された個々の周囲および拡散カラー値に対するカラーの個々の組み合わせを調整することが可能になる。更に、乱流と光沢度入力に関連するスライダ１０３と１０４はオペレータが操作することができ、それにより、フェノメノンエディタ２６が、ダイアログノード６５により、木材料フェノメノン６０の他のノードに関連するシェイダーに提供された個々の乱流および光沢度値を調整することができるようになる。
【００５７】
図２に戻って、オペレータがフェノメノンエディタ２６を使用して、種々のフェノメノンに対する値と、シーンに関連するフェノメノンインスタンスを確立した後、これらの値は、シーンと共にシーンオブジェクトデータベース２２に格納される。その後、シーンイメージ生成部２１、特にシーンイメージジェネレータ３０によりシーンのイメージのレンダリングが可能になり、オペレータインタフェース３１により表示される。シーンイメージジェネレータ３０により実行される操作は、図７に示されるフローチャートにより概略が記載される。図７を参照すると、シーンイメージジェネレータ３０は、前処理フェーズ、レンダリングフェーズ、および後処理フェーズを含む一連のフェーズにおいて作動する。前処理フェーズにおいては、シーンイメージジェネレータ３０は、シーンに付加されたフェノメノンを調べて、前処理および／または後処理操作を、それに関連して実行する必要があるかどうかを判定する（ステップ１００）。その後、シーンイメージジェネレータ３０は、ステップ１００における操作が、前処理操作がシーンに付加された少なくとも１つのフェノメノンに関連して必要かどうかを判定し（ステップ１０１）、もし必要であれば、前処理操作を実行する（ステップ１０２）。例としての処理操作には、例えば、シーンに付加されたフェノメノンが幾何学シェイダーを含むならば、それによりシーンに対して定義された幾何学図形を生成するための幾何学図形の生成が含まれる。他の例としての前処理操作には、例えば、シャドウおよびフォトンマッピング、多重継承分析などが含まれる。ステップ１０２またはステップ１０１に続いて、シーンイメージジェネレータ３０がそのステップで否定的な判定をした場合は、シーンイメージジェネレータ３０は、レンダリングに先立ちシーン表現に関連して要求され、シーンに付加されたフェノメノンには関係のない更なる前処理操作を実行できる（ステップ１０３）。
【００５８】
ステップ１０３の後、シーンイメージジェネレータ３０は、レンダリングフェーズを実行し、そこにおいて、前処理されたシーン表現に関連するレンダリング操作を、レンダリングされたイメージを生成するために実行する（ステップ１０４）。その操作において、シーンイメージジェネレータ３０は、シーンオブジェクトデータベース２２に格納され、シーンの種々の構成要素に付加されるフェノメノンを、エンティティ幾何学的表現ジェネレータ２３により生成されたものと特定し、それぞれにフェノメノンのすべての主要およびオプションのルートノードを、ルートノードのタイプに適切なシーン構成要素に付加する。その後、シーンイメージジェネレータ３０はイメージのレンダリングを行なう。更に、シーンイメージジェネレータ３０は、必要であれば、後処理フェーズの間に後処理操作において使用できる情報を生成する。
【００５９】
レンダリングフェーズ（ステップ１０４）の後、シーンイメージジェネレータ３０は、後処理フェーズを実行する。その操作において、シーンイメージジェネレータ３０は、ステップ１００で実行された操作が、後処理操作が、シーンに付加されたフェノメノンに関連して要求されることを示したかどうかを判定する（ステップ１０５）。シーンイメージジェネレータ３０がステップ１０５において肯定的な判定をすると、そのシーンに付加されたフェノメノンに関連して要求される後処理操作を実行する（ステップ１０６）。更に、シーンイメージジェネレータ３０は、ステップ１０６において、フェノメノンには関係しない後処理操作を実行できる。シーンイメージジェネレータ３０は、カラー補正のための操作ピクセル値と関連して後処理操作を実行することができ、フィルタ処理して種々の光学効果を提供する。更に、シーンイメージジェネレータ３０は、例えば、シーンに付加されたフェノメノンが、１つの実施形態においては、レンダリングされたイメージと関連して、例えば、各ピクセル値と関連して格納された速度および深度情報に依存して、出力シェイダーにおいて完全に行なえる被写界深度または動きによるブレの計算のような後処理操作を定義する出力シェイダーを含む場合は、後処理操作を実行できる。
【００６０】
本発明は数多くの利点をもたらす。特に、本発明は、フェノメノンを作成（フェノメノンクリエータ２４を参照）および操作（フェノメノンエディタ２６を参照）するための機構を提供するコンピュータグラフィックシステムを提供する。そのように作成されたフェノメノンは、フェノメノンクリエータ２４により処理されて、それらが矛盾なく、レンダリング中に処理できるということが保証される。フェノメノンはシーンに付加される前に作成されるので、フェノメノンがプログラマまたは他のコンピュータプログラム開発の専門家により作成でき、それにより、プログラムを展開する必要のあるアーティスト、製図者などの負担を軽減するということは理解されよう。また、フェノメノンは、アーティストから、シーンに多数の異なる相互に関連するシェイダーを構成する複雑さを、フェノメノン作成専門家ユーザーにより前もって実行できる独立したタスクに分離することにより開放する。フェノメノンを使用すれば、構成作業はかなり自動化できる。フェノメノンまたはフェノメノンインスタンスがいったん作成されれば、それはシーンからは独立しており、多数のシーンに再使用でき、繰返し作業を回避できる。
【００６１】
本発明に対して、多数の変更および修正が加えられることは理解されるであろう。上述したように、フェノメノンは、シーンに関連する使用とは分離して作成できるので、フェノメノンを作成および修正するために使用されたフェノメノンクリエータ２４と、フェノメノンインスタンスを作成するために使用されたフェノメノンエディタ２６は、別のコンピュータグラフィックシステムに設けることができる。例えば、フェノメノンエディタ２６を含むコンピュータグラフィックシステム１０は、例えば、フェノメノンデータベース２５が適切な、予め作成されたフェノメノンを含み、オペレータがフェノメノンを作成または修正する必要がなければ、フェノメノンクリエータ２４を含む必要はない。
【００６２】
更に、上述したように、フェノメノンのパラメータの値は固定であってもよく、または１つまたは２つ以上の変数の関数に基づいて変化してもよい。例えば、個々のパラメータの１つまたは２つ以上の値が時間を変数として変化すると、フェノメノンインスタンスは、時間依存、または「動画化」できる。これは通常は、動画を備える一連のフレームのフレーム番号により分類される時間間隔に分離されるが、時間依存性は、それにも拘わらず、任意のフェノメノンパラメータ値が付けられた、時間に関する関数の形式を採ることができ、そのそれぞれは絶対時間値によりタグ付けされ、それにより、イメージが連続フレーム番号でレンダリングされても、シェイダーは分離区間には拘束されない。
【００６３】
これに関連して、フェノメノンエディタが、フェノメノンの１つまたは２つ以上のパラメータに対する時間依存値を選択するために使用され、時間依存する「フェノメノンインスタンス」を作成する。１つの特別な実施形態においては、フェノメノンのパラメータに対する時間依存値の選択は、ここでは、「フェノメノン特質制御ツリー」と称されるものを、フェノメノンに対し、グラフィカルで対話的な付加をすることにより達成される。フェノメノン特質制御ツリーは、ツリーまたはDAGの形式であってもよいが、フェノメノンパラメータに付加され、特にフェノメノンの外では効果的に付加され、フェノメノンと共に、フェノメノンインスタンスデータベースに格納される。フェノメノン特質制御ツリーは、１つまたは２つ以上のノードから構成され、そのそれぞれは、それが、例えば、運動曲線、データルックアップ関数などを提供する関数という意味で、シェイダーである。フェノメノン特質制御ツリーは、好ましくは浅く維持され、通常は、非常に少ない分岐レベルしか有しない。フェノメノン特質制御ツリーはただ１つのシェイダーから構成でき、起動時に、関連付けられるパラメータに対する値を計算する関数を定義する。フェノメノン特質制御ツリーは、浅く維持することができるが、これは、フェノメノンは複雑なシェイダーツリーまたはDAGのカプセル化を可能にしかつ促進し、レンダリングステップにおいて、例えば、再使用のためにデータ格納することにより、最適な方法での評価を促進するからである。オペレータがそのようなフェノメノン特質制御ツリーを付加して、フェノメノンのパラメータの制御を可能にすることは、ユーザーが前もって定義されパッケージ化されたフェノメノンの使用に基づくカスタム効果を達成するという柔軟性を大幅に改善する。このようにして作成できる相異なるフェノメノンインスタンスの数は、そのため非常に増大し、一方、使い易さは、フェノメノンにおける複雑さのすべてのカプセル化により低められることはない。
【００６４】
更に、図３と図５で記載された、フェノメノンクリエータ２４とフェノメノンエディタ２６と関連して使用されたウィンドウの外観と構造は、ここで記載されたものとは異なってもよい。
本発明に従うシステムは、そのいずれの部分も適切なプログラムで制御できる特別目的ハードウェアまたは汎用コンピュータシステム、またはそのいかなる組み合わせからでも、その全体または一部を構築できるということは理解されよう。任意のプログラムは、その全体またはその一部において、従来の方法でシステムの一部を含み、またはシステムに格納することができ、またはその全体またはその一部を、ネットワークまたは、従来の方法で情報を転送する他の機構を介して、システムに設けることができる。更に、システムは、システムに直接接続できる、または、ネットワークまたは、従来の方法で情報を転送する他の機構を介して、情報をシステムに転送できるオペレータ入力要素（図示せず）を使用して、オペレータにより提供される情報により操作および／または制御できる。
【００６５】
米国特許第６，４９６，１９０号明細書において記載され、上記に検討したフェノメノンシステムは非常に有効であることが実証されたが、最近は、多数のシェイディングプラットフォームおよび言語が開発され、そのため、ビデオゲーム用のハードウェアシェイングであろうが、動画における視覚効果のためのソフトウェアシェイディングであろうが、現在存在するシェイダー言語は特別なプラットフォームおよびアプリケーションに狭く焦点が合わされてきている。従来のシェイダーシステム及び言語に典型的なこのプラットフォームの依存性は、重大な制限であり得る。
【００６６】
従って、下記の節とその項においては、（１）プラットフォームに独立で、単一の言語またはシステム構築のもとで種々のシェイディングツールおよびアプリケーションを統合できるシェイダー方法およびシステムと、（２）効率的で簡単な、シェイダーの再使用と再目的化を可能にし、頻繁に普通に発生する（例えば、Lara Croft-Tomb Raider）、ビデオゲームおよび特作映画の統合に有効である方法とシステムと、（３）コンピュータプログラミングの必要がなく、シェイダーの設計および構築を容易にし、アーティストに対して有効な方法とシステムと、（４）シェイダーのグラフィカルなデバッグを可能にし、シェイダーの作成者がシェイダーにおける欠陥を検出して解決するようにできる方法とシステムを記載する。
【００６７】
第ＩＩ節  メンタルミル
図８は、本発明の１つの形態による全体の方法１５０のフローチャートを示す。記載される方法は、コンピュータグラフィックシステムにおいて、少なくとも１つのシェイダーノードを備えるカプセル化されたシェイダーDAGを備える、少なくとも１つのインスタンス化されたフェノメノンが付加された表現から、シーンのイメージの生成を可能にする。
【００６８】
ステップ１５１において、ネットワークにおいてより複雑なシェイダーを構築するために組み合わせることができる構成要素シェイダーを備えるメタノードの作成のために作動可能な、メタノード環境が構築される。
ステップ１５２において、メタノード環境と連絡状態にあり、メタノード環境を管理して、ユーザーが、メタノード環境を使用して、シェイダーグラフおよびフェノメノンを構築できるようにするグラフィカルユーザーインタフェース（GUI）が構築される。
【００６９】
ステップ１５３において、ソフトウェア言語が、人間のオペレータにより使用でき、メタノード環境を管理し、シェイダーを実践し、分離したシェイディングアプリケーションを統合できるようにするインタフェースとして提供される。ソフトウェア言語は、選択されたハードウェアプラットフォームに対する複数の選択されたシェイダー言語のスーパーセットとして構築可能であり、コンパイラ機能が、ソフトウェア言語において表現されたフェノメノンの単一の、再使用できる記述から、選択されたシェイダー言語において選択されたハードウェアプラットフォームに対する最適化ソフトウェアコードを生成することを可能にする。
【００７０】
ステップ１５４において、少なくとも１つのGUIライブラリが提供され、それはメタノード環境と関連して使用でき、シェイダーグラフおよびフェノメノンを構築できるようなGUIを生成できる。
ステップ１５５において、対話的で、視覚的、リアルタイムのデバッグ環境が構築され、それはGUIと連絡状態にあり、（１）ユーザーがシェイダーにおける潜在的な欠陥を検出して補正できるようにし、（２）テスト中のシェイダー、メタノード、またはフェノメノンによるテストシーンが、常にレンダリングされるビューイングウィンドウを提供するように作動可能である。
【００７１】
ステップ１５６において、設備が構築され、それはコンパイラ機能と連絡状態にあり、選択されたハードウェアプラットフォームと、選択されたシェイダー言語に対して最適化されたソフトウェアコードを、選択されたシェイダー言語に対して、固有のコンパイラ機能を使用して、選択された集積回路インスタンス化に対する機械コードに変換するように作動可能である。
【００７２】
下記の検討は、次のように４つの主要な節にまとめられる。
Ａ．メンタルミル機能概観
Ｂ．メンタルミルGUI仕様
Ｃ．MetaSL設計仕様
Ｄ．MetaSLシェイダーデバッガ
【００７３】
Ａ.メンタルミル機能概観
メンタルミル（商標）技術は、視覚効果のためのシェイダーの作成に改良されたアプローチを提供する。メンタルミルは、今日、シェイダーライターが直面する多数の問題を解決し、将来のシェイダープラットフォームの変更および展開に対して、将来に備えてシェイダーに耐性を付与する。
【００７４】
スタンドアロンの操作に対するユーザーインタフェースを提供することに加えて、メンタルミルは、更に、シェイダー作成を管理するAPIを提供するライブラリを含む。このライブラリは、構成要素化する方法で、サードパーティのアプリケーションに統合でき、アプリケーションが、それが必要とするメンタルミルの構成要素のみを使用できるようにする。
【００７５】
メンタルミルシェイディングの基盤は、メンタルミルシェイディング言語MetaSL（商標）である。MetaSLは、単純であるが、シェイダーを実践するために特別に設計された表現豊かな言語である。メンタルミルは、シェイダーネットワークで組み合わされて、より複雑で、視覚的に興味あるシェイダーを構築できる、単純でコンパクトな構成要素化されたシェイダー（メタノード（商標）と称する）の作成を促進する。
【００７６】
MetaSLの目標は、別のシェイディング言語を導入することではなく、既存の言語のパワーを、単一のメタ言語、MetaSLを介して活用しようとすることである。現在存在するシェイダー言語は、相対的に特別なプラットフォームまたは状況、例えば、ゲーム用ハードウェアシェイディング、または特作映画視覚効果用のソフトウェアシェイディングに焦点を当てている。MetaSLは、これらのシェイディングアプリケーションを単一の言語に統合する。
【００７７】
メンタルミルは、「メタノード」と称されるシェイダーブロックの作成を可能にし、メタノードは、MetaSLで書かれ、洗練されたシェイダーグラフおよびフェノメノン（商標）を形成するために付加され、組み合わされる。シェイダーグラフは、シェイダーコードを書くための技術的専門知識がないユーザーがアクセス可能なシェイダーを作成するための、直感的なグラフィカルユーザーインタフェースを提供する。メンタルミルのグラフィカルユーザーインタフェース・ライブラリは、シェイダーグラフとフェノメノンを構築するための完全なグラフィカルユーザーインタフェースをユーザーに提供するために、シェイダーグラフパラダイムを利用する。下記に詳細に検討するように、本発明は、「メタノード環境」、つまり、メタノードの作成と操作のために作動可能な環境を提供する。更に、下記で検討されるように、記述されたメタノード環境は、ソフトウェア、またはソフトウェアとハードウェアの組み合わせとして実装できる。
【００７８】
スタンドアロンの適用は、メンタルミルの一部として含まれるが、メンタルミルはクロスプラットフォーム（cross-platform）、構成要素化されたライブラリを提供するので、サードパーティのアプリケーションへの統合が可能なようにも設計されている。スタンドアロンのメンタルミルのアプリケーションは、単に、これらのライブラリを、他の任意のアプリケーションと同じように使用する。メンタルミルライブラリは、下記のように細分化できる。（１）フェノメノン・クリエータ・グラフィカルユーザーインタフェース（GUI）、（２）フェノメノンフェノメノンシェイダーグラフ・コンパイラ、および（３）MetaSLシェイディング言語コンパイラ。
【００７９】
メンタルミル・フェノメノン・クリエータGUIライブラリは、GUI構成要素の一群を提供し、それにより、広汎な技術的専門知識を有するユーザーが、複雑なシェイダーおよびフェノメノンを作成することが可能になる。
主なGUI構成要素は、シェイダーグラフビューである。このビューは、ユーザーが、シェイダーノード（メタノードまたは他のフェノメノン）を作成し、それらを記述されたグラフに一緒に付加することによりフェノメノンを構築することを可能にする。シェイダーグラフは、シェイダーコードを見ているときには見つけられないシェイダープログラムの明確な視覚表現を提供する。これにより、シェイダーの作成を、シェイダーコードを書くための技術的専門知識がないユーザーが行なえるようにする。GUIライブラリはまた、他のユーザーインタフェース構成要素を提供し、下記にまとめてある。
【００８０】
・シェイダーパラメータエディタ−スライダ、カラーピッカー、および、シェイダーパラメータ値の編集を促進する他の制御ツールを提供する。
・レンダリングプレビューウィンドウ−ユーザーのシェイダーの進行に関しての、ユーザー対話的フィードバックを提供する。
・フェノメノンライブラリエクスプローラ−ユーザーが前もって構築されたフェノメノンのライブラリを閲覧および維持できるようにする。
【００８１】
・メタノードライブラリエクスプローラ−ユーザーが、メタノードの組織化されたツールボックス、フェノメノンの基盤構築ブロックを閲覧および維持することを可能にする。
・コードエディタおよび統合開発環境（IDE）−より技術レベルが高いユーザーが新しいメタノードをMetaSLで開発するために必要なツールを提供する。IDEは、メンタルミルGUIと統合されて、対話的視覚フィードバックを提供する。更に、IDEは、シェイダーにおける欠陥の位置を発見し補正するための高いレベルの対話的視覚デバッガを提供する。
【００８２】
メンタルミルGUIライブラリは、構成要素化されたクロスプラットフォームである。ライブラリは、いかなる特別なオペレーティングシステムまたはプラットフォームのユーザーインタフェースライブラリに依存することなく開発された。
更に、メンタルミルGUIライブラリは、サードパーティのアプリケーションへの統合のために設計されている。GUIライブラリの構成要素は、デフォルトのルック＆フィールを有するが、プラグインインタフェースが、フェノメノンクリエータGUIの見かけと感触が、ホストアプリケーションのルック＆フィールに合うようにカスタマイズすることを可能にするために提供される。
【００８３】
MetaSLシェイディング言語は、今日利用できる多数のシェイディング言語を統合し、新しい言語とプラットフォームが、将来登場したときにそれらをサポートするように拡張可能である。これによりMetaSLは、プラットフォーム依存性からの脱却が可能になる。
MetaSLは、単純であるが、シェイダーのライターのニーズに目標を置いた強力な言語である。それにより、シェイダーを、それがなければ快適なプログラミングを感じることがないユーザーによりアプローチできる、コンパクトで非常に読みやすい構文で書くことが可能になる。
【００８４】
MetaSLシェイダーは、特別なプラットフォーム上に依存することなく書くことができるので、MetaSLシェイダーは、多様な異なる方法で使用できる。単一のシェイダーは、ソフトウェアでオフラインのレンダリング、またはハードウェアのリアルタイムのレンダリングに使用できる。同じシェイダーは、次世代のビデオゲームコンソールにより使用されるような、異なるプラットフォーム間でも使用できる。
【００８５】
シェイダーをMetaSLで書くことにより、シェイダーの開発に費やした時間は、いかなる言語からも取り残されることなく保護され、多数の異なるプラットフォーム上での再使用の可能性により活用される。
メンタルミルライブラリの一部であるMetaSLコンパイラそれ自身は拡張可能である。コンパイラのフロントエンドはプラグインなので、他の言語または構文に対するパーサー（オペランド解析器）（parser）は、MetaSLフロントエンドと置き換えることができる。同様に、コンパイラのバックエンドもまたプラグインなので、新しいターゲットプラットフォームは、将来容易にサポートされる。メンタルミル・コンパイラ・ライブラリの両者のエンドに対する拡張性により、それがシェイダー世代のハブになることが可能になる。
【００８６】
シェイダーのライターは、典型的にいくつかのフロント上の困難に直面する。下記に節は、これらの問題と、完全なソリューションセットを提供すべく設計された、メンタルミル技術の作成の裏にある論理的根拠の概要を述べる。
メンタルミルにより開発されたシェイダーは、プラットフォームには依存しない。これはメンタルミルの重要な特徴であり、シェイダーの開発に費やされた努力が、目標とするプラットフォームが発展するにつれて無駄になることはない。このプラットフォームの独立性は、MetaSLで書かれたシェイダーと、メタノードのシェイダーグラフの両者に提供される。
【００８７】
メンタルミルライブラリは、特別なプラットフォームのためのシェイダーを、フェノメノンシェイダーグラフまたは、モノリシックなMetaSLシェイダーからの要求に応じてダイナミックに生成するためのアプリケーションプログラミングインタフェース（API）を提供する。または、メンタルミルは、目標のプラットフォームにより要求される形式でシェイダーを静的ファイルにエクスポートすることを可能にする。これにより、シェイダーを、メンタルミルライブラリを必要とすることなく使用することが可能になる。
【００８８】
図９は、本発明の１つの形態による、全体システム２００の図を示す。図９に示されるように、システム２００は、下記に記述される、多数のサブモジュールおよび他の構成要素をふくむ、メンタルミル処理モジュール２０２を含む。メンタルミル処理モジュール２０２は、フェノメノン２０４およびMetaSLコード２０６の形式の入力を受け取る。メンタルミル処理モジュール２０２は、出力として、Cg 208、HLSL 210、GLSL 212、Cell SPU 214、C++ 216などを含む、選択されたシェイダー言語のソースコードを提供する。更に、メンタルミル２０２は、出力として、まだ開発されていない将来の言語２１８のソースコードを提供するようにも適合可能である。
【００８９】
プラットフォーム独立性の構成要素は、特別なレンダリングアルゴリズムからは隔離されている。例えば、ハードウェアレンダリングは、ソフトウェアレンダリングに比べて、異なるレンダリングアルゴリズムをしばしば採用する。ハードウェアレンダリングは、複雑な幾何学図形のレンダリングは非常に速いが、大域照明のような進歩した照明アルゴリズムを直接にはサポートしない。
【００９０】
MetaSLは、３つのサブセットまたはレベルに分割されると考えられ、各レベルは、その表現の豊かさの量と、異なるレンダリングアルゴリズムに対する適合性の両者において異なる。図１０は、サブセットとしてのMetaSL２２０のレベルを示す図を示している。点線の楕円形の領域２２４は、基準のサブセットとしてのC++を示している。
レベル１（２２１）−これは、最も一般的なMetaSLのサブセットである。このサブセット内で書かれたシェイダーは、容易に幅広い多様なプラットフォームの目標になり得る。シェイダーの多くのタイプが、このサブセット内でその全体を書くことができる。
【００９１】
レベル２（２２２）−レベル１（２２１）のスーパーセットであり、レベル２（２２２）は、レイトレーシングおよび大域照明のようなソフトウェアレンダリングアルゴリズムでのみ典型的に利用可能な特徴を追加する。レベル１（２２１）と同様に、レベル２（２２２）は、依然として相対的に簡略化された言語であり、レベル２（２２２）内で書かれたシェイダーは、ハードウェアプラットフォーム上で部分的にレンダリングすることが可能である。これにより、レンダリングの一部が、ハードウェアおよびソフトウェアの一部で行なわれるレンダリングアルゴリズムの混合を達成することが可能になる。
【００９２】
レベル３（２２３）−これは、レベル１（２２１）とレベル２（２２２）の両者のスーパーセットである。更に、レベル３（２２３）はまた、一般的なC++言語のスーパーセットでもある。レベル３（２２３）シェイダーは、ソフトウェアでしか実行できないが、レベル３（２２３）は、それがC++のすべての特徴を含むので、３つのレベルで最も表現が豊かである。しかし、C++の複雑さを必要とするシェイダーはほとんどなく、レベル１（２２１）が可能な目標の最小な、一般的なセットを有することを考えると、ほとんどのシェイダーは、レベル１（２２１）とレベル２（２２２）のみを使用して書かれると思われる。
【００９３】
レベル１（２２１）は、MetaSLの最も小さなサブセットと見なされるが、それはまた、それがサポートするプラットフォームのタイプにおいて最も一般的でもある。レベル３（２２３）は、最大のスーパーセットであり、C++のすべてさえも含み、それを非常に強力かつ表現豊かにしている。それを必要とするアプリケーションに対しては、レベル３（２２３）は、複雑なシェイダーを、C++の特徴のすべてを使用して書くことを可能にする。レベル２２３を使用することによる代償は、それをサポートする目標が限られているということにある。図１１は、MetaSLのレベルと、そのハードウェアおよびソフトウェアレンダリングへの適用性を示す棒グラフ２３０である。
【００９４】
レベル１と２のシェイダー（２２１、２２２）は、高いレベルの互換性を有し、違いは、レベル２のシェイダー（２２２）が、GPU上では起動できない高度なアルゴリズムを利用するということのみである。しかし、MetaSLコンパイラは、レベル１（２２１）にサポートされていない機能を除去し、それを無操作（no-ops）で置き換えることで、それがあたかもレベル１のシェイダー（２２１）（そして、目標ハードウェアプラットフォーム）のようにレベル２のシェイダー（２２２）を使用することができる。MetaSLコンパイラのこの特徴、および所与のシェイダーのレベルをも検出する機能により、MetaSLコンパイラが、シェイダーのハードウェアとソフトウェアのバージョンを同時に生成（または、それが必要なときは、ソフトウェアのシェイダーのみを生成）することが可能になる。ハードウェアのシェイダーは、ハードウェアレンダリングを介して、ユーザーへの直接のフィードバックのために使用することができる。そして、ソフトウェアレンダリングは、より精度の高いイメージを付け加えることができる。
【００９５】
メンタルミルの別の有効な特徴は、シェイダーの目的を容易に変更できる機能である。この重要な例の１つは、ビデオゲームおよび特作映画の統合に見られる。成功した映画からその内容を使用する許可を得て開発されたビデオゲームを見ることはあまりない。ますます特作映画は、成功したビデオゲームに基づいて製作されもする。ビデオゲームと、それに基づく映画に対して、同じ芸術的資産を使用することは意味のあることであるが、過去においては、映画は、ビデオゲームとはまったく異なるレンダリングアルゴリズムを使用してレンダリングされるので、これはシェイダーにとっては課題であった。メンタルミルは、同じMetaSLシェイダーを、両方の状況で使用できるようにすることで、この障害を克服する。
【００９６】
シェイダーを構築するためのシェイダーグラフモデルもまた、シェイダーの再使用を促進する。シェイダーグラフは、本質的に、構成要素化される方法において、シェイダーの構築を促進する。MetaSLシェイダーにより実装された単一のメタノードは、多くの異なるシェイダーにおいて、異なる方法で使用できる。実際、グラフのサブツリーの全体は、フェノメノンにパッケージ化することができ、単一ノードとして再使用できる。
【００９７】
メンタルミルのグラフィカルユーザーインタフェースは、必ずしもプログラミングを含まないシェイダーの構築方法を提供する。従って、コードを書くことに心地良さを感じないアーティストまたは他の人間は、ここで、自分自身でシェイダーを作成できる能力を有することになる。過去においては、シェイダーを作成するためにはプログラマに頼る必要があり、それは、プログラマとアーティストの間で多くの繰返しを含む可能性のある緩慢なプロセスであった。アーティストに、シェイダー作成プロセスに対する制御を与えることにより、プログラマを他のタスクに解放できるだけでなく、アーティストがより自由に、カスタムシェイダーを介して可能になる可能性を探索できるようになる。
【００９８】
メンタルミルのユーザーインタフェースもまた、プログラマと技術ディレクタに対して開発環境を提供する。プログラマは、MetaSLで書かれたカスタムメタノードを作成でき、そしてアーティストは、これらのノードを使用して、新しいシェイダーを作成できる。技術ディレクタは、機能の単位を実現する複雑なカスタムシェイダーグラフを作成でき、それらのグラフをフェノメノンにパッケージ化することができる。柔軟性および複雑さのこれらの異なるレベルは、ユーザーに、シェイダー作成プロセスに対する幅広い制御を与え、ユーザーを、幅広い技術的および芸術的専門知識に巻き込むことができる。
【００９９】
シェイダーの作成の重要な面は、欠陥を分析し、その原因を判定し、解決法を見つける機能である。つまり、シェイダークリエータは、そのシェイダーのデバッグを行なうことができなければならない。シェイダーにおける欠陥を見つけて解決することは、シェイダーが、グラフを形成するためにメタノードを付加することにより、またはMetaSLを書くことにより、またはその両者により作成されたか、に無関係に必要なことである。メンタルミルは、ユーザーに、高いレベルの視覚的技術を使用してそのシェイダーのデバッグを行なえる機能を提供する。これにより、シェイダーのクリエータは、そのシェイダーの状態を視覚的に分析し、問題の原因を迅速に隔離することが可能になる。プロトタイプのアプリケーションが、このシェイダーデバッグシステムのコンセプトの証明として作成された。
【０１００】
オフラインのまたはリアルタイムの対話的レンダリングのような、シェイダーのほとんどすべてのアプリケーションは、シェイダーが可能な限りの高いレベルの性能を達成することを要求する。典型的に、シェイダーは、レンダラーの最も性能が重要なセクションで起動され、そのため、全体の性能に重要なインパクトを有する。このため、シェイダーの作成者が、細かい点において、そのシェイダーの性能を分析して、シェイダーの計算上、非常に高価な部分を隔離できることが重要である。
【０１０１】
メンタルミルは、プロファイリング（profiling）と称される分析法を、直感的なグラフによる表現により提供する。これにより、メンタルミルのユーザーは、シェイダーの部分の相対的な性能を示す視覚的フィードバックを受け取ることが可能になる。このプロファイリング情報は、グラフまたはフェノメノンの一部であるノードに対するノードレベルと、メタノードに含まれるMetaSLコードに対するステートメントレベルの両者において提供される。
【０１０２】
シェイダーの性能タイミングは、そのシェイダーを駆動する特別な入力値に依存することができる。例えば、シェイダーは、ループを介する繰返し数が、特別な入力パラメータ値の関数であるループを含むことができる。メンタルミルのグラフィカルプロファイラ（profiler）により、シェイダーの性能が、ノードが常駐するシェイダーのグラフの状況において分析できるようになり、性能の結果を、その状況の中で、ノードを駆動する特別な入力値に対し相対的とすることができる。
【０１０３】
任意の特別な詳細度における性能情報は、ノード、つまり全体のシェイダーの全体性能コストに対して、または、複数のシェイダーによるシーン全体のレンダリングのコストに対して正規化される。例えば、メタノードにおけるMetaSLのステートメントの実行時間は、そのメタノードの合計実行時間、またはメタノードがグラフのメンバーの場合は、シェイダー全体の合計実行時間の百分率で表現できる。
【０１０４】
性能結果のグラフによる表現は、複数の視覚化技術を使用して提供される。例えば、１つの技術は、正規化された性能コストを、百分率をカラー勾配にマッピングすることにより提示することである。
図１２は、本発明のこの形態を示すスクリーンショット２３０を示している。MetaSLコードリスト２３２が、スクリーン２３０の中央に現れている。カラーバー２３４は、相対的な性能を示す各ステートメント２３２の左に現れている。最初の１０パーセントの点は、青の勾配にマップされ、残りの９０パーセントの点は、赤の勾配にマップされる。このような非線形マッピングを使用すると、ユーザーの注意を、そのMetaSLコードにおける「ホットスポット」に集中させることができる。更に、ユーザーは、勾配からカラーを選択するために使用される特別な数値にアクセスできる。ユーザーがマウスをカラーバー全体上で掃引すると、ポップアップがステートメントの実行時間を、合計実行時間の百分率として表示する。
【０１０５】
シェイダーがアニメーションの一部の場合は、その性能特性は、シーンをレンダリングする全体コストが時間と共に変化するか、またはシェイダーそれ自身が時間の関数のために、時間と共に変化する。性能結果のグラフによる表現は、これらの変化を性能プロフィール（profile）に反映するために、アニメーションの進行と共に更新される。図１２のスクリーン２３０において、コードの各ステートメント２３２に隣接するカラーバー２３４は、アニメーションが再生されるに従って、測定された性能の変化を反映するために変化する。
【０１０６】
図１３は、別の視覚化技術を示す性能グラフ２４０を示している。グラフ２４０は、特別な入力パラメータの値の範囲に対する性能結果を表示している。この例において、シェイダーの照明ループの性能コストは、シーンにおける照明の数に対してグラフ化されている。この例において、性能コストにおけるジャンプは、シェイダーを、グラフィックハードウェアの制約条件を満たすために、パスに分解しなければならない点を示している。
【０１０７】
メンタルミルはまた、性能結果を表形式で表示できる。図１４は表２５０を示し、フェノメノンの各ノードの性能タイミングが、シェイダー全体の全体の性能コストに関して表示されている。
メンタルミルの他の特徴のような、メンタルミルによるグラフィカルプロファイリング技術は、プラットフォームに依存しない。これは、性能タイミングが、任意のサポートされている目標プラットフォームに対して生成できることを意味している。新しいプラットフォームが登場するにつれて、メンタルミルコンパイラへの新しいバックエンドプラグインが提供され、これらの新しいプラットフォームは、同じようにプロファイルできる。しかし、いかなる特別なタイミングも、ある選択された目標プラットフォームに関して測定される。例えば、同じシェイダーを、ハードウェア対ソフトウェア上で、または異なるハードウェアプラットフォーム上で実行するときにプロファイルできる。異なるプラットフォームは、個々の特性を有し、そのため、特別なシェイダーの性能プロファイルは、プラットフォームを比べると大変異なって見えることもある。シェイダーの作成者が、異なるプラットフォーム上でシェイダーを分析する能力は、すべてのターゲットプラットフォーム上での相当な性能で実行されるシェイダーを開発するためには重要である。
【０１０８】
図１５は、メンタルミルのライブラリ構成要素２６０の図を示す。メンタルミルのライブラリ構成要素２６０は、２つの主要なカテゴリに分割される。それはグラフィカルユーザーインタフェース（GUI）ライブラリ２７０とコンパイラライブラリ２８０である。GUIライブラリ２７０は、下記の構成要素を含む。それは、フェノメノングラフエディタ２７１、シェイダーパラメータエディタ２７２、レンダープレビューウィンドウ２７３、フェノメノンライブラリエクスプローラ２７４、メタノードライブラリエクスプローラ２７５、およびコードエディタとIDE２７６である。コンパイラライブラリ２８０は、下記の構成要素を含む。それは、MetaSL言語コンパイラ２８１と、フェノメノンフェノメノンシェイダーグラフ・コンパイラ２８２である。
【０１０９】
図１６は、コンパイラライブラリ２８０の、より詳細な図を示している。メンタルミル・コンパイラ・ライブラリ２８０は、MetaSLシェイダーを、特別なプラットフォーム、または同時に複数のプラットフォームを目標にしたシェイダーにコンパイルする機能を提供する。コンパイラライブラリ２８０はまた、フェノメノンを平坦なモノリシックシェイダーに実装するシェイダーグラフをコンパイルする機能も提供する。シェイダーグラフを単一のシェイダーに平坦化することにより、シェイダーからシェイダーへのコールのオーバーヘッドはほぼゼロにまで減少する。これにより、小さなシェイダーノードから構築されたグラフが、それほどのオーバーヘッドを負担することなく効率的に使用できるようになる。
【０１１０】
本発明の更なる形態によれば、メンタルイメージの次世代レンダラー（renderer）と、リアリティサーバー（Reality Server）（登録商標）は、MetaSLおよびモノリシックC++シェイダーに基づくことになる。この目的のため、それらは、MetaSLシェイダーおよびフェノメノンからの、実行可能なC++およびハードウェアシェイダーコードを生成するMetaSLコンパイラのコピーを含む。図１７は、本発明のこの形態によるレンダラー２９０の図を示している。
【０１１１】
図１７の構成において、MetaSLも、また他のシェイダーコードもエクスポートされていない。すべての言語のパスがこの図に示されているが、典型的なレンダラーは、底部に示されている５つのレンダリングユニットすべては使用しないことに注意されたい。典型的には、最も適切な２つ（１つのソフトウェアと１つのハードウェア）しか一度には使用されない。
【０１１２】
MetaSLコンパイラの拡張性により、複数の目標プラットフォームとシェイディング言語がサポートされる。新しい目標は、将来、それが登場したときにサポートできる。この拡張性は、コンパイラのバックエンドへのプラグインにより達成される。MetaSLコンパイラは、多くの処理を扱い、バックエンドプラグインに対し、高いレベルのシェイダーの表現を提供し、それをシェイダーコードの生成に使用できる。MetaSLコンパイラは、現在は、高いレベルの言語を目標にするが、GPUを直接目標にし、高いレベルの表現からマシンコードを生成する可能性もある。これにより、コードジェネレータが、この高いレベルの表現から直接作動し、固有のコンパイラを避けるということのみのために利用できる固有の最適化の利点を利用することが、特別なハードウェアにとって可能になるであろう。
【０１１３】
メンタルミルGUIライブラリは、洗練されたシェイダーグラフおよびフェノメノンの構築のための、直感的な、使い易いインタフェースを提供する。ライブラリは、構成要素化され、プラットフォームに依存しない方法で実現され、UI構成要素のいくつか、またはすべてをサードパーティアプリケーションに統合することが可能になる。
スタンドアロンのフェノメノンクリエータアプリケーションもまた提供され、それは、直接他のアプリケーションへの統合に利用できる同じGUIを利用する。
【０１１４】
ライブラリにより提供される主要なGUI構成要素は次の通りである。
・フェノメノングラフエディタ−グラフエディタは、シェイダーグラフを、入力をメタノードの出力に接続することにより構築できるようにする。
・シェイダーパラメータエディタ−パラメータエディタは、シェイダーノード入力のためのパラメータ値を設定するための直感的なユーザーインタフェースコントロールを提供する。
【０１１５】
・レンダープレビューウィンドウ−プレビューウィンドウは、シェイダーグラフを構築し、シェイダーパラメータを編集するときに、ユーザーへの対話的フィードバックを提供する。
・フェノメノンライブラリエクスプローラ−ユーザーが前もって構築されたフェノメノンのライブラリを閲覧することを可能にする。ユーザーは、自分自身のシェイダーグラフをライブラリに追加し、その内容を構成することができる。
【０１１６】
・メタノードライブラリエクスプローラ−メタノードライブラリは、ユーザーが、シェイダーグラフを構築するために使用できる、メタノードのツールボックスを提供する。新しいメタノードは、MetaSLコードを書くことにより作成され、ライブラリに追加できる。
・コードエディタとIDE−コードエディタと統合開発環境（IDE）は、新しいメタノードとモノリシックMetaSLシェイダーが、GUIで直接書けるようにする。ユーザーがMetaSLコードを書くと、そのコードは自動的にコンパイルされて、その結果は、シェイダーのグラフおよびプレビューウィンドウで即座に見ることができる。対話的な、視覚に基づくデバッガにより、ユーザーがMetaSLコードを段階的に進むことが可能になり、変数の値を調べることができるようになる。メンタルミルのGUIを介して、ユーザーは、特別なピクセル位置において、変数の特別な数値を知ることができ、その変数が取りえる複数の値を、オブジェクトの表面上で調べることができる。
【０１１７】
フェノメノングラフエディタは、ユーザーが、マウスでクリックしてドラッグすることにより、ノードを置いて、それを一緒にグラフを形成するために付加することにより、シェイダーとフェノメノンを構築することを可能にする。広範囲にわたるツールセットは、このタスクにおいてユーザーを支援し、複雑なシェイダーグラフを容易にナビゲートし、維持することを可能にする。図１８は、グラフ・エディタ・ユーザー・インタフェース３００の図を示している。
【０１１８】
グラフノードは、詳細の種々のレベルで表現されており、ユーザーがその全体のグラフの大きな図を得るためにズームアウトし、任意の特別なノードの詳細のすべてを見るためにズームインすることが可能なる。
シェイダーグラフの部分は、閉じたときに単一のノードのように見えるフェノメノンに組み込むことができる。これにより、ユーザーが、サブグループを単一ノードにグループ化することにより、多くのノードの大きな複雑なグラフにより首尾よく対処できるようになる。フェノメノンは開くことができ、それにより、ユーザーはその内部グラフを編集できる。
【０１１９】
シェイダーグラフ内の各ノードは、グラフのその点におけるシェイダーの状態を示すプレビューウィンドウを有している。これは、シェイダーの作成のための視覚化デバッグ機構を提供する。ユーザーは、グラフのデータフローに従うことができ、各ノードにおいて、それまでの結果を見ることができる。一瞥して、ユーザーは、シェイダーの構築の視覚表現を見ることができる。
【０１２０】
図１９から図２２は、一連のスクリーンショット３１０、３２０、３３０、３４０、および３５０を示し、メンタルミルのフェノメノングラフエディタと、統合されたMetaSLグラフィカルデバッガを示している。
図２４は、シェイダーパラメータエディタ３６０の図を示している。パラメータエディタ３６０は、ユーザーが、シェイダーとフェノメノンパラメータのための特別な値を設定することを可能にする。新しいシェイダータイプを作成するときに、これは、ユーザーが、そのタイプの将来のインスタンスのためのデフォルトのパラメータ値を指定することを可能にする。
【０１２１】
パラメータビューの内部から付加することができ、ユーザーは、１つのノードから他のノードへ、このビュー内で取付けパスを辿ることができる。これは、ある状況においては有効な、シェイダーグラフの作成と編集のための代替の方法を提供する。
サイズ変更可能レンダープレビューウィンドウは、ユーザーが、シェイダーの結果を対話的に視覚化することを可能にする。このプレビューウィンドウは、レイトレーシングおよび大域照明のような、高度なレンダリングアルゴリズムを含む、高品質ソフトウェアレンダリング結果と共に、シェイダーのリアルタイムなハードウェア加速化プレビューを提供できる。
【０１２２】
フェノメノン／メタノード・ライブラリ・エクスプローラ・ビューは、ユーザーがフェノメノンとメタノードの集積体を閲覧および構成することを可能にする。図２５Ａは、サムネールビュー３７０を示し、図２５Ｂは、リストビュー３８０を示している。新しいノードを現在のグラフ中に、これらのライブラリの１つから作成するために、ユーザーは単に、ノードをドラッグし、グラフの中にドロップする。
【０１２３】
ライブラリは、組織化のために、格納およびカテゴリ化できる。ユーザーは、ライブラリをリストビュー、またはアイコンビューで見ることができ、各ノードの機能を示すサンプルの寄せ集めを見ることができる。
コードエディタは、ユーザーが、MetaSLコードを書くことにより新しいメタノードを制作することを可能にする。コードエディタは、メンタルミルGUIの残りに統合され、それにより、ユーザーは、シェイダーコードを編集し、ユーザーインタフェースの残りは、相互に更新して、その変更を反映する。
【０１２４】
図２６は、コードエディタとIDEビュー３９０を示している。コードエディタもまたメンタルミルコンパイラに統合される。ユーザーがシェイダーコードを編集すると、コンパイラから対話的なフィードバックを受け取る。コンパイラからのエラーまたは警告は、このビューにおいてユーザーに、そのエラーまたは警告の原因となるコードの部分を強調表示するオプションを含んで提示される。
【０１２５】
メンタルミルのMetaSLデバッガは、ユーザーに、該当するシェイダーノードのためのMetaSLコードを含むソースコードリストを提供する。そして、ユーザーは、シェイダーの命令を段階的に進むことができ、プログラムの実行中を通して変化するときの変数の値を調べることができる。しかし、ユーザーに単一の数値を単に提供する代わりに、デバッガは、同時に複数の値を、オブジェクトの表面上にマップされたカラーとして表示する。
【０１２６】
変数の値を、単一の数字ではなく、１つのイメージとして表現することは、いくつかの利点がある。第１に、ユーザーは、変数の値を駆動している関数の特性を即座に認識でき、間違って作動している領域を見つけることができる。例えば、表面を通しての、変数の変化率は、表面に亘って、カラーがどのように変化しているかを観察することにより、直感的な方法で見ることができる。ユーザーが、シェイダーを一度に１ピクセルデバッグするという従来の方法を使用していれば、これは、認識することは難しい。
【０１２７】
ユーザーはまた、視覚化デバッグパラダイムを使用して、望ましくない結果をもたらす入力条件を迅速に突き止めることができる。シェイダーのバグは、ある入力パラメータが特別な値を取ったときだけに現れ、そのような状況は、幾何学図形の表面の特別な部分でしか起きない。メンタルミルのデバッガは、ユーザーがマウスを使用して三次元空間をナビゲートして、問題の兆候である表面上の位置の周りの図を見つけて視界をそこに向けさせることを可能にする。
【０１２８】
従来のデバッグ技術は、ユーザーが１行ずつプログラムを進み、各ステートメントにおけるプログラムの状態を調べることを可能にする。典型的に、ユーザーは１行または２行以上ずつ先に（プログラムの実行の方向）段階的に進むことしかできないが、任意のステートメントにジャンプすることは一般的にはプログラムを再スタートさせることが必要である。
【０１２９】
メンタルミルのMetaSLデバッガは、ユーザーが任意の順番で、シェイダーコード内の任意のステートメントへのジャンプを可能にする。この特徴の特に素晴らしい面の１つは、コードステートメントが、関心対象の変数の値を修正するときである。シェイダーのライターは、このステートメントの前後に容易に進むことができ、ステートメントが実行される前および後で、変数の値を交換することができる。これにより、ユーザーが、変数の値についての任意の特別なステートメントの効果を分析することがより容易になる。
【０１３０】
変数の値を、オブジェクトの表面上にマップされたカラーとして表示することは、変数がカラータイプのときは良好に機能することは明白である。この方法もまた、スカラーおよびベクトル値（３つ以下の構成要素）に対して相当に機能するが、値は、正規なカラーを出すためには、０−１の範囲でマップしなければならない。メンタルミルのUIは、ユーザーが、それらの値をカラーにマップするために使用される、スカラーとベクトルの範囲を指定することを可能にする。または、メンタルミルは、任意の所与の視点に対して、その視点から見たときの、表面上の変数の最小および最大値を決定することにより、範囲を自動的に計算することができる。
【０１３１】
変数を、オブジェクトの表面上にマップされたカラーとして見ることに加えて、ユーザーは、メンタルミルにより提供される、他の視覚化技術を利用することができる。ベクトル値に対する１つのそのような技術は、ユーザーが、オブジェクトの表面上を、マウスを掃引することを可能にし、メンタルミルのデバッガは、表面上のその位置における変数により指定される方向を指し示す矢印を描く。デバッガはまた、マウスにより選択できる、またはユーザーがピクセル座標を提供することにより指定できるピクセル位置における変数に対する数値を表示する。この技術は、図２７Ａ−Ｃに示され、それは、一連のスクリーンイメージ４００、４１０、４２０であり、イメージの表面において、マウスの異なる位置に対応して表示されている。
【０１３２】
メンタルミルのシェイダーデバッガは、メンタルミルのプラットフォーム非依存性の別の利点を示す。デバッガは、ハードウェアまたはソフトウェアモードで作動でき、いかなる特別なレンダリングアルゴリズムまたはプラットフォームとは独立して作動する。シェイダーデバッガが、メンタルミルのフェノメノン作成環境にしっかりと統合されているという事実は、作成／テストサイクルを更に減少し、シェイダーの作成者が、プラットフォーム依存性から隔離されて、高いレベルで作業を続けることを可能にする。
【０１３３】
メンタルミルのGUIライブラリは、プラットフォーム非依存の方法で実現される。シェイダーグラフエディタの構成要素は、グラフィックAPIを使用して、複雑なシェイダーグラフを編集するときにスムーズな性能を保証する。グラフィック抽象層は、いかなる特別なAPIに対する依存性も回避する。例えば、あるアプリケーションは、OpenGLよりもDirectXを使用することを望み、それにより、アプリケーションもまたDirectXを使用するときの統合問題を簡素化する。
【０１３４】
GUIの残りもまた抽象層を使用して、いかなる特別なプラットフォームオペレーティングシステムのユーザーインタフェースライブラリへの依存性を回避する。図２８は、本発明のこの形態によるGUIライブラリアーキテクチャ４３０の図を示している。図２８は、これらの抽象層が、どのようにして、アプリケーションおよびメンタルミルのユーザーインタフェースを、プラットフォーム依存性から隔離するかを示している。
【０１３５】
メンタルミルのGUI構成要素をサードパーティのアプリケーションに統合するときに、構成要素のルック＆フィールを、ホストアプリケーションの標準により良く合わせるようにカスタマイズできる。これは、特別なカラーまたはフォントを使用して、純粋に表面的なカスタマイゼーションを含むことができ、または、ユーザーが相互作用することにより、構成要素の外観とその動作をカスタマイズすることを含むことができる。
【０１３６】
下記は、メンタルミルのGUIライブラリがカスタマイゼーションを可能にする方法である。
・フェノメノングラフ外観−メタノードおよび接続線のような、フェノメノングラフの構成要素は、プラグインコールバック機能を起動することで描かれる。デフォルトの描画機能が提供される。しかし、サードパーティもまた自分自身の機能を提供して、シェイダーグラフの外観をより良くそのアプリケーションに合わせるようにカスタマイズすることもできる。コールバック機能もまた、ノードの構成要素を異なる位置に配置できるので、マウス・ポイント・ヒット・テスティングを扱う。
【０１３７】
・キーボードショートカット−すべてのキーボードコマンドは、再配置可能である。
・マウス動作−マウスボタンのマッピングのようなマウス動作はカスタマイズ可能である。
・ツールバーアイテム−各ツールバーアイテムは省略または含めることができる。
・ビューウィンドウ−各ビューウィンドウは、他のウィンドウへ依存することなく、それ自身で作動できるように設計されている。これにより、サードパーティは、フェノメノングラフビューだけを、例えば、それ自身のアプリケーションに統合できる。各ビューウィンドウは、APIにより駆動でき、それによりサードパーティが、ビューウィンドウのいくつかを自分自身のユーザーインタフェースと置き換えることにより、ビューウィンドウの任意の組み合わせを含むことができるようになる。
【０１３８】
メンタルミルシェイディング言語−MetaSLは、簡単、直感的で、かつ、メンタルミルによりサポートされるプラットフォームの広い範囲に対して要求されるシェイダーの全体スペクトルを表現するためには十分な表現性を備えている。
MetaSL言語は、一般的に、プログラミング言語と共に、他の標準シェイディング言語に見られる概念を使用する。しかし、MetaSLは、効率的なシェイダープログラミング用に設計されている。他の言語に精通しているユーザーは、MetaSLを素早く習得できるであろうし、一方、プログラミング技術の専門知識がないユーザーは、その読み易さのために、MetaSLシェイダーの多くの部分を理解できると思われる。
【０１３９】
ここで、MetaSLの機能的な概観を述べる。
シェイダークラス−MetaSLシェイダークラス宣言は、シェイダーの外部とのインタフェースを記述する。シェイダー宣言は、他のメンバー変数と共に、入力および出力パラメータの指定を含む。
シェイダー宣言は、シェイダーのエントリポイント、mainと称されるメソッドの宣言を含む。更に、オプションのeventメソッドは、シェイダーがイベントの開始および終了に対応することを可能にする。
【０１４０】
シェイダークラスは、他のメンバー変数およびメソッドの宣言も含むことができる。他のメンバー変数は、シェイディング計算により使用されるデータを保持でき、シェイダーのeventメソッドから初期化できる。他のmemberメソッドは、シェイダーのmainメソッドまたはeventメソッドによりコールされる、helperメソッドとして機能できる。
下記は、例としてのシェイダー宣言である。
【０１４１】
shader Phong
{
input:
Color ambient;
Color diffuse;
Color specular;
Scalar shininess; 
output:
Color result; 
void main(); 
void event();
};
・MetaSLは、内蔵データタイプの幅広い範囲を提供する。
【０１４２】
・Scalar−浮動小数点値
・Bool−ブーリアン
・String−文字列
・Color−カラー
・Vector−長さが２、３、または４のベクトルが提供される。更に、ブーリアンおよび整数のベクトルもまたはサポートされる。
【０１４３】
・Matrix−N×Mのサイズのマトリックスがサポートされ、NおよびMは２、３、または４。
・Texture−１d、２d、３d、および立体マップテクスチャタイプが提供される。
・Shader−シェイダー・インスタンス・データ・タイプ
ベクトルおよびマトリックスと作用する数学関数および演算子の標準セットが提供される。数学的演算子は、マトリックスおよびベクトルを乗算、除算、加算、および減算するためにサポートされる。これにより、下記のようなコンパクトで読み易い表現が可能になる。
【０１４４】
Vector3 result = pt + v*mat;
スウィズリング（swizzling）と称される概念もサポートされる。これにより、ベクトルの成分が、成分を同時に再整列または複製する間に読み込み、または書き込みが可能になる。例えば、
vect.yz
vectのyおよびz成分から構築される２dベクトルの結果になる。
【０１４５】
vect.xxyy
vectのx成分が最初の２成分に割り当てられ、vectのy成分が最後の２成分に割り当てられた、４dベクトルの結果になる。
v1.yz=v2.xx
v2のx成分を、v1のyおよびz成分の両者に割り当てる。
【０１４６】
ベクトルタイプは、変換によりデータの損失がなければ、１つのタイプから別のタイプに暗黙的に変換される。Colorタイプは、主にコードの読み易さのために提供され、それ以外の場合は、Vector4と同義である。
MetaSLにより提供される内蔵タイプに加えて、カスタム構造タイプを定義できる。構造は、他の変数と共に、入力および出力パラメータの両者に対して使用できる。構造と内蔵タイプの両者は、配列として宣言できる。配列は、固定または動的サイズのいずれかを有することができる。配列要素は、括弧（[]）構文でアクセスされる。
【０１４７】
struct Texture_layer
{ 
Texture2d texture;
Scalar weight; 
};
Texture_layer tex_layers[4];
この例は、カスタムタイプの固定長配列として宣言された変数を有するカスタム構造タイプを示している。
【０１４８】
MetaSLは、シェイダーの実行の流れを制御する、よく知られたプログラミングコンストラクトをサポートする。具体的には、for; while; do, while: if, else; switch, caseがある。
シーン照明上での繰返し、およびその照明のまとめのタスクは、lightループおよびiteratorによりMetaSLで抽象化される。light iteratorのインスタンスが宣言され、foreachステートメントが各シーン照明上を繰り返す。ループ内では、light iterator変数が、各lightからの結果としての照明へのアクセスを提供する。
【０１４９】
Color diffuse_light(0,0,0,0);
Light_iterator light;
foreach (light){
diffuse_light += max(0, light.dot_nl) * light.color;
}
シェイダーのライターは、どの照明がシーンのどの部分に寄与するか、または所与の照明を何回サンプリングする必要があるかについて心配する必要はない。照明ループはそのプロセスを自動化する。
【０１５０】
シェイダーのmainメソッド内で、特別状態変数のセットが、暗黙的に宣言され、シェイダーコードが参照できるようになる。これらの変数は、シェイダーコールにつながる、インターセクション（intersection）についての情報と同様に、レンダラーの現在の状態の両者を記述する値を保持する。例えば、normalは、インターセクションの点における内挿された法線のことである。状態変数は、下記に詳細に記述される。
【０１５１】
MetaSL内のlightとilluminationを取り扱う２つのコンストラクト（construct）がある。その１つは、BRDF（双方向反射配布関数）シェイダータイプであり、それにより、表面の照明モデルを、高度に効率的な方法で抽象化およびレンダリングできるようになる。または、ライトイテレータ（light iterator）は、各light内でシーン照明とサンプル上を繰り返すためのより伝統的なメソッドを提供する。
【０１５２】
BRDFシェイダーアプローチは、いくつかの理由によりしばしばより好ましい。それは、別のフォトンシェイダーを作成する必要なく、効率的なサンプリングおよび大域照明を可能にする。一般的に単一のBRDFインプリメンテーション（implementation）は、異なるレンダリングアルゴリズムにより変更されないで使用できる。それは、シャドウレイ(shadow rays)をトレーシングするような、ある照明計算を実行する関数を、重要なレンダリング最適化を可能にする遅延した方法により容易にする。それはまた、分析および取得された照明モデルの統合した記述も提供する。
【０１５３】
MetaSLにおいて、BRDFは、ファースト・クラス・シェイダー・オブジェクトである。それらは、同じeventメソッドを通常シェイダーとして有する。しかし、mainメソッドの代わりに、いくつかの他のメソッドが、BRDFを実現するためには提供されなければならない。
図２９は、BRDFシェイダーを実装するために要求されるメソッドを一覧表示する表４４０を示している。
【０１５４】
これらのメソッドにおけるin_dirおよびout_dirベクトルは、局所座標システムにより指定される。この座標システムは、表面法線によりz軸として定義され、xおよびy軸として接線ベクトルにより定義される。
BRDFは、shaderキーワードの代わりに、brdfキーワードが使用されることを除いて、通常のシェイダーのように宣言される。また、BRDFは、出力変数を有しないという事実により通常のシェイダーとは異なる。BRDFそれ自身は、それ自身の出力である。下記は、Phong BRDFに対する実施例である。
【０１５５】
brdf Phong 
{
input:
Color diffuse; 
Color glossy;
Color specular; 
Scalar exponent;
Color eval_diffuse(
Vector3 in_dir,
Vector3 out_dir)
{ 
return in_dir.z * out_dir.z < 0.0?
diffuse: Color(0, 0, 0, 0);
}
Color eval_glossy(
Vector3 in_dir,
Vector3 out_dir)
{
Vector3 r =Vector3(-in_dir.x, -in_dir.y, in_dir.z);
return pow(saturate(dot(r, out_dir)), exponent) * glossy;
}
Color eval_specular(
Vector3 in_dir,
Int specular_component,
out Vector3 out_dir,
out Ray_type out_type)
{ 
out_dir = Vector3(-in_dir.x,-in_dir.y, in_dir.z);
out_type = RAY_REFLECT;
return specular; 
}
Int specular_components()
{
return 1;
}
};
表面シェイダーの組合わせと、直接および間接BRDFシェイダーの両者は、特別な表面に対するシェイディングを定義する。MetaSLは、表面シェイダーが、照明計算を実行するために使用できる２つの関数を供給する。それは、ある、またはすべての照明上をループして、与えられたBRDFを評価するdirect_lighting()と、大域照明から照明の寄与を計算するindirect_lighting()である。これらの２つの関数は、照明を、分離した拡散、光沢、および反射構成要素として計算し、その結果を、出力引数として、それらに渡された変数に格納する。
【０１５６】
void direct_lighting(
out Color diffuse,
out Color glossy,
out Color specular);
void indirect_lighting(
out Color diffuse,
out Color glossy,
out Color specular);
ほとんどの場合、出力パラメータとして照明関数に渡された変数は、ルート・サーフェス・シェイダー・ノードの実際の出力パラメータであってよい。言い換えると、照明関数へのコールはシェイダーの最終結果を生成する。これらの出力値への他の直接の依存性がない限り、レンダラーは、自由にその計算を遅らせることができ、それにより、重要な最適化が可能になる。
【０１５７】
別の可能性は、表面シェイダーの出力が、他のノードの入力に取り付けられるということである。これにより、照明関数の結果に、直接の依存性を課することになり、それは可能であるが、遅延された照明計算の可能性と、それと共にある潜在的な性能ゲインは除去される。
表面シェイダーの結果に依存性を課することを回避するために、表面シェイダーの出力によって実行されるはずであったほとんどの操作は、BRDFノードそれ自身に適用される。数学演算子の制限されたセットは、BRDFノードに適用できるが、これらは、通常は、最も普通の使用のケースを成し遂げるには十分である。これらの操作は、
・２つまたは３つ以上のBRDFを加える
・BRDFをスカラーまたはカラーで掛ける
・動的にBRDFをセットから選択する
である。
【０１５８】
BRDFを、スカラーまたはカラーで縮小／拡大した後に加える機能は、BRDFノードにより表現された複数の照明ノードを混合することを可能にする。スカラーまたはカラー因子は、一定である必要はなく、例えば、２つのBRDFを、フレネル（Fresnel）減衰（falloff）のテクスチャの関数として混合するために、他のシェイダーの出力により駆動することができる。図３０は、例としての構成４５０の図を示しており、２つのBRDFが混合される。
【０１５９】
図３０において、「Mix BRDF」ノードは、合成BRDFであり、その２つのBRDF入力を「amount」および「1-amount」それぞれで縮小／拡大することにより実現される。この例においては、「amount」パラメータは、２つのBRDFの混合を制御するテクスチャの出力に取り付けられる。Phong BRDFの鏡面反射は、フレネル減衰関数により減衰される。
材料フェノメノンは、それ自身はシェイダーグラフにより表現される表面シェイダーと共に、直接および間接BRDFシェイダーを収集する。表面シェイダーが照明関数を起動すると、材料フェノメノン内のBRDFシェイダーは、照明サンプル上を繰り返して、照明関数の結果を計算するために使用される。この場合、表面シェイダーの結果に対する依存性はないので、照明計算は、レンダラーにより最適時間まで遅延される。
【０１６０】
BRDFシェイダータイプは、Phongのような分析モデルにより表現されるBRDFの表現を、測定装置により生成されたデータにより表現される取得されたBRDFと統合する。direct_lighting()およびindirect_lighting()関数は、それらに与えられたBRDFの実現とは関係なく、このように、取得された、または分析BRDFと、同等に良好に作動する。
取得されたBRDFを表現する未処理データは、多数の異なる形式で提供でき、通常は疎であり、構造化されていない。典型的には、未処理データは、スタンドアロンユーティリティアプリケーションに与えられ、そこで前処理される。このアプリケーションは、データを規則的な格子に組織化し、データを分解し、および／またはデータをより実際的なサイズに圧縮することができる。データを浮動小数点テクスチャに格納することにより、測定されたBRDFは、ハードウェアシェイディングに使用できる。
【０１６１】
図３１は、取得されたBRDFによるシェイディングのためのパイプライン４６０を示す図である。スタンドアロンユーティリティアプリケーションは、未処理BRDFデータを処理して、構造化データをXMLファイルに格納し、随意的に、バイナリファイルまたはテクスチャを参照して、実際のデータを保持する。XMLファイルは、データフォーマットと、関連するモデル、または分解の記述を提供する。次に、このファイルおよび関連するデータは、レンダリング時にBRDFシェイダーによりロードでき、BRDFを定義するために使用される。XMLファイルは、ユーザーに要求されると、更なる処理のためにユーティリティアプリケーションにフィードバックできる。
【０１６２】
データを浮動少数点テクスチャに格納することにより、データに基づくBRDFが、ハードウェア内で作動することが可能になる。この場合、データを保持するテクスチャおよびデータモデルを記述する他のいかなるパラメータも、BRDFノードの明示されたパラメータとすることができる。
測定されたBRDFとのソフトウェアシェイディングに対しては、データをロードするための２つのオプションがある。最初の１つは、データをファイルから読み込む固有のC++関数を、配列に導入することである。次に、この固有の関数は、Level 2 MetaSL BRDFシェイダーによりコールできる。他のオプションは、BRDFシェイダー全体を、Level 3 MetaSLシェイダーとして導入することであり、それにより、シェイダーに、C++のすべての機能への完全なアクセスを与える。このシェイダーは、データファイルを直接読むことができるが、Level 2シェイダーの柔軟性を多少失うことになる。データが、配列のようなLevel 2互換表現にロードできる限り、データを固有のC++関数からロードする最初のオプションの方が好ましい。データがポインタ（kd−ツリーのような）を要求する構造により表現しなければならない場合は、ポインタの使用を必要とする実現の一部は、Level 3シェイダーであることが必要である。
【０１６３】
技術は、シェイダー実現の１つの変形例である。あるシェイダーが、単一の技術のみを必要としている場合があるが、複数の技術を導入することが所望される状況もある。言語は、シェイダー内に複数の技術を宣言する機構を提供する。
技術は、それがハードウェアまたはソフトウェア環境で異なるコードを実行することが所望される場合に使用できるが、同じシェイダーが、ハードウェアとソフトウェアの両者に使用できるということがよくある。技術の別の使用法は、同じシェイダーの交互のバージョンを異なる品質レベルで記述することである。
【０１６４】
技術はシェイダークラスにおいて宣言される。各技術は、mainメソッドおよびeventメソッドのそれ自身のバージョンを有しているが、パラメータと他のメンバー変数またはメソッドは、他の技術と共有している。
下記は、シェイダー内での技術宣言の例である。
Shader my_shader{
input:
Color c;
output:
Color result;
technique software{
void event(Event_type event);
void main();
}
technique hardware{
void event(Event_type event); 
void main();
}
};
言語は、マテリアルシェイダーが、その結果を、単一のカラー値の代わりに、一連の成分として表現することを可能にする。これにより、格納される成分が、後の合成のためにイメージバッファーを分離することを可能にする。個々のパスは、すべての成分のサブセットのレンダリングを行ない、それらを、以前にレンダリングされた残りの成分と組み合わせることもできる。
【０１６５】
マテリアルシェイダーは、その結果を、各成分に対して分離した出力を宣言することにより成分に分解する。出力変数の名前は、現在のレンダリングの層の名前を規定する。
shader Material_shader{
input:
...
output:
Color diffuse_lighting;
Color specular_lighting;
Color indirect_lighting;
}; 
この例は、拡散、反射、および間接照明に対する３つの成分を指定するマテリアルシェイダーを示している。
【０１６６】
１つのシーンに、その結果を異なる層に分解する複数のマテリアルシェイダーが存在するときは、層の合計数は大きくなり得る。ユーザーは、これらの層のそれぞれに分離したイメージバッファーを割り当てることを望まないであろう。このシーン定義ファイルにおける機構は、ユーザーが、層をイメージバッファーに組み合わせるための合成規則を指定することを可能にする。ユーザーは、いくつのイメージバッファーを作成するかを指定し、各バッファーに対して、ピクセルのレンダリングが行なわれるときに、そのバッファーに置くカラーを決定する式を指定できる。式は、次のような、層の値の関数であってよい。
【０１６７】
Imagel=indirect_lighting
Image2= diffuse_lighting + specular_lighting
この例において、以前の例におけるシェイダー結果構造からの３つの層は、２つのイメージバッファーへの経路が定められる。
シェイダーのユーザーがGUIでそれらと相互作用して、そのパラメータ値を設定するためには、アプリケーションは、シェイダーパラメータについてのある追加的情報と、シェイダーそれ自身を知る必要がある。MetaSLは、シェイダーパラメータ、技術、およびシェイダーそれ自身に、追加的メタデータにより注釈を付ける機能を提供する。
【０１６８】
シェイダーの注釈付けは、他の事項の中で、パラメータ範囲、デフォルト値、およびツールチップ説明を記述できる。カスタム注釈タイプを使用して、任意のデータをシェイダーに付加することもできる。
MetaSLは、内蔵関数の広範囲な集積体を含む。これらには、少し挙げると、数学、幾何学、およびテクスチャルックアップ関数などが含まれる。更に、ソフトウェアレンダリングプラットフォームによってのみサポートできる関数もまた含まれる。例としては、反射光線を空間の１点に投じる、または空間の１点における大域照明の量を計算する関数がある。
【０１６９】
Ｂ.メンタルミルＧＵＩ仕様
メンタルミル（商標）フェノメノン（商標）作成ツールにより、ユーザーは、プログラミングなしで対話的にシェイダーを構築できる。ユーザーは、主に、シェイダーグラフビューにおいて作業し、そこには、複雑な効果を構築するために、メタノード（商標）が他のシェイダーノードに取り付けられている。メタノードは、単純化されたシェイダーであり、より複雑なフェノメノン（商標）を構築するための構築ブロックを形成する。
【０１７０】
「フェノメノン」の定義は、「視覚効果」の概念を完全に把握するために、メンタルレイ（登録商標）レンダラーにより導入された。簡単に述べれば、フェノメノンはシェイダー、またはシェイダーツリー、または協働シェイダーツリー（DAG）のセットであってよく、幾何学的シェイダーを含み、その結果、定義の領域を有する単一のパラメータ化された機能、および、シーンにおける幾何学的オブジェクトにより与えられる境界条件と共に、レンダラーの起動時に作成される境界条件を含む、三次元空間における境界条件のセットである。
【０１７１】
フェノメノンは、1つまたは2つ以上のシェイダーまたはシェイダーDAG、およびレンダリングを制御する種々の「条件」オプションを含む構造体である。外見上は、フェノメノンは、まさに、入力パラメータおよび出力を伴うシェイダーのように見えるが、内部では、その機能はプログラミング言語では実現されず、フェノメノンインタフェースパラメータへの特別なアクセスを有するシェイダーDAGのセットとして実現される。補助的な目的のために、追加的なシェイダーまたはシェイダーDAGもまた含めることができる。フェノメノンは、シーンへの取り付けポイントとして機能する固有ルートノードに取り付けられる。内部構造は、外部のユーザーからは隠されているが、メンタルミルフェノメノン作成ツールによりアクセスできる。
【０１７２】
コードを書くことによりシェイダーを開発しようと所望するユーザーに対して、メンタルミルは、メンタルイメージシェイダー（mental images' shader）言語；MetaSL（商標）を使用して、メタノードを作成するための、統合開発環境（IDE）も提供する。ユーザーは、コード、またはフェノメノンシェイダーグラフの構成要素にする特別な機能を提供するメタノードを書くことにより完全なモノリシックシェイダーを開発できる。
【０１７３】
メンタルミルツールは、フェノメノンおよびメタノードに対する自動生成グラフィカルユーザーインタフェース（GUI）も提供する。このGUIにより、ユーザーはパラメータに対する値を選択し、その設定の結果を対話的にプレビューすることが可能になる。
シーンに付加される前に、フェノメノンをインスタンス化するためのパラメータ値が指定されなければならない。ユーザーが編集するフェノメノンには２つのタイプがある。それは、パラメータ値が指定されていないフェノメノン（自由値フェノメノンと称される）と、パラメータが固定、または部分的に固定されたフェノメノン（固定フェノメノンと称される）である。ユーザーがシェイダーグラフを作成することにより、またはMetaSLコードを書くことにより（またはその両者を組み合わせて）新しいフェノメノンを作成するときは、新しいタイプの、自由パラメータ値のフェノメノンを作成することになる。そしてユーザーは、この新しいフェノメノンのタイプに基づいて、固定パラメータ値を有するフェノメノンを作成できる。典型的には、特別なフェノメノンに基づいて、多数の固定値フェノメノンが存在することになる。ユーザーがフェノメノンを変更すると、それに基づくすべての固定フェノメノンは、その変化を継承する。固定フェノメノンへの変更は、その特別なフェノメノンのみに限られる。
【０１７４】
ユーザーが新しいフェノメノンタイプを作成することを選択すると、ユーザーにはそのシェイダーグラフを構築させておいて、新しい空のフェノメノンを作成することによりメンタルミルが開始する。ユーザーは、そのシェイダーへの公共インタフェースを形成するフェノメノンインタフェースパラメータを指定することもできる。更に、フェノメノンルーツと他のオプションの数を指定することもできる。
【０１７５】
ここで、メンタルミル・ユーザー・インタフェースおよびそれが提供する特徴を説明する。
メンタルミルアプリケーションUIは、各ビューが制御の異なるセットを含むいくつかの異なるビューから構成される。ビューパネルは、４つの可動スプリッタバーにより分離される。これにより、ユーザーがビューの相対的なサイズを調整できるようになる。
【０１７６】
図３２は、基本的な簡略化レイアウトを示すスクリーンショット４７０である。主要なビューパネルには名前が付けられているが、簡略化のために、これらのビューの内容は示していない。これらのビューパネルは、以下を含む。ツールボックス４７２、フェノメノングラフビュー４７４、コードエディタビュー４７６、ナビゲーションコントロール４７８、プレビュー４８０、およびパラメータビュー４８２である。
【０１７７】
フェノメノングラフビュー４７４により、ユーザーは、メタノードまたはフェノメノンノードを一緒に接続してグラフを形成することにより、新しいフェノメノンを作成できる。ノードの出力は、１つまたは２つ以上の入力に接続でき、それにより、接続されたノードは、それが接続されている入力パラメータに対して値を提供できる。
フェノメノングラフビュー領域４７４は、仮想的に無限の大きさであってよく、それにより任意の複雑なシェイダーグラフを保持できる。ユーザーは、この領域を、マウスを使用して、真中のマウスボタンを押すことによりパンニングし、右マウスボタンを押すことによりズーミングして（ボタンの割り付けは変更できる）ナビゲートできる。下記の節で説明するナビゲーションコントロールは、フェノメノンビューをコントロールするための多くの方法を提供する。
【０１７８】
ユーザーは、下記に示すように、ノードをツールボックス４７２からフェノメノングラフビュー４７４へドラッグすることによりノードを作成できる。グラフビュー４７４において一度、ノードはユーザーにより位置決めできる。レイアウトコマンドは、グラフノードの自動レイアウトも行なう。
図３３は、グラフノード４９０を示している。グラフノード４９０（フェノメノンノードまたはメタノード）はいくつかの要素を含んでいる。
【０１７９】
・プレビュー−ノードのプレビューウィンドウ部により、ユーザーは、表面上にレンダリングされたシェイダーノードの結果を見ることができる。球は、デフォルトの表面であるが、他の幾何学的図形も指定できる。すべてのノードは、シェイダーグラフの内部ノードであっても、潜在的にプレビューウィンドウを有することができる。プレビューは、個々のノードを完全なシェイダーと考え、そのシェイダーを使用してサンプルの幾何学的図形をレンダリングすることにより生成される。これにより、ユーザーが、グラフのそれぞれの段階でのシェイダーの結果を見ることができるので、シェイダーグラフを通してデータフローを視覚化できる。ノードのプレビュー部は、ノードのサイズを小さくするために閉じることもできる。
【０１８０】
・出力−各ノードは、少なくとも１つの出力を有するが、２つ以上の出力を有するノードもある。ユーザーは、出力位置上でクリックおよびドラッグして、出力を別のノードの入力に付加する。出力は２点以上の入力に付加できる。
・入力−各ノードは、入力パラメータを有しないか、１つ以上の入力パラメータを有する。入力は、別のノードの出力に付加でき、それによりそのシェイダーが、入力パラメータの値をコントロールすることができる。または、値はユーザーにより設定できる。入力は、１つの出力にのみ付加できる。ユーザーがマウスを、入力の上に少しの間保持すると、そのパラメータの簡単な説明を示すツールチップが表示される。ツールチップのテキストは、シェイダーに関連する属性により提供される。
【０１８１】
入力または出力パラメータのいくつかは、サブパラメータの構造体であってよい。この場合、ノードの入力パラメータは、構造体を開くまたは閉じるための「＋」またはボタンを有する。構造体の個々の要素に取り付けることができる。図３４は、サブパラメータを含むグラフノード５００を示している。
フェノメノンノードそれ自身は、シェイダーグラフを含む。トップレベルにおいては、ユーザーは、それぞれが新しいシェイダーを表現している、複数のフェノメノンノードを作成できる。コマンドはユーザーをフェノメノンノードに入り込ませ、フェノメノンノードはフェノメノングラフビューをフェノメノン内部に存在するグラフと入れ替える。または、フェノメノンは、それが常駐しているグラフにおいて直接開くこともできる。これにより、ユーザーは、フェノメノンそれ自身の内容と共に、フェノメノンの外側のノード、およびおそらくそれに接続されているノードを見ることができる。
【０１８２】
フェノメノンの内部において、ユーザーは、フェノメノン出力および補助ルートと共に、フェノメノンインタフェースパラメータへのアクセスを有する。フェノメノンへの入力（インタフェースパラメータ）は、フェノメノンの左上隅に現れ、フェノメノンの内部から見たとき、出力のように動作する。フェノメノンの出力は、右上隅に現れ、内部から見たときに入力ように動作する。
【０１８３】
フェノメノンの内部のシェイダーグラフは、他のフェノメノンノードを含むこともできる。ユーザーは、同じ方法でこれらのフェノメノンノードに入り込むことができ、フェノメノンが入れ子にされる限り処理を繰り返すことができる。
図３５は、フェノメノンの内部のときのサンプルグラフビュー５１０を示している。全体のグラフがこの図に示されているが、ユーザーが極端にズームアウトしないかぎり、全体のグラフが一度には見ることができないような、十分に大きなグラフとなることは普通である。この例においては、１つのノード以外のすべてのノードは、そのプレビューウィンドウを閉じていることに注意されたい。
【０１８４】
フェノメノンをグラフの中で開くとき、グラフビュー全体を覆うように最大化することも、適切な大きさで開くことも可能である。適切な大きさで開くと、ユーザーは、図３６のグラフビュー５２０に示されているように、内部のグラフと共に、フェノメノンの外部のグラフも見ることができる。
フェノメノンは、他のフェノメノンの内部に入れ子にすることができるので、フェノメノンを、他の開いたフェノメノンの内部で開き、新しい入れ子のフェノメノンを作成することが可能である。図３７は、そのような場合を示すグラフビュー５３０を示している。
【０１８５】
ユーザーがノードをトップレベルにドラッグすると、ユーザーは、ドラッグすることを選択したフェノメノンのタイプに基づいて、固定値を有するフェノメノンを作成することになる。トップレベルの固定フェノメノンノードは、編集可能なパラメータを有するが、他のノードへ取り付けられない。固定フェノメノンとは、先に言及したように、それが作成され、そのフェノメノンへのいかなる変更も継承するフェノメノンのことである。固定フェノメノンを自由値フェノメノンへ変換するコマンドも利用でき、それにより、ユーザーは、他のインスタンスに影響を与えることなくフェノメノンを修正できる。
【０１８６】
ユーザーがノードをフェノメノン内にドラッグすると、固定値フェノメノンまたはメタノードが、作成されたノードのタイプにより、フェノメノンの内部に作成される。フェノメノン内部のノードは、他のノードまたはフェノメノンインタフェースパラメータと有線により接続できる。ユーザーがフェノメノン内にドラッグしたノードが、それ自身フェノメノンノードの場合は、固定値のフェノメノンが作成される。そのパラメータ値を設定、または他のノードに付加することができるが、それはもとのフェノメノンである固定フェノメノンなので、ユーザーはフェノメノンノードの内部に入り込んで、それを変更することはできない。また、もとのフェノメノンに対するいかなる変更もノードに影響する。ユーザーがフェノメノンを変更したいと所望する場合は、ノードを、ユーザーが入り込んで修正できる新しい自由値フェノメノンに変換するコマンドが利用できる。
【０１８７】
シェイダー付加を作成するために、ユーザーは１つのノードの出力領域上でクリックおよびドラッグして、マウスカーソルを、別のノードの入力上に置く。ユーザーがマウスを離すと、シェイダー接続を表現する接続線が描かれる。接続が有効なものでなければ、付加処理の間に、可能な入力の上にマウスを置くと、カーソルはこれをユーザーに示す。
タイプチェッキングシステムは、シェイダーが、その出力タイプに整合している入力にだけ付加されることを保証する。ある場合には、変換を処理するアダプタシェイダーが存在すれば、異なるタイプの２つのパラメータの付加を行なうことができる。例えば、スカラー値を、アダプタシェイダーを使用して、カラー入力に付加できる。アダプタシェイダーは、スカラーを灰色に変換でき、または、ユーザーにより選択された設定により、他の変換を行なうことができる。アダプタシェイダーは、それが利用できるときは、自動的に挿入される。ユーザーがアダプタを必要とするパラメータを付加すると、アダプタは、ユーザーが付加を完成するときに自動的に挿入される。更に、メンタルミルは、付加を行なうときに、ユーザーがグラフ内で不注意にサイクルを作成しないことを保証する。
【０１８８】
図３８は、カラー出力をスカラー入力に付加した結果を示すビュー５４０を示している。「カラーからスカラー」アダプタシェイダーノードがその間に挿入され、変換を行なう。アダプタノードの変換タイプパラメータにより、ユーザーはカラーがスカラーに変換される方法を選択できる。このパラメータに対するいくつかのオプションは次の通りである。
【０１８９】
・平均（average）−赤、緑、および青成分の平均を取る。
・NTSC重み付け輝度（NTSC weighted luminance）−赤、緑、および青の重み付け平均を取る。
・セレクト成分（select component）−赤、緑、青、またはアルファ成分のカラーの１つのみを取る。
【０１９０】
ノードと接続線の両者は選択および削除できる。ノードを削除するときは、そのノードへのすべての接続もまたは削除される。接続を削除するときは、接続それ自身のみが削除される。
シェイダーグラフがより複雑になると、ユーザーは、グラフの部分をフェノメノンノードに詰めることにより、グラフを構成することができる。現在選択されているサブグラフを取り、それをフェノメノンノードに変換するコマンドが利用できる。結果は、未選択ノードへ付加された選択されたノードの各入力に対するインタフェースパラメータを有する新しいフェノメノンである。このフェノメノンは、その出力が未選択ノードに付加された各選択ノードに対する出力を有する。新しいフェノメノンは、フェノメノン内で移動された古いサブグラフに替わって付加される。その結果は、シェイダーグラフの動作には変更がないが、グラフは、いくつかのノードが単一のノードにより置き換えられたので簡略化されて見える。フェノメノンが複雑な動作を単一ノードにカプセル化する機能は、メンタルミルの重要かつ強力な特徴である。
【０１９１】
図３９はビュー５５０を示し、そこにおいて、シェイダー２，３および４は、新しいフェノメノンノードに詰められている。外部のノードへの接続は維持され、グラフによりもたらされる結果は変更されていない。しかし、グラフは、わずかに整理されている。フェノメノンは入れ子にすることができるので、サブグラフの、フェノメノンへの、このタイプのグループ化が、任意の深さのレベルで起き得る。
【０１９２】
プレビューウィンドウは、現在選択されているフェノメノンのサンプルレンダリングを表示している。イメージは、フェノメノンノードの前のウィンドウに示されたイメージと同じであるが、より詳細を示すために、大きくすることができる。
プレビューは、常に、最上位のフェノメノンノードの結果を示す。いったん、ユーザーがフェノメノンに入ると、プレビューは、どのノードが選択されたかに拘わらず、そのフェノメノンの結果を示す。これにより、ユーザーは、まだ最終結果をプレビューしている間に、フェノメノン内の、シェイダーのグラフ上で作業できるようになる。
【０１９３】
ナビゲーションウィンドウは、ユーザーがフェノメノングラフをナビゲートできるようにするコントロールを提供する。ボタンにより、ユーザーは、フェノメノンのグラフ内のグラフの選択された部分に合わせるために、または、グラフ全体を見られるように合わせるためにズーミングできる。
「鳥瞰」コントロールは、フェノメノングラフビューに示されたグラフの部分を示す長方形により、シェイダーグラフの全体の小さな表現を示す。このコントロールの上でユーザーがクリックおよびドラッグして、長方形を、ユーザーが見たいと所望するグラフの部分に位置決めすることができる。また、「ズームイン」および「ズームアウト」ボタン、およびスライダがあり、それによりユーザーはビュー長方形のサイズをコントロールできる。ユーザーがズームレベルを変更するにつれて、長方形はより大きくまたは小さくなる。等角のビューもまた考慮されている。
【０１９４】
図４０は、サンプルシェイダーグラフをビューしている鳥瞰ビューコントロールを示すビゅー５６０である。暗い灰色の長方形５６２は、フェノメノングラフビューにおいて見ることができる領域を示している。
ユーザーがズームインおよびズームアウトすると、グラフビューにおけるシェイダーノードは、より大きくまたは小さくなる。ユーザーがよりズームアウトして、ノードがより小さくなるにつれ、ノードのある要素は、消えてノードを簡素化する。図４１Ａ−Ｄは、一連のビュー５７０、５７２、５７４、および５７６を示しており、詳細のノードレベルの進行を示している。
【０１９５】
入力または出力が崩壊しても、ユーザーは依然として付加を行なうことができる。付加をノードへドラッグすると、ポップアップリストにより、ユーザーはマウスを離すことにより、実際の入力を選択できる。
フェノメノングラフの節で記述したように、ユーザーはフェノメノンのノードに入り込むことができ、それにより、グラフビューが、入力されたフェノメノンのグラフと置き換えられる。このプロセスは、フェノメノンが他のフェノメノンの中に入れ子となる限り続けることができる。ナビゲーションウィンドウは、後退および前進ボタンを提供し、それにより、ユーザーは、入れ子のフェノメノンをナビゲートしてきた経路を逆に辿ることを可能にする。
【０１９６】
ツールボックスウィンドウは、シェイダーグラフがそこから構築される構築ブロックを作成するシェイダーノードを含む。ユーザーはクリックして、ノードをツールボックスからフェノメノングラフビューにドラッグし、ノードをシェイダーグラフに追加することができる。
ノードは、ツールボックス内で、アイコンおよび名前として現れる。典型的には、アイコンは、シェイダーを使用してレンダリングされた球であるが、他のアイコンが使用される場合もある。ノードのリストは、アイコンなしのぎっしり詰まったリストにおいても見ることができ、それにより、より多くのノードをビューに合わせることが可能になる。あるノードはフェノメノンノード、つまり、シェイダーグラフにより定義されたノードであってもよく、そして、他のノードは、メタノード、つまり、MetaSLコードにより定義されたノードであってもよい。これは、ノードの両者のタイプが互換可能に使用できるので、ユーザーにとって重要でないことがしばしばある。フェノメノンノードは、メタノードとは異なるようにカラーを付けるか、または別の方法で視覚的に区別できるようにカラーを付け、それにより、ユーザーはその２つを区別できるようになる。フェノメノンノードは、そのシェイダーグラフを編集することにより、グラフとして編集できるが、メタノードは、そのMetaSLソースコードを変更することによってのみ編集できる。
【０１９７】
ノードはカテゴリによりソートされ、ユーザーは、単一のカテゴリまたはすべてのカテゴリを、カテゴリのドロップダウンリストから選択することにより、見るように選択できる。ユーザーが、そのカテゴリを構成できようにする、ダイアログをもたらすコマンドもある。このダイアログにおいて、ユーザーは、カテゴリを作成または削除し、カテゴリをそれぞれのノードタイプに割り付けるようにコントロールすることができる。
【０１９８】
フェノメノンまたは、メタノードに加えて、ツールボックスも「動作（action）」を含む。動作とは、完全なシェイダーグラフの断片であり、ユーザーは、新しいシェイダーグラフを構築するときに使用できる。シェイダーノードおよび付加のパターンが異なるシェイダーに現れるのは、普通のことである。ユーザーは、シェイダーグラフの部分を選択でき、それを使用して、新しい動作を作成する。将来、ユーザーが同じ構成のノードを作成したいと所望するときは、ユーザーは単に動作をツールボックスから、シェイダーグラフにドラッグして、それらのノードを作成することが出来る。
【０１９９】
図４２Ａ−Ｂは、ビュー５８０と５８２であり、２つの異なるビューモードのツールボックスを示している。図４２Ａのビュー５８０は、サムネールビューモードを示し、図３８Ｂのビュー５８２は、リストビューモードを示している。
ツールボックスは、指定されたシェイダー記述ファイルで定義されたノードがぎっしり詰まっている。ユーザーは、１つまたは２つ以上のシェイダー記述ファイルを選択して、ツールボックスを介して、アクセスできるシェイダーライブラリとして使用できる。このライブラリにノードタイプを追加する、およびノードを除去するコマンドがある。メンタルミルツールは、メタノードの初期ライブラリもまた提供する。
【０２００】
図４３は、パラメータビューにおけるいくつかのコントロールを例示する部分的スクリーンショット５９０を示している。パラメータビューは、選択されたノードのパラメータを編集できるコントロールを表示している。これらのコントロールには、いくつか挙げると、スライダ、カラーピッカー、チェックボックス、ドロップダウンリスト、テキスト編集フィールド、およびファイルピッカーがある。
【０２０１】
自由値フェノメノンインタフェースパラメータを編集するときは、編集されているのはデフォルト値である。固定値フェノメノンは、それらのパラメータ値を上書きする。
シェイダー付加が可能な場合は、ボタン列が存在し、それにより、ユーザーは、パラメータビューの内部から付加ソースを取り出すことができる。現在の段階では、シェイダー付加は、トップレベルのフェノメノンを編集するときにはできないということに注意されたい。このボタンにより、ポップアップリストが現れ、それにより、ユーザーは、現在のグラフの中で利用できる他のノードから、新しいノードを取り出しまたは選択できる。「無し（none）」オプションは、付加を除去するために設けられている。付加が行なわれると、パラメータに対する通常のコントロールは、付加されたノードの名前を示すラベルと置換される。
【０２０２】
いくつかのパラメータは構造体であり、その場合は、コントロールは、構造体の各要素に対して作成される。更なる形態によれば、構造体は、「崩壊した（collapsed）」形状のUIにより表示され、それを開くための＋ボタンにより開かれる（入れ子構造体に対しては繰返し的に）。または、構造体は、常に、拡張された形状で表示することもできる。
UIにおいて、パラメータは、それらがフェノメノンまたはメタノードにおいて宣言された順に現れるが、ノードにおける属性もまた、その順序およびパラメータのグループ化をコントロールできる。自由値フェノメノンに対するデフォルトパラメータを編集するときに、パラメータをグループにまとめるコマンドが、パラメータの順序を変更するコマンドと共に利用できる。これらのコマンドは、ノードに関連する属性を編集する。
【０２０３】
ほとんどのパラメータは、それらに関連するハードなまたはソフトな制限を有している。ハードな制限は、パラメータが超えることができない範囲である。ソフトな制限は、一般的に有効なパラメータに対する範囲を指定することであるが、パラメータは厳密にはその範囲に制限されない。スライダのコントロールの範囲は、パラメータのソフトな制限に設定される。パラメータビューにおけるコマンドにより、ユーザーは、スライダの範囲を、それがハードな制限を越えない限り、ソフトな制限を越えて変更できるようになる。
【０２０４】
パラメータビューにおけるコントロールは、ユーザーがマウスを少しの間コントロール上に置くと、ツールチップを表示する。ツールチップに表示されるテキストは、シェイダーに関連する属性に起因するパラメータの簡単な説明である。同様に、すべてのコントロールの上部にあるボタンは、全体としてのシェイダー機能の、相対的に短い説明を表示する。この説明もまた、ノードに関連する属性に起因する。
【０２０５】
図４４は、本発明の本形態による、コードエディタビューを例示する部分的スクリーンショット６００を示している。コードエディタビューにより、シェイダーを、コードを書くことにより作成したいユーザーは、MetaSLを使用することでそれができるようになる。ユーザーは、必要であれば、コードを書くことによりモノリシックなシェイダーを作成できるが、ユーザーは、シェイダーのグラフの一部として使用される目的の、新しいメタノードを作成する可能性が高い。
【０２０６】
コマンドにより、ユーザーは新しいメタノードを作成できるようになる。その結果は、新しいタイプのメタノードを表現するグラフ（フェノメノン内ではない）のトップレベルにおけるメタノードである。ユーザーは、所望するのであればいつでも、フェノメノン内に、この新しいメタノードのインスタンスを作成できる。
ユーザーが新しいメタノードを作成するとき、メンタルミルは、最小コンパイル可能シェイダーに対して、初期スケルトンコードを作成する。そして、ユーザーは、そのシェイダーが提供することになっている特別な機能の実現に即座に集中できる。
【０２０７】
トップレベルのメタノード（フェノメノンの外側）が選択されると、対応するMetaSLコードが、ユーザーの編集のためにコードエディタビュー内に現れる。コードに変更を加えた後で、シェイダーをコンパイルするためのコマンドが利用できるようになる。ユーザーの固有プラットフォームに対するMetaSLコンパイラおよびC++コンパイラは、シェイダーをコンパイルするメンタルミルにより起動される。他のプラットフォームに対するクロスコンパイルもまた可能である。いかなるエラーもメンタルミルに戻され、その結果、メンタルミルはそれをユーザーに表示する。エラー上でクリックすると、ユーザーはエディタ内の対応する行に導かれる。シェイダーがコンパイルに成功すると、メタノードは更新し、入力パラメータおよび出力の現在のセットを示す。プレビューウィンドウもまた更新し、シェイダーの見かけに対して視覚的フィードバックを与える。MetaSLおよびC++コンパイラのこの統合により、メタノードおよびモノリシックシェイダーの開発がかなり簡素化される。
【０２０８】
パラメータビューもまた、選択されたトップレベルのメタノードに対するコントロールを表示し、それにより、ユーザーは、ノードの入力パラメータに対するデフォルト値の編集ができるようになる。これは、自由値フェノメノンのインタフェースパラメータの編集に類似している。
多くのユーザー、特に、技術に精通していないユーザーは、コードを書くことに関心がなく、構築フェノメノンのグラフ編集方法を使用することだけを望むと思われる。UIにより、コード編集ウィンドウが、余分なスペースがフェノメノンのグラフビューに対して放棄されて、閉じることが可能になる。
【０２０９】
メインメニューは、以下を含んで、多様な方法で構成できる。
・ファイル（File）−ファイルメニューは、下記の項目を含む。
１.  新しいフェノメノン（New Phenomenon）−このコマンドは、新しい自由値フェノメノンを作成するために使用される。いったん作成されると、固定パラメータ値を有する他のフェノメノンを、このフェノメノンに基づいて作成できる。
【０２１０】
２.  新しいメタノード（New Metanode）−新しいメタノードタイプを作成する。トップレベルのメタノードは、選択されると作成され、そのコードはコードエディタ内で編集可能である。
３.  ファイルを開く（Open File）−編集のために、シェイダー記述ファイルを開く。ファイルの内容がフェノメノングラフビュー内に現れる。これは、メタノードタイプと共に、自由または固定フェノメノンを含むことができる。ツールボックスの一部として指定されたファイルを開くことも編集することもできる。フェノメノンのシェイダーグラフを編集すると、そのフェノメノンに基づくすべての固定値フェノメノンが影響を受ける。従って、ツールボックスファイルを開くことは、フェノメノンまたはメタノードをツールボックスからフェノメノングラフビューにドラッグすることとはまったく異なる。ノードをツールボックスからドラッグすると、元のフェノメノンに影響を与えることなく修正ができる固定値フェノメノンが作成される。ツールボックスにより使用される記述ファイルを開くと、元のフェノメノンを修正できるようになる。
【０２１１】
４.  保存（Save）−現在開いているファイルを保存する。ファイルが以前に保存されたことがなければ、このコマンドは、ユーザーに新しいファイルに対して名前を付けることを要請する。
５.  名前を付けて保存（Save as）−現在開いているファイルを保存するが、ユーザーがファイルに対して新しい名前を付けることができる。
【０２１２】
６.  終了（Exit）−メンタルミルアプリケーションを終了する。
・編集（Edit）−編集メニューは下記の項目を含む。
１.  元に戻す（Undo）−最後の変更を元に戻す。これは、シェイダーグラフに対する変更、パラメータの値の変更、またはコードエディタビュー内で作成されたシェイダーコードへの変更が含まれる。メンタルミルツールは、仮想的に元に戻す無制限のレベルを有している。ユーザーは、嗜好により元に戻すレベルの最大数を設定できるが、このアプリケーションは、メモリをそれほど使用しないので、元に戻すレベルの数は、非常に高いままにしておくことができる。
【０２１３】
２.  繰返し（Redo）−前に元に戻された最後の変更を繰り返す。
３.  切取り（Cut）−選択された項目を削除するが、それをクリップボードにコピーする。選択される項目には、ノード（または複数のノード）またはコードエディタビューにおけるテキストが含まれる。キーボードフォーカスがコードビュー内にあると、テキストが切り取られ、そうでないときは、シェイダーグラフ選択が切り取られる。これは、コピー（copy）、貼付け（paste）、削除（delete）、すべて選択（select all）、何も選択しない（select none）、反転を選択（select invert）にも適用される。
【０２１４】
４.  コピー−選択された項目をクリップボードにコピーする。
５.  貼付け−クリップボードの内容をシェイダーグラフまたはコードビューに貼り付ける。
６.  削除−選択された項目を削除する。
７.  すべて選択−すべての項目を選択する。キーボードフォーカスに依存して、シェイダーノードまたはコードエディタ内のテキスト。
【０２１５】
８.  何も選択しない−選択をクリアする。
９.  反転を選択−選択されていないすべての項目を選択し、選択されたすべての選択を解除する。
１０.  オプション（Preferences）−ユーザーが、メンタルミルアプリケーションに対して好みの設定ができるようにするダイアログをもたらす。
【０２１６】
・ヘルプ−ヘルプメニューは、下記の項目を含む
１.  メンタルミルヘルプ−メンタルミルのヘルプファイルをもたらす。
２.  製品情報（About）−製品情報ボックスをもたらす。
ツールバーは、共通コマンドに簡単にアクセスできるツールボタンを含む。一般的には、ツールバーのコマンドは、シェイダーグラフの選択で作動する。ツールバーコマンドのいくつかは、メインメニューにあるコマンドの複製である。ツールバーの項目のリストには、下記のコマンドが含まれる。ファイルを開く、ファイルを保存（Save file）、新しいシェイダーグラフ（New shader graph）（フェノメノン）、コードベースの新しいシェイダー（New shader code-based）、元に戻す、繰返し、コピー、貼付け、閉じる（Close）。
【０２１７】
シェイダー作成の重要な面は、欠陥を分析し、その原因を決定し、解決策を見つける機能である。言い換えれば、シェイダーの作成者は、シェイダーのデバッグができなければならない。シェイダーにおいて欠陥を見つけて解決することは、シェイダーが、グラフを形成するためにメタノードを付加することにより作成されようが、MetaSLコードを書くことにより作成されようが、あるいはその両者により作成されようが、それとは無関係に必要なことである。メンタルミルは、ユーザーが、高いレベルの視覚的技術を使用して、ユーザーのシェイダーをデバッグできる機能を提供する。これによりシェイダーの作成者は、シェイダーの状態を視覚的に分析でき、問題の原因を迅速に隔離できる。
【０２１８】
本発明の本形態は、フェノメノンのデバッグのための構造体を提供する。メンタルミルGUIにより、ユーザーは、メタノード、または他のフェノメノンを付加することによりフェノメノンを構築でき、グラフを形成できる。各メタノードは、そのノードによりもたらされた結果を説明するプレビューイメージを含むUIによる表現を有している。全体として見ると、このイメージのネットワークは、シェイダーがその結果を計算するために使用するプロセスのイラストを提供する。図４５は、本発明のこの形態を例示している、部分的スクリーンショット６１０を示している。第１メタノード６１２は、表面上の照明を計算し、別のメタノード６１４は、テクスチャパターンを計算する。第３のノード６１６は、最初の２つの結果を組み合わせてその結果を作成する。
【０２１９】
メタノードネットワークを視覚的に見渡すことにより、シェイダーの作成者は、そのシェイディングアルゴリズムを調べることができ、結果が予想とは異なる場所を見つけ出すことができる。ネットワークにおけるノードは、フェノメノンであることもあり、その場合は、それ自身の1つまたは2つ以上のネットワークを含む。メンタルミルにより、ユーザーがフェノメノンノードにナビゲートして、同じ技術を使用して視覚的にそのシェイダーグラフを調べることができる。
【０２２０】
ある場合には、フェノメノンにおける各ノードの結果を調べても、ユーザーがシェイダーの問題を分析するために十分な情報が得られないこともある。例えば、特別なメタノードへのすべての入力は、正しい値を有しているように見えるが、それでも、そのメタノードの結果は、ユーザーが予期していたようには見えないこともある。また、MetaSLコードを書くことにより新しいメタノードをオーサリングするときも、ユーザーは、メタノードがその結果の値を計算するときに、メタノード内の変数の値を分析したいと所望することもある。
【０２２１】
一般的なプログラムのデバッグのための伝統的なモデルは、シェイダーのデバッグに完全には適応していない。CPU上で起動する一般的なプログラムは、本質的に、典型的な線形であり、データを操作する連続する指令が実行される。実行の複数のスレッドを有するプログラムもあるが、普通は、相対的により少ない数のスレッドを有し、１２以下ということもしばしばあり、各スレッドは、分離した独立の連続指令を表現している。
【０２２２】
一方、シェイダープログラムは、線形な連続指令を表現してはいるが、平行して多数のデータポイント上で作動するという点が異なる。シェイダープログラムが指令の連続リストを実行する間、それは、それを各データポイントに対して同時に行なっているように見える。シェイダーがSIMD（単一指令複数データ）モデルを使用して処理される場合もあり、その場合は、各指令は、実際、多数のデータポイントに同時に適用される。
【０２２３】
プログラムを一行ずつ進み、変数の値を調べる伝統的なモデルは、各変数が、シェイダーの実行のいかなる特別な段階においても、各データポイントに亘って広がっている多くの異なる値を有する可能性があることを考慮して修正されなければならない。これは、変数の個々の値を調べる伝統的な方法を、その時間の多くを非実用的にしてしまう。
メンタルミルは、視覚的デバッグパラダイムを、各メタノードの背後にあるMetaSLコードへ拡張する。メンタルミルMetaSLデバッガは、ユーザーに、問題のシェイダーノードに対するMetaSLコードを含むソースコードリストを提供する。そして、ユーザーは、シェイダーの指令を進むことができ、ユーザーがプログラムの実行を通して変数が変化するときにその変数の値を調べることができる。しかし、ユーザーに単一の数値をただ提供する代わりに、デバッガは、複数の値を同時に、オブジェクトの表面上にマップされたカラーとして表示する。
【０２２４】
変数の値を、単一の数字としてではなく、イメージとして表現することには、いくつかの利点がある。第１に、ユーザーは変数の値を駆動する機能の特徴を即座に認識でき、不正確に作動している領域を見つけ出すことができる。例えば、表面における変数の変化率は、表面上でカラーがどのように変化しているかを観察することにより、直感的な方法で見ることができる。ユーザーがシェイダーを一度に１ピクセルデバッグする伝統的な方法を使用している限り、これを認識することは難しい。シェイダーにおける欠陥は、シェイダーの背後の機能における不連続性に起因することがよくある。シェイダーの変化率を観察することにより、ユーザーはそのような不連続性を隔離することができる。
【０２２５】
ユーザーはまた、視覚的デバッグパラダイムを使用して、望ましくない結果をもたらす入力条件を迅速に突き止めることができる。シェイダーのバグは、ある入力パラメータが特別な値を取るときのみしか現れないこともあり、そのような状況は、幾何学的な表面の特別な部分にしか現れないこともある。メンタルミルデバッガにより、ユーザーが三次元空間を、マウスを使用してナビゲートして、問題の兆候である表面上の位置を見つけて、そこへ視線を向けることを可能にする。
【０２２６】
メンタルミルMetaSLデバッグは、ユーザーに、選択されたステートメントにおけるスコープ(scope)のすべての変数のリストを提供する。図４６は、本発明の本形態による、変数リストを例示する部分的スクリーンショット６２０を示している。ユーザーが異なるステートメントを選択すると、新しい変数がスコープに入り込み、リストに現れ、一方、他の変数はスコープから出て行き、リストから削除される。リストにおける各変数は、その名前の隣にボタンを有しており、それにより、ユーザーは、変数を開いて、そのタイプのような追加的情報や、表面上にその値を表示する小さなプレビューイメージを見ることができる。ユーザーが、変数を修正するステートメントを通過すると、その変数に対するプレビューイメージは更新してその修正を反映する。
【０２２７】
更に、ユーザーは、リストから変数を選択して、その値をより大きいプレビューウィンドウに表示することができる。
伝統的なデバッグ技術により、ユーザーはプログラムを一行ずつ進むことができ、各ステートメントにおけるプログラムの状態を調べることができる。典型的には、ユーザーはプログラムの実行の方向に、１つまたは２つ以上の行ずつ進むことのみができる。一般的に、任意のステートメントにジャンプすると、プログラムの再スタートが必要である。
【０２２８】
メンタルミルMetaSLデバッガにより、ユーザーは、いかなる順序でも、そのシェイダーコード内のいかなるステートメントへもジャンプできる。この機能の特別にすばらしい面は、コードステートメントが関心対象の変数の値を修正するとき、シェイダーのライターは、このステートメントから容易に戻りまたは先に進み、ステートメントが実行される前と後で変数の値を切り替えできる。これにより、ユーザーが変数の値上のいかなる特別なステートメントの効果も分析することが容易となる。
【０２２９】
ループ（for,for each, while ループのような）と条件ステートメント（ifとelseのような）は、このデバッグモデル内に興味ある状況を作成する。シェイダープログラムは、同時に複数のデータポイント上で動作するため、if／elseステートメントの文は、各データポイントに対して実行されることもされないこともある。
MetaSLデバッグは、ユーザーに、条件ステートメント内の変数の値を見るためのいくつかのオプションを提供する。問題は、選択されたステートメントを含むifまたはelse文を実行しないデータポイントをどのように処理するかである。これらのオプションモードには下記のものが含まれる。
【０２３０】
・最終シェイダー結果を示す−このモードでは、選択されたステートメントに到達しないデータポイントは、完全なシェイダーにより処理され、最終結果は、出力イメージに生成される。
・一定のカラーを示す−このモードでは、一定のカラーが、選択されたステートメントへ到達しないデータポイントに対する最終結果に置き換わる。これにより、ユーザーは、選択されたステートメントによりどのデータポイントが処理され、そしてされないかを容易に特定できる。これはそれ自身で、そしてそれ自身の有効なデバッグツールである。
【０２３１】
・破棄（discard）−このモードでは、選択されたステートメントが特別なデータポイントに対して到達しないと、シェイダーはそのデータポイントのみに対して廃棄され、出力イメージは修正されない。これは、実質的に、選択されたステートメントが到達されなかったデータポイントを含む表面の部分を除去する。
同様に、ループは各データポイントに対して異なる回数実行することができる。更に、ユーザーはシェイダープログラムにおけるいかなるステートメントへも任意にジャンプできるので、ループ内のステートメントを選択した場合は、ユーザーはループのどの繰り返しをユーザーが考慮しているかを指定しなければならない。ループが異なる回数、各データポイントに対して実行される可能性があるとすれば、いくつかのデータポイントは、所望の繰り返し回数に達する前にすでにループを抜けていることもある。
【０２３２】
メンタルミルデバッガにより、ユーザーは、ループを通して、所望の繰り返し回数を指定するループカウント値を指定することができる。ループカウンタは、ゼロより大きい任意の値に設定できる。値が大きいほど、より多くのデータポイントが選択されたステートメントに到達しなくなり、実際、十分に大きな値が与えられると、選択されたステートメントへ到達するデータポイントはなくなる。選択されたステートメントが到達されない状況をコントロールするオプションもまたループに適用される。
【０２３３】
変数の値を、オブジェクトの表面上にマップされたカラーとして表現することは、変数がカラータイプの場合は、良好に機能することは明白である。この方法はまた、３成分以下のスカラーおよびベクトル値に対してもかなり良好に機能するが、正規なカラーを生み出すには値を０−１の範囲にマップしなければならない。メンタルミルUIにより、ユーザーは、それらの値をカラーにマップするために使用されるスカラーとベクトルに対する範囲を指定することができる。または、メンタルミルは、所与の視点から見たときの表面上の変数の値の最小値および最大値を決めることにより、その視点に対する範囲を自動的に計算できる。
【０２３４】
ユーザーが指定した範囲を使用してスカラーおよびベクトルをカラーにマッピングすることは、有効であるが、ユーザーが変数の値を、表面のカラーを見て推測するということが要求される。メンタルミルUIは、これらのデータタイプを視覚化する他の技術を提供する。方向（場所ではなく）を表現するベクトルタイプに対して、１つの視覚化技術は、下記のイラストのように、ユーザーがマウスを表面上でドラッグするときに、表面上に位置する矢印としてベクトルを描くことである。この視覚化技術は、図４７Ａ−Ｃに示される一連の部分的スクリーンショット６３０、６３２、および６３４に例示されている。
【０２３５】
変数の数値もまた、ユーザーがオブジェクトの表面上でマウスを移動するときに、ツールチップに表示される。
マトリックスタイプの変数は視覚化に別の課題を課する。４行４列のマトリックスは、標準マトリックス表記にフォーマットされた数値の格子と見なすことができる。この視覚化技術は、図４８に示される部分的スクリーンショット６４０に例示されている。
【０２３６】
３行３列のマトリックスタイプの変数は、マトリックスの行を形成する３方向のベクトルのセットと考えることができる。これの共通の例は、接空間マトリックスであり、u'導関数、v'導関数、および法線から構成されている。マトリックスの３つの行ベクトルは、下記に示すように、マウスポインタの下の矢印として描くことができる。更に、マトリックスの個々の値は、標準マトリックスレイアウトに表示できる。この視覚化技術は、図４９に示されている部分的スクリーンショット６５０に例示されている。
【０２３７】
方向を表現しないベクトルタイプの値は、ゲージスタイルディスプレイを使用して見ることができる。これらの値をカラーにマップする同じユーザー指定範囲を使用して、ユーザーが表面上の位置を選択したときに現れる、ゲージの範囲またはゲージのセットを設定できる。ユーザーが表面上でマウスを移動すると、ゲージは、ユーザー指定範囲に対する値を図示する。この視覚化技術は、図５０に示されている部分的スクリーンショット６６０に例示されている。
【０２３８】
数値を含むベクトル矢印、ゲージ、またはツールチップが表示されると、ユーザーは、カラーにマップされた変数の値の代わりに、オブジェクトの表面上の最終シェイダー結果を見ることを選択できる。これにより、ユーザーは、選択された変数の値をモニタしながら、最終シェイダー結果における特徴に対応する表面の部分の位置を知ることができる。
メンタルミルデバッガが提供する別の有益な特徴は、マウスポインタを表面上で相互的に掃引するために使用する代わりに、特別なピクセル位置上にロックすることである。ユーザーは、ピクセルの位置を選択でき（それをマウスで選択するか、数値のピクセル座標を与えるかにより）、そのピクセル位置における変数の値は、ユーザーがコード中のステートメントを進むときに表示される。
【０２３９】
メンタルミル・シェイダー・デバッガは、メンタルミルのプラットフォームに依存しない別の利点を示す。単一のMetaSLメタノード、または１つのフェノメノン全体は、作成かつデバッグでき、更に、複数のプラットフォームを目標にできる。
デバッガは、ハードウェアまたはソフトウェアモードで作動でき、いずれの特別なレンダリングアルゴリズムとは独立に機能する。シェイダーデバッガが、メンタルミルのフェノメノン作成環境にぎっしりと統合されている事実は、作成／テストサイクルを更に減少し、それにより、ユーザーは、シェイダーの作成者が高いレベルで、プラットフォームの依存性から隔離されて作業を続けることができる。
【０２４０】
プロトタイプのアプリケーションが、このシェイダーデバッグシステムの概念の証明として作成された。
メンタルミルのアプリケーションは、このアプリケーションにより利用されるすべての機能を含むモジュラーライブラリ上に構築される。APIにより、サードパーティツールがメンタルミル技術をそのアプリケーションに統合することが可能になる。
【０２４１】
メンタルミルレイ（登録商標）の将来の世代は、メンタルミルライブラリのいくつかのサブ構成要素にアクセスできるであろうが、それは、メンタルレイによるレンダリングを容易にするためにのみ行なう。完全なメンタルミルライブラリはメンタルミルレイとは別にライセンスが与えられる。
メンタルミルAPIのより詳細な文書資料は、将来の文書により入手できるであろう。
【０２４２】
メンタルミル技術をサードパーティのアプリケーションに統合する際に、メンタルミルGUIをカスタマイズして、そのアプリケーションのルック＆フィールに合わせることができる。メンタルミルAPIにより可能なGUIのカスタマイゼーションにはいくつかの方法がある。
・フェノメノングラフの外観−メタノードおよび接続線のようなフェノメノングラフの要素は、プラグインコールバック機能を起動することにより描くことができる。デフォルト描画機能が提供されるが、サードパーティもまたそれ自身の機能を提供でき、そのアプリケーションにより合うようにシェイダーグラフの外観をカスタマイズできる。コールバック機能はまた、ノードの要素を異なる位置に配置することが可能なので、マウス・ポイント・ヒット・テスティング（mouse point hit testing）にも対処する。
【０２４３】
・キーボードショートカット−すべてのキーボードコマンドは、再割付可能である。
・マウス動作−マウスボタンの割付けのようなマウス動作は、カスタマイズできる。
・ツールバーアイテム−各ツールバーアイテムは、省略することも、含めることもできる。
・ビューウィンドウ−各ビューウィンドウは、他のウィンドウに依存することなく、それ自身で作動するように設計される。これにより、サードパーティは、例えば、フェノメノングラフビューのみをそのアプリケーションに統合することができる。各ビューウィンドウは、APIにより駆動できるので、サードパーティは、ビューウィンドウのいかなる組合せも含むことができ、ビューウィンドウのいくつかを、それ自身のユーザーインタフェースと置換できる。
【０２４４】
Ｃ．MetaSL設計仕様
メンタルミル（商標）シェイディング言語（MetaSL（商標））は、カスタムシェイディング効果を実現するための強力なインタフェースを提供し、シェイダーが実行されるいかなる特別なプラットフォームからのアブストラクション（abstraction）として機能する。
【０２４５】
レンダリングはCPU上、またはグラフィックプロセッサユニット（GPU）上で実行できるので、シェイダーはそれ自身、CPUまたはGPU上で作動する。グラフィックハードウェアとそれを駆動するAPIの機能の両者には、大きな違いがある。従って、グラフィックハードウェアを直接目標にした言語で書かれたシェイダーは、おそらく、ハードウェアおよびAPIが変化すると、書き換えなければならないだろう。更に、そのようなシェイダーは、ソフトウェアレンダラーにおいては作動せず、レイトレーシングのような、現在は、ソフトウェアのレンダリングにのみ利用できる機能はサポートしない。
【０２４６】
MetaSLは、いかなる目標プラットフォームからの独立性を維持することによりこの問題を解決する。シェイダーはいったんはMetaSLで書くことができ、MetaSLコンパイラは、それを任意のサポートされたプラットフォームへ自動的に変換する。新しいプラットフォームが登場して、グラフィックハードウェアの機能が変更されると、MetaSLで書かれたシェイダーは、書き換えの必要なく、新しい機能の利点を自動的に得るようになる。
【０２４７】
ターゲットプラットフォームからのこの隔離により、MetaSLシェイダーが、ソフトウェアまたはハードウェアレンダリングモードにおいて自動的に作動できるようになる。同じシェイダーを使用して、マシン上のソフトウェアモードおよび他のマシン上のハードウェアモードをレンダリングすることができる。この機能の別の使用法は、異なる状況に対する、シェイダーの自動的な再目的化である。例えば、映画の視覚効果のために使用するように作成されたシェイダーは、その映画に基づくビデオゲームに対しても使用できる。
【０２４８】
多くの場合、同じMetaSLシェイダーを、レンダリングがソフトウェアまたはハードウェアにおいて実行され、ユーザーが複数のシェイダーを実行することを要求される、またはされないかに拘わらず使用することができる。ある場合には、ユーザーは、シェイダーをGPUまたはCPUに対してカスタマイズすることを所望することもある。言語は、これを行ないながら、依然としてMetaSLにおいて両者の技術を実行する機構を提供する。
【０２４９】
MetaSLコンパイラにより生成されたハードウェアシェイダーは、それが、メンタルレイ（登録商標）およびニューレイ（neuray）（商標）に基づくリアリティサーバー（Reality Server）（登録商標）の次世代によるレンダリングのみにしか使用できないという制限を受ける。メンタルミル（商標）フェノメノン（商標）作成技術は、メンタルレイによるレンダリングまたはゲームのような他のアプリケーションにより外部的に使用できるハードウェアシェイダーを生成する機能を提供する。
【０２５０】
次節は、MetaSL言語仕様を説明する。MetaSLは、一般のプログラミング言語に見られるような広範囲にわたり、時折、理解が難しい特徴ではなく、共通のシェイディングアルゴリズムに必要なプログラミング要素に集中して、使い易いように設計されている。
MetaSLシェイダーのすべての要素は、シェイダーキーワードで示されるシェイダークラスにグループ化されている。
【０２５１】
shader my_shader{
// Contents of the shader are found here
};
単一のソースファイルは、複数のシェイダー定義を有することができる。シェイダークラスもまた、子シェイダーの名前の後に続き、コロンで分離されている親シェイダーの名前を記述することにより、別のシェイダーの定義を継承できる。
【０２５２】
shader my_parent_shader{
//...
};
shader my_shader : my_parent_shader {
//...
};
これにより、すべての変形例に共通なシェイダー部分を共有しながら、シェイダータイプのいろいろな変形例が実行される。シェイダーの定義は単一の親シェイダーからのみ継承できる。
【０２５３】
シェイダーは、シェイダーがその結果の値を決定するために使用する入力パラメータを、ゼロまたは１つ以上有することができる。パラメータは、下記のように任意の内蔵タイプを使用でき、または、これも下記のように、カスタム構造タイプを使用できる。
シーンにおいて使用されるとき、入力パラメータが文字による値を格納していることもあり、または別のシェイダーの結果に付加されることもあるが、シェイダーは、この可能性に関連する必要はない。シェイダーは、それが別のいずれかの変数をも参照するように、入力パラメータを参照できる。しかし、入力パラメータは読み込みのみ可能で、書き込みはできないことに注意されたい。
【０２５４】
シェイダーはその入力パラメータを、入力に示されるセクションにおいて宣言する。各パラメータの宣言が続くラベル。
shader my_shader {
input:
Color cO;
Color cl;
};
この例は、２つのカラー入力パラメータを有するシェイダーを宣言する。
【０２５５】
入力パラメータはまた、固定または可変サイズの配列であってよい。ダイナミック配列のサイズは前もって知ることはできないので、配列入力パラメータは、内蔵カウントパラメータを含む。「my array」と名前の付いた配列の長さは、my_array.countとして参照できる。固定長の入力パラメータは、ダイナミック配列とは異なり、宣言の一部として示される長さを有する。
【０２５６】
shader my_shader{
input:
int n[4]; // Fixed size array (count = 4)
int m[]; // Variable sized array
};
配列の配列は、入力パラメータタイプとしてはサポートされない。
【０２５７】
シェイダーは、少なくとも１つの出力パラメータを有していなければならないが、２つ以上有してもよい。出力パラメータは、シェイダーの結果を格納する。シェイダーの目的は、その入力パラメータのある関数を計算し、その関数の結果を出力パラメータに格納することである。
出力パラメータは、任意のタイプであってよく、ユーザー定義の構造タイプを含む。しかし、ダイナミック配列を含むことはできない。
【０２５８】
シェイダーは、その出力パラメータを、出力により示されるセクションにおいて宣言する。各パラメータの宣言が後に続くラベル。
shader my_shader{
output:
Color ambient_light;
Color direct_light; 
}; 
この例は、２つのカラー出力を有するシェイダーを宣言する。多くのシェイダーは、慣習により「result」と名前が付けられる、単一の出力パラメータのみを有する。
【０２５９】
シェイダーは、入力または出力パラメータではない他の変数を宣言できるが、その代わりシェイダーにより読まれる他の値を格納する。レンダリングが始まる前に初期化するときに、シェイダーは、値を計算でき、それをメンバー変数に格納する。メンバー変数は、レンダリングが始まる前にいったん計算された値を保持するように設計されているが、その後は変化しない。これにより、シェイダーが呼び出される毎に値を計算するという冗長性を回避する。
【０２６０】
メンバー変数は、メンバー；キーワードにより示されたセクションにおいて宣言される。例えば、
shader my_shader {
input:
Scalar amount; 
output:
Color result;
member:
Scalar noise_table [1024];
};
シェイダーの主な仕事は、1つまたは2つ以上の結果値を計算することである。これは、「main」と呼ばれるメソッドによりシェイダークラスにおいて実行される。このメソッドは、レンダラーがシェイダーの結果を必要なとき、またはシェイダーが別のシェイダーの入力パラメータに付加され、そのシェイダーがパラメータ値を必要なときにコールされる。
【０２６１】
このメソッドの戻りタイプは常にボイドであり、つまり、値を戻さない。その代わり、シェイダーの結果は、その出力パラメータに置かれなければならない。
shader mix_colors{
input:
Color cO;
Color cl; 
Scalar mix;
output:
Color result;
void main (){
result = co*(1.0-mix) + cl*mix;
}
};
この例としてのシェイダーは、第３ミックスパラメータに基づいて２つのカラーを混合する。
【０２６２】
mainメソッドは、簡単なシェイダーに対しては都合のよいインラインメソッドとして実行される。メソッドが大きい場合は、そのメソッドをシェイダー定義とは別に実行することが望ましい。これを行なうため、メソッドの名前は、シェイダー名の前に付けなければならず、２つのコロンにより分離される。例えば、
void mix_colors::main(){
result = co* (1.0-mix) + cl*mix;
}
mainメソッドに加えて、mainメソッドに対してhelperメソッドとして機能する、他のメソッドもシェイダークラスで定義できる。これらのメソッドは、任意のタイプの値を返すことができ、任意タイプのパラメータのコールを容認する。メソッド宣言は、シェイダークラスに置かれ、次の例のようである。
【０２６３】
Vector3 average_normals(Vector3 norml, Vector3 norm2);
mainメソッドの場合と同様に、helperメソッドの実行も、直接シェイダークラス定義において実行されるか、その外側で実行される。シェイダークラス定義の外側で実行されるときは、メソッドの名前を、シェイダーの名前の前に付けなければならず、その後に２つのコロンが続く。
【０２６４】
MetaSLにより、メソッドのように、特別なシェイダークラスに直接関連しない関数の定義が可能になる。関数は、宣言が任意のシェイダークラスの外側に現れることを除けば、メソッドと同様に宣言される。関数は、その関数への参照の前に現れる宣言を有しなければならない。関数本体は、宣言の一部として含むことができ、または分離した関数宣言は、関数宣言の後に、ソースファイルにおいて後であってもよい。
【０２６５】
メソッドと関数の両者は、同じ名前であるが、コールパラメータの別のセットである、別のメソッドまたは関数を定義することによりオーバーロードできる。関数またはメソッドのオーバーロードされたバージョンは、異なる数のパラメータまたはタイプが異なるパラメータ、またはその両者を有しなければならない。オーバーロードされた関数が、戻りタイプだけが異なるだけでは不十分である。
【０２６６】
関数およびメソッドへのパラメータは、常に値により渡される。コールパラメータ宣言は、下記の修飾語の１つにより修飾でき、関数またはメソッドがコールパラメータを修正することを可能にし、その修正を、コール元に見えるようにできる。
・in−パラメータ値はコールされている関数にコピーされるが、写し出すことはできない。
【０２６７】
・out−パラメータ値は、コールされている関数にコピーされず、コールされた関数により読まれても定義されない。しかし、コールされた関数は、パラメータ値を設定でき、その結果は、コール元により渡された変数にコピーして戻される。
・inout−パラメータ値は、コールされている関数にコピーされ、コール元により渡された変数に写し取られる。
【０２６８】
本発明の本形態によれば、関数およびシェイダーメソッドは、再帰的にコールすることはできないということに注意されたい。
シェイダークラスにおける別の特別に名前を付けられたメソッドは、「event」と呼ばれるメソッドである。このメソッドは、シェイダーが、シェイディング操作の前後にタスクを実行することを可能にするためにコールされる。時折、これらは「init」または「exit」関数と称される。
【０２６９】
eventメソッドは、イベントを特定する、単一のEvent_typeパラメータにより渡される。図５１は、本発明の本形態による、Event_typeパラメータのリストを説明する表６７０を示している。
すべてのinit/exitイベントは、Module__init/exit and Class_init/exitを除くスレッドローカル（threadlocal）変数へのアクセスを有している。
【０２７０】
shader my_shader{
input:
Color c; 
output:
Color result;
member:
Scalar noise_table[1024];
void main(); 
void event(Event_type event) {
if (event == Instance_init) {
for (int i=0; i<1024; i++)
noise_table [i] = Random();
}
}
};
この例において、Instance initイベントは、処理され、ノイズテーブル配列は初期化されて乱数値を含むようになる。
【０２７１】
MetaSLは、基本的タイプの広範囲のセットを含む。これらの内蔵タイプは、シェイダーが有する必要性のほとんどをカバーするが、下記に記述するように、カスタム構造を定義することにも使用できる。
下記は、MetaSL固有タイプのリストである。
・Int−単一の整数値
・Bool−ブーリアン値（真または偽）
・Scalar−指定なし精度の浮動少数点値。このタイプは、目標プラットフォームの可能な最高精度にマップする。
【０２７２】
・Vector2−２つのスカラー成分を有するベクトル
・Vector3−３つのスカラー成分を有するベクトル
・Vector4−４つのスカラー成分を有するベクトル
・Vector2i−２つの整数成分を有するベクトル
・Vector3i−３つの整数成分を有するベクトル
・Vector4i−４つの整数成分を有するベクトル
・Vector2b−２つのブーリアン成分を有するベクトル
・Vector3b−３つのブーリアン成分を有するベクトル
・Vector4b−４つのブーリアン成分を有するベクトル
・Matrix2x2−２行２列のマトリックス
・Matrix3x2−３行２列のマトリックス
・Matrix2x3−２行３列のマトリックス
・Matrix3x3−３行３列のマトリックス
・Matrix4x2−４行２列のマトリックス
・Matrix2x4−２行４列のマトリックス
・Matrix4x3−４行３列のマトリックス
・Matrix3x4−３行４列のマトリックス
・Matrix4x4−４行４列のマトリックス
・Color−r、g、b、およびスカラー成分のカラー
・Texture1d−一次元テクスチャ
・Texture2d−二次元テクスチャ
・Texture3d−三次元テクスチャ
・Texture cube−キューブマップテクスチャ
・Shader−シェイダーへの参照
・String−==および+演算子をサポートする文字列
MetaSLは、名前の付けられた整数定数のセットを表現するための便利な方法として、列挙（enumeration）を定義する関数を提供する。「enum」のキーワードが、括弧で囲まれた識別子のカンマ分離リストの前に使用される。例えば、
enum { LOW, MEDIUM, HIGH };
列挙は、名前を付けることもでき、その場合は、それは新しいタイプを定義する。列挙子（enumerator）もまた、明示的に値を割り当てることができる。例えば、
enum Detail {
LOW = 1,
MEDIUM = 2,
HIGH = 3
}; 
この例は、可能な値LOW、MEDIUM、およびHIGHを有するDetailと呼ばれる新しいタイプを定義する。列挙タイプ値は、暗黙的に整数に割り当てられ、その結果、明示的に割り当てられた値を有する整数となる。明示的な値が指定されない場合は、値は、最初の列挙子に対してゼロから開始して割り当てられ、その後、１つずつ増加される。
【０２７３】
すべてのベクトルタイプは、同様な方法でアクセスできる成分を有する。成分は、変数名にピリオドを付けて、その後に、[ｘ、ｙ、ｚ、ｗ]の１つを続けることにより参照できる。長さ２のベクトルは、ｘおよびｙ成分のみを有することができ、長さ３のベクトルは、ｘ、ｙ、およびｚを有し、長さ４のベクトルは、４成分すべてを有する。
ベクトル成分を参照するときは、同時に複数の成分にアクセスできるが、結果は、同じまたは異なる長さの別のベクトルである。成分の順序もまた任意であってよく、同じ成分を、２回以上使用することもできる。例えば、長さ３のベクトルVに対しては、
・  V.xyは２成分ベクトル<x,y>を返す
・  V.zyxは３成分ベクトル<z,y,x>を返す
・  V.xxyyは４成分ベクトル<x,x,y,y>を返す
ベクトルに書くときに、同じ構文をマスクとして使用できる。違いは、割り当ての左側の成分を繰り返すことができないということである。
【０２７４】
V.yz = Vector2(0.0, 0.0);
この例において、ｙとｚ成分は、0.0に設定され、ｘとｙ成分は変更されない。
ベクトル成分もまた、配列インデックスを使用してアクセスでき、配列インデックスは変数であってよい。
Scalar sum = 0.0;
for (int i=0; i<4; i++)
sum += V[i];
この例において、Vector4 Vは、ループを使用して合計した成分を有する。
【０２７５】
ベクトルは、要素の合計数が、構築中のベクトルにおける要素の数以上であれば、他のベクトル（またはカラー）から直接構築できる。要素は、それらが一覧表示されたときの順序でコンストラクタパラメータから取り出される。
Vector4 v4(1.0, 2.0, 3.0, 4.0);
Vector2 v2(v4);
Vector3 v3(0.0, v2);
上記の３つのベクトルコンストラクタコールはすべて適性である。この例は、図５２で示した表６８０に記載した値により初期化された３つのベクトルの結果となる。
【０２７６】
標準数学演算子（+,-,*,/）は、すべてのベクトルに適用され、成分に関して演算を行なう。標準数学演算子は、オーバーロードされて、式において異なるサイズのスカラーおよびベクトルの混合を可能にするが、いかなる単一の式においても、すべてのベクトルは同じサイズを有しなければならない。スカラーがベクトルと混合されると、スカラーは、各要素がスカラーの値に設定された、同じサイズのベクトルに促進される。
【０２７７】
Vector2 vl(a,b);
Vector2 v2(c,d);
Vector2 result '= (vl+v2) * e;
この例において、変数a、b、c、d、およびeは、すべて以前に宣言されたスカラー値である。変数の結果は、値<(a+c)*e, (b+d)*e>を有する。
【０２７８】
標準ブーリアン論理演算子は、ブーリアンの個々またはベクトルにも適用できる。ブーリアンのベクトルに適用されると、成分に関して演算を行ない、ベクトル結果をもたらす。これらの演算子は、図５３で示した表６９０中に一覧表示されている。
ビットに関する演算子はサポートされていない。比較演算子はサポートされており、ベクトルに対して、成分に関する演算を行ない、ブーリアンベクトル結果をもたらす。サポートされている比較演算子のリストは、図５４に示す表７００に記載されている。
【０２７９】
３値条件演算子もまた、成分に関して、ベクトルオペランドに適用できる。条件オペランドは、成分の数が、第２および第３オペランドの成分と同じである、単一なブーリアン式またはベクトルブーリアン式でなければならない。
Vector2 vl(1.0, 2.0);
Vector2 v2(2.0, 1.0);
Vector2 result = vl < v2 ? Vector2(3.0, 4.0): Vector2 (5.0, 6.0);
この例において、結果変数は値＜3.0、6.0＞を保持する。
【０２８０】
Colorタイプのインスタンスは、その構造において、Vector4のインスタンスと同一であるが、そのメンバーは、[x、ｙ、ｚ、ｗ]の代わりに、[r、ｇ、ｂ、a]により参照され、それぞれ、赤、緑、青、およびアルファ成分を意味する。
それらは、Vector4が使用できる場所であればどこでも使用でき、Vector4に適用されるすべての演算は、Colorでも同様に作用する。このタイプの主な目的は、コードの可読性である。そうでない場合は、このタイプは論理的にVector4と同義である。
【０２８１】
マトリックスは、２から４の範囲のサイズの行と列により定義される。すべてのマトリックスは、Scalarタイプの要素から構成されている。マトリックスの要素は、配列インデックスがマトリックスから行を選択する配列の表記法（行優先順序）を使用して参照することもできる。結果としての行は、元のマトリックスのサイズにより決まり、Vector2、Vector3、またはVector4である。マトリックスのインデックス付けの結果は、ベクトルであり、ベクトルタイプもインデックス演算子をサポートするので、マトリックスの個々の要素は、多次元配列に対しての構文と同様な構文によりアクセスできる。
【０２８２】
Matrix4x3 mat(
1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.5, 0.0);
Vector4 row;
Scalar element;
// row will equal <0.0, 1.0, 0.0> after the assignment
row = mat[I];
// element will equal 0.5 after the assignment 
element = mat[3][1]
この例により示されるように、マトリックスは、行優先順序で要素の値を容認するコンストラクタも有する。マトリックスは、下記の例のように、行ベクトルを指定することでも構築できる。
【０２８３】
Vector3 row0(1.0, 0.0, 0.0);
Vector3 row1(0.0, 1.0, 0.0);
Vector3 row2(0.0, 0.0, 1.0);
Vector3 row3(0.0, 0.0, 0.0);
Matrix4x3 mat(row0, row1, row2, row3);
マトリックスコンストラクタに渡されたベクトルの要素の数は、構築されているマトリックスの行における要素数と合わなければならない。
【０２８４】
乗算演算子は、２つのマトリックスまたはマトリックスとベクトルの乗算のためにサポートされ、その２つの間で線形代数スタイルの乗算を行なう。２つのマトリックスを乗算するときに予想されるように、左側のマトリックスの列数は、右側のマトリックスの行数に等しくなければならない。Ｎ×ＴマトリッスをＴ×Ｍマトリックスに乗算した結果は、Ｎ×Ｍマトリックスである。ベクトルは、ベクトルがマトリックスの左側にあるときに、要素数が行数に等しければ、そして、ベクトルが右側にあるときに、要素数が列数に等しければ、右側からでも左側からでも乗算できる。
【０２８５】
自動的タイプ変換は、１つのタイプの変数を別のタイプの変数に割り当てることを可能にする。唯一の制限は、暗黙的にベクトルを変換するときに、変換は同じサイズのベクトルに対してであるということである。異なるサイズのベクトル間で、またはスカラー間で変換するためには、コンストラクタが使用できるか、または.xyzw表記が使用できるかである。例えば、
Vector3 v3(0,0,0);
Vector2 v2 = Vector2(v3.x, v3.y); 
or:
Vector3 v3(0,0,0);
Vector2 v2 = v3.xy;
.xyzw表記は、ベクトルを生成するために、Scalarタイプの変数に適用できる。例えば、
Scalar s = 0.0; 
Vector3 v3 = s.xxx;
この状況では、１つの要素ベクトルと考えられるスカラーに対しては、x要素のみが有効である。
【０２８６】
スカラーを整数に変換するような、精度が落ちる結果となる可能性のある変換は可能だが、コンパイラ警告が発せられる。この警告は、シェイダーのライターが所望するならば発せられないようにできる。
MetaSLは、内蔵タイプの、またはユーザー定義構造のいずれの配列もサポートするが、固定長の配列のみがシェイダー関数においては宣言できる。２つの例外がある。入力パラメータの節で述べたように、シェイダー入力は、ダイナミックなサイズを有する配列として宣言できる。他の例外は、関数またはメソッドに対するパラメータであり、指定されないサイズの配列であってよい。これら両者の場合において、レンダリング中に、シェイダーが起動されるまでには、配列変数の実際のサイズが分かる。シェイダーコードはname. countとして配列のサイズを参照でき、ここにおいてnameは配列変数名である。
【０２８７】
Scalar sum_array(Scalar values[]) {
Scalar sum = 0.0;
for (int i=0; i<values.count; i++)
sum += values[i];
return sum;
} 
Scalar a_function() {
Scalar foo[8]; ... // initialize members of foo 
return sum_array(foo);
}
この簡単な例は、配列上をループし、成分を合計する。この機能に対するコードは、配列のサイズを実際には知ることなく書かれたが、シェイディングのときは、サイズも分かる。配列変数が配列シェイダーパラメータからもたらされるか、または固定サイズの配列がコール関数において宣言されるかである。
【０２８８】
カスタム構造タイプは、MetaSLシェイダーにより使用されるタイプのセットを拡張するために定義できる。構造タイプ定義の構文は、下記の例のようである。
struct Color_pair {
Color a;
Color b;
};
この例において、Color対と呼ばれる新しいタイプは、２つのカラーから構成されるものとして定義される。
【０２８９】
構造メンバー変数は、いかなる内蔵タイプでもよく、入れ子構造を作成するための別のユーザー定義構造タイプでもよい。構造メンバーは、配列であってもよい。
ユーザー定義構造および列挙は、MetaSLにおけるユーザー定義タイプの唯一の形態である。
シェイダーのmainメソッド内で、特別な状態変数は、暗黙的に宣言され、シェイダーコードが参照するために利用できる。これらの変数は、シェイダーコールという結果になったインターセクションについての情報と共に、レンダラーの現在の状態の両者を記述する値を保持している。例えば、法線は、インターセクションの点において内挿された法線を参照する。
【０２９０】
これらの変数は、シェイダーのmainメソッドの内部においてのみ利用できる。シェイダーがhelperメソッド内のこれらの状態変数の１つにアクセスしようとするとき、変数は明示的にそのメソッドに渡されなければならない。
状態変数のこのセットは、すべてのシェイダーに対しては、暗黙的入力として見える。状態入力のデータタイプは、シェイダーが利用できるすべての状態変数を含むストラクトである。特別状態シェイダーは、この暗黙的入力に接続できる。状態シェイダーは、各状態メンバーに対する入力を有しており、その状態ストラクトを出力する。
【０２９１】
状態のデータメンバーは、直接は修正できないが、状態を入力として開示すると、１つのシェイダーが、別のシェイダーが、そのシェイダーにより使用される状態値を駆動することを可能にしながら、状態変数を参照することが可能になる。シェイダーの状態入力が付加されないままでいると、シェイダー内からの、状態変数へのいかなる参照も、修正されていない状態値への参照に戻ってしまう。
【０２９２】
例えば、照明を計算するシェイダーは、インターセクションの点において垂直な表面を参照する可能性がある。バンプマップシェイダーは、それが、状態法線の組み合わせから計算する修正された法線と、グレースケールのイメージから導出された乱れを作成できる。状態シェイダーは、このように法線を入力としてエクスポーズする照明シェイダーへ付加できる。次に、バンプシェイダー出力は、状態シェイダーの法線入力に付加できる。
【０２９３】
照明シェイダーは、シーンの照明上を繰り返す照明ループを含み、間接的に、照明シェイダーを評価させる可能性が最もある。照明シェイダーに渡された状態値は、表面シェイダーに提供された状態値と同じである。状態は状態シェイダーにより修正されると、その修正は、照明シェイダーにも影響を与える。
暗黙的状態入力パラメータのこのシステムは、シェイダーの書き込みを簡単にする。シェイダーは容易に状態変数を参照でき、一方、同時に別のシェイダーを、その状態変数を修正するために付加する可能性を維持している。状態はそれ自身、実際には修正されないので、別のシェイダーに悪影響を与える危険はない。
【０２９４】
図５５は、本発明の本形態による、バンプマッピングを例示する模式図７１０を示す。最初は、これは少し複雑に見えるかもしれないが、バンプマッピングを実行するグラフは、フェノメノンノード内に詰めることができ、あたかも単一のシェイダーのように見える。
「Perturb法線」シェイダーは、グレースケールイメージの３つのサンプルを使用して、乱れ量を作成する。バンプマップテクスチャをサンプリングするために使用されるテクスチャ座標は、UおよびV方向の両者においてオフセットされており、UおよびV方向におけるグレースケールイメージの勾配を計算することが可能になる。
【０２９５】
「量」入力は、乱れ量を拡大／縮小する。「Perturb法線」シェイダーは、この乱れを状態の法線に追加して、新しい修正法線を作成する。
３つの「Textureルックアップ」シェイダーが「Perturb法線」シェイダーの入力を駆動する。これらのシェイダーの２つは、付加された状態シェイダーから修正テクスチャ座標を供給される。状態シェイダーはそれ自身「Offset座標」シェイダーにより作成された修正テクスチャ座標が供給される。
【０２９６】
模式図全体は、フェノメノンに含まれるので、すべてのユーザーがこの詳細に関心を持つ必要はない。バンプマップフェノメノンは、Texture2dタイプの入力を有し、それは３つのテクスチャルックアップのすべてに供給される。「オフセット」入力により、ユーザーはUおよびV方向におけるオフセットを、単一パラメータによりコントロールできるようになる。「Perturb法線」シェイダーの「量」入力もまた入力としてバンプマップフェノメノンに開示される。
【０２９７】
図５６は、使用中のバンプマップフェノメノンを例示している図７２０を示している。フォンシェイダー(phong shader)は、それがシーン照明上をループするとき、暗黙的に状態法線を参照する。この場合、フォンシェイダー入力は、状態シェイダーに付加され、バンプシェイダーにより作成された修正法線は、状態シェイダーの法線入力に付加される。
状態シェイダーの存在は、シーンの背後で何が起きているかを、ユーザーに非常に明確にする。興味あるユーザーは、バンプマップフェノメノンを開けて、バンプマップアルゴリズムを視覚的に描写しているグラフを見ることができる。
【０２９８】
状態変数のセットには以下が含まれる。位置、法線、原点、方向、距離、texture_coord_n、およびscreen_position。このリストは、それをより広範囲にするために補充できる。プリプロセッサを使用して、これらの長い名前を共通の短い名前の省略（１文字のこともよくある）で置き換えることもできることに注意されたい。
代替の構成においては、状態変数パラメータが、ノードに追加される。本発明の本形態によれば、特別状態変数のセットは、シェイダーのmainメソッド内で、暗黙的に宣言され、シェイダーコードが参照のために利用できる。これらの変数は、シェイダーコールにつながるインターセクションについての情報と共に、レンダラーの現在の状態の両者を記述する値を保持している。例えば、normal変数は、インターセクションの点における内挿された法線を参照する。
【０２９９】
本発明の本形態によると、これらの変数は、シェイダーのmainメソッドの内部でのみ利用できる。シェイダーが、helperメソッド内のこれらの状態変数の１つへのアクセスを所望すると、変数は、そのメソッドへ明示的に渡されなければならない。または、状態変数それ自身を別のメソッドに渡してもよく、その場合は、すべての状態変数は、そのメソッドで利用可能になる。
【０３００】
状態変数のこのセットは、デフォルトにより、状態それ自身に付加された、すべてのシェイダーへの暗黙的な入力と見なすことができる。しかし、１つまたは２つ以上の入力パラメータを、名前が状態変数に対応しているシェイダーのインスタンスに動的に追加することもできる。その場合、これらの入力は状態値に上書きされ、元のシェイダーソースコードを修正することなく、別のシェイダーの結果への接続が可能になる。上書きされる入力パラメータにより状態変数を修正することに加えて、シェイダーは、MetaSLインプレメンテーションにおける割当てステートメントにより、状態変数を直接修正することもできる。
【０３０１】
状態変数を入力として開示することにより、１つのシェイダーが状態変数を参照することが可能になり、一方、別のシェイダーはそのシェイダーにより使用される状態変数を駆動することが可能になる。特別に参照された状態変数に対して、入力パラメータがない場合は、その変数は元の状態値を参照し続ける。
例えば、照明を計算するシェイダーは、典型的にインターセクションの点における表面法線を参照する。バンプマップシェイダーは、状態法線とグレースケールイメージから導出されたパーターベーションの組合せから計算して、修正法線を生成することもある。「normal」と呼ばれるパラメータを、照明シェイダーのインスタンスに追加することにより、normalを、入力として、その特別のインスタンスに対してのみ開示することができる。そして、バンプシェイダーの出力は、シェイダーのnormal入力に付加できる。
【０３０２】
本発明の更なる形態によれば、照明シェイダーは、シーンの照明上を繰り返す照明ループを含み、照明シェイダーを直接評価させる。照明シェイダーに渡された状態変数は、表面シェイダーに提供されたものと同じ状態値となる。状態変数がパラメータにより上書きされるか、またはシェイダー内で修正されると、その修正は照明シェイダーにも影響する。しかし、すべての入力パラメータは、シェイダーが実行を始める前に評価されるので、入力パラメータに付加されたシェイダーに影響を与える状態変数を修正することはできない。
【０３０３】
暗黙的状態入力パラメータのこのシステムは、シェイダーの書込みを単純化する。シェイダーは容易に状態変数を参照でき、一方、同時に、別のシェイダーを付加してその状態変数を修正する可能性もまた維持する。
図５７は、バンプマップフェノメノン７３２の模式図７３０を示している。図５７に示されるように、バンプマッピングを実行するグラフは、フェノメノンノード内部に詰め込むことができ、あたかも単一シェイダーのように見える。
【０３０４】
「Perturb 法線」シェイダー７３４は、パーターベーション量を作成するために、グレースケールイメージの３つのサンプルを使用する。バンプマップテクスチャをサンプリングするテクスチャ座標は、UおよびV方向の両者においてオフセットされ、これにより、UおよびV方向におけるグレースケールイメージの勾配を計算できる。「量」入力は、パーターベーションの量を拡大／縮小する。「Perturb 法線」シェイダー７３４は、このパーターベーションを状態「normal」に追加して新しい修正「normal」を作成する。
【０３０５】
３つの「Texture lookup」シェイダー７３６は、「Perturb 法線」シェイダー００４の入力を駆動する。これらのシェイダーの２つは、付加された「Offset coord」シェイダー７３８から、修正テクスチャ座標が供給される。
模式図全体は、フェノメノン７３２に含まれており、そのため、すべてのユーザーが詳細に関連しなければならないといことはない。このバンプマップフェノメノンは、３つの「Texture lookup」に供給されたTexture2dタイプの入力を有する。「offset」入力により、ユーザーは、単一のパラメータによりUおよびV方向におけるオフセットのコントロールが可能になる。「Perturb 法線」シェイダーの「量」入力もまた、バンプマップフェノメノンへの入力として開示される。
【０３０６】
図５８は、使用中のバンプマップフェノメノン７４０の図を示している。フォンシェイダー７４２は、それがシーン照明上をループするときに、状態normalを暗黙的に参照する。このイラストは、追加された「normal」入力を有するフォンシェイダーのインスタンスを示しており、それにより、normalがバンプマップシェイダーの出力に付加できるようになる。図５９Ａ−Ｂは、状態変数の完全なセットを一覧表示している表７５０を示している。
【０３０７】
状態ベクトルは、常に「内部（internal）」空間において提供される。内部空間は定義されず、異なるプラットフォーム間で変化もできる。シェイダーが、座標系に依存せずに計算を実行できるならば、状態ベクトルと直接作用することができ、そうでなければ、状態ベクトルを既知の空間へ変換する必要がある。
いくつかの定義された空間があり、状態は、これらの座標系の間で、ベクトル、点、および法線を変換するマトリックスおよび関数を提供する。図６０は、変換マトリックスを一覧表示している表７６０を示している。
【０３０８】
照明およびボリュームシェイダーが利用できるいくつかの追加的状態変数があり、それらは、照明の特性およびボリュームシェイダーに対する入力値へのアクセスを提供する。照明またはボリュームシェイダー状態変数を参照するシェイダーノードは、照明またはボリュームシェイダーとして、またはそれ自身が照明またはボリュームシェイダーとして使用されるグラフにおいてのみ使用できる。
【０３０９】
照明シェイダーは、状態変換関数をコールし、値「light」を、fromまたはtoパラメータとして渡すことができる。
図６１は、照明シェイダー状態変数を一覧表示している表７７０を示し、図６２は、ボリュームシェイダー状態変数を一覧表示している表７８０を示している。
現在のインターセクション状態の原因となっているレイは、レイタイプ、レイシェイダーにより記述され、ray_dispersal_group()およびray_history_group()状態変数および関数である。これらの変数および関数は、レイの属性を記述するために下記の文字列を使用する。
【０３１０】
レイは正確に下記のタイプの１つを有する。
・「eye」-その原点が眼の位置にある第１世代レイ
・「transparent」−現在のオブジェクトへの透明レイ
・「refract」−現在のオブジェクトへの屈折
・「reflect」−現在のオブジェクトからの反射
・「shadow」−シャドウレイ
・「occlusion」−周囲遮断レイ
・「environment」−環境レイ
レイは下記のグループの最大１つのメンバーであってよい。
【０３１１】
・「specular」−鏡面透明、反射、または屈折
・「glossy」−光沢透明、反射、または屈折
・「diffuse」−拡散透明、反射、または屈折
シェイダーは、下記のグループの正確に１つのメンバーである。
・「regular」−正規表面またはボリューム
・「photon」−大域照明または火線フォトン
・「light」−照明シェイダーコール
・「displace」−変位シェイダーコール
レイは、下記の履歴フラッグを０または１つ以上を有することができる。
【０３１２】
・「lightmap」−照明マップシェイダーコール
・「final gather」−最終統合レイ
・「probe」−シェイダーをコールしないプローブレイ
・「hull」−胴体表面を介するパス
・「volume」−レイの原点は、空の空間
所定のTrace_optionsクラスは、次節で記述されるtrace()およびocclusion()関数により使用されるパラメータを保持する。シェイダーはこのタイプのインスタンスをいったん宣言でき、それを複数のトレースコールへ渡す。
【０３１３】
Trace_optionsインスタンスが宣言されると、そのメンバー値すべては、デフォルト値に初期化される。そして、シェイダーは種々のセットメソッドをコールして、値をデフォルトとは異なる値に変更できる。図６３は、Trace_optionsクラスのメソッドを一覧表示している表７９０を示している。
図６４と６５は、インターセクション状態の一部として提供され、状態変数を介してアクセスできる値に依存する関数を一覧表示している表８００と８１０を示す。これらの関数は、状態変数と同様に、シェイダーmainメソッドまたは状態変数がパラメータとして渡されるいかなるメソッドにおいてのみコールできる。
【０３１４】
MetaSLはシェイダーの実行の流れをコントロールする馴染みのあるプログラミングコンストラクトをサポートする。具体的には、次の通りである。
・ループステートメント、for、while、およびdo、while。キーワードcontinueおよびbreakは、ループの実行をコントロールするためにサポートされる。
・オプションのelseクローズを伴う分岐ステートメントifと、switch、caseステートメント。
【０３１５】
・関数またはメソッドを終了し、関数またはメソッドがボイドタイプを有していなければ値を返すためのreturnステートメント。
フローコントロールステートメントのための構文は、標準Cプログラミング言語で使用されるものと同じものである。
Light_iteratorクラスは、照明繰返しを容易にし、明示的照明リストシェイダー入力パラメータは要求されない。照明イテレータは、暗黙的に、状態を介してシーン照明を参照する。このイテレータのインスタンスは、foreachステートメントの一部として宣言され指定される。構文は下記のように見える。
【０３１６】
Light_iterator light;
foreach (light) {
// Statements that refer to members of 'light'
}
ほとんどの表面シェイダーは、照明光源をループして、シーンにおける照明から直接照明を合計する。更に、エリア照明は、エリア照明の表面上の点において複数のサンプルを取ることを要求する。foreachステートメントは、適切であれば、シーンにおける照明と、エリア照明の表面上のサンプル点の両者を列挙する。
【０３１７】
foreachブロック内で、各照明に対する照明シェイダーを起動することによる結果を含む照明イテレータのメンバーにアクセスできる。Light_iteratorクラスは、図６６に示されている表８２０において一覧表示されている。
シェイダーはいくつの照明が、またはいくつのサンプルが累積されているかを意識する必要はなく、照明およびサンプルの列挙を駆動しているレンダラーに、一度に単一のサンプルに対するBRDFを提供することのみに責任がある。シェイダーは、ループの外側で1つまたは2つ以上の変数を宣言して、照明の結果を格納する可能性がある。ループの各トリップのたびに、シェイダーは、BRDFの結果をこれらの変数に追加する。
【０３１８】
Color diffuse_light(0,0,0,0);
Light_iterator light; foreach (light) {
diffuse_light += light.dot_nl * light.color;
これは、照明上をループして拡散照明を合計する簡単な例である。
MetaSLの強力な特徴は、特別な目標プラットフォームからは独立してシェイダーを記述できる機能である。これには、MetaSLシェイダーを、ソフトウェアに基づくレンダラーと共にソフトウェア内で、およびGPUが利用できるときにハードウェア内で起動する機能も含まれる。
【０３１９】
ソフトウェアレンダリングは、典型的には、より一般化され、柔軟性があり、それにより、レイトレーシングおよび大域照明を含む多様なレンダリングアルゴリズムが可能になる。この明細書を書いている時点では、グラフィックハードウェアは、一般的にはこれらの特徴をサポートしていない。更に、異なるグラフィックハードウェアは、異なる機能とリソースの制限を有する。
【０３２０】
MetaSLコンパイラは、シェイダーのライターに、それがコンパイルする特別なシェイダーいずれに対しての条件を示すフィードバックを提供する。これにより、ユーザーは、自分が書いたシェイダーが、グラフィックハードウェアの特別な部分上で実行可能かどうかを知ることができる。可能な場合は、コンパイラは、シェイダーのどの部分が、グラフィックハードウェアとの非互換性の原因となっているかを具体的に示す。例えば、シェイダーがレイトレーシング関数をコールすると、コンパイラは、レイトレーシングコールの存在が、シェイダーがソフトウェア互換のみでなければならないことを強制していることを示す。または、ユーザーは、コンパイラにハードウェアシェイダーを作成させるスイッチを指定することもできる。ハードウェアによりサポートされていないAPIへのコールは、シェイダーから自動的に除去される。
【０３２１】
MetaSLは、下記のプリプロセッサ宣言に対するサポートを含む。#define、#undef、#if、#ifdef、#ifndef、#else、#elif、#endif。
これらの宣言は、Cプログラミング言語における等価なものと同じ意味を有している。引数を伴うマクロもまた次のようにサポートされる。
#define square(a) ((a)*(a))
#include宣言も、他のMetaSLソースファイルを現在のファイルに追加するためにサポートされる。これにより、構造定義およびシェイダーに基づくクラスはファイル間で共有できる。
【０３２２】
技術は、シェイダーインプレメンテーションの変形例である。あるシェイダーは、単一の技術のみを必要とするが、複数の技術を実装するのが望ましい状況もある。言語は、シェイダー内で複数の技術を宣言するための機構を提供する。
単一のシェイダーの実装がソフトウェアとハードウェアの両者にマップが可能で、まったく同じシェイダーが、レンダリングがCPUまたはGPU上で行なわれるかに無関係に使用できることがよくある。しかし、ある場合には、例えば、ソフトウェアシェイダーが現在のグラフィックハードウェアによりサポートされていない関数を使用する場合などには、シェイダーがGPU上でも作動するために、シェイダーのための別のメソッドを実装する必要がある。異なるグラフィックプロセッサは、また異なる関数と制限を有しており、従って、特別なGPU上で作動するシェイダーが、別のGPU上で作動するには複雑すぎることもある。技術により、シェイダーの複数のバージョンがハードウェアの異なるクラスをサポートできるようになる。
【０３２３】
あるシェイダーは、異なる状況で使用される種々のシェイディング方法を実装したいとも考えるだろう。例えば、マテリアルシェイダーは、シャドウレイをトレースするときに使用される、表面の点における透明度の量を提供するシャドウ技術を実装するかもしれない。異なる技術は、より高速であるがより低品質の、または、より低速であるがより高品質のシェイダーを実装するために使用することもできる。
【０３２４】
ある意味では、技術はシェイダーの異なるバージョンのようであるが、シェイダーの技術は、シェイダークラス内で宣言され、シェイダーパラメータと他の変数を共有する。これにより、技術は引き続き、クラス内にグループ化されて構成される。シェイダーが１つの技術しか有しないときは、シェイダークラスが、正式にその技術を宣言する必要はない。
【０３２５】
技術宣言は、シェイダークラス定義内の入れ子のクラス定義にいくらか類似して見える。技術宣言は、その技術を参照するために使用できる名前を提供する。技術は、少なくとも、シェイダー技術の主要な機能を実行するmainメソッドを定義しなければならない。更に、技術は、init and exitイベントを扱うeventメソッドを実装することができる。mainメソッドおよびeventメソッドは前節に記述されている。更に、技術は、２つの主要技術方法により使用される、他のローカルなhelperメソッドを含むこともできる。
【０３２６】
Shader my_shader {
input:
Color c;
output:
Color result;
technique software {
void event(Event_type event);
void main();
}
technique hardware { 
void event(Event_type event);
void main();
}
};
void my_shader::software::event(Event_type event) {
…
}
void my_shader::software::main() {
…
}
void my_shader::hardware::event(Event_type event) {
…
}
void my_shader::hardware::main() {
…
}
この例は、ハードウェアとソフトウェアに対する２つの別の技術を実装するシェイダーを示している。技術のmainメソッドおよびeventメソッドは、クラス定義中にインラインで、またはこの例で示されるように分離して実装できる。
【０３２７】
レンダー時に、レンダラーによりアクセスできる分離したルールファイルは、レンダラーに、どのようにしてシェイダーの異なる技術を選択するかを報知する。ルールは、所定のトークンのセットの値に基づいて技術を選択するための基準を記述する。トークン値は、シェイダーが使用される状況を記述する。可能なトークン値は、次の通りである。
・シェイディング品質（Shading quality）−反射で現れる表面の点は（でこぼこで、ぼやけた、またはそうでなければ、ゆがんだ表面の点）より高速であるがより低品質バージョンのシェイダーによりシェイディングされることがよくある。
【０３２８】
・シャドウ（Shadow）−シャドウレイをトレーシングする間に、透明度を決定するために表面の点をシェイディングするときは、このトークン値は真である。
・エネルギー（Energy）−照明により生成されるエネルギーを決定して、レンダラーが重要度によりレイをソートできるようにするために照明シェイダーをコールするときは、このトークン値は真である。
【０３２９】
・ハードウェア／ソフトウェア（Hardware/Software）−これらのトークン値は、レンダリングがCPU上でソフトウェアにおいて行なわれているか、GPU上でハードウェアにおいて行なわれているかを示す。
・シェイダーバージョン（Shader version）−現在のハードウェアによりサポートされる最高のピクセルシェイダーバージョン。
【０３３０】
・ハードウェアベンダーチップセット（Hardware vender chipset）−現在のハードウェアのチップセットを特定する文字列。例えば、nv30またはr420。
ルールは、技術の名前と、トークン値に基づき、特別な技術が選択されたときに定義する式を指定する必要がある。複数のルールは、トークン値の特別なセットのいずれにも合っている。レンダラーが、シェイダーのための技術を選択するために使用するプロセスは次の通りである。最初は、シェイダーに存在する技術に対するルールのみを考慮する。これらのルールから、それぞれが順番にテストされ、第１の適合ルールが技術を選択する。合うルールがない場合は、エラー／警告が発せられるか、デフォルト技術が、シェイダーに対して使用される。
【０３３１】
下記は、ルールファイルの例を示している。
beauty:              software and shade_quality > 1
fast:                software and shade_quality = 1 
standard:            software
fancy_hardware:      hardware and shader_vers?}on >= 3.0
nvidia_hardware:     hardware and chipset == "nv30"
basic_hardware:      hardware
最初の３つのルールは、「standard」と呼ばれる、シェイディング品質レベルのすべてを扱う単一の技術または、２つの異なる品質レベルのシェイディングを別々に扱うための２つの技術「beauty」と「fast」を有するシェイダーを有するソフトウェアシェイダーをサポートする。トークン値は、作動時にシェイダーが利用することも可能で、単一のstandard技術を有するシェイダーは、所望する品質レベルに従って、オプションの計算を実行することができる。
【０３３２】
第２の３つのルールは、ハードウェアの異なるクラスをサポートするための異なる技術の例である。高度なハードウェア技術は、シェイダーモデル３.０またはそれ以降にのみ利用できる機能を利用することができる。nvidia_hardware技術は、NVIDIAのnv30チップセットに特有な特徴を使用できる。最終的に、basic_hardwareは、一般のハードウェアを扱うための、多様に対処可能な技術といえる。
【０３３３】
言語は、マテリアルシェイダーがその結果を、単一のカラー値の代わりに、一連の成分として表現することを可能にする機構を含む。これにより、成分を、後での合成のためにイメージバッファーを分離するために格納することが可能になる。個々のパスもまた、すべての成分のサブセットのレンダリングを行なうことができ、それらを、以前にレンダリングされた残りの成分と組み合わせることができる。
【０３３４】
シェイダーがその結果を複数の成分に分解するとき、同時にすべての成分、またはすべての成分のサブセットを計算するシェイダーの変形例を自動的に生成することができる。成分のサブセットのみが計算されているときは、成分が依存した他の計算を、自動的に生成されたシェイダーから省略することができる。例えば、シェイダーが大域照明を使用して、間接照明を計算し、その間接照明を別の層に格納すると、大域照明を再計算することなしに、他の層を再レンダリングされ、間接照明層と合成できる。同じシェイダーソースコードを各パスに対して使用できるが、レンダラーは、単一のソースから、必要な成分のみを計算する個々のシェイダーを自動的に生成する。これは、層のいずれかがソフトウェアレンダリングに関連するならば、明らかにC++コンパイラと共に利用できるソースコードを有することに依存する。
【０３３５】
マテリアルシェイダーは、その結果を、各成分に対して別個の出力を宣言することにより成分に分解する。出力変数の名前は、現在のレンダリングにおける層の名前を定義する。
shader Material_shader {
input:
…
output:
Color diffuse_lighting;
Color specular_lighting; 
Color indirect_lighting;
};
この例は、拡散、鏡面反射、および間接照明のための３つの成分を指定するマテリアルシェイダーを示している。
【０３３６】
複数のマテリアルシェイダーが、その結果を異なる層に分解するシーンに存在すると、層の合計数は大きくなる可能性がある。ユーザーは、これらの層のそれぞれに、別のイメージバッファーを割り当てることを所望しないかもしれない。シーン定義ファイルにおける機構により、ユーザーは、層をイメージバッファーに組み合わせるための合成ルールを指定できる。ユーザーは、いくつのイメージバッファーを作成するかを指定し、各バッファーに対して、ピクセルがレンダリングされるときにそのバッファーに置くべきカラーを決定する式を指定する。式は次のような層の値の関数として表現できる。
【０３３７】
Imagel = indirect_lighting
Image2 = diffuse_lighting + specular_lighting
この例において、前の例におけるシェイダー結果構造からの３つの層は、２つのイメージバッファーへルーティングされる。
標準MetaSLライブラリは、API機能を提供し、それにより、シェイダーはレイを投じることができる。レイトレーシングは、計算量が非常に多い。レンダリング時間を最適化するためにレンダラーは、レイトレーシングを遅延して、複数のシェイダーコールがグループ化できるようにする機構を提供する。これは、キャッシュの一貫性を改善し、従って、全体のシェイダー性能を改善する。シェイダーは、レイトレーシングのためにレイを予定するための関数をコールするオプションを有している。この関数は、レイが実際にトレーシングされる直前に戻り、シェイダーと他のシェイダーが処理を続行することが可能になる。
【０３３８】
シェイダーがレイトレーシングを予定するときは、レイトレーシングからの結果をシェイダーの結果と合成することのコントロールを支援するファクタも提供しなければならない。更に、最終イメージへのレイの重要性を記述する重量ファクタも提供し、それにより、重要性に基づくサンプリングが可能になる。例えば、ファクタは、ユーザー指定の反射量と組み合わされたフレネル減衰の結果であってもよい。レイを予定することは、暗黙的に層を定義する。層合成ルールにおける式は、レイを予定する時に提供されるファクタを参照できる。例えば、次の通りである。
【０３３９】
Imagel = diffuse + reflectionFactor * reflection
シェイダーがレイトレーシングの結果に直接作用する必要があり、後の合成のためにレイを予定できない場合もある。そのような場合には、同期レイトレーシング関数が依然として利用できる。
シェイダーパラメータは、グラフィカルユーザーインタフェース（GUI）を使用するアプリケーションにおいてユーザーが設定することがよくある。ユーザーがGUIにおけるシェイダーと相互作用するためには、アプリケーションは、シェイダーパラメータと、シェイダーそれ自身についてのいくつかの追加的情報を知る必要がある。
【０３４０】
シェイダーソースコードに注釈を書き込むことにより、情報属性をシェイダー、パラメータ、または技術に付加することができる。注釈は、シェイダー、パラメータ、または技術宣言の直後に、属性のリストを曲線括弧で囲むことにより置く。属性インスタンスは、コンストラクタへ渡されるオプションのパラメータにより、同様なメソッドでクラスに宣言される。構文は次のようである。
【０３４１】
{
attribute_name(paraml, param2, ... );
attribute_name(paraml, ... );
}
属性コンストラクタへのパラメータは、状態変数をデフォルト値として割り当てる特別な場合を除いて、直定数でなければならない。いくつかの標準属性は予め定義されている。
【０３４２】
・default value (object value)−パラメータに対するデフォルト値を指定するためにパラメータに付加される。
−value−パラメータに対するデフォルトとして使用される値。この値のタイプは、パラメータと同じタイプである。
・soft range (object min, object max)−パラメータに対する有効な値の範囲を指定する。この範囲は、ユーザーが所望するのであれば超えることができる。
【０３４３】
−min−範囲の下端。この値のタイプは、パラメータのタイプと同じである。
−max−範囲の上端。この値のタイプは、パラメータのタイプと同じである。
・hard range (object min, object max)−超えることができないパラメータに対する境界を指定する。
−min−範囲の下端。この値のタイプは、パラメータのタイプと同じである。
【０３４４】
−max−範囲の上端。この値のタイプは、パラメータのタイプと同じである。
・display name (string name)−ユーザーに表示すべきシェイダー、パラメータ、または技術の名前。
−name−表示名。これは、典型的な変数名よりももっと読み易い名前であってよく、スペースを含むことができる。
【０３４５】
・description (string description)−シェイダー、パラメータ、または技術の記述。
−description−記述。アプリケーションはこの文字列を使用してGUIにツールチップを提供できる。
・hidden−パラメータに付加され、パラメータがアプリケーションGUI内で示されてはいけないことを示す。この属性はパラメータを有しない。属性が存在するときは、パラメータは、隠されていると考えられるか、または隠されない。
【０３４６】
・enum label (int value, string label)−enumタイプであるパラメータに付加される。この属性の２つ以上のインスタンスが、可能なenum値に対して１つずつ、enumタイプのパラメータに付加される可能性がある。
−value−パラメータが設定される可能なenum値の１つ。
−label−enum値をGUIにおけるオプションとして提示するときに使用するラベル。
【０３４７】
これらの属性と他のGUI関連の属性は、外部ファイルを介してシェイダーに割り当てることができる。シェイダーソースコードを多数の注釈で一杯にすることは常には望ましいこととはいえない。
下記は、使用中の属性の例である。
shader mix_colors {
input:
Color colorl {
default_value(Color(0,0,0,1));
display_name("Color 1");
};
Color color2 {
default_value(Color(1,1,1,1));
display_name("Color 2");
};
Scalar mix {
default_value(0.5);
soft_range(0.0, 1.0);
display_name("Mix amount");
}; 
output:
Color result;
void main() { 
result = colorl*(1.0-mix) + color2*mix;
}
} { Description("Blends two colors using a mix amount parameter") };
下記のキーワードは、現在は、MetaSL内では使用されていないが、将来のバージョンのために保存されている。class, const, private, protected, public, template, this, typedef, union, virtual。
【０３４８】
MetaSLは、固有関数の標準ライブラリを含む。下記は、本発明の範囲を逸脱することなく拡張でき、ソフトウェアのみの方法を含まない、照明関数およびレイトレーシング関数を含むリストである。
・数学的関数：abs, acos, all, any, acos, asin, atan, ceil, clamp, cos, degrees, exp, exp2, oor, frac, lerp, log, log2, log10, max, min, mod, pow, radians, round, rsqrt, saturate, sign, sin, smoothstep, sqrt, step, tan。
【０３４９】
・幾何学的関数：cross, distance, dot, faceforward, length, normalize, reflect, refract。
・テクスチャマップ関数：texture lookup。テクスチャ関数は、ソフトウェアおよびハードウェアシェイダーの統合に対して興味ある問題を投げかける。ハードウェアテクスチャ関数は、普通は、いくつかのバージョンがあり、それにより投影テクスチャリング（projective texturing）（wによる分割が「texture lookup」に構築される）、明示的フィルタ幅（explicit filter width）、深度比較を有する深度テクスチャルックアップ（depth texture lookup with depth compare）を可能としている。CgもまたテクスチャルックアップのRECTバージョンを有し、正規化座標の代わりに、テクスチャのピクセル座標を使用する。このように、関数はハードウェアとソフトウェアの両者に提供される。しかし、楕円フィルタ処理（elliptical filtering）を有するソフトウェアのみのテクスチャルックアップを提供することが望ましい。
【０３５０】
・導関数：ddx, ddy, fwidth。
図６７は、本発明の更なる形態によるMetaSLコンパイラのアーキテクチャ８３０を例示する図を示している。MetaSLコンパイラは、MetaSLシェイダーのターゲットフォーマットへの変換、およびシェイダーグラフを単一のシェイダーにコンパイルすること、の両者を扱う。MetaSLコンパイラのアーキテクチャは、プラグインにより拡張可能で、それにより、異なる入力構文と共に、将来の言語ターゲットをサポートすることが可能になる。
【０３５１】
コンパイラフロントエンドは、異なる入力言語をサポートする、プラグイン可能なパーサーモジュールをサポートする。MetaSLが主要な入力言語と期待されているが、他の言語を拡張によりサポートすることも可能である。これにより、例えば、シェイダーが書かれた言語に対するパーサーが作成されれば、シェイダーの既存のコードベースを利用することが可能になる。
【０３５２】
コンパイラバックエンドもまた、プラグインモジュールにより拡張可能である。MetaSLコンパイラは、多くの処理を扱い、バックエンドプラグインに高いレベルのシェイダーの表現を提供し、シェイダーコードを生成するために使用できる。現在使用されている、いくつかの言語およびプラットフォームに対するサポートが計画されているが、将来、新しいプラットフォームが現れることはほぼ確実である。ミル技術の主な利点は、シェイダーをこれらの変更から隔離することである。新しいプラットフォームまたは言語が利用できるようになると、新しいバックエンドプラグインモジュールを、これらのターゲットをサポートするために実装できる。
【０３５３】
MetaSLコンパイラは、現在、高いレベルの言語を目標としているが、GPUを直接目標として、高レベルの表現からマシンコードを生成する可能性も存在する。これにより、コードジェネレータが、この高レベル表現から直接機能し、固有コンパイラを迂回するという理由で、特別なハードウェアは、利用できる固有の最適化を利用できる。
ミルのMetaSLコンパイラの別の構成要素は、フェノメノンフェノメノンシェイダーグラフ・コンパイラである。グラフ・コンパイラは、シェイダーグラフを処理し、それらを単一のシェイダーにコンパイルする。これらのシェイダーは、シェイダーアタッチメントのオーバーヘッドを回避し、それにより、少数の複雑なノードではなく、より多数の単純なノードからグラフを構築することが可能になる。これは、シェイダーの内部構造を、専門的なプログラマでないユーザーに対してよりアクセスし易くする。
【０３５４】
図６８は、本発明の代替形態による、MetaSLコンパイラのアーキテクチャ８４０を例示する図を示している。
下記の例は、MetaSLに実装されたフォンシェイダーを示している。
shader Phong { 
input:
Color ambience; 
Color ambient;
Color diffuse;
Color specular;
Scalar exponent; 
output:
Color result;
void main() {
result = ambience * ambient; 
Light_iterator light;
foreach(light) {
result += light.color * max(0, light.dot_nl);
result += light.color * specular * 
phong_specular(light.direction, exponent); 
}
}
};
この例でコールされたphong_specular関数は、MetaSLにより提供された内蔵関数である。表面法線およびレイ方向のような状態パラメータは、暗黙的に関数に渡される。
【０３５５】
下記の例は、MetaSLに実装された簡単なチェッカーテクスチャシェイダーを示している。
shader Checker {
Input:
Color colorl;
Color color2;
Vector2 coords; 
Vector2 size;
output:
Color result;
void main() {
Vector2 m = fmod(abs(coords), size)/size;
Vector2b b = m < 0.5f;
result = lerp(colorl, color2, b.x ^^ b.y);
}
};
【０３５６】
Ｄ．MetaSLシェイダーデバッガ
ここで、イメージベースのシェイダーデバッグの概念のインプレメンテーションを提供する、メンタルミルMetaSLシェイダーデバッガアプリケーションを説明する。
【０３５７】
図６９は、本発明の更なる形態によるデバッガUI８５０のスクリーンショットを示している。シェイダーデバッガUI８５０は、現在ロードされているシェイダーに対するMetaSLコードを表示するコードビューパネル８５２と、選択されたステートメントにおける範囲ですべての変数を表示する変数リストパネル８５４と、選択された変数の値、または変数が選択されていないときは、シェイダー全体の結果を表示する３Dビューウィンドウ８５６を備える。さらに、エラー表示ウィンドウ８５８も備える。
【０３５８】
図７０は、シェイダーをロードするときに現れるデバッガUI８６０のスクリーンショットを示しており、コンパイルエラーがあると、それらは、エラー表示ウィンドウ８６８に一覧表示される。リストにおいてエラーを選択すると、エラーが現れたコード８６２のラインが強調表示される。シェイダーファイルは、F5キーを押すことにより再ロードされる。
【０３５９】
図７１は、シェイダーがいったん首尾よくロードされ、エラーなくコンパイルされると現れる、デバッガUI８７０のスクリーンショットを示している。デバッグは、コードビューパネル８７４内のステートメント８７２を選択することにより開始される。選択されたステートメントは、選択されたステートメントのラインに沿って、明るい緑色で強調表示される。変数ウィンドウは、選択されたステートメントに対する範囲の変数８７６を表示する。
【０３６０】
図７１に示されるように、ステートメントは、変数上のコードクリックのライン上でクリックすることで選択され、その値をレンダーウィンドウに表示する。図７１のスクリーンショット８７０においては、「normal」変数（Vector3タイプ）が選択されている。ベクトル値は、それぞれのカラーにマップされる。ステートメントであるラインは、白い背景を有する。ステートメントでないラインは灰色である。
【０３６１】
図７２は、デバッガスクリーン８８０のスクリーンショットを示しており、条件ステートメントとループがどのように扱われるかを例示している。条件ステートメントとループは、いくつかのデータ点に対しては実行されず、従って、選択されたステートメントが条件クローズであるときは、変数は、あるデータ点に対しては、見ることができない。
図７２に示されるように、選択されたステートメント８８２が条件ステートメントであるときは、条件値が真であるピクセル８８４のみがデバッグ値を表示する。残りのピクセルは元の結果を表示する。
【０３６２】
図７３は、デバッガスクリーン８９０のスクリーンショットを示しており、選択されたステートメントがループにあるときに何が起こるかを例示している。その場合は、表示された値は、ループを介する第１パスを表現している。ループカウンタを追加して、ユーザーがループを介してどのパスをデバッグしたいかを指定できるようにすることも可能である。
【０３６３】
ユーザーは、左右の矢印キーを使用して、コードのラインを前後に移動することにより、ステートメントを進むことができる。アップおよびダウン矢印キーは、変数リスト中を移動する。
スペースバーは、ビューポートにおけるサンプルオブジェクトタイプ内を循環する。
図７４は、デバッガスクリーン９００のスクリーンショットを示し、テクスチャ座標がどのように扱われるかを示している。ユーザーは、この例に示されるように、テクスチャ座標を選択して見ることができる。プロトタイプは、テクスチャ座標の４つのセットを提供し、それぞれは、以前のセットの２倍多い回数だけ並べて表示されている。UとVの導出ベクトルもまた供給される。
【０３６４】
ベクトル値がカラーにマップされると、その値が１を超えると、ラップするように設定される。この例においては、選択されたテクスチャ座標は、４回繰り返され、それはデバッガにおける変数９０２を見るときに明確に見ることができる。
図７４において、テクスチャ座標のセットは、２倍のタイリングで利用できる。
図７５は、デバッガスクリーン９１０のスクリーンショットを示しており、視差のマップにより、テクスチャ座標を変形することにより深度のイリュージョンが生成されている。図７６のスクリーンショット９２０において、テクスチャ座標のオフセットは、デバッガにおけるテクスチャ座標を見ると、明確に見ることができる。
【０３６５】
図７７と７８は、デバッガスクリーン９３０と９４０のスクリーンショットであり、他のシェイダーを例示している。
・結論
上記の記述は、本発明の特別な実施形態に限定されてきた。しかし、種々の変形および修正が、本発明に対してなされ、本発明の利点のいくつかまたはすべてを得ることができるということは明白であろう。付随する請求項の目的は、これらと、他の変形例および修正例を、本発明の真の精神および範囲に含まれるものとしてカバーすることである。
【図面の簡単な説明】
【０３６６】
【図１】パッケージ化およびカプセル化され、それぞれが１つまたは２つ以上のシェイダーを含み、シェイダーDAGにおけるシェイダーがレンダリング中に正しく協働できることを保証するように生成され、本発明に従って構築されるシェイダーDAGの生成を容易にすることで、シェイダー間の強化された協働を提供するコンピュータグラフィックシステムを示している。
【図２】図１に示されたコンピュータグラフィックシステムの機能ブロック図である。
【図３】その機能ブロック図を図２に示した、コンピュータグラフィックシステムにおいて使用されるフェノメノンクリエータの１つの実施の形態に対するグラフィカルユーザーインタフェースを示している。
【図４】図２および図３に示されたフェノメノンクリエータを使用して生成された実例としてのフェノメノンを図示している。
【図５】その機能ブロック図を図２に示した、コンピュータグラフィックシステムにおいて使用されるフェノメノンエディターの１つの実施の形態に対するグラフィカルユーザーインタフェースを示している。
【図６】Ａ及びＢは、図５に示されたグラフィカルユーザーインタフェースの詳細を示している。
【図７】図７は、シーンのイメージを生成する際の、図２に示されたコンピュータグラフィックシステムの、シーンイメージ生成部により行なわれる操作を示すフローチャートを示している。
【図７Ａ】図７Ａは、シーンのイメージを生成する際の、図２に示されたコンピュータグラフィックシステムの、シーンイメージ生成部により行なわれる操作を示すフローチャートを示している。
【図８】本発明の１つの形態による全体の方法のフローチャートを示している。
【図９】メンタルミルのプラットフォーム独立性を例示するソフトウェアの層の図を示している。
【図１０】サブセットとしてのMetaSLのレベルのイラストを示している。
【図１１】MetaSLのレベルと、ハードウェアおよびソフトウェアレンダリングに対するその適用性を例示する棒状図を示している。
【図１２】グラフィカル性能分析ウィンドウのスクリーンショットを示している。
【図１３】特別入力パラメータの値の範囲に関する性能結果の棒グラフを示している。
【図１４】性能結果が表形式で表示されるスクリーンビューを示している。
【図１５】メンタルミルライブラリの主要カテゴリを例示する、ライブラリモジュールの図を示している。
【図１６】メンタルミル・コンパイラ・ライブラリの図を示している。
【図１７】メンタルミルに基づくレンダラーの図を示している。
【図１８】フェノメノングラフエディタのスクリーンビューを示している。
【図１９】フェノメノングラフエディタおよび統合MetaSLグラフィカルデバッガの操作を例示する一連のスクリーンショットを示している。
【図２０】フェノメノングラフエディタおよび統合MetaSLグラフィカルデバッガの操作を例示する一連のスクリーンショットを示している。
【図２１】フェノメノングラフエディタおよび統合MetaSLグラフィカルデバッガの操作を例示する一連のスクリーンショットを示している。
【図２２】フェノメノングラフエディタおよび統合MetaSLグラフィカルデバッガの操作を例示する一連のスクリーンショットを示している。
【図２３】フェノメノングラフエディタおよび統合MetaSLグラフィカルデバッガの操作を例示する一連のスクリーンショットを示している。
【図２４】シェイダーパラメータエディタの図を示している。
【図２５】Ａ及びＢは、それぞれ、フェノメノン／メタノードライブラリエクスプローラのサムネールビューおよびリストビューを示している。
【図２６】コードエディタおよびIDEの図を示している。
【図２７】Ａ〜Ｃは、ピクセル位置における変数に対する数値が、マウス位置に基づいて表示されている、デバッガスクリーンの一連の図を示している。
【図２８】GUIライブラリアーキテクチャの図を示している。
【図２９】BRDFシェイダーを実装するために必要なメソッドを一覧表示した表０１０１を示している。
【図３０】２つのBRDFが混合されている例としての構成の図を示している。
【図３１】取得したBRDFによるシェイディングのためのパイプラインを例示する図である。
【図３２】GUIの基本的なレイアウトのスクリーンショットを示している。
【図３３】グラフノードの図を示している。
【図３４】サブパラメータの構造を含む、グラフノードの図を示している。
【図３５】フェノメノンの内部のサンプルグラフビューを示している。
【図３６】フェノメノンが定位置において開かれたときのサンプルグラフビューを示している。
【図３７】フェノメノンが、別のフェノメノン内で開かれたときのサンプルグラフビューを示している。
【図３８】カラー出力をスカラー入力に付加した結果を例示する図を示している。
【図３９】新しいフェノメノンノードへ箱詰めされたシェイダーを例示する図を示している。
【図４０】サンプルシェイダーグラフを見るための鳥瞰図コントロールを示している。
【図４１】Ａ〜Ｄは、詳細のノードレベルの進行を例示する一連の図を示している。
【図４２】Ａ及びＢは、サムネールビューとリストビューにおけるツールボックスを示している。
【図４３】選択されたノードのパラメータを編集可能にするコントロールを表示するためのパラメータビューを示している。
【図４４】MetaSLのユーザーが、コードを書くことによりシェイダーを作成できるようにするコードエディタの図を示している。
【図４５】２つのメタノードを第３のメタノードにする組み合わせを例示する図を示している。
【図４６】変数リストの一部の図を示している。
【図４７】Ａ〜Ｃは、ユーザーがマウスをイメージ表面上でドラッグするとき、ベクトルが、イメージ表面上に位置する矢印として描かれる視覚化技術を例示する一連の図を示している。
【図４８】マトリックスに対する視覚化技術を例示する図を示している。
【図４９】３方向のベクトルに対する視覚化技術を例示する図を示している。
【図５０】ゲージスタイルディスプレイを使用して、ベクトルタイプ値を見るための視覚化技術を例示する図を示している。
【図５１】Evnet_typeパラメータとその説明を一覧表示する表を示している。
【図５２】ベクトル構築メソッドの結果を例示する表を示している。
【図５３】ブーリアン（Boolean）演算子を記述する表を示している。
【図５４】比較演算子を一覧表示する表を示している。
【図５５】バンプマップ（bump map）フェノメノンの模式図を示している。
【図５６】使用中のバンプマップフェノメノンを例示する図を示している。
【図５７】本発明の更なる形態による、バンプマップフェノメノンの模式図を示している。
【図５８】使用中のバンプマップフェノメノンの図を示している。
【図５９Ａ】状態変数のセットを一覧表示する表を示している。
【図５９Ｂ】状態変数のセットを一覧表示する表を示している。
【図６０】変換マトリックスを一覧表示する表を示している。
【図６１】照明シェイダー状態変数を一覧表示する表を示している。
【図６２】ボリュームシェイダー状態変数を一覧表示する表を示している。
【図６３】Trace_optionsクラスのメソッドを一覧表示する表を示している。
【図６４】インターセクション状態の一部として提供され、状態変数を介してアクセスできる値に依存する機能を一覧表示する表を記述している。
【図６５】インターセクション状態の一部として提供され、状態変数を介してアクセスできる値に依存する機能を一覧表示する表を記述している。
【図６６】Light_iteratorクラスのメンバーを一覧表示する表を示している。
【図６７】MetaSLコンパイラの図を示している。
【図６８】本発明の代替の形態による、MetaSLコンパイラの図を示している。
【図６９】本発明の更なる形態による、デバッガスクリーンのスクリーンショットを示している。
【図７０】シェイダーをロードするときに、コンパイルエラーがあった場合のデバッガスクリーンのスクリーンショットを示している。
【図７１】シェイダーがいったん首尾よくロードされ、エラーなくコンパイルされ、その時点でデバッグがステートメントを選択することにより開始できるときのデバッガスクリーンのスクリーンショットを示している。
【図７２】選択されたステートメントが条件付であるときのデバッガスクリーンのスクリーンショットを示している。
【図７３】選択されたステートメントがループにあるときのデバッガスクリーンのスクリーンショットを示している。
【図７４】テクスチャ座標が見える、デバッガスクリーンのスクリーンショットを示している。
【図７５】視差のマッピングが、テクスチャ座標を変形することにより深度のイリュージョンを生成する、デバッガスクリーンのスクリーンショットを示している。
【図７６】テクスチャ座標のオフセットが、デバッガのテクスチャ座標を見るときに見ることができる、デバッガスクリーンのスクリーンショットを示している。
【図７７】他のシェイダーの例を例示するデバッガスクリーンのスクリーンショットを示している。
【図７８】他のシェイダーの例を例示するデバッガスクリーンのスクリーンショットを示している。
【図１】
2009500730.tif 000003
【図２】
2009500730.tif 000004
【図３】
2009500730.tif 000005
【図４】
2009500730.tif 000006
【図５】
2009500730.tif 000007
【図６】
2009500730.tif 000008
【図７】
2009500730.tif 000009
【図７Ａ】
2009500730.tif 000010
【図８】
2009500730.tif 000011
【図９】
2009500730.tif 000012
【図１０】
2009500730.tif 000013
【図１１】
2009500730.tif 000014
【図１３】
2009500730.tif 000015
【図１４】
2009500730.tif 000016
【図１５】
2009500730.tif 000017
【図１６】
2009500730.tif 000018
【図１７】
2009500730.tif 000019
【図１８】
2009500730.tif 000020
【図２４】
2009500730.tif 000021
【図２５】
2009500730.tif 000022
【図２６】
2009500730.tif 000023
【図２８】
2009500730.tif 000024
【図２９】
2009500730.tif 000025
【図３０】
2009500730.tif 000026
【図３１】
2009500730.tif 000027
【図３２】
2009500730.tif 000028
【図３３】
2009500730.tif 000029
【図３４】
2009500730.tif 000030
【図３５】
2009500730.tif 000031
【図３６】
2009500730.tif 000032
【図３７】
2009500730.tif 000033
【図３８】
2009500730.tif 000034
【図３９】
2009500730.tif 000035
【図４０】
2009500730.tif 000036
【図４１】
2009500730.tif 000037
【図４２】
2009500730.tif 000038
【図４３】
2009500730.tif 000039
【図４４】
2009500730.tif 000040
【図４６】
2009500730.tif 000041
【図５１】
2009500730.tif 000042
【図５２】
2009500730.tif 000043
【図５３】
2009500730.tif 000044
【図５４】
2009500730.tif 000045
【図５５】
2009500730.tif 000046
【図５６】
2009500730.tif 000047
【図５７】
2009500730.tif 000048
【図５８】
2009500730.tif 000049
【図５９Ａ】
2009500730.tif 000050
【図５９Ｂ】
2009500730.tif 000051
【図６０】
2009500730.tif 000052
【図６１】
2009500730.tif 000053
【図６２】
2009500730.tif 000054
【図６３】
2009500730.tif 000055
【図６４】
2009500730.tif 000056
【図６５】
2009500730.tif 000057
【図６６】
2009500730.tif 000058
【図６７】
2009500730.tif 000059
【図６８】
2009500730.tif 000060
【図１２】
2009500730.tif 000061
【図１９】
2009500730.tif 000062
【図２０】
2009500730.tif 000063
【図２１】
2009500730.tif 000064
【図２２】
2009500730.tif 000065
【図２３】
2009500730.tif 000066
【図２７】
2009500730.tif 000067
【図４５】
2009500730.tif 000068
【図４７】
2009500730.tif 000069
【図４８】
2009500730.tif 000070
【図４９】
2009500730.tif 000071
【図５０】
2009500730.tif 000072
【図６９】
2009500730.tif 000073
【図７０】
2009500730.tif 000074
【図７１】
2009500730.tif 000075
【図７２】
2009500730.tif 000076
【図７３】
2009500730.tif 000077
【図７４】
2009500730.tif 000078
【図７５】
2009500730.tif 000079
【図７６】
2009500730.tif 000080
【図７７】
2009500730.tif 000081
【図７８】
2009500730.tif 000082