シーングラフ中のパラメータのアクセス性および制御のための方法およびシステム
シーングラフ内のパラメータへのアクセスおよびその制御を提供する方法およびシステムが、シーングラフ内のコンポーネントまたはノードの意味内容を再定義することを含む。コンポーネントまたはノードのセット（シーングラフ構造に依存する）は、選択されたシーングラフ情報へのアプリケーション・ユーザー・インターフェースからのアクセスを可能にするために要求される。ある実施形態では、シーングラフ・パラメータを制御するためのユーザー・インターフェースが生成される。さらに、ある種のシーングラフ・パラメータへのアクセスを許容または禁止し、その値の範囲を制約する拘束条件が実装されることができる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、シーングラフに、より詳細にはシーングラフのレンダリングの際のパラメータのアクセス性（accessibility）および制御に関する。
【背景技術】
【０００２】
シーングラフはオブジェクトとも呼ばれるノードからなる階層構造である。ノードはグループ化ノード（grouping nodes）（枝と枝の間の交わり）または葉（leaves）のいずれかでありうる。そのような構造は通例、2Dまたは3Dグラフィック情報（たとえば幾何学的モデル）の保存およびレンダリングするためのその構成として使用される。
【０００３】
シーングラフは、時間的補間手段またはフレーム・ベースのアニメーション（たとえばマクロメディア・フラッシュの場合）のいずれかによって形成されるアニメーション情報を含むことができる。シーングラフはまた、シーンまたは内部に構成されるオブジェクトとの許容されるユーザー対話を表すセンサーをも含むことができる。正しく動作するためには、そのようなアニメーションはフルに記述されなければならず、対話トリガーはシーングラフ内で正しくルーティングされなければならない。
【０００４】
コンピュータ・グラフィックにおけるシーングラフの使用が一般化して数年になる。たいていの3Dオーサリング・ツール（たとえばオートデスク3Dスタジオ（Autodesk 3D Studio）またはマヤ（Maya））および3Dレンダリング・エンジン（たとえばピクサー・レンダーマン（Pixar RenderMan））は内部的に（すなわちそのアプリケーション内で）シーングラフをデータ構造としておよび交換のためのファイル・フォーマットとして使用する（たとえばVRML、COLLADA）。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
シーングラフのレンダリングの際のユーザー・コントロールは、その記述がシーングラフに埋め込まれなければならないという事実のため、比較的限られている。すなわち、残念ながら、現在利用可能な技術においては、シーングラフ内で、あるいはシーングラフのレンダリングの際にアニメーションおよびパラメータについての直接的なアプリケーション・ユーザー・インターフェース・コントロールを定義する簡単な手段はない。
【課題を解決するための手段】
【０００６】
本発明の諸実施形態は、シーングラフのパラメータの制御を可能にする簡単な手段と、アプリケーション・レベルでそれらのコントロールを扱い、それをユーザーに呈示する方法とを提供する。本発明の諸実施形態はまた、値の範囲、増分、デフォルトおよびある種のコントロールを許容するまたはしないことについてのユーザー・プロファイルもしくはプラットフォーム・プロファイルを使って、ユーザー対話についての制約の定義をも可能にする。
【０００７】
本発明のある実施形態では、シーングラフを制御する方法は、シーングラフ内で要素の集合を再定義し、再定義された要素に従ってシーングラフ内の選択された情報にアクセスし、選択された情報を制御する手段を提供することを含む。
【０００８】
本発明の代替的な実施形態では、シーングラフを制御するシステムは、シーングラフ内の要素の集合を再定義する手段と、再定義された要素に従ってシーングラフ内の選択された情報にアクセスするための手段と、選択された情報を制御する手段とを含む。
を含む。
【０００９】
本発明の教示は、以下の詳細な記述を付属の図面とともに考慮することによって容易に理解されうる。
【図面の簡単な説明】
【００１０】
【図１】本発明のある実施形態に基づく、シーングラフ・パラメータの制御を可能にするためのプロセスの流れ図である。
【図２】本発明のある実施形態に基づく、シーングラフおよび対応するコントロールのグラフィックな表現を描いた図である。
【図３】本発明のある実施形態に基づく、シーングラフ中のパラメータのアクセス性および制御のための方法の流れ図である。
【図４】本発明のある実施形態に基づく、図３の方法の再定義ステップの流れ図である。
【図５】本発明のある実施形態に基づく、図４の方法のリンク・ステップの流れ図である。
【発明を実施するための形態】
【００１１】
図面は本発明の概念を例解する目的のためであって、必ずしも本発明を例解する唯一の可能な構成ではないことは理解しておくべきである。理解を助けるため、可能なところでは、諸図面に共通する同一の要素を示すために同一の参照符号が使われている。
【００１２】
シーングラフ記述のために多くの規格が定義されている。それには、VRML（Virtual Reality Modeling Language［仮想現実感モデリング言語］）、X3D（eXtensible 3D［拡張可能3D］）、MPEG-4システム、COLLADAおよびJava（登録商標）3Dが含まれる。そのような規格はテキスト表現またはXMLを使用する。さらに、いくつかの独自規格も存在している（たとえば、マイクロソフトDirectXフォーマット、NVIDIA NVSGなど）。しかしながら、これらの表現のいずれにおいても、ユーザー対話を可能にする主たる手段は、すべての対話（センサー）および振る舞いをシーングラフ内に統合してモデル全体を上位構造に埋め込む（たとえば、VRML／X3Dにおけるプロトタイプ）か、あるいはシーングラフ・アプリケーション・インターフェース（VRMLではEAI（External Application Interface［外部アプリケーション・インターフェース］、X3DではSAI（Scene Access Interface［シーン・アクセス・インターフェース］）と称され、DirectXは前記マイクロソフトのフォーマット用インターフェースであり、MPEG-JはMPEG-4システムにおけるインターフェースである）を使って特定のアプリケーションを開発することである。
【００１３】
最初に挙げた解決策におけるようにシーングラフ内での対話および制御全体を記述することは、シーングラフのためのレンダリング・エンジンがアニメーションおよび対話イベントを処理するための実行エンジンを含むことを要求する（VRMLハンドブックの記載を参照）。これは、これらの場合におけるアプリケーション・ユーザー・インターフェースがシーングラフの知識を持たないからである。よって、シーングラフからデータを抽出するため、そして該データへのアクセスをユーザーに与えるためには、固有のソース・コードが開発されなければならない。上記の第二の解決策はVRML/X3Dにおいて定義されるようなプロトタイプを使うことを含む（VRMLハンドブックを参照）。VRMLハンドブックに記載されるように、この解決策は、「オブジェクトに対して何ができるかを制限することを作者に許容する保護機構」である。しかしながら、問題は、この「プロトタイプ・ノード」技法が：１）プロファイル管理；２）パラメータの値の簡単な制限（可能な唯一の方法はこの場合スクリプトを使うことである）を許容せず；３）フィールドを制御するためのユーザー・インターフェースを作成するための簡単な包含を提供しないということである（すなわち、実行エンジン内でイベントを処理するための識別子名のほかはパラメータに与えられる実名がなく、プロトタイプ技法はシーングラフ内の、ユーザーではなくオブジェクト（ノード）間の対話において助けるのみである）。さらに、この技法を使うことは、新しいパラメータの単純な追加がユーザーに呈示されることを許容しない。というのも、「プロトタイプ・ノード」は実際のシーングラフ構造をユーザーから隠すからである。
【００１４】
上記の第三の技法は、SAIのためのX3D仕様のようなシーングラフ・アクセス・インターフェース（Scenegraph Access Interface）（SAI）を使う。ここでこの技法は、シーングラフ情報へのアクセスを得るために特定のユーザー・インターフェースを開発することである。この技法は、シーングラフのどのメンバーへのアクセスをも許容する。しかしながら、すべてのフィールドへのアクセスはユーザーがシーングラフ構造全体を知っていて、そのすべての構造要素（ノード、フィールド等）の知識をもたなければならないということを意味する。さらに、その文法的な構成の名前のために、シーングラフ中の名前はユーザーにとって十分明快でないことがありうる。たとえば、スペース文字は許容されない。
【００１５】
本発明の諸実施形態は、実装が選ばれたシーングラフ・ファイル・フォーマット文法に合致する限り、いかなる既存のシーングラフ記述言語（たとえばテキストまたはXML）に適用されることもできる。その際、本発明の特徴を許容してまたは許容せずに本願の原理によって定義されたノードを扱うか扱わないかをパーサー〔構文解析器〕が決定できる。本アプリケーションはまた、本願の原理によって定義されたユーザー・インターフェースのコントロールを表示しないことを選ぶこともできる。たとえば、本発明の新しい特徴を扱わないことは、すべてのノードが、時にブラケット（たとえば「｛」および「｝」）またはXMLタグ・ブラケット（たとえば「＜ノード＞」および「＜／ノード＞」）として表現される境界をもつので、パース側では非常にストレートなことであろう。その際、パーサーはそのブラケットに限定されたシーングラフ内の完全な特徴宣言を無視するだけでよい。
【００１６】
本発明の諸実施形態は、もとのシーングラフ記述を修正することなくアプリケーション・ユーザー・インターフェースから選択されたシーングラフ情報へのアクセスを可能にするために必要とされる追加的なコンポーネントまたはノードのセット（シーングラフ構造に依存する）を含む。新しいコンポーネントまたはノードは、目標とされるシーングラフ情報のセマンティック〔意味内容〕を、ユーザーに呈示可能となるよう、たとえばユーザー・インターフェース上での理解可能な名前および修飾子をもって再定義することを可能にする。その際、この情報は、グラフィカル・ユーザー・インターフェースを通じてユーザーに提供される、新たに生成されたグラフィカル・インターフェースのウィジェットを通じて制御されることができる。
【００１７】
たとえば、本発明のある実施形態では、特徴識別子は、シーングラフ文法に準拠して定義された対応する閉じブラケットと開きブラケットをもって表現されることができる。さらに、プロファイル識別子は、そのプロファイルを記述する文字列または識別子のリストによって表現されることができる。プロファイルは、たとえばアクセス権を記述してユーザーを、あるいは機能および／またはプロファイルを記述してプラットフォームを含むことができる。これらのプロファイル識別子文字列の包含は、アプリケーション依存であることができ、あるいは名前記述または数値であることができる。この文字列のリストが空であれば、すべての定義されたコントロールは全ユーザーまたはプラットフォームに利用可能となるであろう。しかしながら、本発明の代替的な実施形態のある種の実装は、この情報を全く使わなくてもよく（すなわち、デコーダSTB（セットトップボックス）のようなプラットフォーム上にプロファイルが存在しない事例）、一方、他の実施形態は本アプリケーション中の別個のレイヤーでプロファイルを管理することができる（すなわち、切換器のようなプラットフォーム中の静的プロファイルの場合）。本発明の諸実施形態はさらに、そのそれぞれについて、シーングラフ中の制御される項目のリストを含むことができる。
【００１８】
シーングラフ中の識別子（identifier）は、シーングラフ中の目標とされる情報を定義する文字列または識別子のリストを含み、通例、ノードの名前定義または識別子と、制御されるべきノードのフィールドの名前または識別子とからなる。識別子がシーングラフ中の現在のパース・レベルにみつからなければ、その制御は有効にされるべきではない。本アプリケーションは次いで、シーングラフ中でのその定義の結果として、フィールド値型（たとえば浮動小数点、整数）を取得することができる。このフィールドは本質的には、グループ化された修正、たとえば同時にいくつかの色フィールドを単一のユーザー・インターフェース・コンポーネントのもとで許容する文字列のリストである。したがって、リストされるフィールドは同じ型であることが必要である。
【００１９】
本発明の諸実施形態はさらに、アプリケーション・ユーザー・インターフェース上に現れる名前（name）を含むことができる。これは通例、前段落で述べた識別子名とは異なるであろう。通例、シーングラフ中の識別子はシンタックス的に文法において制約されており（スペースや特定の文字なし）、適切な記述を呈示しないことがありうるからである（すなわち、これらの識別子は通例、グラフィック・モデリング・ツールによって自動的に生成される）。
【００２０】
本発明の諸実施形態によれば、リセット（reset）または工場値（factory value）は、ユーザー・インターフェース上で「リセット」または「工場値」ボタンが作動されるときにパラメータを設定するための値を含むことができる。この値は、シーングラフにおける値そのものとは異なっていてもよい。シーングラフは特定の時点での値を記憶するからである。さらに、そのパラメータについて有効な値の範囲を定義する最小値および最大値が含められてもよい。最小値および最大値は、ユーザー・インターフェースのコントロールについての限界を定義する。
【００２１】
本発明の諸実施形態の本アプリケーションは、さらに、たとえば「＋」または「−」ボタンを押すことによってユーザー・インターフェース上でパラメータに（プラスにまたはマイナスに）適用するステップごとの増分（絶対値）に対応するステップ増分（Step Increment）と、このコントロールが有効にされる定義されたプロファイル（Profiles）とを含むことができる。すなわち、このコントロールが有効にされる選択されたプロファイル識別子（たとえば、上に挙げたものまたは他のアプリケーション定義識別子）がここにリストされることができる。
【００２２】
本発明のある実施形態では、すべての値はフィールド型数値領域（domain）において表現される。選ばれたシーングラフがたとえば浮動小数点値およびブーリアン〔ブール値〕を表現するための一般的フィールド型を提供しない場合、それらのパラメータを定義するために最大の領域が使用されることができる。たとえば、浮動小数点表現が使用されることができ、値は整数またはブーリアンとしてキャストされることができる。本発明の諸実施形態によれば、たとえばRGB値（赤、緑および青）をもつ色など、多くのパラメータは二つ以上の要素または成分からなることができるので、すべての値は、数字の配列であることができる。制御されるフィールドをなす要素／成分の数と最小値、最大値、リセット値および増分値に含まれる要素／成分の数とが異なる場合、制御されるフィールド中の要素／成分の数に合致する後者の値についての最小数の要素のみが使われるものとする。たとえば、制御されるフィールドが３成分をもつRGB色を表現し、「リセット」値が「[1.0 1.0 1.0 1.0]」と定義される場合、システムは最初の三つの要素のみを使用し、最後の一つは未使用のままとする。
【００２３】
制御されるフィールドが含まれるノードがシーングラフの実行の際に破壊される場合、このノードにリンクされたユーザー・インターフェースのコントロールも無効にされるか破壊される。本発明の諸実施形態はまた、制御される項目がグループ化されることをも許容する。これは、たとえば「ホイール」から構成される「車」など、ユーザー・インターフェース上のパラメータのリストのグループ化をより自然な仕方で許容する、あるいは情報をユーザーに呈示するためのシーングラフの自然な階層構造のオーバーライドを許容する。
【００２４】
本発明の諸実施形態は、各シーングラフ・モデルに固有な制約があるだけで、いかなる既存のシーングラフ上で実装されることもできる。たとえば、VRML 2.0は一般的なフィールド型を提供せず、最大の領域として「SFFloat」が使用できるのみである。
【００２５】
たとえば、本発明のVRML 2.0ノード実装は次のように表現されることができる：
【００２６】
【表１】
「ControlProfiles」ノードは、プロファイルがアプリケーション・レイヤーで定義される場合は破棄されることができる。
【００２７】
【表２】
「items」フィールドは、「ControlItems」（下記参照）または他の「ControlGroup」ノードのリストを含むことができる。「name」フィールドはユーザーに呈示されるグループ名、たとえば「car〔車〕」を定義する。呈示されている「profiles」フィールドは、「items」リスト中の個々の項目（item）上のプロファイル指定をオーバーライドし、プロファイルがグループ全体を簡単に制御することを許容する。
【００２８】
【表３】
上記の実施形態では、「profiles」リストは、「ControlProfiles」ノードまたはアプリケーション依存値によって定義されるプロファイルのリストを含む。
【００２９】
本発明のある代替的な実施形態では、VRML 2.0実装内のPROTO構造概念が次のように表現できる：
【００３０】
【表４】
本発明のさらなる代替的な実施形態では、本発明のX3Dノード実装が次のように表現できる：
【００３１】
【表５】
図１は、本発明のある実施形態に基づくシーングラフ・パラメータの制御を可能にするためのプロセスの流れ図を描いている。図１のプロセス１００は、本発明の上記の実施形態の制御方法を含むオーサリングまたはモデリング・ツール１０２をもって始まる。ステップ１０３では、コンテンツ・クリエイターが主題となるシーングラフをエクスポートする。シーングラフがコントロールを有効にされていれば、プロセスはステップ１０８に続く。オーサリング／モデリング・ツールがそのような機能性をシーングラフに供給しない場合、あとでコントロールを追加するために特定のモジュールが生成されることができる。たとえば、オーサリング・モデリング・ツール１０２がそのような機能性を供給しない場合、必要なコントロールを追加するために作者はシーングラフ１０４をモジュール１０６にエクスポートする。次いでコントロールをもつシーングラフが有効にされ（１０８）、アプリケーション・ブロック１１０にロードされる。アプリケーション１１２は次いでシーングラフをレンダリング１１４するためにロードし、これでグラフィカル・ユーザー・インターフェース上にコントロールを生成し（１１６）それをユーザーに利用可能にすることができる。
【００３２】
本発明のある実施形態では、アプリケーション１１２は、ユーザー・コントロールを追加するために、直接、コントロール生成モジュール１１６を埋め込むことができる。これは、コンテンツ・クリエイターがシーングラフおよびその対応するコントロールの正しい実行およびレンダリングを検証するために有用であることができる。
【００３３】
図２は、本発明のある実施形態に基づくシーングラフおよび対応するコントロールのグラフィックな表現を描いている。図２の実施形態は、本発明の方法をサポートするアプリケーションによる、シーングラフ２００（この場合、単純な立方体）およびそのコントロール（この場合、単純なRGB色選択）のレンダリングを示している。シーングラフは、VRMLノード実施形態の解釈に関して当該アプリケーションによって生成された、アプリケーション・レンダリング・ウィンドウ２０８上に表示された白の背景２０２、淡青の立方体２０６と、コントロール・ウィンドウ２０４とを含む。図２で使われているシーングラフの例は、プロファイルを無効にしてVRML 2.0シーングラフを使って書かれる。本発明のある実施形態によれば、そのシーングラフのVRML 2.0記述は次のように表現できる：
【００３４】
【表６】
上の例に描かれるように、アプリケーション１１２は、コントロール項目（Control Item）を使用して、コントロール・グループ（Control Group）「Cube〔立方体〕」からの名前「Color〔色〕」と、VRML 2.0規格では型がSFColorである「MAT」ノードの一部であるシーングラフ・フィールド「diffuseColor」との間の結び付きを確立し、そうして機能的に所望されるコントロール（すなわち、赤、緑および青の色レベルについての３つの編集可能なフィールド）をサポートする。これは、図２において、個々のR、G、Bコントロールが示されているコントロール・ウィンドウ２０４によって示されている。
【００３５】
図３は、本発明のある実施形態に基づく、シーングラフ内のパラメータのアクセス性および制御の方法の流れ図を描いている。図３の方法３００は、シーングラフ内の要素のセットが初期に再定義されるステップ３０２において始まる。本方法は次いでステップ３０４に進む。
【００３６】
ステップ３０４では、ひとたび再定義されると、シーングラフ内の選択された情報が再定義された要素に従ってアクセスされる。本方法は次いでステップ３０６に進む。
【００３７】
ステップ３０６では、選択された情報がアクセスされたとき、選択された情報を制御するための手段が提供される。
【００３８】
図４は、本発明のある実施形態に基づく図３の方法３００の再定義ステップ３０２の流れ図を描いている。図３の方法３００において定義された要素を再定義するために、最初に、コントロールが提供されるべき要素のセットがステップ３１０で識別される。ステップ３１２で、ひとたび識別されたら、追加的な制御情報が識別された要素のセットに対応して、シーングラフ中の既存の構造にリンクされる。
【００３９】
図５は、本発明のある実施形態に基づく、図４の方法のリンクするステップ３１２の流れ図を描いている。図５の実施形態では、追加的情報をリンクするため、ステップ３２０における、シーングラフ内でのコンポーネントまたはノードの存在の初期探索がある。次いでステップ３２２では、制御されるべき情報がそのコンポーネントまたはノードの一部であるかどうかが判定される。ひとたびこの判定がなされたら、ステップ３２４で、シーングラフにおいて使用されている標準的な文法から情報データ型のもう一つの判定がなされる。ステップ３２５では、上記の判定がすべてなされており、前記データの型およびポイントが、ユーザー・イベントを受け取るために本アプリケーション中に記憶されることができる。
【００４０】
上記において特定の仕方に言及することなく、あるいは一つの仕方を使ってのみ記載されているとしても、さまざまな側面、実装および特徴が多様な仕方のうちの一つまたは複数において実装されうる。たとえば、さまざまな側面、実装および特徴は、たとえば方法、装置、方法を実行するための装置もしくは処理デバイス、プログラムもしくはその他の命令の集合、プログラムもしくは命令の集合を含む装置およびコンピュータ可読媒体のうちの一つまたは複数を使って実装されてもよい。
【００４１】
装置はたとえば、ばらばらなまたは統合されたハードウェア、ファームウェアおよびソフトウェアを含んでもよい。一例として、装置はたとえば、プロセッサを含んでいてもよい。プロセッサとは、たとえばマイクロプロセッサ、集積回路またはプログラム可能な論理デバイスを含む処理装置一般をいう。もう一つの例として、装置は、一つまたは複数のプロセスを実行するための命令を有する一つまたは複数のコンピュータ可読媒体を含んでいてもよい。
【００４２】
コンピュータ可読媒体は、たとえば、ソフトウェア担体または他の記憶デバイスを含んでいてもよい。他の記憶デバイスはたとえば、ハードディスク、コンパクト・ディスケット、ランダム・アクセス・メモリ（「RAM」）または読み出し専用メモリ（「ROM」）といったものである。コンピュータ可読媒体はまた、たとえば命令をエンコードまたは伝送するフォーマットされた電磁波を含んでいてもよい。命令はたとえば、ハードウェア、ファームウェア、ソフトウェアまたは電磁波の形であってもよい。命令はたとえば、オペレーティング・システム、別個のアプリケーションまたは両者の組み合わせにおいて見出されてもよい。したがって、プロセッサは、プロセスを実行するよう構成された装置およびプロセスを実行するための命令を有するコンピュータ可読媒体を含む装置の両方として特徴付けされることができる。
【００４３】
シーングラフ内のパラメータへのアクセスおよびその制御を提供するための方法およびシステムのための好ましい実施形態（これは限定するものではなく例示的なものであることが意図されている）を記載してきたが、上記の教示に照らして当業者によって修正および変形がなされうることを注意しておく。したがって、開示された本発明の個別的な実施形態に対して、付属の請求項によって記載される本発明の範囲および精神の範囲内にはいる変更がなされうることは理解されるものとする。以上は本発明のさまざまな実施形態に向けられているが、本発明の他の実施形態およびさらなる実施形態が本発明の基本的な範囲から外れることなく考案されうる。
【技術分野】
【０００１】
本発明は、シーングラフに、より詳細にはシーングラフのレンダリングの際のパラメータのアクセス性（accessibility）および制御に関する。
【背景技術】
【０００２】
シーングラフはオブジェクトとも呼ばれるノードからなる階層構造である。ノードはグループ化ノード（grouping nodes）（枝と枝の間の交わり）または葉（leaves）のいずれかでありうる。そのような構造は通例、2Dまたは3Dグラフィック情報（たとえば幾何学的モデル）の保存およびレンダリングするためのその構成として使用される。
【０００３】
シーングラフは、時間的補間手段またはフレーム・ベースのアニメーション（たとえばマクロメディア・フラッシュの場合）のいずれかによって形成されるアニメーション情報を含むことができる。シーングラフはまた、シーンまたは内部に構成されるオブジェクトとの許容されるユーザー対話を表すセンサーをも含むことができる。正しく動作するためには、そのようなアニメーションはフルに記述されなければならず、対話トリガーはシーングラフ内で正しくルーティングされなければならない。
【０００４】
コンピュータ・グラフィックにおけるシーングラフの使用が一般化して数年になる。たいていの3Dオーサリング・ツール（たとえばオートデスク3Dスタジオ（Autodesk 3D Studio）またはマヤ（Maya））および3Dレンダリング・エンジン（たとえばピクサー・レンダーマン（Pixar RenderMan））は内部的に（すなわちそのアプリケーション内で）シーングラフをデータ構造としておよび交換のためのファイル・フォーマットとして使用する（たとえばVRML、COLLADA）。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
シーングラフのレンダリングの際のユーザー・コントロールは、その記述がシーングラフに埋め込まれなければならないという事実のため、比較的限られている。すなわち、残念ながら、現在利用可能な技術においては、シーングラフ内で、あるいはシーングラフのレンダリングの際にアニメーションおよびパラメータについての直接的なアプリケーション・ユーザー・インターフェース・コントロールを定義する簡単な手段はない。
【課題を解決するための手段】
【０００６】
本発明の諸実施形態は、シーングラフのパラメータの制御を可能にする簡単な手段と、アプリケーション・レベルでそれらのコントロールを扱い、それをユーザーに呈示する方法とを提供する。本発明の諸実施形態はまた、値の範囲、増分、デフォルトおよびある種のコントロールを許容するまたはしないことについてのユーザー・プロファイルもしくはプラットフォーム・プロファイルを使って、ユーザー対話についての制約の定義をも可能にする。
【０００７】
本発明のある実施形態では、シーングラフを制御する方法は、シーングラフ内で要素の集合を再定義し、再定義された要素に従ってシーングラフ内の選択された情報にアクセスし、選択された情報を制御する手段を提供することを含む。
【０００８】
本発明の代替的な実施形態では、シーングラフを制御するシステムは、シーングラフ内の要素の集合を再定義する手段と、再定義された要素に従ってシーングラフ内の選択された情報にアクセスするための手段と、選択された情報を制御する手段とを含む。
を含む。
【０００９】
本発明の教示は、以下の詳細な記述を付属の図面とともに考慮することによって容易に理解されうる。
【図面の簡単な説明】
【００１０】
【図１】本発明のある実施形態に基づく、シーングラフ・パラメータの制御を可能にするためのプロセスの流れ図である。
【図２】本発明のある実施形態に基づく、シーングラフおよび対応するコントロールのグラフィックな表現を描いた図である。
【図３】本発明のある実施形態に基づく、シーングラフ中のパラメータのアクセス性および制御のための方法の流れ図である。
【図４】本発明のある実施形態に基づく、図３の方法の再定義ステップの流れ図である。
【図５】本発明のある実施形態に基づく、図４の方法のリンク・ステップの流れ図である。
【発明を実施するための形態】
【００１１】
図面は本発明の概念を例解する目的のためであって、必ずしも本発明を例解する唯一の可能な構成ではないことは理解しておくべきである。理解を助けるため、可能なところでは、諸図面に共通する同一の要素を示すために同一の参照符号が使われている。
【００１２】
シーングラフ記述のために多くの規格が定義されている。それには、VRML（Virtual Reality Modeling Language［仮想現実感モデリング言語］）、X3D（eXtensible 3D［拡張可能3D］）、MPEG-4システム、COLLADAおよびJava（登録商標）3Dが含まれる。そのような規格はテキスト表現またはXMLを使用する。さらに、いくつかの独自規格も存在している（たとえば、マイクロソフトDirectXフォーマット、NVIDIA NVSGなど）。しかしながら、これらの表現のいずれにおいても、ユーザー対話を可能にする主たる手段は、すべての対話（センサー）および振る舞いをシーングラフ内に統合してモデル全体を上位構造に埋め込む（たとえば、VRML／X3Dにおけるプロトタイプ）か、あるいはシーングラフ・アプリケーション・インターフェース（VRMLではEAI（External Application Interface［外部アプリケーション・インターフェース］、X3DではSAI（Scene Access Interface［シーン・アクセス・インターフェース］）と称され、DirectXは前記マイクロソフトのフォーマット用インターフェースであり、MPEG-JはMPEG-4システムにおけるインターフェースである）を使って特定のアプリケーションを開発することである。
【００１３】
最初に挙げた解決策におけるようにシーングラフ内での対話および制御全体を記述することは、シーングラフのためのレンダリング・エンジンがアニメーションおよび対話イベントを処理するための実行エンジンを含むことを要求する（VRMLハンドブックの記載を参照）。これは、これらの場合におけるアプリケーション・ユーザー・インターフェースがシーングラフの知識を持たないからである。よって、シーングラフからデータを抽出するため、そして該データへのアクセスをユーザーに与えるためには、固有のソース・コードが開発されなければならない。上記の第二の解決策はVRML/X3Dにおいて定義されるようなプロトタイプを使うことを含む（VRMLハンドブックを参照）。VRMLハンドブックに記載されるように、この解決策は、「オブジェクトに対して何ができるかを制限することを作者に許容する保護機構」である。しかしながら、問題は、この「プロトタイプ・ノード」技法が：１）プロファイル管理；２）パラメータの値の簡単な制限（可能な唯一の方法はこの場合スクリプトを使うことである）を許容せず；３）フィールドを制御するためのユーザー・インターフェースを作成するための簡単な包含を提供しないということである（すなわち、実行エンジン内でイベントを処理するための識別子名のほかはパラメータに与えられる実名がなく、プロトタイプ技法はシーングラフ内の、ユーザーではなくオブジェクト（ノード）間の対話において助けるのみである）。さらに、この技法を使うことは、新しいパラメータの単純な追加がユーザーに呈示されることを許容しない。というのも、「プロトタイプ・ノード」は実際のシーングラフ構造をユーザーから隠すからである。
【００１４】
上記の第三の技法は、SAIのためのX3D仕様のようなシーングラフ・アクセス・インターフェース（Scenegraph Access Interface）（SAI）を使う。ここでこの技法は、シーングラフ情報へのアクセスを得るために特定のユーザー・インターフェースを開発することである。この技法は、シーングラフのどのメンバーへのアクセスをも許容する。しかしながら、すべてのフィールドへのアクセスはユーザーがシーングラフ構造全体を知っていて、そのすべての構造要素（ノード、フィールド等）の知識をもたなければならないということを意味する。さらに、その文法的な構成の名前のために、シーングラフ中の名前はユーザーにとって十分明快でないことがありうる。たとえば、スペース文字は許容されない。
【００１５】
本発明の諸実施形態は、実装が選ばれたシーングラフ・ファイル・フォーマット文法に合致する限り、いかなる既存のシーングラフ記述言語（たとえばテキストまたはXML）に適用されることもできる。その際、本発明の特徴を許容してまたは許容せずに本願の原理によって定義されたノードを扱うか扱わないかをパーサー〔構文解析器〕が決定できる。本アプリケーションはまた、本願の原理によって定義されたユーザー・インターフェースのコントロールを表示しないことを選ぶこともできる。たとえば、本発明の新しい特徴を扱わないことは、すべてのノードが、時にブラケット（たとえば「｛」および「｝」）またはXMLタグ・ブラケット（たとえば「＜ノード＞」および「＜／ノード＞」）として表現される境界をもつので、パース側では非常にストレートなことであろう。その際、パーサーはそのブラケットに限定されたシーングラフ内の完全な特徴宣言を無視するだけでよい。
【００１６】
本発明の諸実施形態は、もとのシーングラフ記述を修正することなくアプリケーション・ユーザー・インターフェースから選択されたシーングラフ情報へのアクセスを可能にするために必要とされる追加的なコンポーネントまたはノードのセット（シーングラフ構造に依存する）を含む。新しいコンポーネントまたはノードは、目標とされるシーングラフ情報のセマンティック〔意味内容〕を、ユーザーに呈示可能となるよう、たとえばユーザー・インターフェース上での理解可能な名前および修飾子をもって再定義することを可能にする。その際、この情報は、グラフィカル・ユーザー・インターフェースを通じてユーザーに提供される、新たに生成されたグラフィカル・インターフェースのウィジェットを通じて制御されることができる。
【００１７】
たとえば、本発明のある実施形態では、特徴識別子は、シーングラフ文法に準拠して定義された対応する閉じブラケットと開きブラケットをもって表現されることができる。さらに、プロファイル識別子は、そのプロファイルを記述する文字列または識別子のリストによって表現されることができる。プロファイルは、たとえばアクセス権を記述してユーザーを、あるいは機能および／またはプロファイルを記述してプラットフォームを含むことができる。これらのプロファイル識別子文字列の包含は、アプリケーション依存であることができ、あるいは名前記述または数値であることができる。この文字列のリストが空であれば、すべての定義されたコントロールは全ユーザーまたはプラットフォームに利用可能となるであろう。しかしながら、本発明の代替的な実施形態のある種の実装は、この情報を全く使わなくてもよく（すなわち、デコーダSTB（セットトップボックス）のようなプラットフォーム上にプロファイルが存在しない事例）、一方、他の実施形態は本アプリケーション中の別個のレイヤーでプロファイルを管理することができる（すなわち、切換器のようなプラットフォーム中の静的プロファイルの場合）。本発明の諸実施形態はさらに、そのそれぞれについて、シーングラフ中の制御される項目のリストを含むことができる。
【００１８】
シーングラフ中の識別子（identifier）は、シーングラフ中の目標とされる情報を定義する文字列または識別子のリストを含み、通例、ノードの名前定義または識別子と、制御されるべきノードのフィールドの名前または識別子とからなる。識別子がシーングラフ中の現在のパース・レベルにみつからなければ、その制御は有効にされるべきではない。本アプリケーションは次いで、シーングラフ中でのその定義の結果として、フィールド値型（たとえば浮動小数点、整数）を取得することができる。このフィールドは本質的には、グループ化された修正、たとえば同時にいくつかの色フィールドを単一のユーザー・インターフェース・コンポーネントのもとで許容する文字列のリストである。したがって、リストされるフィールドは同じ型であることが必要である。
【００１９】
本発明の諸実施形態はさらに、アプリケーション・ユーザー・インターフェース上に現れる名前（name）を含むことができる。これは通例、前段落で述べた識別子名とは異なるであろう。通例、シーングラフ中の識別子はシンタックス的に文法において制約されており（スペースや特定の文字なし）、適切な記述を呈示しないことがありうるからである（すなわち、これらの識別子は通例、グラフィック・モデリング・ツールによって自動的に生成される）。
【００２０】
本発明の諸実施形態によれば、リセット（reset）または工場値（factory value）は、ユーザー・インターフェース上で「リセット」または「工場値」ボタンが作動されるときにパラメータを設定するための値を含むことができる。この値は、シーングラフにおける値そのものとは異なっていてもよい。シーングラフは特定の時点での値を記憶するからである。さらに、そのパラメータについて有効な値の範囲を定義する最小値および最大値が含められてもよい。最小値および最大値は、ユーザー・インターフェースのコントロールについての限界を定義する。
【００２１】
本発明の諸実施形態の本アプリケーションは、さらに、たとえば「＋」または「−」ボタンを押すことによってユーザー・インターフェース上でパラメータに（プラスにまたはマイナスに）適用するステップごとの増分（絶対値）に対応するステップ増分（Step Increment）と、このコントロールが有効にされる定義されたプロファイル（Profiles）とを含むことができる。すなわち、このコントロールが有効にされる選択されたプロファイル識別子（たとえば、上に挙げたものまたは他のアプリケーション定義識別子）がここにリストされることができる。
【００２２】
本発明のある実施形態では、すべての値はフィールド型数値領域（domain）において表現される。選ばれたシーングラフがたとえば浮動小数点値およびブーリアン〔ブール値〕を表現するための一般的フィールド型を提供しない場合、それらのパラメータを定義するために最大の領域が使用されることができる。たとえば、浮動小数点表現が使用されることができ、値は整数またはブーリアンとしてキャストされることができる。本発明の諸実施形態によれば、たとえばRGB値（赤、緑および青）をもつ色など、多くのパラメータは二つ以上の要素または成分からなることができるので、すべての値は、数字の配列であることができる。制御されるフィールドをなす要素／成分の数と最小値、最大値、リセット値および増分値に含まれる要素／成分の数とが異なる場合、制御されるフィールド中の要素／成分の数に合致する後者の値についての最小数の要素のみが使われるものとする。たとえば、制御されるフィールドが３成分をもつRGB色を表現し、「リセット」値が「[1.0 1.0 1.0 1.0]」と定義される場合、システムは最初の三つの要素のみを使用し、最後の一つは未使用のままとする。
【００２３】
制御されるフィールドが含まれるノードがシーングラフの実行の際に破壊される場合、このノードにリンクされたユーザー・インターフェースのコントロールも無効にされるか破壊される。本発明の諸実施形態はまた、制御される項目がグループ化されることをも許容する。これは、たとえば「ホイール」から構成される「車」など、ユーザー・インターフェース上のパラメータのリストのグループ化をより自然な仕方で許容する、あるいは情報をユーザーに呈示するためのシーングラフの自然な階層構造のオーバーライドを許容する。
【００２４】
本発明の諸実施形態は、各シーングラフ・モデルに固有な制約があるだけで、いかなる既存のシーングラフ上で実装されることもできる。たとえば、VRML 2.0は一般的なフィールド型を提供せず、最大の領域として「SFFloat」が使用できるのみである。
【００２５】
たとえば、本発明のVRML 2.0ノード実装は次のように表現されることができる：
【００２６】
【表１】
「ControlProfiles」ノードは、プロファイルがアプリケーション・レイヤーで定義される場合は破棄されることができる。
【００２７】
【表２】
「items」フィールドは、「ControlItems」（下記参照）または他の「ControlGroup」ノードのリストを含むことができる。「name」フィールドはユーザーに呈示されるグループ名、たとえば「car〔車〕」を定義する。呈示されている「profiles」フィールドは、「items」リスト中の個々の項目（item）上のプロファイル指定をオーバーライドし、プロファイルがグループ全体を簡単に制御することを許容する。
【００２８】
【表３】
上記の実施形態では、「profiles」リストは、「ControlProfiles」ノードまたはアプリケーション依存値によって定義されるプロファイルのリストを含む。
【００２９】
本発明のある代替的な実施形態では、VRML 2.0実装内のPROTO構造概念が次のように表現できる：
【００３０】
【表４】
本発明のさらなる代替的な実施形態では、本発明のX3Dノード実装が次のように表現できる：
【００３１】
【表５】
図１は、本発明のある実施形態に基づくシーングラフ・パラメータの制御を可能にするためのプロセスの流れ図を描いている。図１のプロセス１００は、本発明の上記の実施形態の制御方法を含むオーサリングまたはモデリング・ツール１０２をもって始まる。ステップ１０３では、コンテンツ・クリエイターが主題となるシーングラフをエクスポートする。シーングラフがコントロールを有効にされていれば、プロセスはステップ１０８に続く。オーサリング／モデリング・ツールがそのような機能性をシーングラフに供給しない場合、あとでコントロールを追加するために特定のモジュールが生成されることができる。たとえば、オーサリング・モデリング・ツール１０２がそのような機能性を供給しない場合、必要なコントロールを追加するために作者はシーングラフ１０４をモジュール１０６にエクスポートする。次いでコントロールをもつシーングラフが有効にされ（１０８）、アプリケーション・ブロック１１０にロードされる。アプリケーション１１２は次いでシーングラフをレンダリング１１４するためにロードし、これでグラフィカル・ユーザー・インターフェース上にコントロールを生成し（１１６）それをユーザーに利用可能にすることができる。
【００３２】
本発明のある実施形態では、アプリケーション１１２は、ユーザー・コントロールを追加するために、直接、コントロール生成モジュール１１６を埋め込むことができる。これは、コンテンツ・クリエイターがシーングラフおよびその対応するコントロールの正しい実行およびレンダリングを検証するために有用であることができる。
【００３３】
図２は、本発明のある実施形態に基づくシーングラフおよび対応するコントロールのグラフィックな表現を描いている。図２の実施形態は、本発明の方法をサポートするアプリケーションによる、シーングラフ２００（この場合、単純な立方体）およびそのコントロール（この場合、単純なRGB色選択）のレンダリングを示している。シーングラフは、VRMLノード実施形態の解釈に関して当該アプリケーションによって生成された、アプリケーション・レンダリング・ウィンドウ２０８上に表示された白の背景２０２、淡青の立方体２０６と、コントロール・ウィンドウ２０４とを含む。図２で使われているシーングラフの例は、プロファイルを無効にしてVRML 2.0シーングラフを使って書かれる。本発明のある実施形態によれば、そのシーングラフのVRML 2.0記述は次のように表現できる：
【００３４】
【表６】
上の例に描かれるように、アプリケーション１１２は、コントロール項目（Control Item）を使用して、コントロール・グループ（Control Group）「Cube〔立方体〕」からの名前「Color〔色〕」と、VRML 2.0規格では型がSFColorである「MAT」ノードの一部であるシーングラフ・フィールド「diffuseColor」との間の結び付きを確立し、そうして機能的に所望されるコントロール（すなわち、赤、緑および青の色レベルについての３つの編集可能なフィールド）をサポートする。これは、図２において、個々のR、G、Bコントロールが示されているコントロール・ウィンドウ２０４によって示されている。
【００３５】
図３は、本発明のある実施形態に基づく、シーングラフ内のパラメータのアクセス性および制御の方法の流れ図を描いている。図３の方法３００は、シーングラフ内の要素のセットが初期に再定義されるステップ３０２において始まる。本方法は次いでステップ３０４に進む。
【００３６】
ステップ３０４では、ひとたび再定義されると、シーングラフ内の選択された情報が再定義された要素に従ってアクセスされる。本方法は次いでステップ３０６に進む。
【００３７】
ステップ３０６では、選択された情報がアクセスされたとき、選択された情報を制御するための手段が提供される。
【００３８】
図４は、本発明のある実施形態に基づく図３の方法３００の再定義ステップ３０２の流れ図を描いている。図３の方法３００において定義された要素を再定義するために、最初に、コントロールが提供されるべき要素のセットがステップ３１０で識別される。ステップ３１２で、ひとたび識別されたら、追加的な制御情報が識別された要素のセットに対応して、シーングラフ中の既存の構造にリンクされる。
【００３９】
図５は、本発明のある実施形態に基づく、図４の方法のリンクするステップ３１２の流れ図を描いている。図５の実施形態では、追加的情報をリンクするため、ステップ３２０における、シーングラフ内でのコンポーネントまたはノードの存在の初期探索がある。次いでステップ３２２では、制御されるべき情報がそのコンポーネントまたはノードの一部であるかどうかが判定される。ひとたびこの判定がなされたら、ステップ３２４で、シーングラフにおいて使用されている標準的な文法から情報データ型のもう一つの判定がなされる。ステップ３２５では、上記の判定がすべてなされており、前記データの型およびポイントが、ユーザー・イベントを受け取るために本アプリケーション中に記憶されることができる。
【００４０】
上記において特定の仕方に言及することなく、あるいは一つの仕方を使ってのみ記載されているとしても、さまざまな側面、実装および特徴が多様な仕方のうちの一つまたは複数において実装されうる。たとえば、さまざまな側面、実装および特徴は、たとえば方法、装置、方法を実行するための装置もしくは処理デバイス、プログラムもしくはその他の命令の集合、プログラムもしくは命令の集合を含む装置およびコンピュータ可読媒体のうちの一つまたは複数を使って実装されてもよい。
【００４１】
装置はたとえば、ばらばらなまたは統合されたハードウェア、ファームウェアおよびソフトウェアを含んでもよい。一例として、装置はたとえば、プロセッサを含んでいてもよい。プロセッサとは、たとえばマイクロプロセッサ、集積回路またはプログラム可能な論理デバイスを含む処理装置一般をいう。もう一つの例として、装置は、一つまたは複数のプロセスを実行するための命令を有する一つまたは複数のコンピュータ可読媒体を含んでいてもよい。
【００４２】
コンピュータ可読媒体は、たとえば、ソフトウェア担体または他の記憶デバイスを含んでいてもよい。他の記憶デバイスはたとえば、ハードディスク、コンパクト・ディスケット、ランダム・アクセス・メモリ（「RAM」）または読み出し専用メモリ（「ROM」）といったものである。コンピュータ可読媒体はまた、たとえば命令をエンコードまたは伝送するフォーマットされた電磁波を含んでいてもよい。命令はたとえば、ハードウェア、ファームウェア、ソフトウェアまたは電磁波の形であってもよい。命令はたとえば、オペレーティング・システム、別個のアプリケーションまたは両者の組み合わせにおいて見出されてもよい。したがって、プロセッサは、プロセスを実行するよう構成された装置およびプロセスを実行するための命令を有するコンピュータ可読媒体を含む装置の両方として特徴付けされることができる。
【００４３】
シーングラフ内のパラメータへのアクセスおよびその制御を提供するための方法およびシステムのための好ましい実施形態（これは限定するものではなく例示的なものであることが意図されている）を記載してきたが、上記の教示に照らして当業者によって修正および変形がなされうることを注意しておく。したがって、開示された本発明の個別的な実施形態に対して、付属の請求項によって記載される本発明の範囲および精神の範囲内にはいる変更がなされうることは理解されるものとする。以上は本発明のさまざまな実施形態に向けられているが、本発明の他の実施形態およびさらなる実施形態が本発明の基本的な範囲から外れることなく考案されうる。
【特許請求の範囲】
【請求項１】
シーングラフを制御する方法であって：
シーングラフ内で要素の集合を再定義する段階と；
再定義された要素に従って前記シーングラフ内の選択された情報にアクセスする段階と；
選択された情報を制御する手段を提供する段階とを有する、
方法。
【請求項２】
前記再定義された要素の集合は、前記シーングラフの構造に依存して少なくとも一つのコンポーネントまたは少なくとも一つのノードを含む、請求項１記載の方法。
【請求項３】
制御する手段を提供する前記段階が、アクセスされた選択された情報に関係するコントロールをユーザー・インターフェースに提供することを含む、請求項１記載の方法。
【請求項４】
制御が提供されるべき要素の集合を識別する段階と；
識別された要素の集合に対応する制御情報を前記シーングラフ中の既存の構造にリンクさせる段階とを有する、
請求項１記載の方法。
【請求項５】
前記再定義する段階がさらに、選択されたシーングラフ情報へのアプリケーション・ユーザー・インターフェースからのアクセスを可能にするために一つまたは複数の追加的なコンポーネントまたはノードを追加することを含む、請求項４記載の方法。
【請求項６】
制御する手段を提供する前記段階が、前記シーングラフとのユーザー対話のための少なくとも一つの制約条件を定義することを含む、請求項１記載の方法。
【請求項７】
前記再定義する段階が、値の範囲、増分およびユーザー・プロファイルもしくはプラットフォーム・プロファイルのうちの少なくとも一つを有する要素の集合を使用することを含む、請求項６記載の方法。
【請求項８】
前記シーングラフが一般的フィールド型を提供するかどうかを判定し；
前記シーングラフが一般的フィールド型を提供しないとき、要素の前記再定義のために前記シーングラフ中の最大の領域を使うことをさらに含む、
請求項１記載の方法。
【請求項９】
追加的な制御情報をリンクさせる前記段階が：
前記シーングラフ中のコンポーネントまたはノードの存在を探索する段階と；
制御されるべき情報が前記コンポーネントまたはノードの一部であるかどうかを判定する段階と；
前記シーングラフから情報データ型を判定する段階と；
ユーザー・イベントを受け取るために、前記データ型および前記エータへのポインティングをアプリケーション中に記憶する段階とを有する、
請求項４記載の方法。
【請求項１０】
前記再定義する段階、アクセスする段階および提供する段階が、シーングラフ・オーサリング・ツールを使ってシーングラフ・オーサリングの際に実行される、請求項１記載の方法。
【請求項１１】
前記再定義する段階、アクセスする段階および提供する段階が、シーングラフのオーサリングが完了したあとに実行される、請求項１記載の方法。
【請求項１２】
オーサリング・ツールからシーングラフをエクスポートする段階と；
前記のエクスポートされたシーングラフ中にコントロールをインポートする段階と；
コントロールをもつ前記シーングラフを保存する段階と；
有効にされたコントロールをもつ前記シーングラフをアプリケーションにロードする段階とをさらに有する、
請求項１１記載の方法。
【請求項１３】
シーングラフを制御するシステムであって：
シーングラフ内で要素の集合を再定義する手段と；
再定義された要素に従って前記シーングラフ内の選択された情報にアクセスする手段と；
選択された情報を制御する手段とを有する、
システム。
【請求項１４】
前記再定義された要素の集合は、前記シーングラフの構造に依存して少なくとも一つのコンポーネントまたは少なくとも一つのノードを含む、請求項１３記載のシステム。
【請求項１５】
前記制御する手段が、アクセスされた選択された情報に関係するコントロールをもつグラフィカル・ユーザー・インターフェースを有する、請求項１３記載のシステム。
【請求項１６】
前記再定義する手段が、制御が提供されるべき要素の集合を識別する手段と、識別された要素の集合に対応する追加的な制御情報を前記シーングラフ中の既存の構造にリンクさせる手段とをさらに有する、請求項１３記載のシステム。
【請求項１７】
前記再定義する手段がさらに、選択されたシーングラフ情報へのアプリケーション・ユーザー・インターフェースからのアクセスを可能にするために一つまたは複数の追加的なコンポーネント（またはノード）を追加するための手段をさらに有する、請求項１６記載のシステム。
【請求項１】
シーングラフを制御する方法であって：
シーングラフ内で要素の集合を再定義する段階と；
再定義された要素に従って前記シーングラフ内の選択された情報にアクセスする段階と；
選択された情報を制御する手段を提供する段階とを有する、
方法。
【請求項２】
前記再定義された要素の集合は、前記シーングラフの構造に依存して少なくとも一つのコンポーネントまたは少なくとも一つのノードを含む、請求項１記載の方法。
【請求項３】
制御する手段を提供する前記段階が、アクセスされた選択された情報に関係するコントロールをユーザー・インターフェースに提供することを含む、請求項１記載の方法。
【請求項４】
制御が提供されるべき要素の集合を識別する段階と；
識別された要素の集合に対応する制御情報を前記シーングラフ中の既存の構造にリンクさせる段階とを有する、
請求項１記載の方法。
【請求項５】
前記再定義する段階がさらに、選択されたシーングラフ情報へのアプリケーション・ユーザー・インターフェースからのアクセスを可能にするために一つまたは複数の追加的なコンポーネントまたはノードを追加することを含む、請求項４記載の方法。
【請求項６】
制御する手段を提供する前記段階が、前記シーングラフとのユーザー対話のための少なくとも一つの制約条件を定義することを含む、請求項１記載の方法。
【請求項７】
前記再定義する段階が、値の範囲、増分およびユーザー・プロファイルもしくはプラットフォーム・プロファイルのうちの少なくとも一つを有する要素の集合を使用することを含む、請求項６記載の方法。
【請求項８】
前記シーングラフが一般的フィールド型を提供するかどうかを判定し；
前記シーングラフが一般的フィールド型を提供しないとき、要素の前記再定義のために前記シーングラフ中の最大の領域を使うことをさらに含む、
請求項１記載の方法。
【請求項９】
追加的な制御情報をリンクさせる前記段階が：
前記シーングラフ中のコンポーネントまたはノードの存在を探索する段階と；
制御されるべき情報が前記コンポーネントまたはノードの一部であるかどうかを判定する段階と；
前記シーングラフから情報データ型を判定する段階と；
ユーザー・イベントを受け取るために、前記データ型および前記エータへのポインティングをアプリケーション中に記憶する段階とを有する、
請求項４記載の方法。
【請求項１０】
前記再定義する段階、アクセスする段階および提供する段階が、シーングラフ・オーサリング・ツールを使ってシーングラフ・オーサリングの際に実行される、請求項１記載の方法。
【請求項１１】
前記再定義する段階、アクセスする段階および提供する段階が、シーングラフのオーサリングが完了したあとに実行される、請求項１記載の方法。
【請求項１２】
オーサリング・ツールからシーングラフをエクスポートする段階と；
前記のエクスポートされたシーングラフ中にコントロールをインポートする段階と；
コントロールをもつ前記シーングラフを保存する段階と；
有効にされたコントロールをもつ前記シーングラフをアプリケーションにロードする段階とをさらに有する、
請求項１１記載の方法。
【請求項１３】
シーングラフを制御するシステムであって：
シーングラフ内で要素の集合を再定義する手段と；
再定義された要素に従って前記シーングラフ内の選択された情報にアクセスする手段と；
選択された情報を制御する手段とを有する、
システム。
【請求項１４】
前記再定義された要素の集合は、前記シーングラフの構造に依存して少なくとも一つのコンポーネントまたは少なくとも一つのノードを含む、請求項１３記載のシステム。
【請求項１５】
前記制御する手段が、アクセスされた選択された情報に関係するコントロールをもつグラフィカル・ユーザー・インターフェースを有する、請求項１３記載のシステム。
【請求項１６】
前記再定義する手段が、制御が提供されるべき要素の集合を識別する手段と、識別された要素の集合に対応する追加的な制御情報を前記シーングラフ中の既存の構造にリンクさせる手段とをさらに有する、請求項１３記載のシステム。
【請求項１７】
前記再定義する手段がさらに、選択されたシーングラフ情報へのアプリケーション・ユーザー・インターフェースからのアクセスを可能にするために一つまたは複数の追加的なコンポーネント（またはノード）を追加するための手段をさらに有する、請求項１６記載のシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図２】
【図３】
【図４】
【図５】
【公表番号】特表２０１０−５２１７３７（Ｐ２０１０−５２１７３７Ａ）
【公表日】平成２２年６月２４日（２０１０．６．２４）
【国際特許分類】
【出願番号】特願２００９−５５３５５７（Ｐ２００９−５５３５５７）
【出願日】平成１９年６月２８日（２００７．６．２８）
【国際出願番号】ＰＣＴ／ＵＳ２００７／０１５１４９
【国際公開番号】ＷＯ２００８／１１５１９６
【国際公開日】平成２０年９月２５日（２００８．９．２５）
【出願人】（５０１２６３８１０）トムソン ライセンシング (2,848)
【氏名又は名称原語表記】Ｔｈｏｍｓｏｎ Ｌｉｃｅｎｓｉｎｇ
【住所又は居所原語表記】１−５， ｒｕｅ Ｊｅａｎｎｅ ｄ’Ａｒｃ， ９２１３０ ＩＳＳＹ ＬＥＳ ＭＯＵＬＩＮＥＡＵＸ， Ｆｒａｎｃｅ
【Ｆターム（参考）】
【公表日】平成２２年６月２４日（２０１０．６．２４）
【国際特許分類】
【出願日】平成１９年６月２８日（２００７．６．２８）
【国際出願番号】ＰＣＴ／ＵＳ２００７／０１５１４９
【国際公開番号】ＷＯ２００８／１１５１９６
【国際公開日】平成２０年９月２５日（２００８．９．２５）
【出願人】（５０１２６３８１０）トムソン ライセンシング (2,848)
【氏名又は名称原語表記】Ｔｈｏｍｓｏｎ Ｌｉｃｅｎｓｉｎｇ
【住所又は居所原語表記】１−５， ｒｕｅ Ｊｅａｎｎｅ ｄ’Ａｒｃ， ９２１３０ ＩＳＳＹ ＬＥＳ ＭＯＵＬＩＮＥＡＵＸ， Ｆｒａｎｃｅ
【Ｆターム（参考）】
[ Back to top ]