JP2003510704A - シーン・ベース・プログラムの高速処理の方法およびシステム - Google Patents

Abstract

(57)【要約】 シーン・グラフ・ベースのデータおよび／またはプログラムもしくはその両方の高速処理のシステムおよび方法を開示する。一実施形態では、シーン・グラフを直接に使用するようにシステムを構成することができる。もう１つの実施形態では、元々シーン・グラフの一部として受け取られたデータを管理する、複数の構造体およびスレッドを生成するようにシステムを構成することができる。構造体およびスレッドは、メッセージングの使用を介して状態変化に関する情報を伝えるように構成することができる。このシステムには、スレッド間のメッセージングと、タイム・スタンプおよび／またはイベント・スタンプを用いるメッセージングと、一貫性を保証するためのエポックと、レンダ・ビン、ジオメトリ構造体、およびレンダリング環境構造体などの補助構造体とのサポートを含めることができる。

Description

【発明の詳細な説明】

【０００１】 （発明の背景） １．発明の分野 本発明は、全般的にはコンピュータ・グラフィックスの分野に関し、より具体
的には、３次元グラフィックス・データを管理し、レンダリングするグラフィッ
クス・システムおよびグラフィックス・ソフトウェアに関する。

【０００２】 ２．関連技術の説明 コンピュータ・システムは、通常、コンピュータ・スクリーンまたはディスプ
レイ・デバイスへのビジュアル出力を生成するために、そのグラフィックス・シ
ステムを利用する。初期のグラフィックス・システムは、プロセッサが出力とし
て生成したものを受け取り、それをスクリーンに表示することを担当するだけで
あった。本質的に、これらのグラフィックス・システムは、単純なトランスレー
タまたはインターフェースとして働いた。しかし、現代のグラフィックス・シス
テムには、高い処理能力を有するグラフィックス・プロセッサが組み込まれてい
る。これらのグラフィックス・プロセッサは、単純なトランスレータではなく、
コプロセッサのように働く。この変化は、ディスプレイ・デバイスに送られるデ
ータの複雑さと量の両方における最近の増加に起因する。たとえば、現代のコン
ピュータ・ディスプレイは、初期のモデルより多数の画素、より多くのカラー・
デプスを表示し、より複雑な画像をより高いリフレッシュ・レートで表示するこ
とができる。同様に、表示される画像は、より複雑であり、アンチエイリアスお
よびテクスチャ・マッピングなどの高度な技法を用いることができる。

【０００３】 その結果、グラフィックス・システムにかなりの処理能力がなければ、ＣＰＵ
が、グラフィックス計算の実行に長時間を費やすことになる。これによって、プ
ログラム実行に関連する他のタスクを実行するのに必要な処理能力がコンピュー
タ・システムから奪われ、これによって、総合システム性能が劇的に低下する可
能性がある。しかし、強力なグラフィックス・システムがあれば、ＣＰＵが、ス
クリーンに箱を描くように指示された時に、ＣＰＵが、各画素の位置および色を
計算する必要から解放される。その代わりに、ＣＰＵは、「この座標に箱を描け
」と述べる要求をビデオ・カードに送ることができる。グラフィックス・システ
ムが、箱を描き、他のタスクを実行するためにプロセッサを解放する。

【０００４】 一般に、コンピュータ内のグラフィックス・システム（グラフィックス・シス
テムとも称する）は、性能レベルを高めるためにそれ自体のプロセッサを含むビ
デオ・アダプタの１種である。これらのプロセッサは、グラフィカル変換の計算
用に特殊化され、したがって、コンピュータ・システムによって使用される汎用
ＣＰＵよりもよい結果を達成する。さらに、これらのプロセッサは、グラフィッ
クス・システムがグラフィックス計算を処理している間に他のコマンドを実行す
るためにコンピュータのＣＰＵを解放する。グラフィカル・アプリケーション、
特にマルチメディア・アプリケーションの普及によって、高性能グラフィックス
・システムが、コンピュータ・システムの一般的な特徴になった。ほとんどのコ
ンピュータ製造業者が、現在、その自社システムに高性能グラフィックス・シス
テムをバンドルしている。

【０００５】 グラフィックス・システムは、通常は、限られた機能の組だけを実行するので
、カスタマイズすることができ、したがって、グラフィックス・オペレーション
においてコンピュータの汎用中央プロセッサよりはるかに効率的である。初期の
グラフィックス・システムは、２次元（２Ｄ）グラフィックスの実行に制限され
ていたが、グラフィックス・システムの機能性は、３次元（３Ｄ）ワイヤフレー
ム・グラフィックス、３Ｄソリッドをサポートするために高められ、現在では、
高度なシェーディング、フォギング、アルファ・ブレンディング、およびスペキ
ュラ（鏡面反射）・ハイライティングなどの特殊効果およびテクスチャを有する
３次元（３Ｄ）グラフィックスのサポートを含む。

【０００６】 グラフィックス・システムと現代のＣＰＵ全般の両方の新機能を利用するため
に、グラフィックス・アプリケーション・プログラム・インターフェース（「Ａ
ＰＩ」）が開発された。ＡＰＩは、ソフトウェア・アプリケーションを構築する
ためのルーチン、プロトコル、および／またはツールの組である。ＡＰＩでは、
プログラマがアプリケーションを作成するために必要とする基本構成要素の構築
を提供することによって、プログラムを開発するタスクを単純化することが試み
られている。一般的なＡＰＩの一例が、Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔ
ｉｏｎ社のＷｉｎ３２ ＡＰＩである。

【０００７】 グラフィックスＡＰＩは、プログラマがグラフィカル・アプリケーションをす
ばやく開発できるようにする点では成功したが、レンダリングされるシーンの複
雑さの最近の増加が、アプリケーションを実行するＣＰＵおよびグラフィックス
・システムに対するさらに大きな要求を課しつつある。従来は、タスクが単一の
ＣＰＵにとって計算集中的に過ぎるようになった時に、多重ＣＰＵシステムが使
用される。これらの多重ＣＰＵシステムでは、並列処理を使用して、２つ以上の
プロセッサの間で計算を分割する。しかし、通常のグラフィカルＡＰＩは、並列
処理、特にネットワークを介する並列処理を可能にするのによく適してはいない
。したがって、複雑なシーンの作成、更新、およびレンダリングを効率的に管理
するシステムおよび方法が必要である。具体的には、ＡＰＩで実施することがで
き、ネットワーク化された設定での分散処理をサポートすることができるシステ
ムおよび方法も望ましい。

【０００８】 （発明の概要） 上で識別された問題は、本明細書に記載のシーン・グラフ・ベースのデータの
高速処理のシステムおよび方法によって、少なくとも部分的に解決することがで
きる。一実施態様では、このシステムが、シーン・グラフ・ベースのデータに関
する並列構造体を生成する。この並列構造体には、オブジェクトとスレッドの両
方を含めることができる。有利なことに、このシステムは、レンダリングに並列
構造体を使用することができ、これによって、階層（すなわちツリー）形式での
シーン・グラフのトラバーサルの反復を回避することができる。この並列構造体
は、効果的にグラフィックス・アプリケーション・プログラマに見られないよう
にＡＰＩ内で実施することができ、グラフィックス・アプリケーション・プログ
ラマは、シーン・グラフ構造体の使用を継続して、グラフィックス・アプリケー
ションを作成する。

【０００９】 一実施態様では、このシステムを、シーン・グラフを直接に使用するように構
成することができる。もう１つの実施態様では、このシステムを、補助構造体の
ソースとしてシーン・グラフを使用するように構成することができる。補助構造
体は、シーン・グラフ・ベースのプログラムのレンダリングおよび実行の際にシ
ステムを助けることができる。システムには、スレッドとオブジェクトの間のメ
ッセージングと、タイム・スタンプおよび／またはイベント・スタンプを用いる
メッセージングと、一貫性を保証するためのエポックと、レンダ・ビン、ジオメ
トリ構造体、およびレンダリング環境構造体などの補助構造体とのサポートを含
めることもできる。

【００１０】 コンピュータ・プログラムも企図されている。一実施態様では、コンピュータ
・プログラムに、シーン・グラフを受け取り、シーン・グラフをトラバースして
、シーン・グラフに対応する複数の構造体およびスレッドを生成するように構成
された複数の命令が含まれる。シーン・グラフには、複数の３次元オブジェクト
を表す情報を含めることができる。シーン・グラフには、３次元オブジェクトの
挙動データ、サウンド・データ、触覚（たとえばフォース・フィード・バック・
データ）、外見データ、ジオメトリ・データ、環境データ（たとえば照明、フォ
グ）、および他のデータを含む、複数の異なるタイプのデータも含めることがで
きる。情報には、外見データ、ジオメトリ・データ、および環境データを含める
ことができる。各構造体を、シーン・グラフから選択されたデータを管理するオ
ブジェクトとすることができ、複数のスレッドを、シーン・グラフに対応する１
つまたは複数のフレームをレンダリングするために実行可能とすることができる
。いくつかの実施態様では、スレッドを、状態変化を指定するメッセージを生成
するように構成することができ、メッセージを、複数の構造体にマルチキャスト
するか、単一の構造体にユニキャストすることができる。各構造体は、その構造
体を更新するように構成された、対応する更新スレッドを有することができる。
作成される並列構造体の１つが、レンダリングされる特定のジオメトリ・データ
への参照を受け取り、レンダ・ビンに保管するように構成されるレンダ・ビンで
あることが好ましい。レンダ・ビンに、１つまたは複数のレンダ・スレッドを関
連付けることができ、これによって、多数のプロセッサを使用する並列レンダリ
ングが可能になる。

【００１１】 有利なことに、各構造体を、それ自体のデータを管理（し、任意選択として最
適化）するように構成することができる。したがって、１つの構造体によって、
すべての変換データを管理することができ、複数の変換を一緒に縮約することに
よって、複数の変換を最適化することができる。

【００１２】 上で注記したように、シーン・グラフを管理し、レンダリングする方法も企図
されている。一実施態様では、この方法に、複数の３次元オブジェクトを表す情
報を含むシーン・グラフを生成することと、シーン・グラフに対応する構造体お
よびスレッドの並列の組を生成するためにシーン・グラフをトラバースすること
とを含めることができ、各構造体に、シーン・グラフから選択されたデータを管
理するオブジェクトが含まれ、複数のスレッドが、シーン・グラフに対応する１
つまたは複数のフレームをレンダリングするために実行可能である。この方法は
、ソフトウェア、ハードウェア、またはその組合せで実施することができる。

【００１３】 本発明の前述ならびに他の目的、特徴、および長所は、添付図面と併せ読むと
き、以下の詳細な説明を参照することによってさらに完全に理解することができ
る。

【００１４】 本発明は、さまざまな修正形態および代替形態を許すが、その特定の実施態様
を、例として図面に示し、本明細書で詳細に説明する。しかし、図面およびそれ
に対する詳細な説明が、開示される特定の形態に本発明を制限することを意図さ
れたものではなく、逆に、その意図が請求項によって定義される本発明の趣旨お
よび範囲に含まれるすべての修正形態、同等物、および代替形態を含むことであ
ることを理解されたい。単語「できる、可能性がある（ｍａｙ）」は、本出願で
は、必須の意味（すなわちｍｕｓｔ）ではなく、許容的な意味（すなわち、潜在
能力を有する、可能である）で使用される。同様に、単語「含まれる（ｉｎｃｌ
ｕｄｅ）」およびその派生形は、本明細書では、「含むがこれに制限されない（
ｉｎｃｌｕｄｉｎｇ，ｂｕｔ ｎｏｔ ｌｉｍｉｔｅｄ ｔｏ）」を意味するた
めに使用される。

【００１５】 （複数の実施形態の詳細な説明） コンピュータ・システム−図１ 図１を参照すると、上で説明したシステムおよび方法を実施するのに使用する
ことができるコンピュータ・システム１０の一実施形態が示されている。このコ
ンピュータ・システムは、従来のデスクトップ・パーソナル・コンピュータ、ラ
ップトップ・コンピュータ、ネットワークＰＣ、インターネット機器、ＨＤＴＶ
システムおよびインタラクティブ・テレビジョン・システムを含むテレビジョン
、携帯情報端末（ＰＤＡ）、および、２Ｄまたは３Ｄのグラフィックスを表示す
る他の装置を含む、任意の数のさまざまなシステムの基礎として使用することが
できる。

【００１６】 図からわかるように、コンピュータ・システム１０には、システム・ユニット
１２と、システム・ユニット１２に結合されたビデオ・モニタまたはディスプレ
イ・デバイス１４が含まれる。ディスプレイ・デバイス１４は、さまざまなタイ
プのディスプレイ・モニタまたはディスプレイ・デバイスのいずれか（たとえば
ＣＲＴ、ＬＣＤ、ガス−プラズマ・ディスプレイ）とすることができる。キーボ
ード１６および／またはマウス１８もしくは他の入力装置（たとえば、トラック
ボール、ディジタイザ、タブレット、６自由度入力デバイス、ヘッド・トラッカ
、アイ・トラッカ、データ・グローブ、ボディ・センサなど）を含むさまざまな
入力デバイスを、コンピュータ・システムに接続することができる。アプリケー
ション・ソフトウェアを、コンピュータ・システム１０によって実行して、３Ｄ
グラフィカル・オブジェクトをディスプレイ・デバイス１４に表示することがで
きる。アプリケーション・ソフトウェアは、メモリに保管されるか、ネットワー
ク接続を使用してサーバから読み取られるか、コンピュータ・ディスケット、Ｃ
Ｄ−ＲＯＭ、ＤＶＤ−ＲＯＭ、またはコンピュータ・テープなどの記憶媒体から
読み取ることができる。

【００１７】 コンピュータ・システムのブロック図−図２ 図２を参照すると、図１のコンピュータ・システムの一実施形態を示す単純化
されたブロック図が示されている。コンピュータ・システムのうちで、本発明の
理解に必要でない要素は、便宜上図示されていない。図からわかるように、コン
ピュータ・システム１０には、高速メモリ・バスまたはシステム・バス２４に結
合された中央処理装置（ＣＰＵ）２２が含まれる。システム・メモリ２６も、高
速バス２４に結合することができる。

【００１８】 ホスト・プロセッサ２２には、たとえば、マイクロプロセッサ、マルチプロセ
ッサ、およびＣＰＵなどのさまざまなタイプの１つまたは複数のプロセッサを含
めることができる。システム・メモリ２６には、ランダム・アクセス・メモリ（
たとえば、とりわけ、スタティック・ランダム・アクセス・メモリすなわち「Ｓ
ＲＡＭ」、シンクロナス・ダイナミック・ランダム・アクセス・メモリすなわち
「ＳＤＲＡＭ」、およびＲａｍｂｕｓダイナミック・アクセス・メモリすなわち
「ＲＤＲＡＭ」）および大容量記憶装置を含む、異なるタイプのメモリ・サブシ
ステムの組合せを含めることができる。システム・バスまたはホスト・バス２４
には、１つまたは複数の通信バスまたはホスト・コンピュータ・バス（ホスト・
プロセッサ、ＣＰＵ、およびメモリ・サブシステムの間の通信用）ならびに特殊
化されたサブシステム・バスを含めることができる。

【００１９】 本発明による３Ｄグラフィックス・システムまたはグラフィックス・システム
２８が高速メモリ・バス２４に結合される。３Ｄグラフィックス・システム２８
は、たとえば、クロスバ・スイッチまたは他のバス接続性ロジックによって、バ
ス２４に結合することができる。さまざまな他の周辺デバイスまたは他のバスを
、高速メモリ・バス２４に接続できることが仮定される。３Ｄグラフィックス・
システムを、コンピュータ・システム１０内の１つまたは複数のバスに結合でき
、かつ／または、さまざまなタイプのバスに結合できることに留意されたい。さ
らに、３Ｄグラフィックス・システムを、通信ポートに結合し、これによって、
たとえばインターネットまたはネットワークなどの外部ソースからグラフィック
ス・データを直接に受け取ることができる。図からわかるように、ディスプレイ
・デバイス１４が、コンピュータ・システム１０に含まれる３Ｄグラフィックス
・システム２８に接続される。

【００２０】 ホストＣＰＵ２２は、プログラムされた入出力（Ｉ／Ｏ）プロトコルに従って
ホスト・バス２４を介してグラフィックス・システム２８との間で情報を転送す
ることができる。その代わりに、グラフィックス・システム２８が、直接メモリ
・アクセス（ＤＭＡ）プロトコルに従って、またはインテリジェント・バス・マ
スタリングを介して、メモリ・サブシステム２６にアクセスすることができる。

【００２１】 ＯｐｅｎＧＬまたはＪａｖａ（Ｒ） ３Ｄなどのアプリケーション・プログラ
ミング・インターフェース（ＡＰＩ）に準拠するグラフィカル・アプリケーショ
ン・プログラムを、ホストＣＰＵ２２上で実行し、ディスプレイ・デバイス１４
での出力のためのポリゴンなどのジオメトリック・プリミティブ（グラフィック
ス・データ）を定義するコマンドおよびデータを生成することができる。使用さ
れる特定のグラフィックス・インターフェースによる定義に従って、これらのプ
リミティブが、表面と裏面について別々の色プロパティを有することができる。
ホスト・プロセッサ２２は、これらのグラフィックス・データをメモリ・サブシ
ステム２６に転送することができる。その後、ホスト・プロセッサ２２は、ホス
ト・バス２４を介してグラフィックス・システム２８にグラフィックス・データ
を転送するように動作することができる。もう１つの実施形態では、グラフィッ
クス・システム２８が、ＤＭＡアクセス・サイクルを使用して、ホスト・バス２
４を介してジオメトリ・データ配列を読み込むことができる。もう１つの実施形
態では、グラフィックス・システム２８を、Ｉｎｔｅｌ Ｃｏｒｐｏｒａｔｉｏ
ｎ社によって広められたＡｄｖａｎｃｅｄ Ｇｒａｐｈｉｃｓ Ｐｏｒｔ（ＡＧ
Ｐ）などの直接ポートを介してシステム・メモリ２６に結合することができる。

【００２２】 グラフィックス・システムは、ホストＣＰＵ２２および／またはシステム・メ
モリ２６、他のメモリを含むさまざまなソースから、または、たとえばインター
ネットなどのネットワークなど外部ソースから、または、たとえばテレビジョン
などの放送媒体から、または他のソースから、グラフィックス・データを受け取
ることができる。

【００２３】 グラフィックス・システムの一実施形態に、ディスプレイ・バッファに結合さ
れたグラフィックス・プロセッサを含めることができる。本明細書で使用される
ディスプレイ・バッファは、ディスプレイ・デバイスに出力され、表示される特
定のフレームを表す情報（たとえば、画素または画素を形成するのに使用するこ
とができるサンプル）が保管されるバッファである。たとえば、従来のフレーム
・バッファを、ディスプレイ・バッファとみなすことができる。ディスプレイ・
バッファの内容は、通常は、ディスプレイ・デバイスでの表示のために、ディジ
タル情報をアナログ・ビデオ信号に変換するディジタル・アナログ変換器（ＤＡ
Ｃ）に出力される。構成に応じて、グラフィックス・プロセッサ（並列処理シス
テムの場合には複数のプロセッサ）を、メイン・システム・メモリおよび／また
はホストＣＰＵから受け取った、命令を実行するかデータを処理するように構成
することができる。

【００２４】 コンピュータ・システム１０には、コンピュータ・システムがコンピュータ・
ネットワークとの間でデータを送受信できるようにするネットワーク・インター
フェース（図示せず）を含めることもできる。一実施形態では、コンピュータ・
システムを、３次元シーン・グラフの管理およびレンダリングに関連するタスク
をネットワーク上の他のコンピュータに分配するように構成することができる。
タスクは、オブジェクト（たとえばデータとスレッド）をネットワーク上の他の
コンピュータに（すなわち、それぞれがそれ自体の非共有メモリを使用して）送
信することによって分配することができる。これらのコンピュータは、メッセー
ジのシステム（下で詳細に説明する）を介して互いに通信することができる。

【００２５】 シーン・グラフ−図３ 上記のように、シーン・グラフは、特定の３次元シーンまたはワールドを定義
するオブジェクトおよびグラフィックス・データの階層である。たとえば、最上
位ノードが、建物全体と、その建物を占めるすべての家具調度および人を表すこ
とができる。シーン・グラフをトラバースする際に、グループ・ノードの次のレ
ベルが、建物の中の特定の部屋を表すことができる。シーン・グラフをもう１レ
ベルだけトラバースすることによって、それぞれが特定の部屋の中の１人の人ま
たは１つの家具オブジェクト（たとえば椅子）を表すグループ・ノードをもたら
すことができる。各グループ・ノードが、変換ノードの下のどんなノード（すな
わち子ノード）の並行移動かつ／または回転を行う変換ノードも有することがで
きる。多数のレベルのシーン・グラフが可能であるが、最終的に、シーン・グラ
フのトラバースは、リーフ・ノードで終わる。リーフ・ノードは、通常は、ある
オブジェクト（たとえばティー・カップまたは椅子）またはより大きいオブジェ
クトの部分（たとえば人の手）を表す。リーフ・ノードは、通常は、オブジェク
トを記述したグラフィックス・データへの１つまたは複数のポインタを有する。
たとえば、実施形態では、リーフ・ノードが、オブジェクトの形状を定義するポ
リゴン（またはＮＵＲＢＳ（Ｎｏｎ−Ｕｎｉｆｏｒｍ Ｒａｔｉｏｎａｌ Ｂ−
Ｓｐｌｉｎｅ））およびオブジェクトの外見を定義するテクスチャ・マップを含
むデータ・ファイルへのポインタを有することができる。リーフ・ノードは、境
界ボックスへのポインタも有することができる。

【００２６】 シーン・グラフをレンダリングのためにサブミットする前に、「オブジェクト
・カリング」を実行することが有利である。オブジェクト・カリングは、オブジ
ェクトをシーン・グラフから選択的に除去する処理を指す。オブジェクト・カリ
ングのほとんどの実施形態で、オブジェクトは、現在のビューフラスタンの外部
にあるか、さえぎられる（部分的にまたは完全にのいずれか）ので、除去される
。オブジェクトは、多数のオブジェクトを有する複雑なシーン・グラフについて
特に有用である。現在のグラフィックス・ハードウェアは、すべてのオブジェク
トをレンダリングする時に満足なフレーム・レートを達成できない場合があるの
で、オブジェクト・カリング(object culling)によって、現在の視点／方位から
見ることができないオブジェクトの除去を試みる。したがって、オブジェクト・
カリングでは、ビューアに実際に可視であるオブジェクトだけをレンダリングす
ることによって、グラフィックス・パイプライン帯域幅の浪費を減らすことを試
みる。たとえば、特定のシーン・グラフが、都市全体の仮想モデルを表すと仮定
すると、現在の視点が特定の建物の基部に近い場合に、その特定の建物が、その
背後にあるものを覆い隠す。したがって、その建物が不透明であり、その特定の
建物の背後の他の構造の影または反射が可視ではないと仮定すると、これらの隠
された構造のレンダリングにレンダリング・リソースを割り当てる理由はない。

【００２７】 図３に移ると、シーン・グラフ５０の一実施形態が図示されている。この例で
は、シーン・グラフ５０が、Ｊａｖａ（Ｒ） ３Ｄクラスのインスタンスから作
成されるが、他のタイプのシーン・グラフも可能であり、企図されている（たと
えば、ＶＲＭＬシーン・グラフ）。シーン・グラフ５０は、ビジュアル・オブジ
ェクトおよびオーディオ・オブジェクトのジオメトリ、サウンド、ライト、位置
、方位、および外見を定義するオブジェクトから組み立てられる。

【００２８】 図からわかるように、シーン・グラフ５０は、ノードとアークを有するデータ
構造とみなすことができる。ノードは、データ要素を表し、アークは、データ要
素の間の関係を表す。図では、シーン・グラフ５０のノード５４から６６および
７４が、Ｊａｖａ（Ｒ） ３Ｄクラスのインスタンスである。アークは、Ｊａｖ
ａ（Ｒ） ３Ｄクラス・インスタンスの間の２タイプの関係を表す。第１のタイ
プの関係は、親子関係である。たとえば、この実施形態では、分岐グループ・ノ
ード６０などのグループ・ノードが、任意の数の子（Ｓｈａｐｅ３ｄリーフ・ノ
ード６４など）を有することができるが、１つの親（すなわちローカル(locale)
・ノード５４）だけを有する。同様に、リーフ・ノードは、１つの親を有するが
、子は有しない。これらの関係が、図では実線によって示されている。第２のタ
イプの関係が、参照である。参照によって、特定のノード・コンポーネント・オ
ブジェクトがシーン・グラフ・ノードに関連付けられる。ノード・コンポーネン
ト・オブジェクトによって、ビジュアル・オブジェクトのレンダリングに使用さ
れるジオメトリ属性および外見属性が定義される。参照は、図では破線によって
示されている。

【００２９】 図からわかるように、Ｊａｖａ（Ｒ） ３Ｄ（商標）シーン・グラフ５０は、
親子関係でツリー構造を形成するノード・オブジェクトから構成される。あるツ
リー構造の中では、１つのノード（たとえば、図のＶｉｒｔｕａｌＵｎｉｖｅｒ
ｓｅノード５２）がルートである。他のノードは、ルートからアークに従うこと
によってアクセス可能である。シーン・グラフ５０は、ローカル(locale)・オブ
ジェクト５４をルートとするツリーから形成される。ノード・コンポーネントお
よび参照アークは、シーン・グラフ・ツリーの一部ではない。ツリーのルートか
らリーフのそれぞれには１つのパスだけが存在するので、シーン・グラフのルー
トからリーフ・ノードのそれぞれへのパスは１つだけ存在する。シーン・グラフ
５０のルートから特定のリーフ・ノードへのパスを、そのリーフ・ノードの「シ
ーン・グラフ・パス」と呼ぶ。シーン・グラフ・パスは、正確に１つのリーフに
つながるので、シーン・グラフ５０内のリーフごとに１つのシーン・グラフ・パ
スがある。

【００３０】 Ｊａｖａ（Ｒ） ３Ｄシーン・グラフのシーン・グラフ・パスのそれぞれによ
って、そのリーフの状態情報が完全に指定される。状態情報には、ビジュアル・
オブジェクトの位置、方位、およびサイズが含まれる。その結果、各ビジュアル
・オブジェクトのビジュアル属性は、そのシーン・グラフ・パスだけに依存する
。Ｊａｖａ（Ｒ） ３Ｄレンダラは、この事実を利用し、最も効率的であると判
定された順序でリーフをレンダリングする。Ｊａｖａ（Ｒ） ３Ｄプログラマは
、通常は、オブジェクトのレンダリング順序に対する制御を有しない。

【００３１】 シーン・グラフのグラフィック表現は、Ｊａｖａ（Ｒ） ３Ｄプログラムの設
計ツールおよび／またはドキュメンテーションとして働くことができる。シーン
・グラフは、図に示された標準グラフィック・シンボルを使用して描かれる。Ｊ
ａｖａ（Ｒ） ３Ｄプログラムは、シーン・グラフのオブジェクトより多数のオブジェクトを
有することができる。

【００３２】 Ｊａｖａ（Ｒ） ３Ｄ ｖｉｒｔｕａｌ ｕｎｉｖｅｒｓｅを設計するために
は、シンボルの標準セットを使用してシーン・グラフを描く。設計が完了した後
に、そのシーン・グラフ・ドローイングを、プログラムの仕様として使用するこ
とができる。プログラムが完了した後に、同一のシーン・グラフが、プログラム
の簡潔な表現になる（仕様に従ったと仮定して）。したがって、既存のプログラ
ムから描かれたシーン・グラフによって、そのプログラムが作成するシーン・グ
ラフがドキュメント化される。

【００３３】 シーン・グラフ・ベースのプログラムの高速処理 まず、シーン・グラフ・ベース・プログラムのシステムおよび方法の一実施形
態の全般的概要を開示する。その後、Ｊａｖａ（Ｒ） ３Ｄ ＡＰＩのコンテキ
ストで実施されるシステムおよび方法の一実施形態の詳細な説明を開示する。こ
の開示、添付の図面、および請求項を再検討した後に当業者が理解するであろう
ように、他のプログラミング言語および／またはＡＰＩを、本明細書に開示され
たシステムおよび方法を実施するために使用または修正することができる。

【００３４】 上で注記したように、シーン・ベース・プログラムの処理の柔軟性および／ま
たは速度を改善するために、グラフィックス・システム（ハードウェアおよび／
またはソフトウェア）を、直接にまたはさまざまな補助構造体を構築するための
「ソース」構造体としてシーン・グラフを使用するように構成することができる
。シーン・グラフの詳細な説明および例を、付属物２（「Ｇｅｔｔｉｎｇ Ｓｔ
ａｒｔｅｄ ｗｉｔｈ ｔｈｅ Ｊａｖａ（Ｒ） ３Ｄ（商標）ＡＰＩ」）とし
て本明細書に添付する。一実施形態では、グラフィックス・システムを、（ｉ）
たとえばレンダリング（フラスタン・カリング(frustumn culling)およびオクル
ージョン・カリング(occlusion culling）を含む）、サウンド（モノラル、ステ
レオ、３Ｄ化されたサウンドを含む）、実行カリング、衝突検出、および／また
はピッキングもしくはこれらの組合せなどのシーン・グラフ・ベースのプログラ
ムのより効率的なレンダリングおよび実行を助けるか、（ｉｉ）オリジナルのシ
ーン・グラフへの参照が制限されるか存在しない状態での直接実行のための補助
構造体を生成（コンパイル）するのを助けるか、いずれかのために、これらの補
助構造体を使用するように構成することができる。

【００３５】 これには、オリジナル構造体のトラーバサルの範囲を減らすための補助構造体
の使用、それによってオリジナル構造体（シーン・グラフ）への参照を減らすた
めの１つまたは複数の補助構造体によるオリジナル構造体の置換、または、関連
するシーン・グラフ・ベース・プログラムのレンダリングおよび実行（グラフィ
ックス、挙動、サウンド、衝突検出、およびピッキングを含むがこれに制限され
ない）のために十分な情報を含む新しい構造体によるオリジナル構造体の完全な
置換を含めることができるが、これに制限されない。

【００３６】 そのような補助構造体（スケーラビリティのために設計された）の特定の一実
施形態が、ｋ−ｄｏｐ階層のより低次元のバージョンであり、この場合には、可
視性検出、フラスタン・カリング、オクルージョン・カリング、実行カリング、
衝突検出、境界ボリューム判定、およびピッキングに使用される、軸に整列され
た境界ボックス（６−ｄｏｐ）の階層である。そのような実施形態の１つが、１
９９９年２月９日出願の米国特許出願第０９／２４７４６６号、表題「Ｖｉｓｉ
ｂｌｅ Ｏｂｊｅｃｔ Ｄｅｔｅｒｍｉｎａｔｉｏｎ ｆｏｒ Ｉｎｔｅｒａｃ
ｔｉｖｅ Ｖｉｓｕａｌｉｚａｔｉｏｎ」に開示されている。

【００３７】 いくつかの実施形態では、システムが、マスタ・コントロールと称するシステ
ム・ベースのスケジューラをサポートすることができ、このマスタ・コントロー
ルは、シングル・プロセッサ・システムおよびマルチプロセッサ・システムのリ
ソースを含むさまざまなリソースの管理を処理する。マスタ・コントロールは、
さまざまなレンダラおよびシステムの計算を管理し、それらの実行をコンピュー
タのさまざまなプロセッサ、メモリ・システム、および他のネットワーク接続さ
れたコンピュータに割り当てることができる。マスタ・コントロールは、システ
ムのさまざまな計算をシリアライズするか、これらの計算を並列に実行すること
ができる。マスタ・コントロールは、最初のスタートアップ時に、またはシステ
ムが実行を継続する時間にわたって動的にの両方で、レンダリング・コンポーネ
ントおよび計算コンポーネントの追加または除去を可能にすることができる。こ
のさまざまなレンダリング・コンポーネントおよび計算コンポーネントの直交化
によって、新しいレンダラ（たとえば触覚）によるシーン・グラフ実行システム
の拡張または既存レンダラのそのレンダラの異なる実施形態による置換が可能に
なる。

【００３８】 いくつかの実施形態で、このシステムで、状態変化を指定するためのメッセー
ジ・パッシングの使用を実施することもできる。これらのメッセージは、単調増
加するタイムスタンプ／イベントスタンプを用いてラベルが付けられる。これら
の「スタンプされた」またはラベルを付けられたイベントを用いると、一貫性を
保証しながら並列処理または分散処理が可能になる。

【００３９】 いくつかの実施形態では、一貫性を保証するために、「エポック」を使用する
ようにシステムを構成することができる。エポックは、「スタンプされた」メッ
セージの選択されたインターバルに含まれるラベル（タイムスタンプ／イベント
スタンプ）のコンパクトな（連続的な）セットを有するすべてのメッセージから
なる。新しいエポックの連続的な宣言によって、レンダラおよび他の計算が、現
在のエポック内で作業でき、したがって、変更の一貫性のあるセットを操作でき
るようになる。

【００４０】 いくつかの実施形態で、ジオメトリ構造体と呼ばれる補助構造体を使用するこ
とができる。ジオメトリ構造体は、ａｐｐ空間的に配置されたレンダリング可能
なオブジェクトの現在の一貫性のある状態を含むように構成することができる。
この構造体は、レンダリング可能な空間的に配置されたオブジェクトのグループ
化にクラスタ・アルゴリズムを使用する境界ボックス階層とすることができる。
この構造体には、多数のオブジェクトをすばやく含め、除外するための特殊化さ
れたメソッド（スイッチ処理）も含めることができる。この構造体には、さらに
、望ましいプロパティを保持するために階層を再平衡化するための特殊化された
メソッドを含めることができる。この構造体によって、そのオブジェクトへの一
貫性のある同時アクセスが可能になる。

【００４１】 すべての非レンダリング可能な空間的に配置されたオブジェクトの現在の一貫
性のある状態（ライト、フォグ、背景、クリップ、モデル・クリップなどのノー
ドなどの非ジオメトリック・オブジェクトを含む）を含む、レンダリング環境構
造体と呼ばれる補助構造体。この構造体は、オブジェクトをすばやく含め、除外
するための特殊化されたメソッドと、望ましいプロパティを保持するために階層
を再平衡化するための特殊化されたメソッドを共有する。この構造体によって、
そのオブジェクトへの一貫性のある同時アクセスが可能になる。

【００４２】 いくつかの実施形態で、グラフィックス・システムを、レンダ・ビンと称する
補助構造体を生成／サポートするように構成することができる。レンダ・ビンは
、特定のフレームについてレンダリングする必要があるオブジェクトのスーパー
セットを含むように構成することができる。レンダ・ビンは、構造体に保持され
るオブジェクトを「エイジング」し、随時の「コンパクション」計算中に「オー
バーエイジ」オブジェクトを除去することができる。レンダ・ビン構造体は、Ｍ
Ｔ／ＭＰ（マルチスレッド／マルチプロセッサ）対応とすることができ、これに
よって、オブジェクトの追加とオブジェクトへのアクセスの両方のための同時ア
クセスが可能になる。この構造体は、基礎となるレンダリング・ハードウェア・
アーキテクチャとの互換性がより高い順序に、レンダリングされるオブジェクト
をソートすることと、基礎となるハードウェアに対するより適当な一致のために
レンダリング可能なコンポーネントを組み合わせるか分割できるようにする他の
ローカル（ほとんど「ピープホール(peephole)」）最適化のために、レンダリン
グされるオブジェクトをソートすることの両方を行うことができる。レンダ・ビ
ンに保持されたレンダリング可能なオブジェクトに、関連するオブジェクトがレ
ンダリングされる前に実行されるコールバックを関連付けることができ、これら
のオブジェクトは、複数の状態変化オブジェクトへの参照を保持することができ
る。これらのオブジェクトに、複数の変換行列、レンダリング属性、およびジオ
メトリ詳細のレベルを含むシステム固有の計算、またはユーザ指定のバージョン
の前のそれぞれの計算も含めることができる。レンダ・ビン構造体は、レンダリ
ング可能なオブジェクトの大きなグループの包含または除外のために最適化する
ことができる（スイッチ・モード処理）。

【００４３】 図４に移ると、シーン・グラフを管理し、レンダリングするために並列構造体
を作成する方法の一実施形態を示す図が示されている。シーン・グラフには、ロ
ーカル・ノード５４、変換ノード６６ＡからＤ、ビュー・プラットホーム７４、
挙動ノード９２、ライト・ノード９０、およびジオメトリ・ノード・コンポーネ
ント９６が含まれる。この図に、シーン・グラフの一部だけが示されていること
と、追加のノードおよびノード・コンポーネント（たとえばＢｒａｎｃｈＧｒｏ
ｕｐノード）が存在するが、単純にするために図に示されていないことに留意さ
れたい。

【００４４】 図からわかるように、シーン・グラフが作成されるか最初にトラバースされる
際に、複数の構造体２００から２１０を含む並列構成が生成される。各構造体は
、シーン・グラフ内の特定のタイプのオブジェクトに関する責任を負う。たとえ
ば、ジオメトリ構造体２００は、シーン・グラフのジオメトリ・ノード・コンポ
ーネントに関する責任を負う。同様に、レンダリング属性構造体２０２は、現在
の視点およびビュー・フラスタンなどのレンダリング属性に関する責任を負う。
レンダリング環境構造体２０４は、照明および、フォグなどの他の環境効果に関
する責任を負う。変換構造体２０６は、グループ・ノードの変換に関する責任を
負い、挙動構造体２０８は、挙動ノード（たとえば、衝突が検出されるなど、あ
る条件が満たされた結果としてのオブジェクトに対する変化）に関する責任を負
う。レンダ・ビン２１０は、オブジェクトの選択およびレンダリングに関する責
任を負う。

【００４５】 図からわかるように、並列データ構造体２００から２０８は、それぞれが更新
スレッド２００Ｂから２０８Ｂを有することができる。更新スレッドは、変更を
処理するために呼び出すことができる（たとえば、対応するメッセージ・キュー
内のメッセージに基づいて）。たとえば、ライト・ノード９０の色が変化したと
仮定すると、その効果に対するメッセージを、レンダリング環境構造体２０４の
メッセージ・キュー２０４Ａに送ることができる。レンダリング環境構造体の更
新スレッド２０４Ｂを呼び出して、メッセージについてメッセージ・キュー２０
４Ａを検査し、更新メッセージを検出し、それ相応にレンダリング環境構造体２
０４を変更することができる。いくつかの場合に、更新スレッドが、他の構造体
（たとえばレンダ・ビン２１０）に伝えられるそれ自体のメッセージを生成する
ことができる。

【００４６】 レンダ・ビン２１０は、更新スレッドの代わりに複数の異なるレンダ・スレッ
ド２１２Ａから２１２Ｎを用いて構成することができる。これらのスレッドは、
並列に動作し、レンダ・ビン２１０の異なる部分をレンダリングする。その一例
が、仮想現実感用のヘッド・マウント式ディスプレイを使用するシステムである
。ヘッド・マウント式ディスプレイは、通常は、２つのスクリーン（目のそれぞ
れに１つ）を有する。立体視効果を達成するために、各ディスプレイが、通常は
、それぞれが異なる視点に従ってレンダリングされる異なる画像を表示する。し
たがって、２つの異なるディスプレイのそれぞれについて、異なるレンダ・メソ
ッドを開始することができる。同様に、一部の仮想現実感アプリケーションでは
、複数のユーザのそれぞれが、仮想世界を個別にナビゲートする際に、自分自身
の視点を有することができる。もう１つの実施形態では、視点ごとに異なるレン
ダ・ビンを生成する（これは、下で詳細に説明する）。レンダ・スレッドは、並
列に動作することができるが、それぞれが、特定のビューではなく特定の１つま
たは複数のオブジェクトに対応することができる。

【００４７】 複数の異なるタイプの並列データ構造体を図に示し、本明細書で説明するが、
正確な実施形態に依存して、必要に応じて（たとえばサウンドまたはフォース・
フィードバック・デバイスのサポートのため）追加のタイプの並列データ構造体
を作成できることに留意されたい。同様に、複数の追加のスレッドも作成するこ
とができる。

【００４８】 有利なことに、この並列構造体を使用することによって、並列構造体を生成す
るために、シーン・グラフを１回トラバースするだけでよくなる。シーン・グラ
フ・トラーバサルの数を減らすことによって、レンダリング性能を潜在的に改善
することができる。さらに、並列構造体およびそれに対応するスレッドの異なる
部分を、並列処理のためにネットワークを介して別のコンピュータ（すなわち、
１つまたは複数の非共有メモリ・コンピュータ）に伝えることができる。各構造
体がセット・アップされた後に、実行を並列に行うことができ、状態変化情報は
、異なるコンピュータまたはプロセッサの間で伝送されるメッセージを介して伝
えられる。対照的に、シーン・グラフの継続的に繰り返されるトラーバサルは、
特に並列プロセッサがメモリを共有しない時には、並列処理実施形態にも適さな
い。

【００４９】 各構造体２００から２１０は、メッセージを受け取り、保管するように構成さ
れた、対応するメッセージ・キュー２００Ａから２１０Ａを有する。図からわか
るように、シーン・グラフの作成中または最初のトラーバサル中に、メッセージ
を生成し、対応する並列構造体に伝えることができる。たとえば、ジオメトリ・
ノード・コンポーネント９６がシーン・グラフに追加される時に、ジオメトリ構
造体２００のメッセージ・キュー２００Ａにメッセージが送られる。同様に、ラ
イト・ノード９０がシーン・グラフに追加される時に、レンダリング環境構造体
２０４のメッセージ・キュー２０４Ｂにメッセージが送られる。

【００５０】 図５に移ると、シーン・グラフ・ベースのグラフィックス・データを管理し、
レンダリングするために並列構造体を作成する方法の一実施形態の流れ図が示さ
れている。この実施形態では、方法が、ｕｎｉｖｅｒｓｅの作成（ステップ１０
２）から開始（ステップ１００）される。次に、子ノード（たとえば図３および
４に示されたものなど）および分岐のグラフを作成する（ステップ１０４）。こ
の処理を、ツリーが完成するまで継続する（ステップ１０６）。次に、ツリーを
トラバースする（ステップ１１０）。検出されたノードごとに（ステップ１１２
）、メッセージ（たとえば「ＩｎｓｅｒｔＮｏｄｅ」）を生成する（ステップ１
１４）。同様に、検出された新しいビューごとに（ステップ１１６）、メッセー
ジ（たとえば「ＣｒｅａｔｅＲｅｎｄｅｒＢｉｎ」）を生成する（ステップ１１
８）。この処理を、ツリーを完全にトラバースするまで継続する（ステップ１２
０）。他の実施形態では、メッセージを、シーン・グラフ・ツリーの作成と同時
に生成できることに留意されたい。

【００５１】 次に、タイマ・カウンタを初期化することができ（ステップ１２２）、マスタ
・コントロール・スレッドを開始することができる（ステップ１３０）。マスタ
・コントロール・スレッドは、現在のエポックを定義するように構成され（ステ
ップ１３２）、その後、実行のためにスレッドをスケジューリングする（ステッ
プ１３４）。この処理が、実行が完了するまで継続される（ステップ１３６から
１３８）。エポックは、スレッド実行の効率的なスケジューリングを可能にする
ためにマスタ・コントロール・スレッドによって定義される時間期間である。メ
ッセージにタイムスタンプを付けることができ、これによって、マスタ・コント
ロール・スレッドが、スレッドによって処理されるメッセージまたはタスクのエ
イジ（および重要性）に基づいてスレッドをスケジューリングできるようになる
。この時間管理処理の一実施形態を、下で詳細に説明する。

【００５２】 Ｊａｖａ（Ｒ） ３Ｄ（商標）ＡＰＩを使用する例の実施形態 Ｊａｖａ（Ｒ） ３Ｄアーキテクチャ Ｊａｖａ（Ｒ） ３Ｄ ＡＰＩを使用して、上で説明したシステムおよび方法
の一実施形態を実施することができる。そのような実施形態の１つを、下で詳細
に説明する。しかし、他の実施形態も可能であり、企図されていることに留意さ
れたい。この特定の実施形態を説明するために、シーン・グラフ構造体の概要を
提示し、その後、ランタイム・システムのコンポーネントを提示する。次に、シ
ステム・スタートアップ、ランタイム・システム・オペレーション、およびシス
テム・シャットダウンの処理を提示する。その後、この実施形態の特定の特徴を
、さらに詳細に説明する。また、標準Ｊａｖａ（Ｒ）（商標）およびＪａｖａ（
Ｒ） ３Ｄの変数名、オブジェクト名、およびプロセスが、本明細書で使用され
ることに留意されたい。Ｊａｖａ（Ｒ）およびＪａｖａ（Ｒ） ３Ｄに関するさ
らなる情報について、書籍、表題「Ｔｈｅ Ｊａｖａ（Ｒ） ３Ｄ（商標）ＡＰ
Ｉ Ｓｐｅｃｉｆｉｃａｔｉｏｎ」、Ｓｏｗｉｚｒａｌ、Ｒｕｓｈｆｏｒｔｈ、
およびＤｅｅｒｉｎｇ著、Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ Ｐｕｂｌｉｓｈｉｎ
ｇ Ｃｏ．，刊、ＩＳＢＮ：０２０１７１０４１２、および表題「Ｔｈｅ Ｊａ
ｖａ（Ｒ）（商標）Ｐｒｏｇｒａｍｍｉｎｇ Ｌａｎｇｕａｇｅ」、Ｋｅｎ Ａ
ｒｎｏｌｄ、Ｊａｍｅｓ Ｇｏｓｌｉｎｇ、およびＤａｖｉｄ Ｈｏｌｍｅｓ著
、Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ Ｐｕｂｌｉｓｈｉｎｇ Ｃｏ．，刊、ＩＳＢ
Ｎ：０２０１７０４３３１を参照されたい。

【００５３】 シーン・グラフ構造体 Ｊａｖａ（Ｒ） ３Ｄ ＡＰＩは、Ｊａｖａ（Ｒ）クラスのセットである。ア
プリケーションは、これらのクラスのインスタンスを作成し、そのメソッドを呼
び出してＪａｖａ（Ｒ） ３Ｄを制御する。一実施形態では、これらのクラスの
多くを、実際に実装を処理する、保持されるクラス（retained class）を囲むラ
ッパー・クラスにすぎないものとすることができる。ＡＰＩオブジェクトを作成
する時に、そのオブジェクトが、それに保持される対応オブジェクトを作成する
ことができる。これは、ＮｏｄｅおよびＮｏｄｅＣｏｍｐｏｎｅｎｔのサブクラ
スであるすべてのクラスにあてはまる。一実施形態では、作業中のシーン・グラ
フ構造体が、保持される側だけで実装される。

【００５４】 図６に移ると、シーン・グラフ構造体の一実施形態が示されている。この実施
形態では、シーン・グラフ構造体およびすべての子／親関係が、保持されるクラ
スで実装される。ＡＰＩクラスは、保持されるクラス（６２’、６６Ａ’、６６
Ｂ’、６４Ａ’、および６４Ｂ’）のラッパー・クラス（５４、６２、６６Ａ、
６６Ｂ、６４Ａ、６４Ｂ）として構成することができる。さらに、すべてのシー
ン・グラフ・リンク（たとえば親／子関係）が、保持される側で実装される。い
くつかの実施形態では、各クラスのほとんどを、保持される側で実装することが
できる。やはり図に示されているように、この実施形態では、「Ｌｏｃａｌｅ」
クラスが、並列に保持されるクラスを有しない。このタイプの内部構造を使用す
ることの可能な長所の１つは、ｃａｐａｂｉｌｉｔｙ ｂｉｔ処理およびシーン
・グラフのコンパイルが、単純化されることである（下で詳細に説明する）。

【００５５】 ｃａｐａｂｉｌｉｔｙ ｂｉｔ処理 ｃａｐａｂｉｌｉｔｙ ｂｉｔは、Ｊａｖａ（Ｒ） ３Ｄ ＡＰＩで、アプリ
ケーションが、シーン・グラフの異なる部分に対してアプリケーションが行う修
正または照会が何であるかをＪａｖａ（Ｒ） ３Ｄに知らせるのに使用すること
ができる。シーン・グラフ内のＮｏｄｅおよびＮｏｄｅＣｏｍｐｏｎｅｎｔのそ
れぞれが、そのＮｏｄｅまたはＮｏｄｅＣｏｍｐｏｎｅｎｔのために定義された
ｃａｐａｂｉｌｉｔｙ ｂｉｔを有することができる。分岐グラフが、ライブに
された（シーン・グラフに挿入された）か、コンパイルされた（ＢｒａｎｃｈＧ
ｒｏｕｐ．ｃｏｍｐｉｌｅ（）またはＳｈａｒｅｄＧｒｏｕｐ．ｃｏｍｐｉｌｅ
（）を介して）後に、アプリケーションは、それがオブジェクトごとにセットし
たｃａｐａｂｉｌｉｔｙ ｂｉｔに基づく修正または照会だけを行うことができ
る。これは、ＡＰＩクラスのそれぞれのメソッドに、並列に保持されるメソッド
を呼び出す前にｃａｐａｂｉｌｉｔｙ ｂｉｔを検査する責任を負わせることに
よって実施することができる。

【００５６】 下記のコードは、Ｍａｔｅｒｉａｌクラスからのそのようなテストの例である
。 ｐｕｂｌｉｃ ｆｉｎａｌ ｖｏｉｄ ｓｅｔＡｍｂｉｅｎｔＣｏｌｏｒ （Ｃ
ｏｌｏｒ３ｆ ｃｏｌｏｒ） ｛ ｉｆ （ｉｓＬｉｖｅＯｒＣｏｍｐｉｌｅｄ（）） ｉｆ （！ｔｈｉｓ．ｃａｐａｂｉｌｉｔｉｅｓ．ｇｅｔ （ＡＬＬＯＷ＿ＣＯ
ＭＰＯＮＥＮＴ＿ＷＲＩＴＥ）） ｔｈｒｏｗ ｎｅｗ ＣａｐａｂｉｌｉｔｙＮｏｔＳｅｔＥｘｃｅｐｔｉｏｎ
（“Ｍａｔｅｒｉａｌ：ｎｏ ｃａｐａｂｉｌｉｔｙ ｔｏ ｓｅｔ ｃｏｍｐ
ｏｎｅｎｔ”）； （（ＭａｔｅｒｉａｌＲｅｔａｉｎｅｄ） ｔｈｉｓ．ｒｅｔａｉｎｅｄ）．
ｓｅｔＡｍｂｉｅｎｔＣｏｌｏｒ （ｃｏｌｏｒ）； ｝ Ｍａｔｅｒｉａｌ．ＡＬＬＯＷ＿ＣＯＭＰＯＮＥＮＴ＿ＷＲＩＴＥ ｃａｐａ
ｂｉｌｉｔｙ ｂｉｔは、材料（ｍａｔｅｒｉａｌ）属性の設定を制御するため
に定義されたｃａｐａｂｉｌｉｔｙ ｂｉｔである。オブジェクトがコンパイル
されたかライブになった後に変更可能にならないようにするために、いくつかの
メソッドが定義されている。下記のコードは、ＩｍａｇｅＣｏｍｐｏｎｅｎｔ２
Ｄからの例である。 ｐｕｂｌｉｃ ｆｉｎａｌ ｖｏｉｄ ｓｅｔ （ＢｕｆｆｅｒｅｄＩｍａｇｅ
ｉｍａｇｅ） ｛ ｃｈｅｃｋＦｏｒＬｉｖｅＯｒＣｏｍｐｉｌｅｄ（）； （（ＩｍａｇｅＣｏｍｐｏｎｅｎｔ２ＤＲｅｔａｉｎｅｄ） ｔｈｉｓ．ｒｅｔ
ａｉｎｅｄ）． ｓｅｔ（ｉｍａｇｅ）； ｝

【００５７】 この場合、コンポーネントがライブであるかコンパイル済みである場合に、ｃ
ｈｅｃｋＦｏｒＬｉｖｅＯｒＣｏｍｐｉｌｅｄ（）が例外をスローする。いくつ
かの実施形態では、すべてのＮｏｄｅおよびＮｏｄｅＣｏｍｐｏｎｅｎｔが、ｃ
ａｐａｂｉｌｉｔｙ ｂｉｔ処理を実施することができる。したがって、すべて
のＮｏｄｅおよびＮｏｄｅＣｏｍｐｏｎｅｎｔが、並列に保持されるクラスを有
する。ＡＰＩに対して変更が行われる時に、ＮｏｄｅおよびＮｏｄｅＣｏｍｐｏ
ｎｅｎｔに、新しいｃａｐａｂｉｌｉｔｙ ｂｉｔを必要とする可能性がある新
しい特徴を与えることができる。これを容易にすると同時にコンパクトな全体セ
ットの維持を試みるために（すなわち、ｃａｐａｂｉｌｉｔｙ ｂｉｔテストを
すばやく実行できるようにするために）、すべてのｃａｐａｂｉｌｉｔｙ ｂｉ
ｔ値を定義するクラスを含めることができる。このクラスは、クラス階層に基づ
く線形の順序でビット値を割り当てることができる。有利なことに、クラス階層
内のどのパスでも、線形の順序で進行するビット値を有することができる。さら
に、独立の階層が、同一のビット値を有することができ、これによって、ビット
値のコンパクトなセットがもたらされる。

【００５８】 Ｊａｖａ（Ｒ） ３Ｄでは、最も深いクラス階層が、ＣｏｎｅＳｏｕｎｄ階層
であり、最大のｃａｐａｂｉｌｉｔｙ ｂｉｔ値が３９である。いくつかの実施
形態では、６４ビット（すなわち「ｌｏｎｇ」変数型で使用可能なビット数）未
満の限界またはゴールを設定することができる。

【００５９】 分岐グラフのコンパイル Ｊａｖａ（Ｒ） ３Ｄ ＡＰＩでは、アプリケーションがＢｒａｎｃｈＧｒａ
ｐｈまたはＳｈａｒｅｄＧｒａｐｈをコンパイルすることができる（Ｂｒａｎｃ
ｈＧｒｏｕｐ．ｃｏｍｐｉｌｅ（）およびＳｈａｒｅｄＧｒｏｕｐ．ｃｏｍｐｉ
ｌｅ（）を介して）。コンパイル時に、実施形態が、サブグラフを分析し、サブ
グラフに対する最適化を実行することができる。実施形態は、アプリケーション
が最適化を案内するためにセットしたｃａｐａｂｉｌｉｔｙ ｂｉｔを使用する
ことができる。１つの可能な最適化の例が、シーン・グラフのフラット化である
。

【００６０】 図７に移ると、シーン・グラフをフラット化する方法の一実施形態が示されて
いる。この図には、２つの特徴が示されている。第１に、この例では、Ｔｒａｎ
ｓｆｏｒｍＧｒｏｕｐノード６６ＡからＢが、ｃａｐａｂｉｌｉｔｙ ｂｉｔを
セットされておらず、したがって、変更または照会することができない。その結
果、分岐グラフがコンパイルされた時に、ＴｒａｎｓｆｏｒｍＧｒｏｕｐＲｅｔ
ａｉｎｅｄノードが除去され、その合成値が、Ｓｈａｐｅ３ＤＲｅｔａｉｎｅｄ
ノード６４”にキャッシングされる。

【００６１】 第２に、保持されるクラスを囲むラッパー・クラスとしてＡＰＩクラスを構成
することの１つの可能な長所が示されている。ＴｒａｎｓｆｏｒｍＧｒｏｕｐノ
ードは、ｃａｐａｂｉｌｉｔｙ ｂｉｔをセットされておらず、この分岐がコン
パイルされているので、アプリケーションがＴｒａｎｓｆｏｒｍＧｒｏｕｐＲｅ
ｔａｉｎｅｄノードを変更または照会する方法がない。したがって、これらを除
去することができる。アプリケーションは、まだＴｒａｎｓｆｏｒｍＧｒｏｕｐ
ノードへの参照を有することができるが、ｃａｐａｂｉｌｉｔｙ ｂｉｔがセッ
トされていないので、これは問題ではない。

【００６２】 したがって、この図には、コンパイル最適化の１つの例が示されている。しか
し、一般に、コンパイル最適化は、Ｊａｖａ（Ｒ） ３Ｄ実装の残りでの最適化
と独立である。いくつかの実施形態では、Ｊａｖａ（Ｒ） ３Ｄランタイム・シ
ステムが、サブグラフを受け取るか処理する前に、最適化を実行することができ
る。他のコンパイル最適化には、小さいＳｈａｐｅ３Ｄノードのクラスタ化、大
きなＳｈａｐｅ３Ｄノードの分割、ジオメトリ・データのストリップ化、および
ジオメトリ・データの圧縮をも含めることができる。

【００６３】 ランタイム・システムの概要 Ｊａｖａ（Ｒ） ３Ｄ ＡＰＩは、マルチスレッド式の完全に非同期の実施形
態をサポートするように構成されている。このＡＰＩを用いると、実施形態が、
その作業構造体としてのシーン・グラフ、または性能向上のための代替データ構
造のいずれかを使用できるようになる。いくつかの実施形態では、シーン・グラ
フが、主作業構造体である。多数の特徴に関して、これは有用な作業構造体であ
る。しかし、可能な最適化を検討する時に、シーン・グラフが、実際には、処理
に制限がある構造体になる可能性がある。したがって、他の実施形態では、より
柔軟なアーキテクチャをサポートして、より高度な最適化をもたらすことができ
る。一実施形態では、より柔軟なアーキテクチャに、３つのコンポーネントすな
わち、構造体、スレッド、およびメッセージが含まれる。これらのコンポーネン
トのそれぞれを、下で詳細に説明する。

【００６４】 構造体 構造体は、他のオブジェクトの集合を管理するオブジェクトである。構造体は
、シーン・グラフの内容だけに依存する。構造体は、その構造体に対する要件の
組を与えられて、それに含まれるオブジェクトの最適化の責任を負う。構造体は
、シーン・グラフ構造体から独立であり、それ自体のオブジェクトだけに関して
責任を負う。すべての構造体の親クラスが、Ｊ３ｄＳｔｒｕｃｔｕｒｅである。
下に、このシステムの一実施形態でサポートすることができる異なるタイプの構
造体の説明をリストする。

【００６５】 ＧｅｏｍｅｔｒｙＳｔｒｕｃｔｕｒｅ ＧｅｏｍｅｔｒｙＳｔｒｕｃｔｕｒｅは、シーン・グラフ内のすべてのジオメ
トリ・データおよびバウンド・データを編成する責任を負う。ＶｉｒｔｕａｌＵ
ｎｉｖｅｒｓｅごとに１つのＧｅｏｍｅｔｒｙＳｔｒｕｃｔｕｒｅがある。

【００６６】 ＢｅｈａｖｉｏｒＳｔｒｕｃｔｕｒｅ ＢｅｈａｖｉｏｒＳｔｒｕｃｔｕｒｅは、すべてのＢｅｈａｖｉｏｒノードを
編成する責任を負う。挙動スケジューラのセマンティクスを実装する責任は負わ
ない。ＢｅｈａｖｉｏｒＳｔｒｕｃｔｕｒｅは、高速の実行カリングおよび処理
のために、ノードおよびそれらのウェイクアップ判断基準を編成するだけである
。ＶｉｒｔｕａｌＵｎｉｖｅｒｓｅごとに１つのＢｅｈａｖｉｏｒＳｔｒｕｃｔ
ｕｒｅがある。

【００６７】 ＳｏｕｎｄＳｔｒｕｃｔｕｒｅ ＳｏｕｎｄＳｔｒｕｃｔｕｒｅは、すべてのＳｏｕｎｄノードを編成する責任
を負う。サウンド・スケジューラのセマンティクスを実装する責任は負わない。
ＳｏｕｎｄＳｔｒｕｃｔｕｒｅは、高速のサウンド・レンダ・カリングのために
ノードを編成するだけである。ＶｉｒｔｕａｌＵｎｉｖｅｒｓｅごとに１つのＳ
ｏｕｎｄＳｔｒｕｃｔｕｒｅがある。

【００６８】 ＲｅｎｄｅｒｉｎｇＥｎｖｉｒｏｎｍｅｎｔＳｔｒｕｃｔｕｒｅ ＲｅｎｄｅｒｉｎｇＥｎｖｉｒｏｎｍｅｎｔＳｔｒｕｃｔｕｒｅは、レンダリ
ング環境に影響するオブジェクトを編成する責任を負う。これには、Ｌｉｇｈｔ
ノード、Ｆｏｇノード、Ｃｌｉｐノード、Ｂａｃｋｇｒｏｕｎｄノード、および
ＭｏｄｅｌＣｌｉｐノードが含まれる。ＲｅｎｄｅｒｉｎｇＥｎｖｉｒｏｎｍｅ
ｎｔＳｔｒｕｃｔｕｒｅは、それらのセマンティクスを実装しない。Ｒｅｎｄｅ
ｒｉｎｇＥｎｖｉｒｏｎｍｅｎｔＳｔｒｕｃｔｕｒｅは、シーンまたは特定のジ
オメトリに適用される環境特性を判定するための高速なメソッドを提供するだけ
である。ＶｉｒｔｕａｌＵｎｉｖｅｒｓｅ．．１．３．１．５ごとに１つのＲｅ
ｎｄｅｒｉｎｇＥｎｖｉｒｏｎｍｅｎｔＳｔｒｕｃｔｕｒｅがある。

【００６９】 ＲｅｎｄｅｒｉｎｇＡｔｔｒｉｂｕｔｅｓＳｔｒｕｃｔｕｒｅ ＲｅｎｄｅｒｉｎｇＡｔｔｒｉｂｕｔｅｓＳｔｒｕｃｔｕｒｅは、ＮｏｄｅＣ
ｏｍｐｏｎｅｎｔオブジェクトおよびそのミラー・オブジェクトのレンダリング
のすべてを管理する責任を負う。Ｊａｖａ（Ｒ） ３Ｄのすべてについて１つの
ＲｅｎｄｅｒｉｎｇＡｔｔｒｉｂｕｔｅｓＳｔｒｕｃｔｕｒｅがある。

【００７０】 ＲｅｎｄｅｒＢｉｎ ＲｅｎｄｅｒＢｉｎ構造体は、可視ジオメトリ・オブジェクトの集合を、レン
ダリングに最適に編成する責任を負う。Ｖｉｅｗごとに１つのＲｅｎｄｅｒＢｉ
ｎがある。

【００７１】 ＴｒａｎｓｆｏｒｍＳｔｒｕｃｔｕｒｅ ＴｒａｎｓｆｏｒｍＳｔｒｕｃｔｕｒｅは、システム内で使用されるすべての
変換およびバウンドを更新する責任を負う。

【００７２】 スレッド スレッドは、上で説明した構造体を使用するように構成される。１．２実装に
は、多数の異なるタイプのスレッドがある。この節では、システム内のすべての
スレッド・タイプを提示する。

【００７３】 ＭａｓｔｅｒＣｏｎｔｒｏｌ ＭａｓｔｅｒＣｏｎｔｒｏｌは、システムの制御スレッドである。Ｍａｓｔｅ
ｒＣｏｎｔｒｏｌは、システム内の他のすべてのスレッドのスケジューリングを
行う。ＭａｓｔｅｒＣｏｎｔｒｏｌは、タイム・スナップショットを取る責任も
負う。これは、Ｔｉｍｅの節で説明する。システム全体に１つのＭａｓｔｅｒＣ
ｏｎｔｒｏｌがある。

【００７４】 Ｊ３ｄＴｈｒｅａｄ Ｊ３ｄＴｈｒｅａｄは、システム内の他のすべてのスレッドの抽象親クラスで
ある。Ｊ３ｄＴｈｒｅａｄでは、スレッドの、初期化と、ＭａｓｔｅｒＣｏｎｔ
ｒｏｌによって通知されることと、クリーンアップとに関するすべての機能性が
実装される。ＭａｓｔｅｒＣｏｎｔｒｏｌを除く、システム内のすべてのスレッ
ドが、Ｊ３ｄＴｈｒｅａｄのサブクラスである。

【００７５】 ＳｔｒｕｃｔｕｒｅＵｐｄａｔｅＴｈｒｅａｄ すべての構造体が、ＳｔｒｕｃｔｕｒｅＵｐｄａｔｅＴｈｒｅａｄを有する。
メッセージが構造体に送られる時に、ＳｔｒｕｃｔｕｒｅＵｐｄａｔｅＴｈｒｅ
ａｄが、その構造体に関してこれらのメッセージを取り出すようにスケジューリ
ングされる。ＳｔｒｕｃｔｕｒｅＵｐｄａｔｅＴｈｒｅａｄは、その更新パスの
時間インターバルの間に含まれる、その構造体に関するメッセージだけを取り出
す。これは、下で詳細に説明する。

【００７６】 Ｒｅｎｄｅｒｅｒ これは、ジオメトリをレンダリングするスレッドである。これは、ＳｗａｐＢ
ｕｆｆｅｒｓコマンドも発行する。Ｓｃｒｅｅｎ３Ｄごとに１つのＲｅｎｄｅｒ
ｅｒがある。単一のスクリーン上に複数のＣａｎｖａｓ３Ｄがある時には、Ｒｅ
ｎｄｅｒｅｒスレッドが、Ｃａｎｖａｓ３Ｄごとに実行される。Ｒｅｎｄｅｒｅ
ｒは、ＲｅｎｄｅｒＢｉｎおよびＲｅｎｄｅｒｉｎｇＡｔｔｒｉｂｕｔｅｓＳｔ
ｒｕｃｔｕｒｅを使用する。

【００７７】 ＢｅｈａｖｉｏｒＳｃｈｅｄｕｌｅｒ このスレッドは、トリガされたアクティブな挙動のスケジューリングおよび処
理に関する責任を負う。このスレッドは、ＢｅｈａｖｉｏｒＳｔｒｕｃｔｕｒｅ
を使用する。現在、ＶｉｒｔｕａｌＵｎｉｖｅｒｓｅごとに１つのＢｅｈａｖｉ
ｏｒＳｃｈｅｄｕｌｅｒがある。

【００７８】 ＳｏｕｎｄＳｃｈｅｄｕｌｅｒ このスレッドは、サウンド・スケジューリングと、ＡｕｄｉｏＤｅｖｉｃｅ３
Ｄへのサウンド・レンダリング要求の送出に関する責任を負う。Ｖｉｅｗごとに
１つのＳｏｕｎｄＳｃｈｅｄｕｌｅｒがある。このスレッドは、ＳｏｕｎｄＳｔ
ｒｕｃｔｕｒｅを使用する。

【００７９】 ＩｎｐｕｔＤｅｖｉｃｅＳｃｈｅｄｕｌｅｒ このスレッドは、非ブロッキング入力デバイスのスケジューリングに関する責
任を負う。ＰｈｙｓｉｃａｌＥｎｖｉｒｏｎｍｅｎｔごとに１つのＩｎｐｕｔＤ
ｅｖｉｃｅＳｃｈｅｄｕｌｅｒがある。

【００８０】 メッセージ メッセージは、システム内で発生する変化を、システムを介して内部または外
部と通信するのに使用される。一実施形態では、「Ｊ３ｄＭｅｓｓａｇｅ」と呼
ばれる単一のメッセージ・クラスが実装される。各メッセージは、下記のフィー
ルドを有することができる。 ｔｉｍｅ−メッセージが送られた時刻。これは、時間を管理するＭａｓｔｅｒ
Ｃｏｎｔｒｏｌによって書き込まれる。 ｒｅｆｃｏｕｎｔ−このメッセージの参照カウント。１つのメッセージが、複
数のデスティネーションに行くことができる。すべてのデスティネーションがメ
ッセージを消費した時に、そのメッセージのｒｅｆｃｏｕｎｔが０になり、その
メッセージはｆｒｅｅｌｉｓｔに置かれる。 ｔｈｒｅａｄｓ−このメッセージを必要とするすべてのスレッド・タイプを表
すｂｉｔｍａｓｋ。 ｕｎｉｖｅｒｓｅ−このメッセージを発したｕｎｉｖｅｒｓｅ。 ｖｉｅｗ−このメッセージを受け取らなければならないＶｉｅｗ。ｎｕｌｌの
場合には、すべてのＶｉｅｗがこのメッセージを受け取る。 ｔｙｐｅ−このメッセージのタイプ。 ａｒｇｓ−５つのオブジェクト参照の配列。引数は、このフィールドを介して
デスティネーションに渡される。 ＭａｓｔｅｒＣｏｎｔｒｏｌがメッセージのｆｒｅｅｌｉｓｔを維持するので
、メッセージが必要な時に、ＧＣアクティビティが減少する。

【００８１】 Ｔｉｍｅ 本明細書で使用される時に、時間への言及は、Ｓｙｓｔｅｍ．ｃｕｒｒｅｎｔ
ＴｉｍｅＭｉｌｌｉｓ（）で測定された時間を指さない。その代わりに、時間は
、より正確には、変更カウントと呼ばれる。ＭａｓｔｅｒＣｏｎｔｒｏｌが、「
ｔｉｍｅ」と呼ばれるフィールドを有し、このフィールドは、０として開始され
、（ｉ）システム内でメッセージが送られるたびに、および（ｉｉ）Ｍａｓｔｅ
ｒＣｏｎｔｒｏｌがタイム・スナップショットをとる時に、増分される。この時
間の概念は、さまざまなスレッドが、すべてのスレッドにまたがって一貫性があ
るデータ・スナップショットに対してそれぞれのタスクを実行していることを保
証するのに使用される。これを、下でさらに詳細に説明する（節見出しＭａｓｔ
ｅｒＣｏｎｔｒｏｌを参照されたい）。

【００８２】 システム・スタートアップ Ｊａｖａ（Ｒ） ３Ｄのブートストラップには、処理のためにシステムを準備
するための、いくつかのシステム関連オペレーションの実行が含まれる。一実施
形態では、この処理が、Ｊａｖａ（Ｒ） ３Ｄシステムの呼出しごとに１回だけ
行われる。ブートストラップ・コードは、ＭａｓｔｅｒＣｏｎｔｒｏｌに含まれ
る。ＭａｓｔｅｒＣｏｎｔｒｏｌは、ＶｉｒｔｕａｌＵｎｉｖｅｒｓｅクラスの
ｓｔａｔｉｃメンバであり、これは、Ｊａｖａ（Ｒ） ３Ｄシステムに１つのＭ
ａｓｔｅｒＣｏｎｔｒｏｌだけが存在することを意味する。したがって、Ｍａｓ
ｔｅｒＣｏｎｔｒｏｌのコンストラクタが、ブートストラップ・コードの実行に
使用される。たとえば、使用されるネイティブ・グラフィックス・ライブラリの
タイプを照会し、ロードすることができる。

【００８３】 使用されるネイティブ・レンダリングＡＰＩを含むクラスを、ＮａｔｉｖｅＡ
ＰＩＩｎｆｏと呼ぶ。このクラスの異なる実装を、異なるターゲット・プラット
ホームごとにコンパイルすることができる。このクラスは、１つのメソッド、ｇ
ｅｔＲｅｎｄｅｒｉｎｇＡＰＩ（）を有し、その可能な値は、ＲＥＮＤＥＲ＿Ｏ
ＰＥＮＧＬ＿ＳＯＬＡＲＩＳ、ＲＥＮＤＥＲ＿ＯＰＥＮＧＬ＿ＷＩＮ３２、また
はＲＥＮＤＥＲ＿ＤＩＲＥＣＴ３Ｄである。しかし、どのレンダリング・ライブ
ラリを使用するかの選択は、システムにコンパイルすることができ、また、ブー
トストラップ処理を拡張することによってランタイムに選択可能にすることがで
きることに留意されたい。

【００８４】 任意の順序でＪａｖａ（Ｒ） ３Ｄオブジェクトを作成するようにアプリケー
ションを構成することができる。しかし、Ｊａｖａ（Ｒ） ３Ｄにそれ自体をブ
ートストラップさせる条件も存在する可能性がある。第１に、上で示したように
、ＶｉｒｔｕａｌＵｎｉｖｅｒｓｅが作成される場合に、ブートストラップが発
生する。Ｃａｎｖａｓ３Ｄなどの、ＶｉｒｔｕａｌＵｎｉｖｅｒｓｅが作成され
る前にネイティブ・ライブラリ・アクセスが必要になる他のケースがある。これ
らのケースでは、ｓｔａｔｉｃのイニシャライザ・メソッドをクラスに含めるこ
とができる。そのメソッドは、ｓｔａｔｉｃのＭａｓｔｅｒＣｏｎｔｒｏｌを作
成させるｓｔａｔｉｃメソッドＶｉｒｔｕａｌＵｎｉｖｅｒｓｅ．ｌｏａｄＬｉ
ｂｒａｒｉｅｓ（）を呼び出すように構成することができ、ブートストラップが
発生する。

【００８５】 Ｕｎｉｖｅｒｓｅ構造体 ＶｉｒｔｕａｌＵｎｉｖｅｒｓｅが作成される時に、複数の構造体が作成され
る。これには、ＧｅｏｍｅｔｒｙＳｔｒｕｃｔｕｒｅ、ＢｅｈａｖｉｏｒＳｔｒ
ｕｃｔｕｒｅ、ＳｏｕｎｄＳｔｒｕｃｔｕｒｅ、およびＲｅｎｄｅｒｉｎｇＥｎ
ｖｉｒｏｎｍｅｎｔＳｔｒｕｃｔｕｒｅが含まれる。これらは、Ｖｉｅｗ／Ｒｅ
ｎｄｅｒｉｎｇ独立なので、ここで作成される。これらは、ビューがまだアクテ
ィブでない可能性がある場合であっても、Ｎｏｄｅがシーン・グラフに追加され
る時に使用可能であることが必要である。ＲｅｎｄｅｒｉｎｇＡｔｔｒｉｂｕｔ
ｅｓＳｔｒｕｃｔｕｒｅは、Ｊａｖａ（Ｒ） ３Ｄのすべてについて１つだけが
あるので、ＭａｓｔｅｒＣｏｎｔｒｏｌが作成される時に作成される。

【００８６】 Ｃａｎｖａｓ３Ｄ作成 Ｃａｎｖａｓ３Ｄを作成するためには、アプリケーションが、まず、必要を満
たすＧｒａｐｈｉｃｓＣｏｎｆｉｇｕｒａｔｉｏｎを得なければならない。これ
には、ＧｒａｐｈｉｃｓＣｏｎｆｉｇＴｅｍｐｌａｔｅ３Ｄオブジェクトに書き
込み、そのオブジェクトを、レンダリングされるデバイスのｇｅｔＢｅｓｔＣｏ
ｎｆｉｇｕｒａｔｉｏｎ（）メソッドに渡すことが含まれる。現在の実装では、
デフォルト・スクリーン・デバイスだけがサポートされる。ＧｒａｐｈｉｃｓＤ
ｅｖｉｃｅ．ｇｅｔＢｅｓｔＣｏｎｆｉｇｕｒａｔｉｏｎ（）は、単純にＧｒａ
ｐｈｉｃｓＣｏｎｆｉｇＴｅｍｐｌａｔｅ３Ｄ．ｇｅｔＢｅｓｔＣｏｎｆｉｇｕ
ｒａｔｉｏｎ（）メソッドを呼び出して、引数としてすべての使用可能な構成を
渡す。そのテンプレートに最良のＧｒａｐｈｉｃｓＣｏｎｆｉｇｕｒａｔｉｏｎ
を選択し、返すのは、ＧｒａｐｈｉｃｓＣｏｎｆｉｇＴｅｍｐｌａｔｅ３Ｄの責
任である。ＧｒａｐｈｉｃｓＣｏｎｆｉｇＴｅｍｐｌａｔｅ３Ｄは、Ｊａｖａ（
Ｒ） ３Ｄクラスであり、したがって、選択処理に対する制御を有する。Ｇｒａ
ｐｈｉｃｓＣｏｎｆｉｇＴｅｍｐｌａｔｅ３Ｄには、コンパイル時にＪａｖａ（
Ｒ） ３Ｄに組み込まれ、プラットホーム／レンダリングＡＰＩ固有の選択セマ
ンティクスを実装する、ＮａｔｉｖｅＣｏｎｆｉｇＴｅｍｐｌａｔｅ３Ｄという
クラスがある。Ｓｏｌａｒｉｓの場合、ＯｐｅｎＧＬが唯一のレンダリングＡＰ
Ｉであるが、渡されるＧｒａｐｈｉｃｓＣｏｎｆｉｇｕｒａｔｉｏｎｓのリスト
が無視され、選択は、ｇｌＸＣｈｏｏｓｅＶｉｓｕａｌ（）を行うことによって
ネイティブ・コードで実行される。ビジュアルが選択された後に、そのＩＤが返
され、渡されたＧｒａｐｈｉｃｓＣｏｎｆｉｇｕｒａｔｉｏｎｓと突き合わされ
る。一致するＧｒａｐｈｉｃｓＣｏｎｆｉｇｕｒａｔｉｏｎが返される。ｗｉｎ
３２では、ＯｐｅｎＧＬとＤｉｒｅｃｔ３Ｄの両方について、選択処理では何も
行われない。ｗｉｎ３２ウィンドウのＰｉｘｅｌＦｏｒｍａｔは、いつでも変更
することができるので、Ｊａｖａ（Ｒ） ３Ｄは、システムが最初のレンダリン
グＧｒａｐｈｉｃｓＣｏｎｔｅｘｔを必要とする時に、単純にウィンドウのＰｉ
ｘｅｌＦｏｒｍａｔを変更する。これについては、Ｒｅｎｄｅｒｅｒを説明する
時にさらに説明する。

【００８７】 この最後に、Ｃａｎｖａｓ３Ｄに、現在のレンダリングＡＰＩを用いてレンダ
リングすることができる。しかし、システムは、Ｃａｎｖａｓ３Ｄがレンダリン
グされる準備ができるか、アクティブ化されるまで、スタート・アップしない。
この処理を、下で説明する。

【００８８】 Ｖｉｅｗアクティブ化 ランタイム・システムは、２ステップで起動される。第１ステップは、Ｃａｎ
ｖａｓ３ＤオブジェクトがＡＷＴ（抽象ウィンドウ・ツールキット）コンテナに
追加されることによって（すなわち、Ｃａｎｖａｓ３Ｄ．ａｄｄＮｏｔｉｆｙ（
）が呼び出される時に）トリガされる。それに応答して、キャンバスが、Ｖｉｅ
ｗ．ａｄｄＮｏｔｉｆｙ（）を呼び出すことによって、それが追加されたことを
そのＶｉｅｗに通知する。この時点で、Ｖｉｅｗが、それ自体および呼出し元の
キャンバスをＭａｓｔｅｒＣｏｎｔｒｏｌに登録する。次に、ＶｉｅｗのＲｅｎ
ｄｅｒＢｉｎおよびＳｏｕｎｄＳｃｈｅｄｕｌｅｒが、作成され、初期化される
。これがＭａｓｔｅｒＣｏｎｔｒｏｌに登録される最初のビューである場合には
、ＢｅｈａｖｉｏｒＳｃｈｅｄｕｌｅｒも作成され、初期化される。これがその
スクリーンについて最初に登録されるキャンバスである場合には、そのスクリー
ンのＲｅｎｄｅｒｅｒも、作成され、初期化される。

【００８９】 この時点で、すべてのスレッドおよび構造体が、作成され、初期化されている
。しかし、Ｖｉｅｗは、まだアクティブではない（すなわち、その構造体が、メ
ッセージを受け取らず、そのスレッドが、ＭａｓｔｅｒＣｏｎｔｒｏｌによって
スケジューリングされない）。これは、ビューに関連するＣａｎｖａｓ３Ｄがア
クティブ化されるまで行われない。一実施形態では、Ｃａｎｖａｓ３Ｄをアクテ
ィブ化できる前に、３つの条件を満足しなければならない。第１に、ペイント・
イベントが、Ｃａｎｖａｓ３Ｄで受け取られていなければならない。これは、Ａ
ＷＴがＣａｎｖａｓ３Ｄ用の基礎となるウィンドウ・システム・リソースを割り
振る方法に基づく要件である（これは、下のＲｅｎｄｅｒｅｒの節で詳細に説明
する）。第２に、Ｃａｎｖａｓ３Ｄが実行状態になっていなければならない。こ
れは、Ｃａｎｖａｓ３Ｄ．ｓｔａｒｔ／ｓｔｏｐＲｅｎｄｅｒｅｒ（）メソッド
によって直接に制御される。最後の第３の条件は、Ｃａｎｖａｓ３Ｄがスクリー
ン上で可視でなければならないことである。これは、Ｃａｎｖａｓ３Ｄ上のさま
ざまなイベントを追跡することによって監視される。Ｃａｎｖａｓ３Ｄ上のイベ
ントを追跡するために、内部クラス（ＥｖｅｎｔＣａｔｃｈｅｒ）で、Ｃａｎｖ
ａｓ３ＤまたはＢｅｈａｖｉｏｒＳｃｈｅｄｕｌｅｒが追跡するイベントの適当
なリスナ・インターフェースのすべてを実装する。ＥｖｅｎｔＣａｔｃｈｅｒは
、イベントを受け取り、それをＢｅｈａｖｉｏｒＳｃｈｅｄｕｌｅｒに渡す。Ｅ
ｖｅｎｔＣａｔｃｈｅｒは、その状態が変化したことをＣａｎｖａｓ３Ｄにも通
知する。３つの条件のいずれかの状態が変化した場合に、Ｃａｎｖａｓ３Ｄ．ｅ
ｖａｌｕａｔｅＡｃｔｉｖｅ（）を呼び出して、Ｃａｎｖａｓ３Ｄの状態を再評
価する。Ｃａｎｖａｓ３Ｄのアクティブ状態が変化した場合には、Ｖｉｅｗ．ｅ
ｖａｌｕａｔｅＡｃｔｉｖｅ（）を介して、それが関連するＶｉｅｗに、その状
態を評価するように通知する。一実施形態では、アクティブ化される前に満たさ
れる２つの条件がある。第１に、Ｖｉｅｗが、ライブのＶｉｅｗＰｌａｔｆｏｒ
ｍに接続されていなければならない。第２に、ＶｉｅｗのＣａｎｖａｓ３Ｄの１
つがアクティブでなければならない。Ｖｉｅｗの状態が変化する場合には、Ｖｉ
ｅｗが、それ自体をアクティブ化または非アクティブ化する。

【００９０】 Ｖｉｅｗアクティブ化には、複数のステップが含まれる。第１に、新しいＶｉ
ｅｗがアクティブ化されたというメッセージが、システム内のスレッドにブロー
ドキャストされる。これは、新しいＶｉｅｗが、関係を持つすべての構造体に登
録されることを保証するために行われる。また、このメッセージによって、最初
の可視性オペレーションおよびレンダ・オペレーションがこのＶｉｅｗに対して
行われる。次に、Ｖｉｅｗが、ＩＤ番号を持っていない場合には、それを取得す
る。このＩＤの使用は、下で説明する。ＩＤ番号を受け取った後に、Ｖｉｅｗが
、そのＶｉｒｔｕａｌＵｎｉｖｅｒｓｅがプライマリ・ビューを有するかどうか
を調べる。そうでない場合には、ＭａｓｔｅｒＣｏｎｔｒｏｌに新しいプライマ
リ・ビューを選択させる。その後、Ｖｉｅｗが、そのＶｉｒｔｕａｌＵｎｉｖｅ
ｒｓｅに、このＶｉｅｗに関連するすべてのＣａｎｖａｓ３Ｄ上の現在イネーブ
ルされているイベントのすべて（ＢｅｈａｖｉｏｒＳｃｈｅｄｕｌｅｒによって
選択される）をイネーブルさせる。

【００９１】 注−アクティブ化追跡が常に行われることを保証するために、Ｃｏｍｐｏｎｅ
ｎｔＥｖｅｎｔｓが、Ｃａｎｖａｓ３Ｄについて必ずイネーブルされる。最後に
、Ｖｉｅｗが、ＭａｓｔｅｒＣｏｎｔｒｏｌにそれをアクティブ化させる。この
時点で、ＭａｓｔｅｒＣｏｎｔｒｏｌは、ＶｉｅｗのＲｅｎｄｅｒＢｉｎおよび
ＳｏｕｎｄＳｃｈｅｄｕｌｅｒをアクティブとしてマークする。これが唯一のア
クティブＶｉｅｗである場合には、ＭａｓｔｅｒＣｏｎｔｒｏｌが、Ｂｅｈａｖ
ｉｏｒＳｃｈｅｄｕｌｅｒもアクティブ化する。この時点で、システムが、通常
の動作状態になる。

【００９２】 システム・フロー この実施形態は、メッセージ・パッシングに基づくので、発生するセット・シ
ステム・フローはない。しかし、コンポーネントがどのようにインターオぺレー
トするかを説明するために、例のアプリケーション・シナリオを例として使用す
ることができる。この例では、アプリケーションが、回転する単独の立方体であ
るＨｅｌｌｏＵｎｉｖｅｒｓｅである。Ｊａｖａ（Ｒ）３Ｄの観点から、このア
プリケーションは、１つのＳｈａｐｅ３Ｄノードとその上で変化するＴｒａｎｓ
ｆｏｒｍＧｒｏｕｐからなる。ＴｒａｎｓｆｏｒｍＧｒｏｕｐは、フレームごと
に１回トリガされるＢｅｈａｖｉｏｒから変更されている。これが内部的にどの
ように見えるかを知るために、まずＭａｓｔｅｒＣｏｎｔｒｏｌを調べる。

【００９３】 図８に移ると、例のＨｅｌｌｏＵｎｉｖｅｒｓｅアプリケーションについてＭ
ａｓｔｅｒＣｏｎｔｒｏｌによって管理されるスレッドの一実施形態が示されて
いる。図に示されたスレッドの数は、このような単純なアプリケーションに対し
て多く見えるかもしれないが、箱の中に「Ｘ」があるスレッドだけが、反復のそ
れぞれで実行される。また、構造体および更新スレッドのそれぞれが、シーン・
グラフに含まれるものに基づいて条件的に作成されることに留意されたい。まず
、反復を開始するために、ＭａｓｔｅｒＣｏｎｔｒｏｌが、タイム・スナップシ
ョットをとる。言い換えると、この時点で、ＭａｓｔｅｒＣｏｎｔｒｏｌが、ど
のスレッドをこの特定の反復で実行する必要があるかを決定する。この決定は、
どのメッセージが各スレッドに送られたかに基づく。図に示された例では、２つ
の更新スレッドが実行される。ＴｒａｎｓｆｏｒｍＧｒｏｕｐが、フレームごと
に変更されるので、ＧｅｏｍｅｔｒｙＳｔｒｕｃｔｕｒｅおよびＲｅｎｄｅｒＢ
ｉｎが、Ｓｈａｐｅ３Ｄノードの位置を追跡する必要がある。したがって、これ
らの更新スレッドが、反復ごとにスケジューリングされる。この場合、両方の更
新スレッドによって、Ｓｈａｐｅ３ＤノードのＴｒａｎｓｆｏｒｍ３Ｄ値が更新
される。ＧｅｏｍｅｔｒｙＳｔｒｕｃｔｕｒｅおよびＲｅｎｄｅｒＢｉｎは、２
つの異なる参照時間に作業するので、これらがキャッシングする値は異なる。こ
れは、ＣａｃｈｅｄＴｒａｎｓｆｏｒｍと呼ばれる新しいオブジェクトを用いて
達成される。このオブジェクトは、下でＴｒａｎｓｆｏｒｍＧｒｏｕｐノードに
関して詳細に説明する。ＭａｓｔｅｒＣｏｎｔｒｏｌは、この反復について進行
する前に、すべての更新スレッドが終了するのを待つ。これによって、残りのス
レッドが、状態更新を追跡する必要なしに有効なデータを操作することが保証さ
れる。

【００９４】 この図には、実際に２つのスレッド・リストが示されている。最初のリストに
は、更新スレッドおよび「作業」スレッドが含まれ、第２のリストには、レンダ
・スレッドが含まれる。ＭａｓｔｅｒＣｏｎｔｒｏｌは、２つのリストを保ち、
その結果、レンダ・スレッドにより高い優先順位を与えて、これらを並列に処理
できるようになる。レンダ・スレッドは、必ずＲｅｎｄｅｒＢｉｎ構造体から作
業するので、ＲｅｎｄｅｒＢｉｎがメッセージを処理する間に行えることに対す
るいくつかの制約がある可能性がある。これは、下のＲｅｎｄｅｒＢｉｎの節で
詳細に説明する。ＨｅｌｌｏＵｎｉｖｅｒｓｅの例では、第１のＲｅｎｄｅｒス
レッドが最初にスケジューリングされる。このスレッドが、ＲｅｎｄｅｒＢｉｎ
をレンダリングする。それと同時に、各更新スレッドが実行を許可される。この
例では、これに、ＴｒａｎｓｆｏｒｍＳｔｒｕｃｔｕｒｅおよびＧｅｏｍｅｔｒ
ｙＳｔｒｕｃｔｕｒｅが含まれる。

【００９５】 次に、ＢｅｈａｖｉｏｒＳｃｈｅｄｕｌｅｒが実行を許可され、最後に、Ｒｅ
ｎｄｅｒＢｉｎ更新が実行を許可される。この時間の間に、Ｒｅｎｄｅｒスレッ
ドが終了した場合に、レンダＳｗａｐスレッドが実行を許可される。これによっ
て、ＨｅｌｌｏＵｎｉｖｅｒｓｅの反復が完了する。

【００９６】 次に、この例で各スレッドが行うことについて簡単に説明する。Ｔｒａｎｓｆ
ｏｒｍＧｒｏｕｐがフレームごとに変化するので、ＴｒａｎｓｆｏｒｍＳｔｒｕ
ｃｔｕｒｅが、システム内のジオメトリ・オブジェクトの仮想世界座標でのｌｏ
ｃａｌＴｏＶｗｏｒｌｄの値およびバウンドを更新する必要がある。Ｔｒａｎｓ
ｆｏｒｍＳｔｒｕｃｔｕｒｅ更新が完了した後になるまで、Ｔｒａｎｓｆｏｒｍ
Ｓｔｒｕｃｔｕｒｅの後のどの更新スレッドもスケジューリングすることができ
ない。これは、ほとんどの構造体が、その更新された値に頼るからである。

【００９７】 次に更新される構造体は、ＧｅｏｍｅｔｒｙＳｔｒｕｃｔｕｒｅである。この
構造体は、シーン内のすべてのジオメトリ・データの空間データ構造を維持する
。あるオブジェクトが移動する場合に、そのオブジェクトの新しい位置を反映す
るようにこのデータ構造が更新される。

【００９８】 ＢｅｈａｖｉｏｒＳｃｈｅｄｕｌｅｒおよびＲｅｎｄｅｒＢｉｎの更新は、同
時に実行することができる。ＢｅｈａｖｉｏｒＳｃｈｅｄｕｌｅｒは、最後のサ
イクル以降にトリガされた挙動を実行する。この場合では、立方体を回転させて
いるのはＲｏｔａｔｉｏｎＩｎｔｅｒｐｏｌａｔｏｒである。

【００９９】 ＲｅｎｄｅｒＢｉｎについては、立方体が移動したので、ＲｅｎｄｅｒＢｉｎ
が、同一のライトおよびフォグがこのジオメトリに適用されるかどうかを検査す
る。同一のライトおよびフォグが適用される場合には、この場合にはこれで終了
である。ＲｅｎｄｅｒＢｉｎ更新スレッドは、実際にＲｅｎｄｅｒＢｉｎを変更
しない可能性がある。これは、ＲｅｎｄｅｒＢｉｎ更新スレッドと同時に１つま
たは複数のＲｅｎｄｅｒｅｒがＲｅｎｄｅｒＢｉｎを実行しているからである。
変更が必要な場合には、それを単純に記録し、ＯｂｊｅｃｔＵｐｄａｔｅの時（
下で詳細に説明する）まで延期する。

【０１００】 これと並列に、Ｒｅｎｄｅｒｅｒスレッドも動作中である可能性がある。最初
のＲｅｎｄｅｒｅｒスレッド呼出しは、すべての可視オブジェクトをＣａｎｖａ
ｓ３Ｄにレンダリングする責任を負う。それが完了した後に、第２のＲｅｎｄｅ
ｒｅｒスレッド呼出しが、バッファ・スワップを実行する。バッファ・スワップ
が完了した後に、フレームが経過したことをＢｅｈａｖｉｏｒＳｃｈｅｄｕｌｅ
ｒに通知するようにＭａｓｔｅｒＣｏｎｔｒｏｌを構成することができる。その
通知によって、もう一度挙動にトリガがかけられ、処理が継続する。

【０１０１】 システム・エグジット Ｊａｖａ（Ｒ）メモリ・モデルの潜在的な長所の１つが、システム・エグジッ
トおよびクリーンアップが比較的単純であることである。アプリケーションが、
そのＪａｖａ（Ｒ） ３Ｄオブジェクトへの参照のすべてを除去し、すべてのＪ
ａｖａ（Ｒ） ３Ｄスレッドがエグジットする場合に、Ｊａｖａ（Ｒ）ガーベッ
ジ・コレクタが、Ｊａｖａ（Ｒ） ３Ｄが割り当てたＪａｖａ（Ｒ）リソースのすべてを再利用する。残念ながら
、いくつかの実施形態では、アプリケーションがＪａｖａ（Ｒ） ３Ｄについて
終了した時をＪａｖａ（Ｒ） ３Ｄに通知するためのサポートがない。したがっ
て、代替の機構を使用して、Ｊａｖａ（Ｒ） ３Ｄスレッドが不要になった時に
、それがエグジットすることを保証することができる。

【０１０２】 一実施形態では、この機構を、既存のａｄｄＮｏｔｉｆｙ／ｒｅｍｏｖｅＮｏ
ｔｉｆｙ方式で実施することができる。たとえば、Ｃａｎｖａｓ３Ｄがそのコン
テナから除去される時に、Ｃａｎｖａｓ３ＤがそのＶｉｅｗｓに通知するように
構成することができる。Ｖｉｅｗが除去される時に、Ｖｉｅｗが、Ｍａｓｔｅｒ
Ｃｏｎｔｒｏｌ．ｕｎｒｅｇｉｓｔｅｒＶｉｅｗ（）を介してＭａｓｔｅｒＣｏ
ｎｔｒｏｌに通知する。ＭａｓｔｅｒＣｏｎｔｒｏｌは、そのＶｉｅｗに関連す
るすべてのスレッドを停止する。それが最後の登録されたＶｉｅｗである場合に
は、ＭａｓｔｅｒＣｏｎｔｒｏｌは、ＶｉｒｔｕａｌＵｎｉｖｅｒｓｅベースの
スレッドを停止し、最後に、それ自体を停止する。これによって、アクティブな
Ｊａｖａ（Ｒ） ３Ｄスレッドのすべてが除去されるので、ユーザがもはやＪａ
ｖａ（Ｒ） ３Ｄ参照を有しない時に、それらがＪＶＭ（Ｊａｖａ（Ｒ）仮想マ
シン）によって完全に再利用される。これによって、Ｊａｖａ（Ｒ） ３Ｄラン
タイム・システムの概要を完了する。下では、本明細書に記載のシステムおよび
方法を実施するのに使用することができる個々のコンポーネント、そのアーキテ
クチャ、およびそれらが使用するアルゴリズムを詳細に説明する。

【０１０３】 ＭａｓｔｅｒＣｏｎｔｒｏｌ ＭａｓｔｅｒＣｏｎｔｒｏｌは、Ｊａｖａ（Ｒ） ３Ｄのグローバル制御オブ
ジェクトである。これは、ＶｉｒｔｕａｌＵｎｉｖｅｒｓｅクラスのｓｔａｔｉ
ｃオブジェクトであり、したがって、システム内に１つだけ存在する。その主な
機能は、他のすべてのスレッドの、ユーザ・ベースのスケジューリングを実行す
ることである。ＭａｓｔｅｒＣｏｎｔｒｏｌは、少数のＡＰＩ機能も実装するこ
とができる。

【０１０４】 スレッドの作成および消滅 一実施形態では、システム内のすべてのスケジューリング可能なスレッドが、
Ｊ３ｄＴｈｒｅａｄのサブクラスである。このクラスでは、スレッドの初期化コ
ード、通信コード、および消滅コードのすべてが実装される。これによって、Ｍ
ａｓｔｅｒＣｏｎｔｒｏｌに、スレッドの作成、スケジューリング、および破棄
のための共通インターフェースが与えられる。

【０１０５】 システム内には、２タイプのスレッド関連付けすなわち、ＶｉｒｔｕａｌＵｎ
ｉｖｅｒｓｅに関連するスレッドとＶｉｅｗに関連するスレッドがある。それぞ
れを順番に説明する。ＶｉｒｔｕａｌＵｎｉｖｅｒｓｅスレッドに関して、Ｖｉ
ｒｔｕａｌＵｎｉｖｅｒｓｅが作成される時に、ＶｉｒｔｕａｌＵｎｉｖｅｒｓ
ｅ用の構造体が作成される。ＶｉｒｔｕａｌＵｎｉｖｅｒｓｅに関連するスレッ
ドは、そのＶｉｒｔｕａｌＵｎｉｖｅｒｓｅに登録されたビューがある時に限っ
て初期化される必要がある。したがって、それが、これらのスレッドの初期化に
トリガをかけるイベントになる。ＶｉｒｔｕａｌＵｎｉｖｅｒｓｅの最初のビュ
ーが登録される時に、ＭａｓｔｅｒＣｏｎｔｒｏｌが、ＶｉｒｔｕａｌＵｎｉｖ
ｅｒｓｅのスレッドを初期化する。作成され初期化される構造体は、Ｇｅｏｍｅ
ｔｒｙＳｔｒｕｃｔｕｒｅ、ＢｅｈａｖｉｏｒＳｔｒｕｃｔｕｒｅ、Ｓｏｕｎｄ
Ｓｔｒｕｃｔｕｒｅ、およびＲｅｎｄｅｒｉｎｇＥｎｖｉｒｏｎｍｅｎｔＳｔｒ
ｕｃｔｕｒｅである。やはり、ＲｅｎｄｅｒｉｎｇＡｔｔｒｉｂｕｔｅｓＳｔｒ
ｕｃｔｕｒｅは、１つのグローバル構造体としてＭａｓｔｅｒＣｏｎｔｒｏｌに
よって作成される。これらの構造体のそれぞれが、ＭａｓｔｅｒＣｏｎｔｒｏｌ
に登録される更新スレッドを有する。これらの構造体と共に、ＭａｓｔｅｒＣｏ
ｎｔｒｏｌは、ＶｉｒｔｕａｌＵｎｉｖｅｒｓｅのＢｅｈａｖｉｏｒＳｃｈｅｄ
ｕｌｅｒも作成し、初期化する。最後に、ＭａｓｔｅｒＣｏｎｔｒｏｌＴｈｒｅ
ａｄがない場合には、これによって、ＭａｓｔｅｒＣｏｎｔｒｏｌＴｈｒｅａｄ
が作成され、初期化される。

【０１０６】 Ｖｉｅｗベースのスレッドの場合、トリガをかけるイベントは、Ｖｉｅｗの登
録である。Ｖｉｅｗが登録される時に、そのＶｉｅｗのスレッドが、作成され、
初期化される。このスレッドには、ＳｏｕｎｄＳｃｈｅｄｕｌｅｒと、Ｒｅｎｄ
ｅｒＢｉｎの更新スレッドが含まれる。このＶｉｅｗのＰｈｙｓｉｃａｌＥｎｖ
ｉｒｏｎｍｅｎｔのＩｎｐｕｔＤｅｖｉｃｅＳｃｈｅｄｕｌｅｒも、作成され、
初期化される（必要な場合に）。また、Ｖｉｅｗの各Ｃａｎｖａｓ３Ｄに関連す
る一意のＳｃｒｅｅｎ３Ｄのそれぞれが、そのＲｅｎｄｅｒｅｒスレッドを初期
化される。スレッドは、作成され初期化されるが、まだアクティブではない。こ
れは、Ｖｉｅｗがアクティブになった後に発生する。あるＶｉｅｗがアクティブ
になる時に、それに関連するすべてのスレッドが、アクティブ化される。Ｍａｓ
ｔｅｒＣｏｎｔｒｏｌがスケジューリングについてそれらのスレッドを検討する
のは、この時点である。Ｖｉｅｗが非アクティブ化される時に、スレッドが、単
に非アクティブとしてマークされる。スレッドは、この時点では破棄されない。
これによって、Ｖｉｅｗのスレッドを、破棄せずに停止することが可能になる。

【０１０７】 Ｖｉｅｗベースのスレッドのスレッド消滅は、Ｖｉｅｗの登録解除によってト
リガされる。ＭａｓｔｅｒＣｏｎｔｒｏｌは、Ｖｉｅｗ登録と完全に非同期なの
で、なんらかの記録が必要である。Ｖｉｅｗが登録解除される時に、Ｍａｓｔｅ
ｒＣｏｎｔｒｏｌは、スレッドを破棄する前に、安全な時点まで待つ。スレッド
を即座に破棄するのではなく、ＭａｓｔｅｒＣｏｎｔｒｏｌは、スレッドをゾン
ビ・スレッド・リストに置くだけである。その後、ＭａｓｔｅｒＣｏｎｔｒｏｌ
Ｔｈｒｅａｄが、スレッド・リストの変化を調べる時に、Ｊ３ｄＴｈｒｅａｄ．
ｆｉｎｉｓｈ（）を呼び出すことによってゾンビ・スレッドを破棄する。Ｖｉｅ
ｗは、ＭａｓｔｅｒＣｏｎｔｒｏｌＴｈｒｅａｄがゾンビ・リストをクリーンす
る前にそれ自体を登録解除し、登録する可能性があるので、すべてのスレッド作
成コードに、まず、作成されるスレッドがゾンビ・リストにあるかどうかを検査
させることが望ましい。ＶｉｒｔｕａｌＵｎｉｖｅｒｓｅスレッドの消滅は、Ｖ
ｉｒｔｕａｌＵｎｉｖｅｒｓｅの最後のＶｉｅｗの除去によってトリガされる。
これも、非同期イベントであり、したがって、スレッドは、やはりゾンビ・リス
トに置かれて、安全な時にＭａｓｔｅｒＣｏｎｔｒｏｌによって取り除かれる。

【０１０８】 ＭａｓｔｅｒＣｏｎｔｒｏｌＴｈｒｅａｄ ＭａｓｔｅｒＣｏｎｔｒｏｌオブジェクトは、２つの部分に分割されて、それ
らがもはや不要になった時にＪａｖａ（Ｒ） ３Ｄが関連するリソースを解放で
きるようになっている。すべてのデータがＭａｓｔｅｒＣｏｎｔｒｏｌオブジェ
クト自体の中に保持されるが、制御するスレッドは、ＭａｓｔｅｒＣｏｎｔｒｏ
ｌＴｈｒｅａｄ（ＭＣＴ）にカプセル化されている。これによって、システムが
、システム状態を維持しながら、制御するスレッドをすばやく作成でき、破棄で
きるようになる。ＭａｓｔｅｒＣｏｎｔｒｏｌＴｈｒｅａｄのフローを使用して
、ＭａｓｔｅｒＣｏｎｔｒｏｌの大部分を説明することができる。第１に、ＭＣ
Ｔは、実行すべきタスク（すなわち作業）があるかどうかを調べる。Ｂｏｏｌｅ
ａｎ変数ｗｏｒｋＴｏＤｏを使用して、保留中の作業があることをＭＣＴに知ら
せる。実行すべきタスクがない場合には、ＭａｓｔｅｒＣｏｎｔｒｏｌＴｈｒｅ
ａｄは、タスクが到着するまで待ち状態に入る。作業を引き起こすアクションに
よって、ＭＣＴが通知を受ける。これによって、Ｊａｖａ（Ｒ） ３Ｄが、実行
すべき保留中のタスクがない時にＣＰＵリソースを消費しないようにすることが
できる。

【０１０９】 ｗｏｒｋＴｈｒｅａｄｓリスト 次に、ＭＣＴは、新しいスレッドがシステムに追加されたかどうかを調べる。
これは、ｕｐｄａｔｅＴｈｒｅａｄＬｉｓｔｓ（）で行われる。スレッドが、シ
ステムに追加されたか除去された時に、ＭＣＴが、スケジューリング可能なスレ
ッドのリストを更新する。スレッド変更が必要な時には、Ｂｏｏｌｅａｎ変数ｔ
ｈｒｅａｄＬｉｓｔｓＣｈａｎｇｅｄがセットされる。そうである場合には、ｕ
ｐｄａｔｅＴｈｒｅａｄＬｉｓｔｓ（）が、スレッドのｗｏｒｋＴｈｒｅａｄｓ
配列を再計算し、ゾンビ・スレッドをクリーン・アップする。次に、ｕｐｄａｔ
ｅＷｏｒｋＴｈｒｅａｄｓ（）が、スレッド・スケジューリングの決定を行う。
この処理の一部として、ｕｐｄａｔｅＷｏｒｋＴｈｒｅａｄｓ（）は、まず、ｗ
ｏｒｋＴｈｒｅａｄｓ配列に何個の項目が必要であるかを計算する。一実施形態
では、ｗｏｒｋＴｈｒｅａｄｓ配列が、２次元である。上で注記したように、更
新／作業スレッドの配列と、レンダ・スレッドの配列がある。それぞれの項目の
数は、下記のように計算される。 更新／作業リストの場合、スレッド項目の数は、 ・更新スレッドの数と、 ・ＶｉｒｔｕａｌＵｎｉｖｅｒｓｅ（それぞれについて１つのＢｅｈａｖｉｏ
ｒＳｃｈｅｄｕｌｅｒ）の数と、 ・Ｖｉｅｗごとに、 ｉ．１つのＳｏｕｎｄＳｃｈｅｄｕｌｅｒと、 ｉｉ．一意のＰｈｙｓｉｃａｌＥｎｖｉｒｏｎｍｅｎｔ（ＩｎｐｕｔＤｅｖｉ
ｃｅＳｃｈｅｄｕｌｅｒ）の数と の合計である。これによって、更新／作業配列の全長が与えられる。 レンダ・リストの場合、スレッド項目の数は、 ・１つのレンダ要求スレッドと（ＯｆｆｓｃｒｅｅｎモードおよびＩｍｍｅｄ
ｉａｔｅモードについて） ・Ｖｉｅｗごとに、 ｉ．Ｃａｎｖａｓ３Ｄの数（Ｃａｎｖａｓ３Ｄごとに１Ｒｅｎｄｅｒｅｒ）と
、 ｉｉ．Ｓｃｒｅｅｎ３Ｄの数（Ｓｃｒｅｅｎ３Ｄごとに１Ｓｗａｐ）と の合計である。

【０１１０】 ｗｏｒｋＴｈｒｅａｄｓ配列は、Ｊ３ｄＴｈｒｅａｄＤａｔａオブジェクトの
配列である。Ｊ３ｄＴｈｒｅａｄＤａｔａオブジェクトによって、単一の呼出し
についてスレッドを実行するのに必要なすべての情報がカプセル化される。Ｊ３
ｄＴｈｒｅａｄＤａｔａが保存するデータには、下記が含まれる。 ・スレッド参照であるＪ３ｄＴｈｒｅａｄ ・４つの時間値のセット（Ｔｉｍｅの節で説明した） ・このスレッド呼出しのオプションのｂｉｔｍａｓｋ ・スレッドに渡される引数 ・このスレッドがこのパスで実行されることを必要とするか否か ・Ｒｅｎｄｅｒｅｒスレッドによって使用される引数

【０１１１】 Ｊ３ｄＴｈｒｅａｄＤａｔａオブジェクトは、スレッドが、ｗｏｒｋＴｈｒｅ
ａｄｓのリスト内に複数存在できるようにするために使用される。これの一例が
、Ｒｅｎｄｅｒｅｒスレッドであり、これは、単一のＭＣＴパスについて複数回
実行される可能性がある。各スレッドは、そのＪ３ｄＴｈｒｅａｄＤａｔａオブ
ジェクトのリストを管理する責任を負う。いくつかの実施形態では、Ｒｅｎｄｅ
ｒｅｒスレッドだけが、複数のＪ３ｄＴｈｒｅａｄＤａｔａオブジェクトを有す
る。Ｒｅｎｄｅｒｅｒスレッドは、ＲｅｎｄｅｒｉｎｇについてＶｉｅｗ／Ｃａ
ｎｖａｓ３Ｄ対ごとに１つのＪ３ｄＴｈｒｅａｄＤａｔａオブジェクトと、Ｓｗ
ａｐｐｉｎｇについてＶｉｅｗ／Ｓｃｒｅｅｎ３Ｄ対ごとに１つのＪ３ｄＴｈｒ
ｅａｄＤａｔａオブジェクトを使用する。

【０１１２】 ｗｏｒｋＴｈｒｅａｄｓ配列が割り当てられた後に、その配列に書き込むよう
にｕｐｄａｔｅＷｏｒｋＴｈｒｅａｄｓ（）を構成することができる。Ｊ３ｄＴ
ｈｒｅａｄＤａｔａオブジェクトは、配列に追加される時に、そのさまざまなフ
ィールドに書き込まれる。スレッド呼出しを管理する方法を知るためにＭＣＴが
使用する、いくつかのスレッド実行オプションがある。オプションの一部は、互
いに排他的であるが、それ以外は組み合わせることができる。 一実施形態では、オプションのリストに下記が含まれる。 ・Ｊ３ｄＴｈｒｅａｄＤａｔａ．ＣＯＮＴ＿ＴＨＲＥＡＤ：このスレッドの実
行中に他のスレッドを実行することができる。 ・Ｊ３ｄＴｈｒｅａｄＤａｔａ．ＷＡＩＴ＿ＴＨＩＳ＿ＴＨＲＥＡＤ：他のス
レッドの実行を許可する前に、このスレッドが終了するまで待機する。 ・Ｊ３ｄＴｈｒｅａｄＤａｔａ．ＷＡＩＴ＿ＡＬＬ＿ＴＨＲＥＡＤＳ：他のス
レッドの実行を許可する前に、現在実行中のすべてのスレッドが完了するのを待
つ。 次の２つのフラグの一方を、上のフラグと組み合わせることができる。 ・Ｊ３ｄＴｈｒｅａｄＤａｔａ．ＳＴＡＲＴ＿ＴＩＭＥＲ：所与のＶｉｅｗに
関連するフレームのタイミングを開始する。 ・Ｊ３ｄＴｈｒｅａｄＤａｔａ．ＳＴＯＰ＿ＴＩＭＥＲ：所与のＶｉｅｗに関
連するフレームのタイミングを停止する。そのデータをＶｉｅｗに保管する。

【０１１３】 状態配列に書き込む際に、配列の最初のスレッドは、ＲｅｎｄｅｒｉｎｇＡｔ
ｔｒｉｂｕｔｅＳｔｒｕｃｔｕｒｅ更新スレッドである。これが最初であるのは
、システム全体について１つだけ存在するからである。次に、各ｕｎｉｖｅｒｓ
ｅのＴｒａｎｓｆｏｒｍＳｔｒｕｃｔｕｒｅ更新スレッドが追加される。これら
は、他のスレッドが更新された値を使用できるようにするために、早期に実行さ
れる必要がある。これによって、更新リストのセクション１が完了する。このセ
クションのすべてのスレッドを、並列に実行することができるが、更新リストは
、それらが終了するまで継続されない。スレッドの次のセクションは、更新スレ
ッドに基づくｕｎｉｖｅｒｓｅの完了である。したがって、ｕｎｉｖｅｒｓｅご
とに、更新スレッドが、ＧｅｏｍｅｔｒｙＳｔｒｕｃｔｕｒｅ、Ｂｅｈａｖｉｏ
ｒＳｔｒｕｃｔｕｒｅ、ＲｅｎｄｅｒｉｎｇＥｎｖｉｒｏｎｍｅｎｔＳｔｒｕｃ
ｔｕｒｅ、およびＳｏｕｎｄＳｔｒｕｃｔｕｒｅについて追加される。このセク
ションのすべてのスレッドを、並列に実行することができるが、これらが完了す
るまでは、それ以上の更新／作業スレッドは実行されない。これは、これらが、
これらの構造体に対する更新に頼るからである。更新／作業スレッドの最後のセ
ットは、各ｕｎｉｖｅｒｓｅのＢｅｈａｖｉｏｒＳｃｈｅｄｕｌｅｒ、各Ｐｈｙ
ｓｉｃａｌＥｎｖｉｒｏｎｍｅｎｔのＩｎｐｕｔＤｅｖｉｃｅＳｃｈｅｄｕｌｅ
ｒ、および、Ｖｉｅｗごとの、ＲｅｎｄｅｒＢｉｎ更新スレッドおよびＳｏｕｎ
ｄＳｃｈｅｄｕｌｅｒである。これらのスレッドも、並列に実行することができ
る。

【０１１４】 ｗｏｒｋＴｈｒｅａｄｓ配列の第２次元は、レンダ・スレッドに使用される。
ＭＣＴは、別々のＳｃｒｅｅｎ３Ｄに対するものであるが同一のＶｉｅｗを共有
するＣａｎｖａｓ３Ｄへの並列レンダリングを可能にする。これを容易にするた
めに、Ｃａｎｖａｓ３ＤがＶｉｅｗに追加され、除去される時に、いくつかのデ
ータ構造をＶｉｅｗで更新することができる。これらは、２つのＡｒｒａｙＬｉ
ｓｔからなる。第１のＡｒｒａｙＬｉｓｔであるｓｃｒｅｅｎＬｉｓｔは、現在
アクティブなすべてのＳｃｒｅｅｎ３Ｄのリストである。第２のＡｒｒａｙＬｉ
ｓｔであるｃａｎｖａｓＬｉｓｔは、ＡｒｒａｙＬｉｓｔのリストである。この
リストの各ＡｒｒａｙＬｉｓｔは、そのＳｃｒｅｅｎ３Ｄ上のすべてのＣａｎｖ
ａｓ３Ｄのリストである。

【０１１５】 図９に移ると、この構造が、３つの一般的なケースについて示されている。第
１のケースは、最も一般的な、１つのＳｃｒｅｅｎ３Ｄ（３０２）上の１つのＣ
ａｎｖａｓ３Ｄ（３０８）を有するケースである。第２のケースは、１つのＳｃ
ｒｅｅｎ３Ｄ（３０２）上の２つのＣａｎｖａｓ３Ｄ（３０８および３２０）を
有する。第３のケースは、２つのＳｃｒｅｅｎ３Ｄ（３０２および３１６）上の
２つのＣａｎｖａｓ３Ｄ（３０８および３２０）である。第３のケースは、シス
テムが２つのキャンバスに並列にレンダリングできるケースである。ｃａｎｖａ
ｓＬｉｓｔ（３１０）が、Ｃａｎｖａｓ３Ｄの２次元配列（３１０Ａから３１０
Ｂ）としてキャッシングされ、したがって、これをすばやく構文解析することが
できる。

【０１１６】 ｕｐｄａｔｅＷｏｒｋＴｈｒｅａｄｓ（）に戻ると、スケジューリングされる
必要があるＲｅｎｄｅｒｅｒを、この２次元配列から導出することができる。ｃ
ａｎｖａｓＬｉｓｔの各項目は、そのＳｃｒｅｅｎ３ＤのＣａｎｖａｓ３Ｄの配
列である。ｃａｎｖａｓＬｉｓｔ配列の長さは、並列に実行できるＲｅｎｄｅｒ
ｅｒの総数である。ｃａｎｖａｓＬｉｓｔ内の最長の配列が、スケジューリング
される必要がある並列Ｒｅｎｄｅｒグループの総数である。各Ｓｃｒｅｅｎ３Ｄ
が、その上の異なる数のＣａｎｖａｓ３Ｄを有する可能性があるので、各並列レ
ンダ・グループが、同一のサイズであるとは限らない。並列レンダ・グループ内
の、最後の１つを除くすべてのＲｅｎｄｅｒスレッドが、スレッド・オプション
にＪ３ｄＴｈｒｅａｄＤａｔａ．ＣＯＮＴ＿ＴＨＲＥＡＤをセットされる。レン
ダ・グループ内の最後の１つは、そのフラグにＪ３ｄＴｈｒｅａｄＤａｔａ．Ｗ
ＡＩＴ＿ＡＬＬ＿ＴＨＲＥＡＤＳをセットされる。というのは、これが、そのグ
ループ内のすべてのスレッドが終了するのを待つからである。これらのＲｅｎｄ
ｅｒｅｒ呼出しのすべてが、２つのスレッド引数すなわち、実行するオペレーシ
ョン（Ｒｅｎｄｅｒｅｒ．ＲＥＮＤＥＲ）と、レンダリングする対象のＣａｎｖ
ａｓ３Ｄを有する。

【０１１７】 ｗｏｒｋＴｈｒｅａｄｓレンダ配列に次に追加されるスレッドのセットは、バ
ッファ・スワップ・コマンドを発行するＲｅｎｄｅｒｅｒスレッドである。Ｖｉ
ｅｗのＳｃｒｅｅｎ３Ｄごとに１つのスレッド呼出しが必要である。これは、ｃ
ａｎｖａｓＬｉｓｔをもう一度反復することによって、直接に得られる。これら
のＲｅｎｄｅｒｅｒスレッド呼出しの、最後の１つを除くすべてが、そのスレッ
ド・オプションにＪ３ｄＴｈｒｅａｄＤａｔａ．ＣＯＮＴ＿ＴＨＲＥＡＤをセッ
トされる。というのは、これらのすべてを並列に実行できるからである。最後の
Ｒｅｎｄｅｒｅｒは、そのスレッド・オプション・フラグに、Ｊ３ｄＴｈｒｅａ
ｄＤａｔａ．ＷＡＩＴ＿ＡＬＬ＿ＴＨＲＥＡＤＳおよびＪ３ｄＴｈｒｅａｄＤａ
ｔａ．ＳＴＯＰ＿ＴＩＭＥＲをセットされる。というのは、このスレッドが、す
べてのスレッドが終了するのを待ち、Ｖｉｅｗタイマを停止するからである。各
Ｒｅｎｄｅｒｅｒが受け取る引数は、実行するオペレーション（Ｒｅｎｄｅｒｅ
ｒ．ＳＷＡＰ）、Ｖｉｅｗ、およびスワップされるＣａｎｖａｓ３Ｄのリストで
ある。レンダ配列の最後の項目は、レンダ要求スレッドである。これは、オフス
クリーン・レンダリング要求およびイミディエート・モード要求を処理するのに
使用される。この時点で、ｗｏｒｋＴｈｒｅａｄｓ配列が更新された。ｕｐｄａ
ｔｅＷｏｒｋＴｈｒｅａｄｓ（）が完了した後に、ｕｐｄａｔｅＴｈｒｅａｄＬ
ｉｓｔｓ（）が、ゾンビ・スレッドのリストを処理し、Ｊ３ｄＴｈｒｅａｄ．ｆ
ｉｎｉｓｈ（）を呼び出すことによってそれらをｋｉｌｌする。ここで、Ｍａｓ
ｔｅｒＣｏｎｔｒｏｌが、スケジューリングされるスレッドの完全に更新された
セットを有する。

【０１１８】 Ｔｉｍｅ 上で述べたように、一実施形態では、各スレッドに関連する４つの時間がある
。まず、ｌａｓｔＵｐｄａｔｅＴｉｍｅがある。これは、メッセージがそのスレ
ッドに送られた最後の時刻である。メッセージがスレッドに送られるたびに、こ
の値が更新される。次はｕｐｄａｔｅＴｉｍｅである。これは、ｌａｓｔＵｐｄ
ａｔｅＴｉｍｅのスナップショット値である。スナップショット時間は、各ＭＣ
Ｔ反復の最初にとられる。最後に、ｌａｓｔＵｐｄａｔｅＲｅｆｅｒｅｎｃｅＴ
ｉｍｅとｕｐｄａｔｅＲｅｆｅｒｅｎｃｅＴｉｍｅがある。これらの時間によっ
て、スレッドの所与の呼出しで処理されつつある時間値のスナップショット範囲
が定義される。これらも、各ＭＣＴ反復の最初にとられる。

【０１１９】 ＭＣＴのフローに戻って、ｗｏｒｋＴｈｒｅａｄｓリストを検査した後に、Ｍ
ＣＴは、スレッドのタイム・スナップショットをとる。これは、ｕｐｄａｔｅＴ
ｉｍｅＶａｌｕｅｓ（）で行われる。反復ごとに保存される、２つの時間値すな
わち、ｃｕｒｒｅｎｔＴｉｍｅとｌａｓｔＴｉｍｅがある。変数ｃｕｒｒｅｎｔ
Ｔｉｍｅは、ｕｐｄａｔｅＴｉｍｅＶａｌｕｅｓ（）が呼び出されるたびに、ｇ
ｅｔＴｉｍｅ（）を呼び出すことによって取り出される。変数ｌａｓｔＴｉｍｅ
は、前のｃｕｒｒｅｎｔＴｉｍｅである。スナップショットごとに、ｃｕｒｒｅ
ｎｔＴｉｍｅとｌａｓｔＴｉｍｅの間の時間値によって、現在の時間範囲が定義
される。２つの時間値が更新された後に、各ｗｏｒｋＴｈｒｅａｄが検査される
。各スレッドのｌａｓｔＵｐｄａｔｅＲｅｆｅｒｅｎｃｅＴｉｍｅに、ｌａｓｔ
Ｔｉｍｅがセットされ、各スレッドのｕｐｄａｔｅＲｅｆｅｒｅｎｃｅＴｉｍｅ
に、ｃｕｒｒｅｎｔＴｉｍｅがセットされ、各スレッドのｕｐｄａｔｅＴｉｍｅ
に、スレッドのｌａｓｔＵｐｄａｔｅＴｉｍｅがセットされる。スレッドのｕｐ
ｄａｔｅＴｉｍｅが、そのｌａｓｔＵｐｄａｔｅＲｅｆｅｒｅｎｃｅＴｉｍｅよ
り大きい場合には、そのスレッドが、実行される必要があるスレッドとしてフラ
グを立てられる。

【０１２０】 スレッドの実行 タイム・スナップショットが行われた後に、ＭＣＴは、各スレッドの実行に進
む。ＭＣＴは、ｒｕｎＭｏｎｉｔｏｒ（）を使用して、各スレッドの実行フラグ
に従い、レンダ・スレッドに最高の優先順位を与えて、各スレッドを実行させる
。Ｊ３ｄＴｈｒｅａｄは、初期化される時に、即座にその同期化されるｒｕｎＭ
ｏｎｉｔｏｒ（）メソッドに進み、ｗａｉｔ（）状態に進み、ＭＣＴからの通知
を待つ。スレッドを実行する時刻である時に、ＭＣＴが、それ自体の同期化され
るｒｕｎＭｏｎｉｔｏｒ（）メソッドに進み、スレッドのｒｕｎＭｏｎｉｔｏｒ
（）を呼び出して、それに通知（ｎｏｔｉｆｙ（））し、リターンする。

【０１２１】 この時点で、ＭＣＴは、複数の状態に入ることができる。スレッド実行オプシ
ョンから、このスレッドを待つことが示される場合には、スレッド参照を保管し
、ＭＣＴは、そのスレッドのｎｏｔｉｆｙ（）によってそのスレッドが終了した
ことが示されるまで、ｗａｉｔ（）状態になる。スレッド実行オプションから、
ＭＣＴがすべてのスレッドの完了を待たなければならないことが示される場合に
は、ＭＣＴは、すべての実行中のスレッドが終了するまでｗａｉｔ（）状態に繰
り返し入る。これは、現在実行中のスレッドの数を表すｔｈｒｅａｄＰｅｎｄｉ
ｎｇカウンタを有することによって追跡される。これらのオプションのどちらも
がセットされていない場合には、ＣＰＵリソース不足であるかどうかを検査する
ようにＭＣＴを構成することができる。ＭＣＴは、ｃｐｕＬｉｍｉｔに対してｔ
ｈｒｅａｄＰｅｎｄｉｎｇを検査することによってこれを行う。これらが等しい
場合には、ＭＣＴは、スレッドが完了するまでｗａｉｔ（）状態に入る。これら
の条件のどれもが真でない場合には、ＭＣＴは、次のスレッドに進む。すべての
スレッドが処理された後に、ＭＣＴは、ｕｐｄａｔｅＯｂｊｅｃｔリストを処理
し、もう１つの反復のためにリターンする。

【０１２２】 更新オブジェクト 構造体が、それらの更新を処理する時に、Ｒｅｎｄｅｒｅｒが使用している構
造体の一部を修正することが必要になる場合がある。構造体は、メッセージを処
理する時に更新を行うことができない。というのは、その時にＲｅｎｄｅｒｅｒ
が実行中である可能性が高いからである。いくつかの実施形態では、インターフ
ェース呼出しＯｂｊｅｃｔＵｐｄａｔｅを定義して、この問題に対処することが
できる。インターフェース呼出しは、単一のｕｐｄａｔｅＯｂｊｅｃｔ（）メソ
ッドからなるインターフェースとすることができる。オブジェクトが、それ自体
に対する、Ｒｅｎｄｅｒｅｒが依存する修正を行う必要があることを見つけた場
合に、そのオブジェクトが、このインターフェースを実装する。修正が必要にな
った時に、オブジェクトは、それ自体をＭａｓｔｅｒＣｏｎｔｒｏｌのオブジェ
クト更新リストに追加する。ＭａｓｔｅｒＣｏｎｔｒｏｌは、レンダ依存構造体
への修正を行うことが安全であると判断した時に、その更新オブジェクト・リス
トの各オブジェクトのｕｐｄａｔｅＯｂｊｅｃｔ（）メソッドを呼び出す。これ
が、ＲｅｎｄｅｒｉｎｇＡｔｔｒｉｂｕｔｅｓＳｔｒｕｃｔｕｒｅ、Ｔｒａｎｓ
ｆｏｒｍＳｔｒｕｃｔｕｒｅ、ＲｅｎｄｅｒＢｉｎ、および他の構造体が、その
レンダ依存修正を処理する方法である。

【０１２３】 フレーム・タイマ ＭａｓｔｅｒＣｏｎｔｒｏｌによって実装される特徴の１つが、Ｖｉｅｗフレ
ーム・タイミングＡＰＩである。ＭａｓｔｅｒＣｏｎｔｒｏｌは、ＭＣＴによっ
て処理されるスレッドのスレッド実行オプションにフラグを追加することによっ
て、これを行う。ＭＣＴは、各スレッドについて反復する際に、スレッドの実行
フラグを検査する。Ｊ３ｄＴｈｒｅａｄＤａｔａ．ＳＴＡＲＴ＿ＴＩＭＥＲフラ
グがセットされている場合には、Ｖｉｅｗをスレッド引数から抽出し、Ｖｉｅｗ
のｆｒａｍｅＮｕｍｂｅｒを増分し、Ｓｙｓｔｅｍ．ｃｕｒｒｅｎｔＴｉｍｅＭ
ｉｌｌｉｓ（）を呼び出すことによってｆｒａｍｅＳｔａｒｔＴｉｍｅを取り出
す。その後、スレッドが実行を許可される。スレッドについてＪ３ｄＴｈｒｅａ
ｄＤａｔａ．ＳＴＯＰ＿ＴＩＭＥＲフラグがセットされている場合には、そのス
レッドが、実行を許可され、Ｖｉｅｗが、スレッド引数から抽出され、そのＶｉ
ｅｗのｓｔｏｐＴｉｍｅが、Ｓｙｓｔｅｍ．ｃｕｒｒｅｎｔＴｉｍｅＭｉｌｌｉ
ｓ（）を呼び出すことによって記録され、Ｖｉｅｗ．ｓｅｔＦｒａｍｅＴｉｍｉ
ｎｇＶａｌｕｅｓ（）メソッドが呼び出される。この同期化されるメソッドは、
ｆｒａｍｅＮｕｍｂｅｒ値、ｓｔａｒｔＴｉｍｅ値、およびｓｔｏｐＴｉｍｅ値
を受け取り、ｃｕｒｒｅｎｔＦｒａｍｅＮｕｍｂｅｒ、ｃｕｒｒｅｎｔＦｒａｍ
ｅＳｔａｒｔＴｉｍｅ、ｃｕｒｒｅｎｔＦｒａｍｅＤｕｒａｔｉｏｎ、ｆｒａｍ
ｅＮｕｍｂｅｒｓ環状バッファ、およびｆｒａｍｅＳｔａｒｔＴｉｍｅｓ環状バ
ッファを更新する。アプリケーションが、Ｖｉｅｗ ＡＰＩを用いてこれらの値
のいずれかを取り出す時に、アプリケーションは、同期化されるメソッドを介し
て進んで、これらの値がＭＴ−ＳＡＦＥな形で保管され、取り出されることを保
証する。

【０１２４】 メッセージ 上で注記したように、メッセージを使用して、システム全体を通じて情報を通
信することができる。ＭａｓｔｅｒＣｏｎｔｒｏｌは、システム内のメッセージ
を保管し、配布する。メッセージが必要な時には必ず、そのメッセージが、Ｖｉ
ｒｔｕａｌＵｎｉｖｅｒｓｅ．ｍｃ．ｇｅｔＭｅｓｓａｇｅ（）を呼び出すこと
によって取り出される。このＭａｓｔｅｒＣｏｎｔｒｏｌメソッドは、まず、メ
ッセージｆｒｅｅｌｉｓｔがメッセージを有するかどうかを調べる。そうである
場合には、これらのメッセージの１つを再利用する。そうでない場合には、新し
いメッセージを作成し、それを返す。コンポーネントがメッセージを有した後に
、それをシステムに送る前に書き込まれる必要がある複数のフィールドがある。
書き込まれなければならない最初のフィールドは、ｕｎｉｖｅｒｓｅである。次
に、メッセージのタイプが書き込まれる。すべてのメッセージ・タイプが、Ｊ３
ｄＭｅｓｓａｇｅクラスで見つかる。その後、スレッドのｂｉｔｍａｓｋが書き
込まれる。これは、このメッセージを送られる必要があるすべてのスレッド・タ
イプのｂｉｔｍａｓｋである。可能なすべてのスレッド・タイプを、Ｊ３ｄＴｈ
ｒｅａｄクラスで見つけることができる。最後に、メッセージの引数を書き込む
必要がある。引数の最大個数は、現在は５であるが、この数は任意である。すべ
てのフィールドが完了した後に、メッセージが、ＶｉｒｔｕａｌＵｎｉｖｅｒｓ
ｅ．ｍｃ．ｐｒｏｃｅｓｓＭｅｓｓａｇｅ（）を呼びす事によって、システムに
送られる。処理することができるメッセージには、主に２つのタイプがある。構
造体に送られると同時に作業スレッドに通知するメッセージがある。また、実行
が必要なスレッドに通知することだけを意図されたメッセージがある。この後者
のケースが必要なものである場合には、コンポーネントは、単純にＶｉｒｔｕａ
ｌＵｎｉｖｅｒｓｅ．ｍｃ．ｓｅｎｄＲｕｎＭｅｓｓａｇｅ（）を呼び出して、
引数で指定されたスレッドに通知することができる。

【０１２５】 メッセージの送出 メッセージは、ＶｉｒｔｕａｌＵｎｉｖｅｒｓｅ．ｍｃ．ｐｒｏｃｅｓｓＭｅ
ｓｓａｇｅ（）に送られる時に、以下のステップをたどる。まず、ｇｅｔＴｉｍ
ｅ（）を介して新しい時間値を得ることによって、メッセージの時間フィールド
が書き込まれる。次に、メッセージの宛先である各作業スレッドが、そのｌａｓ
ｔＵｐｄａｔｅＴｉｍｅ値に、メッセージの新しい時間値をセットされる。その
後、このメッセージが予定されたすべての構造体に、Ｊ３ｄＳｔｒｕｃｔｕｒｅ
．ａｄｄＭｅｓｓａｇｅ（）を呼び出すことによってこのメッセージが送られる
。最後に、ＭａｓｔｅｒＣｏｎｔｒｏｌが、行うべき作業があることの通知を受
ける。

【０１２６】 メッセージの消費 メッセージは、ＭａｓｔｅｒＣｏｎｔｒｏｌによって、そのｐｒｏｃｅｓｓＭ
ｅｓｓａｇｅｓ（）メソッドを介して、構造体に送られる。メッセージを取り出
すのは、構造体の更新メソッドの責任である。スレッドは、ＭａｓｔｅｒＣｏｎ
ｔｒｏｌによって実行を通知される時に、２つの時間値すなわち、ｌａｓｔＵｐ
ｄａｔｅＴｉｍｅおよびｒｅｆｅｒｅｎｃｅＴｉｍｅを受け取る。時間値ｌａｓ
ｔＵｐｄａｔｅＴｉｍｅは、メッセージがこの構造体に送られた最後の時間値で
ある。スレッドは、そのスレッドが作業する参照時間であるｒｅｆｅｒｅｎｃｅ
Ｔｉｍｅも得る。構造体にとって、これは、更新スレッドが、ｌａｓｔＵｐｄａ
ｔｅＴｉｍｅ以下であるがｒｅｆｅｒｅｎｃｅＴｉｍｅを超えないすべてのメッ
セージを消費する必要があることを意味する。

【０１２７】 構造体のｐｒｏｃｅｓｓＭｅｓｓａｇｅｓ（）メソッドが呼び出される時に、
その構造体は、時間範囲を用いてｇｅｔＭｅｓｓａｇｅｓ（）を呼び出す。この
メソッドは、その時間範囲に含まれるすべてのメッセージを返す。単一のメッセ
ージを多数の構造体に送ることができ、したがって、各メッセージが、参照カウ
ントを有する。メッセージが構造体メッセージ・キューに追加されるたびに、そ
の参照カウントが増分される。各構造体のｐｒｏｃｅｓｓＭｅｓｓａｇｅｓ（）
メソッドが最後に実行することが、Ｊ３ｄＭｅｓｓａｇｅ．ｄｅｃＲｅｆｃｏｕ
ｎｔ（）の呼出しである。参照カウントが０になる時に、そのフィールドのすべ
てがｎｕｌｌにされ、ＭａｓｔｅｒＣｏｎｔｒｏｌメッセージｆｒｅｅｌｉｓｔ
に置かれる。

【０１２８】 プライマリ・ビュー ＭａｓｔｅｒＣｏｎｔｒｏｌは、各ＶｉｒｔｕａｌＵｎｉｖｅｒｓｅのプライ
マリ・ビューを割り当てる責任も負う。ＭａｓｔｅｒＣｏｎｔｒｏｌにこれを行
うことを要求できるケースが２つある。Ｖｉｅｗがアクティブになる時に、その
Ｖｉｅｗが、ＶｉｒｔｕａｌＵｎｉｖｅｒｓｅがプライマリＶｉｅｗを有するか
どうかを調べる。そうでない場合には、そのＶｉｅｗは、ＶｉｒｔｕａｌＵｎｉ
ｖｅｒｓｅ．ｍｃ．ａｓｓｉｇｎＮｅｗＰｒｉｍａｒｙＶｉｅｗ（）を呼び出す
。また、Ｖｉｅｗが非アクティブ化される時に、そのＶｉｅｗがそのＶｉｒｔｕ
ａｌＵｎｉｖｅｒｓｅのプライマリＶｉｅｗである場合に、そのＶｉｅｗが、Ｖ
ｉｒｔｕａｌＵｎｉｖｅｒｓｅ．ｍｃ．ａｓｓｉｇｎＮｅｗＰｒｉｍａｒｙＶｉ
ｅｗ（）を呼び出す。渡されたＶｉｒｔｕａｌＵｎｉｖｅｒｓｅがプライマリ・
ビューを有する場合に、それは、もはやアクティブでないＶｉｒｔｕａｌＵｎｉ
ｖｅｒｓｅであり、したがって、ＶｉｅｗのｐｒｉｍａｒｙＶｉｅｗフラグに偽
がセットされる。その後、与えられたＶｉｒｔｕａｌＵｎｉｖｅｒｓｅ内のビュ
ーを探して、すべてのアクティブＶｉｅｗについて反復する。最初の１つを見つ
けた時に停止する。見つかった場合には、そのＶｉｅｗのｐｒｉｍａｒｙＶｉｅ
ｗフラグに真をセットし、ＶｉｒｔｕａｌＵｎｉｖｅｒｓｅのプライマリ・ビュ
ーに、見つかったビューをセットする。見つからない場合には、Ｖｉｒｔｕａｌ
Ｕｎｉｖｅｒｓｅのプライマリ・ビューにｎｕｌｌをセットする。

【０１２９】 上の実施形態をかなり詳細に説明してきたが、他のバージョンが可能である。
上の開示を完全に理解した後に、多数の変形形態および修正形態が、当業者に明
白になるであろう。請求項は、そのような変形形態および修正形態のすべてを含
むように解釈されることが意図されている。本明細書で使用した見出しは、編成
のみを目的とし、本明細書の説明または請求項を制限することを意図されていな
いことに留意されたい。

【図面の簡単な説明】

【図１】 本明細書に記載のシステムおよび方法を実施するのに使用することができるコ
ンピュータ・システムの一実施形態を示す図である。

【図２】 図１のコンピュータ・システムの簡略化されたブロック図である。

【図３】 シーン・グラフの一実施形態を示す図である。

【図４】 管理およびレンダリングのための並列構造体を有するシーン・グラフの一実施
形態を示す図である。

【図５】 図４の並列構造体を生成する方法の一実施形態の流れ図である。

【図６】 シーン・グラフのもう１つの実施形態の図である。

【図７】 構造体最適化の一実施形態の図である。

【図８】 現在の作業スレッドのリストの一実施形態の図である。

【図９】 スクリーン・リストおよびキャンバス・リストの複数の例の構成を示す図であ
る。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＭＺ，ＳＤ，ＳＬ，ＳＺ，ＴＺ，ＵＧ ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ， ＲＵ，ＴＪ，ＴＭ)，ＡＥ，ＡＧ，ＡＬ，ＡＭ，ＡＴ， ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＢＺ，Ｃ Ａ，ＣＨ，ＣＮ，ＣＲ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＤＭ ，ＤＺ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ， ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ，Ｋ Ｅ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ ，ＬＴ，ＬＵ，ＬＶ，ＭＡ，ＭＤ，ＭＧ，ＭＫ，ＭＮ， ＭＷ，ＭＸ，ＭＺ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，Ｒ Ｕ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ ，ＴＲ，ＴＴ，ＴＺ，ＵＡ，ＵＧ，ＵＺ，ＶＮ，ＹＵ， ＺＡ，ＺＷ (72)発明者 ソウィッヅラル，ヘンリー アメリカ合衆国・94022−1240・カリフォ ルニア州・ロス アルトス・イースト ポ ートラ アベニュ・16 (72)発明者 ラッシュホース，ケヴィン アメリカ合衆国・95124−2207・カリフォ ルニア州・サン ホゼ・フォウン ドライ ブ・3314 (72)発明者 トゥイリーガー，ドゥーグ アメリカ合衆国・95008−5112・カリフォ ルニア州・キャンベル・フォウン ドライ ブ・1147 Ｆターム(参考） 5B050 BA08 BA09 CA02 EA19 EA24 EA26 FA02 5B080 CA03 GA00

Claims (20)

【特許請求の範囲】
1. 【請求項１】 複数の３次元オブジェクトを表す情報を含むシーン・グラフ
   を生成することと、 該シーン・グラフに対応する構造体およびスレッドの並列セットを生成するた
   めに該シーン・グラフをトラバースすることであって、各構造体が、該シーン・
   グラフから選択されたデータを管理するオブジェクトを含み、複数のスレッドが
   、該シーン・グラフに対応する１つまたは複数のフレームをレンダリングするた
   めに実行可能である、該シーン・グラフをトラバースすることと を含む方法。
2. 【請求項２】 該選択されたデータが、外見データ、ジオメトリ・データ、
   および環境データを含む請求項１に記載の方法。
3. 【請求項３】 複数の３次元オブジェクトを表す、外見データ、ジオメトリ
   ・データ、および環境データを含む情報を備えたシーン・グラフを受け取ること
   と、 該シーン・グラフに対応する複数の構造体およびスレッドを生成するために該
   シーン・グラフをトラバースすることであって、各構造体が、該シーン・グラフ
   から選択されたデータを管理するオブジェクトを含み、複数のスレッドが、該シ
   ーン・グラフに対応する１つまたは複数のフレームをレンダリングするために実
   行可能である、該シーン・グラフをトラバースすることと を実行するように構成された複数の命令を含む、電子媒体上で実施されるコン
   ピュータ・プログラム。
4. 【請求項４】 該スレッドが、状態変化を指定するメッセージを生成するよ
   うに構成された請求項１から３に記載のコンピュータ・プログラムまたは方法。
5. 【請求項５】 該メッセージを、複数の構造体にマルチキャストするか、単
   一の構造体にユニキャストすることができる請求項１から４に記載のいずれかの
   コンピュータ・プログラムまたは方法。
6. 【請求項６】 各構造体が、該構造体を更新するように構成された対応する
   更新スレッドを有する請求項１から５に記載のいずれかのコンピュータ・プログ
   ラムまたは方法。
7. 【請求項７】 該シーン・グラフが、該３次元オブジェクトの挙動データを
   含む請求項１から６に記載のいずれかのコンピュータ・プログラムまたは方法。
8. 【請求項８】 該環境データが、照明情報およびフォグ情報を含む請求項１
   から７に記載のいずれかのコンピュータ・プログラムまたは方法。
9. 【請求項９】 １つの構造体が、レンダリングされる特定のジオメトリ・デ
   ータへの参照をレンダ・ビン内に保管するメッセージを受け取るように構成され
   た該レンダ・ビンである請求項１から８に記載のいずれかのコンピュータ・プロ
   グラムまたは方法。
10. 【請求項１０】 該レンダ・ビンが、それに関連する１つまたは複数のレン
    ダ・スレッドを有し、各レンダ・スレッドが、該ジオメトリ・データをレンダリ
    ングするように構成された請求項１から９に記載のコンピュータ・プログラムま
    たは方法。
11. 【請求項１１】 該プログラムが、各構造体に該シーン・グラフからの該構
    造体のデータを最適化させるように構成された請求項１から１０に記載のコンピ
    ュータ・プログラムまたは方法。
12. 【請求項１２】 該プログラムが、ジオメトリ・データをストリップ化する
    ことによって該構造体のデータを最適化するように構成された請求項１から１１
    に記載のいずれかのコンピュータ・プログラムまたは方法。
13. 【請求項１３】 該プログラムが、ノードを分割することによって該構造体
    のデータを最適化するように構成された請求項１から１２に記載のいずれかのコ
    ンピュータ・プログラムまたは方法。
14. 【請求項１４】 該プログラムが、該シーン・グラフをフラット化すること
    によって該構造体のデータを最適化するように構成された請求項１から１３に記
    載のいずれかのコンピュータ・プログラムまたは方法。
15. 【請求項１５】 該構造体の１つが、境界ボックスである請求項１から１４
    に記載のいずれかのコンピュータ・プログラムまたは方法。
16. 【請求項１６】 該メッセージが、タイム・スタンプを含む請求項１から１
    ５に記載のいずれかのコンピュータ・プログラムまたは方法。
17. 【請求項１７】 該タイム・スタンプが、変更カウントであるいずれかの請
    求項１６に記載のコンピュータ・プログラムまたは方法。
18. 【請求項１８】 該メッセージが、イベント・スタンプを含む請求項１から
    １７に記載のいずれかのコンピュータ・プログラムまたは方法。
19. 【請求項１９】 該メッセージが、個々のスレッドの並列処理を可能にする
    ために使用される請求項１から１８に記載のいずれかのコンピュータ・プログラ
    ムまたは方法。
20. 【請求項２０】 シーン・グラフを受け取ることと、 該シーン・グラフに対応する構造体およびスレッドの並列セットを生成するこ
    とであって、各構造体が、該シーン・グラフから選択されたデータを管理するオ
    ブジェクトを含み、該スレッドの第１サブセットが、該オブジェクトに対する変
    更に基づいて該構造体を更新するために実行可能であり、該スレッドの第２サブ
    セットが、該シーン・グラフを繰り返してトラバースすることなく該構造体に基
    づいて画像をレンダリングするために実行可能である、該シーン・グラフに対応
    する構造体およびスレッドの並列セットを生成することと を含む方法。