JP3059138B2 - ３次元仮想現実環境作成、編集及び配布システム - Google Patents

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、仮想現実（バー
チャル・リアリティ）など高度なグラフィック環境を提
供する分野、特に、通信網を使用してリアルタイムで３
次元仮想現実環境を作成、編集および配布するシステ
ム、情報の配布方法、仮想現実環境、仮想環境の更新方
法、並びに仮想現実環境の実行方法に関する。

【０００２】

【従来の技術】３次元仮想現実環境の作成・編集・配布
分野では、ファイルに格納されているこれらの環境の保
存について改善の必要性のあることがやがて了解される
であろう。仮想現実環境の一部に手を加える場合や異な
るバージョンで仮想現実環境を伝送する場合、つまり、
その環境を編集したり伝送したりする場合、通常、大型
ファイルを格納、伝送およびダウンロードする必要があ
る。

【０００３】３次元仮想現実環境ファイルをインターネ
ットを通じてリアルタイムで編集、作成および配布しよ
うとすると、そこにさまざまな問題が発生する。問題の
範囲としては、永続性(persistence)、スケーラビリテ
ィ(scalability)、セキュリティ、多重編集機能、多解
像度などの問題や、多重フォーマット要件およびバージ
ョン制御が含まれる。

【０００４】まず、永続性について説明する。永続性
は、３次元仮想環境で変更が行われた場合に、その変更
を記録しておく機能のことをいう。確かに、変更はファ
イル全体を書き直せば保存できる。そのため、ほとんど
のシステムでは、オーサリング・ツール（authoring to
ol）で、ブラウザのみ恒久的な変更を行うことは許され
ない。たとえば、ＶＲＭＬファイルについて言うと、フ
ァイル全体をロードおよび保存しなくてもその一部だけ
を変更できることが一般には望ましい。ＶＲＭＬとはバ
ーチャル・リアリティ・モデリング・ランゲージ（Virt
ual Reality Modeling Language)のことで、３次元仮想
現実環境のコンテンツを記録するためのファイル形式で
あることが了解されるであろう。ファイルの中の１つの
項目を変更するために、ファイル全体を読み出してから
それを保存する必要がある。一般にＶＲＭＬファイルの
容量は１０メガバイトにもなることがあるため、変更量
が少ない場合でも実行が厄介になる。

【０００５】次に、３次元仮想環境の規模の拡張にかか
わるスケーラビリティについて説明する。先行技術のフ
ァイル・システムにこの種の機能を期待するのはひたす
ら困難である。それは、情報のほとんどが１つまたはせ
いぜい数個のファイルに格納されるためである。仮想現
実環境を拡張するためには、その数個のファイルを際限
なく多数の部分に分割する必要があり、仮想現実環境用
ファイルの操作方法として、やはり手間ひまがかかる。
さらに、ＶＲＭＬ機能を使用して大型ファイルを細分化
しても、ファイルシステムにおいて非常にたくさんの細
かいファイルを処理しなければならないという新たな問
題が生じ、エラーやデータ損失の発生する機会が増え
る。

【０００６】セキュリティについて説明する。１つのフ
ァイルにセキュリティ・コードを付けた場合、そのファ
イルを編集しようとするユーザはファイル全体へのアク
セス権をもつことが了解されるであろう。ゆえに、現
在、ファイルの編集を要する限られた部分のみのアクセ
ス権を付与し、同時にその他の部分をロックすることは
できない。

【０００７】さらに、アクセス権を与える部分とそうで
ない部分とにファイルを分け、各ユーザの編集個所を限
定することは非常にむずかしい。

【０００８】

【発明が解決しようとする課題】その結果、複数のユー
ザが仮想現実環境の各部分を並行して編集できる多重編
集機能をもたせることは１つのファイルで仮想環境を提
供する現状ではできない。また、１つのファイル・シス
テムでは３次元仮想現実環境を多様な解像度で提供する
ことができない。多解像度の便利な点は、受信するマシ
ンの解像度に出力ファイルの解像度を合わせることがで
きる点である。たとえば、あるハイエンド・マシンには
他のマシンにはないグラフィック・オブジェクトを細か
いテクスチャで表示できる機能がある。また、ポリゴン
のような３次元画像の描画の主要な要素を描く能力はマ
シンにより異なる。現在のところ、ある特定の解像度が
要求されると、それに応じてファイル全体を変更しなけ
ればならないため、単一のコンテンツの入った一つのフ
ァイルを多様な解像度で提供する方法は存在しない。ま
た、１つのファイルで３次元仮想環境を記録する場合、
複数のプラットフォームで同じコンテンツを表示する機
能、たとえばプラットフォーム間での互換機能がない。
仮想現実環境を単一ファイルに記録する方法では、同じ
コンテンツを異なるフォーマットで提供する多重フォー
マットを使用できない。

【０００９】最後に、仮想現実環境の格納に単一ファイ
ルを使用する場合、元のファイル全体を複製しなくては
バージョン修正ができない。よって、たとえば１０メガ
バイトのファイルについて数バイトの変更をする場合、
バージョンを変更するために１０メガバイトのファイル
が２つできてしまう。

【００１０】まとめとして、３次元仮想環境の作成、編
集および配布に関する上記の問題は、複数のプラットフ
ォームで複数のオーサ(author)が作業することのできな
い現行システムでは解決できない。ゆえに、機能の異な
る多様なハードウェアマシンにコンテンツを配布するシ
ステムを必要とする。さらに、必ず指定されたユーザだ
けにコンテンツへのアクセス権が与えられるようにする
一方で、仮想環境の無限の成長を妨げないようにするこ
とが重要である。

【００１１】最後に、どうしたら３次元環境をオーサが
その環境のオブジェクトの制御権を得たり放棄したりで
きる間、永続的かつ編集可能にすることが思いのままに
できるかは、仮想環境を単一ファイルに格納する現状を
考えると、面倒な問題である。

【００１２】この発明は上述した点に鑑みてなされたも
ので、複数のユーザが共通の３次元環境の個々の部分を
並行して作業でき、各人に３次元環境の異なる部分への
アクセス権を選択して与えることを可能にする３次元仮
想現実環境作成、編集および配布システムを得ることを
目的とする。

【００１３】

【課題を解決するための手段】この発明に係る３次元仮
想現実環境作成、編集および配布システムは、データベ
ースと、仮想現実環境を作成する手段と、上記作成され
た仮想現実環境を上記データベースに格納する手段と、
上記データベースにアクセスし、アクセスされたデータ
を配布する手段とを備え、上記データベースはレコード
を含み、上記仮想現実環境は異なるパーツに分割され、
パーツ毎に個々のレコードに分けて格納され、それによ
り上記仮想現実環境は他の部分に影響を与えることなく
作成、編集または配布できるものとすると共に、上記パ
ーツをローカルとし、さらに、上記データベースに上記
仮想現実環境の各種バージョンが格納されるものとし、
ネットワークと、上記ネットワークに接続され、予め決
められた構成をもつ配布先マシンとをさらに備え、上記
データベースにアクセスし、アクセスされたデータを配
布する手段は、上記予め決められた構成に互換性のある
上記データベースに格納された上記仮想現実環境の特定
のバージョンだけを上記配布先マシンに伝送するもので
ある。

【００１４】また、上記データベースをリレーショナル
・データベースとするものである。

【００１５】

【００１６】

【００１７】また、上記データベースの予め決めたられ
た部分だけにアクセスを許可する手段をさらに含むもの
である。

【００１８】

【００１９】

【００２０】

【００２１】

【００２２】

【００２３】

【００２４】

【００２５】

【００２６】

【００２７】

【００２８】

【００２９】

【００３０】

【００３１】

【００３２】

【００３３】

【００３４】

【００３５】

【００３６】

【００３７】

【００３８】

【００３９】

【００４０】

【００４１】

【００４２】

【００４３】

【００４４】

【００４５】

【００４６】

【００４７】

【発明の実施の形態】この発明に係る仮想環境の作成・
編集・配布システムは、仮想現実環境またはシーンをフ
ァイル形式ではなく、別々のレコードに分割してデータ
ベース形式で格納するシステムである。これにより、複
数のオーサが共通の３次元環境の個々の部分を並行して
作業できるほか、各人に３次元環境の異なる部分へのア
クセス権を選択して与えることが可能となり、バージョ
ン制御が実現し、永続性などの変更を保存する機能が実
現し、スケーラビリティ、セキュリティおよびフォーマ
ット制御機能が実現し、すべて他の部分に影響を与えず
仮想現実環境のさまざまな部分について作業ができる独
立性がもたらされる。また、データベースを使用するこ
とにより、インデックスにより環境のさまざまな部分に
速やかにアクセスできるようになる。

【００４８】たとえば、データベースで個々のレコード
またはオブジェクトを他のレコードを変更せずに更新で
きる点は、先行技術のシステムよりも有利である。ここ
では、仮想環境をファイルとして格納し、たとえば、２
人以上の異なるクリエータが、少し前に加えられた変更
に影響を与えたり、それらを書き換えたりせずに、同時
にいろいろなレコードを変更し、対象レコードだけを更
新できる。これにより、必要なネットワーク通信量をか
なり減らすことができる。

【００４９】データベースを使用することにより、他の
レコードに関係なく、データベースの必要な部分を照
合、変更および出力できるため、永続性、スケーラビリ
ティ、多重編集機能、多解像度、多重フォーマットおよ
びバージョン制御の問題を解決できる。

【００５０】永続性を保つには、揮発性ＲＡＭ記憶装置
を除き、高密度ディスク記憶装置などの非揮発性の永久
記憶装置を必要とし、それらがいずれも高速かつ非揮発
性であることが注目されるであろう。

【００５１】きめ細かい方法でアクセスおよびロッキン
グ制御を行い複数のユーザによる使用を促進することが
できる点も重要である。しかし、１度にロッキングでき
る部分が大きすぎる場合、たとえばパーティションの細
かさが不十分な場合などは、一人のオーサが３次元環境
の細かい部分の編集をするときも、広い部分をロックア
ップした状態でしか目的の編集ができない。

【００５２】データベースに３次元環境を格納すること
により、ハードディスクでのファイルと等価な永続性を
得られる。実際、データベースの使用により、３次元環
境の必要な部分にだけアクセスすることができ、そうす
ることで、ファイル全体を使用しダウンロードする場合
より格段に早く編集できる。また、データベースでは、
複数のオーサの同時アクセスおよび行またはオブジェク
トのロッキング作業も可能である。

【００５３】上記のことを達成するために、データベー
スにパーティションを作り、３次元環境全体を関連付け
された扱いやすい分量の大きさに細分化する。一つの実
施例で、フレキシビリティとスケーラビリティにも優れ
ているという理由から「ローカル」方式を選択すると便
利である。

【００５４】したがって、この発明である仮想環境作成
・編集・配布システムは、仮想現実環境情報をデータベ
ースに格納し、各部分を他の部分に影響を与えずに作
成、編集または配布できるようにする。データベースに
は、たとえばワイド・エリア・ネットワークなどの通信
網を使ってアクセスし、各データベースのレコードをデ
ータベース内の他のレコードに影響を与えることなく個
別に更新できる。このように、仮想環境ファイルを変更
するために、ファイル全体を読み出したり格納したりす
る必要がない。さらに、配布先マシンの特性によりデー
タベースの読出しバージョンが口述されるため、配布先
マシンと互換性のあるバージョンを提供できる。さら
に、テクスチャなど仮想現実環境の特定の態様をいろい
ろな形で格納し、配布先マシンのそれぞれの特性に適応
できる。たとえば、ある仮想現実環境の地形テクスチャ
を、大容量のテクスチャ・メモリを備えた配布先マシン
用として「高解像度、２４ビットフォーマット」、小容
量のテクスチャ・メモリの配布先マシン用として「低解
像度、低ビット・デプス(depth)フォーマット」、さら
にテクスチャ・メモリを備えていない配布先マシン用と
して非テクスチャフォーマットで、それぞれ格納でき
る。

【００５５】（詳細な説明）全体として、仮想現実環境
が使用される機会はますます増えている。仮想現実環境
を応用したものとしてはコンピュータ・ゲームがある。
しかし、他にも多くの分野で実用化が模索されている。
たとえば、仮想現実環境は、医療分野など特定の分野で
手術の訓練環境など専門家の育成を可能にするために作
成できる。また、通信網で複数の人がその環境にアクセ
スすることを可能にしてそれらの人の協働や対話を可能
にする仮想現実環境が作成されつつある。

【００５６】仮想現実環境はそれを実行する所定の配布
先コンピュータ・システムでそのグラフィック機能やサ
ウンド機能などいろいろな資源を利用する。

【００５７】コンピュータの機能は千差万別である。た
とえば、あるハイエンド・コンピュータ・システムは非
常に詳細なテクスチャのグラフィックを表示できる。ま
た、ハイエンド・グラフィック表示ワークステーション
は、６４メガバイトのテクスチャ用メモリを備え、その
メモリを使用して、表示する仮想現実環境の現実感をか
なり高めることができる。テクスチャを格納するメモリ
をもたない配布先マシンもある。ある配布先コンピュー
タ・システムには３次元グラフィックス表示機能がある
が、他の配布先コンピュータ・システムには２次元グラ
フィックス表示機能しかないということもある。あるハ
イエンド・コンピュータ・システムは非常に高忠実度の
サウンドを出すことができるのに対し、他のローエンド
機器は比較的低忠実度のサウンドしか出せない。さら
に、ネットワーク化された環境では、コンピュータ・シ
ステムによりネットワーク通信速度が異なる。仮想現実
環境は、たとえば複数の人がネットワーク化されたゲー
ムを行ったり、実際に仮想現実環境をリモート・コンピ
ュータに格納し、ネットワークを通じて配布先コンピュ
ータにそれを伝送したりする場合でも、配布先マシンの
ネットワーク通信機能に左右される。

【００５８】仮想現実環境のコンテンツを各種の配布先
コンピュータに分散する従来技術の方法では、それぞれ
の配布先マシンに送られる内容を、ハイエンド・ワーク
ステーション用は第一ファイル、ミドルレンジ・ワーク
ステーション用は第二ファイル、パーソナル・コンピュ
ータ用は第三ファイル、ネットワーク・コンピュータ用
は第四ファイル、そしてセットトップボックス(SET TOP
BOX)用は第五ファイルにというように、それぞれ別々
のファイルに分散させる。

【００５９】従来技術によるこれら各配布先コンピュー
タ用のコンテンツの開発手順は、それぞれの配布先コン
ピュータに合わせてコンテンツを個々に開発し、それら
を別々の大型ファイルに格納するというものである。仮
想環境の一部にだけアクセスすればよい場合も、配布先
コンピュータはやはりファイル全体をダウンロードしな
ければならない。よって、３次元仮想環境を読み出し、
それらを１つのファイルに格納する方法以外の方法で格
納し、必要な部分だけをダウンロードすれば済むように
する必要がある。また、各種マシンまたはプラットフォ
ームに配布される仮想環境は同様の内部構造をもち、す
べてのマシンでそれらを維持する必要がある。複数のフ
ァイルが同一の内部構造を保つように保守することは困
難であり、時間がかかる。

【００６０】また、コンテンツの一部を変更する場合、
少なくともさらに２つの問題が生じる。第一に、ハイエ
ンド・ワークステーションのコンテンツを変更しても、
セットトップボックスなどのローエンド・ワークステー
ションのコンテンツにそれが反映されないことである。
変更は、ファイルごとに別々に行う必要がある。第二
に、コンテンツをほんの少し変更するだけでも、全体の
コンテンツを再びファイルに保存する必要があることで
ある。仮想現実環境は大型ファイルとなる可能性があ
り、事実、常にそうである。ファイルを保存する単純な
行為に手間取る可能性があり、それだけで仮想現実環境
を変更の妨げとなる。

【００６１】了解されるように、仮想現実環境のほんの
一部分を変更するために、少なくともファイル全体を保
存しなおして変更を完了する必要があるため、一般に、
ファイル全体にアクセスする必要がある。このことが面
倒な操作であるという状況は容易に想像がつく。たとえ
ば、ミシガン州デトロイトにいるクライアントのネット
ワークで仮想現実環境の変更を要求する例を挙げる。ク
リエータがミシガン州のネットワークで作成した仮想現
実環境のインストールに成功した後、カリフォルニア州
の自宅からその編集をしている時に、仮想現実環境のあ
る部分を変更したいという要求を上記のクライアントか
ら受けた。クリエータは、ローカル・コンピュータ・シ
ステムに仮想現実ファイルのコピーをもっていても、要
求された変更をした後、ファイル全体をそのクライアン
トのネットワークに転送する必要がある。普通、仮想現
実環境ファイルのサイズが大きい場合、クライアントの
ネットワークにそのファイルを転送するために要する時
間は法外とは言わないまでも、非常に長くなる可能性が
ある。したがって、３次元仮想現実ファイルの限られた
部分だけを編集できるシステムが必要である。

【００６２】さらにまた、仮想現実環境を作成する際、
クリエータは一般に開発用マシンで環境を開発する。開
発用マシンは、一般に比較的ハイエンドである。よっ
て、開発する環境は、ハイエンド・マシンの機能を用い
て表示し、往々にしてローエンドの配布先マシンで個々
に試験する必要がある。この過程は、開発、試験、再開
発の反復となる可能性がある。必要なのは、同じコンテ
ンツを機能の異なるマシン上で設計できるよう、多様な
バージョンでコンテンツを作成できるシステムである。

【００６３】したがって、必要とされるのは、上記の課
題を克服する仮想現実環境開発および実行環境というこ
とになる。

【００６４】より詳細には、解決を必要とする問題と
は、各種プラットフォームで複数のオーサが共に３次元
環境を設計する方法である。また、機能的に異なる種々
のハードウェアにコンテンツを配布できなければならな
い。必ず指定したユーザにだけコンテンツへのアクセス
権が付与され、指定したオーサにだけ３三次元環境の修
正が許可されるようにすることも重要である。さらに、
たとえば毎秒描画できるポリゴンの数についてハードウ
ェア上の制限がある場合でも、どのようにして無限に仮
想環境を拡張していくことができるかが重要である。ま
た、３次元環境にある期間にわたり永続性をもたせ、修
正可能とし、オーサが環境内のオブジェクトに自由に制
御できるようにする必要もある。

【００６５】したがって、３次元環境を速やかに変更、
作成、管理および配布する機能に問題があるために、イ
ンターネット上のリアルタイム系３次元仮想環境に永続
性、スケーラビリティ、セキュリティ、多重編集機能、
機能の異なるプラットフォーム間の互換性をもたらす多
重フォーマット、多解像度およびバージョン制御機能を
実現することが重要である。

【００６６】次に、図１（Ａ）と（Ｂ）を参照すると、
それから分かるように、端末装置１０は仮想現実シーン
１２をディスプレイ１４に表示している。一般に、点線
で囲まれた枠１８の領域内のグラフィカル・オブジェク
ト１６を編集対象として仮想現実シーンを編集するのが
望ましい。仮想現実シーンのそのような部分を編集する
ことが望ましい場合、以下で説明するように、リレーシ
ョナル・データベースの中の当該グラフィカル・オブジ
ェクトの位置する特定のローカルが格納されている部分
にアクセスし、そのグラフィカル・オブジェクト１６を
変更できる。この例の場合、自転車がなくなり、グラフ
ィカル・オブジェクト１６’のように立っている人物が
描かれる。

【００６７】次に、図２を参照して説明する。３次元環
境編集機能を実現するために、最初に、テクスチャとサ
ウンド２２、プリミティブ２４、パーツの集合および階
層を含む構成要素２６、さらに一般的には仮想現実画面
をいろいろなまとまりや領域に分けるローカル２８など
の入力データを使用して枠２０に示すように３次元環境
を作成する。

【００６８】作成した３次元仮想環境は、細分化された
データベース３０にダウンロードしてそこに格納し、３
次元仮想現実環境を含む単一ファイル全体の読出しおよ
び（または）格納を行わなくても３次元環境のいろいろ
な部分を編集、変更または削除することができる。

【００６９】これにより、複数のオーサ３２が仮想現実
環境のいろいろな部分に手を加えることが可能になる。
さらに、３４に示すように、仮想現実環境の各部分への
アクセスを制限できる。また、特定の仮想環境のバージ
ョンは３６で制御するが、どのバージョンかはクライア
ント・サーバ・システムのクライアントの示すハードウ
ェア要件３８によりいくぶん異なる。

【００７０】永続性は、４２に示すように、他に影響を
与えることなく仮想環境の各部分を変更する機能により
保証されるのに対し、スケーラビリティは、４４に示す
ように、細分化データベースを編集することで実現す
る。

【００７１】最後に、フォーマット４６を指定して、細
分化データベースの出力が特定の関連ハードウェアの出
力をフォーマットまたは調整し、種々のフォーマット変
換を行ったり、５０に示すように、単一のプリミティブ
を編集したりすることができる。

【００７２】「細分化」という語は仮想環境を個々の部
分に分割し、各部分を別々に作業できることをさしてい
ることが了解されるであろう。

【００７３】次に、図３について説明のための実施例を
用いて説明する。仮想現実シーンに、たとえばテーブル
３００、カップ３０２、皿３０４および別の皿３０６を
描くとする。図から分かるように、これらの要素は原点
（０，０，０）を基準に仮想現実シーンに位置してい
る。仮想現実シーン全体を３００から３０６までの項目
に分け、単一のファイルに格納した場合は常にファイル
全体をダウンロードする必要がある。しかし、仮想現実
シーンを各ローカルに分割し、ここでは参照数字３１０
のついているローカルＡにカップ３０２、皿３０４およ
びテーブル３００を含め、それと別に、ここでは参照数
字３１２のついたローカルＢにリレーショナル・データ
ベースの表３２０で示したように皿３０６を含めること
により、当該ローカルを指定して皿３０６を取り出し、
仮想現実シーンの他のすべてのグラフィカル・オブジェ
クトとは別にそれを編集できる。ファイル４００から分
かるように、ローカルＡはテーブルや皿などを含むのに
対し、ローカルＢは（１０，１０，０）の位置の皿を含
む。したがって、特定の細分化されたリレーショナル・
データベースを使用することにより、仮想現実シーンの
どのような小さい部分も編集できることがわかる。

【００７４】次に、図４を参照すると、データベースに
アクセスする手段となるＶＲＭＬファイルにより、デー
タベースの個々の部分を変更して仮想現実環境の対応す
る部分を変更できることが明らかである。

【００７５】より詳細に、次に、図５（Ａ）を参照する
と、画像５００は、仮想環境５０２に描かれたシーンで
ある。この仮想環境は、家５０４、ビル５０６と５０
８、道路５１０、風景５１２および草５１４、５１６、
５１８、５２０を含む。広告掲示板５２２は、仮想環境
で３次元レンダリング・モードのハードウェアが描画す
る必要のあるポリゴンの数を増やすことなく環境の現実
感を高めるために仮想環境でよく使用される「テクスチ
ャ・マップ」という画像を表示する。また、存在し、音
は聞こえるが、画面に表示されないものとしては、鳥の
さえずりとビル、家および広告掲示板を吹き抜ける風の
音がある。

【００７６】図５（Ａ）に示された家５０４などの各モ
デルは、ポリゴンの一覧表を使用して作成する。各ポリ
ゴンは面または頂点ごとに固有の色が割り当てられてい
る。また、ポリゴンごとに関連付けられた「テクスチャ
・マップ」があり、同一色で塗りつぶしたり、隣接する
ポリゴン間で滑らかに明るさが変化するように処理した
ポリゴンではなく、細かい柄や模様の画像をポリゴンに
貼り付けたように画像を表示できる。

【００７７】テクスチャ・マップは、３次元仮想環境に
なくてはならないものである。なぜなら、３次元グラフ
ィックス作成用の各ハードウェアは、画面にポリゴンを
描画する機能が限られているからである。一軒の家を非
常に詳しく現実感を出して描くために何百万個というポ
リゴンを必要とする場合、テクスチャを使用してその家
の側面全体を、その細部を再現したような画像の写った
一枚の方形のポリゴンに置き換えることができる。つま
り、毎秒１０，０００個のポリゴンしか描けない３次元
グラフィックス作成ハードウェアでも１０または１５フ
レーム／秒というかなりの速度で各フレームに数軒の家
を描画できるうえ、描画されたこれらの家は家として認
識できる。

【００７８】３次元グラフィックスを表示するにあた
り、すべての３次元グラフィック作成用ハードウェアが
テクスチャ・マップを使用できるわけではないが、テク
スチャ・マップを使用して画面をより詳細に描写するこ
とが重要視されるために、そのような状況はますます稀
有になりつつある。

【００７９】ただし、今日、ほとんどの３次元グラフィ
ックス表示用ハードウェアがテクスチャ・マップをサポ
ートしているとはいえ、それらのハードウェアがすべて
同じようにテクスチャを処理するわけではない。あるハ
ードウェアは、ガラスやプラスチックなどの透明なテク
スチャをサポートする。また、あるハードウェアは、テ
キスト画像を方形あるいは１２８×１２８ピクセルのよ
うな特定のサイズにする必要がある。１メガバイトのテ
クスチャ画像しか処理できないものもあれば、６４メガ
バイトのテクスチャ画像をサポートし、非常に優れた質
感の３次元環境を描けるものもある。

【００８０】限られたテクスチャ・メモリしか使用でき
ない場合、４メガバイトのテクスチャを使用する大型仮
想環境は、各テクスチャがそれより小さくても表示でき
る。つまり、すべてのテクスチャを各方向２分の１に縮
小することにより、それらのテクスチャに要する総メモ
リをたった１メガバイトに減らすことができ、１メガバ
イト・テクスチャのマシンでそれを表示できる。

【００８１】テクスチャ・マップは、図５（Ａ）の広告
掲示板５２２に見られ、家５０４の側面で家の窓を表す
ためにも使用されている。他に道路５１０の交通車線の
表示にも見られる。

【００８２】草５１４、５１６、５１８および５２０
は、一連のポリゴンを組み合わせて草の葉の形に表示す
ることができるが、一般に、葉は部分的に透明な部分を
もつ１つの方形である。画像の透明でない部分は生えて
いる葉の形にグリーンで彩色する。

【００８３】次に、図５（Ｂ）を参照すると、広告掲示
板５２２’は、やはりテクスチャ・マップを使用してい
ることが分かるが、画像は英字以外の文字を含んでい
る。この場合、仮想環境の景色である画像５００’は、
英語を話さない人のために、元の英語版広告掲示板のテ
クスチャの代わりに、視聴者の母国語で描かれたテクス
チャで描かれている。本人に直に尋ねるなど、視聴者の
話す言語を確かめる方法はいろいろあることが了解され
るであろう。使用言語を確認した後、その言語によるテ
クスチャが作成されたとして、広告掲示板のテクスチャ
・マップに対応する適切な画像に置換できる。

【００８４】また、これと同じ置換技術を使用して、仮
想環境の視聴者の個性と特定の関心対象に応じて的を絞
った広告メッセージを広告掲示板に載せることができる
ことも了解されるであろう。

【００８５】現在使用可能なシステムではこの種の置換
を行う便利な方法は存在しない。前述のように、ほとん
どのシステムは、仮想環境を単一の大型ファイルに格納
してそれを描写する。そのファイルを変更するには、フ
ァイル全体を読み出し、大小の変更を加え、再びそのフ
ァイルをファイル・システムに保存する必要がある。こ
のファイルが大きいと、読出し、編集および保存作業に
何分もかかる恐れがあり、実用的ではない。

【００８６】さらに、上記の例すべてに関して仮想環境
の構造が変わらない場合でも、その環境内の詳細な設定
はそのシーンをレンダリングするために使用するハード
ウェアやシーンの視聴者により変更される可能性がある
ことが分かる。再び図５（Ａ）および図５（Ｂ）につい
て説明する。恐らく、画像５００’をレンダリングする
ハードウェアに部分的に透明なテクスチャを表示する機
能が備わっていないためであろう、草５１４、５１６、
５１８および５２０が画像中５００’で表示されないこ
とが了解されるであろう。家５０４’は、たぶん画像５
００’をレンダリングするハードウェアが画像５００を
レンダリングしたハードウェアと毎秒同じ数のポリゴン
を描画する機能がないため細かく描画されていない。

【００８７】また、広告掲示板５２２’の表示画像が広
告掲示板５２２と異なるだけでなく、解像度もまったく
異なり、広告掲示板５２２に使用する画像と異なるフォ
ーマットで格納されるものと思われる。

【００８８】次に、図６（Ａ）、（Ｂ）、（Ｃ）を参照
する。これらの図は、仮想環境でレンガ模様を描くする
ために使用するようなテクスチャ・マップを使用してい
る。

【００８９】図６（Ａ）は、１０２４×１０２４ピクセ
ルの解像度で格納された高解像度レンガ画像である。ま
た、画像の色情報を示すために２４ビット／ピクセルを
使用して格納される。２４ビット／ピクセルにすること
により、画像の個々のピクセルについて、１６０万色以
上の表現が可能となり、ほとんど例外なく、それ以下の
ビット／ピクセルのものより優れた絵が描かれる。ピク
セルの色は、固有の方法でハードディスクのような非揮
発性記憶装置に格納し、プログラムがそれらを使用でき
るようにする必要がある。一般の記憶形式は、ポータブ
ル・ネットワーク・グラフィックスはＰＮＧ、タグ付き
画像ファイル形式はＴＩＦＦ、画像圧縮形式はＪＰＥＧ
とそれぞれ言う。その他、ＴＡＲＧＡ、ＧＩＦ、ＰＩＣ
などの形式もあるが、これらはそれぞれ後の使用のため
の画素情報を格納する固有の方法をいう。

【００９０】上記の各形式はそれぞれ異なる機能をも
つ。たとえば、ＧＩＦ形式の場合は、画像データを損失
なく圧縮できるが、８ビット／ピクセルで最高２５６色
しか格納できない。ＧＩＦ形式で格納された写真は、明
らかに画質が劣る。ただし、使用ディスク・スペースは
２４ビット画像よりはるかに少なくて済む。

【００９１】図６（Ａ）は、２４ビット／ピクセルでＴ
ＩＦＦ形式で格納された１０２４×１０２４ピクセル、
すなわち１，０４８，５７６ピクセルの画像である。こ
のような画像は、画像情報と画像を記述する補足データ
を格納するために１，７２０キロバイトのディスク・ス
ペースを消費する。ほとんどの画像が圧縮でき、ＰＮ
Ｇ、ＴＩＦＦ、ＪＰＥＧ、ＧＩＦ等のファイル形式は損
失の大小の差はあるが圧縮できる。

【００９２】図６（Ｂ）は、８ビット／ピクセルすなわ
ち２５６色でＧＩＦ形式を用いて格納された１２８×１
２８ピクセル画像、すなわち１６，３８４ピクセル画像
を示す。この画像は、画像およびカラー・マップに関す
る補足データを含み、約８キロバイトのディスク・スペ
ースを消費する。

【００９３】図６（Ｃ）は、ＧＩＦ形式による３２×３
２ピクセルのさらに解像度の低い画像を示す。この画像
は、約２キロバイトしかディスク・スペースを消費しな
いが、他の画像に比べて明らかに質が劣る。

【００９４】これらの画像はみな、仮想環境シーンをレ
ンダリングするソフトウェアおよびハードウェアがこれ
らの画像フォーマットを読み出して解釈できるなら、仮
想環境でテクスチャ・マップとして使用できる。残念な
がら、特定のレンダリング用ソフトウェアは使用できる
ファイル形式と解像度が限定されていて、あらゆるレン
ダリング用ソフトウェアで共通に使用できる業界の標準
はない。たとえば、ハイエンドのＳＧＩ社製ソフトウェ
アは、ＸとＹの解像度が２の累乗であるテクスチャ・マ
ップを使用する。パーソナル・コンピュータを使用する
レンダリング・マシンは、解像度１２８×１２８ピクセ
ルの２乗のテクスチャしか使用できない。あるレンダリ
ング・マシンは、ＧＩＦ、ＰＮＧおよびＪＰＥＧファイ
ルを読み込むが、他はＲＧＢという特殊なＳＧＩ形式も
読む。ＰＮＧとＪＰＥＧしか使用しないものもあれば、
ＧＩＦ形式だけを使用するものもある。これらの違いに
より、どのプラットフォームでも実行できる単一の仮想
環境を作成することは難しい。

【００９５】さらに、ネットワーク接続で仮想環境をリ
モートで見る場合、数メガバイトのテクスチャ・マップ
を含むシーンはダウンロードに長時間かかる状況も考え
る必要がある。たとえば、図６（Ａ）の非圧縮画像は現
行の業界標準である２８．８キロバイト／秒のモデムで
送信するのに１０分近くかかる。図６（Ｂ）の画像の場
合はたった約３秒で済む。仮想環境に３０個だけ画像が
含まれるとして、それらを２８．８キロバイト／秒でダ
ウンロードする場合、中解像度画像は１分半ほどですべ
てをダウンロードできるが、高解像度画像の場合は約５
時間もかかる。

【００９６】ウェブの代わりにＣＤ−ＲＯＭを使用する
コンピュータ用にこの仮想現実環境を開発し、ハードウ
ェアに３０１．７メガバイトのテクスチャを示す機能が
あるとすると、そのＣＤ−ＲＯＭを使用する仮想環境
は、モデムを使用するパーソナル・コンピュータの表示
する仮想環境より明らかに優れたものになるだろう。

【００９７】さまざまな解像度およびファイル形式の画
像を、その仮想環境の構造全体が変わらなくても、種々
の状況で配布できると有利であることは明らかであろ
う。

【００９８】図７（Ａ）を参照すると、この図は、風景
７０２、家７０４、木７０６および雲７０８を含む仮想
環境のシーンを示す。図７Ｂは、風景、家、木および雲
を表すモデルおよびテクスチャを含むファイル・システ
ムのリストを示す。

【００９９】図７（Ａ）に示されたような一般的な仮想
環境では、風景７０２、家７０４、木７０６および雲７
０８を含む仮想環境のコンテンツは、図７Ｃに示した一
つの大型ファイルか、図７Ｂに示した数個の大型ファイ
ルに格納される。ＬＡＮＤＳＣＡＰＥ．ＰＬＹ７１０の
ようなファイルは、仮想環境のレンダリングされたビュ
ーに示される面を描くための辺と頂点で構成されるポリ
ゴンの一覧表を含む。また、ハードウェアによりレンダ
リングするときに彩色する各ポリゴンまたは頂点の色の
一覧表も含む。その他、このファイルはそれらのポリゴ
ンに使用するテクスチャのリストを含むが、テクスチャ
自体をそのポリゴンの一覧表と共にファイルに格納する
ことはめったにない。

【０１００】図７（Ｂ）は、図７（Ａ）に示されたビュ
ーを作成またはレンダリングする際に使用されるすべて
のファイルを示すディレクトリを含む。“Textures”７
１２と題するディレクトリは、実際は図７（Ａ）のシー
ンのレンダリングに用いるすべてのテクスチャ・マップ
用ファイルを含むサブディレクトリであり、少なくとも
草、屋根の素材、森、雲、木立および舗装道路の画像を
含む。前に示したように、これらの各テクスチャ・ファ
イルの容量は、解像度とビット・デプスにより１６キロ
バイトから３メガバイトの間である。

【０１０１】代わって、図７（Ｃ）は、ポリゴンとその
テクスチャ・マップを除く関連情報のすべてをＡＬＬ．
ＰＬＹ７１４という１つの大型ファイルに格納する別の
方法を示す。１つの大型ファイルを使用することは、仮
想環境の設計者またはオーサが図７Ｂに示した場合のよ
うにたくさんのファイルを処理する必要がないため、仮
想環境のレンダリングに使用するデータを送信するのに
便利な場合がある。ただし、仮想環境のどのような小さ
な部分を変更をするときでも、ＡＬＬ．ＰＬＹ７１４を
読み出し、たとえば木を少し左にずらすなど所定の変更
を加え、さらにＡＬＬ．ＰＬＹファイル全体を保存しな
おす必要がある。この場合、変更されたのは４メガバイ
ト以上もあるファイルのうちのせいぜい１２バイト程度
であり、このように些細な変更を加えるときでさえ、フ
ァイル全体を読み出し、書込みを行わなければならなく
て面倒である。すべてのポリゴンをまとめて１つのファ
イルに格納した場合のほうが明らかに処理が楽である。

【０１０２】さらに、仮想環境の先行バージョンを保存
して変更を追跡する必要がある場合、ファイル全体の第
二コピーを保存する必要があり、１回１２バイトの変更
をするために４メガバイト以上のディスク・スペースを
余計に費やすことになる。

【０１０３】この極端な例を挙げて説明する。仮想環境
のすべての要素を図７（Ｂ）に示した状況と類似した、
１ファイル１オブジェクトのそれぞれより小さいファイ
ルに保存するが、その仮想環境がはるかに一般的および
複雑なものであると仮定する。ファイル数が増えると、
適当なファイル名を付けて、どのオブジェクトがどのフ
ァイルに格納されたか追跡することがかなり難しくな
る。小さな変更を加える場合、オブジェクトごとにファ
イルを変えて格納すると時間が節約できて便利ではある
が、多数の細かいファイルを管理しなければならず、ど
うしようもなく厄介である。また、ファイル・システム
の中で仮想環境のクリエータが利用できる補足情報のフ
ァイルだけは、作成時と同じ大きさである。ファイルに
格納されたモデルの空間範囲のような有用な情報は一般
にモデルの境界枠と呼ばれるが、それらは直接利用する
ことはできず、１つのファイルに関してその情報を得る
には、そのファイルをメモリに読み込み、分析する必要
がある。

【０１０４】再び図６を参照すると、たとえばハイエン
ドのレンダリング用ハードウェアで扱うポリゴン数の多
いモデルやローエンドのパーソナル・コンピュータで扱
うポリゴン数の少ないモデルなど、さまざまな状況に対
応できる２つのバージョンのモデルを保持する必要があ
る場合は、仮想環境関連フィールドをすべて含むディレ
クトリ内でやや自由な命名方式を考案するか、またはデ
ィレクトリの構造全体を複製し、ポリゴン数の多い各フ
ァイルをポリゴン数の少ないコンパニオン・ファイルに
置き換えることが必要となる。ポリゴン数の多いモデル
とポリゴン数の少ない対応モデルをもつモデルがほんの
少ししかない場合、このような方法で余分に使用される
ディスク・スペースは驚異的かつ法外となる可能性があ
る。

【０１０５】また、これらのファイルとディレクトリの
管理は、手作業またはプログラムを使用して行う必要が
あることが了解されるであろう。手作業によるファイル
の管理は時間がかかり、間違いの生じる可能性がある。
一方、プログラムでファイルを管理するには、プログラ
マの専門技術を必要とする。魅力的で美しい仮想環境を
構築できる専門技術を持つ１人の人が、仮想環境を格納
するファイルやディレクトリの管理用スクリプトを書き
込むプログラミング技術を兼ね備えていることは非常に
稀である。

【０１０６】繰り返し説明する。仮想環境のオブジェク
トに対し個人または集団でアクセスできるようにするこ
とは有益なことである。たとえば、仮想環境を表示また
は伝送する際など、一度に仮想環境全体にアクセスでき
ると便利な場合があり、また、たとえば仮想環境を変更
する場合など、一回に仮想環境の１つのオブジェクトを
選択してアクセスできると便利な場合がある。したがっ
て、仮想環境オブジェクトを管理するためにファイル・
システムを使用することが不便で面倒であることは明ら
かであろう。

【０１０７】次に、図８を参照すると、テーブル８００
の上にティーポット８０２、円錐体８０４、立方体８０
６が載っている。テーブルには四本の脚８０８、８１
０、８１２、８１４があり、テーブルに密着している。
この画像を示した目的は、仮想環境の一般の格納方法お
よび要件を示すことにある。この特別の仮想環境は、規
模は非常に小さいが適例である。テーブル８００は、木
目のように描かれたテクスチャ・マップで「質感」が描
出されているため、木でできているような外見をしてい
る。このテクスチャ・マップを格納するファイルはＪＰ
ＥＧ形式であり、９６キロバイトのディスク・スペース
を使用する。画面の判読可能な記述であるＶＲＭＬ形式
の記述を含むファイルの大きさは約３２キロバイトであ
る。ＶＲＭＬはバーチャル・リアリティ・モデリング・
ランゲージを意味し、仮想環境を記述するためのプラッ
トフォーム間の共通使用言語として開発されたものであ
る。

【０１０８】図９は、図８に示した仮想環境シーンのＶ
ＲＭＬ形式による簡略リスト出力である。このリストを
短くするために、頂点、色、法線を記述するデータが
“−−−−−DATA GOES HERE−−−−−”という語に
置き換えられている。テーブル８００、ティーポット８
０２、円錐体８０４、立方体８０６および４本の脚８０
８、８１０、８１２ならびに８１４がすべてそのファイ
ルに記述されていることに注目する。また、シーンをレ
ンダリングするために使用されるカメラの位置などの属
性の記述をはじめ、シーンに関する総合的な情報もファ
イルに入れる。

【０１０９】次に、テーブル８００を定義するデータの
リスト出力である図１０を参照すると、数字の複数の一
覧表がポリゴンに使用する頂点の位置を示す。また、法
線、テクスチャの座標および各ポリゴンで使用する頂点
を示すインデックスも示すが、この補足情報はテーブル
の完全なレンダリングを作成する際に使用する。各数字
のまとまりが何を意味するかをここで詳しく説明するこ
とは必ずしも必要ではない。なぜなら、３次元グラフィ
ックスの技術およびレンダリングに精通している人は、
用語や各数字または数字の集合の意味を熟知していると
思われるからである。さらに、ＶＲＭＬ２．０の参考資
料を読めば、このファイルの各エントリの意味を明確に
知ることができる。ＶＲＭＬ２．０の参考資料は、イン
ターネットを通じてＶＲＭＬコンソーシアムから入手で
きる。

【０１１０】次は、図１１を参照すると、この図は１つ
の大型仮想環境の完全な画像を構築するために必要な種
々の情報を格納する位置を示す。たとえば、ファイル名
が拡張子．ＰＬＹで終わるモデル用ファイルを示す欄１
１０２がある。欄１１０４のファイルは、画像の格納フ
ォーマットに正確に応じて拡張子が例に示したように変
わる一例の画像ファイルである。欄１１０６のファイル
は、この例ではファイル名拡張子を．ＡＮＩとする、動
画情報を含むファイルである。これらの情報はすべて何
らかの方法で仮想環境で使用される。しかし、その情報
の組成、すなわち構築方法、表示方法および使用法は、
一般に、雲１１０８の場合のような実行プログラムに格
納される。このプログラムは、普通、ＣまたはＣ＋＋で
書かれ、個々のマシンの型に合わせて実行可能プログラ
ムにコンパイルされる。

【０１１１】ここで例を示す。アドレス帳作成プログラ
ムを開発するものと仮定する。１つの方法として考えら
れるのは、プログラマがＣコードに当アドレス帳プログ
ラムに載せる各人の名前と住所をその上に書き込む方法
である。名前を追加または削除する必要がでてきた場
合、プログラマは、ソース・ファイルを再びオープン
し、その名前と住所を入力または削除した後、そのプロ
グラムを再コンパイルする必要がある。これは非常に手
間のかかるアドレス帳作成プログラムの開発方法である
が、現在仮想環境で行っていることと非常によく通じる
ものがある。便利なアドレス帳作成プログラムは、フィ
ールドまたは部分の個々の集合に複数の行または集合の
情報を格納するデータベースを使用して構築できる。デ
ータベースを使用すると、名前の追加および削除はほと
んど取るに足りない作業となり、変更がたいへん楽にな
る。

【０１１２】この発明は、これに類似した仮想環境の構
築方法を説明する。仮想環境の構造とコンテンツを定義
するための場所を確保したデータベースの構造を開発し
た。データベースの各行または各部分に情報を入力する
ことにより、仮想環境を完全に定義することができるほ
か、モデル１１０２、テクスチャ・マップ１１０４、動
画情報１１０６および構造１１０８をどれも一ヶ所に格
納できる。データを変更すると、再コンパイルしなくて
もコンピュータの画面への仮想環境の表示方法を変更で
きる。

【０１１３】以下に記述するように、仮想環境はもはや
単一ファイルや複数の大型ファイル、すなわち管理能力
を上回るような多数の小さいファイルに格納する必要が
ない。ファイル・システムは仮想環境の情報を格納する
最善の場所ではないがこれまで使用されてきた。それ
は、そのシステムがどのコンピュータでも自由に使え、
曲がりなりにも簡単とはいかないまでも仮想環境情報の
格納および検索というジョブの一部を実行できるよう適
応可能であったためである。

【０１１４】図１２は、仮想環境のデータと構造を共に
１つのデータベースに格納できるデータベース設計また
は「スキーマ」の例を示す。データをすべて一ヶ所に格
納する場合でも、データベースを使用すると、情報の細
分化された各部分を編集または表示するために同時に照
会または取り出しが可能になる。さらに、図１２に示す
スキーマを使用すると、データベースを走査し、ファイ
ルを構築するだけで、ＶＲＭＬフォーマットを使用し
て、１つのファイルに格納されたテクスチャ・マップ以
外の仮想環境全体を取り出すことができる。テクスチャ
・マップは、さらに、ＶＲＭＬを使用して別に検索する
必要がある。

【０１１５】Rocale Info テーブル１２００は、個別に
見ることができるが通常はすべての隣接ローカルと同時
に見ることのできる仮想環境の一部分として定義される
“ローカル”に関する情報を含む。ローカルは、１９９
６年１１月発行のJohn Barrus・Richard Waters 共著に
よる『ＩＥＥＥコンピュータグラフィックスおよびアプ
リケーション』の中の「ローカル：大型マルチユーザ仮
想環境のサポート」という題名の論文に詳しく定義およ
び解説されている。

【０１１６】Locale Neighborsテーブル１２０２は仮想
環境の設計者が大型の継ぎ目のない仮想環境を作成でき
るローカル間の関係を定義するものである。上記２つの
テーブルは、通常、実行可能プログラム１１０８に直接
格納される仮想環境の構造に関係する。

【０１１７】Composition Listテーブル１２０４は、所
定のローカルのすべての構成要素の一覧表を含む。構成
要素は、１つのオブジェクトまたはパーツもしくはパー
ツの階層で構成される。Composition Listテーブル１２
０４、Node List テーブル１２０６およびParts Listテ
ーブル１２０８の組み合わせは、１つのローカルのシー
ンにあるオブジェクトまたはパーツの階層を定義する。

【０１１８】Parts テーブル１２１０は、１つのオブジ
ェクトまたはパーツに関する情報を含む。各パーツは、
Primitivesテーブル１２１４に格納された１つ以上のプ
リミティブで構成される。プリミティブは、ポリゴンの
オーディオ・ファイルまたは一覧表である。Texture テ
ーブル１２１６は、テクスチャ・マップに関する情報を
含む。画像そのものを含む可能性もあるが、画像は使用
データベースにより外部の位置に格納することもある。

【０１１９】テーブル１２１８は、各パーツのクリエー
タについて、オーサ名、Parts ListとAuthor Info を結
び付けるためのＩＤ番号、オーサの所属集団およびその
オーサがスーパバイザであるかどうかなどの情報を含
む。

【０１２０】このデータベース構造を使用すると、一ヶ
所に大型仮想環境に関するすべての情報を格納すること
が可能になり、現行の技術状況に次のような改善がもた
らされる。すなわち、必要に応じて仮想環境の一部また
は全体を要求する機能、他のオブジェクトに影響を与え
ず１つのオブジェクトを編集するためのロック機能、プ
ログラミングまたはプログラムのコンパイルをしないで
仮想環境の構造を変更できる機能および視聴者や表示環
境などの状況に応じて仮想環境で使用される実際のデー
タを変更する機能などが実現される。このスキーマでは
明確に示していないが、特定のオーサおよび視聴者だけ
に仮想環境との対話を制限または許可するセキュリティ
機能を提供することもできる。

【０１２１】図１３から図２５は、仮想環境をデータベ
ースに導入する方法の１つの例を説明したものであるこ
とが了解されるであろう。この例は、Microsoft Corp．
（本社 Seattle，Washington DC）のMicrosoft Access
という一般的なデータベースを使用する。Microsoft Ac
cessはリレーショナル・データベースであり、リンクテ
ーブルに情報を格納する。これは情報を格納する１つの
方法ではあるが、オブジェクト指向型やオブジェクト・
リレーショナル型など、他にもいろいろな種類のデータ
ベースが使用可能で、仮想環境の格納基盤として状況に
より効率がまったく同じであったり、優れていたりす
る。以下、各テーブルとその使用法を説明する。

【０１２２】次に、図１３を参照すると、この図は、Lo
cale Info というテーブル１３００を示す。テーブル１
３００は、各ローカルについて、判読可能な名前１３０
４、ＩＤ番号１３０６、ローカル内の地形の高さを表す
数字１３０８、当ローカルについての注釈１３１０など
の簡単な記述を含む。ローカルには任意の名前を付ける
ことができる上、それらは一意である必要はない。ただ
し、ローカルＩＤは、１つのデータベース内では一意と
する。高さ情報１３０８は、オブジェクトが当ローカル
の地面を表すどのポリゴンよりも、この例では、３メー
トル以上高い場合、そのオブジェクトをそのローカル外
のものとみなすことを示すために使用する。これによ
り、均一なポリゴンを使用して、各ポリゴンに高さを加
えるだけで３次元のボリュームを表すことができる。ロ
ーカルという概念に精通している人は皆、隣接ローカル
間のずれを確定するために、ローカルの内側を表す３次
元ボリュームを定義する必要のあることを知っているで
あろう。

【０１２３】一般のデータベースは多数のローカルを格
納することに注意する。前述のローカルに関する論文で
紹介されたアプリケーションであるダイヤモンド・パー
クには、５つの大ローカルとそれらの接点または接続経
路の働きをする多数の小ローカルを含め、６０個以上の
ローカルがある。つまり、一般的なLocale Info表は一
意のＩＤの付くローカルを１００個以上含む。

【０１２４】図１３の二番めのテーブル１３０２は、デ
ータベースの全ローカル内の構成要素の一覧表である。
もちろん、この場合はローカルが１つのため、そのロー
カルＩＤ１３１２は、あらゆる構成要素に共通である。
このComposition Listテーブルは、構成要素の一番上の
階層だけを示す。ローカルに子をもつ構成要素がある場
合は、当階層のルートだけをこのテーブルで示し、子は
別のテーブルに示す。

【０１２５】図８において、テーブル８００、ティーポ
ット８０２、立方体８０６および円錐体８０４が示され
る。テーブルの脚８０８、８１０、８１２および８１４
は、すべてテーブル面８００の子であり、よってCompos
ition Listテーブル１３０２には示さない。Compositio
n Listテーブル１３０２は、大バージョン番号１３１６
と小バージョン番号１３１４も含む。

【０１２６】現在、ある特定の期間にわたり、コンピュ
ータのプログラマは累積的に作業して、ＲＣＳ修正制御
システム、またはＳＣＣＳソース・コード制御システム
などのプログラムを使用して現在および過去の制作品を
どちらも保存することが可能である。これらの各システ
ムにより、プログラマはコードの断片を「チェックアウ
ト」し、修正した後、同一コードを「チェックイン」す
ることができる。チェックインする時、新しいソース・
コードをチェックアウト・コピーと比較し、差異を検出
する。これらの差異にはバージョン番号を付け、現在の
ソース・コードと共に格納する。このシステムの利点
は、ある人が変更をしたが、うまくいかず、使用中のソ
フトウェアの動作を停止させた場合、持ち込まれた問題
点を見つけるまで先行バージョンのソフトウェアに戻る
ことができる点である。

【０１２７】類似した機能が、コンテンツのクリエータ
と３次元のオーサにとって非常に役立つ。たとえば、濃
く明るい色で仮想環境を作成し、それを淡くやわらかな
色調の環境に変更する場合、変換にかなりの時間がかか
り、元の色調に戻すのも容易ではない。所定のバージョ
ン制御機能であれば元の明るい色の環境に戻すことがで
きる。同じ例を色の編集だけでなくモデルとテクスチャ
の変更にも簡単に適用できる。

【０１２８】Composition Listテーブル１３０２の大バ
ージョン番号１３１４と小バージョン番号１３１６があ
ることにより、コンテンツのクリエータは初歩的なバー
ジョン制御方式を使用できる。普通、データベースから
環境を取り出して表示するとき、各構成要素、パーツお
よびプリミティブのすべての最新バージョンを取り出
す。ただし、ユーザの要求に応じて先行バージョンも取
り出して表示できる。事実、パーツの全バージョンを取
り出して、それらを並べて表示することにより、パーツ
の変更を順を追って概観できる。表（１３０２）の他の
欄については改めて説明するまでもないであろう。

【０１２９】図１４を参照すると、この図は、わかりや
すくするために前図のCompositionListテーブル１４０
０を含む。Node List テーブル１４０２は、ルート・ノ
ードがComposition Listテーブル１４００に示されてい
る階層の内部構造を含む。構成要素ＩＤ０１４０６およ
び１４０８は、図８のテーブルの天板８００を表すが、
これだけは子をもつため、その構成要素ＩＤはNode Lis
t テーブル１４０２全体の中で一貫している。テーブル
の天板８００は、Node List テーブル１４０２に示した
４つの子をもつ。子ＩＤ１４１０も、Parts Listテーブ
ル１４０４で使用する構成要素ＩＤであり、そのためテ
ーブル１４００またはテーブル１４０４の別の構成要素
ＩＤとの重複は許されない。

【０１３０】Pos X１４１２、Pos Y１４１４、Pos Z１
４１６という欄があることに注意する。これらの欄は、
それらの親構成要素に関するローカルでの各パーツの位
置を記述する。Pos Zの後に続くｑ１、ｑ２、ｑ３、ｑ
４、Scale X、Scale YおよびScale Z１４１８を含む欄
は、すべてこのテーブル１４０２の記述する階層で使用
するときのパーツの方向と相対的なスケールを記述す
る。

【０１３１】Jim Foley 他の共著による「コンピュータ
グラフィックス：原理と実際」という題名の書物の２１
３ページから２２６ページにかけて、３次元形状の変換
とそれらを使用した画面上でのオブジェクトの移動およ
び拡大・縮小方法についての解説がある。多くの３次元
オブジェクトは、それらが最初に構築された時に、ロー
カル座標系の中心を軸に設計される。たとえば、球は中
心点と半径を定めることにより最も簡単に定義される。
普通は、その中心点をローカル座標系の原点（０、０、
０）とみなす。その球を仮想環境で使用するとき、仮想
環境の原点から数メートル離れた所を中心とする円周に
１０個の球のコピーを置くことが望ましい。その場合、
Foley らの説明にあるように、仮想環境のそれぞれ適正
な位置にこれらの球を移動させる一連の変換、すなわち
置換、方向転換およびスケーリングを表す４×４マトリ
ックスを定義できる。

【０１３２】変換はマトリックスで格納されることもあ
る。また、それらの構成要素であるパーツごとにｘ、
ｙ、ｚ位置の置換、回転およびｘ、ｙ、ｚ方向のスケー
リングなどの変換を格納すると便利なこともある。この
例では、後者を含むデータベースを示すが、このデータ
ベースに構成要素の代わりにマトリックスを格納するの
は造作ないことだろう。もちろん、使用対象を示すフラ
グと共に構成要素とマトリックスの両方を格納すること
は可能であるし、望ましい場合もある。この例では、位
置の変更が見やすいように構成要素のパーツを示した。

【０１３３】テーブル１４０４は変換情報を示す。これ
らの変換情報は、仮想環境およびお互いを基準にパーツ
を移動するために使用する。動画は、シーンが何度も描
き換えられて、変換情報を変更できる。Ｘ座標の値の増
減を繰り返して描画された球は、仮想環境のＸ軸を上下
するように見える。ただし、球の静止位置はデータベー
スに格納し、誰かがその仮想環境を自身のコンピュータ
にロードしてそれを表示したときに、元の位置でその球
を見ることができるようにする必要がある。

【０１３４】変換は、現行の座標系を基準に指定する。
たとえば、オブジェクトがローカルの座標系にあり、変
換を適用するとき、当オブジェクトはそのローカルの座
標系の新しい位置に移動する。オブジェクトが恒等変
換、つまり変位ゼロ、スケーリング１、回転ゼロに等し
い変換でローカルの座標系にある場合、そのオブジェク
トの座標系の原点はローカルの座標系の原点と完全に一
致する。オブジェクトが親オブジェクトの子である場合
に恒等変換すると、そのオブジェクトの座標系は親オブ
ジェクトがローカルの座標系を基準にどのように変換さ
れたとしても、親オブジェクトの座標系に合わせて位置
づけされる。この方法で行われる変換は、グラフィック
ス業界では周知のものであり、コンピュータによる３次
元モデルの設計およびレンダリング技術に熟練した人た
ちが広く利用している。

【０１３５】図１５は、図８の簡単な仮想環境例の階層
を示す。この階層も、図１４に示されたようなデータベ
ースの中のデータ、テーブル１４００、１４０２および
１４０４に対応する。たとえば、テーブル１４００は、
Locale O １５００に含まれる構成要素が行１４２４で
示された円錐体１５０２であり、行で示された１４２６
の立方体１５０４であり、行１４２２で示されたティー
ポット１５０６であり、行１４２０で示されたテーブル
の天板１５０８であることを示す。テーブルの脚はシー
ンの階層の最上位にないためテーブル１４００に入って
いないことに注意する。次に、図１４のテーブル１４０
２を見ると、行１４２８で示された、図１５でもオブジ
ェクト１５１０、１５１２、１５１４および１５１６と
して示された脚１から４は、行１４２０で示されたテー
ブルの天板構造要素１５０８の子オブジェクトである。

【０１３６】構成要素の各パーツに関する変換は、それ
らの構成要素のノードを個々のパーツと関連付けるPart
s Listテーブル１４０４に格納する。残りの図で分かる
ように、各脚は実際にはテーブルの天板１４２０および
１５０８の座標系の原点を基準にして異なる位置に描か
れる。変位は、列１４１２、１４１４および１４１６に
示す。

【０１３７】次に図１６を参照すると、Parts Listテー
ブル１６００は、構成要素のノードと個々のパーツ間の
関係を含む。Parts テーブル１６０２にあるように、パ
ーツごとにバージョン情報、欄１６０６とオーサ情報、
欄１６０８、欄１６１０の最初の作成日および最終の修
正日を記録する。さらに、各パーツは、Primitive テー
ブル１６０４のプリミティブとも関連している。この関
連付けは欄１６１２に記録する。各表の関係を記述する
この方法は、リレーショナル・データベースにおける基
本概念の１つであり、データベースの開発および普及技
術に熟練した人は皆、そのようなものとして認識するで
あろう。

【０１３８】前に戻り、図１２を参照すると、この図で
は、すべてのテーブルの関係を含め、データベースの全
体構造を見ることができる。

【０１３９】Primitivesテーブル１６０４は、例示した
仮想環境で使用されるオブジェクトまたはプリミティブ
の一覧表を含む。Partsテーブル１６０２にはテーブル
の脚を示す４つの異なるパート、つまり、行１６１４
が、それらの脚はすべて、Primitivesテーブル１６０４
に格納した同じ３次元情報１６１６を使用して描かれ
る。行１６１６を見ると、Partsテーブル１６０２との
つながりを示すプリミティブＩＤ欄１６１８があり、３
次元オブジェクトの種類を示すプリミティブの種類欄１
６２０があることが分かる。データを２進表現の大型オ
ブジェクト、すなわちＢＬＯＢとして直接データベース
に格納しないときにデータファイル名を保持する欄１６
２２がある。データがデータベースの欄１６２４にある
場合、欄１６２２にあるファイル名は余分なものにな
る。フォーマット欄１６２６は、ファイルまたはデータ
欄１６２４に格納されたデータの解釈を示す。

【０１４０】言語欄１６２８は、さらに細かい記述を必
要とする。一般に、図５（Ａ）と（Ｂ）に示したよう
な、仮想環境で広告掲示板または宣伝文句を表すために
使用するテクスチャ・マップは、固有の言語で書かれた
テキストを含む。３次元バージョンの記号を構築して言
語記号の形状を作成することもできる。たとえば、大文
字の「Ｔ」を、英字の形状に含まれるポリゴンを使用し
て作成し、さらにデプスをつけるために押出しができ
る。この環境の日本語または中国語バージョンでは、ロ
ーマ字「Ｉ］の代わりに自分を意味する漢字記号を作成
して使用する場合がある。オブジェクトまたはテクスチ
ャ・マップにより表わされる言語を指定することによ
り、データベース全体を置き換えなくても別の国の言語
記号を作成して補足できる。

【０１４１】たとえば、日本で仮想環境を表示する際、
データベース・エンジンはそのデータベースから情報を
取り出す際、Primitive テーブル１６０４まで関係をた
どっていく。プリミティブＩＤ欄１６１８で適正なプリ
ミティブＩＤをもつプリミティブを見つけると、言語欄
１６２８が「日本語」かどうかをチェックする。「日本
語」でない場合は、ＩＤが同じで言語が「日本語」のプ
リミティブを検索しつづける。言語欄１６２８のアスタ
リスクは、そのプリミティブがどの言語でも使えること
を示し、言語欄でアスタリスクの付いた適正なプリミテ
ィブを見つけると、データベースエンジンはそのプリミ
ティブを要求者に配布する。

【０１４２】複数の国に配備される仮想環境を開発した
人には、言語でプリミティブを特徴づけ、必要なプリミ
ティブだけを修正できると便利であることは明らかであ
ろう。現行の方法は、ファイル・システムの別のディレ
クトリでデータベース全体を作成し直してから系統的に
言語固有ファイル、たとえばテクスチャ・マップ、オー
ディオまたはモデルなどを検索し、それらのファイルを
修正する。この方法は、ディスク・スペースを消耗する
だけでなく、それぞれの格納情報にわずかしか違いが認
められない２つの別々のディレクトリ間の整合性をオー
サが保とうとして、管理がとても面倒である。

【０１４３】Primitivesテーブル１６０４に格納された
その他の情報は、データ・ファイルまたはデータBLOB１
６２４から取り出すことができるが、便宜上、表の欄と
して格納される。一連の欄１６３４および１６３６は、
各モデルの大きさを示すためのもので、これらを使用し
て、魅力ある便利な方法でプリミティブの一覧表を照会
することができる。これら２つの欄の情報を使用する
と、ローカル内の特定のオブジェクトの半径５メートル
以内に位置するすべてのパーツを探すことができる。現
行の方法では、上記のような照会に対する回答を求める
前に、すべてのファイルをオープンするか、すべてのデ
ータBLOSをくまなく分析するかしなければならない。一
連の欄１６３４および１６３６の情報を使用すれば、フ
ァイルまたはBLOB全体を検索しなくてもパーツの一覧表
やデータを返すことができる。

【０１４４】次に、図１７を参照すると、欄１７０４
は、テーブル１７０２の含むオーサに関係する。この場
合も、リレーショナル・データベース業界で標準とされ
ているように、テーブル１７００の各行のオーサ情報す
べてを反復検索したり、間違った情報が紛れ込んで混乱
が生じる危険を侵したりする代わりに、オーサ情報をPa
rts テーブル１７００に格納する。便利なように、オー
サＩＤを実際にテーブル１７００に格納する場合でも、
欄１７０４にはオーサの名字が示される。

【０１４５】一般に、テーブル１７０２は、各オーサに
関するさらに多数の情報を含むが、この種のデータベー
スは、それを使用する企業ごとに要件が異なり、それに
応じてテーブル１７０２が編集されるものと予想される
ため、ここでこれ以上の情報を示す必要はない。

【０１４６】最後に、図１８に示すように、各プリミテ
ィブは、ゼロ以上のテクスチャと関連付けることができ
る。あるプリミティブは他のプリミティブの使用するテ
クスチャ・マップを使用し、あるプリミティブは１つ以
上のテクスチャ・マップを使用する。プリミティブとテ
クスチャ・マップのこの関係は、Texture Listテーブル
１８０２に格納する。この場合は、ＩＤ０のプリミティ
ブ１８０８とＩＤ０のテクスチャ・マップ１８１０だけ
が関係をもつ。テクスチャ・マップ１８１０はＩＤ０の
プリミティブに使用され、テーブルの天板が木材ででき
ているような質感を出す。

【０１４７】最初の黒く塗られた列にアスタリスクのつ
いた１８０６ような行は、すべて、新しい情報を追加す
るために確保された空の行である。行１８０６がプリミ
ティブＩＤ０とテクスチャＩＤ０間の関係を示すとして
も、これはデータベースの有効な行ではなく、データベ
ースにコミットされる前に編集する必要がある。

【０１４８】Texture テーブル１８０４には言語欄１８
１２があることに注意する。この欄は、Primitivesテー
ブル１８１４の言語欄と同じ方法で使用する。この発明
の精神に反することなく、ソートまたはフィルタリング
を目的とするプリミティブまたはテクスチャ・マップの
固有の属性を記述するその他の列を追加しても構わな
い。フォーマット欄１８１６も同様に使用する。

【０１４９】Texture テーブル１８０４に含まれるファ
イル１８２２およびデータ１８２０欄は、Primitivesテ
ーブル１８００のこれらに相当する欄１８２４および１
８２６とまったく同じであり、図１７のそれらの欄につ
いての説明がこの場合もあてはまる。

【０１５０】図１９は、図１８のプリミティブＩＤ３と
して使用する立方体のＶＲＭＬフォーマットの例であ
る。ファイル１９００には色および形状情報と頂点１９
０２および面１９０４のリストを示す。これらの情報も
表を補足し、記入することにより同一データベースで検
索および格納できるが、このように情報の細分化が進む
と良いことはあまり期待できそうになく、データベース
から情報を取り出す速度が確実に低下する。

【０１５１】上述し、図１２から図１８で例示したデー
タベース・フォーマットおよびスキーマは唯一の例であ
り、現在の最良の実現モードであることが了解されるで
あろう。仮想環境用データベースを改善するとき、デー
タベースに格納するフィールドの変更や一部のフィール
ドの追加または削除、あるいはそれらを必要に応じて他
の表に移動したりすることが可能であり、実際に行われ
ることが予想される。この種の情報を格納するためによ
り適していると思われるデータベースが他にもあること
も了解されるであろう。特に、Poet Software（本社：
カリフォルニア州San Mateo）のPoet、Versant Object
Technology，Inc（本社：カリフォルニア州Menlo Par
k）のVersant、Computer Associates（本社：カリフォ
ルニア州Alameda）のJasmineなどのオブジェクト指向デ
ータベースがそれである。オブジェクト指向データベー
スでは、格納方式が多少異なるほか、キャッシュへの格
納方式が非常に異なり、情報のアクセスおよび伝送方法
も異なる。それでも、オブジェクト指向データベースへ
の移行は、この発明の性質と目的に反しない。よって、
このこの発明の範囲に含まれるものである。

【０１５２】次に、図２０を参照すると、ブラウザとサ
ーバ間の情報の交換方法を示す流れ図を示す。ブラウザ
は、Silicon Graphics,Inc（本社：カリフォルニア州Mo
untain View）のCosmo Player というプラグインＶＲＭ
Ｌブラウザをはじめとする３次元情報要求プログラムで
ある。サーバは、通信プログラムとデータベースとを組
み合わせたものである。いろいろな２次元情報用サーバ
がある。たとえば、Netscape Communications（本社：
カリフォルニア州Mountain View）社製サーバなどであ
る。これらのサーバは、ワールド・ワイド・ウェブ（Ｗ
ＷＷ）で普及したＨＴＴＰプロトコルを使用して応答
し、データ・ストリームの形で情報を送信し、通常はフ
ァイルを使用するが、それらはＨＴＭＬコードおよびテ
キスト、ＧＩＦまたはＪＰＥＧ形式のグラフィック情報
を含むファイルまたは前述のような３次元情報を含むＶ
ＲＭＬファイルである。

【０１５３】２００２の枠で参照するサーバは、自身の
情報を図１２から図１８に示したデータベースから取り
出し、その情報を要求されたモデル・フォーマットの特
定のデータ・ストリームに変換し、２０００の枠で述べ
られるブラウザに返送する。

【０１５４】１つの実施例で、ブラウザは、サーバのデ
ータベースで記述された特定のローカルの３次元情報を
要求するサーバにメッセージを送信する。この要求は、
通常、インターネット・アドレス形式で要求元マシンの
アドレスとマシンの特性を含むが、それらは一般に「ク
ッキー」としてブラウザから送信される。「クッキー」
は、ブラウジング・コンピュータが格納し、データの要
求を受けてサーバに渡す小さいパケット情報である。２
０００の枠内で参照するブラウザが送信するクッキー
は、好ましいテクスチャ・マップのファイル形式の仕
様、マシンのグラフィック・ハードウェアの種類、３次
元環境の所望のフレーム転送速度などの関連情報を含
む。

【０１５５】サーバは、情報の要求を受信すると、デー
タベースで一連の検索またはデータ抽出を開始する（２
００２）。同じく２００２、サーバは、Locale Info テ
ーブル１２００を調べてローカルＩＤ番号を見つける。
このＩＤ番号を使用して、Composiotion List テーブル
１２０４からルート構成要素ノードの一覧表を取り出す
（２００４）。さらにサーバはテーブル１２０６および
１２０８を調べて仮想環境情報の取り出しを続け、仮想
環境の構造を構築するために階層とパーツＩＤを見つけ
る（２００６）。次に、Parts テーブル１２１０からプ
リミティブの一覧表を検索し、当ローカルで使用する形
状を探し出す。サーバはPrimitivesテーブル１２１４を
検索し、要求されたローカルのすべての３次元情報を表
す最終的なバッファまたはデータ・ストリームを構築す
るために必要な情報を取り出す（２００８）。そして、
その情報バッファが作成される（２０１０）。

【０１５６】サーバは、テクスチャ・マップ画像を除く
当ローカルに関する完全な情報を示すその情報バッファ
を取り出し、それをネットワークでブラウザに送信する
２０１２。それと並行して、ブラウザの次ステップとし
てＨＴＴＰやその他広く普及しているプロトコルを使用
するテクスチャ・マップの要求のあることを見越し、ロ
ーカルで使用するテクスチャ・マップの変換および検索
を開始する（２０１８）。

【０１５７】次に、図２１を参照すると、ブラウザから
テクスチャ・マップの要求が行われる間に考えられる１
つの情報の流れを表す流れ図を示す。１つの実施例で、
ブラウザはＨＴＴＰプロトコルを使用して特定のテクス
チャ・マップを要求する２１００。再び、ブラウザから
サーバにグラフィック・ハードウェアとその他の関連情
報を示すためにクッキーが送られる。この情報を使用し
て、サーバは、Texture テーブル１２１６全体の検索を
開始し、ブラウザから送信されたクッキーに含まれる
か、またはクッキーから派生するすべての属性に一致す
る適正なテクスチャＩＤの付いたテクスチャ・マップを
見つける（２１０２）。たとえば、ブラウザのユーザが
英語を話し、ソフトウェアが低解像度のＪＰＥＧ形式に
よる画像を必要とし、画像を二乗アスペクト比にするよ
うにブラウザが指定したとする。ブラウザは、他の属性
も指定できる。また、一部の属性を数種のフォーマット
の１つまたは任意の有効フォーマットで使用可能なもの
として指定することもできる。たとえば、個々のブラウ
ザでＪＰＥＧ、ＧＩＦ、ＴＩＦ、ＲＧＢや他のさまざま
な画像ファイル形式の１つを受信することができ、他の
属性に一致する最初のテクスチャ・マップが応答時に送
信されるとする。

【０１５８】正確に一致するテクスチャ・マップが見つ
かると、サーバは、直ちに２１０８のステップを実行し
てそのテクスチャ・マップのデータをブラウザに送信す
る（２１０８）。正確に一致するものを提供できない場
合はTexture テーブル１２１６を調べ、それに近いもの
を探す。テクスチャＩＤが同じだが、他の属性の一部が
ブラウザの要求する属性と完全に一致しないテクスチャ
・マップが類似テクスチャ・マップとして定義される。
ある特定の規則を使用して最も良く一致したものを求め
る方法はあるが、１つの実施例では、類似テクスチャ・
マップはすべて有効とみなすことができる。類似テクス
チャ・マップが見つかると、サーバは、テクスチャ・マ
ップの特定の属性を要求された属性に変換するコマンド
を含む幾つかのフォーマット変換表の１つを調べる（２
１０６）。たとえば、Handmade Software（本社：カリ
フォルニア州Fremont）のImage Alchemy というプログ
ラムは、異なるフォーマット、解像度、アスペクト比、
ビット・デプスやその他のさまざまな属性相互の変換が
できる。そのプログラムを使用してサーバは変換ステッ
プを実行できる２１０６。もちろん、変換の後、サーバ
は最終画像データをＨＴＴＰなどのプロトコルを使用し
てブラウザに送信する２１０８。

【０１５９】Syndesis Corp（本社：ウィスコンシン州J
efferson）のInter Changeなどのプログラムを使用し
て、モデルに対してフォーマット変換など同じような種
類の属性変換ができる。図２２は、Primitives テーブ
ル１２１０またはPartsテーブル１２１４に格納できる
モデル属性を示す。例として、言語、面数、頂点数など
の属性のみを示す。

【０１６０】テーブル１２１４のプリミティブがオーデ
ィオ・ファイルの場合、そのオーディオ・ファイルのサ
ンプル転送レート、ビット・デプス、長さなどいろいろ
な属性を格納する。これらは、どれもモデルのプリミテ
ィブに適用されない。データベースに格納する属性情報
の種類は、プリミティブの種類により異なる。

【０１６１】図２３（Ａ）、（Ｂ）および（Ｃ）は、３
つの異なる解像度で構成されたティーポットを示す。同
一のポットをで表しているが、低解像度のティーポット
２３０４は、高解像度バージョン２３００より描写が非
常におおまかである。しかし、どちらもティーポットと
認められ、そのようなものとして仮想環境に使用でき
る。技術者は、一般に、オブジェクトが仮想環境におい
て視聴者からはるか遠くにある場合、描くポリゴンの数
を減らすために、これらの図に示すように同じモデルに
ついて複数のバージョンを作成する。しかし、この発明
では、１０〜１５フレーム／秒の対話フレーム速度を維
持するために、解像度の異なる複数のモデルを各種グラ
フィックス・ハードウェア用に使用する。

【０１６２】図２４は、３種類の異なる現行のハードウ
ェア・プラットフォームを、１秒間に描画可能なポリゴ
ン数と当プラットフォームで使用可能なテクスチャ・マ
ップ用メモリ容量などのおよその性能数値と共に示す。
これらの各プラットフォームは、ここで説明する３次元
データベースにアクセスするために使用する。

【０１６３】図２５（Ａ）は、図２４に示したような複
数のハードウェア・プラットフォームに対して今日どの
ようにコンテンツの開発が行われているかを示す。一般
に、コンテンツのクリエータは、ここでマシンＡとして
示すハードウェア・プラットフォームを選択し、その１
つのプラットフォーム用にコンテンツを開発する。次
に、自身の開発用プラットフォームのファイル・システ
ムの別のディレクトリにそのコンテンツをすべて複写
し、ここでマシンＢと定義した２番目のハードウェア・
プラットフォーム用にそのコンテンツを編集し始める。
編集では、モデルのポリゴン数の増減、テクスチャ・マ
ップおよびオーディオ・ファイルの解像度またはフォー
マットなどの変更を行う。

【０１６４】ここで説明するシステムと図２５（Ｂ）に
示す開発手順を使用することにより、最初のコンテンツ
を開発した後、他のハードウェア・プラットフォームで
その仮想環境を表示できるようにするために、要求に応
じて幾つかのコンテンツを動的に変換し、ごくわずかな
コンテンツだけを手操作で修正するだけで済むようにな
る。

【０１６５】次に、図２６を参照すると、当仮想環境の
コンテンツまたは資産の管理を助けるという意味で、コ
ンテンツ・マネージャともいわれるサーバ２６００と交
信するブラウザ２６０２の場合にはＨＴＴＰ ウェブプ
ロトコルだけが有用であることが明らかであろう。監視
ツール２６０６および管理ツール２６０８は、他の状況
でデータベースを管理するために通常使用可能なツール
と理解されているが、ＨＴＴＰプロトコルを使用しな
い。その他、オーサリング・ツールは、ファイル・シス
テムかデータベースかに関係なく大容量の（extensiv
e）双方向データ通信が可能である。

【０１６６】以上、発明の幾つかの実施例とそれに対す
る幾つかの変更と変形例について説明したが、上記は単
なる例示的なものであり、限定的なものではないことが
当事者には明白に理解できるであろう。多数の変形例や
その他の実施例は通常の技術の１つの範囲内に存在し、
添付特許請求とそれに相当するものによってのみ限定さ
れるこの発明の範囲に含まれるものである。

【０１６７】

【発明の効果】以上のように、この発明によれば、複数
のオーサが共通の３次元環境の個々の部分を並行して作
業できるほか、各人に３次元環境の異なる部分へのアク
セス権を選択して与えることが可能となり、バージョン
制御が実現し、永続性などの変更を保存する機能が実現
し、スケーラビリティ、セキュリティおよびフォーマッ
ト制御機能が実現し、すべて他の部分に影響を与えず仮
想現実環境のさまざまな部分について作業ができる独立
性がもたらされる。また、データベースを使用すること
により、インデックスにより環境のさまざまな部分に速
やかにアクセスできるようになる。すなわち、仮想現実
環境を構築する情報をデータベースに格納し、他の部分
を変えずに必要な部分だけを作成、編集または配布する
ことができる。たとえば、ワイド・エリア・ネットワー
クなどの通信網で当該データベースにアクセスし、他の
レコードに関係なく必要なレコードだけを個別に更新す
ることができる。このように、仮想現実環境を変更する
ために関連ファイル全体を読み出し、格納する必要がな
い。さらに、配布先マシンの特性として、データベース
が読み出すバージョンを口述して、配布先マシンと互換
性のあるバージョンを提供できる。

【図面の簡単な説明】

【図１】 仮想環境の変更対象部分の選択を示す図であ
る。

【図２】 仮想環境の格納に使用するデータベースの使
用法を示すブロック図である。

【図３】 別々のローカルで別々に処理されるさまざま
なグラフィカル・オブジェクトを示す仮想現実画面の図
である。

【図４】 リレーショナル・プレイス・データベースの
種々の場所のローカルに含まれるグラフィカル・オブジ
ェクトの記憶域を示し、個々のローカルにアクセスする
ための対応するＶＲＭＬファイルを示す図である。

【図５】 風景、２つのビル、１軒の家および広告掲示
板の描かれた大型仮想環境の一部を示す仮想現実画面の
図である。

【図６】 同一画像を、高解像度および高ビット・デプ
スフォーマット、中解像度および中ビット・デプスフォ
ーマット、低解像度および低ビット・デプスフォーマッ
トでそれぞれ示す２つの異なる画像ファイルを示す図で
ある。

【図７】 風景、雲、木、道路、小道、家の描かれた仮
想環境画面、仮想環境の情報をファイルに格納すること
が可能なある方法を示すコンピュータ・ファイル・シス
テムのリスト、すべての情報が１つのファイルに含まれ
る仮想環境情報を格納できる別の方法を示すコンピュー
タ・ファイル・システムのリストをそれぞれ示す図であ
る。

【図８】 テーブルの上にティーポット、円錐体および
立方体が載っているテーブルを示す仮想現実画面の図で
ある。

【図９】 図８の画面をバーチャル・リアリティ・モデ
リング・ランゲージ（ＶＲＭＬ）ファイル形式を使用し
て示すことが可能なある方法を示すコンピュータによる
簡略出力リストを示す図である。

【図１０】 図８のテーブルの上にそこに示されていな
かった他の要素を載せた場合のデータを示すコンピュー
タによる簡略出力リストの図である。

【図１１】 仮想現実画面をコンピュータで表示するた
めに必要な各種の情報を、一般の先行技術の状況でそれ
らが格納される場所と共に示す図である。

【図１２】 仮想現実画面の構成とデータの両方を１つ
のデータベースに完全に格納する方法を示す図である。

【図１３】 図１２のデータベースに格納されたデータ
例を図８の画面に対応するデータで示した一連のテーブ
ルを示す図である。

【図１４】 図１２のデータベースに格納されたデータ
例を図８の画面に対応するデータで示した一連のテーブ
ルを示す図である。

【図１５】 図１４に示したデータベース例で格納され
ているオブジェクトの階層例の図である。

【図１６】 図１２のデータベースに格納されたデータ
例を図８の画面に対応するデータで示す一連のテーブル
を示す図である。

【図１７】 図１２のデータベースに格納されたデータ
例を図８の画面に対応するデータで示す一連のテーブル
を示す図である。

【図１８】 図１２のデータベースに格納されたデータ
例を図８の画面に対応するデータで示す一連のテーブル
を示す図である。

【図１９】 データベースにおける１つのプリミティブ
のデータ・ファイル例を図１５と図１７に示したプリミ
ティブのテーブルと共に示す図である。

【図２０】 データベースから情報を取り出す方法を示
す流れ図である。

【図２１】 ブラウザからテクスチャ・マップの要求を
受けたときにサーバが送信すべきテクスチャ・マップを
決定する方法を示す流れ図である。

【図２２】 ３次元データベースに格納されたモデルに
適用する属性を示す図である。

【図２３】 同一ティーポットを３種類の異なる解像度
で示した図である。

【図２４】 ３次元情報を表示できる各種ハードウェア
・プラットフォームの重要な特性の一部を示す図であ
る。

【図２５】 複数のプラットフォームで使用できるよう
にコンテンツを開発する２つの方法を並べて示した図で
ある。

【図２６】 本明細書で説明した発明の使用する要素の
一部とそれら相互の関連を示す図である。

【符号の説明】

１０ 端末装置、１２ 仮想現実シーン、１４ ディス
プレイ、１６ グラフィカルオブジェクト、１８ 枠、
２０ ３次元環境作成、２２ テクスチャとサウンド、
２４ プリミティブ、２６ 構成要素の集合とパーツの
階層、２８ ローカル、３０ データベース、３２ 複
数のオーサ、３４ アクセス、３６ バージョン制御、
３８ ハードウェア（要件）、４２ 変更の永続性、４
４ スケーラビリティ、４６ セキュリティ（許可）、
フォーマット、４８ ハードウェアに合わせて異なるフ
ォーマットに変換して出力を調整、５０ 単一プリミテ
ィブを編集、３１０ ローカルＡ、３１２ ローカル
Ｂ、７１０ ＬＡＮＤＳＣＡＰＥ．ＰＬＹ、７１２ Ｔ
ＥＸＴＵＲＥＳ、７１４ ＡＬＬ．ＰＬＹ ディレクト
リのリスト、２６００ コンテンツ・マネージャ・サー
バ、２６０２ ブラウザ、２６０４ プラットフォーム
・シミュレータ、２６０６ オーサリング・ツール、２
６０８ 監視ツール、２６１０ 管理ツール。

───────────────────────────────────────────────────── フロントページの続き (73)特許権者 597067574 201 ＢＲＯＡＤＷＡＹ， ＣＡＭＢＲ ＩＤＧＥ， ＭＡＳＳＡＣＨＵＳＥＴＴ Ｓ 02139， Ｕ．Ｓ．Ａ. (72)発明者 ジョン・バラス アメリカ合衆国、カリフォルニア州、メ ンロ・パーク、レキシントン・ドライブ 328 (72)発明者 ステファン・マッケオン アメリカ合衆国、カリフォルニア州、ロ ス・オルトス、チェスター・サークル 17 (72)発明者 イレーネ・ビー・スターンズ アメリカ合衆国、カリフォルニア州、ロ ス・オルトス、チェスター・サークル 17 (56)参考文献 特開 平10−40295（ＪＰ，Ａ) 特開 平６−195439（ＪＰ，Ａ) 特開 平10−301946（ＪＰ，Ａ) 特開 平９−282249（ＪＰ，Ａ) ＩＥＥＥ Ｃｏｍｐｕｔｅｒ Ｇｒａ ｐｈｉｃｓ ａｎｄ Ａｐｐｌｉｃａｔ ｉｏｎｓ、16［６］（Ｎｏｖｅｍｂｅｒ 1996）、（米）、Ｊｏｈｎ Ｗ．Ｂａ ｒｒｕｓ，Ｒｉｃｈａｒｄ Ｃ．Ｗａｔ ｅｒｓ，ａｎｄ Ｄａｖｉｄ Ｂ．Ａｎ ｄｅｒｓｏｎ、“Ｌｏｃａｌｅｓ：Ｓｕ ｐｐｏｒｔｉｎｇ Ｌａｒｇｅ Ｍｕｌ ｔｉｕｓｅｒ Ｖｉｒｔｕａｌ Ｅｎｖ ｉｒｏｎｍｅｎｔｓ”ｐ．50−57 (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06T 1/00 - 17/50 G06F 17/30

Claims (3)

(57)【特許請求の範囲】
1. 【請求項１】 データベースと、仮想現実環境を作成す
   る手段と、上記作成された仮想現実環境を上記データベ
   ースに格納する手段と、上記データベースにアクセス
   し、アクセスされたデータを配布する手段とを備え、 上記データベースはレコードを含み、上記仮想現実環境
   は異なるパーツに分割され、パーツ毎に個々のレコード
   に分けて格納され、それにより上記仮想現実環境は他の
   部分に影響を与えることなく作成、編集または配布でき
   るものとすると共に、上記パーツをローカルとし、 さらに、上記データベースに上記仮想現実環境の各種バ
   ージョンが格納されるものとし、 ネットワークと、 上記ネットワークに接続され、予め決められた構成をも
   つ配布先マシンとをさらに備え、 上記データベースにアクセスし、アクセスされたデータ
   を配布する手段は、上記予め決められた構成に互換性の
   ある上記データベースに格納された上記仮想現実環境の
   特定のバージョンだけを上記配布先マシンに伝送する ３
   次元仮想現実環境作成、編集および配布システム。
2. 【請求項２】 上記データベースをリレーショナル・デ
   ータベースとする請求項１記載の３次元仮想現実環境作
   成、編集および配布システム。
3. 【請求項３】 上記データベースの予め決めたられた部
   分だけにアクセスを許可する手段をさらに含む請求項１
   記載の３次元仮想現実環境作成、編集および配布システ
   ム。