モデル３Ｄ構築アプリケーションプログラムインターフェース
アプリケーションプログラムインターフェースは、モデル３Ｄオブジェクトによって定義された３Ｄモデルの３次元（３Ｄ）場面を構築するために使用することができる。このインターフェースは、１つまたは複数のグループオブジェクトおよび１つまたは複数のリーフオブジェクトを有する。グループオブジェクトは、他のグループオブジェクトおよび／またはリーフオブジェクトを含むか、あるいは収集する。リーフオブジェクトは、描画オブジェクトであってもイルミネーションオブジェクトであってもよい。グループオブジェクトは、それらのグループ内で収集されたオブジェクトを変換するための変換演算を有することができる。描画オブジェクトは、３Ｄ場面の３Ｄモデルを描画するための命令、または、２Ｄ画像を３Ｄモデル上で描画するための命令を定義する。イルミネーションオブジェクトは、３Ｄモデルを３Ｄ場面内で照らすライトの種類および方向を定義する。方法は、アプリケーションプログラムインターフェースのオブジェクトにより構築されたコンピュータプログラムオブジェクトのツリー階層を処理する。この方法は、オブジェクトの３Ｄ場面ツリー階層の枝をトラバースして、グループオブジェクトおよびリーフオブジェクトを処理する。この方法は、次の未処理オブジェクトがリーフオブジェクトのグループオブジェクトであるかどうかを検出する。それがリーフオブジェクトである場合、この方法は、このリーフオブジェクトがライトオブジェクトであるか、描画３Ｄオブジェクトであるかを検出する。リーフオブジェクトがライトオブジェクトである場合、３Ｄ場面のイルミネーションが設定される。描画３Ｄオブジェクトが検出される場合、３Ｄモデルはイルミネーションによって照らされるように描画される。この方法はまた、グループオブジェクトによって収集されたオブジェクトのグループにグループ演算を実行することもできる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般にコンピュータグラフィックスの分野に関する。より詳細には、本発明は、３次元場面グラフィックスのためのアプリケーションプログラミングインターフェースに関する。
【背景技術】
【０００２】
コンピュータシステム上のグラフィックスにアクセスする従来のモデルは限界に達しつつあり、これは、メモリおよびバス速度が、メインプロセッサおよび／またはグラフィックスプロセッサの進歩に追いついていないことに１つの要因がある。一般に、ビットマップを用いたフレームの準備のための現在のモデルは、複雑なグラフィックスエフェクトが望まれるときにハードウェアのリフレッシュレートに追いつくために、膨大な量のデータ処理を必要とする。結果として、複雑なグラフィックスエフェクトが従来のグラフィックスモデルを用いて試みられるとき、視覚エフェクトが知覚される結果となる変化を次のフレームに対して適時完了するのではなく、この変化が異なるフレームに亘って追加され、視覚的に望ましくない結果を引き起こす場合がある。
【０００３】
さらに、３次元（３Ｄ）グラフィックスを２次元（２Ｄ）合成システムに導入して、２Ｄ画像および３Ｄ場面を有する混合場面を表示することによって、この問題は悪化される。このような混合システムの実施における問題の中には、３Ｄモデルのためのプログラムオブジェクトをどのように定義するかがある。このプログラムオブジェクトはどのように編成されるべきであるだろうか。
【０００４】
これらの検討事項およびその他に関して、本発明は作られた。
【０００５】
【特許文献１】VISUAL AND SCENE GRAPH INTERFACEという名称の関連特許出願
【発明の開示】
【発明が解決しようとする課題】
【０００６】
上記および他の問題は、コンピュータプログラムオブジェクトに適用されて、ツリー階層を構築し、３Ｄモデルの３次元（３Ｄ）場面をレンダリングするコンピュータデータ構造によって解決される。ツリー階層内のルートオブジェクトは、３Ｄ場面のためのオブジェクトを収集する。ツリー階層内のグループオブジェクトは、ツリー階層内の他のグループオブジェクトおよび描画オブジェクトを収集し、グループオブジェクトによって収集された描画オブジェクトに演算するグループ演算を定義する。ツリー階層内のライトオブジェクトは、３Ｄモデルを３Ｄ場面内でレンダリングする際に使用されるイルミネーションを定義し、１つまたは複数の描画３Ｄオブジェクトは、３Ｄモデルを３Ｄ場面内で描画するための演算を定義する。
【課題を解決するための手段】
【０００７】
本発明の他の態様によれば、本発明は、合成システムによってレンダリングされた３次元（３Ｄ）モデルの２次元（２Ｄ）ビューを描画するための、コンピュータプログラムオブジェクトの階層を処理するための方法に関する。この方法は、オブジェクトの３Ｄ場面ツリー階層の枝をトラバースして、グループオブジェクトおよびリーフオブジェクトを処理する。この方法は、次の未処理オブジェクトがリーフオブジェクトのグループオブジェクトであるか否かを検出する。それがリーフオブジェクトである場合、この方法は、このリーフオブジェクトがライトオブジェクトであるか、描画３Ｄオブジェクトであるかを検出する。リーフオブジェクトがライトオブジェクトである場合、３Ｄ場面のイルミネーションが設定される。描画３Ｄオブジェクトが検出される場合、３Ｄモデルはイルミネーションによって照らされるように描画される。この方法はまた、グループオブジェクトによって収集されたオブジェクトのグループにグループ演算を実行することもできる。
【０００８】
さらに他の態様によれば、本発明は、モデル３Ｄオブジェクトによって定義された３Ｄモデルの３次元（３Ｄ）場面を作成するための、アプリケーションプログラムインターフェースに関する。このインターフェースは、１つまたは複数のグループオブジェクトおよび１つまたは複数のリーフオブジェクトを有する。グループオブジェクトは、他のグループオブジェクトおよび／またはリーフオブジェクトを含むか、あるいは収集する。リーフオブジェクトは、描画オブジェクトであってもイルミネーションオブジェクトであってもよい。グループオブジェクトは、それらのグループ内で収集されたオブジェクトを変換するための変換演算を有することができる。描画オブジェクトは、３Ｄ場面の３Ｄモデルを描画するための命令、または、２Ｄ画像を３Ｄモデル上で描画するための命令を定義する。イルミネーションオブジェクトは、３Ｄモデルを３Ｄ場面内で照らすライトの種類および方向を定義する。
【０００９】
本発明を、コンピュータプロセス、コンピューティングシステムとして、または、コンピュータプログラム製品もしくはコンピュータ読取り可能な媒体などの製品として実施することができる。コンピュータ読取り可能な媒体は、コンピュータシステムによって読取り可能であり、コンピュータプロセスを実行するための命令のコンピュータプログラムをエンコードする、コンピュータ記憶媒体にすることができる。コンピュータ読取り可能な媒体はまた、コンピューティングシステムによって読取り可能であり、コンピュータプロセスを実行するための命令のコンピュータプログラムをエンコードする、キャリア上の伝播信号であってもよい。
【００１０】
本発明を特徴付けるこれらおよび様々な他の特徴ならびに利点は、以下の詳細な説明を読み、関連する図面を見直すことから明らかになるであろう。
【発明を実施するための最良の形態】
【００１１】
図１は、本発明の一実施形態による、Ｍｏｄｅｌ ３Ｄ ＡＰＩを実装するためのコンピュータプログラムオブジェクトのアーキテクチャを例示する。Ｍｏｄｅｌ３Ｄオブジェクト１０は、ルートまたは抽象オブジェクトである。ルートオブジェクトに関係付けられた子である４つの可能なモデル３Ｄオブジェクトがある。これらの３つのオブジェクトは、Ｐｒｉｍｉｔｉｖｅ３Ｄオブジェクト１２、Ｖｉｓｕａｌ Ｍｏｄｅｌ３Ｄオブジェクト１４、およびＬｉｇｈｔオブジェクト１６であり、このアーキテクチャではリーフオブジェクトである。Ｍｏｄｅｌ３ＤＧｒｏｕｐオブジェクト２０は、リーフオブジェクトまたは他のグループオブジェクトのための、ツリー内の収集ノードであり、Ｔｒａｎｓｆｏｒｍ３Ｄオブジェクト１８も含む。Ｔｒａｎｓｆｏｒｍ３Ｄオブジェクトは、それに関連付けられた変換オブジェクトの階層を有する。
【００１２】
Ｐｒｉｍｉｔｉｖｅ３Ｄオブジェクトは、メッシュ情報２６およびマテリアル情報２８を含み、これらの情報もまたオブジェクトの階層を参照または示して、Ｐｒｉｍｉｔｉｖｅ３Ｄオブジェクト１２によって描画される３Ｄモデルの定義を支援することができる。Ｖｉｓｕａｌ Ｍｏｄｅｌ３Ｄオブジェクト１４は、３Ｄ場面に組み込むための２Ｄ画像を定義する。Ｌｉｇｈｔオブジェクト１６は、３Ｄ場面用のイルミネーションを定義し、様々な照明状態を定義するためのオブジェクトの階層を有する。これらのすべてのオブジェクトは以下で、Ｍｏｄｅｌ ３Ｄ ＡＰＩ定義において定義される。
【００１３】
図１のオブジェクトは、モデル３Ｄ場面ツリー、すなわち、３Ｄ場面をレンダリングするためのモデル３Ｄオブジェクトのツリー階層を構築するために使用される。３Ｄ場面ツリーは、ｖｉｓｕａｌ ３Ｄオブジェクト２２、または描画コンテキスト２５を有するｖｉｓｕａｌ ２Ｄオブジェクトのいずれかから、Ｍｏｄｅｌ３Ｄルートオブジェクト１０において入力される。Ｖｉｓｕａｌ ３Ｄオブジェクト２２、および、Ｖｉｓｕａｌ ２Ｄオブジェクト２４の描画コンテキスト２５は、Ｍｏｄｅｌ３Ｄルートオブジェクト１０およびｃａｍｅｒａオブジェクト３２を示すポインタを含む。ｖｉｓｕａｌ ３Ｄオブジェクトのポインタ３３は、ｍｏｄｅｌ３Ｄルートオブジェクト１０を示す。ｖｉｓｕａｌ ３Ｄオブジェクトのポインタ３４は、ｃａｍｅｒａオブジェクト３２を示す。ｖｉｓｕａｌ ２Ｄオブジェクト２４の描画コンテキスト２５内に含まれたポインタ３１は、ｍｏｄｅｌ３Ｄルートオブジェクト１０を示す。ｖｉｓｕａｌ ２Ｄオブジェクト２４の描画コンテキスト２５内に含まれたポインタ３５は、ｃａｍｅｒａオブジェクト３２を示す。
【００１４】
ｃａｍｅｒａオブジェクト３２は、３Ｄ場面を表示するカメラの視点またはアイポイントの位置を定義する。ｃａｍｅｒａオブジェクト３２は、ｃａｍｅｒａオブジェクトの階層を有し、この階層には、ｐｒｏｊｅｃｔｉｏｎ ｃａｍｅｒａオブジェクト３９、ｐｅｒｓｐｅｃｔｉｖｅ ｃａｍｅｒａオブジェクト３６、ｏｒｔｈｏｇｏｎａｌ ｃａｍｅｒａオブジェクト３７およびＭａｔｒｉｘ３Ｄ ｃａｍｅｒａオブジェクト３８が含まれる。これらの各ｃａｍｅｒａオブジェクトは以下で、Ｍｏｄｅｌ３Ｄ ＡＰＩ定義において定義される。
【００１５】
後述の図６は、図１のモデル３Ｄオブジェクトをビルディングブロックとして使用して構築された、３Ｄ場面ツリーの一実施例である。図６からの３Ｄ場面をレンダリングするための演算フローを、以下で図７を参照して説明する。本発明を実施するための例示的動作ハードウェアおよびソフトウェア環境をこのとき、図２ないし５を参照して説明する。
【００１６】
（例示的オペレーティング環境）
図２に、本発明を実施することができる適切なコンピューティングシステム環境１００の一実施例を示す。コンピューティングシステム環境１００は、適切なコンピューティング環境の単なる一実施例でしかなく、本発明の使用または機能性の範囲についてのいかなる限定をも示唆するように意図されない。コンピューティング環境１００は、例示的オペレーティング環境１００に例示するコンポーネントのいずれか１つ、またはそれらの組合せに関係するいかなる依存性または要件も有するように解釈されるべきではない。
【００１７】
本発明は、多数の他の汎用または専用コンピューティングシステム環境または構成と共に動作可能である。本発明と共に使用するために適切である可能性のある、周知のコンピューティングシステム、環境および／または構成の例には、これに限定されないが、パーソナルコンピュータ、サーバーコンピュータ、ハンドヘルドまたはラップトップ装置、タブレット装置、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラマブルなコンシューマエレクトロニクス、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたは装置のいずれかを含む分散コンピューティング環境などが含まれる。
【００１８】
本発明を、一般にコンピュータによって実行されるプログラムモジュールなど、コンピュータ実行可能な命令に関連して説明することができる。一般に、プログラムモジュールには、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。これらは、特定のタスクを実行し、または特定の抽象データ型を実施する。また、本発明を分散コンピューティング環境において実施することもできる。この環境では、タスクが、通信ネットワークを通じてリンクされるリモート処理装置によって実行される。分散コンピューティング環境では、プログラムモジュールは、メモリ記憶装置を含む、ローカルおよびリモートのコンピュータ記憶媒体内に位置することができる。
【００１９】
図２を参照すると、本発明を実施するための例示的なシステムは、コンピュータ１１０の形態における汎用コンピューティング装置を含む。コンピュータ１１０のコンポーネントには、これに限定されないが、処理装置１２０、システムメモリ１３０、および、システムメモリを含む様々なシステムコンポーネントを処理装置１２０に結合するシステムバス１２１が含まれる場合がある。システムバス１２１をいくつかの種類のバス構造のいずれにすることもでき、これらのバス構造には、様々なバスアーキテクチャのいずれかを使用するメモリバスまたはメモリコントローラ、周辺バスおよびローカルバスが含まれる。限定ではなく例として、このようなアーキテクチャには、ＩＳＡ（業界標準アーキテクチャ）バス、ＭＣＡ（マイクロチャネルアーキテクチャ）バス、ＥＩＳＡ（拡張ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、ＡＧＰ（Ａｃｃｅｌｅｒａｔｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ）バス、および、メザニンバスとしても知られるＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスが含まれる。
【００２０】
コンピュータ１１０は通常、様々なコンピュータ読取り可能な媒体を含む。コンピュータ読取り可能な媒体は、コンピュータ１１０によってアクセスすることができるいかなる使用可能な媒体にすることもでき、揮発性および不揮発性の媒体、ならびに取り外し可能および固定の媒体が含まれる。例として、限定ではなく、コンピュータ読取り可能な媒体は、コンピュータ記憶媒体および通信媒体を含むことができる。コンピュータ記憶媒体には、揮発性および不揮発性、取り外し可能および固定の媒体が含まれ、これらの媒体はコンピュータ読取り可能な命令、データ構造、プログラムモジュールまたは他のデータなど、情報の格納のためのいずれかの方法または技術において実装される。コンピュータ記憶媒体には、それだけに限定されないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）もしくは他の光ディスク記憶、磁気カセット、磁気テープ、磁気ディスク記憶もしくは他の磁気記憶装置、または、所望の情報を格納するために使用することができ、コンピュータ１１０によってアクセスすることができる他のいかなる媒体もが含まれる。通信媒体は通常、コンピュータ読取り可能な命令、データ構造、プログラムモジュールまたは他のデータを、搬送波または他の移送メカニズムなどの変調データ信号において実施し、いかなる情報配信媒体をも含む。「変調データ信号」という用語は、信号内の情報をエンコードするような方法でその特性の１つまたは複数が設定または変更されている信号を意味する。限定ではなく例として、通信媒体には、有線ネットワークまたは直接有線接続などの有線媒体、ならびに、音響、ＲＦ、赤外線および他の無線媒体などの無線媒体が含まれる。上記のいずれの組合せも、コンピュータ読取り可能な媒体の範囲内に含まれるべきである。
【００２１】
システムメモリ１３０は、読み取り専用メモリ（ＲＯＭ）１３１およびランダムアクセスメモリ（ＲＡＭ）１３２など、揮発性および／または不揮発性メモリの形態におけるコンピュータ記憶媒体を含む。基本入出力システム１３３（ＢＩＯＳ）は、起動中など、コンピュータ１１０内の複数の要素の間で情報を転送する助けとなる基本ルーチンを含み、通常はＲＯＭ１３１に格納される。ＲＡＭ１３２は通常、処理装置１２０によって即時アクセス可能および／または現在演算中であるデータおよび／またはプログラムモジュールを含む。限定ではなく例として、図２に、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６およびプログラムデータ１３７を例示する。
【００２２】
コンピュータ１１０はまた、他の取り外し可能／固定の、揮発性／不揮発性のコンピュータ記憶媒体も含むことができる。単に例として、図２に、固定の、不揮発性の磁気媒体に対する読み書きを行うハードディスクドライブ１４１、取り外し可能な、不揮発性磁気ディスク１５２に対する読み書きを行う磁気ディスクドライブ１５１、および、ＣＤ ＲＯＭまたは他の光媒体など、取り外し可能な、不揮発性の光ディスク１５６に対する読み書きを行う光ディスクドライブ１５５を例示する。例示的なオペレーティング環境で使用することができる他の取り外し可能／固定の、揮発性／不揮発性のコンピュータ記憶媒体には、これに限定されないが、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭなどが含まれる。ハードディスクドライブ１４１は、通常、システムバス１２１にインターフェース１４０などの固定のメモリインターフェースを通じて接続される。磁気ディスクドライブ１５１および光ディスクドライブ１５５は、通常、システムバス１２１にインターフェース１５０などの取り外し可能なメモリインターフェースによって接続される。
【００２３】
上述し、および図２に例示したドライブおよびそれらの関連付けられたコンピュータ記憶媒体は、コンピュータ１１０用のコンピュータ読取り可能な命令、データ構造、プログラムモジュールおよび他のデータの記憶を提供する。図２では、例えば、ハードディスクドライブ１４１は、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６およびプログラムデータ１４７を格納するものとして例示される。これらのコンポーネントを、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６およびプログラムデータ１３７と同じものにも異なるものにもすることができることに留意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６およびプログラムデータ１４７には異なる番号を与え、少なくとも、それらが異なるコピーであることが例示される。ユーザーは、コマンドおよび情報をコンピュータ１１０へ、タブレット（電子デジタイザ）１６４、マイクロフォン１６３、キーボード１６２、および、一般にマウス、トラックボールまたはタッチパッドと呼ばれるポインティングデバイス１６１などの入力装置を通じて入力することができる。他の入力装置（図示せず）には、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナなどが含まれる場合がある。これらおよび他の入力装置は、多くの場合、システムバスに結合されるユーザー入力インターフェース１６０を通じて処理装置１２０へ接続されるが、パラレルポート、ゲームポートまたはユニバーサルシリアルバス（ＵＳＢ）など、他のインターフェースおよびバス構造によって接続することができる。モニタ１９１または他の種類の表示装置もまたシステムバス１２１へ、ビデオインターフェース１９０などのインターフェースを介して接続される。モニタ１９１をまた、タッチスクリーンパネル１９３などと統合することもでき、タッチスクリーンパネル１９３などは、タッチスクリーンインターフェース１９２などのインターフェースを介してコンピュータシステム１１０に手書きするなど、デジタル化された入力を入力することができる。モニタおよび／またはタッチスクリーンパネルは、コンピューティング装置１１０がタブレット型のパーソナルコンピュータ内などに組み込まれたハウジングに、物理的に結合されることができ、タッチスクリーンパネル１９３は、本質的にタブレット１６４としての機能を果たす。加えて、コンピューティング装置１１０などのコンピュータはまた、スピーカ１９５およびプリンタ１９６など、出力周辺インターフェース１９４などを通じて接続することができる他の周辺出力装置を含むこともできる。
【００２４】
コンピュータ１１０は、ネットワーク環境において、リモートコンピュータ１８０など、１つまたは複数のリモートコンピュータへの論理接続を使用して操作することができる。リモートコンピュータ１８０は、パーソナルコンピュータ、サーバー、ルーター、ネットワークＰＣ、ピア装置または他の共通ネットワークノードにすることができる。リモートコンピュータ１８０は、通常、コンピュータ１１０に関連して上述した要素の多数またはすべてを含むが、メモリ記憶装置１８１のみが図２において例示されている。図２に示す論理接続には、ローカルエリアネットワーク（ＬＡＮ）１７１およびワイドエリアネットワーク（ＷＡＮ）１７３が含まれるが、他のネットワークが含まれる可能性もある。このようなネットワーキング環境は、オフィス、企業規模のコンピュータネットワーク、イントラネットおよびインターネットにおいて一般的である。
【００２５】
ＬＡＮネットワーキング環境において使用するとき、コンピュータ１１０は、ＬＡＮ１７１へ、ネットワークインターフェースまたはアダプタ１７０を通じて接続される。ＷＡＮネットワーキング環境において使用するとき、コンピュータ１１０は、通常、モデム１７２、またはインターネットなどのＷＡＮ１７３を介して通信を確立するための他の手段を含む。モデム１７２を内部または外部にすることができ、システムバス１２１へ、ユーザー入力インターフェース１６０または他の適切なメカニズムを介して接続することができる。ネットワーク環境では、コンピュータ１１０に関連して示したプログラムモジュールまたはその一部を、リモートメモリ記憶装置に格納することができる。限定ではなく例として、図２に、リモートアプリケーションプログラム１８５をメモリ装置１８１上に存在するものとして例示する。図示のネットワーク接続は例示的であり、複数のコンピュータの間で通信リンクを確立する他の手段を使用することができることは理解されよう。
【００２６】
（ビジュアルツリー階層を処理するためのソフトウェア環境）
図３は、その中でビジュアルツリーを処理することができる、汎用階層化アーキテクチャ２００を表す。図３に表すように、プログラムコード２０２（例えば、アプリケーションプログラムまたはオペレーティングシステムコンポーネントなど）を、１つまたは複数の様々な方法でグラフィックスデータを出力するように開発することができる。これらの方法には、イメージング２０４を介すること、ベクトルグラフィック要素２０６を介すること、および／または、本発明の一態様による、ビジュアルアプリケーションプログラミングインターフェース（ＡＰＩ）レイヤ２１２に直接出されたファンクション／メソッドコールを介することが含まれる。一般に、イメージング２０４は、プログラムコード２０２に画像、例えばビットマップを読み込み、編集し、およびセーブするための機構を提供する。後述のように、これらの画像を、システムの他の部分によって使用することができ、プリミティブ描画コードを使用して画像を直接描画するための方法もある。ベクトルグラフィックス要素２０６は、オブジェクトモデルの残りとの整合性を有して、グラフィックスを描画するためのもう１つの方法を提供する（後述）。ベクトルグラフィック要素２０６を、マークアップ言語を介して作成することができ、要素／プロパティシステム２０８およびプレゼンタシステム２１０はこれを解釈して、ビジュアルＡＰＩレイヤ２１２への適切な呼び出しを行う。
【００２７】
グラフィックスレイヤアーキテクチャ２００は、高レベル合成およびアニメーションエンジン２１４を含む。高レベル合成およびアニメーションエンジン２１４は、キャッシングデータ構造２１６を含み、あるいはそうでない場合はキャッシングデータ構造２１６に関連付けられる。キャッシングデータ構造２１６は、シーングラフを含む。このシーングラフは、後述のように定義済オブジェクトモデルに従って管理される、階層的に配列されたオブジェクトを備える。一般に、ビジュアルＡＰＩレイヤ２１２は、プログラムコード２０２（およびプレゼンタシステム２１０）に、オブジェクトの作成、データをオブジェクトに提供するためのオブジェクトの開閉などを行う能力を含む、キャッシングデータ構造２１６へのインターフェースを提供する。すなわち、高レベル合成およびアニメーションエンジン２１４は、統一された媒体ＡＰＩレイヤ２１２を公開し、それによって開発者は、グラフィックス情報を表示するためにグラフィックスおよび媒体についての意図を表現し、下にあるプラットフォームに十分な情報を提供して、プラットフォームがハードウェアの使用をプログラムコードに合わせて最適化できるようにすることができる。例えば、下にあるプラットフォームは、キャッシング、リソースネゴシエーション、および媒体統合を担うようになる。
【００２８】
高レベル合成およびアニメーションエンジン２１４は、命令ストリームおよび場合によっては他のデータ（例えば、ビットマップへのポインタ）を、高速の低レベル合成およびアニメーションエンジン２１８に渡す。本明細書で使用されるとき、「高レベル」および「低レベル」という用語は、他のコンピューティングシナリオで使用されるものに類似しており、一般に、あるソフトウェアコンポーネントがより高いコンポーネントに対して低いほど、そのコンポーネントはハードウェアにより近い。したがって、例えば、高レベル合成およびアニメーションエンジン２１４から送信されたグラフィックス情報は低レベル合成およびアニメーションエンジン２１８で受信される可能性があり、この情報は、ハードウェア２２２を含むグラフィックスサブシステムにグラフィックスデータを送信するために使用される。
【００２９】
高レベル合成およびアニメーションエンジン２１４はプログラムコード２０２と共に、シーングラフを構築して、プログラムコード２０２によって提供されたグラフィックス場面を表現する。例えば、描画されるべき各項目を描画命令と共に読み込むことができ、これをシステムはシーングラフデータ構造２１６内にキャッシュすることができる。後述するように、このデータ構造２１６および何が描画されるかを指定するための、いくつかの様々な方法がある。さらに、高レベル合成およびアニメーションエンジン２１４はタイミングおよびアニメーションシステム２２０と統合して、宣言型（または他の）アニメーション制御（例えば、アニメーション間隔）およびタイミング制御を提供する。アニメーションシステムは、アニメート値が本質的にシステム内のいかなる場所にも渡されることを可能にし、これらの場所には例えば、要素プロパティレベル２０８において、ビジュアルＡＰＩレイヤ２１２の内部、および、他のリソースのいずれかの内部が含まれる。タイミングシステムは、要素およびビジュアルレベルで公開される。
【００３０】
低レベル合成およびアニメーションエンジン２１８は、場面の合成、アニメートおよびレンダリングを管理し、次いで場面はグラフィックスサブシステム２２２に提供される。低レベルエンジン２１８は、多数のアプリケーションの場面のためのレンダリングを構成し、レンダリングコンポーネントと共に、場面へのグラフィックスの実際のレンダリングを実施する。しかし、時には、レンダリングの一部がより高いレベルで起こることが必要および／または有利である場合があることに留意されたい。例えば、より低いレイヤは、多数のアプリケーションからの要求を提供するが、より高いレイヤは、アプリケーションごとにインスタンス化され、それにより、イメージング機構２０４を介して、時間のかかる、またはアプリケーション特有のレンダリングをより高いレベルで実行し、ビットマップへの参照をより低いレイヤに渡すことが可能である。
【００３１】
図４および５は、ｖｉｓｕａｌと呼ばれるベースオブジェクトを含む、シーングラフの例３００および４００をそれぞれ示す。一般に、ｖｉｓｕａｌは、仮想面をユーザーに表現するオブジェクトを備え、ビジュアル表現をディスプレイ上で有する。図４に表すように、トップレベル（またはルート）ｖｉｓｕａｌ３０２は、ｖｉｓｕａｌ ｍａｎａｇｅｒオブジェクト３０４に接続され、ｖｉｓｕａｌ ｍａｎａｇｅｒオブジェクト３０４はまた（例えば、ハンドルを介して）、ウィンドウ（ＨＷｎｄ）３０６、または、その中でグラフィックデータがプログラムコードのために出力される類似の単位との関係も有する。ＶｉｓｕａｌＭａｎａｇｅｒ３０４は、そのウィンドウ３０６へのトップレベルｖｉｓｕａｌ（およびそのｖｉｓｕａｌのいかなる子も）の描画を管理する。描画するため、ｖｉｓｕａｌ ｍａｎａｇｅｒ３０４はシーングラフを、ディスパッチャ３０８によってスケジュールされたように処理（例えば、トラバースまたは送信）し、グラフィックス命令および他のデータを、その対応するウィンドウ３０６のための低レベルコンポーネント２１８（図３）に提供する。シーングラフ処理は通常、ディスパッチャ３０８によって、低レベルコンポーネント２１８および／またはグラフィックスサブシステム２２２のリフレッシュレートより比較的遅いレートでスケジュールされるようになる。図４は、トップレベル（ルート）ｖｉｓｕａｌ３０２より階層的に低く配列されたいくつかの子ｖｉｓｕａｌ３１０〜３１５を示し、子ｖｉｓｕａｌのいくつかは、描画コンテキスト３１６、３１７（それらの一時的性質を表すために破線のボックスとして図示）を介して、例えば描画プリミティブおよび他のｖｉｓｕａｌを含む、関連付けられた命令リスト３１８および３１９を取り込んでいるように表現される。これらのｖｉｓｕａｌはまた他のプロパティ情報を含む場合もあり、これを以下のｖｉｓｕａｌクラスの例に示す。
【００３２】
【表１】
【００３３】
表１に示すように、ｖｉｓｕａｌは、ｔｒａｎｓｆｏｒｍ、ｃｌｉｐ、ｏｐａｃｉｔｙ、および場合によっては、設定することができ、かつ／またはｇｅｔメソッドを介して読むことができる他のプロパティを規定することによってサービスを提供する。加えて、ｖｉｓｕａｌは、それがどのようにヒットテストに参加するかを制御するフラグを有する。Ｓｈｏｗプロパティは、ｖｉｓｕａｌを表示する／隠すために使用され、例えば、偽であるときにはｖｉｓｕａｌは不可視であり、そうでない場合はｖｉｓｕａｌは可視である。
【００３４】
ｔｒａｎｓｆｏｒｍプロパティによって設定された変換は、ｖｉｓｕａｌのサブグラフのための座標系を定義する。変換前の座標系は変換前座標系と呼ばれ、変換後の座標系は変換後座標系と呼ばれ、すなわち、変換を有するｖｉｓｕａｌは、親として変換ノードを有するｖｉｓｕａｌに相当する。ビジュアルツリーおよび合成システムのより完全な説明は、上記で相互参照されたVISUAL AND SCENE GRAPH INTERFACEという名称の関連特許出願に含まれる。
【００３５】
（モデル３Ｄ ＡＰＩ処理）
図６は、３Ｄ場面、この場合はオートバイの２次元ビューをレンダリングするためのモデル３Ｄ ＡＰＩにより構築された、例示的な３Ｄ場面ツリー階層を示す。このツリーは、モデル３Ｄ ＡＰＩ内の様々な構造データオブジェクトの使用を例示する。オートバイのためのツリーの抽象またはルートノードは、オブジェクト６０２である。この抽象オブジェクトは４つの子、すなわちライトオブジェクト６０４、ボディグループオブジェクト６０６、ホイールグループオブジェクト６０８、および計器Ｖｉｓｕａｌ Ｍｏｄｅｌ３Ｄオブジェクト６１０を有する。
【００３６】
ボディグループオブジェクトは、オートバイのボディを構成する３つの子を有し、これらはフレームプリミティブオブジェクト６１２、エンジンプリミティブオブジェクト６１４およびガスタンクプリミティブオブジェクト６１６である。これらの各プリミティブオブジェクトは、オブジェクトに由来するオートバイのボディ要素を描画するようになる。ホイールグループオブジェクト６０８は、フロントホイールグループオブジェクト６１８およびリアホイールグループオブジェクト６２０を収集する。ホイールプリミティブオブジェクト６２４は、ホイールの３Ｄモデルを描画する。フロントホイールグループオブジェクト６１８は、ホイールプリミティブオブジェクト６２４によって描画されるべきホイールをフロントホイールに変換するための、３Ｄ変換６１９を有する。同様に、リアホイールグループオブジェクト６２０は、ホイールプリミティブオブジェクト６２４によって描画されるべきホイールをリアホイールに変換するための、３Ｄ変換６２１を有する。加えて、ホイールグループオブジェクト６０８に含まれる３Ｄ変換６２２がある。変換オブジェクト６２２は例えば、フロントプリミティブオブジェクト６１８およびリアプリミティブオブジェクト６２０の実行を変換して、ホイールをアニメーション効果のために回転させることができる。
【００３７】
モデル３Ｄオブジェクトのこの例示的ツリーを、図７に例示する論理演算の演算フローによって処理することができる。本発明の実施形態の論理演算は、（１）コンピューティングシステム上で実行するコンピュータ実装動作またはプログラムモジュールのシーケンスとして、かつ／または（２）コンピューティングシステム内で相互接続されたマシン論理回路または回路モジュールとして実施される。この実施は、本発明を実施するコンピューティングシステムのパフォーマンス要件に依存する、選択できることである。したがって、本明細書で説明する本発明の実施形態を構成する論理演算は、演算、構造装置、動作またはモジュールと様々に呼ばれる。これらの演算、構造装置、動作およびモジュールをソフトウェア内、ファームウェア内、専用デジタル論理内、およびそのいかなる組合せにおいても、本明細書に付属の特許請求の範囲内で列挙されるような本発明の趣旨および範囲から逸脱することなく実装することができることは、当業者には理解されよう。
【００３８】
図７で、演算フローはカメラビュー設定演算７０２で開始する。カメラ位置は、ｖｉｓｕａｌ ３Ｄオブジェクト２２（図１）によって提供される。トラバース演算７０４は、オブジェクトに達するまでツリーの枝を下がるように探索する。通常は、ツリーを下がるように左から右に向かって探索する。グループテスト演算７０６は、オブジェクトがグループオブジェクトであるか、リーフオブジェクトであるかを検出する。それがグループオブジェクトである場合、演算フローはグループオブジェクト演算処理７０８に枝分かれする。演算７０８は、オブジェクト内に含まれた任意のグループ演算を処理するようになる。変換３Ｄ演算は、グループ演算の例である。さらなるオブジェクトテスト演算７１０は、ツリー内にさらにオブジェクトがあるか否かを検出し、少なくとももう１つのオブジェクトがある場合、フローをトラバース演算７０４に戻す。
【００３９】
次のオブジェクトがリーフオブジェクトである場合、演算フローはグループテスト演算７０６からライトオブジェクトテスト演算７１２に枝分かれする。リーフオブジェクトがライトオブジェクトである場合、演算フローは次いで、ライトオブジェクトテスト演算７１２からイルミネーション設定演算７１４へのＹＥＳに枝分かれする。演算７１４はライトオブジェクトを処理して、３Ｄ場面のためのイルミネーションを設定する。次いで、演算フローはさらなるリーフオブジェクトテスト演算７１６に進む。リーフオブジェクトがライトオブジェクトでない場合、演算フローはプリミティブ／ビジュアルモデルオブジェクトテスト演算７１８に移動する。リーフオブジェクトがプリミティブオブジェクトである場合、演算フローはプリミティブ描画演算７２０に枝分かれし、その後、さらなるリーフオブジェクトテスト演算７１６に枝分かれする。プリミティブ描画演算７２０は、プリミティブオブジェクトによって指定された３Ｄモデルを描画するようになる。リーフオブジェクトがＶｉｓｕａｌ Ｍｏｄｅｌ３Ｄオブジェクトである場合、演算フローはビジュアルモデル描画演算７２２に枝分かれし、その後、さらなるリーフオブジェクトテスト演算７１６に枝分かれする。ビジュアルモデル描画演算７２２は、Ｖｉｓｕａｌ Ｍｏｄｅｌ３Ｄオブジェクトによって指定されたビジュアルモデルを描画するようになる。
【００４０】
グループ内にさらにリーフオブジェクトがある場合、さらなるリーフオブジェクトテスト演算７１６は、演算フローをリーフトラバース演算７２４に枝分かれさせる。トラバース演算７２４は、同じグループオブジェクトの下の次の子へと、ツリーを歩く。ライトオブジェクトテスト演算７１２およびプリミティブ／ビジュアルモデルテスト演算７１８は、次のリーフがライトオブジェクトであるか、プリミティブオブジェクトであるか、ビジュアルモデルオブジェクトであるかを検出する。検出されたリーフオブジェクトは、上述の繰り返しのように処理される。同じグループオブジェクトの子である、すべてのリーフオブジェクトが処理された後、演算フローはテスト演算７１６からさらなるオブジェクトテスト演算７１０へのＮＯに枝分かれする。さらに処理するべきオブジェクトがある場合、演算フローはトラバース演算７０４に戻る。そうでない場合、モデル３Ｄツリーは処理されており、演算フローは戻り７２６を通過して、３Ｄ場面の処理の呼び出し側に戻る。
【００４１】
図６の３Ｄ場面ツリーの実施例では、最初に到達されたオブジェクトはライトオブジェクトである。以下のＭｏｄｅｌ ３Ｄ ＡＰＩ定義において定義されるように、ライトオブジェクトは、３Ｄ場面を照らすライト型を指定する。最初のリーフノードであるライトオブジェクトに到達するとき、グループオブジェクトテスト演算７０６は、そのオブジェクトがリーフオブジェクトであることを検出し、演算フリーはライトオブジェクトテスト演算７０８に枝分かれする。ライトオブジェクト６０４はテスト演算７０８によって検出され、イルミネーション設定演算７１４は、ライトオブジェクトによって実行されて、３Ｄ場面のイルミネーションが設定される。次いで、フローは、さらなるリーフオブジェクトテスト演算７１６およびさらなるオブジェクトテスト演算７１０を通じて、トラバース演算７０４に戻る。
【００４２】
トラバース演算７０４は、図６のツリーを下がるように、ボディグループオブジェクト６０６まで歩く。このとき、グループテスト演算はフローをグループ演算処理７０８に枝分かれさせて、そのボディグループ用であるグループオブジェクト６０６内のいかなる演算をも実行する。次いで、フローは再度トラバース演算７０４に戻り、トラバース演算は枝をボディグループオブジェクト６０６からフレームプリミティブオブジェクト６０２へ、下がるように歩く。フレームプリミティブオブジェクト６０２は、上述のように、演算フローがテスト演算７０６、７１２および７１８を通じて枝分かれした後、プリミティブ描画演算７２０によって処理されるようになる。エンジンプリミティブオブジェクト６１４およびガスタンクプリミティブオブジェクト６１６は、演算フローがさらなるリーフオブジェクトテスト７１６を通じてループバックし、次のリーフオブジェクト演算７２４ならびにテスト演算７１２および７１８にトラバースするとき、処理されるようになる。ボディグループオブジェクトノード６０６からのすべてのリーフが処理されるとき、トラバース演算７０４はツリーを、ホイールグループオブジェクト６０８へと探索する。
【００４３】
ホイールグループオブジェクトおよびその子の処理は、ボディグループオブジェクトおよびその子の処理と同じであるが、ただし、ホイールボディグループオブジェクト６０８はＴｒａｎｓｆｏｒｍ３Ｄオブジェクト６２２を含む。Ｔｒａｎｓｆｏｒｍ３Ｄオブジェクトは、オートバイの画像のホイールをアニメーションにするために使用することができる。ホイールボディグループオブジェクト６０８を処理するとき、演算フローは、Ｔｒａｎｓｆｏｒｍ３Ｄオブジェクト６２２を検出すると、グループオブジェクトテスト演算７０６からグループ演算処理７０８に枝分かれするようになる。グループ演算処理７０８は、オブジェクト６２２の変換演算を実行して、オートバイのホイールを回転させるようにする。
【００４４】
図６の例示的な３Ｄ場面ツリー内で処理される最後のオブジェクトは、計器Ｖｉｓｕａｌ Ｍｏｄｅｌ３Ｄオブジェクト６１０である。ツリーのホイールグループブランチが処理された後、トラバース演算７０４はツリーを、計器オブジェクト６１０へと探索するようになる。図７の演算フローでは、フローは、計器Ｖｉｓｕａｌ Ｍｏｄｅｌ３Ｄオブジェクト６１０を検出するとき、テスト演算７０６、７１２および７１８を通じて、ビジュアルモデル描画演算７２２に移動する。ビジュアルモデル描画演算７２２は、オブジェクト６１０によって指定されたビジュアルモデルを描画する。これで、図７の演算による、図６の３Ｄ場面ツリーの処理が完了する。
【００４５】
（Ｍｏｄｅｌ ３Ｄ ＡＰＩ定義）
以下のＡＰＩは、Ｍｏｄｅｌ ３Ｄオブジェクトについて定義される。
【００４６】
図１のオブジェクト２２など、Ｖｉｓｕａｌ３Ｄオブジェクトは、本質的にちょうど以下の通りである。
・ライトを含む３Ｄの集合（レンダリング命令／シーングラフ／メタファイル）
・その場面の２Ｄ投影を定義するためのカメラ、
・投影をマッピングするためのローカルの座標空間内の長方形の２Ｄビューポート、および
・アンチエイリアシングスイッチ、フォグスイッチなどのような他のアンビエントパラメータ。
【００４７】
（３Ｄへのレンダリング）
２Ｄのように、レンダリングは、呼び出しが行われるところのＤｒａｗｉｎｇＣｏｎｔｅｘｔを介して起こる。例えば、２Ｄでは、以下のようになる。
【００４８】
【表２】
【００４９】
２Ｄとの一貫性を保つために、３Ｄにおける類似のモデルは以下のようになる。
【００５０】
【表３】
【００５１】
このレンダリングのモデルは、保存モード３Ｄビジュアル（「命令」が単に保存される場合）、および、即時モード３Ｄビジュアル（レンダリングが直接起こり、カメラを前もって設置する必要がある場合）の両方について、うまくいくことに留意されたい。実際に、保存モードの場合、内部で起こることは、３Ｄモデリング階層が構築および保存されていることである。別法として、即時モードの場合、このようなことは起こっておらず、命令が直接発行されており、コンテキストスタック（例えば、変換用）が維持されている。
【００５２】
（サンプルコード）
これは、３Ｄ Ｖｉｓｕａｌ ＡＰＩによるプログラミングのフレーバを示すための一実施例である。
【００５３】
この実施例の単純に作成されたＶｉｓｕａｌ３Ｄは、それにレンダリングするための描画コンテキストをグラブし、プリミティブおよびライトをそれにレンダリングし、カメラを設定し、ｖｉｓｕａｌを、制御のｖｉｓｕａｌの子に追加する。
【００５４】
【表４−１】
【００５５】
【表４−２】
【００５６】
（モデリングＡＰＩ）
上記は、描画「命令」がコンテキストに発行される「命令的レンダリング」使用スタイルを示す。これは宣言的使用ではなく、要素／マークアップセクションに達するとき、この命令的手法が宣言マークアップのために適切ではないことがわかるであろう。
【００５７】
したがって、ブラシ、ペン、ジオメトリ、パスなどにより、３Ｄ「リソース」を、２Ｄ内に存在するように構築および使用する宣言的方法がある。
【００５８】
そのために、ユーザーが、３Ｄ命令ストリームに入るものを構築することができる、いくつかの型が導入され、コンテキストを使用するのではなく、構築されたオブジェクトをＶｉｓｕａｌ３Ｄに設定することができる。
【００５９】
例えば、上記のＤｒａｗｉｎｇ３ＤＣｏｎｔｅｘｔベースのサンプルコードを、以下のように書き換えることができる。
【００６０】
【表５】
【００６１】
ここで、我々は実にモデルを構築しており、次いで、このモデルをＶｉｓｕａｌ３Ｄに割り当てている。ＰｕｓｈＴｒａｎｓｆｏｒｍ／Ｐｏｐのペアは、それ自体で変換およびその下のＭｏｄｅｌを有するＭｏｄｅｌ３ＤＧｒｏｕｐの構築によって置き換えられる。
【００６２】
さらに、このモデリング手法および命令コンテキストに基づく手法の両方を提供する目的は、混乱させることではなく、むしろ以下についての解決法を提供することである。
・要素レベルの宣言マークアップ
・ビジュアル列挙
・シーングラフ効果
・ビジュアルコンテンツの修正可能性
【００６３】
（モデリングクラス階層）
図１は、モデリングクラス階層を例示する。モデリングクラスツリーのルートはＭｏｄｅｌ３Ｄであり、Ｍｏｄｅｌ３Ｄは、Ｖｉｓｕａｌ３Ｄに付加することができる３次元モデルを表す。最終的に、ライト、メッシュ、（ファイル、リソース、メモリなどから来ることができる）．Ｘファイルストリーム、モデルのグループ、および、３Ｄ位置付けされた２Ｄビジュアルは、すべてモデルである。したがって、以下の階層を有する。
・Ｍｏｄｅｌ３Ｄ
・Ｍｏｄｅｌ３ＤＧｒｏｕｐ−Ｍｏｄｅｌ３Ｄのグループを１単位として扱うためのコンテナ
・Ｐｒｉｍｉｔｉｖｅ３Ｄ
・MeshPrimitive3D(mesh,material,hitTestID)
・ImportedPrimitive3D(stream,hitTestID)（．ｘファイル用）
・Ｌｉｇｈｔ
・AmbientLight
・SpecularLight
・DirectionalLight
・PointLight
・SpotLight
・ＶｉｓｕａｌＭｏｄｅｌ３Ｄ−ＶｉｓｕａｌおよびＰｏｉｎｔ３およびｈｉｔＴｅｓｔＩＤを有する
Ｍｏｄｅｌ３Ｄクラス自体は、以下の演算をサポートする。
・３Ｄ境界ボックスを得る。
・Ｍｏｄｅｌ３ＤのＴｒａｎｓｆｏｒｍを得て設定する。
・シェーディングモードなど、他の「ノード」レベルプロパティを得て設定する。
・ｈｉｔＴｅｓｔＯｂｊｅｃｔを得て設定する。
【００６４】
（ビジュアルＡＰＩ指定）
最初に、各型について明示的にリストされないが、これらの型のいずれもが以下のメソッドを有することに留意されたい（ここではＶｅｃｔｏｒ３Ｄについて示すが、他のあらゆるものにも適用可能）。
【００６５】
【表６】
【００６６】
また、Ｃｈａｎｇｅａｂｌｅから（直接的または間接的に）派生するあらゆる型は、「ｐｕｂｌｉｃ ｎｅｗ ＭｙＴｙｐｅ Ｃｏｐｙ（）」メソッドをその上に有することが必要となる。
【００６７】
（プリミティブタイプ）
これらのプリミティブ型は単に、このセクションで説明する他の型のサポートにおいて存在する。
【００６８】
（Ｐｏｉｎｔ３Ｄ）
Ｐｏｉｎｔ３Ｄは、２Ｄ Ｐｏｉｎｔ ｔｙｐｅ Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ（登録商標）．Ｐｏｉｎｔに直接類似するものである。
【００６９】
【表７】
【００７０】
ＴｙｐｅＣｏｎｖｅｒｔｅｒ指定
【００７１】
【表８−１】
【００７２】
【表８−２】
【００７３】
（Ｖｅｃｔｏｒ３Ｄ）
Ｖｅｃｔｏｒ３Ｄは、２Ｄ Ｖｅｃｔｏｒ ｔｙｐｅ Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ（登録商標）．Ｖｅｃｔｏｒに直接類似するものである。
【００７４】
【表９】
【００７５】
ＴｙｐｅＣｏｎｖｅｒｔｅｒ指定
【００７６】
【表１０】
（Ｐｏｉｎｔ４Ｄ）
Ｐｏｉｎｔ４Ｄは第４のｗコンポーネントを３Ｄポイントにアドインし、非アフィンＭａｔｒｉｘ３Ｄを通じた変換のために使用される。１の「ｗ」コンポーネントは、Ｐｏｉｎｔ３Ｄにトランスレートし、０の「ｗ」コンポーネントは、Ｖｅｃｔｏｒ３Ｄにトランスレートするので、Ｖｅｃｔｏｒ４Ｄはない。
【００７７】
【表１１】
ＴｙｐｅＣｏｎｖｅｒｔｅｒ指定
【００７８】
【表１２】
【００７９】
（Ｑｕａｔｅｒｎｉｏｎ）
Ｑｕａｔｅｒｎｉｏｎは、はっきりと、３次元における回転を表す３Ｄエンティティである。その指数は、平滑で信頼性のある補間を達成するために複数の４元数の間で補間する（および、したがってアニメションにする）ことが可能となる。特定の補間メカニズムは、球面線形補間（またはＳＬＥＲＰ）として知られている。
【００８０】
Ｑｕａｔｅｒｎｉｏｎは、それらのコンポーネント（ｘ、ｙ、ｚ、ｗ）の直接の指定から、または、軸／角度表現として構築することができる。最初の表現は結果として、非正規化された４元数となる場合があり、これについて特定の演算は意味を成さない（例えば、軸および角度の抽出）。
【００８１】
Ｑｕａｔｅｒｎｉｏｎが構築された後にＱｕａｔｅｒｎｉｏｎのコンポーネントを設定することはできず、これは、それを行うことにおいて潜在的な曖昧さがあるからである。（例えば、Ａｎｇｌｅを非正規化されたＱｕａｔｅｒｎｉｏｎ上に設定することに何の意味があるか。）
【００８２】
【表１３−１】
【００８３】
【表１３−２】
【００８４】
ＴｙｐｅＣｏｎｖｅｒｔｅｒ指定
【００８５】
【表１４】
【００８６】
（Ｍａｔｒｉｘ３Ｄ）
Ｍａｔｒｉｘ３Ｄは、Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ（登録商標）．Ｍａｔｒｉｘに類似する３Ｄである。Ｍａｔｒｉｘのように、大部分のＡＰＩはＭａｔｒｉｘ３Ｄを取らないが、むしろＴｒａｎｓｆｏｒｍ３Ｄを取り、これは深い方法でアニメーションをサポートする。
【００８７】
３Ｄ計算のための行列は４ｘ４行列として表される。ＭＩＬは行ベクトル構文を使用する。
【００８８】
【表１５】
【００８９】
行列がある点により乗算されるとき、行列はその点を、新しい座標系から以前の座標系へ変換する。
【００９０】
変換をいかなるレベルにもネストさせることができる。新しい変換が適用されるときは常に、これは、現在の変換行列上にそれを前から掛ける（ｐｒｅ−ｍｕｌｔｉｐｌｙｉｎｇ）することと同じである。
【００９１】
【表１６−１】
【００９２】
【表１６−２】
【００９３】
ＴｙｐｅＣｏｎｖｅｒｔｅｒ指定
【００９４】
【表１７】
【００９５】
（Ｔｒａｎｓｆｏｒｍ３Ｄクラス階層）
Ｔｒａｎｓｆｏｒｍ３Ｄは、２Ｄ Ｔｒａｎｓｆｏｒｍのように、３Ｄ変換の特定の型を表す具象サブクラスを有する抽象ベースクラスである。
【００９６】
Ｔｒａｎｓｆｏｒｍ３Ｄの特定のサブクラスもまた、アニメーションが入るところである。
【００９７】
Ｔｒａｎｓｆｏｒｍ３Ｄの全体の階層はこのようになり、これを図８に示す。
Transform3D
----Transform3DCollection
----AffineTransform3D
--------TranslateTransform3D
--------ScaleTransform3D
--------RotateTransform3D
----MatrixTransform3D
（Ｔｒａｎｓｆｏｒｍ３Ｄ）
【００９８】
ルートのＴｒａｎｓｆｏｒｍ３Ｄオブジェクト８０２は、Ｔｒａｎｓｆｏｒｍの特定のクラスを構築するためのある興味深い静的メソッドを有する。このオブジェクトはＭａｔｒｉｘ３Ｄ表現を公開せず、これはこのＴｒａｎｓｆｏｒｍがそれよりも幅広い可能性があるからであることに留意されたい。
【００９９】
【表１８−１】
【０１００】
【表１８−２】
【０１０１】
Ｐｏｉｎｔ３Ｄ／Ｖｅｃｔｏｒ３Ｄを取るＴｒａｎｓｆｏｒｍ（）メソッドは、変換がアフィンでない場合、例外を引き起こすようになることに留意されたい。
【０１０２】
（Ｔｒａｎｓｆｏｒｍ３ＤＣｏｌｌｅｃｔｉｏｎ）
Ｔｒａｎｓｆｏｒｍ３Ｄ ｃｏｌｌｅｃｔｉｏｎオブジェクト８０４は、ｖｉｓｕａｌ ２ＤにおけるＴｒａｎｓｆｏｒｍＣｏｌｌｅｃｔｉｏｎを正確にまねるようになり、Ａｄｄメソッドは、上記のＣｒｅａｔｅメソッドと同じように修正される。
【０１０３】
【表１９】
【０１０４】
（ＡｆｆｉｎｅＴｒａｎｓｆｏｒｍ３Ｄ）
Ａｆｆｉｎｅ Ｔｒａｎｓｆｏｒｍ３Ｄオブジェクト８０６は単に、すべての具象アフィン３Ｄ変換（ｔｒａｎｓｌａｔｅ、ｓｋｅｗ、ｒｏｔａｔｅ、ｓｃａｌｅ）が派生する元のベースクラスであり、Ｍａｔｒｉｘ３Ｄへの読み取りアクセスを公開する。
【０１０５】
【表２０−１】
【０１０６】
【表２０−２】
【０１０７】
（ＴｒａｎｓｌａｔｅＴｒａｎｓｆｏｒｍ３Ｄオブジェクト８０８）
【０１０８】
【表２１】
【０１０９】
（ＳｃａｌｅＴｒａｎｓｆｏｒｍ３Ｄオブジェクト８１２）
【０１１０】
【表２２】
【０１１１】
（ＲｏｔａｔｅＴｒａｎｓｆｏｒｍ３Ｄ）
ＲｏｔａｔｅＴｒａｎｓｆｏｒｍ３Ｄオブジェクト８１２は、それを中心に回転するための軸の概念の導入（および、したがって４元数の使用）による、２Ｄ回転からの単なる単純マッピングだけではない。
【０１１２】
【表２３−１】
【０１１３】
【表２３−２】
【０１１４】
ここではＱｕａｔｅｒｎｉｏｎプロパティのみがアニメメーションにすることが可能であることに留意されたい。一般に、軸／角度のアニメーションはうまく行く傾向がない。４元数をよりよくアニメーションにするために、軸および角度を４元数のベース値から抽出することができる。単に角度を固定軸に対してアニメーションにすることを望む場合、これを指定する容易な方法は、これらの位置を表す２つの４元数を構築し、それらの４元数の間でアニメーションにすることである。
【０１１５】
（ＭａｔｒｉｘＴｒａｎｓｆｏｒｍ３Ｄ）
ＭａｔｒｉｘＴｒａｎｓｆｏｒｍ３Ｄオブジェクト８１４は、Ｔｒａｎｓｆｏｒｍ３ＤをＭａｔｒｉｘ３Ｄから直接構築する。
【０１１６】
【表２４】
【０１１７】
（Ｔｒａｎｓｆｏｒｍ３Ｄ ＴｙｐｅＣｏｎｖｅｒｔｅｒ）
Ｔｒａｎｓｆｏｒｍ３Ｄタイプのプロパティがマークアップで指定されるとき、プロパティシステムはＴｒａｎｓｆｏｒｍ型コンバータを使用して、文字列表現を適切なＴｒａｎｓｆｏｒｍ派生オブジェクトに変換する。アニメーションにされたプロパティを、この構文を使用して記述する方法はないが、複合プロパティ構文をアニメーション記述のために使用することができる。
【０１１８】
（構文）
この構文は、２Ｄ Ｔｒａｎｓｆｏｒｍからモデリングされる。＜＞は任意選択のパラメータを表す。
【０１１９】
・matrix(m00 m01 m02 m03 m11...m33)
・translate(tx ty tz)
・scale(sx <sy> <sz> <cx> <cy> <cz>)
・＜ｓｙ＞または＜ｓｚ＞が指定されない場合、これは均等スケールであると仮定される。
【０１２０】
・＜ｃｘ＞＜ｃｙ＞＜ｃｚ＞が指定される場合、これらはすべて指定される必要があり、＜ｓｘ＞＜ｓｙ＞も同様である。これらはスケーリング中心のために使用される。これらが使用されない場合、中心は０、０、０であると仮定される。
【０１２１】
・rotate(ax ay az angle <cx> <cy> <cz>)
・ａｘ、ａｙ、ａｚは回転の角度を指定する
・角度は、その軸を通じた角度である
・ｃｘ、ｃｙ、ｃｚが指定されない場合、これは０、０、０であると仮定される。
【０１２２】
・skew(angleX angleY angleZ <cx> <cy> <cz>)
・ｃｘ、ｃｙ、ｃｚが指定されない場合、これは０、０、０であると仮定される。
【０１２３】
文法
【０１２４】
【表２５−１】
【０１２５】
【表２５−２】
【０１２６】
（Ｖｉｓｕａｌ３Ｄ）
図１のＶｉｓｕａｌ３Ｄオブジェクト２２はＶｉｓｕａｌ２Ｄから派生し、そのように行う際に、以下を含むそのプロパティのすべてを得る。
【０１２７】
・オパシティ
・２Ｄジオメトリッククリップ
・２Ｄブレンドモード
・ヒットテストＡＰＩ
・２Ｄバウンドクエリ
・ビジュアルツリーにおける参加
オパシティ、クリップ、ブレンドモードおよびバウンドのすべては３Ｄ場面の２Ｄ投影に適用されることに留意されたい。
【０１２８】
【表２６】
【０１２９】
ＶｉｅｗＰｏｒｔボックスは、Ｃａｍｅｒａ／Ｍｏｄｅｌの組合せによって決定された投影が２Ｄローカル座標空間内のどこにマップするかを確立する。
【０１３０】
（Ｄｒａｗｉｎｇ３ＤＣｏｎｔｅｘｔ）
Ｄｒａｗｉｎｇ３ＤＣｏｎｔｅｘｔは実に、２Ｄ Ｄｒａｗｉｎｇ Ｃｏｎｔｅｘｔに類似しており、Ｖｉｓｕａｌ３ＤのＭｏｄｅｌ３ＤＣｏｌｌｅｃｔｉｏｎから、ＲｅｎｄｅｒＯｐｅｎ／ＲｅｎｄｅｒＡｐｐｅｎｄを介してアクセス可能である。これは命令を内部で保存中であるとしても、即時モードレンダリングコンテキストのような感じである。
【０１３１】
【表２７】
【０１３２】
これらのＤｒａｗｉｎｇ３ＤＣｏｎｔｅｘｔ演算の意味体系の具体的な詳細については、モデリングＡＰＩのセクションを参照されたい。モデリングＡＰＩのために、Ｄｒａｗｉｎｇ３ＤＣｏｎｔｅｘｔは実際には単に好都合なものである。例えば、ＤｒａｗＩｍｐｏｒｔｅｄＰｒｉｍｉｔｉｖｅ（ＩｍｐｏｒｔｅｄＰｒｉｍｉｔｉｖｅ３ＤＳｏｕｒｃｅ ｐｒｉｍｉｔｉｖｅＳｏｕｒｃｅ、ｏｂｊｅｃｔＨｉｔＴｅｓｔＴｏｋｅｎ）は単にＩｍｐｏｒｔｅｄＰｒｉｍｉｔｉｖｅ３Ｄを作成し、これを、現在累積中のＭｏｄｅｌ３Ｄに追加する（現在累積中のＭｏｄｅｌ３Ｄは、コンテキストにおいてＰｕｓｈ／Ｐｏｐメソッドによって操作される）。
【０１３３】
ＤｒａｗＭｏｄｅｌ（）は、「コンテキスト」ワールドと「モデリング」ワールドの間のもう１つのクロスオーバーポイントであり、Ｍｏｄｅｌ３Ｄがコンテキストに「描画」されることを可能にする。
【０１３４】
Ｄｒａｗｉｎｇ３ＤＣｏｎｔｅｘｔからの明示的な「リードバック」はない。これは、それが単にＭｏｄｅｌ３ＤＧｒｏｕｐにそれを支援させているからであり、常にその集合を列挙することができるからである。
【０１３５】
（モデリングＡＰＩ）
これは、これらのクラスのためのパブリックおよび保護されたＡＰＩであり、継承されたメンバを示さない。
【０１３６】
（Ｍｏｄｅｌ３Ｄ）
図１のＭｏｄｅｌ３Ｄオブジェクト１０は、あらゆるものがそこから構築される抽象モデルオブジェクトである。
【０１３７】
【表２８】
【０１３８】
（Ｍｏｄｅｌ３ＤＧｒｏｕｐ）
図１のＭｏｄｅｌ３ＤＧｒｏｕｐオブジェクト１８は、モデルの組合せを構築し、これらを単位として扱い、任意選択で変換するか、あるいは他の属性をこれらに適用する。
【０１３９】
【表２９】
【０１４０】
またＭｏｄｅｌ３ＤＧｒｏｕｐは、ＲｅｎｄｅｒＯｐｅｎ／Ａｐｐｅｎｄをも有し、ＲｅｎｄｅｒＯｐｅｎ／Ａｐｐｅｎｄは、Ｄｒａｗｉｎｇ３ＤＣｏｎｔｅｘｔを戻すことに留意されたい。このコンテキストの使用は、Ｍｏｄｅｌ３ＤＣｏｌｌｅｃｔｉｏｎ自体を修正する。ＲｅｎｄｅｒＯｐｅｎ（）とＲｅｎｃｅｒＡｐｐｅｎｄ（）の間の違いは、ＲｅｎｄｅｒＯｐｅｎ（）がコレクションを最初にクリアすることである。
【０１４１】
また、一度にただ１つのＤｒａｗｉｎｇ３ＤＣｏｎｔｅｘｔのみをＭｏｄｅｌ３ＤＧｒｏｕｐ上で開くことができ、Ｄｒａｗｉｎｇ３ＤＣｏｎｔｅｘｔが開かれるとき、アプリケーションはそのＭｏｄｅｌ３ＤＧｒｏｕｐのコンテンツに（読み取りまたは書き込みのために）直接アクセスすることができないことにも留意されたい。
【０１４２】
（Ｌｉｇｈｔ階層）
Ｌｉｇｈｔオブジェクトは、Ｍｏｄｅｌ３Ｄオブジェクトである。Ｌｉｇｈｔオブジェクトには、Ａｍｂｉｅｎｔ、Ｐｏｓｉｔｉｏｎａｌ、ＤｉｒｅｃｔｉｏｎａｌおよびＳｐｏｔ ｌｉｇｈｔが含まれる。これらは実にＤｉｒｅｃｔ３Ｄライティング群においてモデリングされるが、モデリング階層の一部であるという追加のプロパティを有し、したがって、座標空間変換を受ける。
【０１４３】
アンビエント、ディフューズおよびスペキュラー色はすべてのライトにおいて提供される。
【０１４４】
ｌｉｇｈｔ階層はこのようになり、これをまた図９にも示す。
【０１４５】
Model3D
----Light（抽象）
--------AmbientLight（具象）
--------DirectionalLight（具象）
--------PointLight（具象）
------------SpotLight（具象）
ベースのｌｉｇｈｔオブジェクト９０２クラスは、単に以下を有する抽象クラスである。
【０１４６】
【表３０】
【０１４７】
（ＡｍｂｉｅｎｔＬｉｇｈｔ）
Ａｍｂｉｅｎｔ ｌｉｇｈｔオブジェクト９０４はモデルを、それらの形状にかかわらず、均等に明るくする。
【０１４８】
【表３１】
【０１４９】
（ＤｉｒｅｃｔｉｏｎａｌＬｉｇｈｔ）
ｄｉｒｅｃｔｉｏｎａｌ ｌｉｇｈｔオブジェクト９０６からの指向性ライトは、空間における位置を有しておらず、それらのライトを、それを定義するベクトルによって指定された特定の方向に沿って投影する。
【０１５０】
【表３２】
【０１５１】
方向が正規化される必要はないが、方向もまたゼロでない大きさを有していなければならない。
【０１５２】
（ＰｏｉｎｔＬｉｇｈｔ）
ｐｏｉｎｔ ｌｉｇｈｔオブジェクト９０８からの定位置ライトは、空間における位置を有し、それらのライトをすべての方向に投影する。ライトの減少は、ａｔｔｅｎｕａｔｉｏｎおよびｒａｎｇｅプロパティによって制御される。
【０１５３】
【表３３】
【０１５４】
（ＳｐｏｔＬｉｇｈｔ）
ＳｐｏｔＬｉｇｈｔは、位置、範囲および減衰を有するので、ＰｏｉｎｔＬｉｇｈｔから派生するが、ライトの「コーン」を制御するための方向およびパラメータもアドインする。「コーン」を制御するために、ｏｕｔｅｒＣｏｎｅＡｎｇｌｅ（何ものもこれを越えて照らされない）およびｉｎｎｅｒＣｏｎｅＡｎｇｌｅ（その内部のあらゆるものが完全に照らされる）が指定されなければならない。内部コーンの外側と外部コーンの間のライティングは線形に減少する。（ここで可能性のある混乱の原因は、２つの減少がここで進行中であり、一方が内部コーンの端と外部コーンの間の「角度」であり、他方がライトの位置に対する距離におけるものであり、減衰および範囲によって影響されることである。）
【０１５５】
【表３４】
【０１５６】
角度は度で指定されることに留意されたい。
【０１５７】
（Ｐｒｉｍｉｔｉｖｅ３Ｄ）
図１のＰｒｉｍｉｔｉｖｅ３Ｄオブジェクト１２は、ツリー内のレンダリングの結果となるリーフノードである。具象クラスは、明示的に指定されたメッシュ、ならびに、インポートされたプリミティブ（．ｘファイル）を取り込む。
【０１５８】
【表３５】
【０１５９】
（ＭｅｓｈＰｒｉｍｉｔｉｖｅ３Ｄ）
ＭｅｓｈＰｒｉｍｉｔｉｖｅ３Ｄは、メッシュおよびマテリアルによるモデリング用である。
【０１６０】
【表３６】
【０１６１】
ＭｅｓｈＰｒｉｍｉｔｉｖｅ３Ｄはリーフジオメトリであり、Ｍｅｓｈを含むが、それ自体はＭｅｓｈではないことに留意されたい。これは、メッシュデータを複製することなく、異なるヒットテストを受ける、異なるマテリアルを有する、複数のＭｅｓｈＰｒｉｍｉｔｉｖｅ３Ｄの間で、Ｍｅｓｈを共有することができることを意味する。
【０１６２】
（ＩｍｐｏｒｔｅｄＰｒｉｍｉｔｉｖｅ３Ｄ）
ＩｍｐｏｒｔｅｄＰｒｉｍｉｔｉｖｅ３Ｄは、取り込まれて適切な内部形式に変換された、外部から獲得されたプリミティブ（潜在的にマテリアルおよびアニメーションを有する）を表す。ＩｍｐｏｒｔｅｄＰｒｉｍｉｔｉｖｅ３Ｄは、Ａｖａｌｏｎによって厳格なモデルとして扱われる。これの標準的な例は．Ｘファイルであり、Ｘファイルを明示的にインポートするＩｍｐｏｒｔｅｄＰｒｉｍｉｔｉｖｅ３ＤＳｏｕｒｃｅのサブクラスがある。
【０１６３】
【表３７】
【０１６４】
ＩｍｐｏｒｔｅｄＰｒｉｍｉｔｉｖｅ３ＤのためのＴｙｐｅＣｏｎｖｅｒｔｅｒ
．ｘファイルは場面内に含まれるので、これを表現するための単純なＴｙｐｅＣｏｎｖｅｒｔｅｒは、以下にようなものになるはずである。
【０１６５】
【表３８】
【０１６６】
（ＶｉｓｕａｌＭｏｄｅｌ３Ｄ）
ＶｉｓｕａｌＭｏｄｅｌ３ＤはいかなるＶｉｓｕａｌ（定義により、２Ｄ）をも取り、これを場面内に入れる。レンダリングされるとき、これはスクリーンに合わせられ、そのサイズは影響を受けないが、カメラから特定のｚ平面にあるようになる。Ｖｉｓｕａｌはインタラクティブなままとなる。
【０１６７】
【表３９】
【０１６８】
ＶｉｓｕａｌＭｏｄｅｌ３Ｄのレンダリングは、最初にＣｅｎｔｅｒＰｏｉｎｔをワールド座標に変換する。これは次いでＶｉｓｕａｌをピクセルバッファへ、スクリーンに合わせられる方法でレンダリングし、変換されたＣｅｎｔｅｒＰｏｉｎｔのｚは、ビジュアルの中心が配置されるところになる。カメラの動きの下で、ＶｉｓｕａｌＭｏｄｅｌ３Ｄは常に同じ量のスクリーンリアルエステートを占有するようになり、常に前を向き、ライトなどによって影響を受けないようになる。場面の残りに対するビジュアルのこのカメラの動きの中の固定点は、配置がその点に基づいて起こるので、ビジュアルの中心となる。
【０１６９】
提供されたＶｉｓｕａｌは完全にインタラクティブであり、事実上、それを囲むＶｉｓｕａｌ３Ｄが「親に当たる」（これは、Ｖｉｓｕａｌが単一の親しか有することができないのと同然に、所与のＶｉｓｕａｌをいずれかのＶｉｓｕａｌＭｏｄｅｌ３Ｄにおいて一度しか使用することができないことを意味することに留意されたい）。
【０１７０】
（Ｍｅｓｈ３Ｄ）
Ｍｅｓｈ３Ｄプリミティブは、プログラム的に構築することができる直接的なトライアングルプリミティブ（インデックス付きおよびインデックスなしの指定を可能にする）である。Ｍｅｓｈ３Ｄプリミティブは位置、標準、色およびテクスチャ情報をサポートし、最後の３つは任意選択であることに留意されたい。メッシュはまた、それが三角形として表示されるべきであるか、線として表示されるべきであるか、点として表示されるべきであるかの選択も可能にする。メッシュはまた、インデックスを解釈するための３つのトポロジもサポートし、これらはトライアングルリスト、トライアングルストリップおよびトライアングルファンである。
【０１７１】
Ｍｅｓｈ３Ｄによって直接サポートされない頂点フォーマットおよび他のプリミティブ構造では、．ｘファイルを構築およびインポートすることができる。
【０１７２】
【表４０】
【０１７３】
ＭｅｓｈＰｒｉｍｉｔｉｖｅＴｙｐｅは以下のように定義される。
【０１７４】
【表４１】
【０１７５】
（Ｍｅｓｈデータの解釈）
Ｍｅｓｈ３Ｄにおける頂点単位のデータは、Ｐｏｓｉｔｉｏｎｓ、Ｎｏｒｍａｌｓ、ＣｏｌｏｒｓおよびＴｅｘｔｕｒｅＣｏｏｒｄｉｎａｔｅｓに分割される。言うまでもなく、Ｐｏｓｉｔｉｏｎｓのみが必要とされる。他のいずれかが提供される場合、これらはＰｏｓｉｔｉｏｎｓコレクションと正確に同じ長さを有していなければならず、そうでない場合、例外が引き起こされるようになる。
【０１７６】
Ｎｏｒｍａｌｓが提供される場合、正規化されると仮定される。正規化が望まれるとき、これらは供給されなければならない。
【０１７７】
ＴｒｉａｎｇｌｅＩｎｄｉｃｅｓコレクションは、メッシュを構成する三角形のための頂点単位の情報を決定するために頂点データに索引付けするメンバを有する。この集合は、ＭｅｓｈＰｒｉｍｉｔｉｖｅＴｙｐｅの設定に基づいて解釈される。これらの解釈は、Ｄｉｒｅｃｔ３Ｄにおけるものと正確に同じである。ＴｒｉａｎｇｌｅＬｉｓｔでは、ＴｒｉａｎｇｌｅＩｎｄｉｃｅｓ集合内の３つおきの要素が新しい三角形を定義する。ＴｒｉａｎｇｌｅＦａｎでは、インデックス０、１、２が最初の三角形を決定し、次いで後続の各インデックスｉが、頂点０、ｉ、ｉ−１によって与えられた新しい三角形を決定する。ＴｒｉａｎｇｌｅＳｔｒｉｐでは、インデックス０、１、２が最初の三角形を決定し、後続の各インデックスｉが、頂点ｉ−２、ｉ−１およびｉによって与えられた新しい三角形を決定する。ＬｉｎｅＬｉｓｔ、ＬｉｎｅＳｔｒｉｐおよびＰｏｉｎｔＬｉｓｔは類似の解釈を有するが、レンダリングは、三角形ではなく線および点に関する。
【０１７８】
ＴｒｉａｎｇｌｅＩｎｄｉｃｅｓがヌルである場合、Ｍｅｓｈはインデックスなしプリミティブとして実装され、これは、長さｎのＰｏｓｉｔｉｏｎｓ集合について値０、１、．．．、ｎ−２、ｎ−１を保持するＴｒｉａｎｇｌｅＩｎｄｉｃｅｓに等しい。
【０１７９】
（Ｍｅｓｈの構築およびデータ複製の回避）
Ｍｅｓｈを構築した上で、この実装は、このメッシュを表す最適なＤ３Ｄ構造を作成する。この時点で、実際のＣｏｌｌｅｃｔｉｏｎデータ構造を、Ｍｅｓｈ実装によってスローして、データの複製を回避することができる。ある他の機構（例えば、Ｖｉｓｕａｌ３Ｄモデル階層をトラバースすること）を通じてアクセスされた場合のメッシュの後続のリードバックは、元のデータを保存するのではなく、その上に保持されているＤ３Ｄ情報からデータを再構築する可能性が高くなる。
【０１８０】
（Ｍｅｓｈの変更可能性）
メッシュはＣｈａｎｇｅａｂｌｅから派生し、したがって修正することができる。この実装では、群を頂点およびインデックスデータにトラップし、これらの変更をＤ３Ｄデータ構造に伝搬させることが必要となる。
【０１８１】
（ＭｅｓｈのためのＴｙｐｅＣｏｎｖｅｒｔｅｒ）
他のすべての型と同様に、ＸＡＭＬ複合プロパティ構文を使用して、Ｍｅｓｈ３Ｄを定義するコレクションを指定することができる。しかし、指定をより簡潔にするために、ＴｙｐｅＣｏｎｖｅｔｅｒが提供される。
【０１８２】
メッシュ内で定義された各集合は、この集合を作成するために解析および使用されるべき一連の数を取ることができる。例えば、索引付きトライアングルストリップを位置および色のみにより表すＭｅｓｈを、以下のように指定することができる。
【０１８３】
【表４２】
【０１８４】
言うまでもなく、これらのいかなるものも、複合プロパティ構文においてはるかにより冗長に表現される可能性がある。
【０１８５】
（Ｍａｔｅｒｉａｌ）
Ｐｒｉｍｉｔｉｖｅ３Ｄを構築するメソッドは、それらの外観を定義するためにＭａｔｅｒｉａｌを取る。Ｍａｔｅｒｉａｌは抽象ベースクラスであり、ＢｒｕｓｈＭａｔｅｒｉａｌ、ＶｉｓｕａｌＭａｔｅｒｉａｌ、およびＡｄｖａｎｃｅｄＭａｔｅｒｉａｌという３つの具象サブクラスを有する。ＢｒｕｓｈＭａｔｅｒｉａｌおよびＶｉｓｕａｌＭａｔｅｒｉａｌは、ＢａｓｉｃＭａｔｅｒｉａｌと呼ばれるもう１つの抽象クラスのサブクラスである。したがって、以下の通りである。
【０１８６】
Material
----BasicMaterial
--------BrushMaterial
--------VisualMaterial
----AdvancedMaterial
【０１８７】
・ＢｒｕｓｈＭａｔｅｒｉａｌは、単に単一のＢｒｕｓｈを取り、幅広い範囲の効果のために使用することができ、これらの効果には、透過性を達成すること（ピクセル単位またはスカラ単位のいずれか）、テクスチャ変換（アニメーションにするのものでも）を有すること、ビデオテクスチャを使用すること、暗黙の自動生成ＭＩＰマッピングなどが含まれる。具体的には、単一色、画像、グラディエント、または、さらにもう１つのＶｉｓｕａｌのテクスチャリングでは、単にＳｏｌｉｄＣｏｌｏｒＢｒｕｓｈ、ＩｍａｇｅＢｒｕｓｈ、ＧｒａｄｉｅｎｔＢｒｕｓｈまたはＶｉｓｕａｌＢｒｕｓｈを使用して、それらのＢｒｕｓｈＭａｔｅｒｉａｌを作成するようになる。
【０１８８】
・ＶｉｓｕａｌＭａｔｅｒｉａｌは特に、Ｖｉｓｕａｌからマテリアルを構築するために設計される。このマテリアルは、入力がＶｉｓｕａｌへ、それが埋め込まれる３Ｄワールドから渡されるという意味で、インタラクティブとなる。これと、ＶｉｓｕａｌＢｒｕｓｈを有するＢｒｕｓｈＭａｔｅｒｉａｌの間の違いについて疑問に思うかもしれない。この違いは、ＢｒｕｓｈＭａｔｅｒｉａｌがインタラクティブでないということである。
【０１８９】
・ＡｄｖａｎｃｅｄＭａｔｅｒｉａｌクラスは、単にＢｒｕｓｈＭａｔｅｒｉａｌまたは、ＶｉｓｕａｌＭａｔｅｒｉａｌを使用するよりもかなり複雑であるが、さらに多くの柔軟性を提供する。しかし、非３Ｄ−ＥｉｎｓｔｅｉｎはＡｄｖａｎｃｅｄＭａｔｅｒｉａｌについて知る必要はなく、単にＢｒｕｓｈＭａｔｅｒｉａｌ／ＶｉｓｕａｌＭａｔｅｒｉａｌを使用して、達成することを望む大部分のことを達成することができる。
【０１９０】
【表４３】
【０１９１】
Ｍａｔｅｒｉａｌは、Ｂｒｕｓｈに基づくことによって、大変な柔軟性および「概念の節約」を得る。具体的には、以下の通りである。
【０１９２】
・ビデオテクスチャ、グラディエントテクスチャなどのようなものを反映する別々のＴｅｘｔｕｒｅ階層がある必要はなく、これは、これらがすべてＢｒｕｓｈとして指定可能であるからである。
【０１９３】
・Ｂｒｕｓｈはすでにアルファマスクおよびスカラオパシティ値をカプセル化しており、そのため、これらは両方ともテクスチャリングに使用可能となる。
【０１９４】
・Ｂｒｕｓｈはすでに、それに関連付けられた２Ｄ Ｔｒａｎｓｆｏｒｍを有しており、２Ｄ Ｔｒａｎｓｆｏｒｍは、テクスチャリングの場合、メッシュ内のｕｖ座標をテクスチャにマップするように変換するためのテクスチャ変換として解釈されるようになる。
【０１９５】
・Ｂｒｕｓｈは、将来、ウッドグレインシェーダなどのストック手順シェーダをハングするための正しい場所である。これは次いで、２Ｄにおいて塗りつぶしまたはペンとして、また３Ｄにおいてテクスチャとして使用可能となる。特定のＡＰＩサポートが３Ｄ空間において手順シェーダのために与えられる必要はない。
【０１９６】
ＴｅｘｔｕｒｅＴｒａｎｓｆｏｒｍプロパティは、ＢｒｕｓｈＭａｔｅｒｉａｌまたはＶｉｓｕａｌＭａｔｅｒｉａｌの定義の内部に存在する可能性のあるいかなる変換からも別個であることに留意されたい。ＴｅｘｔｕｒｅＴｒａｎｓｆｏｒｍプロパティは、問題のＭａｔｅｒｉａｌからテクスチャ座標空間（その範囲は［０，０］から［１，１］）への変換を指定する。Ｍａｔｅｒｉａｌ内部の変換はＴｅｘｔｕｒｅＴｒａｎｓｆｏｒｍと結合して、１ｘ１（テクスチャ座標における）のＭａｔｅｒｉａｌがＭｅｓｈを介してどのようにマップされるかを記述する。
【０１９７】
（シェーダ）
「ストック」シェーダのセットの多くはパラメータ化されており、ＡＰＩにおいて以下のようにアクセス可能である。
【０１９８】
１）２Ｄワールド内で意味を成すシェーダでは、シェーダはＢｒｕｓｈの具象サブクラスとして公開されるようになり、それらのパラメータ化はクラス上のコンストラクタを通じて、あるいはクラス上のプロパティとして表現される。次いでシェーダを２Ｄオブジェクトに適用することができる。
【０１９９】
２）３Ｄ内でしか意味を成さないシェーダでは、シェーダはＭａｔｅｒｉａｌまたはＢａｓｉｃＭａｔｅｒｉａｌの具象サブクラスとして公開され、そこでシェーダをまた、それらのコンストラクタを通じてパラメータ化することもできる。
【０２００】
この公開は次いで、シェーダが３Ｄ（および、適切なところでは２Ｄ）メッシュに適用されることを可能にするようになる。
【０２０１】
（ＢｒｕｓｈＭａｔｅｒｉａｌ）
上述のように、ＢｒｕｓｈＭａｔｅｒｉａｌは単にＢｒｕｓｈをカプセル化する。Ｐｒｉｍｉｔｉｖｅ３Ｄに適用されたＢｒｕｓｈＭａｔｅｒｉａｌは、テクスチャとして扱われる。テクスチャは直接マッピングされるようになり、すなわち、マッピングされているプリミティブにおける２Ｄのｕ，ｖ座標は、テクスチャ変換によって修正された、Ｔｅｘｔｕｒｅ上の対応するｘ，ｙ座標に直接索引付けするようになる。Ａｖａｌｏｎにおけるすべての２Ｄのように、テクスチャの座標系は左上の（０，０）から出て、正のｙが下を指すことに留意されたい。
【０２０２】
Ｂｒｕｓｈのために使用されたＶｉｓｕａｌＢｒｕｓｈは入力を受け入れないようになるが、その上のいかなるアニメーションにも、またはそれに起こったいかなる構造上の変更にも従って更新するようになる。ＶｉｓｕａｌをＭａｔｅｒｉａｌとして使用し、なお入力を受信するためには、後述のＶｉｓｕａｌＭａｔｅｒｉａｌを使用する。
【０２０３】
【表４４】
【０２０４】
（ＶｉｓｕａｌＭａｔｅｒｉａｌ）
上述のように、ＶｉｓｕａｌＭａｔｅｒｉａｌはインタラクティブなＶｉｓｕａｌをカプセル化する。これは、Ｖｉｓｕａｌと共に使用されたＢｒｕｓｈＭａｔｅｒｉａｌとは、Ｖｉｓｕａｌがそのテクスチャリングされた形式で残る点で異なる。Ｖｉｓｕａｌは次いで、事実上、ある方法でルートのＶｉｓｕａｌ３Ｄが親に当たることに留意されたい。単一のＵＩＥｌｅｍｅｎｔを複数のＭａｔｅｒｉａｌで使用すること、または、ＶｉｓｕａｌＭａｔｅｒｉａｌを複数の場所で使用することは、正しくない。
【０２０５】
【表４５】
【０２０６】
（ＡｄｖａｎｃｅｄＭａｔｅｒｉａｌ）
ＢｒｕｓｈＭａｔｅｒｉａｌ／ＶｉｓｕａｌＭａｔｅｒｉａｌおよびＢｕｍｐＭａｐは、ＡｄｖａｎｃｅｄＭａｔｅｒｉａｌを定義するために使用される。
【０２０７】
【表４６】
【０２０８】
ＥｎｖｉｒｏｎｍｅｎｔＭａｐは、キューブマッピングを可能にするための特定のフォーマットであると予期されるテクスチャであることに留意されたい。具体的には、キューブマップの６面が、Ｔｅｘｔｕｒｅに関連付けられたＢｒｕｓｈの周知のセクションにおいて表現されることが必要となる（Ｂｒｕｓｈ上の３ｘ２グリッドのようなものである可能性が高い）。
【０２０９】
Ａｍｂｉｅｎｔ、ＤｉｆｆｕｓｅおよびＳｐｅｃｕｌａｒプロパティは、ＢａｓｉｃＭａｔｅｒｉａｌを取り、汎用のＭａｔｅｒｉａｌを取らず、これは、これらがＡｄｖａｎｃｅｄＭａｔｅｒｉａｌそのものとして指定されないからである。また、環境マップはＢｒｕｓｈＭａｔｅｒｉａｌであることにも留意されたい。
【０２１０】
（ＢｕｍｐＭａｐ定義）
Ｂｕｍｐマップは、テクスチャのように、３Ｄプリミティブ上に、プリミティブ上のテクスチャ座標を介してマップされるグリッドである。しかし、補間データは表面の標準への摂動として解釈され、結果としてプリミティブの「でこぼこ」な外観となる。これを達成するため、バンプマップは、標準摂動などの情報、および潜在的に他の情報を伝える。バンプマップは色または透過性情報を伝えない。このため、Ｂｒｕｓｈをバンプマップとして使用することは不適当である。
【０２１１】
したがって、新しいＢｕｍｐＭａｐクラスを導入し、これは特定のピクセルフォーマットのＩｍａｇｅＳｏｕｒｃｅとなる。
【０２１２】
【表４７】
【０２１３】
（ＭａｔｅｒｉａｌのためのＴｙｐｅＣｏｎｖｅｒｔｅｒ）
Ｍａｔｅｒｉａｌは、Ｂｒｕｓｈの文字列指定が自動的にＢｒｕｓｈＭａｔｅｒｉａｌにプロモートされることを可能にする、単純なＴｙｐｅＣｏｎｖｅｒｔｅｒを提供する。
【０２１４】
【表４８】
【０２１５】
これは以下のような指定を可能にする。
【０２１６】
【表４９】
【０２１７】
（「アンビエント」パラメータ）
このセクションでは、ジオメトリック階層内の任意のレベルで埋め込み可能ではないモデルの「アンビエント」パラメータを考察する。
【０２１８】
（Ｆｏｇ）
ＦｏｇプロパティをＶｉｓｕａｌ３Ｄ上に設定することによって、Ｆｏｇを場面に追加することができる。使用可能なＦｏｇは「ピクセルフォグ」である。Ｆｏｇは、抽象クラス、および以下に示すような階層として表現される。
【０２１９】
【表５０】
【０２２０】
ｆｏｇＤｅｎｓｉｔｙは０〜１の範囲であり、フォグの密度の正規化表現である。
【０２２１】
ｆｏｇＳｔａｒｔおよびｆｏｇＥｎｄは装置空間［０，１］内で指定されたｚ深度であり、フォグが開始および終了するところを表す。
【０２２２】
（Ｃａｍｅｒａ）
図１のＣａｍｅｒａオブジェクト３２は、３Ｄモデルが２Ｄビジュアル上に投影される機構である。Ｃａｍｅｒａ自体は抽象タイプであり、２つのサブクラスはＰｒｏｊｅｃｔｉｏｎＣａｍｅｒａおよびＭａｔｒｉｘＣａｍｅｒａである。ＰｒｏｊｅｃｔｉｏｎＣａｍｅｒａ自体は抽象クラスであり、２つの具象サブクラスのＰｅｒｓｐｅｃｔｉｖｅＣａｍｅｒａおよびＯｒｔｈｏｇｏｎａｌＣａｍｅｒａを有する。ＰｅｒｓｐｅｃｔｉｖｅＣａｍｅｒａは、Ｐｏｓｉｔｉｏｎ、ＬｏｏｋＡｔＰｏｉｎｔおよびＦｉｅｌｄＯｆＶｉｅｗなどのよく理解されたパラメータを取り、Ｃａｍｅｒａを構築する。ＯｒｔｈｏｇｏｎａｌＣａｍｅｒａはＰｅｒｓｐｅｃｔｉｖｅＣａｍｅｒａに類似しており、ただしＯｒｔｈｏｇｏｎａｌＣａｍｅｒａはＦｉｅｌｄＯｆＶｉｅｗの代わりにＷｉｄｔｈを取る。ＭａｔｒｉｘＣａｍｅｒａは、Ｗｏｒｌｄ−Ｔｏ−Ｄｅｖｉｃｅ変換を定義するために使用されたＭａｔｒｉｘ３Ｄを取る。
【０２２３】
【表５１】
【０２２４】
Ｖｉｓｕａｌ３Ｄで、ＣａｍｅｒａはビューをＭｏｄｅｌ３Ｄ上に提供するために使用され、結果として生じる投影は、Ｖｉｓｕａｌ３Ｄ上で確立された２Ｄ ＶｉｅｗＰｏｒｔにマップされる。
【０２２５】
また、Ｖｉｓｕａｌ３Ｄの２Ｄ境界ボックスは単に、その凸の、軸に合わせられた包によりラップされ、ビジュアル上で確立されたクリップにクリップされた、３Ｄモデルの投影された３Ｄボックスとなる。
【０２２６】
（ＰｒｏｊｅｃｔｉｏｎＣａｍｅｒａ）
図１のＰｒｏｊｅｃｔｉｏｎＣａｍｅｒａオブジェクト３９は、ＰｅｒｓｐｅｃｔｉｖｅＣａｍｅｒａおよびＯｒｔｈｏｇｏｎａｌＣａｍｅｒａが派生する元の抽象親である。ＰｒｏｊｅｃｔｉｏｎＣａｍｅｒａオブジェクト３９は、ＭＩＬ（媒体統合レイヤ）がサポートするＰｒｏｊｅｃｔｉｏｎＣａｍｅｒａの両方の型に共通である、位置、見る方向および上方向などのプロパティをカプセル化する。
【０２２７】
【表５２−１】
【０２２８】
【表５２−２】
【０２２９】
（ＰｅｒｓｐｅｃｔｉｖｅＣａｍｅｒａ）
図１のＰｅｒｓｐｅｃｔｉｖｅＣａｍｅｒａオブジェクト３６は、それによってＰｏｓｉｔｉｏｎ、ＬｏｏｋＡｔＰｏｉｎｔおよびＦｉｅｌｄＯｆＶｉｅｗなどのよく理解されたパラメータから透視投影カメラが構築される手段である。以下の例示は、ＰｅｒｓｐｅｃｔｉｖｅＣａｍｅｒａの関連する態様のよい指示を提供する。
【０２３０】
【表５３】
【０２３１】
【表５４】
【０２３２】
以下に留意されたい。
・ＰｅｒｓｐｅｃｔｉｖｅＣａｍｅｒａは、位置、見る方向および上ベクトルプロパティをＰｒｏｊｅｃｔｉｏｎＣａｍｅｒａから継承する。
・ＦｉｅｌｄＯｆＶｉｅｗは水平視野を表し、度で指定される（他のすべてのＭＩＬ角と同様）。
・ＮｅａｒおよびＦａｒ ＰｌａｎｅＤｉｓｔａｎｃｅは、カメラのＰｏｓｉｔｉｏｎから、ＬｏｏｋＤｉｒｅｃｔｉｏｎ点によって定義されたベクトルに沿った、３Ｄワールド座標距離を表す。ＮｅａｒＰｌａｎｅＤｉｓｔａｎｃｅのデフォルトは０であり、ＦａｒＰｌａｎｅＤｉｓｔａｎｃｅのデフォルトは無限となる。
・実際の投影の上で、Ｎｅａｒ／ＦａｒＰｌａｎｅＤｉｓｔａｎｃｅがなおそれぞれ０／無限である場合、モデルが検査され、その境界ボリュームはカメラの投影に従って投影される。結果として生じる境界ボリュームが次いで検査され、近平面距離は、カメラ位置に最も近いＬｏｏｋＤｉｒｅｃｔｉｏｎに垂直な境界ボリュームの平面に設定されるようになる。遠平面についても同じであるが、最も遠い平面を使用する。これは結果として、なおモデル全体を表示しながら、ｚバッファ解決の最適な使用となる。
【０２３３】
ＰｅｒｓｐｅｃｔｉｖｅＣａｍｅｒａのパラメータによって定義された「投影面」は次いでＶｉｓｕａｌ３Ｄ上のＶｉｅｗＰｏｒｔ長方形にマッピングされること、および、３空間から２空間への最終移行を表すことに留意されたい。
【０２３４】
（ＯｒｔｈｏｇｏｎａｌＣａｍｅｒａ）
図１のＯｒｔｈｏｇｏｎａｌＣａｍｅｒａオブジェクト３７は、ワールドから装置空間への垂直投影を指定する。ＰｅｒｓｐｅｃｔｉｖｅＣａｍｅｒａのように、ＯｒｔｈｏｇｏｎａｌＣａｍｅｒａ、すなわち垂直カメラは、位置、見る方向、および上方向を指定する。しかし、ＰｅｒｓｐｅｃｔｉｖｅＣａｍｅｒａとは異なり、ＯｒｔｈｏｇｏｎａｌＣａｍｅｒａは、透視短縮を含まない投影を記述する。物理的には、ＯｒｔｈｏｇｏｎａｌＣａｍｅｒａは、その辺が平行であるビューイングボックスを記述する（ＰｅｒｓｐｅｃｔｉｖｅＣａｍｅｒａは、その辺が最終的にカメラの点に集まるビューイングｆｒｕｓｔｒｕｍを記述する）。
【０２３５】
【表５５−１】
【０２３６】
【表５５−２】
【０２３７】
以下に留意されたい。
・ＯｒｔｈｏｇｏｎａｌＣａｍｅｒａは、位置、見る方向および上ベクトルプロパティをＰｒｏｊｅｃｔｉｏｎＣａｍｅｒａから継承する。
・ＷｉｄｔｈはＯｒｔｈｏｇｏｎａｌＣａｍｅｒａのビューイングボックスの幅を表し、ワールドユニットで指定される。
・ＮｅａｒおよびＦａｒ ＰｌａｎｅＤｉｓｔａｎｃｅは、ＰｅｒｓｐｅｃｔｉｖｅＣａｍｅｒａについて振る舞うのと同じように振る舞う。
【０２３８】
（ＭａｔｒｉｘＣａｍｅｒａ）
図１のＭａｔｒｉｘＣａｍｅｒａオブジェクト３８は、Ｃａｍｅｒａのサブクラスであり、Ｍａｔｒｉｘを投影変換として直接指定することに備える。これは、それら自体の投影行列計算機構を有するアプリケーションにとって有用である。これは明確に、システムの高度な使用を表す。
【０２３９】
【表５６】
【０２４０】
以下に留意されたい。
・ＶｉｅｗＭａｔｒｉｘは、ＭａｔｒｉｘＣａｍｅｒａのための位置、見る方向および上ベクトルを表す。これは、ビルボーディングのために、Ｍｏｄｅｌ３Ｄ階層のトップレベル変換とは異なる場合がある。ＰｒｏｊｅｃｔｉｏｎＭａｔｒｉｘはカメラ空間からの場面を装置空間に変換する。
【０２４１】
ＭｉｎｉｍｕｍＺおよびＭａｘｉｍｕｍＺプロパティは削除されており、これは、これらの値がＭａｔｒｉｘＣａｍｅｒａの投影行列によって暗示されるからである。投影行列は座標系をカメラ空間から、正規化されたキューブへ変換し、ただしＸおよびＹは［−１，１］からの範囲となり、ｚは［０，１］からの範囲となる。カメラ空間内の最低および最大ｚ座標は、投影行列がどのようにｚ座標を変換するかによって定義される。
【０２４２】
結果として生じる投影は、Ｖｉｓｕａｌ３Ｄ上のＶｉｅｗＰｏｒｔ長方形にマップされること、および、３空間から２空間への最終移行を表すことに留意されたい。
【０２４３】
（ＸＡＭＬマークアップの例）
以下は、ＸＡＭＬにおけるＭｏｄｅｌ３Ｄ階層全体の指定を示す、より完全なマークアップである。構文のいくつかは汎用により変わる場合があることに留意されたい。
【０２４４】
（単純なｘファイルインポートおよび合成）
この例は単に、２つのインポートされた．ｘファイル、および、そのうちの１つにおける回転変換を有するＭｏｄｅｌ、ならびに、０、１、０で上に起き上がる単一の白色点ライトを作成する。
【０２４５】
【表５７】
【０２４６】
このとき、このマークアップは次いで、ファイル、ストリーム、リソース、どんなものの中にもあるようになる。クライアントプログラムはそのＸＡＭＬのロードを呼び出すようになり、それにより、アプリケーションによってそれが適合を見るときに使用される、完全なＭｏｄｅｌ３ＤＧｒｏｕｐを構築するようになる。
【０２４７】
（明示的Ｍｅｓｈ宣言）
この例は、明示的に宣言されたＭｅｓｈＰｒｉｍｉｔｉｖｅ３Ｄを、複合プロパティＸＡＭＬ構文の使用を通じて提供する。メッシュは、黄色から赤までのＬｉｎｅａｒＧｒａｄｉｅｎｔによりテクスチャリングされるようになる。
【０２４８】
また、ライトも場面内にある。
【０２４９】
【表５８】
【０２５０】
（．ｘファイル上のアニメーション）
この例は最初の．ｘファイルを取り、ＸＡＭＬ指定のアニメーションをアドインする。この特定のものは、ｘファイルを１ｘから２．５ｘまで５秒に渡ってスケールし、反転し、無期限に繰り返す、均等スケールを追加する。これはまた、そのスケールのスローイン／スローアウトのための加速／減速も使用する。
【０２５１】
【表５９】
【０２５２】
（ＶｉｓｕａｌＭａｔｅｒｉａｌ指定）
この例は．ｘファイルをインポートし、ライブＵＩをそのマテリアルとして適用する。
【０２５３】
【表６０−１】
【０２５４】
【表６０−２】
【０２５５】
（Ｖｉｅｗｐｏｒｔ３ＤのためのＡＰＩ）
Ｖｉｅｗｐｏｒｔ３ＤのためのＡＰＩ指定は、以下の通りである。
【０２５６】
【表６１】
【０２５７】
これで本発明のこの実施形態におけるＭｏｄｅｌ ３Ｄ ＡＰＩ定義を完了する。
【０２５８】
本発明を、コンピュータの構造上の特徴、方法的動作、およびコンピュータ読取り可能な媒体によるものに特有の言語で説明したが、添付の特許請求の範囲で定義された本発明は必ずしも、説明した特定の構造、動作または媒体に限定されないことを理解されたい。したがって、特定の構造上の特徴、動作および媒体は、主張された本発明を実施する例示的実施形態として開示される。
【０２５９】
上述の様々な実施形態は例示としてのみ提供され、本発明を限定するように解釈されるべきではない。本明細書で例示および説明した実施形態および応用例の例に従うことなく、および、以下の特許請求の範囲に示す本発明の真の趣旨および範囲から逸脱することなく、本発明に行われる可能性のある様々な修正および変更は、当業者には容易に理解されよう。
【図面の簡単な説明】
【０２６０】
【図１】本発明の一実施形態による、モデル３Ｄ構築ＡＰＩにおける関連オブジェクトのデータ構造を例示する図である。
【図２】本発明の実施形態を実施することができる、適切なコンピューティングシステム環境の一実施例を例示する図である。
【図３】本発明を組み込むことができるグラフィックスレイヤアーキテクチャを全体的に表すブロック図である。
【図４】シーングラフをトラバースしてグラフィックスコマンドおよび他のデータを提供することによるなど、シーングラフを処理するためのビジュアルおよび関連コンポーネントのシーングラフの表現の図である。
【図５】妥当性検査ビジュアル、描画ビジュアル、および、構築された関連描画プリミティブのシーングラフの表現の図である。
【図６】オートバイを３Ｄ場面としてレンダリングするための例示的Ｍｏｄｅｌ３Ｄツリー階層を例示する図である。
【図７】図６に示されたものなど、３Ｄシーンツリー階層を処理するための演算フローを示す図である。
【図８】Ｍｏｄｅｌ３Ｄグループオブジェクト内に含まれたＴｒａｎｓｆｏｒｍ３Ｄオブジェクトのための関連オブジェクトのデータ構造を示す図である。
【図９】Ｍｏｄｅｌ３Ｄ ＡＰＩ内のライトオブジェクトのための関連オブジェクトのデータ構造を示す図である。
【技術分野】
【０００１】
本発明は、一般にコンピュータグラフィックスの分野に関する。より詳細には、本発明は、３次元場面グラフィックスのためのアプリケーションプログラミングインターフェースに関する。
【背景技術】
【０００２】
コンピュータシステム上のグラフィックスにアクセスする従来のモデルは限界に達しつつあり、これは、メモリおよびバス速度が、メインプロセッサおよび／またはグラフィックスプロセッサの進歩に追いついていないことに１つの要因がある。一般に、ビットマップを用いたフレームの準備のための現在のモデルは、複雑なグラフィックスエフェクトが望まれるときにハードウェアのリフレッシュレートに追いつくために、膨大な量のデータ処理を必要とする。結果として、複雑なグラフィックスエフェクトが従来のグラフィックスモデルを用いて試みられるとき、視覚エフェクトが知覚される結果となる変化を次のフレームに対して適時完了するのではなく、この変化が異なるフレームに亘って追加され、視覚的に望ましくない結果を引き起こす場合がある。
【０００３】
さらに、３次元（３Ｄ）グラフィックスを２次元（２Ｄ）合成システムに導入して、２Ｄ画像および３Ｄ場面を有する混合場面を表示することによって、この問題は悪化される。このような混合システムの実施における問題の中には、３Ｄモデルのためのプログラムオブジェクトをどのように定義するかがある。このプログラムオブジェクトはどのように編成されるべきであるだろうか。
【０００４】
これらの検討事項およびその他に関して、本発明は作られた。
【０００５】
【特許文献１】VISUAL AND SCENE GRAPH INTERFACEという名称の関連特許出願
【発明の開示】
【発明が解決しようとする課題】
【０００６】
上記および他の問題は、コンピュータプログラムオブジェクトに適用されて、ツリー階層を構築し、３Ｄモデルの３次元（３Ｄ）場面をレンダリングするコンピュータデータ構造によって解決される。ツリー階層内のルートオブジェクトは、３Ｄ場面のためのオブジェクトを収集する。ツリー階層内のグループオブジェクトは、ツリー階層内の他のグループオブジェクトおよび描画オブジェクトを収集し、グループオブジェクトによって収集された描画オブジェクトに演算するグループ演算を定義する。ツリー階層内のライトオブジェクトは、３Ｄモデルを３Ｄ場面内でレンダリングする際に使用されるイルミネーションを定義し、１つまたは複数の描画３Ｄオブジェクトは、３Ｄモデルを３Ｄ場面内で描画するための演算を定義する。
【課題を解決するための手段】
【０００７】
本発明の他の態様によれば、本発明は、合成システムによってレンダリングされた３次元（３Ｄ）モデルの２次元（２Ｄ）ビューを描画するための、コンピュータプログラムオブジェクトの階層を処理するための方法に関する。この方法は、オブジェクトの３Ｄ場面ツリー階層の枝をトラバースして、グループオブジェクトおよびリーフオブジェクトを処理する。この方法は、次の未処理オブジェクトがリーフオブジェクトのグループオブジェクトであるか否かを検出する。それがリーフオブジェクトである場合、この方法は、このリーフオブジェクトがライトオブジェクトであるか、描画３Ｄオブジェクトであるかを検出する。リーフオブジェクトがライトオブジェクトである場合、３Ｄ場面のイルミネーションが設定される。描画３Ｄオブジェクトが検出される場合、３Ｄモデルはイルミネーションによって照らされるように描画される。この方法はまた、グループオブジェクトによって収集されたオブジェクトのグループにグループ演算を実行することもできる。
【０００８】
さらに他の態様によれば、本発明は、モデル３Ｄオブジェクトによって定義された３Ｄモデルの３次元（３Ｄ）場面を作成するための、アプリケーションプログラムインターフェースに関する。このインターフェースは、１つまたは複数のグループオブジェクトおよび１つまたは複数のリーフオブジェクトを有する。グループオブジェクトは、他のグループオブジェクトおよび／またはリーフオブジェクトを含むか、あるいは収集する。リーフオブジェクトは、描画オブジェクトであってもイルミネーションオブジェクトであってもよい。グループオブジェクトは、それらのグループ内で収集されたオブジェクトを変換するための変換演算を有することができる。描画オブジェクトは、３Ｄ場面の３Ｄモデルを描画するための命令、または、２Ｄ画像を３Ｄモデル上で描画するための命令を定義する。イルミネーションオブジェクトは、３Ｄモデルを３Ｄ場面内で照らすライトの種類および方向を定義する。
【０００９】
本発明を、コンピュータプロセス、コンピューティングシステムとして、または、コンピュータプログラム製品もしくはコンピュータ読取り可能な媒体などの製品として実施することができる。コンピュータ読取り可能な媒体は、コンピュータシステムによって読取り可能であり、コンピュータプロセスを実行するための命令のコンピュータプログラムをエンコードする、コンピュータ記憶媒体にすることができる。コンピュータ読取り可能な媒体はまた、コンピューティングシステムによって読取り可能であり、コンピュータプロセスを実行するための命令のコンピュータプログラムをエンコードする、キャリア上の伝播信号であってもよい。
【００１０】
本発明を特徴付けるこれらおよび様々な他の特徴ならびに利点は、以下の詳細な説明を読み、関連する図面を見直すことから明らかになるであろう。
【発明を実施するための最良の形態】
【００１１】
図１は、本発明の一実施形態による、Ｍｏｄｅｌ ３Ｄ ＡＰＩを実装するためのコンピュータプログラムオブジェクトのアーキテクチャを例示する。Ｍｏｄｅｌ３Ｄオブジェクト１０は、ルートまたは抽象オブジェクトである。ルートオブジェクトに関係付けられた子である４つの可能なモデル３Ｄオブジェクトがある。これらの３つのオブジェクトは、Ｐｒｉｍｉｔｉｖｅ３Ｄオブジェクト１２、Ｖｉｓｕａｌ Ｍｏｄｅｌ３Ｄオブジェクト１４、およびＬｉｇｈｔオブジェクト１６であり、このアーキテクチャではリーフオブジェクトである。Ｍｏｄｅｌ３ＤＧｒｏｕｐオブジェクト２０は、リーフオブジェクトまたは他のグループオブジェクトのための、ツリー内の収集ノードであり、Ｔｒａｎｓｆｏｒｍ３Ｄオブジェクト１８も含む。Ｔｒａｎｓｆｏｒｍ３Ｄオブジェクトは、それに関連付けられた変換オブジェクトの階層を有する。
【００１２】
Ｐｒｉｍｉｔｉｖｅ３Ｄオブジェクトは、メッシュ情報２６およびマテリアル情報２８を含み、これらの情報もまたオブジェクトの階層を参照または示して、Ｐｒｉｍｉｔｉｖｅ３Ｄオブジェクト１２によって描画される３Ｄモデルの定義を支援することができる。Ｖｉｓｕａｌ Ｍｏｄｅｌ３Ｄオブジェクト１４は、３Ｄ場面に組み込むための２Ｄ画像を定義する。Ｌｉｇｈｔオブジェクト１６は、３Ｄ場面用のイルミネーションを定義し、様々な照明状態を定義するためのオブジェクトの階層を有する。これらのすべてのオブジェクトは以下で、Ｍｏｄｅｌ ３Ｄ ＡＰＩ定義において定義される。
【００１３】
図１のオブジェクトは、モデル３Ｄ場面ツリー、すなわち、３Ｄ場面をレンダリングするためのモデル３Ｄオブジェクトのツリー階層を構築するために使用される。３Ｄ場面ツリーは、ｖｉｓｕａｌ ３Ｄオブジェクト２２、または描画コンテキスト２５を有するｖｉｓｕａｌ ２Ｄオブジェクトのいずれかから、Ｍｏｄｅｌ３Ｄルートオブジェクト１０において入力される。Ｖｉｓｕａｌ ３Ｄオブジェクト２２、および、Ｖｉｓｕａｌ ２Ｄオブジェクト２４の描画コンテキスト２５は、Ｍｏｄｅｌ３Ｄルートオブジェクト１０およびｃａｍｅｒａオブジェクト３２を示すポインタを含む。ｖｉｓｕａｌ ３Ｄオブジェクトのポインタ３３は、ｍｏｄｅｌ３Ｄルートオブジェクト１０を示す。ｖｉｓｕａｌ ３Ｄオブジェクトのポインタ３４は、ｃａｍｅｒａオブジェクト３２を示す。ｖｉｓｕａｌ ２Ｄオブジェクト２４の描画コンテキスト２５内に含まれたポインタ３１は、ｍｏｄｅｌ３Ｄルートオブジェクト１０を示す。ｖｉｓｕａｌ ２Ｄオブジェクト２４の描画コンテキスト２５内に含まれたポインタ３５は、ｃａｍｅｒａオブジェクト３２を示す。
【００１４】
ｃａｍｅｒａオブジェクト３２は、３Ｄ場面を表示するカメラの視点またはアイポイントの位置を定義する。ｃａｍｅｒａオブジェクト３２は、ｃａｍｅｒａオブジェクトの階層を有し、この階層には、ｐｒｏｊｅｃｔｉｏｎ ｃａｍｅｒａオブジェクト３９、ｐｅｒｓｐｅｃｔｉｖｅ ｃａｍｅｒａオブジェクト３６、ｏｒｔｈｏｇｏｎａｌ ｃａｍｅｒａオブジェクト３７およびＭａｔｒｉｘ３Ｄ ｃａｍｅｒａオブジェクト３８が含まれる。これらの各ｃａｍｅｒａオブジェクトは以下で、Ｍｏｄｅｌ３Ｄ ＡＰＩ定義において定義される。
【００１５】
後述の図６は、図１のモデル３Ｄオブジェクトをビルディングブロックとして使用して構築された、３Ｄ場面ツリーの一実施例である。図６からの３Ｄ場面をレンダリングするための演算フローを、以下で図７を参照して説明する。本発明を実施するための例示的動作ハードウェアおよびソフトウェア環境をこのとき、図２ないし５を参照して説明する。
【００１６】
（例示的オペレーティング環境）
図２に、本発明を実施することができる適切なコンピューティングシステム環境１００の一実施例を示す。コンピューティングシステム環境１００は、適切なコンピューティング環境の単なる一実施例でしかなく、本発明の使用または機能性の範囲についてのいかなる限定をも示唆するように意図されない。コンピューティング環境１００は、例示的オペレーティング環境１００に例示するコンポーネントのいずれか１つ、またはそれらの組合せに関係するいかなる依存性または要件も有するように解釈されるべきではない。
【００１７】
本発明は、多数の他の汎用または専用コンピューティングシステム環境または構成と共に動作可能である。本発明と共に使用するために適切である可能性のある、周知のコンピューティングシステム、環境および／または構成の例には、これに限定されないが、パーソナルコンピュータ、サーバーコンピュータ、ハンドヘルドまたはラップトップ装置、タブレット装置、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラマブルなコンシューマエレクトロニクス、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、上記のシステムまたは装置のいずれかを含む分散コンピューティング環境などが含まれる。
【００１８】
本発明を、一般にコンピュータによって実行されるプログラムモジュールなど、コンピュータ実行可能な命令に関連して説明することができる。一般に、プログラムモジュールには、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。これらは、特定のタスクを実行し、または特定の抽象データ型を実施する。また、本発明を分散コンピューティング環境において実施することもできる。この環境では、タスクが、通信ネットワークを通じてリンクされるリモート処理装置によって実行される。分散コンピューティング環境では、プログラムモジュールは、メモリ記憶装置を含む、ローカルおよびリモートのコンピュータ記憶媒体内に位置することができる。
【００１９】
図２を参照すると、本発明を実施するための例示的なシステムは、コンピュータ１１０の形態における汎用コンピューティング装置を含む。コンピュータ１１０のコンポーネントには、これに限定されないが、処理装置１２０、システムメモリ１３０、および、システムメモリを含む様々なシステムコンポーネントを処理装置１２０に結合するシステムバス１２１が含まれる場合がある。システムバス１２１をいくつかの種類のバス構造のいずれにすることもでき、これらのバス構造には、様々なバスアーキテクチャのいずれかを使用するメモリバスまたはメモリコントローラ、周辺バスおよびローカルバスが含まれる。限定ではなく例として、このようなアーキテクチャには、ＩＳＡ（業界標準アーキテクチャ）バス、ＭＣＡ（マイクロチャネルアーキテクチャ）バス、ＥＩＳＡ（拡張ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、ＡＧＰ（Ａｃｃｅｌｅｒａｔｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ）バス、および、メザニンバスとしても知られるＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスが含まれる。
【００２０】
コンピュータ１１０は通常、様々なコンピュータ読取り可能な媒体を含む。コンピュータ読取り可能な媒体は、コンピュータ１１０によってアクセスすることができるいかなる使用可能な媒体にすることもでき、揮発性および不揮発性の媒体、ならびに取り外し可能および固定の媒体が含まれる。例として、限定ではなく、コンピュータ読取り可能な媒体は、コンピュータ記憶媒体および通信媒体を含むことができる。コンピュータ記憶媒体には、揮発性および不揮発性、取り外し可能および固定の媒体が含まれ、これらの媒体はコンピュータ読取り可能な命令、データ構造、プログラムモジュールまたは他のデータなど、情報の格納のためのいずれかの方法または技術において実装される。コンピュータ記憶媒体には、それだけに限定されないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）もしくは他の光ディスク記憶、磁気カセット、磁気テープ、磁気ディスク記憶もしくは他の磁気記憶装置、または、所望の情報を格納するために使用することができ、コンピュータ１１０によってアクセスすることができる他のいかなる媒体もが含まれる。通信媒体は通常、コンピュータ読取り可能な命令、データ構造、プログラムモジュールまたは他のデータを、搬送波または他の移送メカニズムなどの変調データ信号において実施し、いかなる情報配信媒体をも含む。「変調データ信号」という用語は、信号内の情報をエンコードするような方法でその特性の１つまたは複数が設定または変更されている信号を意味する。限定ではなく例として、通信媒体には、有線ネットワークまたは直接有線接続などの有線媒体、ならびに、音響、ＲＦ、赤外線および他の無線媒体などの無線媒体が含まれる。上記のいずれの組合せも、コンピュータ読取り可能な媒体の範囲内に含まれるべきである。
【００２１】
システムメモリ１３０は、読み取り専用メモリ（ＲＯＭ）１３１およびランダムアクセスメモリ（ＲＡＭ）１３２など、揮発性および／または不揮発性メモリの形態におけるコンピュータ記憶媒体を含む。基本入出力システム１３３（ＢＩＯＳ）は、起動中など、コンピュータ１１０内の複数の要素の間で情報を転送する助けとなる基本ルーチンを含み、通常はＲＯＭ１３１に格納される。ＲＡＭ１３２は通常、処理装置１２０によって即時アクセス可能および／または現在演算中であるデータおよび／またはプログラムモジュールを含む。限定ではなく例として、図２に、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６およびプログラムデータ１３７を例示する。
【００２２】
コンピュータ１１０はまた、他の取り外し可能／固定の、揮発性／不揮発性のコンピュータ記憶媒体も含むことができる。単に例として、図２に、固定の、不揮発性の磁気媒体に対する読み書きを行うハードディスクドライブ１４１、取り外し可能な、不揮発性磁気ディスク１５２に対する読み書きを行う磁気ディスクドライブ１５１、および、ＣＤ ＲＯＭまたは他の光媒体など、取り外し可能な、不揮発性の光ディスク１５６に対する読み書きを行う光ディスクドライブ１５５を例示する。例示的なオペレーティング環境で使用することができる他の取り外し可能／固定の、揮発性／不揮発性のコンピュータ記憶媒体には、これに限定されないが、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭなどが含まれる。ハードディスクドライブ１４１は、通常、システムバス１２１にインターフェース１４０などの固定のメモリインターフェースを通じて接続される。磁気ディスクドライブ１５１および光ディスクドライブ１５５は、通常、システムバス１２１にインターフェース１５０などの取り外し可能なメモリインターフェースによって接続される。
【００２３】
上述し、および図２に例示したドライブおよびそれらの関連付けられたコンピュータ記憶媒体は、コンピュータ１１０用のコンピュータ読取り可能な命令、データ構造、プログラムモジュールおよび他のデータの記憶を提供する。図２では、例えば、ハードディスクドライブ１４１は、オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６およびプログラムデータ１４７を格納するものとして例示される。これらのコンポーネントを、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６およびプログラムデータ１３７と同じものにも異なるものにもすることができることに留意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６およびプログラムデータ１４７には異なる番号を与え、少なくとも、それらが異なるコピーであることが例示される。ユーザーは、コマンドおよび情報をコンピュータ１１０へ、タブレット（電子デジタイザ）１６４、マイクロフォン１６３、キーボード１６２、および、一般にマウス、トラックボールまたはタッチパッドと呼ばれるポインティングデバイス１６１などの入力装置を通じて入力することができる。他の入力装置（図示せず）には、ジョイスティック、ゲームパッド、衛星放送受信アンテナ、スキャナなどが含まれる場合がある。これらおよび他の入力装置は、多くの場合、システムバスに結合されるユーザー入力インターフェース１６０を通じて処理装置１２０へ接続されるが、パラレルポート、ゲームポートまたはユニバーサルシリアルバス（ＵＳＢ）など、他のインターフェースおよびバス構造によって接続することができる。モニタ１９１または他の種類の表示装置もまたシステムバス１２１へ、ビデオインターフェース１９０などのインターフェースを介して接続される。モニタ１９１をまた、タッチスクリーンパネル１９３などと統合することもでき、タッチスクリーンパネル１９３などは、タッチスクリーンインターフェース１９２などのインターフェースを介してコンピュータシステム１１０に手書きするなど、デジタル化された入力を入力することができる。モニタおよび／またはタッチスクリーンパネルは、コンピューティング装置１１０がタブレット型のパーソナルコンピュータ内などに組み込まれたハウジングに、物理的に結合されることができ、タッチスクリーンパネル１９３は、本質的にタブレット１６４としての機能を果たす。加えて、コンピューティング装置１１０などのコンピュータはまた、スピーカ１９５およびプリンタ１９６など、出力周辺インターフェース１９４などを通じて接続することができる他の周辺出力装置を含むこともできる。
【００２４】
コンピュータ１１０は、ネットワーク環境において、リモートコンピュータ１８０など、１つまたは複数のリモートコンピュータへの論理接続を使用して操作することができる。リモートコンピュータ１８０は、パーソナルコンピュータ、サーバー、ルーター、ネットワークＰＣ、ピア装置または他の共通ネットワークノードにすることができる。リモートコンピュータ１８０は、通常、コンピュータ１１０に関連して上述した要素の多数またはすべてを含むが、メモリ記憶装置１８１のみが図２において例示されている。図２に示す論理接続には、ローカルエリアネットワーク（ＬＡＮ）１７１およびワイドエリアネットワーク（ＷＡＮ）１７３が含まれるが、他のネットワークが含まれる可能性もある。このようなネットワーキング環境は、オフィス、企業規模のコンピュータネットワーク、イントラネットおよびインターネットにおいて一般的である。
【００２５】
ＬＡＮネットワーキング環境において使用するとき、コンピュータ１１０は、ＬＡＮ１７１へ、ネットワークインターフェースまたはアダプタ１７０を通じて接続される。ＷＡＮネットワーキング環境において使用するとき、コンピュータ１１０は、通常、モデム１７２、またはインターネットなどのＷＡＮ１７３を介して通信を確立するための他の手段を含む。モデム１７２を内部または外部にすることができ、システムバス１２１へ、ユーザー入力インターフェース１６０または他の適切なメカニズムを介して接続することができる。ネットワーク環境では、コンピュータ１１０に関連して示したプログラムモジュールまたはその一部を、リモートメモリ記憶装置に格納することができる。限定ではなく例として、図２に、リモートアプリケーションプログラム１８５をメモリ装置１８１上に存在するものとして例示する。図示のネットワーク接続は例示的であり、複数のコンピュータの間で通信リンクを確立する他の手段を使用することができることは理解されよう。
【００２６】
（ビジュアルツリー階層を処理するためのソフトウェア環境）
図３は、その中でビジュアルツリーを処理することができる、汎用階層化アーキテクチャ２００を表す。図３に表すように、プログラムコード２０２（例えば、アプリケーションプログラムまたはオペレーティングシステムコンポーネントなど）を、１つまたは複数の様々な方法でグラフィックスデータを出力するように開発することができる。これらの方法には、イメージング２０４を介すること、ベクトルグラフィック要素２０６を介すること、および／または、本発明の一態様による、ビジュアルアプリケーションプログラミングインターフェース（ＡＰＩ）レイヤ２１２に直接出されたファンクション／メソッドコールを介することが含まれる。一般に、イメージング２０４は、プログラムコード２０２に画像、例えばビットマップを読み込み、編集し、およびセーブするための機構を提供する。後述のように、これらの画像を、システムの他の部分によって使用することができ、プリミティブ描画コードを使用して画像を直接描画するための方法もある。ベクトルグラフィックス要素２０６は、オブジェクトモデルの残りとの整合性を有して、グラフィックスを描画するためのもう１つの方法を提供する（後述）。ベクトルグラフィック要素２０６を、マークアップ言語を介して作成することができ、要素／プロパティシステム２０８およびプレゼンタシステム２１０はこれを解釈して、ビジュアルＡＰＩレイヤ２１２への適切な呼び出しを行う。
【００２７】
グラフィックスレイヤアーキテクチャ２００は、高レベル合成およびアニメーションエンジン２１４を含む。高レベル合成およびアニメーションエンジン２１４は、キャッシングデータ構造２１６を含み、あるいはそうでない場合はキャッシングデータ構造２１６に関連付けられる。キャッシングデータ構造２１６は、シーングラフを含む。このシーングラフは、後述のように定義済オブジェクトモデルに従って管理される、階層的に配列されたオブジェクトを備える。一般に、ビジュアルＡＰＩレイヤ２１２は、プログラムコード２０２（およびプレゼンタシステム２１０）に、オブジェクトの作成、データをオブジェクトに提供するためのオブジェクトの開閉などを行う能力を含む、キャッシングデータ構造２１６へのインターフェースを提供する。すなわち、高レベル合成およびアニメーションエンジン２１４は、統一された媒体ＡＰＩレイヤ２１２を公開し、それによって開発者は、グラフィックス情報を表示するためにグラフィックスおよび媒体についての意図を表現し、下にあるプラットフォームに十分な情報を提供して、プラットフォームがハードウェアの使用をプログラムコードに合わせて最適化できるようにすることができる。例えば、下にあるプラットフォームは、キャッシング、リソースネゴシエーション、および媒体統合を担うようになる。
【００２８】
高レベル合成およびアニメーションエンジン２１４は、命令ストリームおよび場合によっては他のデータ（例えば、ビットマップへのポインタ）を、高速の低レベル合成およびアニメーションエンジン２１８に渡す。本明細書で使用されるとき、「高レベル」および「低レベル」という用語は、他のコンピューティングシナリオで使用されるものに類似しており、一般に、あるソフトウェアコンポーネントがより高いコンポーネントに対して低いほど、そのコンポーネントはハードウェアにより近い。したがって、例えば、高レベル合成およびアニメーションエンジン２１４から送信されたグラフィックス情報は低レベル合成およびアニメーションエンジン２１８で受信される可能性があり、この情報は、ハードウェア２２２を含むグラフィックスサブシステムにグラフィックスデータを送信するために使用される。
【００２９】
高レベル合成およびアニメーションエンジン２１４はプログラムコード２０２と共に、シーングラフを構築して、プログラムコード２０２によって提供されたグラフィックス場面を表現する。例えば、描画されるべき各項目を描画命令と共に読み込むことができ、これをシステムはシーングラフデータ構造２１６内にキャッシュすることができる。後述するように、このデータ構造２１６および何が描画されるかを指定するための、いくつかの様々な方法がある。さらに、高レベル合成およびアニメーションエンジン２１４はタイミングおよびアニメーションシステム２２０と統合して、宣言型（または他の）アニメーション制御（例えば、アニメーション間隔）およびタイミング制御を提供する。アニメーションシステムは、アニメート値が本質的にシステム内のいかなる場所にも渡されることを可能にし、これらの場所には例えば、要素プロパティレベル２０８において、ビジュアルＡＰＩレイヤ２１２の内部、および、他のリソースのいずれかの内部が含まれる。タイミングシステムは、要素およびビジュアルレベルで公開される。
【００３０】
低レベル合成およびアニメーションエンジン２１８は、場面の合成、アニメートおよびレンダリングを管理し、次いで場面はグラフィックスサブシステム２２２に提供される。低レベルエンジン２１８は、多数のアプリケーションの場面のためのレンダリングを構成し、レンダリングコンポーネントと共に、場面へのグラフィックスの実際のレンダリングを実施する。しかし、時には、レンダリングの一部がより高いレベルで起こることが必要および／または有利である場合があることに留意されたい。例えば、より低いレイヤは、多数のアプリケーションからの要求を提供するが、より高いレイヤは、アプリケーションごとにインスタンス化され、それにより、イメージング機構２０４を介して、時間のかかる、またはアプリケーション特有のレンダリングをより高いレベルで実行し、ビットマップへの参照をより低いレイヤに渡すことが可能である。
【００３１】
図４および５は、ｖｉｓｕａｌと呼ばれるベースオブジェクトを含む、シーングラフの例３００および４００をそれぞれ示す。一般に、ｖｉｓｕａｌは、仮想面をユーザーに表現するオブジェクトを備え、ビジュアル表現をディスプレイ上で有する。図４に表すように、トップレベル（またはルート）ｖｉｓｕａｌ３０２は、ｖｉｓｕａｌ ｍａｎａｇｅｒオブジェクト３０４に接続され、ｖｉｓｕａｌ ｍａｎａｇｅｒオブジェクト３０４はまた（例えば、ハンドルを介して）、ウィンドウ（ＨＷｎｄ）３０６、または、その中でグラフィックデータがプログラムコードのために出力される類似の単位との関係も有する。ＶｉｓｕａｌＭａｎａｇｅｒ３０４は、そのウィンドウ３０６へのトップレベルｖｉｓｕａｌ（およびそのｖｉｓｕａｌのいかなる子も）の描画を管理する。描画するため、ｖｉｓｕａｌ ｍａｎａｇｅｒ３０４はシーングラフを、ディスパッチャ３０８によってスケジュールされたように処理（例えば、トラバースまたは送信）し、グラフィックス命令および他のデータを、その対応するウィンドウ３０６のための低レベルコンポーネント２１８（図３）に提供する。シーングラフ処理は通常、ディスパッチャ３０８によって、低レベルコンポーネント２１８および／またはグラフィックスサブシステム２２２のリフレッシュレートより比較的遅いレートでスケジュールされるようになる。図４は、トップレベル（ルート）ｖｉｓｕａｌ３０２より階層的に低く配列されたいくつかの子ｖｉｓｕａｌ３１０〜３１５を示し、子ｖｉｓｕａｌのいくつかは、描画コンテキスト３１６、３１７（それらの一時的性質を表すために破線のボックスとして図示）を介して、例えば描画プリミティブおよび他のｖｉｓｕａｌを含む、関連付けられた命令リスト３１８および３１９を取り込んでいるように表現される。これらのｖｉｓｕａｌはまた他のプロパティ情報を含む場合もあり、これを以下のｖｉｓｕａｌクラスの例に示す。
【００３２】
【表１】
【００３３】
表１に示すように、ｖｉｓｕａｌは、ｔｒａｎｓｆｏｒｍ、ｃｌｉｐ、ｏｐａｃｉｔｙ、および場合によっては、設定することができ、かつ／またはｇｅｔメソッドを介して読むことができる他のプロパティを規定することによってサービスを提供する。加えて、ｖｉｓｕａｌは、それがどのようにヒットテストに参加するかを制御するフラグを有する。Ｓｈｏｗプロパティは、ｖｉｓｕａｌを表示する／隠すために使用され、例えば、偽であるときにはｖｉｓｕａｌは不可視であり、そうでない場合はｖｉｓｕａｌは可視である。
【００３４】
ｔｒａｎｓｆｏｒｍプロパティによって設定された変換は、ｖｉｓｕａｌのサブグラフのための座標系を定義する。変換前の座標系は変換前座標系と呼ばれ、変換後の座標系は変換後座標系と呼ばれ、すなわち、変換を有するｖｉｓｕａｌは、親として変換ノードを有するｖｉｓｕａｌに相当する。ビジュアルツリーおよび合成システムのより完全な説明は、上記で相互参照されたVISUAL AND SCENE GRAPH INTERFACEという名称の関連特許出願に含まれる。
【００３５】
（モデル３Ｄ ＡＰＩ処理）
図６は、３Ｄ場面、この場合はオートバイの２次元ビューをレンダリングするためのモデル３Ｄ ＡＰＩにより構築された、例示的な３Ｄ場面ツリー階層を示す。このツリーは、モデル３Ｄ ＡＰＩ内の様々な構造データオブジェクトの使用を例示する。オートバイのためのツリーの抽象またはルートノードは、オブジェクト６０２である。この抽象オブジェクトは４つの子、すなわちライトオブジェクト６０４、ボディグループオブジェクト６０６、ホイールグループオブジェクト６０８、および計器Ｖｉｓｕａｌ Ｍｏｄｅｌ３Ｄオブジェクト６１０を有する。
【００３６】
ボディグループオブジェクトは、オートバイのボディを構成する３つの子を有し、これらはフレームプリミティブオブジェクト６１２、エンジンプリミティブオブジェクト６１４およびガスタンクプリミティブオブジェクト６１６である。これらの各プリミティブオブジェクトは、オブジェクトに由来するオートバイのボディ要素を描画するようになる。ホイールグループオブジェクト６０８は、フロントホイールグループオブジェクト６１８およびリアホイールグループオブジェクト６２０を収集する。ホイールプリミティブオブジェクト６２４は、ホイールの３Ｄモデルを描画する。フロントホイールグループオブジェクト６１８は、ホイールプリミティブオブジェクト６２４によって描画されるべきホイールをフロントホイールに変換するための、３Ｄ変換６１９を有する。同様に、リアホイールグループオブジェクト６２０は、ホイールプリミティブオブジェクト６２４によって描画されるべきホイールをリアホイールに変換するための、３Ｄ変換６２１を有する。加えて、ホイールグループオブジェクト６０８に含まれる３Ｄ変換６２２がある。変換オブジェクト６２２は例えば、フロントプリミティブオブジェクト６１８およびリアプリミティブオブジェクト６２０の実行を変換して、ホイールをアニメーション効果のために回転させることができる。
【００３７】
モデル３Ｄオブジェクトのこの例示的ツリーを、図７に例示する論理演算の演算フローによって処理することができる。本発明の実施形態の論理演算は、（１）コンピューティングシステム上で実行するコンピュータ実装動作またはプログラムモジュールのシーケンスとして、かつ／または（２）コンピューティングシステム内で相互接続されたマシン論理回路または回路モジュールとして実施される。この実施は、本発明を実施するコンピューティングシステムのパフォーマンス要件に依存する、選択できることである。したがって、本明細書で説明する本発明の実施形態を構成する論理演算は、演算、構造装置、動作またはモジュールと様々に呼ばれる。これらの演算、構造装置、動作およびモジュールをソフトウェア内、ファームウェア内、専用デジタル論理内、およびそのいかなる組合せにおいても、本明細書に付属の特許請求の範囲内で列挙されるような本発明の趣旨および範囲から逸脱することなく実装することができることは、当業者には理解されよう。
【００３８】
図７で、演算フローはカメラビュー設定演算７０２で開始する。カメラ位置は、ｖｉｓｕａｌ ３Ｄオブジェクト２２（図１）によって提供される。トラバース演算７０４は、オブジェクトに達するまでツリーの枝を下がるように探索する。通常は、ツリーを下がるように左から右に向かって探索する。グループテスト演算７０６は、オブジェクトがグループオブジェクトであるか、リーフオブジェクトであるかを検出する。それがグループオブジェクトである場合、演算フローはグループオブジェクト演算処理７０８に枝分かれする。演算７０８は、オブジェクト内に含まれた任意のグループ演算を処理するようになる。変換３Ｄ演算は、グループ演算の例である。さらなるオブジェクトテスト演算７１０は、ツリー内にさらにオブジェクトがあるか否かを検出し、少なくとももう１つのオブジェクトがある場合、フローをトラバース演算７０４に戻す。
【００３９】
次のオブジェクトがリーフオブジェクトである場合、演算フローはグループテスト演算７０６からライトオブジェクトテスト演算７１２に枝分かれする。リーフオブジェクトがライトオブジェクトである場合、演算フローは次いで、ライトオブジェクトテスト演算７１２からイルミネーション設定演算７１４へのＹＥＳに枝分かれする。演算７１４はライトオブジェクトを処理して、３Ｄ場面のためのイルミネーションを設定する。次いで、演算フローはさらなるリーフオブジェクトテスト演算７１６に進む。リーフオブジェクトがライトオブジェクトでない場合、演算フローはプリミティブ／ビジュアルモデルオブジェクトテスト演算７１８に移動する。リーフオブジェクトがプリミティブオブジェクトである場合、演算フローはプリミティブ描画演算７２０に枝分かれし、その後、さらなるリーフオブジェクトテスト演算７１６に枝分かれする。プリミティブ描画演算７２０は、プリミティブオブジェクトによって指定された３Ｄモデルを描画するようになる。リーフオブジェクトがＶｉｓｕａｌ Ｍｏｄｅｌ３Ｄオブジェクトである場合、演算フローはビジュアルモデル描画演算７２２に枝分かれし、その後、さらなるリーフオブジェクトテスト演算７１６に枝分かれする。ビジュアルモデル描画演算７２２は、Ｖｉｓｕａｌ Ｍｏｄｅｌ３Ｄオブジェクトによって指定されたビジュアルモデルを描画するようになる。
【００４０】
グループ内にさらにリーフオブジェクトがある場合、さらなるリーフオブジェクトテスト演算７１６は、演算フローをリーフトラバース演算７２４に枝分かれさせる。トラバース演算７２４は、同じグループオブジェクトの下の次の子へと、ツリーを歩く。ライトオブジェクトテスト演算７１２およびプリミティブ／ビジュアルモデルテスト演算７１８は、次のリーフがライトオブジェクトであるか、プリミティブオブジェクトであるか、ビジュアルモデルオブジェクトであるかを検出する。検出されたリーフオブジェクトは、上述の繰り返しのように処理される。同じグループオブジェクトの子である、すべてのリーフオブジェクトが処理された後、演算フローはテスト演算７１６からさらなるオブジェクトテスト演算７１０へのＮＯに枝分かれする。さらに処理するべきオブジェクトがある場合、演算フローはトラバース演算７０４に戻る。そうでない場合、モデル３Ｄツリーは処理されており、演算フローは戻り７２６を通過して、３Ｄ場面の処理の呼び出し側に戻る。
【００４１】
図６の３Ｄ場面ツリーの実施例では、最初に到達されたオブジェクトはライトオブジェクトである。以下のＭｏｄｅｌ ３Ｄ ＡＰＩ定義において定義されるように、ライトオブジェクトは、３Ｄ場面を照らすライト型を指定する。最初のリーフノードであるライトオブジェクトに到達するとき、グループオブジェクトテスト演算７０６は、そのオブジェクトがリーフオブジェクトであることを検出し、演算フリーはライトオブジェクトテスト演算７０８に枝分かれする。ライトオブジェクト６０４はテスト演算７０８によって検出され、イルミネーション設定演算７１４は、ライトオブジェクトによって実行されて、３Ｄ場面のイルミネーションが設定される。次いで、フローは、さらなるリーフオブジェクトテスト演算７１６およびさらなるオブジェクトテスト演算７１０を通じて、トラバース演算７０４に戻る。
【００４２】
トラバース演算７０４は、図６のツリーを下がるように、ボディグループオブジェクト６０６まで歩く。このとき、グループテスト演算はフローをグループ演算処理７０８に枝分かれさせて、そのボディグループ用であるグループオブジェクト６０６内のいかなる演算をも実行する。次いで、フローは再度トラバース演算７０４に戻り、トラバース演算は枝をボディグループオブジェクト６０６からフレームプリミティブオブジェクト６０２へ、下がるように歩く。フレームプリミティブオブジェクト６０２は、上述のように、演算フローがテスト演算７０６、７１２および７１８を通じて枝分かれした後、プリミティブ描画演算７２０によって処理されるようになる。エンジンプリミティブオブジェクト６１４およびガスタンクプリミティブオブジェクト６１６は、演算フローがさらなるリーフオブジェクトテスト７１６を通じてループバックし、次のリーフオブジェクト演算７２４ならびにテスト演算７１２および７１８にトラバースするとき、処理されるようになる。ボディグループオブジェクトノード６０６からのすべてのリーフが処理されるとき、トラバース演算７０４はツリーを、ホイールグループオブジェクト６０８へと探索する。
【００４３】
ホイールグループオブジェクトおよびその子の処理は、ボディグループオブジェクトおよびその子の処理と同じであるが、ただし、ホイールボディグループオブジェクト６０８はＴｒａｎｓｆｏｒｍ３Ｄオブジェクト６２２を含む。Ｔｒａｎｓｆｏｒｍ３Ｄオブジェクトは、オートバイの画像のホイールをアニメーションにするために使用することができる。ホイールボディグループオブジェクト６０８を処理するとき、演算フローは、Ｔｒａｎｓｆｏｒｍ３Ｄオブジェクト６２２を検出すると、グループオブジェクトテスト演算７０６からグループ演算処理７０８に枝分かれするようになる。グループ演算処理７０８は、オブジェクト６２２の変換演算を実行して、オートバイのホイールを回転させるようにする。
【００４４】
図６の例示的な３Ｄ場面ツリー内で処理される最後のオブジェクトは、計器Ｖｉｓｕａｌ Ｍｏｄｅｌ３Ｄオブジェクト６１０である。ツリーのホイールグループブランチが処理された後、トラバース演算７０４はツリーを、計器オブジェクト６１０へと探索するようになる。図７の演算フローでは、フローは、計器Ｖｉｓｕａｌ Ｍｏｄｅｌ３Ｄオブジェクト６１０を検出するとき、テスト演算７０６、７１２および７１８を通じて、ビジュアルモデル描画演算７２２に移動する。ビジュアルモデル描画演算７２２は、オブジェクト６１０によって指定されたビジュアルモデルを描画する。これで、図７の演算による、図６の３Ｄ場面ツリーの処理が完了する。
【００４５】
（Ｍｏｄｅｌ ３Ｄ ＡＰＩ定義）
以下のＡＰＩは、Ｍｏｄｅｌ ３Ｄオブジェクトについて定義される。
【００４６】
図１のオブジェクト２２など、Ｖｉｓｕａｌ３Ｄオブジェクトは、本質的にちょうど以下の通りである。
・ライトを含む３Ｄの集合（レンダリング命令／シーングラフ／メタファイル）
・その場面の２Ｄ投影を定義するためのカメラ、
・投影をマッピングするためのローカルの座標空間内の長方形の２Ｄビューポート、および
・アンチエイリアシングスイッチ、フォグスイッチなどのような他のアンビエントパラメータ。
【００４７】
（３Ｄへのレンダリング）
２Ｄのように、レンダリングは、呼び出しが行われるところのＤｒａｗｉｎｇＣｏｎｔｅｘｔを介して起こる。例えば、２Ｄでは、以下のようになる。
【００４８】
【表２】
【００４９】
２Ｄとの一貫性を保つために、３Ｄにおける類似のモデルは以下のようになる。
【００５０】
【表３】
【００５１】
このレンダリングのモデルは、保存モード３Ｄビジュアル（「命令」が単に保存される場合）、および、即時モード３Ｄビジュアル（レンダリングが直接起こり、カメラを前もって設置する必要がある場合）の両方について、うまくいくことに留意されたい。実際に、保存モードの場合、内部で起こることは、３Ｄモデリング階層が構築および保存されていることである。別法として、即時モードの場合、このようなことは起こっておらず、命令が直接発行されており、コンテキストスタック（例えば、変換用）が維持されている。
【００５２】
（サンプルコード）
これは、３Ｄ Ｖｉｓｕａｌ ＡＰＩによるプログラミングのフレーバを示すための一実施例である。
【００５３】
この実施例の単純に作成されたＶｉｓｕａｌ３Ｄは、それにレンダリングするための描画コンテキストをグラブし、プリミティブおよびライトをそれにレンダリングし、カメラを設定し、ｖｉｓｕａｌを、制御のｖｉｓｕａｌの子に追加する。
【００５４】
【表４−１】
【００５５】
【表４−２】
【００５６】
（モデリングＡＰＩ）
上記は、描画「命令」がコンテキストに発行される「命令的レンダリング」使用スタイルを示す。これは宣言的使用ではなく、要素／マークアップセクションに達するとき、この命令的手法が宣言マークアップのために適切ではないことがわかるであろう。
【００５７】
したがって、ブラシ、ペン、ジオメトリ、パスなどにより、３Ｄ「リソース」を、２Ｄ内に存在するように構築および使用する宣言的方法がある。
【００５８】
そのために、ユーザーが、３Ｄ命令ストリームに入るものを構築することができる、いくつかの型が導入され、コンテキストを使用するのではなく、構築されたオブジェクトをＶｉｓｕａｌ３Ｄに設定することができる。
【００５９】
例えば、上記のＤｒａｗｉｎｇ３ＤＣｏｎｔｅｘｔベースのサンプルコードを、以下のように書き換えることができる。
【００６０】
【表５】
【００６１】
ここで、我々は実にモデルを構築しており、次いで、このモデルをＶｉｓｕａｌ３Ｄに割り当てている。ＰｕｓｈＴｒａｎｓｆｏｒｍ／Ｐｏｐのペアは、それ自体で変換およびその下のＭｏｄｅｌを有するＭｏｄｅｌ３ＤＧｒｏｕｐの構築によって置き換えられる。
【００６２】
さらに、このモデリング手法および命令コンテキストに基づく手法の両方を提供する目的は、混乱させることではなく、むしろ以下についての解決法を提供することである。
・要素レベルの宣言マークアップ
・ビジュアル列挙
・シーングラフ効果
・ビジュアルコンテンツの修正可能性
【００６３】
（モデリングクラス階層）
図１は、モデリングクラス階層を例示する。モデリングクラスツリーのルートはＭｏｄｅｌ３Ｄであり、Ｍｏｄｅｌ３Ｄは、Ｖｉｓｕａｌ３Ｄに付加することができる３次元モデルを表す。最終的に、ライト、メッシュ、（ファイル、リソース、メモリなどから来ることができる）．Ｘファイルストリーム、モデルのグループ、および、３Ｄ位置付けされた２Ｄビジュアルは、すべてモデルである。したがって、以下の階層を有する。
・Ｍｏｄｅｌ３Ｄ
・Ｍｏｄｅｌ３ＤＧｒｏｕｐ−Ｍｏｄｅｌ３Ｄのグループを１単位として扱うためのコンテナ
・Ｐｒｉｍｉｔｉｖｅ３Ｄ
・MeshPrimitive3D(mesh,material,hitTestID)
・ImportedPrimitive3D(stream,hitTestID)（．ｘファイル用）
・Ｌｉｇｈｔ
・AmbientLight
・SpecularLight
・DirectionalLight
・PointLight
・SpotLight
・ＶｉｓｕａｌＭｏｄｅｌ３Ｄ−ＶｉｓｕａｌおよびＰｏｉｎｔ３およびｈｉｔＴｅｓｔＩＤを有する
Ｍｏｄｅｌ３Ｄクラス自体は、以下の演算をサポートする。
・３Ｄ境界ボックスを得る。
・Ｍｏｄｅｌ３ＤのＴｒａｎｓｆｏｒｍを得て設定する。
・シェーディングモードなど、他の「ノード」レベルプロパティを得て設定する。
・ｈｉｔＴｅｓｔＯｂｊｅｃｔを得て設定する。
【００６４】
（ビジュアルＡＰＩ指定）
最初に、各型について明示的にリストされないが、これらの型のいずれもが以下のメソッドを有することに留意されたい（ここではＶｅｃｔｏｒ３Ｄについて示すが、他のあらゆるものにも適用可能）。
【００６５】
【表６】
【００６６】
また、Ｃｈａｎｇｅａｂｌｅから（直接的または間接的に）派生するあらゆる型は、「ｐｕｂｌｉｃ ｎｅｗ ＭｙＴｙｐｅ Ｃｏｐｙ（）」メソッドをその上に有することが必要となる。
【００６７】
（プリミティブタイプ）
これらのプリミティブ型は単に、このセクションで説明する他の型のサポートにおいて存在する。
【００６８】
（Ｐｏｉｎｔ３Ｄ）
Ｐｏｉｎｔ３Ｄは、２Ｄ Ｐｏｉｎｔ ｔｙｐｅ Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ（登録商標）．Ｐｏｉｎｔに直接類似するものである。
【００６９】
【表７】
【００７０】
ＴｙｐｅＣｏｎｖｅｒｔｅｒ指定
【００７１】
【表８−１】
【００７２】
【表８−２】
【００７３】
（Ｖｅｃｔｏｒ３Ｄ）
Ｖｅｃｔｏｒ３Ｄは、２Ｄ Ｖｅｃｔｏｒ ｔｙｐｅ Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ（登録商標）．Ｖｅｃｔｏｒに直接類似するものである。
【００７４】
【表９】
【００７５】
ＴｙｐｅＣｏｎｖｅｒｔｅｒ指定
【００７６】
【表１０】
（Ｐｏｉｎｔ４Ｄ）
Ｐｏｉｎｔ４Ｄは第４のｗコンポーネントを３Ｄポイントにアドインし、非アフィンＭａｔｒｉｘ３Ｄを通じた変換のために使用される。１の「ｗ」コンポーネントは、Ｐｏｉｎｔ３Ｄにトランスレートし、０の「ｗ」コンポーネントは、Ｖｅｃｔｏｒ３Ｄにトランスレートするので、Ｖｅｃｔｏｒ４Ｄはない。
【００７７】
【表１１】
ＴｙｐｅＣｏｎｖｅｒｔｅｒ指定
【００７８】
【表１２】
【００７９】
（Ｑｕａｔｅｒｎｉｏｎ）
Ｑｕａｔｅｒｎｉｏｎは、はっきりと、３次元における回転を表す３Ｄエンティティである。その指数は、平滑で信頼性のある補間を達成するために複数の４元数の間で補間する（および、したがってアニメションにする）ことが可能となる。特定の補間メカニズムは、球面線形補間（またはＳＬＥＲＰ）として知られている。
【００８０】
Ｑｕａｔｅｒｎｉｏｎは、それらのコンポーネント（ｘ、ｙ、ｚ、ｗ）の直接の指定から、または、軸／角度表現として構築することができる。最初の表現は結果として、非正規化された４元数となる場合があり、これについて特定の演算は意味を成さない（例えば、軸および角度の抽出）。
【００８１】
Ｑｕａｔｅｒｎｉｏｎが構築された後にＱｕａｔｅｒｎｉｏｎのコンポーネントを設定することはできず、これは、それを行うことにおいて潜在的な曖昧さがあるからである。（例えば、Ａｎｇｌｅを非正規化されたＱｕａｔｅｒｎｉｏｎ上に設定することに何の意味があるか。）
【００８２】
【表１３−１】
【００８３】
【表１３−２】
【００８４】
ＴｙｐｅＣｏｎｖｅｒｔｅｒ指定
【００８５】
【表１４】
【００８６】
（Ｍａｔｒｉｘ３Ｄ）
Ｍａｔｒｉｘ３Ｄは、Ｓｙｓｔｅｍ．Ｗｉｎｄｏｗｓ（登録商標）．Ｍａｔｒｉｘに類似する３Ｄである。Ｍａｔｒｉｘのように、大部分のＡＰＩはＭａｔｒｉｘ３Ｄを取らないが、むしろＴｒａｎｓｆｏｒｍ３Ｄを取り、これは深い方法でアニメーションをサポートする。
【００８７】
３Ｄ計算のための行列は４ｘ４行列として表される。ＭＩＬは行ベクトル構文を使用する。
【００８８】
【表１５】
【００８９】
行列がある点により乗算されるとき、行列はその点を、新しい座標系から以前の座標系へ変換する。
【００９０】
変換をいかなるレベルにもネストさせることができる。新しい変換が適用されるときは常に、これは、現在の変換行列上にそれを前から掛ける（ｐｒｅ−ｍｕｌｔｉｐｌｙｉｎｇ）することと同じである。
【００９１】
【表１６−１】
【００９２】
【表１６−２】
【００９３】
ＴｙｐｅＣｏｎｖｅｒｔｅｒ指定
【００９４】
【表１７】
【００９５】
（Ｔｒａｎｓｆｏｒｍ３Ｄクラス階層）
Ｔｒａｎｓｆｏｒｍ３Ｄは、２Ｄ Ｔｒａｎｓｆｏｒｍのように、３Ｄ変換の特定の型を表す具象サブクラスを有する抽象ベースクラスである。
【００９６】
Ｔｒａｎｓｆｏｒｍ３Ｄの特定のサブクラスもまた、アニメーションが入るところである。
【００９７】
Ｔｒａｎｓｆｏｒｍ３Ｄの全体の階層はこのようになり、これを図８に示す。
Transform3D
----Transform3DCollection
----AffineTransform3D
--------TranslateTransform3D
--------ScaleTransform3D
--------RotateTransform3D
----MatrixTransform3D
（Ｔｒａｎｓｆｏｒｍ３Ｄ）
【００９８】
ルートのＴｒａｎｓｆｏｒｍ３Ｄオブジェクト８０２は、Ｔｒａｎｓｆｏｒｍの特定のクラスを構築するためのある興味深い静的メソッドを有する。このオブジェクトはＭａｔｒｉｘ３Ｄ表現を公開せず、これはこのＴｒａｎｓｆｏｒｍがそれよりも幅広い可能性があるからであることに留意されたい。
【００９９】
【表１８−１】
【０１００】
【表１８−２】
【０１０１】
Ｐｏｉｎｔ３Ｄ／Ｖｅｃｔｏｒ３Ｄを取るＴｒａｎｓｆｏｒｍ（）メソッドは、変換がアフィンでない場合、例外を引き起こすようになることに留意されたい。
【０１０２】
（Ｔｒａｎｓｆｏｒｍ３ＤＣｏｌｌｅｃｔｉｏｎ）
Ｔｒａｎｓｆｏｒｍ３Ｄ ｃｏｌｌｅｃｔｉｏｎオブジェクト８０４は、ｖｉｓｕａｌ ２ＤにおけるＴｒａｎｓｆｏｒｍＣｏｌｌｅｃｔｉｏｎを正確にまねるようになり、Ａｄｄメソッドは、上記のＣｒｅａｔｅメソッドと同じように修正される。
【０１０３】
【表１９】
【０１０４】
（ＡｆｆｉｎｅＴｒａｎｓｆｏｒｍ３Ｄ）
Ａｆｆｉｎｅ Ｔｒａｎｓｆｏｒｍ３Ｄオブジェクト８０６は単に、すべての具象アフィン３Ｄ変換（ｔｒａｎｓｌａｔｅ、ｓｋｅｗ、ｒｏｔａｔｅ、ｓｃａｌｅ）が派生する元のベースクラスであり、Ｍａｔｒｉｘ３Ｄへの読み取りアクセスを公開する。
【０１０５】
【表２０−１】
【０１０６】
【表２０−２】
【０１０７】
（ＴｒａｎｓｌａｔｅＴｒａｎｓｆｏｒｍ３Ｄオブジェクト８０８）
【０１０８】
【表２１】
【０１０９】
（ＳｃａｌｅＴｒａｎｓｆｏｒｍ３Ｄオブジェクト８１２）
【０１１０】
【表２２】
【０１１１】
（ＲｏｔａｔｅＴｒａｎｓｆｏｒｍ３Ｄ）
ＲｏｔａｔｅＴｒａｎｓｆｏｒｍ３Ｄオブジェクト８１２は、それを中心に回転するための軸の概念の導入（および、したがって４元数の使用）による、２Ｄ回転からの単なる単純マッピングだけではない。
【０１１２】
【表２３−１】
【０１１３】
【表２３−２】
【０１１４】
ここではＱｕａｔｅｒｎｉｏｎプロパティのみがアニメメーションにすることが可能であることに留意されたい。一般に、軸／角度のアニメーションはうまく行く傾向がない。４元数をよりよくアニメーションにするために、軸および角度を４元数のベース値から抽出することができる。単に角度を固定軸に対してアニメーションにすることを望む場合、これを指定する容易な方法は、これらの位置を表す２つの４元数を構築し、それらの４元数の間でアニメーションにすることである。
【０１１５】
（ＭａｔｒｉｘＴｒａｎｓｆｏｒｍ３Ｄ）
ＭａｔｒｉｘＴｒａｎｓｆｏｒｍ３Ｄオブジェクト８１４は、Ｔｒａｎｓｆｏｒｍ３ＤをＭａｔｒｉｘ３Ｄから直接構築する。
【０１１６】
【表２４】
【０１１７】
（Ｔｒａｎｓｆｏｒｍ３Ｄ ＴｙｐｅＣｏｎｖｅｒｔｅｒ）
Ｔｒａｎｓｆｏｒｍ３Ｄタイプのプロパティがマークアップで指定されるとき、プロパティシステムはＴｒａｎｓｆｏｒｍ型コンバータを使用して、文字列表現を適切なＴｒａｎｓｆｏｒｍ派生オブジェクトに変換する。アニメーションにされたプロパティを、この構文を使用して記述する方法はないが、複合プロパティ構文をアニメーション記述のために使用することができる。
【０１１８】
（構文）
この構文は、２Ｄ Ｔｒａｎｓｆｏｒｍからモデリングされる。＜＞は任意選択のパラメータを表す。
【０１１９】
・matrix(m00 m01 m02 m03 m11...m33)
・translate(tx ty tz)
・scale(sx <sy> <sz> <cx> <cy> <cz>)
・＜ｓｙ＞または＜ｓｚ＞が指定されない場合、これは均等スケールであると仮定される。
【０１２０】
・＜ｃｘ＞＜ｃｙ＞＜ｃｚ＞が指定される場合、これらはすべて指定される必要があり、＜ｓｘ＞＜ｓｙ＞も同様である。これらはスケーリング中心のために使用される。これらが使用されない場合、中心は０、０、０であると仮定される。
【０１２１】
・rotate(ax ay az angle <cx> <cy> <cz>)
・ａｘ、ａｙ、ａｚは回転の角度を指定する
・角度は、その軸を通じた角度である
・ｃｘ、ｃｙ、ｃｚが指定されない場合、これは０、０、０であると仮定される。
【０１２２】
・skew(angleX angleY angleZ <cx> <cy> <cz>)
・ｃｘ、ｃｙ、ｃｚが指定されない場合、これは０、０、０であると仮定される。
【０１２３】
文法
【０１２４】
【表２５−１】
【０１２５】
【表２５−２】
【０１２６】
（Ｖｉｓｕａｌ３Ｄ）
図１のＶｉｓｕａｌ３Ｄオブジェクト２２はＶｉｓｕａｌ２Ｄから派生し、そのように行う際に、以下を含むそのプロパティのすべてを得る。
【０１２７】
・オパシティ
・２Ｄジオメトリッククリップ
・２Ｄブレンドモード
・ヒットテストＡＰＩ
・２Ｄバウンドクエリ
・ビジュアルツリーにおける参加
オパシティ、クリップ、ブレンドモードおよびバウンドのすべては３Ｄ場面の２Ｄ投影に適用されることに留意されたい。
【０１２８】
【表２６】
【０１２９】
ＶｉｅｗＰｏｒｔボックスは、Ｃａｍｅｒａ／Ｍｏｄｅｌの組合せによって決定された投影が２Ｄローカル座標空間内のどこにマップするかを確立する。
【０１３０】
（Ｄｒａｗｉｎｇ３ＤＣｏｎｔｅｘｔ）
Ｄｒａｗｉｎｇ３ＤＣｏｎｔｅｘｔは実に、２Ｄ Ｄｒａｗｉｎｇ Ｃｏｎｔｅｘｔに類似しており、Ｖｉｓｕａｌ３ＤのＭｏｄｅｌ３ＤＣｏｌｌｅｃｔｉｏｎから、ＲｅｎｄｅｒＯｐｅｎ／ＲｅｎｄｅｒＡｐｐｅｎｄを介してアクセス可能である。これは命令を内部で保存中であるとしても、即時モードレンダリングコンテキストのような感じである。
【０１３１】
【表２７】
【０１３２】
これらのＤｒａｗｉｎｇ３ＤＣｏｎｔｅｘｔ演算の意味体系の具体的な詳細については、モデリングＡＰＩのセクションを参照されたい。モデリングＡＰＩのために、Ｄｒａｗｉｎｇ３ＤＣｏｎｔｅｘｔは実際には単に好都合なものである。例えば、ＤｒａｗＩｍｐｏｒｔｅｄＰｒｉｍｉｔｉｖｅ（ＩｍｐｏｒｔｅｄＰｒｉｍｉｔｉｖｅ３ＤＳｏｕｒｃｅ ｐｒｉｍｉｔｉｖｅＳｏｕｒｃｅ、ｏｂｊｅｃｔＨｉｔＴｅｓｔＴｏｋｅｎ）は単にＩｍｐｏｒｔｅｄＰｒｉｍｉｔｉｖｅ３Ｄを作成し、これを、現在累積中のＭｏｄｅｌ３Ｄに追加する（現在累積中のＭｏｄｅｌ３Ｄは、コンテキストにおいてＰｕｓｈ／Ｐｏｐメソッドによって操作される）。
【０１３３】
ＤｒａｗＭｏｄｅｌ（）は、「コンテキスト」ワールドと「モデリング」ワールドの間のもう１つのクロスオーバーポイントであり、Ｍｏｄｅｌ３Ｄがコンテキストに「描画」されることを可能にする。
【０１３４】
Ｄｒａｗｉｎｇ３ＤＣｏｎｔｅｘｔからの明示的な「リードバック」はない。これは、それが単にＭｏｄｅｌ３ＤＧｒｏｕｐにそれを支援させているからであり、常にその集合を列挙することができるからである。
【０１３５】
（モデリングＡＰＩ）
これは、これらのクラスのためのパブリックおよび保護されたＡＰＩであり、継承されたメンバを示さない。
【０１３６】
（Ｍｏｄｅｌ３Ｄ）
図１のＭｏｄｅｌ３Ｄオブジェクト１０は、あらゆるものがそこから構築される抽象モデルオブジェクトである。
【０１３７】
【表２８】
【０１３８】
（Ｍｏｄｅｌ３ＤＧｒｏｕｐ）
図１のＭｏｄｅｌ３ＤＧｒｏｕｐオブジェクト１８は、モデルの組合せを構築し、これらを単位として扱い、任意選択で変換するか、あるいは他の属性をこれらに適用する。
【０１３９】
【表２９】
【０１４０】
またＭｏｄｅｌ３ＤＧｒｏｕｐは、ＲｅｎｄｅｒＯｐｅｎ／Ａｐｐｅｎｄをも有し、ＲｅｎｄｅｒＯｐｅｎ／Ａｐｐｅｎｄは、Ｄｒａｗｉｎｇ３ＤＣｏｎｔｅｘｔを戻すことに留意されたい。このコンテキストの使用は、Ｍｏｄｅｌ３ＤＣｏｌｌｅｃｔｉｏｎ自体を修正する。ＲｅｎｄｅｒＯｐｅｎ（）とＲｅｎｃｅｒＡｐｐｅｎｄ（）の間の違いは、ＲｅｎｄｅｒＯｐｅｎ（）がコレクションを最初にクリアすることである。
【０１４１】
また、一度にただ１つのＤｒａｗｉｎｇ３ＤＣｏｎｔｅｘｔのみをＭｏｄｅｌ３ＤＧｒｏｕｐ上で開くことができ、Ｄｒａｗｉｎｇ３ＤＣｏｎｔｅｘｔが開かれるとき、アプリケーションはそのＭｏｄｅｌ３ＤＧｒｏｕｐのコンテンツに（読み取りまたは書き込みのために）直接アクセスすることができないことにも留意されたい。
【０１４２】
（Ｌｉｇｈｔ階層）
Ｌｉｇｈｔオブジェクトは、Ｍｏｄｅｌ３Ｄオブジェクトである。Ｌｉｇｈｔオブジェクトには、Ａｍｂｉｅｎｔ、Ｐｏｓｉｔｉｏｎａｌ、ＤｉｒｅｃｔｉｏｎａｌおよびＳｐｏｔ ｌｉｇｈｔが含まれる。これらは実にＤｉｒｅｃｔ３Ｄライティング群においてモデリングされるが、モデリング階層の一部であるという追加のプロパティを有し、したがって、座標空間変換を受ける。
【０１４３】
アンビエント、ディフューズおよびスペキュラー色はすべてのライトにおいて提供される。
【０１４４】
ｌｉｇｈｔ階層はこのようになり、これをまた図９にも示す。
【０１４５】
Model3D
----Light（抽象）
--------AmbientLight（具象）
--------DirectionalLight（具象）
--------PointLight（具象）
------------SpotLight（具象）
ベースのｌｉｇｈｔオブジェクト９０２クラスは、単に以下を有する抽象クラスである。
【０１４６】
【表３０】
【０１４７】
（ＡｍｂｉｅｎｔＬｉｇｈｔ）
Ａｍｂｉｅｎｔ ｌｉｇｈｔオブジェクト９０４はモデルを、それらの形状にかかわらず、均等に明るくする。
【０１４８】
【表３１】
【０１４９】
（ＤｉｒｅｃｔｉｏｎａｌＬｉｇｈｔ）
ｄｉｒｅｃｔｉｏｎａｌ ｌｉｇｈｔオブジェクト９０６からの指向性ライトは、空間における位置を有しておらず、それらのライトを、それを定義するベクトルによって指定された特定の方向に沿って投影する。
【０１５０】
【表３２】
【０１５１】
方向が正規化される必要はないが、方向もまたゼロでない大きさを有していなければならない。
【０１５２】
（ＰｏｉｎｔＬｉｇｈｔ）
ｐｏｉｎｔ ｌｉｇｈｔオブジェクト９０８からの定位置ライトは、空間における位置を有し、それらのライトをすべての方向に投影する。ライトの減少は、ａｔｔｅｎｕａｔｉｏｎおよびｒａｎｇｅプロパティによって制御される。
【０１５３】
【表３３】
【０１５４】
（ＳｐｏｔＬｉｇｈｔ）
ＳｐｏｔＬｉｇｈｔは、位置、範囲および減衰を有するので、ＰｏｉｎｔＬｉｇｈｔから派生するが、ライトの「コーン」を制御するための方向およびパラメータもアドインする。「コーン」を制御するために、ｏｕｔｅｒＣｏｎｅＡｎｇｌｅ（何ものもこれを越えて照らされない）およびｉｎｎｅｒＣｏｎｅＡｎｇｌｅ（その内部のあらゆるものが完全に照らされる）が指定されなければならない。内部コーンの外側と外部コーンの間のライティングは線形に減少する。（ここで可能性のある混乱の原因は、２つの減少がここで進行中であり、一方が内部コーンの端と外部コーンの間の「角度」であり、他方がライトの位置に対する距離におけるものであり、減衰および範囲によって影響されることである。）
【０１５５】
【表３４】
【０１５６】
角度は度で指定されることに留意されたい。
【０１５７】
（Ｐｒｉｍｉｔｉｖｅ３Ｄ）
図１のＰｒｉｍｉｔｉｖｅ３Ｄオブジェクト１２は、ツリー内のレンダリングの結果となるリーフノードである。具象クラスは、明示的に指定されたメッシュ、ならびに、インポートされたプリミティブ（．ｘファイル）を取り込む。
【０１５８】
【表３５】
【０１５９】
（ＭｅｓｈＰｒｉｍｉｔｉｖｅ３Ｄ）
ＭｅｓｈＰｒｉｍｉｔｉｖｅ３Ｄは、メッシュおよびマテリアルによるモデリング用である。
【０１６０】
【表３６】
【０１６１】
ＭｅｓｈＰｒｉｍｉｔｉｖｅ３Ｄはリーフジオメトリであり、Ｍｅｓｈを含むが、それ自体はＭｅｓｈではないことに留意されたい。これは、メッシュデータを複製することなく、異なるヒットテストを受ける、異なるマテリアルを有する、複数のＭｅｓｈＰｒｉｍｉｔｉｖｅ３Ｄの間で、Ｍｅｓｈを共有することができることを意味する。
【０１６２】
（ＩｍｐｏｒｔｅｄＰｒｉｍｉｔｉｖｅ３Ｄ）
ＩｍｐｏｒｔｅｄＰｒｉｍｉｔｉｖｅ３Ｄは、取り込まれて適切な内部形式に変換された、外部から獲得されたプリミティブ（潜在的にマテリアルおよびアニメーションを有する）を表す。ＩｍｐｏｒｔｅｄＰｒｉｍｉｔｉｖｅ３Ｄは、Ａｖａｌｏｎによって厳格なモデルとして扱われる。これの標準的な例は．Ｘファイルであり、Ｘファイルを明示的にインポートするＩｍｐｏｒｔｅｄＰｒｉｍｉｔｉｖｅ３ＤＳｏｕｒｃｅのサブクラスがある。
【０１６３】
【表３７】
【０１６４】
ＩｍｐｏｒｔｅｄＰｒｉｍｉｔｉｖｅ３ＤのためのＴｙｐｅＣｏｎｖｅｒｔｅｒ
．ｘファイルは場面内に含まれるので、これを表現するための単純なＴｙｐｅＣｏｎｖｅｒｔｅｒは、以下にようなものになるはずである。
【０１６５】
【表３８】
【０１６６】
（ＶｉｓｕａｌＭｏｄｅｌ３Ｄ）
ＶｉｓｕａｌＭｏｄｅｌ３ＤはいかなるＶｉｓｕａｌ（定義により、２Ｄ）をも取り、これを場面内に入れる。レンダリングされるとき、これはスクリーンに合わせられ、そのサイズは影響を受けないが、カメラから特定のｚ平面にあるようになる。Ｖｉｓｕａｌはインタラクティブなままとなる。
【０１６７】
【表３９】
【０１６８】
ＶｉｓｕａｌＭｏｄｅｌ３Ｄのレンダリングは、最初にＣｅｎｔｅｒＰｏｉｎｔをワールド座標に変換する。これは次いでＶｉｓｕａｌをピクセルバッファへ、スクリーンに合わせられる方法でレンダリングし、変換されたＣｅｎｔｅｒＰｏｉｎｔのｚは、ビジュアルの中心が配置されるところになる。カメラの動きの下で、ＶｉｓｕａｌＭｏｄｅｌ３Ｄは常に同じ量のスクリーンリアルエステートを占有するようになり、常に前を向き、ライトなどによって影響を受けないようになる。場面の残りに対するビジュアルのこのカメラの動きの中の固定点は、配置がその点に基づいて起こるので、ビジュアルの中心となる。
【０１６９】
提供されたＶｉｓｕａｌは完全にインタラクティブであり、事実上、それを囲むＶｉｓｕａｌ３Ｄが「親に当たる」（これは、Ｖｉｓｕａｌが単一の親しか有することができないのと同然に、所与のＶｉｓｕａｌをいずれかのＶｉｓｕａｌＭｏｄｅｌ３Ｄにおいて一度しか使用することができないことを意味することに留意されたい）。
【０１７０】
（Ｍｅｓｈ３Ｄ）
Ｍｅｓｈ３Ｄプリミティブは、プログラム的に構築することができる直接的なトライアングルプリミティブ（インデックス付きおよびインデックスなしの指定を可能にする）である。Ｍｅｓｈ３Ｄプリミティブは位置、標準、色およびテクスチャ情報をサポートし、最後の３つは任意選択であることに留意されたい。メッシュはまた、それが三角形として表示されるべきであるか、線として表示されるべきであるか、点として表示されるべきであるかの選択も可能にする。メッシュはまた、インデックスを解釈するための３つのトポロジもサポートし、これらはトライアングルリスト、トライアングルストリップおよびトライアングルファンである。
【０１７１】
Ｍｅｓｈ３Ｄによって直接サポートされない頂点フォーマットおよび他のプリミティブ構造では、．ｘファイルを構築およびインポートすることができる。
【０１７２】
【表４０】
【０１７３】
ＭｅｓｈＰｒｉｍｉｔｉｖｅＴｙｐｅは以下のように定義される。
【０１７４】
【表４１】
【０１７５】
（Ｍｅｓｈデータの解釈）
Ｍｅｓｈ３Ｄにおける頂点単位のデータは、Ｐｏｓｉｔｉｏｎｓ、Ｎｏｒｍａｌｓ、ＣｏｌｏｒｓおよびＴｅｘｔｕｒｅＣｏｏｒｄｉｎａｔｅｓに分割される。言うまでもなく、Ｐｏｓｉｔｉｏｎｓのみが必要とされる。他のいずれかが提供される場合、これらはＰｏｓｉｔｉｏｎｓコレクションと正確に同じ長さを有していなければならず、そうでない場合、例外が引き起こされるようになる。
【０１７６】
Ｎｏｒｍａｌｓが提供される場合、正規化されると仮定される。正規化が望まれるとき、これらは供給されなければならない。
【０１７７】
ＴｒｉａｎｇｌｅＩｎｄｉｃｅｓコレクションは、メッシュを構成する三角形のための頂点単位の情報を決定するために頂点データに索引付けするメンバを有する。この集合は、ＭｅｓｈＰｒｉｍｉｔｉｖｅＴｙｐｅの設定に基づいて解釈される。これらの解釈は、Ｄｉｒｅｃｔ３Ｄにおけるものと正確に同じである。ＴｒｉａｎｇｌｅＬｉｓｔでは、ＴｒｉａｎｇｌｅＩｎｄｉｃｅｓ集合内の３つおきの要素が新しい三角形を定義する。ＴｒｉａｎｇｌｅＦａｎでは、インデックス０、１、２が最初の三角形を決定し、次いで後続の各インデックスｉが、頂点０、ｉ、ｉ−１によって与えられた新しい三角形を決定する。ＴｒｉａｎｇｌｅＳｔｒｉｐでは、インデックス０、１、２が最初の三角形を決定し、後続の各インデックスｉが、頂点ｉ−２、ｉ−１およびｉによって与えられた新しい三角形を決定する。ＬｉｎｅＬｉｓｔ、ＬｉｎｅＳｔｒｉｐおよびＰｏｉｎｔＬｉｓｔは類似の解釈を有するが、レンダリングは、三角形ではなく線および点に関する。
【０１７８】
ＴｒｉａｎｇｌｅＩｎｄｉｃｅｓがヌルである場合、Ｍｅｓｈはインデックスなしプリミティブとして実装され、これは、長さｎのＰｏｓｉｔｉｏｎｓ集合について値０、１、．．．、ｎ−２、ｎ−１を保持するＴｒｉａｎｇｌｅＩｎｄｉｃｅｓに等しい。
【０１７９】
（Ｍｅｓｈの構築およびデータ複製の回避）
Ｍｅｓｈを構築した上で、この実装は、このメッシュを表す最適なＤ３Ｄ構造を作成する。この時点で、実際のＣｏｌｌｅｃｔｉｏｎデータ構造を、Ｍｅｓｈ実装によってスローして、データの複製を回避することができる。ある他の機構（例えば、Ｖｉｓｕａｌ３Ｄモデル階層をトラバースすること）を通じてアクセスされた場合のメッシュの後続のリードバックは、元のデータを保存するのではなく、その上に保持されているＤ３Ｄ情報からデータを再構築する可能性が高くなる。
【０１８０】
（Ｍｅｓｈの変更可能性）
メッシュはＣｈａｎｇｅａｂｌｅから派生し、したがって修正することができる。この実装では、群を頂点およびインデックスデータにトラップし、これらの変更をＤ３Ｄデータ構造に伝搬させることが必要となる。
【０１８１】
（ＭｅｓｈのためのＴｙｐｅＣｏｎｖｅｒｔｅｒ）
他のすべての型と同様に、ＸＡＭＬ複合プロパティ構文を使用して、Ｍｅｓｈ３Ｄを定義するコレクションを指定することができる。しかし、指定をより簡潔にするために、ＴｙｐｅＣｏｎｖｅｔｅｒが提供される。
【０１８２】
メッシュ内で定義された各集合は、この集合を作成するために解析および使用されるべき一連の数を取ることができる。例えば、索引付きトライアングルストリップを位置および色のみにより表すＭｅｓｈを、以下のように指定することができる。
【０１８３】
【表４２】
【０１８４】
言うまでもなく、これらのいかなるものも、複合プロパティ構文においてはるかにより冗長に表現される可能性がある。
【０１８５】
（Ｍａｔｅｒｉａｌ）
Ｐｒｉｍｉｔｉｖｅ３Ｄを構築するメソッドは、それらの外観を定義するためにＭａｔｅｒｉａｌを取る。Ｍａｔｅｒｉａｌは抽象ベースクラスであり、ＢｒｕｓｈＭａｔｅｒｉａｌ、ＶｉｓｕａｌＭａｔｅｒｉａｌ、およびＡｄｖａｎｃｅｄＭａｔｅｒｉａｌという３つの具象サブクラスを有する。ＢｒｕｓｈＭａｔｅｒｉａｌおよびＶｉｓｕａｌＭａｔｅｒｉａｌは、ＢａｓｉｃＭａｔｅｒｉａｌと呼ばれるもう１つの抽象クラスのサブクラスである。したがって、以下の通りである。
【０１８６】
Material
----BasicMaterial
--------BrushMaterial
--------VisualMaterial
----AdvancedMaterial
【０１８７】
・ＢｒｕｓｈＭａｔｅｒｉａｌは、単に単一のＢｒｕｓｈを取り、幅広い範囲の効果のために使用することができ、これらの効果には、透過性を達成すること（ピクセル単位またはスカラ単位のいずれか）、テクスチャ変換（アニメーションにするのものでも）を有すること、ビデオテクスチャを使用すること、暗黙の自動生成ＭＩＰマッピングなどが含まれる。具体的には、単一色、画像、グラディエント、または、さらにもう１つのＶｉｓｕａｌのテクスチャリングでは、単にＳｏｌｉｄＣｏｌｏｒＢｒｕｓｈ、ＩｍａｇｅＢｒｕｓｈ、ＧｒａｄｉｅｎｔＢｒｕｓｈまたはＶｉｓｕａｌＢｒｕｓｈを使用して、それらのＢｒｕｓｈＭａｔｅｒｉａｌを作成するようになる。
【０１８８】
・ＶｉｓｕａｌＭａｔｅｒｉａｌは特に、Ｖｉｓｕａｌからマテリアルを構築するために設計される。このマテリアルは、入力がＶｉｓｕａｌへ、それが埋め込まれる３Ｄワールドから渡されるという意味で、インタラクティブとなる。これと、ＶｉｓｕａｌＢｒｕｓｈを有するＢｒｕｓｈＭａｔｅｒｉａｌの間の違いについて疑問に思うかもしれない。この違いは、ＢｒｕｓｈＭａｔｅｒｉａｌがインタラクティブでないということである。
【０１８９】
・ＡｄｖａｎｃｅｄＭａｔｅｒｉａｌクラスは、単にＢｒｕｓｈＭａｔｅｒｉａｌまたは、ＶｉｓｕａｌＭａｔｅｒｉａｌを使用するよりもかなり複雑であるが、さらに多くの柔軟性を提供する。しかし、非３Ｄ−ＥｉｎｓｔｅｉｎはＡｄｖａｎｃｅｄＭａｔｅｒｉａｌについて知る必要はなく、単にＢｒｕｓｈＭａｔｅｒｉａｌ／ＶｉｓｕａｌＭａｔｅｒｉａｌを使用して、達成することを望む大部分のことを達成することができる。
【０１９０】
【表４３】
【０１９１】
Ｍａｔｅｒｉａｌは、Ｂｒｕｓｈに基づくことによって、大変な柔軟性および「概念の節約」を得る。具体的には、以下の通りである。
【０１９２】
・ビデオテクスチャ、グラディエントテクスチャなどのようなものを反映する別々のＴｅｘｔｕｒｅ階層がある必要はなく、これは、これらがすべてＢｒｕｓｈとして指定可能であるからである。
【０１９３】
・Ｂｒｕｓｈはすでにアルファマスクおよびスカラオパシティ値をカプセル化しており、そのため、これらは両方ともテクスチャリングに使用可能となる。
【０１９４】
・Ｂｒｕｓｈはすでに、それに関連付けられた２Ｄ Ｔｒａｎｓｆｏｒｍを有しており、２Ｄ Ｔｒａｎｓｆｏｒｍは、テクスチャリングの場合、メッシュ内のｕｖ座標をテクスチャにマップするように変換するためのテクスチャ変換として解釈されるようになる。
【０１９５】
・Ｂｒｕｓｈは、将来、ウッドグレインシェーダなどのストック手順シェーダをハングするための正しい場所である。これは次いで、２Ｄにおいて塗りつぶしまたはペンとして、また３Ｄにおいてテクスチャとして使用可能となる。特定のＡＰＩサポートが３Ｄ空間において手順シェーダのために与えられる必要はない。
【０１９６】
ＴｅｘｔｕｒｅＴｒａｎｓｆｏｒｍプロパティは、ＢｒｕｓｈＭａｔｅｒｉａｌまたはＶｉｓｕａｌＭａｔｅｒｉａｌの定義の内部に存在する可能性のあるいかなる変換からも別個であることに留意されたい。ＴｅｘｔｕｒｅＴｒａｎｓｆｏｒｍプロパティは、問題のＭａｔｅｒｉａｌからテクスチャ座標空間（その範囲は［０，０］から［１，１］）への変換を指定する。Ｍａｔｅｒｉａｌ内部の変換はＴｅｘｔｕｒｅＴｒａｎｓｆｏｒｍと結合して、１ｘ１（テクスチャ座標における）のＭａｔｅｒｉａｌがＭｅｓｈを介してどのようにマップされるかを記述する。
【０１９７】
（シェーダ）
「ストック」シェーダのセットの多くはパラメータ化されており、ＡＰＩにおいて以下のようにアクセス可能である。
【０１９８】
１）２Ｄワールド内で意味を成すシェーダでは、シェーダはＢｒｕｓｈの具象サブクラスとして公開されるようになり、それらのパラメータ化はクラス上のコンストラクタを通じて、あるいはクラス上のプロパティとして表現される。次いでシェーダを２Ｄオブジェクトに適用することができる。
【０１９９】
２）３Ｄ内でしか意味を成さないシェーダでは、シェーダはＭａｔｅｒｉａｌまたはＢａｓｉｃＭａｔｅｒｉａｌの具象サブクラスとして公開され、そこでシェーダをまた、それらのコンストラクタを通じてパラメータ化することもできる。
【０２００】
この公開は次いで、シェーダが３Ｄ（および、適切なところでは２Ｄ）メッシュに適用されることを可能にするようになる。
【０２０１】
（ＢｒｕｓｈＭａｔｅｒｉａｌ）
上述のように、ＢｒｕｓｈＭａｔｅｒｉａｌは単にＢｒｕｓｈをカプセル化する。Ｐｒｉｍｉｔｉｖｅ３Ｄに適用されたＢｒｕｓｈＭａｔｅｒｉａｌは、テクスチャとして扱われる。テクスチャは直接マッピングされるようになり、すなわち、マッピングされているプリミティブにおける２Ｄのｕ，ｖ座標は、テクスチャ変換によって修正された、Ｔｅｘｔｕｒｅ上の対応するｘ，ｙ座標に直接索引付けするようになる。Ａｖａｌｏｎにおけるすべての２Ｄのように、テクスチャの座標系は左上の（０，０）から出て、正のｙが下を指すことに留意されたい。
【０２０２】
Ｂｒｕｓｈのために使用されたＶｉｓｕａｌＢｒｕｓｈは入力を受け入れないようになるが、その上のいかなるアニメーションにも、またはそれに起こったいかなる構造上の変更にも従って更新するようになる。ＶｉｓｕａｌをＭａｔｅｒｉａｌとして使用し、なお入力を受信するためには、後述のＶｉｓｕａｌＭａｔｅｒｉａｌを使用する。
【０２０３】
【表４４】
【０２０４】
（ＶｉｓｕａｌＭａｔｅｒｉａｌ）
上述のように、ＶｉｓｕａｌＭａｔｅｒｉａｌはインタラクティブなＶｉｓｕａｌをカプセル化する。これは、Ｖｉｓｕａｌと共に使用されたＢｒｕｓｈＭａｔｅｒｉａｌとは、Ｖｉｓｕａｌがそのテクスチャリングされた形式で残る点で異なる。Ｖｉｓｕａｌは次いで、事実上、ある方法でルートのＶｉｓｕａｌ３Ｄが親に当たることに留意されたい。単一のＵＩＥｌｅｍｅｎｔを複数のＭａｔｅｒｉａｌで使用すること、または、ＶｉｓｕａｌＭａｔｅｒｉａｌを複数の場所で使用することは、正しくない。
【０２０５】
【表４５】
【０２０６】
（ＡｄｖａｎｃｅｄＭａｔｅｒｉａｌ）
ＢｒｕｓｈＭａｔｅｒｉａｌ／ＶｉｓｕａｌＭａｔｅｒｉａｌおよびＢｕｍｐＭａｐは、ＡｄｖａｎｃｅｄＭａｔｅｒｉａｌを定義するために使用される。
【０２０７】
【表４６】
【０２０８】
ＥｎｖｉｒｏｎｍｅｎｔＭａｐは、キューブマッピングを可能にするための特定のフォーマットであると予期されるテクスチャであることに留意されたい。具体的には、キューブマップの６面が、Ｔｅｘｔｕｒｅに関連付けられたＢｒｕｓｈの周知のセクションにおいて表現されることが必要となる（Ｂｒｕｓｈ上の３ｘ２グリッドのようなものである可能性が高い）。
【０２０９】
Ａｍｂｉｅｎｔ、ＤｉｆｆｕｓｅおよびＳｐｅｃｕｌａｒプロパティは、ＢａｓｉｃＭａｔｅｒｉａｌを取り、汎用のＭａｔｅｒｉａｌを取らず、これは、これらがＡｄｖａｎｃｅｄＭａｔｅｒｉａｌそのものとして指定されないからである。また、環境マップはＢｒｕｓｈＭａｔｅｒｉａｌであることにも留意されたい。
【０２１０】
（ＢｕｍｐＭａｐ定義）
Ｂｕｍｐマップは、テクスチャのように、３Ｄプリミティブ上に、プリミティブ上のテクスチャ座標を介してマップされるグリッドである。しかし、補間データは表面の標準への摂動として解釈され、結果としてプリミティブの「でこぼこ」な外観となる。これを達成するため、バンプマップは、標準摂動などの情報、および潜在的に他の情報を伝える。バンプマップは色または透過性情報を伝えない。このため、Ｂｒｕｓｈをバンプマップとして使用することは不適当である。
【０２１１】
したがって、新しいＢｕｍｐＭａｐクラスを導入し、これは特定のピクセルフォーマットのＩｍａｇｅＳｏｕｒｃｅとなる。
【０２１２】
【表４７】
【０２１３】
（ＭａｔｅｒｉａｌのためのＴｙｐｅＣｏｎｖｅｒｔｅｒ）
Ｍａｔｅｒｉａｌは、Ｂｒｕｓｈの文字列指定が自動的にＢｒｕｓｈＭａｔｅｒｉａｌにプロモートされることを可能にする、単純なＴｙｐｅＣｏｎｖｅｒｔｅｒを提供する。
【０２１４】
【表４８】
【０２１５】
これは以下のような指定を可能にする。
【０２１６】
【表４９】
【０２１７】
（「アンビエント」パラメータ）
このセクションでは、ジオメトリック階層内の任意のレベルで埋め込み可能ではないモデルの「アンビエント」パラメータを考察する。
【０２１８】
（Ｆｏｇ）
ＦｏｇプロパティをＶｉｓｕａｌ３Ｄ上に設定することによって、Ｆｏｇを場面に追加することができる。使用可能なＦｏｇは「ピクセルフォグ」である。Ｆｏｇは、抽象クラス、および以下に示すような階層として表現される。
【０２１９】
【表５０】
【０２２０】
ｆｏｇＤｅｎｓｉｔｙは０〜１の範囲であり、フォグの密度の正規化表現である。
【０２２１】
ｆｏｇＳｔａｒｔおよびｆｏｇＥｎｄは装置空間［０，１］内で指定されたｚ深度であり、フォグが開始および終了するところを表す。
【０２２２】
（Ｃａｍｅｒａ）
図１のＣａｍｅｒａオブジェクト３２は、３Ｄモデルが２Ｄビジュアル上に投影される機構である。Ｃａｍｅｒａ自体は抽象タイプであり、２つのサブクラスはＰｒｏｊｅｃｔｉｏｎＣａｍｅｒａおよびＭａｔｒｉｘＣａｍｅｒａである。ＰｒｏｊｅｃｔｉｏｎＣａｍｅｒａ自体は抽象クラスであり、２つの具象サブクラスのＰｅｒｓｐｅｃｔｉｖｅＣａｍｅｒａおよびＯｒｔｈｏｇｏｎａｌＣａｍｅｒａを有する。ＰｅｒｓｐｅｃｔｉｖｅＣａｍｅｒａは、Ｐｏｓｉｔｉｏｎ、ＬｏｏｋＡｔＰｏｉｎｔおよびＦｉｅｌｄＯｆＶｉｅｗなどのよく理解されたパラメータを取り、Ｃａｍｅｒａを構築する。ＯｒｔｈｏｇｏｎａｌＣａｍｅｒａはＰｅｒｓｐｅｃｔｉｖｅＣａｍｅｒａに類似しており、ただしＯｒｔｈｏｇｏｎａｌＣａｍｅｒａはＦｉｅｌｄＯｆＶｉｅｗの代わりにＷｉｄｔｈを取る。ＭａｔｒｉｘＣａｍｅｒａは、Ｗｏｒｌｄ−Ｔｏ−Ｄｅｖｉｃｅ変換を定義するために使用されたＭａｔｒｉｘ３Ｄを取る。
【０２２３】
【表５１】
【０２２４】
Ｖｉｓｕａｌ３Ｄで、ＣａｍｅｒａはビューをＭｏｄｅｌ３Ｄ上に提供するために使用され、結果として生じる投影は、Ｖｉｓｕａｌ３Ｄ上で確立された２Ｄ ＶｉｅｗＰｏｒｔにマップされる。
【０２２５】
また、Ｖｉｓｕａｌ３Ｄの２Ｄ境界ボックスは単に、その凸の、軸に合わせられた包によりラップされ、ビジュアル上で確立されたクリップにクリップされた、３Ｄモデルの投影された３Ｄボックスとなる。
【０２２６】
（ＰｒｏｊｅｃｔｉｏｎＣａｍｅｒａ）
図１のＰｒｏｊｅｃｔｉｏｎＣａｍｅｒａオブジェクト３９は、ＰｅｒｓｐｅｃｔｉｖｅＣａｍｅｒａおよびＯｒｔｈｏｇｏｎａｌＣａｍｅｒａが派生する元の抽象親である。ＰｒｏｊｅｃｔｉｏｎＣａｍｅｒａオブジェクト３９は、ＭＩＬ（媒体統合レイヤ）がサポートするＰｒｏｊｅｃｔｉｏｎＣａｍｅｒａの両方の型に共通である、位置、見る方向および上方向などのプロパティをカプセル化する。
【０２２７】
【表５２−１】
【０２２８】
【表５２−２】
【０２２９】
（ＰｅｒｓｐｅｃｔｉｖｅＣａｍｅｒａ）
図１のＰｅｒｓｐｅｃｔｉｖｅＣａｍｅｒａオブジェクト３６は、それによってＰｏｓｉｔｉｏｎ、ＬｏｏｋＡｔＰｏｉｎｔおよびＦｉｅｌｄＯｆＶｉｅｗなどのよく理解されたパラメータから透視投影カメラが構築される手段である。以下の例示は、ＰｅｒｓｐｅｃｔｉｖｅＣａｍｅｒａの関連する態様のよい指示を提供する。
【０２３０】
【表５３】
【０２３１】
【表５４】
【０２３２】
以下に留意されたい。
・ＰｅｒｓｐｅｃｔｉｖｅＣａｍｅｒａは、位置、見る方向および上ベクトルプロパティをＰｒｏｊｅｃｔｉｏｎＣａｍｅｒａから継承する。
・ＦｉｅｌｄＯｆＶｉｅｗは水平視野を表し、度で指定される（他のすべてのＭＩＬ角と同様）。
・ＮｅａｒおよびＦａｒ ＰｌａｎｅＤｉｓｔａｎｃｅは、カメラのＰｏｓｉｔｉｏｎから、ＬｏｏｋＤｉｒｅｃｔｉｏｎ点によって定義されたベクトルに沿った、３Ｄワールド座標距離を表す。ＮｅａｒＰｌａｎｅＤｉｓｔａｎｃｅのデフォルトは０であり、ＦａｒＰｌａｎｅＤｉｓｔａｎｃｅのデフォルトは無限となる。
・実際の投影の上で、Ｎｅａｒ／ＦａｒＰｌａｎｅＤｉｓｔａｎｃｅがなおそれぞれ０／無限である場合、モデルが検査され、その境界ボリュームはカメラの投影に従って投影される。結果として生じる境界ボリュームが次いで検査され、近平面距離は、カメラ位置に最も近いＬｏｏｋＤｉｒｅｃｔｉｏｎに垂直な境界ボリュームの平面に設定されるようになる。遠平面についても同じであるが、最も遠い平面を使用する。これは結果として、なおモデル全体を表示しながら、ｚバッファ解決の最適な使用となる。
【０２３３】
ＰｅｒｓｐｅｃｔｉｖｅＣａｍｅｒａのパラメータによって定義された「投影面」は次いでＶｉｓｕａｌ３Ｄ上のＶｉｅｗＰｏｒｔ長方形にマッピングされること、および、３空間から２空間への最終移行を表すことに留意されたい。
【０２３４】
（ＯｒｔｈｏｇｏｎａｌＣａｍｅｒａ）
図１のＯｒｔｈｏｇｏｎａｌＣａｍｅｒａオブジェクト３７は、ワールドから装置空間への垂直投影を指定する。ＰｅｒｓｐｅｃｔｉｖｅＣａｍｅｒａのように、ＯｒｔｈｏｇｏｎａｌＣａｍｅｒａ、すなわち垂直カメラは、位置、見る方向、および上方向を指定する。しかし、ＰｅｒｓｐｅｃｔｉｖｅＣａｍｅｒａとは異なり、ＯｒｔｈｏｇｏｎａｌＣａｍｅｒａは、透視短縮を含まない投影を記述する。物理的には、ＯｒｔｈｏｇｏｎａｌＣａｍｅｒａは、その辺が平行であるビューイングボックスを記述する（ＰｅｒｓｐｅｃｔｉｖｅＣａｍｅｒａは、その辺が最終的にカメラの点に集まるビューイングｆｒｕｓｔｒｕｍを記述する）。
【０２３５】
【表５５−１】
【０２３６】
【表５５−２】
【０２３７】
以下に留意されたい。
・ＯｒｔｈｏｇｏｎａｌＣａｍｅｒａは、位置、見る方向および上ベクトルプロパティをＰｒｏｊｅｃｔｉｏｎＣａｍｅｒａから継承する。
・ＷｉｄｔｈはＯｒｔｈｏｇｏｎａｌＣａｍｅｒａのビューイングボックスの幅を表し、ワールドユニットで指定される。
・ＮｅａｒおよびＦａｒ ＰｌａｎｅＤｉｓｔａｎｃｅは、ＰｅｒｓｐｅｃｔｉｖｅＣａｍｅｒａについて振る舞うのと同じように振る舞う。
【０２３８】
（ＭａｔｒｉｘＣａｍｅｒａ）
図１のＭａｔｒｉｘＣａｍｅｒａオブジェクト３８は、Ｃａｍｅｒａのサブクラスであり、Ｍａｔｒｉｘを投影変換として直接指定することに備える。これは、それら自体の投影行列計算機構を有するアプリケーションにとって有用である。これは明確に、システムの高度な使用を表す。
【０２３９】
【表５６】
【０２４０】
以下に留意されたい。
・ＶｉｅｗＭａｔｒｉｘは、ＭａｔｒｉｘＣａｍｅｒａのための位置、見る方向および上ベクトルを表す。これは、ビルボーディングのために、Ｍｏｄｅｌ３Ｄ階層のトップレベル変換とは異なる場合がある。ＰｒｏｊｅｃｔｉｏｎＭａｔｒｉｘはカメラ空間からの場面を装置空間に変換する。
【０２４１】
ＭｉｎｉｍｕｍＺおよびＭａｘｉｍｕｍＺプロパティは削除されており、これは、これらの値がＭａｔｒｉｘＣａｍｅｒａの投影行列によって暗示されるからである。投影行列は座標系をカメラ空間から、正規化されたキューブへ変換し、ただしＸおよびＹは［−１，１］からの範囲となり、ｚは［０，１］からの範囲となる。カメラ空間内の最低および最大ｚ座標は、投影行列がどのようにｚ座標を変換するかによって定義される。
【０２４２】
結果として生じる投影は、Ｖｉｓｕａｌ３Ｄ上のＶｉｅｗＰｏｒｔ長方形にマップされること、および、３空間から２空間への最終移行を表すことに留意されたい。
【０２４３】
（ＸＡＭＬマークアップの例）
以下は、ＸＡＭＬにおけるＭｏｄｅｌ３Ｄ階層全体の指定を示す、より完全なマークアップである。構文のいくつかは汎用により変わる場合があることに留意されたい。
【０２４４】
（単純なｘファイルインポートおよび合成）
この例は単に、２つのインポートされた．ｘファイル、および、そのうちの１つにおける回転変換を有するＭｏｄｅｌ、ならびに、０、１、０で上に起き上がる単一の白色点ライトを作成する。
【０２４５】
【表５７】
【０２４６】
このとき、このマークアップは次いで、ファイル、ストリーム、リソース、どんなものの中にもあるようになる。クライアントプログラムはそのＸＡＭＬのロードを呼び出すようになり、それにより、アプリケーションによってそれが適合を見るときに使用される、完全なＭｏｄｅｌ３ＤＧｒｏｕｐを構築するようになる。
【０２４７】
（明示的Ｍｅｓｈ宣言）
この例は、明示的に宣言されたＭｅｓｈＰｒｉｍｉｔｉｖｅ３Ｄを、複合プロパティＸＡＭＬ構文の使用を通じて提供する。メッシュは、黄色から赤までのＬｉｎｅａｒＧｒａｄｉｅｎｔによりテクスチャリングされるようになる。
【０２４８】
また、ライトも場面内にある。
【０２４９】
【表５８】
【０２５０】
（．ｘファイル上のアニメーション）
この例は最初の．ｘファイルを取り、ＸＡＭＬ指定のアニメーションをアドインする。この特定のものは、ｘファイルを１ｘから２．５ｘまで５秒に渡ってスケールし、反転し、無期限に繰り返す、均等スケールを追加する。これはまた、そのスケールのスローイン／スローアウトのための加速／減速も使用する。
【０２５１】
【表５９】
【０２５２】
（ＶｉｓｕａｌＭａｔｅｒｉａｌ指定）
この例は．ｘファイルをインポートし、ライブＵＩをそのマテリアルとして適用する。
【０２５３】
【表６０−１】
【０２５４】
【表６０−２】
【０２５５】
（Ｖｉｅｗｐｏｒｔ３ＤのためのＡＰＩ）
Ｖｉｅｗｐｏｒｔ３ＤのためのＡＰＩ指定は、以下の通りである。
【０２５６】
【表６１】
【０２５７】
これで本発明のこの実施形態におけるＭｏｄｅｌ ３Ｄ ＡＰＩ定義を完了する。
【０２５８】
本発明を、コンピュータの構造上の特徴、方法的動作、およびコンピュータ読取り可能な媒体によるものに特有の言語で説明したが、添付の特許請求の範囲で定義された本発明は必ずしも、説明した特定の構造、動作または媒体に限定されないことを理解されたい。したがって、特定の構造上の特徴、動作および媒体は、主張された本発明を実施する例示的実施形態として開示される。
【０２５９】
上述の様々な実施形態は例示としてのみ提供され、本発明を限定するように解釈されるべきではない。本明細書で例示および説明した実施形態および応用例の例に従うことなく、および、以下の特許請求の範囲に示す本発明の真の趣旨および範囲から逸脱することなく、本発明に行われる可能性のある様々な修正および変更は、当業者には容易に理解されよう。
【図面の簡単な説明】
【０２６０】
【図１】本発明の一実施形態による、モデル３Ｄ構築ＡＰＩにおける関連オブジェクトのデータ構造を例示する図である。
【図２】本発明の実施形態を実施することができる、適切なコンピューティングシステム環境の一実施例を例示する図である。
【図３】本発明を組み込むことができるグラフィックスレイヤアーキテクチャを全体的に表すブロック図である。
【図４】シーングラフをトラバースしてグラフィックスコマンドおよび他のデータを提供することによるなど、シーングラフを処理するためのビジュアルおよび関連コンポーネントのシーングラフの表現の図である。
【図５】妥当性検査ビジュアル、描画ビジュアル、および、構築された関連描画プリミティブのシーングラフの表現の図である。
【図６】オートバイを３Ｄ場面としてレンダリングするための例示的Ｍｏｄｅｌ３Ｄツリー階層を例示する図である。
【図７】図６に示されたものなど、３Ｄシーンツリー階層を処理するための演算フローを示す図である。
【図８】Ｍｏｄｅｌ３Ｄグループオブジェクト内に含まれたＴｒａｎｓｆｏｒｍ３Ｄオブジェクトのための関連オブジェクトのデータ構造を示す図である。
【図９】Ｍｏｄｅｌ３Ｄ ＡＰＩ内のライトオブジェクトのための関連オブジェクトのデータ構造を示す図である。
【特許請求の範囲】
【請求項１】
３次元（３Ｄ）モデルをレンダリングするためのツリー階層内のコンピュータプログラムオブジェクトに適用されたコンピュータデータ構造であって、
３Ｄ場面をレンダリングするためのオブジェクトツリー階層と、
前記３Ｄ場面のための前記オブジェクトを収集する、前記ツリー階層内のルートオブジェクトと、
前記ツリー階層内の１つまたは複数のグループオブジェクトであって、他のグループオブジェクトおよびリーフオブジェクトを収集し、および前記グループオブジェクトの収集されたオブジェクトに作用する変換を有する１つまたは複数のグループオブジェクトと、
３Ｄモデルを前記３Ｄ場面内でレンダリングすることにおいて使用されるべきイルミネーションを定義する前記ツリー階層内のライトオブジェクト、および
３Ｄモデルを前記３Ｄ場面内で描画する演算を定義する、１つまたは複数の描画３Ｄオブジェクト
を含む前記ツリー階層内のリーフオブジェクトと
を備えたことを特徴とするデータ構造。
【請求項２】
そこから前記３Ｄ場面を２Ｄ画像として見るための３Ｄ空間内のカメラアイポイント位置を定義するカメラデータをさらに備えたことを特徴とする請求項１に記載のデータ構造。
【請求項３】
前記３Ｄ場面の２Ｄ画像を見る２Ｄウィンドウの境界を定義するビューポートデータをさらに備えたことを特徴とする請求項２に記載のデータ構造。
【請求項４】
前記ツリー階層内の前記描画オブジェクトの描画演算を変換して、前記３Ｄモデルを前記３Ｄ場面内で変換する前記グループオブジェクトをさらに備えたことを特徴とする請求項１に記載のデータ構造。
【請求項５】
描画オブジェクトが、前記描画演算を実行して２Ｄ画像を前記３Ｄ場面内で作成する１つまたは複数のビジュアルモデルオブジェクトをさらに備えたことを特徴とする請求項１に記載のデータ構造。
【請求項６】
合成システムによってレンダリングされた３次元（３Ｄ）モデルの２次元（２Ｄ）ビューの描画に関して、コンピュータプログラムオブジェクトの階層を処理するための方法であって、
オブジェクトの３Ｄ場面ツリー階層の枝をトラバースして、前記ツリーのグループオブジェクトおよびリーフオブジェクトを処理するステップと、
次の未処理オブジェクトがグループオブジェクトであるか、リーフオブジェクトであるかを検出するステップと、
リーフオブジェクトが検出される場合、前記リーフオブジェクトがライトオブジェクトであるか、描画３Ｄオブジェクトであるかを検出するステップと、
前記リーフオブジェクトがライトオブジェクトである場合、描画３Ｄオブジェクトによって使用されるべきイルミネーションを設定するステップと、
描画３Ｄオブジェクトが検出される場合、３Ｄモデルを、前記ライトオブジェクトによって提供されたイルミネーションによって照らされるように描画するステップと
を備えたことを特徴とする方法。
【請求項７】
カメラのアイポイントを設定するステップと、
前記描画する動作は、前記３Ｄモデルを前記カメラのアイポイントに基づいて描画するステップと
をさらに備えたことを特徴とする請求項６に記載の方法。
【請求項８】
前記３Ｄ場面ツリー内のリーフオブジェクトをリーフオブジェクトのグループに集めるステップと、
グループ演算を前記リーフオブジェクトのグループにおいて実行するステップと
をさらに備えたことを特徴とする請求項６に記載の方法。
【請求項９】
前記グループ演算は、前記グループ内の前記描画オブジェクトによる描画演算を変換するための１つまたは複数の変換演算であることを特徴とする請求項８に記載の方法。
【請求項１０】
前記描画オブジェクトは、
３Ｄモデルを前記３Ｄ場面内で描画するプリミティブ３Ｄ描画オブジェクト
を含むことを特徴とする請求項６に記載の方法。
【請求項１１】
前記描画オブジェクトは、
２Ｄ画像を前記３Ｄ場面内で描画するモデル３Ｄ描画オブジェクト
を含むことを特徴とする請求項６に記載の方法。
【請求項１２】
コンピューティングシステムにおける、モデル３Ｄオブジェクトによって定義された３Ｄモデルの３次元（３Ｄ）場面を作成するためのアプリケーションプログラムインターフェースであって、
前記３Ｄ場面の３Ｄモデルを描画する命令を定義する１つまたは複数の描画オブジェクトと、
前記３Ｄ場面内の前記３Ｄモデルのイルミネーションを定義するライトオブジェクトと
を備えたことを特徴とするアプリケーションプログラムインターフェース。
【請求項１３】
１つまたは複数の描画オブジェクトをグループに収集して、前記グループ内の前記描画オブジェクトによって描画された前記モデルの組合せであるモデルを描画するグループオブジェクト
をさらに備えたことを特徴とする請求項１２に記載のアプリケーションプログラムインターフェース。
【請求項１４】
前記グループオブジェクトは、前記グループ内の前記描画オブジェクトに作用する１つまたは複数のグループ演算を含むことを特徴とする請求項１３に記載のアプリケーションプログラムインターフェース。
【請求項１５】
前記グループ演算は、
前記グループ内の前記描画オブジェクトの１つまたは複数の描画演算に作用する変換
を含むことを特徴とする請求項１４に記載のアプリケーションプログラムインターフェース。
【請求項１】
３次元（３Ｄ）モデルをレンダリングするためのツリー階層内のコンピュータプログラムオブジェクトに適用されたコンピュータデータ構造であって、
３Ｄ場面をレンダリングするためのオブジェクトツリー階層と、
前記３Ｄ場面のための前記オブジェクトを収集する、前記ツリー階層内のルートオブジェクトと、
前記ツリー階層内の１つまたは複数のグループオブジェクトであって、他のグループオブジェクトおよびリーフオブジェクトを収集し、および前記グループオブジェクトの収集されたオブジェクトに作用する変換を有する１つまたは複数のグループオブジェクトと、
３Ｄモデルを前記３Ｄ場面内でレンダリングすることにおいて使用されるべきイルミネーションを定義する前記ツリー階層内のライトオブジェクト、および
３Ｄモデルを前記３Ｄ場面内で描画する演算を定義する、１つまたは複数の描画３Ｄオブジェクト
を含む前記ツリー階層内のリーフオブジェクトと
を備えたことを特徴とするデータ構造。
【請求項２】
そこから前記３Ｄ場面を２Ｄ画像として見るための３Ｄ空間内のカメラアイポイント位置を定義するカメラデータをさらに備えたことを特徴とする請求項１に記載のデータ構造。
【請求項３】
前記３Ｄ場面の２Ｄ画像を見る２Ｄウィンドウの境界を定義するビューポートデータをさらに備えたことを特徴とする請求項２に記載のデータ構造。
【請求項４】
前記ツリー階層内の前記描画オブジェクトの描画演算を変換して、前記３Ｄモデルを前記３Ｄ場面内で変換する前記グループオブジェクトをさらに備えたことを特徴とする請求項１に記載のデータ構造。
【請求項５】
描画オブジェクトが、前記描画演算を実行して２Ｄ画像を前記３Ｄ場面内で作成する１つまたは複数のビジュアルモデルオブジェクトをさらに備えたことを特徴とする請求項１に記載のデータ構造。
【請求項６】
合成システムによってレンダリングされた３次元（３Ｄ）モデルの２次元（２Ｄ）ビューの描画に関して、コンピュータプログラムオブジェクトの階層を処理するための方法であって、
オブジェクトの３Ｄ場面ツリー階層の枝をトラバースして、前記ツリーのグループオブジェクトおよびリーフオブジェクトを処理するステップと、
次の未処理オブジェクトがグループオブジェクトであるか、リーフオブジェクトであるかを検出するステップと、
リーフオブジェクトが検出される場合、前記リーフオブジェクトがライトオブジェクトであるか、描画３Ｄオブジェクトであるかを検出するステップと、
前記リーフオブジェクトがライトオブジェクトである場合、描画３Ｄオブジェクトによって使用されるべきイルミネーションを設定するステップと、
描画３Ｄオブジェクトが検出される場合、３Ｄモデルを、前記ライトオブジェクトによって提供されたイルミネーションによって照らされるように描画するステップと
を備えたことを特徴とする方法。
【請求項７】
カメラのアイポイントを設定するステップと、
前記描画する動作は、前記３Ｄモデルを前記カメラのアイポイントに基づいて描画するステップと
をさらに備えたことを特徴とする請求項６に記載の方法。
【請求項８】
前記３Ｄ場面ツリー内のリーフオブジェクトをリーフオブジェクトのグループに集めるステップと、
グループ演算を前記リーフオブジェクトのグループにおいて実行するステップと
をさらに備えたことを特徴とする請求項６に記載の方法。
【請求項９】
前記グループ演算は、前記グループ内の前記描画オブジェクトによる描画演算を変換するための１つまたは複数の変換演算であることを特徴とする請求項８に記載の方法。
【請求項１０】
前記描画オブジェクトは、
３Ｄモデルを前記３Ｄ場面内で描画するプリミティブ３Ｄ描画オブジェクト
を含むことを特徴とする請求項６に記載の方法。
【請求項１１】
前記描画オブジェクトは、
２Ｄ画像を前記３Ｄ場面内で描画するモデル３Ｄ描画オブジェクト
を含むことを特徴とする請求項６に記載の方法。
【請求項１２】
コンピューティングシステムにおける、モデル３Ｄオブジェクトによって定義された３Ｄモデルの３次元（３Ｄ）場面を作成するためのアプリケーションプログラムインターフェースであって、
前記３Ｄ場面の３Ｄモデルを描画する命令を定義する１つまたは複数の描画オブジェクトと、
前記３Ｄ場面内の前記３Ｄモデルのイルミネーションを定義するライトオブジェクトと
を備えたことを特徴とするアプリケーションプログラムインターフェース。
【請求項１３】
１つまたは複数の描画オブジェクトをグループに収集して、前記グループ内の前記描画オブジェクトによって描画された前記モデルの組合せであるモデルを描画するグループオブジェクト
をさらに備えたことを特徴とする請求項１２に記載のアプリケーションプログラムインターフェース。
【請求項１４】
前記グループオブジェクトは、前記グループ内の前記描画オブジェクトに作用する１つまたは複数のグループ演算を含むことを特徴とする請求項１３に記載のアプリケーションプログラムインターフェース。
【請求項１５】
前記グループ演算は、
前記グループ内の前記描画オブジェクトの１つまたは複数の描画演算に作用する変換
を含むことを特徴とする請求項１４に記載のアプリケーションプログラムインターフェース。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公表番号】特表２００７−５３６６２２（Ｐ２００７−５３６６２２Ａ）
【公表日】平成１９年１２月１３日（２００７．１２．１３）
【国際特許分類】
【出願番号】特願２００７−５１１３４５（Ｐ２００７−５１１３４５）
【出願日】平成１６年７月２９日（２００４．７．２９）
【国際出願番号】ＰＣＴ／ＵＳ２００４／０２４３６９
【国際公開番号】ＷＯ２００５／１１１９３９
【国際公開日】平成１７年１１月２４日（２００５．１１．２４）
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
【公表日】平成１９年１２月１３日（２００７．１２．１３）
【国際特許分類】
【出願日】平成１６年７月２９日（２００４．７．２９）
【国際出願番号】ＰＣＴ／ＵＳ２００４／０２４３６９
【国際公開番号】ＷＯ２００５／１１１９３９
【国際公開日】平成１７年１１月２４日（２００５．１１．２４）
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
[ Back to top ]