(57)【特許請求の範囲】
【請求項１】
３次元仮想空間を表示する表示制御を行う表示制御装置であって、
前記３次元仮想空間を撮影する撮影手段を想定し、その撮影手段が前記３次元仮想空間を撮影することにより得られる画像を提供する提供手段と、
前記３次元仮想空間における自己を表す自己オブジェクトの視点と前記撮影手段の位置とが一致している状態の１人称モードと、一致していない状態の３人称モードとを切り替えるモード切替手段と、
前記３人称モードとされたときに、前記自己オブジェクトの視点にしたがって、前記撮影手段の位置を制御する制御手段と
を備え、
前記制御手段は、前記３人称モードの状態において、前記自己オブジェクトの視点が変化したとき、所定の遅延時間をおいて前記撮影手段の移動が開始されるように、変化後の前記自己オブジェクトの視点に基づいて、前記撮影手段の移動を制御する
ことを特徴とする表示制御装置。
【請求項２】
前記制御手段は、前記３人称モードとされたとき、前記自己オブジェクトの視点を通り、その視線と所定の仰角をなす直線上の点であって、前記自己オブジェクトの後方に、前記自己オブジェクトの視点から所定の距離だけ離れた点に、前記撮影手段を移動する
ことを特徴とする請求項１に記載の表示制御装置。
【請求項３】
前記所定の距離は、前記撮影手段が撮影を行うことにより得られる画像の幅が、前記自己オブジェクトの幅の所定数倍に一致するようになる距離である
ことを特徴とする請求項２に記載の表示制御装置。
【請求項４】
前記制御手段は、前記３人称モードの状態において、前記自己オブジェクトの移動が終了した後、前記撮影手段の移動が開始されるように前記撮影手段の移動を制御する
ことを特徴とする請求項１に記載の表示制御装置。
【請求項５】
前記制御手段は、前記自己オブジェクトが、前記撮影手段を基準として定められる範囲外に出ないように、前記撮影手段を移動させる
ことを特徴とする請求項１に記載の表示制御装置。
【請求項６】
前記制御手段は、前記自己オブジェクトが移動したときに、前記撮影手段が、前記自己オブジェクトを基準として定められる範囲外に出ないように、前記撮影手段の移動を開始させる
ことを特徴とする請求項１に記載の表示制御装置。
【請求項７】
３次元仮想空間を表示する表示制御を行う表示制御方法であって、
前記３次元仮想空間を撮影する撮影手段を想定し、その撮影手段が前記３次元仮想空間を撮影することにより得られる画像を提供する場合において、
前記３次元仮想空間における自己を表す自己オブジェクトの視点と前記撮影手段の位置とが一致している状態の１人称モードと、一致していない状態の３人称モードとが切り替え可能であり、
前記３人称モードとされたときに、前記自己オブジェクトの視点にしたがって、前記撮影手段の位置を制御し、
前記３人称モードの状態において、前記自己オブジェクトの視点が変化したとき、所定の遅延時間をおいて前記撮影手段の移動が開始されるように、変化後の前記自己オブジェクトの視点に基づいて、前記撮影手段の移動を制御する
ことを特徴とする表示制御方法。
【請求項８】
３次元仮想空間を表示する表示制御処理を、コンピュータに行わせるためのコンピュータプログラムであって、
前記３次元仮想空間を撮影する撮影手段を想定し、その撮影手段が前記３次元仮想空間を撮影することにより得られる画像を提供する場合において、
前記３次元仮想空間における自己を表す自己オブジェクトの視点と前記撮影手段の位置とが一致している状態の１人称モードと、一致していない状態の３人称モードとが切り替え可能であり、
前記３人称モードとされたときに、前記自己オブジェクトの視点にしたがって、前記撮影手段の位置を制御し、
前記３人称モードの状態において、前記自己オブジェクトの視点が変化したとき、所定の遅延時間をおいて前記撮影手段の移動が開始されるように、変化後の前記自己オブジェクトの視点に基づいて、前記撮影手段の移動を制御する
処理を行わせるためのコンピュータプログラムが記録されている記録媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、表示制御装置および表示制御方法、並びに記録媒体に関し、特に、例えば、３次元仮想空間を表示するに際して、ユーザの視点をダイナミックに適切な位置に変えられるようにする表示制御装置および表示制御方法、並びに記録媒体に関する。
【０００２】
【従来の技術】
従来、NIFTY-Serve(商標)や米国のCompuServe(商標)などのように、複数の利用者が自らのパーソナルコンピュータを、モデムおよび公衆電話回線網を介してセンターのホストコンピュータに接続し、所定の通信プロトコルに基づいてホストコンピュータにアクセスする、いわゆるパソコン通信サービスの分野においては、Habitat（商標）と呼ばれるサイバースペースのサービスが知られている。
【０００３】
Habitatは、米国LucasFilm社によって1985年から開発が始められ、米国商業ネットワークであるQuantumLink社で約３年間運用された後、1990年2月に富士通Habitat（商標）としてNIFTY-Serveでそのサービスが開始されたものである。このHabitatにおいては、2次元グラフィックスで描画された「ポピュロポリス（Populopolis）」と呼ばれる仮想の都市に、アバタ（avatar；インド神話に登場する神の化身）と呼ばれるユーザの分身（ユーザ自身を表すオブジェクト）を送り込み、ユーザ同士がチャット（Chat；文字の入力と表示によるテキストベースでのリアルタイムの対話）などを行うことができる。このHabitatの更に詳細な説明については、サイバースペース，マイケル・ベネディクト編，1994年3月20日初版発行，ＮＴＴ出版 ISBN4−87188−265−9C0010（原著；Cyberspace：First Steps ,Michael Benedikt,ed. 1991,MIT PressCambrige,MA ISBN0−262−02327−X）第282頁乃至第307頁を参照されたい。
【０００４】
この種のパソコン通信サービスで運用されている従来のサイバースペースシステムにおいては、仮想的な街並みや部屋の内部の様子が2次元グラフィックスで描画されており、アバタを奥行きまたは手前方向へ移動させる場合、単にアバタを2次元グラフィックスの背景上で上下に移動させるだけであり、仮想空間内での歩行や移動を疑似体験させるには表示の上での表現力が乏しかった。また、自分の分身であるアバタと他人のアバタが表示された仮想空間を、第３者の視点で見ることになるため、この点においても、疑似体験の感覚が損なわれるものであった。
【０００５】
そこで、特開平9-81781号公報に開示されているように、仮想空間を３次元グラフィックスで表示し、ユーザがアバタの視点で自由に歩き回れる機能が、VRML(Virtual Reality Modeling Language)と呼ばれる3次元グラフィクス・データの記述言語を利用することによって実現されている。また、ユーザの代理となるアバタを用いてチャットを行う種々のサイバースペースの考察に関しては、日経エレクトロニクス1996.9.9(no.670)の第151頁乃至159頁に記載されている。
【０００６】
以上のように、３次元グラフィックスで表示された仮想空間、即ち、３次元仮想空間を、アバタの視点で歩き回れる場合には、ユーザは、自身が、その３次元仮想空間に実際にいるかのような感覚を享受することができる。
【０００７】
【発明が解決しようとする課題】
ところで、３次元仮想空間においては、現実にはありえる事象は勿論、人間が空想する世界の事象、即ち、例えば、ユーザが幽体離脱して、幽体となったもう一人の自分が、実存する自分自身（空想の世界で実存する自分自身）を観察しているような状態なども表現することができる。具体的には、例えば、ユーザの視点を、自身を表すアバタ（以下、適宜、アバタのうち、自身を表すアバタを、パイロットアバタという）が見えるような視点とすることで、ユーザは、自身の分身であるパイロットアバタを見ることができ、この場合、幽体となったユーザが、実存する自分自身であるパイロットアバタを観察している、即ち、幽体離脱をしているかのような感覚を享受することができる。
【０００８】
しかしながら、ユーザの視点を、パイロットアバタが見えるような任意の視点にしたのでは、即ち、ユーザに、単に、パイロットアバタを含む３次元仮想空間の画像を提供するのでは、疑似体験の感覚が損なわれることがある。
【０００９】
即ち、例えば、ユーザの視点を、パイロットアバタの顔の真正面にした場合には、パイロットアバタの顔のアップが表示されることになり、幽体である自分が、実存する自分を観察しているような感覚を享受するのは困難である。
【００１０】
また、ユーザの視点を、パイロットアバタが見えるような任意の視点にした状態のままでは、幽体離脱をしているかのような感覚を享受することは可能であるが、自分の分身であるパイロットアバタと他人のアバタ（以下、適宜、他人を表すアバタをドローンアバタという）が表示された仮想空間を、第３者の視点で見ることになるため、自身が仮想世界にいるような感覚（自分自身が仮想世界の中にいて、その中を歩き回っているかのような感覚）を享受するのは困難となる。
【００１１】
従って、ユーザの視点を、パイロットアバタの視点に一致させた状態と、一致させない状態とを切り替えることができれば便利である。
【００１２】
さらに、ユーザの視点を、パイロットアバタの視点に一致させない状態とする場合には、例えば、幽体である自分が、実存する自分を観察しているような感覚を享受することができるような位置に、ユーザの視点をおくのが望ましい。具体的には、例えば、自分の分身であるパイロットアバタとともに、そのパイロットアバタが見ている風景を見ることができれば、幽体である自分が、実存する自分を観察しているような感覚を享受することができることが予想され、ユーザの視点を、パイロットアバタの視点に一致させない状態とした直後は、そのような画像が提供されるのが望ましい。
【００１３】
本発明は、このような状況に鑑みてなされたものであり、ユーザの視点を、ダイナミックに適切な位置に変えることができるようにし、これにより、例えば、自身が仮想世界にいるような感覚、および幽体離脱をしているかのような感覚のいずれをも、ユーザの要望に応じて享受することができるようにするものである。
【００１４】
【課題を解決するための手段】
請求項１に記載の表示制御装置は、３次元仮想空間における自己を表す自己オブジェクトの視点と撮影手段の位置とが一致している状態の１人称モードと、一致していない状態の３人称モードとを切り替えるモード切替手段と、３人称モードとされたときに、自己オブジェクトの視点にしたがって、撮影手段の位置を制御する制御手段とを備え、制御手段は、３人称モードの状態において、自己オブジェクトの視点が変化したとき、所定の遅延時間をおいて撮影手段の移動が開始されるように、変化後の自己オブジェクトの視点に基づいて、撮影手段の移動を制御することを特徴とする。
【００１５】
請求項７に記載の表示制御方法は、３次元仮想空間における自己を表す自己オブジェクトの視点と撮影手段の位置とが一致している状態の１人称モードと、一致していない状態の３人称モードとが切り替え可能であり、３人称モードとされたときに、自己オブジェクトの視点にしたがって、撮影手段の位置を制御し、３人称モードの状態において、自己オブジェクトの視点が変化したとき、所定の遅延時間をおいて撮影手段の移動が開始されるように、変化後の自己オブジェクトの視点に基づいて、撮影手段の移動を制御することを特徴とする。
【００１６】
請求項８に記載の記録媒体は、３次元仮想空間における自己を表す自己オブジェクトの視点と撮影手段の位置とが一致している状態の１人称モードと、一致していない状態の３人称モードとが切り替え可能であり、３人称モードとされたときに、自己オブジェクトの視点にしたがって、撮影手段の位置を制御し、３人称モードの状態において、自己オブジェクトの視点が変化したとき、所定の遅延時間をおいて撮影手段の移動が開始されるように、変化後の自己オブジェクトの視点に基づいて、撮影手段の移動を制御する処理を、コンピュータに行わせるためのコンピュータプログラムが記録されていることを特徴とする。
【００１７】
請求項１に記載の表示制御装置においては、モード切替手段は、３次元仮想空間における自己を表す自己オブジェクトの視点と撮影手段の位置とが一致している状態の１人称モードと、一致していない状態の３人称モードとを切り替え、制御手段は、３人称モードとされたときに、自己オブジェクトの視点にしたがって、撮影手段の位置を制御し、３人称モードの状態において、自己オブジェクトの視点が変化したとき、所定の遅延時間をおいて撮影手段の移動が開始されるように、変化後の自己オブジェクトの視点に基づいて、撮影手段の移動を制御するようになされている。
【００１８】
請求項７に記載の表示制御方法においては、３次元仮想空間における自己を表す自己オブジェクトの視点と撮影手段の位置とが一致している状態の１人称モードと、一致していない状態の３人称モードとが切り替え可能であり、３人称モードとされたときに、自己オブジェクトの視点にしたがって、撮影手段の位置を制御し、３人称モードの状態において、自己オブジェクトの視点が変化したとき、所定の遅延時間をおいて撮影手段の移動が開始されるように、変化後の自己オブジェクトの視点に基づいて、撮影手段の移動を制御するようになされている。
【００１９】
請求項８に記載の記録媒体においては、３次元仮想空間における自己を表す自己オブジェクトの視点と撮影手段の位置とが一致している状態の１人称モードと、一致していない状態の３人称モードとが切り替え可能であり、３人称モードとされたときに、自己オブジェクトの視点にしたがって、撮影手段の位置を制御し、３人称モードの状態において、自己オブジェクトの視点が変化したとき、所定の遅延時間をおいて撮影手段の移動が開始されるように、変化後の自己オブジェクトの視点に基づいて、撮影手段の移動を制御する処理を、コンピュータに行わせるためのコンピュータプログラムが記録されるようになされている。
【００２０】
【発明の実施の形態】
以下、図面を参照し、本発明の実施の形態について説明する。
【００２１】
説明に先立ち、世界的規模で構築されたコンピュータネットワークであるインターネット(The Internet)において、様々な情報を提供するWWW(world wide web)の枠組みを利用して３次元的な情報を統一的に扱うことができる記述言語であるVRML(virtual reality modeling language)について説明する。
【００２２】
ここで、インターネットで利用できる情報提供システムとして、スイスのCERN（European Center for Nuclear Research：欧州核物理学研究所）が開発したWWWが知られている。これは、テキスト、画像、音声などの情報をハイパーテキスト形式で閲覧できるようにしたもので、HTTP(Hyper Text Transfer Protocol)と呼ばれるプロトコルに基づいて、WWWサーバに格納された情報をパーソナルコンピュータなどの端末に非同期転送するものである。
【００２３】
WWWサーバは、HTTPデーモン（HTTP：HyperText Transfer Protocol、ハイパーテキスト転送プロトコル）と呼ばれるサーバ・ソフトウエアとハイパーテキスト情報が格納されるHTMLファイルによって構成される。なお、デーモンとは、UNIX上で作業を行う場合、バックグラウンドで管理や処理を実行するプログラムを意味する。ハイパーテキスト情報は、HTML（HyperText Markup Language、ハイパーテキスト記述言語）と呼ばれる記述言語によって表現される。HTMLによるハイパーテキストの記述は、「＜」と「＞」で囲まれたタグと呼ばれる書式指定によって文章の論理的な構造が表現される。他の情報とのリンクについての記述は、アンカーと呼ばれるリンク情報によって行われる。アンカーによって情報が存在する所を指定する際には、URL(Uniform Resource Locator)が用いられる。
【００２４】
HTMLで記述されたファイルを、TCP/IP(Transmission Control Protocol/Internet Protocol)ネットワーク上において転送するためのプロトコルがHTTPである。クライアントからの情報の要求をWWWサーバに伝え、HTMLファイルのハイパーテキスト情報をクライアントに転送する機能をもっている。
【００２５】
WWWを利用する環境として多く利用されているのが、WWWブラウザ（ブラウザとは閲覧するという意味）と呼ばれる、Netscape Navigator（米国Netscape Communications社の商標）をはじめとするクライアント・ソフトウエアである。
【００２６】
このWWWブラウザを用いて、URLに対応する世界規模で広がるインターネット上のWWWサーバ上のファイル、いわゆるホームページを閲覧することができ、いわゆるネットサーフィンと呼ばれるように、リンクが張られたホームページを次々と辿って、多種多様なWWWの情報ソースにアクセスすることができる。
【００２７】
近年、このWWWをさらに拡張し、3次元空間の記述や、３次元グラフィックスで描画されたオブジェクトに対してハイパーテキストのリンクの設定を可能とし、これらのリンクをたどりながらWWWサーバを次々とアクセスできるようにしたVRMLと呼ばれる３次元グラフィックス記述言語で記述された３次元空間を表示するVRMLブラウザが開発されている。
【００２８】
このVRMLの詳細は、例えば、「VRMLを知る：３次元電脳空間の構築とブラウジング〔マーク・ペッシ著，松田晃一・蒲地輝尚・竹内彰一・本田康晃・暦本純一・石川真之・宮下健・原和弘訳，１９９６年３月２５日初版発行，プレンティスホール出版ISBN4-931356-37-0〕（原著；VRML：Browsing & Building Cyberspace,Mark Pesce, 1995 New Readers Publishing ISBN 1-56205-498-8））」、および「VRMLの最新動向とＣｙｂｅｒＰａｓｓａｇｅ〔松田晃一・本田康晃著、ｂｉｔ（共立出版）／1996 Vol.28 No.7 pp29 乃至pp36, No.8 pp57 乃至pp65, No.9 pp29 乃至pp36, No.10 pp49乃至pp58〕」等の文献に記載されている。
【００２９】
また、 August 4, 1996における The Virtual Reality Modeling Language Version  2.0, ISO/IEC CD 14772の公式かつ完全な仕様書は、http://webspace.sgi.com/moving-worlds/spec/index.htmlで公開されており、その日本語版は、http://www.webcity.co.jp/info/andoh/VRML/vrml2.0/spec-jp/index.htmlで公開されている。
【００３０】
さらに、VRML２．０用ブラウザおよび共有サーバ用ソフトウェアとしては、例えば、本出願人であるソニー株式会社が「Community Place Browser / Bureau(商標)」として開発し、製品化しており、そのβ版（試供版）を、インターネット上のホームページhttp://vs.sony co.jpからダウンロード可能としている。
【００３１】
このようなVRML２．０を用いて３次元的な仮想空間を構築しようとする場合、まず、VRMLにより仮想空間内の物体（モデル）の形、動きおよび位置等を示す図形データの作成（モデル作成）、ユーザが画面表示された仮想空間内のモデルを、例えば、マウスでクリックしてポインティングした場合にイベントを発生させるスイッチ（センサ）のモデルへの付加（センサ付加）、センサへのポインティングに応じて発生するイベントを実現するスクリプトのプログラミング（スクリプト作成）、センサーに対する操作とスクリプトの起動等、図形データおよびスクリプト（以下、図形データ、スクリプトおよびVRMLに規定されているライト等のコモンノード等を総称してノードとも記す）の間の対応付け（ルーティング）などによって所望のコンテンツを表現するVRMLファイルを作成する。
【００３２】
例えば、http://www.ses.co.jp/SES/STAFF/kan/howto/howto1.htmlには、VRML2.0の書き方、サンプルデータなど、丁寧に解説されている。その一部を紹介すると、以下の通りである。
【００３３】
1.VRML2.0で書かれたワールドを見るには
HTML形式で書かれたデータを見るためにHTMLブラウザが必要なように、VRML2.0形式で書かれたデータを見るためにはVRML2.0に対応したVRMLブラウザが必要となる。尚、このページで作成したVRML2.0のデータは全てSONY社製のCommunity Place Browserで行なわれている。
また、ファイルがVRMLで書かれたことを表すためにファイルの拡張子を*.wrl（ワールドの意）に、更にVRML2.0で書かれたことを表すためにファイルの１行目に
#VRML V2.0 utf8
と書くことが必要である。
【００３４】
2.VRML2.0データの基本構造
VRML2.0のデータはノード(Node)とフィールド(Field)で構成されていて、基本的に次のような形で書かれている。
Node { Field(s) }
この中でFieldsは省略することができるが、Nodeと中かっこ'{','}'は省略することができない。
フィールドはノードに変数を渡し、ノードのパラメータを指定します。フィールドを省略した場合、デフォルト値が用いられる。また、フィールドには単一の値しか持たない「単一値フィールド(SF)」と複数の値を持つ「複値フィールド(MF)」があり、単一値フィールドの名前は"SF"で、複値フィールドは"MF"で始まるようになっている。
【００３５】
3.球の書き方
VRML2.0では球や直方体、円柱、円錐などの基本図形を描くためのノードが用意されている。前にも書いているが、それぞれのノードはパラメータを指定するためのフィールドを持っている。例えば、球を描くためのSphereノードは半径を指定するためのradiusというフィールドを持っており、次のように書くことで半径1の球を表示する。尚、radiusフィールドのデータタイプは、SFFloatですから、１つの浮動小数点数の値をとる。
【００３６】
Sample1
1: #VRML V2.0 utf8
2: Transform {
3:     children [
4:         Shape {
5:             geometry Sphere { radius 1 }
6:         }
7:     ]
8: }
【００３７】
実は2,3行目、7,8行目は書かなくてもかまいません。1行目と4行目乃至6行目だけで、きちんと半径1の球を表示できる。
Transformノードは、Groupノードという種類のノードの１つで、文字通りノードのグループ化を行うためのノードである。Transformノードを含めて、以後でてくる他のノードの詳しい機能やフィールドなどは「Appendix1：VRML2.0
Node List」を参照されたい。
球を書くためのノードはSphereであるが、このノードはGeometryノードを呼ばれるノードの１つである。
Geometryノードは、見え方と形状を定義するShapeノードのgeometryフィールドに書く必要がある。
【００３８】
4.球に色を付ける
先ほどの球に色を付けるには次のように書く。
Sample2
1: #VRML V2.0 utf8
2: Transform {
3:     children [
4:         Shape {
5:           appearance Appearance {
6:             material Material { diffuseColor 1 0 0 }
7:           }
8:           geometry Sphere { radius 1 }
9:         }
10:     ]
11: }
【００３９】
この球は赤色で表示される。追加されたのは5行目乃至7行目までである。diffuseColorフィールドのデータタイプは、SFColorであるから、RGBカラーを表す3つの単精度浮動小数点数の組を１つだけ持つ。見え方を定義するMaterialノードはAppearanceノードのmaterialフィールドに書くことになっています。また、AppearanceノードはShapeノードのappearanceフィールドに書くことになっている。このためこのような一見複雑な構造になっている。
【００４０】
5.テクスチャの張り付け
オブジェクトに色を付けるだけではなくて画像ファイルを張り付けることもできる。VRML2.0でテクスチャとして利用できるファイルフォーマットはJPEG,GIF,PNGである。ここでは予め用意したGIFイメージを使っている。
Sample3
1: #VRML V2.0 utf8
2: Transform {
3:     children [
4:         Shape {
5:           appearance Appearance {
6:             texture ImageTexture { url "image.gif" }
7:           }
8:           geometry Box {}
9:         }
10:     ]
11: }
【００４１】
テクスチャを張り付けているのは6行目である。ImageTexureノードはAppearanceノードのtextureフィールドに書くことになっているため、このような書き方になる。尚、8行目のBoxノードは直方体を描くためのノードである。
【００４２】
6.物体の位置を移動させる
次にこの赤色の球を右に移動させる。
Sample4
1: #VRML V2.0 utf8
2: Transform {
3:     translation 2 0 0
4:     children [
5:         Shape {
6:           appearance Appearance {
7:             material Material { diffuseColor 1 0 0 }
8:           }
9:           geometry Sphere { radius 1 }
10:         }
11:     ]
12: }
【００４３】
3行目に追加したtranslationフィールドで物体を平行移動させる。translationフィールドは、
translation x y z
で、それぞれx軸、y軸、ｚ軸の移動量を指定する。ブラウザ上ではx軸は左右（右方向に+）、y軸は上下（上方向に+）、ｚ軸は奥行き（手前に向かって+）を表す。従って、
translation 2 0 0
は右方向に2だけ平行移動することになる。
【００４４】
7.物体の追加
赤い球の左に緑の円錐を追加する。
Sample5
1: #VRML V2.0 utf8
2: Transform {
3:     translation 2 0 0
4:     children [
5:         Shape {
6:           appearance Appearance {
7:             material Material { diffuseColor 1 0 0 }
8:           }
9:           geometry Sphere { radius 1 }
10:         }
11:     ]
12: }
13: Transform {
14:     translation -2 0 0
15:     children [
16:         Shape {
17:           appearance Appearance {
18:             material Material { diffuseColor 0 1 0 }
19:           }
20:           geometry Cylinder {}
21:         }
22:     ]
23: }
【００４５】
13行目以降に追加したソースは12行目以前のものと構造は同じである。物体が球から円錐へ、色が赤から緑へ、そして位置が左に移動している点が12行目以前のものと異なる。
【００４６】
8.ポリゴンで書く
上述した「VRML2.0の書き方」ではプリミティブな図形を使ったが、複雑な図形を書くときにはポリゴンを使用する。ポリゴンで表示するためにIndexedLineSet，IndexedFaceSetの2つのノードが用意されている。IndexedLineSetは線を、IndexedFaceSetは面を表現する。
Sample6
1: #VRML V2.0 utf8
2:     Transform {
3:         children [
4:             Shape {
5:                 geometry IndexedFaceSet {
6:                     coord Coordinate {
7:                         point [
8:                             0 0 0,
9:                             1 0 0,
10:                             1 0 1,
11:                             0 0 1,
12:                             0 1 0,
13:                             1 1 0,
14:                             1 1 1,
15:                             0 1 1
16:                         ]
17:                     }
18:                     coordIndex [
19:                         0, 1, 2, 3,-1,
20:                         0, 1, 5, 4,-1,
21:                         1, 2, 6, 5,-1,
22:                         2, 3, 7, 6,-1,
23:                         3, 0, 4, 7,-1,
24:                         4, 5, 6, 7,-1
25:                     ]
26:                     solid FALSE
27:                 }
28:             }
29:         }
30:     ]
31: }
【００４７】
このサンプルは６つの面で立方体を表している。ポリゴンで表すためにはまず、頂点となる座標を決める（7行目乃至16行目）。この座標は上から0,1,2,と番号が振られる。即ち、10行目の「1 0 1」は「2」番の座標ということになる。次に何番の座標と何番の座標で面を構成するのかを決める（18行目乃至25行目）。19行目の「0, 1, 2, 3, -1」は「0番、1番、2番、３番の座標で面を作る」ことを表している。
【００４８】
9.ノードに名前を付ける
既に定義されているノードを再利用するためにDEFとUSEという機能がある。例えば、半径2の青の球を２つ描くとする。これまでの書き方で書くならば次のようになる。
Sample7
1: #VRML V2.0 utf8
2: Transform {
3:     children [
4:         Shape {
5:             appearance Appearance {
6:                 material Material { diffuseColor 0 0 1 }
7:             }
8:             geometry Sphere { radius 2 }
9:         }
10:     ]
11: }
12: Transform {
13:     translation 0 5 0
14:     children [
15:         Shape {
16:             appearance Appearance {
17:                 material Material { diffuseColor 0 0 1 }
18:             }
19:             geometry Sphere { radius 2 }
20:         }
21:     ]
22: }
【００４９】
12行目以降は13行目の座標移動の部分を除いて11行目以前と全く同じである。１度定義されている「半径2で青い球」を再び同じように記述するのははっきり言って無駄である。そこで次のようにする。
【００５０】
Sample7改
1: #VRML V2.0 utf8
2: Transform {
3:     children [
4:         DEF BlueSphere Shape {
5:             appearance Appearance {
6:                 material Material { diffuseColor 0 0 1 }
7:             }
8:             geometry Sphere { radius 2 }
9:         }
10:     ]
11: }
12: Transform {
13:     translation 0 5 0
14:     children [
15:         USE BlueSphere
16:         }
17:     ]
18: }
4行目を見ると
DEF BlueSphere Shape
となっている。これは「Shape{……}を「BlueSphere」という名前にします。」という意味で、これ以降
USE BlueSphere
と書くだけでShape{……}と同じ内容を表す。
【００５１】
10.WRLファイルの読み込み
大きなVRMLデータをつくるときに１つのファイルにすべての記述を行うのはあまりいい方法ではない。部品ごとに分けて必要に応じて呼び出せるようにしておく方が便利である。このような場合、Inlineノードを使う。例えば1.でつくったSample1.wrlを読み込んで表示する。
Sample8
1: #VRML V2.0 utf8
2: Inline {
3:     url [
4:         sample1.wrl
5:     ]
6: }
【００５２】
11.リンクを張る
オブジェクトにリンクを張り、オブジェクトをクリックしたときに別のページにジャンプさせることもできる。
Sample9
1: #VRML V2.0 utf8
2: Anchor {
3:     children [
4:         Shape {
5:             geometry Sphere { radius 2 }
6:         }
7:     ]
8:     url "test.html"
9:     description "LINK to test.html"
10: }
【００５３】
リンクを張るオブジェクトを子ノードにしてAnchorノードで括る。AnchorノードはGroupノードの１つである。リンク先のファイルをurlフィールドに書く。descriptionフィールドに書いた文字列はマウスポインタがオブジェクトに触れている間表示される。
【００５４】
12.ライトの設定
VRML2.0ではワールドに光を設定するためにDirectionalLight（平行光）、PointLigt（点光源）、SpotLight（スポットライト）３つのノードが用意されている。ここではPointLigtノードを例に挙げて説明する。光の当たり方がわかりやすいように3行目でオブジェクトを回転させている。
Sample10
1: #VRML V2.0 utf8
2: Transform {
3: rotation 1 0 0 0.75
4:     children [
5:         PointLight {
6:             location 0 0 2 #オブジェクトの前
7:         }
8:         Shape {
9:             geometry Cylinder {}
10:         }
11:     ]
12: }
【００５５】
6行目の光源の位置によってオブジェクトの見え方が異なる。このサンプルではオブジェクトの前に光源を置いている。
【００５６】
13.ワールド環境(1)
これまでは主にオブジェクトの作成に関しての解説であったが、今回はオブジェクト作成以外のノードの使い方について触れる。ワールド環境などと勝手に命名しているが、こういう言い方が一般的かどうかは分からない。
まず、ブラウザでデフォルトで用意されている HeadLight を消してみる。HeadLight の ON・OFF はブラウザのOption で変更できるが、ファイル内に書くことによっても設定できる。
Sample11
1: #VRML V2.0 utf8
2: NavigationInfo {
3:     headlight FALSE
4: }
5: Transform{
6:     children [
7:         Shape {
8:             appearance Appearance {
9:                 material Material { diffuseColor 1 0 0 }
10:             }
11:             geometry Sphere {}
12:         }
13:     ]
14: }
【００５７】
このサンプルでブラウザの Option を見ると、Headlight のチェックがはずれている。このサンプルでは今までのサンプルに比べて極端に暗くなっているのが分かる。HeadLight は常にユーザの見ている方向に照らされるライトで、これがないとこのように見える。
新たに加えたのは 2 行目から 4 行目の NavigationInfo ノードである。このノードの headlight フィールドをTRUE か FALSE にすることで HeadLight を ON・OFF する。HeadLight を消して任意のライトを設定することで効果的に明るさを設定できる。
【００５８】
14.ワールド環境(2)
NavigationInfo ノードには他にも幾つかのフィールドが用意されている。その中の type フィールドでナビゲーション方法を変更することができる。
デフォルトでは WALK に設定されている ナビゲーション方法であるが、他にも重力を無視して移動できる FLY、自分が動くことなくオブジェクトを動かす EXAMINE、何もコントロールできない NONE、がある。ちなみに WALKは重力の影響を受けながら移動するナビゲーション方法である。
【００５９】
Sample12
1: #VRML V2.0 utf8
2: NavigationInfo {
3:     type EXAMINE
4: }
5: Transform{
6:     children [
7:         Shape {
8:             appearance Appearance {
9:                 material Material { diffuseColor 1 0 0 }
10:             }
11:             geometry Box {}
12:         }
13:     ]
14: }
このサンプルでは EXAMINE にしている。オブジェクトをマウスでドラッグするとオブジェクトが回転する。
【００６０】
15.シーンにタイトルを付ける
HTML では <title> タグで囲むことによってタイトルを付けることができる。もしこのタグを指定しないとタイトルが [http://ryo1.is.kochi-u…howto3.html] のようにパスが表示される。VRML でもこれと同じことが起こる。これまでのサンプルではタイトルを指定していないためパスが表示されている。VRMLでタイトルを指定するには WorldInfo ノードを使用する。
【００６１】
Sample13
1: #VRML V2.0 utf8
2: WorldInfo {
3:     title "Spin Box"
4:     info["Autor H.Kan","http://ryo1.is.kochi-u.ac.jp/"]
5: }
2: NavigationInfo {
3:     type EXAMINE
4: }
5: Transform{
6:     children [
7:         Shape {
8:             appearance Appearance {
9:                 material Material { diffuseColor 1 0 0 }
10:             }
11:             geometry Box {}
12:         }
13:     ]
14: }
【００６２】
2 行目乃至 5 行目までに WorldInfo ノードを追加した。このサンプルでは前のサンプルに "Spin Box" というタイトルを付けた（Plugin 版では表示されなかった）。尚、info フィールドにはタイトル以外の情報を書くが、ブラウザ上には何の変化も与えない。
【００６３】
16.視点の位置を変える
デフォルトでは視点は最初 z 軸上のどこか（オブジェクトの配置によって異なる）にいる。ここでは最初の視点位置を任意の場所に変更できるようにする。
【００６４】
Sample14
1: #VRML V2.0 utf8
2: Viewpoint{ position x y z }
3: Transform {
4:     children [
5:         Shape {
6:             appearance Appearance {
7:                 material Material { diffuseColor 1 0 0 }
8:             }
9:             geometry Sphere {}
10:         }
11:     ]
12: }
13: Transform {
14:     translation -3 0 0
15:     children [
16:         Shape {
17:             appearance Appearance {
18:                 material Material { diffuseColor 0 1 0 }
19:             }
20:             geometry Sphere {}
21:         }
22:     ]
23: }
24: Transform {
25:     translation 3 0 0
26:     children [
27:         Shape {
28:             appearance Appearance {
29:                 material Material { diffuseColor 0 0 1 }
30:             }
31:             geometry Sphere {}
32:         }
33:     ]
34: }
【００６５】
（0,  0,  0）に赤、（-3,  0 ,  0）に緑、（3,  0,  0）に青の球がある。2 行目の Viewpoint ノードの position フィールドに具体的な座標を指定すると、そこが最初の視点になる。ただし視線方向は常に z 軸の方向である。
【００６６】
17.視線の方向を変える
sample14 では視点の座標のみを変更したが、もちろん視線方向も指定できる。方向を指定するときも Viewpoint ノードを使うが、 フィールドは orientation フィールドを使う。orientation フィールドは SFRotation 型のフィールドで、加点軸と回転角を値として持つ。
【００６７】
18.センサをつける
VRML2.0 のノードの中には Sensor ノードと呼ばれるノードがある。シーン内での様々なことを感知、判定するためのノードで、全部で7種類用意されている。このWebページで動作確認を行っている Community Place Browser では、幾つかの Sensor ノードがまだサポートされていない。ここではオブジェクトにマウスがヒットしたかどうかを感知する TouchSensor をオブジェクトにつけてみる。
【００６８】
Sample15
1: #VRML V2.0 utf8
2: Transform{
3:     children [
4:         DEF TS TouchSensor {}
5:         Shape {
6:             geometry Box {}
7:         }
8:     ]
9: }
【００６９】
これまでのサンプルと異なるのは4行目だけである。ここでは TS という名前を付けた TouchSensor を Box につけている。Box にマウスカーソルが触れると（あなたが使っているブラウザが Community Place Browser ならば）手の形に変わるはずである（他のブラウザの中にはカーソルが変わらないものもある）。ちなみにクリックしても何も起きない。
【００７０】
19.動きをつける(1)
VRML2.0 が VRML1.0 と大きく異なる点はシーンに動きをつけられるという点である。 動きをつけるには Java や VRMLScript(JavaScript) などのスクリプトを用いる方法と、Interplator ノードを用いる方法がある。
まずは Interplator ノードを用いる方法から見ていく。Interplate とは、「差し挟む」とか「内挿する」といった意味である。Interpolator ノードで数値、位置、3Ｄ座標、方向、法線、色の値を変えることによってシーンに動きをつけることができる。ここでは方向を内挿する OrientationInterpolator ノードを用いてオブジェクトを回転させてみる。
【００７１】
Sample16
1: #VRML V2.0 utf8
2: DEF OBJ Transform{
3:     children [
4:         Shape {
5:             geometry Box { size 2 3 1 }
6:         }
7:     ]
8: }
9: DEF TS TimeSensor{
10:     cycleInterval 1
11:     loop TRUE
12:     stopTime -1
13: }
14: DEF OI OrientationInterpolator{
15:     key [0, 0.125, 0.25,0.375, 0.5,
16:          0.625, 0.75, 0.875, 1,]
17:     keyValue [0 1 0 0, 0 1 0 0.785, 0 1 0 1.57,
18:          0 1 0 2.355, 0 1 0 3.14, 0 1 0 -2.355,
19:          0 1 0 -1.57, 0 1 0 -0.785, 0 1 0 0]
20: }
21: ROUTE TS.fraction_changed TO OI.set_fraction
22: ROUTE OI.value_changed TO OBJ.set_rotation
【００７２】
まず、幾つかのノードに名前を付けておく。2,9,14 行目にそれぞれ、OBJ,TS,OI と定義している。これは後述するがイベントの受け渡しをするときに必要になる。
9 行目乃至 13 行目を見ます。TouchSensor は時間の経過を感知するノードで、時間の経過に伴って一定の間隔でイベントを生成することができる。loop フィールドは TRUE か FALSE をとる SFBool フィールドで、TRUE なら stopTime になるまで続く。ここでは stopTime -1 と startTime（デフォルトは0）と startTime より小さな値になっているので永久に継続されることになる。回転する動きをもっと遅くするときには cycleInterval の値をもっと大きくする。
【００７３】
14 行目乃至 20 行目までが OrientationInterpolator ノードである。Interpolator ノードはすべて key と keyValue の2つのフィールドを持っている。key はアニメーション時間の間隔を 0 から 1 の間で設定する。
keyValue は key で設定した間隔に具体的なフィールド値（ここでは MFRotation ）を設定する。ここではアニメーション時間の間隔を9等分して、ｙ軸を中心に回転角を設定している。
【００７４】
しかしこれだけではシーンに動きをつけることはできない。TimeSensorノードの生成したイベントを OrientationInterpolator ノードに渡してやる必要がある。21,22行目を見ます。この ROUTE というキーワードで始まる行で イベントを受け渡しを行う。
TimeSensor TS が起動すると fraction_changed がイベントアウトされる。fraction_changed がイベントアウトされると、OrientationInterplator OIの set_fraction にイベントインされる。ここまでが21 行目の ROUTE の動作である。22 行目はイベントインされた set_fraction 値から OrientationInterplator OI が値を内挿し、それを Transform OBJ の translation フィールドに value_changed としてイベントアウトする。
もう1つサンプルをあげてみる。
【００７５】
20.動きをつける(2)
今度はマウスでオブジェクトをクリックすると移動するサンプルである。移動するには位置を内挿する PositionInterpolator ノードを使用する。
Sample17
1: #VRML V2.0 utf8
2: DEF OBJ Transform {
3:     children [
4:         DEF TS TouchSensor {}
5:         Shape {
6:             appearance Appearance {
7:                 material Material { diffuseColor 1 0 0 }
8:             }
9:             geometry Box {}
10:         }
11:     ]
12: }
13: DEF TIS TimeSensor { cycleInterval 5 }
14: DEF PI PositionInterpolator {
15:     key [0, 0.2, 0.4, 0.6, 0.8, 1.0]
16:     keyValue[0 0 0 , 0 0 -2 , 0 2 -4 , 0 4 -6 , 2 4 -6, 4 2 -6]
17: }
18: ROUTE TS.touchTime TO TIS.set_startTime
19: ROUTE TIS.fraction_changed TO PI.set_fraction
20: ROUTE PI.value_changed TO OBJ.set_translation
【００７６】
今度は、OBJ という名前の赤い立方体に TouchSenor TS をつけている。オブジェクトがクリックされると、TouchSenor TS の touchTime が TimeSensor TIS の startTime にイベントアウトされる。サンプルのソースには TimeSensoe ノードの中に startTime フィールドは書いてないが、デフォルトで startTime 0 となっている。あとは前のサンプルと同じである。
これらの ROUTE によってオブジェクトが移動する。
【００７７】
ここで、第１世代のVRML１．０に対し、第２世代のVRML２．０で新たに加わった機能であるVRML仮想空間内における自律的な動き(Behavior)を実現するためのメカニズムについて概説する。
【００７８】
VRML２．０においては、3次元仮想現実空間（仮想空間）内に配置されたオブジェクトに対する操作に伴って生じるイベントや、予め設定された時間が経過した時点で生じるタイマーイベントに応じて、オブジェクトの自律的な動きを実現することができる。このBehaviorのメカニズムは、センサー、ルーティング、スクリプトの３つの要素の連携動作によって実現される。
【００７９】
すなわち、
▲１▼予め3次元仮想現実空間内に配置されたオブジェクトなどのノードに対して関係付けられて、VRMLファイルとして記述されたセンサーノードが、そのフィールドの値の変化に基づいて、外部イベントを感知し、VRMLシーン内にイベントを発生する。
▲２▼発生したイベントは、 VRMLファイルとして記述されたルーティングに基づいて、オブジェクトの挙動を規定するプログラムである外部のスクリプトに対して、伝達される。
▲３▼外部のスクリプトには予め特定のイベントが到来した時点で呼び出されるメソッドが記述されており、ルーティングによって伝達されたイベントを受け取った外部のスクリプトは、その記述に基づく処理を実行した後、その処理結果と、ルーティングの記述に基づいて、VRMLシーン内の該当するノードのフィールドの値を変更する。
【００８０】
VRML２．０においては、センサーノードとしては、例えば、指定されたオブジェクト上をポインティングデバイスが通過したり、ユーザによってクリックされた場合にイベントを発生するTouchSensorや、指定された領域内にViewPoint(ユーザの視点)が侵入した場合にイベントを発生するProximitySensorや、与えられた時刻となったり、予め指定された時間間隔が経過する毎に発生するTimeSensorなどが定義されている。
【００８１】
もう少し詳しく、Behaviorの仕組みを説明する。先にも述べたように、Behaviorの仕組みは、センサー、イベント、ルーティングおよびスクリプトから構成されている。
【００８２】
センサーは、２つの機能に分けられる。
・ユーザの操作を感知するタイプ
・システムの変化を感知するタイプ
【００８３】
ユーザの操作を感知するタイプのセンサーは、３次元仮想空間内に配置された物体などに関係付けられたソフトウエアによるスイッチとなる。システムの変化を感知するタイプのセンサーは、作動させる時間を事前に設定しておいたタイマーが作動することになる。センサーの働きは、これらの外部イベントを検出して、それをVRML内部のイベントに変換することである。
【００８４】
イベントは、VRMLの内部の関連するノード間で、情報を伝えるためのデータのことを指す。実際には、VRMLファイルの中に記述されたフィールド値の変化がイベントとして伝達される。
【００８５】
ルーティングは、センサー機能で検出されたイベントをどのノードに伝えるかを指定するための仕組みで、イベントによる情報の伝達経路を指定することになる。
【００８６】
スクリプトはイベントの入出力口で、入力されたイベントから何らかの計算を行い、その結果をイベントとして出力することができるものである。スクリプトは特定の言語のみに制限されるものではなく、現段階では、インターネット界で注目を浴びているJavaやJavaScript、通常のシステムでよく利用されているＣ言語、UNIXでよく利用されているTcl/TkやPERL、マイクロソフト社の提供しているVisual Basic言語などが対応している。このようにVRML２．０では特定のスクリプト言語に依存しない仕様になっている（VRML２．０仕様検討中、一時特定の言語仕様としてVRMLScriptが採用されようとしたこともあるが、この構想は取り止めなった）。
【００８７】
次に、Behaviorの処理手段に関して、図１を参照して説明する。Behaviorの処理を図式化すると、図１のようになる。以下、各部に分けて、処理信号の流れを説明する。
【００８８】
▲１▼センサーノード
前にも述べたように、センサーノードには、大きく分類して２系統がある。ユーザの操作を感知するタイプと、システムの変化を感知するタイプのセンサーである。
【００８９】
前者のセンサーには、３次元物体やその平面をマウスクリックしたり、通過したりしたときに感知するTouchSensorやPlaneSensorなどのセンサーノードがあり、後者のセンサーとしては、設定した時間が来るとイベントを発生させる仕組みになっているTimeSensorが用意されている。
【００９０】
この図１の例では、球にTouchSensorが付けられているものとする。このとき、ユーザが球をマウスクリックすると、このイベントをTouchSensorが検出する。このイベントは、TouchSensorのeventOutフィールドのフィールド値が変化することで検出される。通常１回のマウスクリックで２つのイベントを発生する。それは、マウスボタンが押されたタイミングと、離されたタイミングである。
【００９１】
次に、このイベントは、ルーティング記述部分によって、ルーティングされることになる。
【００９２】
▲２▼ルーティング
このイベントのルーティングを指定するのが、図２に示すような「Route」である。
【００９３】
センサー記述部分で発生したイベントがRouteのeventOutフィールドに伝達され、さらに、次に述べるスクリプトノードに伝えられることにより、外部ファイルにイベントが渡され、Behavior機能が実行される。
【００９４】
▲３▼スクリプトノード
このノードは、VRMLファイルと外部のスクリプトとを連動させる仲介をするノードである。スクリプトノードの記述書式に従って、どのような言語で記述されているかとか、ファイル名を指定したり、外部スクリプトファイルとの間でイベントのやり取りをするために、eventInフィールドとeventOutフィールドを規定する。このとき、使用できるスクリプトファイルは、Java、JavaScript、Ｃ言語、Tcl/Tk、PERL、およびVisual Basic言語など多岐に渡る。
【００９５】
実際の処理手段としては、ルーティングされたイベントがスクリプトノードに記述されているスクリプトファイルに処理が伝達され、外部のスクリプトファイルが実行される。外部のスクリプトファイルは、その中で定義されているeventIn（イベントの入口）で受け取り、そのファイル内に記述された処理を実行する。その処理が終了した後、eventOut（イベントの出口）から結果をVRMLファイルのルーティングへ返す。VRMLファイルは、その返された結果を実行して、一連のBehavior処理は終了する。
【００９６】
このような、センサー、ルーティング、スクリプトの連携動作によって実現されるBehaviorのメカニズムを利用することによって、例えば、3次元仮想現実空間内に配置されたスイッチを模したオブジェクトをマウスでクリックすることによって、同じ空間内に配置された他のオブジェクトの外観（形状、姿勢、サイズ、色等）であるとか、挙動シーケンスなどを動的に変更する事ができる。
【００９７】
このBehaviorのメカニズムの詳細な説明については、http://webspace.sgi.com/moving-worlds/spec/part1/concepts.htmlおよび、その日本語版であるhttp://www.webcity.co.jp/info/andoh/VRML/vrml2.0/spec-jp/part1/concepts.html で公開されている、August 4, 1996における The Virtual Reality Modeling Language Version  2.0, ISO/IEC CD 14772の仕様書、4．概念の節に開示されている。この節には、 VRML仕様書を利用するにあたりキーとなる概念が記述されている。ノードをシーングラフに結合する方法、ノードがイベントを生成したり受け取ったりする方法、プロトタイプによるノードタイプの作成方法、VRMLにノードタイプを追加して外部から使用できるようにエクスポートする方法、VRMLファイルにプログラムとして動作するスクリプトを組み込む方法など、様々なノードに関する一般的な項目が記載されている。
【００９８】
次に、このようなVRML２．０の自律的な動き(Behavior)を実現するメカニズムを応用して実現される共有仮想空間を表示する技術について、以下に詳述する。
【００９９】
図３は本発明の一実施の形態の全体のシステム（システムとは、複数の装置が論理的に集合した物をいい、各構成の装置が同一筐体中にあるか否かは問わない）構成図である。
【０１００】
図３において、１，２，３は、VRMLブラウザ及びWWWブラウザがインストールされ、これらが動作しているクライアントＰＣ（パーソナルコンピュータ）であり、IP（インターネット接続サービスプロバイダ）４，５，６を介してインターネット７と接続されている。
【０１０１】
インターネット７とルータ８を介して接続されたLAN(Local Area Network)9には、WWWサーバ１０、WLS（World Location Server）１１、共有サーバ１２、ＡＯ(Application Object)サーバ１３，１４、メールサーバ１５、およびコミュニケーションサーバ１６が接続されている。これらの各サーバ１０乃至１６には、ハードディスク（HDD）１０a，１０b，１１a乃至１６aが、各々設けられている。
【０１０２】
コミュニケーションサーバ１６は、公衆電話回線網１７を介して電話機１８やファクシミリ１９と接続され、さらに、PHS(Personal Handyphone System)サービスプロバイダ２０を介してPHS端末２３に無線接続され、ポケットベルサービスプロバイダー２１を介してポケットベル端末２４に無線接続されている。
【０１０３】
図４はクライアントＰＣ１のハードウェア構成を示すブロック図である。
【０１０４】
図４において、３０は各部を制御するCPU、３１はVRML ２．０ fileや、Java(米国 Sun Microsystems社の商標)により記述された所定のスクリプトプログラム等からなるVRMLコンテンツなどが格納されたHDD、３２はCD−ROMディスク３３に格納されたVRMLコンテンツを読み取るCD−ROMドライブ、３４はBIOS(Basic Input Output Systems)等が格納されたROM、３５はマイクロフォン３６と左右のスピーカ３７，３８が接続されたサウンド処理回路、３９はインターネット７に接続するためのMODEM、４０はマウス４１とキーボード４２が接続されたI/O(入出力)インターフェイス、４３はVRAM４４が内蔵されたグラフィックス処理回路、４５はCRTモニタ、４６はRAMである。
【０１０５】
このRAM４６には、実行時に、Windows95(米国Micro Soft社の商標) の上で動作するWWWブラウザであるNetscape Navigatorと、Javaインタプリタと、ソニー株式会社によって開発されたVRML２.0ブラウザであるCommunity Place Browserが読み込まれて、CPU３０によって実行される状態となっている。
【０１０６】
VRML２．０ブラウザには、米国シリコングラフィクス社によって開発され、無償公開されているVRMLの構文解釈用ライブラリ(パーサ)であるQvLibと、英国Criterion Software Ltd.のソフトウエア・レンダラであるRenderWare等、もしくはこれらと同等の機能を有するパーサやレンダラが実装されている。
【０１０７】
そして、 Community Place Browserは、図３に示すように、WWWブラウザとしてのNetscape Navigatorとの間において、NCAPI（Netscape Client Application Programing Interface）（商標）に基づいて各種データの授受を行う。
【０１０８】
Netscape Navigatorは、インターネット７を介してWWWサーバ１０よりHTMLファイルとVRMLコンテンツ(VRMLファイルとJavaによるスクリプトプログラムとを含む）の供給を受けると、これらをローカルのHDD３１にそれぞれ記憶させる。Netscape Navigatorは、このうちのHTMLファイルを処理してテキストや画像をCRTモニタに表示する一方、 Community Place BrowserはVRMLファイルを処理して3次元仮想空間をCRTモニタに表示するとともに、Javaインタプリタによるスクリプトプログラムの処理結果に応じて、3次元仮想空間内のオブジェクトの挙動、その他の表示状態を変化させる。
【０１０９】
なお、図示は省略するが、他のクライアントＰＣ２やクライアントＰＣ３も、クライアントＰＣ１と同様に構成されている。
【０１１０】
次に上述した一実施の形態の動作について説明する。
【０１１１】
まず、実際にVRMLコンテンツをインターネット経由でダウンロードしてから、１つの仮想空間を複数のユーザで共有するマルチユーザ環境とするまでの手順を図５乃至図７を参照して説明する。
【０１１２】
図５において、番号１で示すように、最初に、WWWブラウザを用いて、VRMLコンテンツを提供しているWebサイトのホームページを閲覧する。この例では、 http://pc.sony.co.jp/sapari/  を閲覧している。次に、番号２で示すように、クライアントＰＣ１とクライアントＰＣ２のユーザは、VRML  2.0fileと、VRML空間内での自律的な動き（Behavior）を実現するためのスクリプトプログラム（Javaによるスクリプトプログラム）とからなるVRMLコンテンツを、それぞれダウンロードする。
【０１１３】
勿論、 CD−ROMディスク３３で提供されるVRMLコンテンツをCD−ROMドライブ３２で読み込んでも良い。
【０１１４】
次に、図６に示すように、クライアントＰＣ１及びクライアントＰＣ２では、それぞれにダウンロードされ、一旦ローカルのHDD３１に格納されたVRML  2.0fileを、VRML２．０ブラウザであるCommunity Place Browserが解釈・実行し、さらに番号３で示すように、VSCP(Virtual Society Server Client Protocol)に基づいて、WLS１１に対して共有サーバ１２のURLを問い合わせる。このとき番号４で示すように、WLS１１はHDD１１aに格納された共有サーバURL管理テーブルを参照して、クライアントＰＣ１及びクライアントＰＣ２に対して、共有サーバ１２のURLを通知する。
【０１１５】
このURLを用いて、図７に示すように、クライアントＰＣ１とクライアントＰＣ２が、共有サーバ１２に接続する。その結果、番号５で示すように、この共有サーバ１２を介して共有3Dオブジェクトの位置や動きなどに関する共有メッセージの送信が行われ、番号６で示すように、その転送が行われ、マルチユーザ環境が実現される。
【０１１６】
なお、以上の接続手順の詳しい説明については、特開平9-81781号公報を参照されたい。
【０１１７】
また、ここでは、３次元仮想空間を、マルチユーザ環境で使用することとしているが、マルチユーザ環境で使用しないこと（以下、適宜、シングルユーザ環境という）、即ち、自身以外の他のユーザのアバタ（ドローンアバタ）を登場させないようにするとともに、自身のアバタ（パイロットアバタ）を、他のユーザのクライアントの３次元仮想空間に登場させないようにすることも可能である。これは、上述した番号３乃至６で表した処理を行わないようにすることで実現することができる。
【０１１８】
図６で説明したように、VRML２．０ブラウザであるCommunity Place Browser（クライアントＰＣ）において、VRML  2.0fileが解釈・実行されると、例えば、図８に示すような３次元仮想空間（の画像）が表示される。
【０１１９】
ここで、本実施の形態では、ブラウザ（VRML２．０ブラウザ）において、３次元仮想空間を撮影する撮影手段としてのカメラが想定され、そのカメラが３次元仮想空間を撮影することにより得られる画像（３次元仮想空間の画像）が提供されるようになされている。そして、３次元仮想空間における自己を表すパイロットアバタ（自己オブジェクト）の視点とカメラの位置とが一致している状態の１人称モードと、一致していない状態の３人称モードとを切り替えることができるようになされている。
【０１２０】
即ち、図８は、パイロットアバタの視点（３次元仮想空間におけるパイロットアバタの眼が位置している点の座標と、見ている方向（視線の方向）との両方を含む）と、カメラの位置（３次元仮想空間におけるカメラが位置している点の座標と、カメラの撮影方向との両方を含む）とが一致している状態の１人称モードの場合における表示画面を示している。この１人称モードにおいては、ユーザは、自身の分身としてのアバタ（パイロットアバタ）の視点で、３次元仮想空間内を自由に歩き回ることができる。従って、１人称モードでは、ユーザは、自身を表すパイロットアバタの姿を見ることはできない（但し、マルチユーザ環境では、他のユーザのアバタ（ドローンアバタ）が存在すれば、そのドローンアバタの姿は見ることができる）。
【０１２１】
１人称モードと３人称モードとの切替は、図８（後述する図９および図１８においても同様）に示したブラウザの左下に表示された切替ボタン５１を操作（例えば、マウス４１でクリック）することで行うことができるようになされている。即ち、図８に示したように、１人称モードでは、切替ボタン５１の表示は、３次元仮想空間を、パイロットアバタの視点から見ていることを象徴するものとなっており、これにより、ユーザが、１人称モードであることを容易に認識することができるようになされている。このような状態において、切替ボタン５１が操作されると、モードが、１人称モードから３人称モードに切り替えられる。
【０１２２】
即ち、図９は、３人称モードとされたときのブラウザの表示状態を示している。
【０１２３】
３人称モードでは、上述したように、パイロットアバタの視点とカメラの位置とが一致していない状態とされるが、１人称モードから３人称モードへの切り替え直後においては、後述するようにして、「カメラの標準位置」が計算され、その位置に、カメラが移動される。これにより、例えば、図９に示したように、自身を表すパイロットアバタ５２の頭上の後方から見たような３次元仮想空間の画像が表示される。即ち、いわば、ユーザを表すパイロットアバタ５２が幽体離脱を行い、幽体となったユーザが、自分自身としてのパイロットアバタ５２を見ているかのような画像が表示される。
【０１２４】
さらに、３人称モードとされると、切替ボタン５１の表示は、図９に示すように、３次元仮想空間を、パイロットアバタの頭上の後方から見ていることを象徴するものとされ、これにより、ユーザが、３人称モードであることを容易に認識することができるようになされている。
【０１２５】
従って、ユーザは、１人称モードと３人称モードとを切り替えることで、自分自身が仮想世界にいて、その仮想世界の中を歩き回っているかのような感覚と、幽体離脱をして、いわば幽体となった自分が、仮想世界の中にいる自分の行動を見ているかのような感覚とを、それぞれ享受することができる。
【０１２６】
なお、本実施の形態では、１人称モードと３人称モードとは、切替ボタン５１を操作するたびに、交互に切り替えられるようになされている。従って、例えば、図９に示した３人称モードの状態において、切替ボタン５１が操作されると、１人称モードとなり、画面は、図８に示したような表示状態に戻る。
【０１２７】
次に、以上のような１人称モードと３人称モードとの切替は、パイロットアバタの視点（パイロットアバタの眼の位置）とカメラの位置との一致、不一致で実現されるが、これらは、以下のように定義されるノードで実現される。
【０１２８】
まず、パイロットアバタの視点は、例えば、以下のように定義されるSony_Eyepoint（以下、適宜、単に、Eyepointとも記述する）ノードによって規定される。
【０１２９】
0003928229.tif 000002
【０１３０】
アバタを規定するアバタファイルの中には、１のEyepointノードを記述することができる。ここで、パイロットアバタは、それを規定するwrlファイル（アバタファイル）が、ブラウザに読み込まれることで、内部的に生成される。その内部構造は、VRMLの形式で記述すると、次のようになる。
【０１３１】
0003928229.tif 000003
【０１３２】
従って、パイロットアバタの生成は、内部的には、アバタファイル（上述の例では、xxx.wrlをインライン（Inline）することと等価である（また、そうあるべきである）。
【０１３３】
なお、ヘッドライト（HeadLight）は、ブラウザにおいて生成されるため、アバタファイルの中で記述する必要はない。また、パイロットアバタの方向は、アバタファイルの中でのワールド座標系、即ち、上述のTransform TR_PILOTにおいて規定されるローカル座標系の+y方向が上と、+z方向が前と、それぞれされる。
【０１３４】
パイロットアバタは、ユーザが、例えば、マウス４１を操作（ナビゲーション操作）することで、３次元仮想空間内を歩き回ることができる。即ち、ユーザによるナビゲーション操作が行われると、TR_PILOTと名前の定義されたTransformノードのtranslationフィールドやrotationフィールドが変更され、これにより、パイロットアバタは、３次元仮想空間内を移動する。なお、ここでは、VRMLコンテンツ側から、TR_PILOTに対してアクセスすることはできないようになされており、従って、VRML2.0の規定に反する方法で、パイロットアバタを移動させたり、その位置を知ることはできない。また、Transformノードのtranslationフィールドやrotationフィールドの変更は、ユーザによるナビゲーション操作の他、VRML2.0で規定されているViewpointノードの機能を使用することによっても行われる。
【０１３５】
上述したように、Eyepointノードは、アバタファイルの中に記述され、そのアバタファイルがパイロットアバタを規定するものとして読み込まれたときに、そのパイロットアバタの眼の位置を表す。このパイロットアバタの眼の位置は、通常、パイロットアバタの身体（例えば、頭部）に固定されており、「目の玉が飛び出る」などの特殊な演出を行う場合以外には動かない。
【０１３６】
また、ここでは、パイロットアバタの視線の方向については、Eyepointノードにおいて規定されているTR_EP座標系の+y方向を上として、-z方向が前（視線の向き）とされる。即ち、ここでは、視線の方向は、VRML2.0のViewpointノードのデフォルトの向きに一致するようになされている。但し、一致させる必要は、必ずしもない。
【０１３７】
Eyepointノードは、ここでは、アバタのメインファイルの中でのみ有効とされている。また、上述したように、アバタファイルの中には、１のEyepointノードを記述することができるが、複数のEyepointノードが記述されている場合には、最初に（先頭に）記述されているものだけが有効になる。これは、VRML2.0のバインドのメカニズムに準拠したものである。
【０１３８】
Eyepointノードの中のchildrenフィールドには、常時、パイロットアバタの視線の方向に一致させる必要のあるものが記述される。後述するように、カメラの位置は、Sony_Renderingpointノードによって規定されるが、このSony_Renderingpointノードを、Eyepointノードの中のchildrenフィールドが指す先に作ることで、EyepointノードおよびSony_Renderingpointノードを一致、即ち、パイロットアバタの視点とカメラの位置とを一致させることができ、これにより、１人称モードを実現することができる。
【０１３９】
なお、アバタファイルに、Eyepointノードが１つも記述されていない場合には、アバタファイルの読み込み時に、デフォルトのEyepointノードが追加され、これにより、パイロットアバタの内部構造は、次のようにされる。
【０１４０】
0003928229.tif 000004
【０１４１】
デフォルトのEyepointノードでは、パイロットアバタが、標準的な大人の体型をしていると仮定して、１．６ｍの高さに、パイロットアバタの眼が付けられる。なお、１．６ｍというのは、NavigationInfoのavatarSizeで指定される「視点の位置」のデフォルトの高さと一致する値である。NavigationInfoが明示的に記述された場合には、そこで規定されている値にしたがって、パイロットアバタの中のTR_EP_POSITIONのtranslationフィールドとrotationフィールドが設定され、これにより、パイロットアバタの眼の位置（Eyepoint）が、NavigationInfoの記述内容と一致するようにされる。
【０１４２】
なお、デフォルトのEyepointノードが付加されたパイロットアバタでは、TR_EP_POSITIONのrotationフィールドにおいて、 眼の位置（Eyepoint）を3.141592、即ち、π［ラジアン］（１８０度）だけ回転させているが、これは、Eyepointによって規定されるパイロットアバタの視線の方向が、上述したことから、ローカル座標系における-z方向になるので、パイロットアバタの正面方向と、その視線の方向とを一致させるためである。
【０１４３】
Eyepointノードは、アバタファイルに記述されていれば、そのアバタファイルの読み込み時にバインドされ、また、アバタファイルに記述されていなければ、アバタファイル読み込み時に自動的に追加されてバインドされる。従って、Eyepointノードが、実行時に生成されても、即ち、パイロットアバタのシーングラフに追加されても、特に何も起こらない。これは、Eyepointノードが、上述したようにバインド（binding）機構に基づいているものであることによる。
【０１４４】
さらに、Eyepointノードは、ここでは、VRMLコンテンツ側からはアクセスすることができないようになされており、従って、実行時に、バインドされているEyepointノードを削除することができるのは、そのEyepointノードが、アバタファイルの中に最初から記述されているものである場合に限られる。バインドされているEyepointノードが削除された場合、アバタファイルの中にEyepointノードが記述されていない場合と同様に、デフォルトのEyepointノードが追加される。従って、デフォルトのEyepointノードがバインドされた場合、そのEyepointノードを、VRMLコンテンツ側から削除することはできない。
【０１４５】
バインドされているEyepointノードを含むローカル座標系自体が変更された場合（移動した場合）、即ち、Eyepointノードの、いわゆる親のTransformノードより上位階層において、移動が生じた場合であっても、ユーザによるナビゲーション操作時や、Viewpointのバインドによるパイロットアバタの移動時などにおけるアルゴリズムがそのまま適用されるため、Eyepointノードを、特別に操作する必要はない。
【０１４６】
次に、Eyepointノードがバインドされたパイロットアバタは、ユーザによるナビゲーション操作によって、３次元仮想空間（ワールド）内を移動するが、このパイロットアバタの移動について説明する。なお、VRML2.0の仕様では、ナビゲーション操作時における上は、Viewpointノードが属するローカル座標系の+y方向であると規定されているので、これを前提とする。また、VRML2.0で規定されているViewpointノードは、それがバインドされたときに、カメラの位置をどこに移動させるかという、いわば行き先を表すものであり、従って、Viewpointノードがバインドされた瞬間においては、Viewpointとカメラの位置とは一致するが、ナビゲーション操作によって、パイロットアバタが移動すれば、Viewpointとカメラの位置とは一致しなくなる。なお、ある瞬間のカメラの位置は、ProximitySensorを使用して、イベントとして取り出すことができる。
【０１４７】
あるViewpointノードがバインドされ、バインドされたViewpointノードが変更されない状態でのパイロットアバタの移動は、ブラウザにおいて、そのパイロットアバタが属するローカル座標系（TR_PILOTを含んでいるTransformノードによって規定されるローカル座標系（以下、適宜、パイロット移動空間座標系という））の中での移動として解釈される。
【０１４８】
例えば、パイロットアバタを、前に移動させると（前に移動させるように、ナビゲーション操作が行われると）、ブラウザでは、パイロット移動空間座標系での水平方向であるxz平面に沿って、パイロットアバタが移動される。即ち、具体的には、TR_PILOTのtranslationフィールドのxやzが書き換えられる。但し、これは、重力や地面の起伏などがない場合で、ある場合には、yの書き換えも行われることがある。
【０１４９】
また、例えば、パイロットアバタをパン（pan）方向に回転させると、ブラウザでは、TR_PILOTのrotationフィールドが書き換えられる。
【０１５０】
さらに、例えば、パイロットアバタの首を上下に移動させると、ブラウザでは、Eyepointノードにおいて定義されているTR_EPのrotationフィールドが書き換えられ、これにより、パイロットアバタの視点（視線）が上下する。
【０１５１】
なお、ここでは、パイロットアバタの移動を実現するために書き換えられるTR_PILOTのtranslationフィールドおよびrotationフィールド、並びにTR_EPのrotationフィールドは、いずれも、VRMLコンテンツ側からはアクセス不可能とされている。これらのフィールドの値、即ち、パイロットアバタの位置や向き、視点を変更し、また、それらを知るためには、VRML2.0に規定されている手法を用いる必要がある。
【０１５２】
あるViewpointノードがバインドされると、そのViewpointを含んでいるローカル座標系が、パイロット移動空間座標系となり、パイロットアバタの状態（transformation）は、以下のように調整される。
【０１５３】
即ち、パイロットアバタは、常に、パイロット移動空間座標系の中を垂直にたっており、従って、パイロット移動空間座標系において、パン方向に回転するが、チルト（tilt）方向や、ロール（roll）方向には回転しない（傾かない）。さらに、Viewpointノードがバインドされた瞬間においては、Eyepoint（パイロットアバタの視点）は、Viewpointノードで指定された点（位置）および方向に一致する。また、Eyepointは、パイロットアバタに対して、パン方向には回転しないが、チルト方向やロール方向には回転する。従って、パイロットアバタに対して、パイロット移動空間座標系における、ある方向が与えられた場合、パン方向は、TR_PILOTで調整され、チルト方向およびロール方向は、Eyepointで調整される。
【０１５４】
感覚的にいうと、パイロットアバタは、常に、身体を垂直にしている。さらに、首を傾け（かしげ）たり、うなずいたりはするが、横には振らない。
【０１５５】
以上は、バインドされたViewpointノードのjumpフィールドがTRUEとされている場合であるが、jumpフィールドがFALSEとされているViewpointノードがバインドされた場合においては、その新たなViewpointノードが属するローカル座標系、即ち、新たなパイロット移動空間座標系の+y方向に、パイロットアバタの上方向が一致するように調整される。但し、ワールド座標系におけるパイロットアバタの位置およびEyepointは、いずれも変更されない。
【０１５６】
次に、カメラの位置は、例えば、以下のように定義されるSony_Renderingpoint（以下、適宜、単に、Renderingpointとも記述する）ノードによって規定される。
【０１５７】
0003928229.tif 000005
【０１５８】
Renderingpointノードのフィールドがデフォルト値になっている場合、カメラの前は-z方向に、上は+y方向に、それぞれされる。ブラウザでは、Renderingpointノードのpositionフィールドで指定される点から、orientationフィールドで指定された方向の３次元仮想空間を、カメラで撮影したときに得られる画像が表示される。この画像は、Viewpointがバインドされた瞬間に表示されるものと一致する。但し、Viewpointノードのpositionフィールドおよびorientationフィールドは、そのViewpointをバインドした瞬間におけるユーザの視点を設定するための書き込み専用のフィールドである。これに対して、Renderingpointノードのpositionフィールドおよびorientationフィールドは、パイロットアバタを（に）追従するカメラの位置をリアルタイムに表す。即ち、カメラの位置は、Renderingpointノードのpositionフィールドおよびorientationフィールドのフィールド値を読み出すことで認識することができる。
【０１５９】
Renderingpointノードの中のHEAD_LIGHTは、VRML2.0で規定されているNavigationInfo.headlightで定義されている平行光のヘッドライト(DirectionalLight)で、このDirectionalLightには、Renderingpointからアクセスすることはできない。このため、ヘッドライトの向き（方向）を、常に、Renderingpointの方向に一致させるために、HEAD_LIGHTは、Renderingpointノードの中に明示的に記述されている。
【０１６０】
Renderingpointノードの中のtypeでは、カメラの自動追従機能を働かせるか否か、即ち、カメラを、パイロットアバタに追従させるかどうかが指定される。typeとして、MANUALが指定された場合、カメラの自動追従機能は働かず、ブラウザが、Renderingpointノードのpositionフィールドやorientationフィールドを、勝手に変更することはない。一方、typeとして、AUTOが指定された場合、カメラの自動追従機能が働き、ブラウザにおいて、パイロットアバタを追従するように、Renderingpointノードのpositionフィールドやorientationフィールドが自動的に変更される。
【０１６１】
なお、typeとして、AUTOが指定された場合には、ブラウザにおいて、Renderingpointノードの中のparameterフィールドの値にしたがって、カメラが移動される。parameterフィールドの解釈は、ブラウザに依存し、上述のRenderingpointノードの定義では、カメラを、パイロットアバタの頭上の後方に位置させることを意味するSEE_PILOT_BACKが規定されている。上述のように、parameterフィールドの解釈は、ブラウザに依存するから、例えば、カメラを、パイロットアバタの頭上の前方に位置させることを意味するSEE_PILOT_FRONTをさらに規定し、VRMLコンテンツに、SEE_PILOT_BACKや、SEE_PILOT_FRONTを、parameterフィールドに設定することを許可すれば、VRMLコンテンツ側から、ブラウザによるカメラの位置制御を制御することが可能となる。
【０１６２】
Renderingpointノードは、ここでは、アバタのメインファイルまたはワールドのメインファイルの中でのみ有効とされている。また、Renderingpointノードが、メインファイルの中に複数記述されている場合には、VRML2.0のバインドメカニズムに準拠して、最初の１つのみが有効とされる。さらに、Renderingpointノードが、アバタのメインファイルおよびワールドのメインファイルの両方に記述されている場合には、そのうちのいずれか一方、即ち、例えば、ワールドのメインファイルに記述されているものが有効とされる。
【０１６３】
Renderingpointノードが、メインファイルに明示的に記述されていない場合には、デフォルトのRenderingpointノード（フィールドに、デフォルト値が設定されたRenderingpointノード）が、パイロットアバタのEyepointの子供（children）として生成される。従って、この場合、RenderingpointとEyepointとは一致する（Renderingpointによって規定される点または方向と、Eyepointによって規定される点または方向とは、それぞれ一致する）。そして、ユーザによるナビゲーション操作が行われた場合や、新たなViewpointがバインドされた場合には、Renderingpointは、Eyepointと同様に移動する。このRenderingpointの移動にしたがって、カメラの位置（カメラが位置する点および方向）が変化するので、ブラウザにおいて、ナビゲーション操作や、新たなViewpointのバインドによるパイロットアバタの移動の様子（パイロットアバタの移動により見える３次元仮想空間）が、インタラクティブに表示される。
【０１６４】
１人称モードは、RenderingpointとEyepointとを一致させること、即ち、Renderingpointのフィールドをデフォルト値とすることで実現することができる。また、３人称モードは、RenderingpointとEyepointとを一致させないこと、即ち、Renderingpointのフィールドをデフォルト値以外の値とすることで実現することができる。具体的には、例えば、Renderingpointのpositionを、左上の手前側の点に設定するとともに、orientationを、その点から原点を見るような方向に設定すると、ブラウザでは、パイロットアバタの左斜め後方から、パイロットアバタを見渡すような画像が表示される。この状態で、ナビゲーション操作を行うと、パイロットアバタは、その操作にしたがって、３次元仮想空間を歩き回るが、ブラウザでは、歩き回るパイロットアバタが画面の同一位置に固定された状態の画像であって、背景である３次元仮想空間がパイロットアバタの移動にしたがって変化するものが表示される。
【０１６５】
従って、例えば、VRMLコンテンツによって、Renderingpointのpositionやorientationを、パイロットアバタの移動に対応して変化させるようにした場合には、３次元仮想空間を歩き回るパイロットアバタを、各種のアングルから撮影した画像を表示する、いわばVRMLコンテンツによるカメラワークを実現することができる。なお、この場合でも、パイロットアバタは、画面の同一位置に固定される。但し、これは、Renderingpointを、アバタファイル（パイロットアバタのメインファイル）に記述した場合で、ワールドのメインファイルに記述した場合には、パイロットアバタを、画面上のどの位置に表示するかは、パイロットアバタの動きに無関係に制御することが可能となる。
【０１６６】
即ち、例えば、パイロットアバタが、奥側に移動しているとした場合、Renderingpointが、アバタファイルに記述されているときには、パイロットアバタの表示位置が不変で、周りの景色が、手前側に動く画面が表示される。一方、Renderingpointが、ワールドのメインファイルに記述されているときには、カメラを動かさないようにして、パイロットアバタが、奥側に移動して、徐々に小さくなっていくような画面を表示することができる。
【０１６７】
次に、実行時におけるRenderingpointに対する操作について説明する。
【０１６８】
Renderingpointが、アバタファイルおよびワールドのメインファイルのうちのいずれにも明示的に記述されていない場合には、Renderingpointは、アバタファイルの読み込み時に、ブラウザにおいて、Eyepointの子供（children）として生成される。ここでは、VRMLコンテンツが、Renderingpointそのものを操作しないこととし、従って、VRMLコンテンツ側では、EyepointやViewpointに対する操作が、Renderingpointに与える影響を考慮すれば良い。
【０１６９】
また、ユーザによるナビゲーション操作によって、パイロットアバタが移動したり、また、その視点（視線）が変化（回転）した場合には、その移動や変化にしたがって、Renderingpointが変更されるので、特に操作を行う必要はない。
【０１７０】
さらに、新たなViewpointがバインドされた場合も、Eyepointのシーングラフの中における場所（位置）、並びにその幾何学的な位置および方向が計算され、それらにしたがって、Renderingpointが変更されるので、やはり、特に操作を行う必要はない。
【０１７１】
また、Eyepointのバインディングが変化した場合には、Renderingpointは、新しくバインドされたEyepointの子供（children）になるように、シーングラフの中における場所が変更され、Renderingpointの位置（カメラが位置する点と撮影方向）は、新たにバインドされたEyepointから計算される。従って、この場合も、Renderingpointに対する操作は、特に必要ない。
【０１７２】
一方、Renderingpointが、アバタファイルまたはワールドのメインファイルに明示的に記述されている場合には、そのRenderingpointがシーングラフから削除されるまでは、特に操作を行う必要はない。即ち、この場合、Renderingpointは、ViewpointやEyepointの位置の移動、それらのバインディングの変化による影響を受けない。
【０１７３】
また、バインドされていたRenderingpointが、シーングラフから削除された場合には、そのときバインドされているEyepointのchildrenとして、Renderingpointが生成される。以後は、Renderingpointが、アバタファイルおよびワールドのメインファイルのうちのいずれにも明示的に記述されていない場合と同様である。
【０１７４】
次に、上述したように、１人称モードは、RenderingpointとEyepointとを一致させることで実現することができ、３人称モードは、RenderingpointとEyepointとを一致させないことで実現することができるが、ここでは、３人称モードとされたときに、ユーザが、幽体離脱をしているかのような感覚を、より強く享受することができるように、カメラの位置、即ち、ユーザの視点が移動されるようになされている。
【０１７５】
ここでは、幽体となったユーザが、パイロットアバタの行動を見ているかのような、いわば、それらしい位置に、パイロットアバタが表示されるように、以下に説明するアルゴリズムにしたがって、カメラが移動される。ブラウザ側からのカメラの位置の制御は、Renderingpointノードの中のtypeとして、AUTOを指定して、カメラの自動追従機能を働かせ、これにより、パイロットアバタを追従するように、Renderingpointノードのpositionフィールドやorientationフィールドを自動的に変更させるようにすることで行うことができる。
【０１７６】
ここで、以下説明するアルゴリズムによるのが、必ずしも、パイロットアバタを「それらしい」位置に表示することができるとは限らないので、場合によっては（例えば、VRMLコンテンツの制作者側の意図していない位置に、カメラが移動され、これにより、パイロットアバタを「それらしい」位置に表示することができない場合には）、VRMLコンテンツ側において、カメラの移動を制御するようにしても良い。VRMLコンテンツ側からのカメラの位置制御は、例えば、パイロットアバタが、VRMLコンテンツ側でカメラを制御したい領域に侵入した場合に、Renderingpointノードの中のtypeとして、MANUALを指定して、カメラの自動追従機能を働かせないようにすることで行うことが可能となる。
【０１７７】
VRML2.0ブラウザであるCommunity Place Browserでは、３人称モードとされた場合、（１）パイロットアバタが歩き回れる範囲が、ある程度広い、（２）パイロットアバタが屋根のある空間に入った場合における、その屋根は、ある程度高い、（３）地平線の起伏が、あまり激しくない、ということを前提として、以下のような処理が行われる。なお、以下説明する処理は、例えば、Renderingpointノードの中のparameterとして、SEE_PILOT_BACKが指定されている場合のものである。但し、上述したように、parameterフィールドの解釈はブラウザに依存するから、SEE_PILOT_BACKが指定されている場合に、ブラウザに、以下のような処理以外の処理を行わせるようにすることも可能である。
【０１７８】
本実施の形態では、図１０のフローチャートに示すように、まず最初に、ステップＳ１において、後述するようにして、パイロットアバタのEyepointに基づいて、カメラの標準位置が計算され、ステップＳ２に進み、ステップＳ１で求められたカメラの標準位置に、カメラの位置、つまり、Renderingpointが移動される。そして、ステップＳ３に進み、パイロットアバタが瞬間移動したかどうかが判定される。
【０１７９】
ここで、本実施の形態では、パイロットアバタが瞬間移動した場合というのは、（１）ワールドが読み込まれた場合、（２）Viewpointがバインドされた場合、（３）バインドされているViewpointの中のpositionフィールドやorientationフィールドに書き込みが行われ、これにより、パイロットアバタの位置が変化した場合をいっている。
【０１８０】
ステップＳ３において、パイロットアバタが瞬間移動したと判定された場合、ステップＳ１に戻り、瞬間移動後のパイロットアバタのEyepointに基づいて、カメラの標準位置が計算され、以下、同様の処理が繰り返される。
【０１８１】
また、ステップＳ３において、パイロットアバタが瞬間移動していないと判定された場合、ステップＳ４に進み、パイロットアバタのEyepointが、ユーザによるナビゲーション操作によって移動（変化）したかどうかが判定される。ステップＳ４において、パイロットアバタのEyepointが変化していないと判定された場合、ステップＳ５に進み、切替ボタン５１が操作されたか否かが判定される。ステップＳ５において、切替ボタン５１が操作されたと判定された場合、即ち、３人称モードから１人称モードへの切り替えが行われた場合、３人称モードの処理を終了する。なお、その後は、RenderingpointとEyepointとを一致させる１人称モードの処理が行われる。
【０１８２】
また、ステップＳ５において、切替ボタン５１が操作されていないと判定された場合、ステップＳ３に戻り、以下、同様の処理を繰り返す。
【０１８３】
一方、ステップＳ４において、パイロットアバタのEyepointが変化したと判定された場合、ステップＳ６に進み、その変化後のEyepointに基づいて、カメラを移動させる位置（カメラを位置させる点と、その撮影方向）（以下、適宜、カメラの移動位置という）が、後述するようにして計算される。そして、カメラの移動位置、即ち、Renderingpointの変更値が求められると、ステップＳ７に進み、求められたカメラの移動位置に、カメラの位置、即ち、Renderingpointが移動される。その後は、ステップＳ４に戻り、以下、同様の処理を繰り返す。
【０１８４】
次に、図１１および図１２を参照して、図１０のステップＳ１におけるカメラの標準位置の計算処理について説明する。
【０１８５】
カメラの標準位置の計算処理では、図１１のフローチャートに示すように、まず最初に、ステップＳ１１において、Eyepointから、パイロットアバタの視線の方向に一致する直線が求められる。即ち、Eyepointから、図１２に示すような、パイロットアバタの視線の方向に一致する直線（パイロットアバタの視点を通り、その視線に平行な直線）ＡＢが求められる。
【０１８６】
そして、ステップＳ１２に進み、Eyepoint、即ち、パイロットアバタの視点が位置する点をＡとして、図１２に示すように、xz平面に垂直で、直線ＡＢを含む平面内にあり、かつ直線ＡＢとなす仰角が、あらかじめ設定された所定の角度αの直線であって、点Ａを通る直線Ｌが求められ、ステップＳ１３に進む。ステップＳ１３では、図１２に示すように、直線Ｌ上の点であって、点Ａからの距離が、後述するようにして求められるβである点Ｃが求められ、ステップＳ１４に進む。
【０１８７】
ステップＳ１４では、点Ｃが、カメラの標準位置を表す座標点とされるとともに、Eyepointの方向と一致する方向が、カメラの標準位置におけるカメラの撮影方向とされ、リターンする。なお、ここでは、カメラは、ロール方向の回転をしないものとされており、従ってカメラの撮影方向は、パン角とチルト角によって規定される。
【０１８８】
次に、カメラの標準位置を規定するパラメータの１つである、上述のβ（図１２）は、例えば、図１３に示すように、カメラの標準位置から撮影を行うことにより得られる画像の幅（横幅）γが、パイロットアバタの幅（横幅）ａの所定数倍に一致するようになる距離に設定されており、これにより、カメラが、カメラの標準位置に移動された場合に、パイロットアバタとともに、そのパイロットアバタの視線方向の風景がある程度見えるような画像が得られるようになされている。
【０１８９】
即ち、図１３は、パイロットアバタを、-y方向に向かって見たもの（パイロットアバタの頭上から見たもの）を表している。
【０１９０】
いま、カメラの視野角（水平視野角）をεとするとともに、パイロットアバタの横幅をａとする。さらに、直線Ｌ（図１２）上の点にカメラを設置して、Eyepointの方向と一致する方向を撮影したときに得られる画像の横幅をγとする。ここでは、例えば、γ＝５ａと設定されており、これにより、パイロットアバタの左右それぞれに、２ａの幅の背景が見えるような画像が得られるようになされている。従って、この場合、βは、以下の式により得られることになる。
【０１９１】
β＝γ／（２×ｔａｎ（ε／２））
なお、カメラの視野角εは、VRML2.0では、ViewpointノードのfieldOFViewフィールドによって規定される。
【０１９２】
以上のように、３人称モードとされたとき（直後）においては、パイロットアバタの視点にしたがって、カメラの位置が、カメラの標準位置に移動され、これにより、パイロットアバタとともに、パイロットアバタが見ている風景が表示された画像が表示される。従って、ユーザは、幽体離脱をしたかのような感覚を享受することができる。
【０１９３】
なお、カメラの標準位置から撮影された画像は、パイロットアバタが、xz平面に平行な方向を見ている場合には、その頭上の後方から、パイロットアバタを見おろしているようなものとなる。
【０１９４】
また、Renderingpointは、通常、例えば、Eyepointなどとは別の座標系に属しているため、カメラの標準位置の計算にあたっては（後述するカメラの移動位置の計算についても同様）、座標変換が必要となる。
【０１９５】
次に、３人称モードとされた状態においては、パイロットアバタの視点、即ち、Eyepointが変化するごとに、その変化後のEyepointに基づいて、カメラの標準位置を計算し、カメラの位置（Renderingpoint）を移動しても良いが、この場合、幽体となったユーザは、常に、パイロットアバタの背後からの画像しか見ることができず、幽体である自分が、下界の自分を観察しているような感覚が薄れることがある。即ち、幽体であるからには、いわば、ふわふわ、若しくはゆらゆらといった感じで、パイロットアバタを背後を追跡している様子の画像が表示されるのが、幽体離脱の感覚を享受する観点からは好ましい。
【０１９６】
そこで、ここでは、３人称モードとされた後に、パイロットアバタ（Eyepoint）が移動されたときに、そのような画像が表示されるように、カメラが移動されるようになされている。
【０１９７】
即ち、図１０のステップＳ６では、図１４および図１５に示すようにして、移動後のパイロットアバタの位置において、１人称モードから３人称モードとされたときに、カメラが移動される位置（カメラの標準位置）と、パイロットアバタが移動する前におけるカメラの位置との間を補間する位置（以下、適宜、補間位置という）が、カメラの移動位置として求められる。
【０１９８】
具体的には、図１４のフローチャートに示すように、まず最初に、ステップＳ２１において、移動後のパイロットアバタのEyepointに基づき、図１１乃至図１３で説明したようにして、カメラの標準位置（以下、適宜、新しいカメラの標準位置という）Ａが求められ、ステップＳ２２に進む。ステップＳ２２では、図１５に示すように、移動後のパイロットアバタ（Eyepoint）の座標点Ｏを中心とし、ＯＡを半径とする球面Ｓが求められる。さらに、ステップＳ２２では、直前のカメラの位置Ｃと、点Ｏとを通る直線Ｌが求められ、この直線Ｌと、球面Ｓとの交点Ｂが求められる。
【０１９９】
そして、ステップＳ２３に進み、図１５に示すように、点Ａと点Ｂとを結ぶ線分ＡＢの中点Ｄが、補間位置として求められ、これが、カメラの移動位置とされて、リターンする。
【０２００】
なお、カメラの移動位置における撮影方向は、図１５において、点Ｄから点Ｏへの方向、あるいは、移動後のパイロットアバタのEyepointの方向とされる。
【０２０１】
以上のようなカメラの移動位置を計算し、そこに、カメラを移動させるようにした場合には、カメラの動き量は、パイロットアバタの動き量よりも少なくなり、いわばアニメーション的に動く画像が表示されることになる。即ち、ユーザには、幽体が、パイロットアバタを、パイロットアバタの動きより幾分少ない動きで追いかけているような画像が提供される。
【０２０２】
ところで、上述の場合においては、例えば、図１６（Ａ）に示すように、パイロットアバタが動くと、同図（Ｂ）に示すように、カメラも即座に動くため、幽体が、ふらふらした感じで、パイロットアバタを追いかけているような感覚が得られないことがある。
【０２０３】
そこで、例えば、図１７（Ａ）に示すように、パイロットアバタが動いた後、カメラの移動は、同図（Ｂ）に示すように、所定の遅延時間をおいてから開始するようにすることができる。即ち、図１７の実施の形態では、パイロットアバタが反時計回りに９０度だけ回転（パン）しており、カメラの移動は、パイロットアバタの回転が終了した後に開始されている。その結果、ブラウザの表示画像は、例えば、図９に示したように、自身を表すパイロットアバタ５２の背中が見えているものから、パイロットアバタ５２の回転にしたがって、その左の横顔が徐々に見えるものに変化していき、回転が終了すると、図１８に示すように、パイロットアバタ５２の左側面が完全に見えるようなものとなる。その後、カメラの移動（ここでは、回転）が開始され、ブラウザの表示画像は、パイロットアバタ５２を背後方向からのものに徐々に変化していく。
【０２０４】
この場合、幽体が、ふらふらした感じで、パイロットアバタを追いかけているような感覚を享受することができる。
【０２０５】
なお、図１６および図１７は（後述する図１９、図２０も同様）、-y方向に向かって見たパイロットアバタとカメラを表している。
【０２０６】
次に、上述の場合には、カメラの移動を、パイロットアバタが動いた後、所定の遅延時間をおいてから開始させるようにしたが、カメラの移動は、その他、例えば、パイロットアバタがカメラの撮影範囲外に出そうになったときに開始させることも可能である。
【０２０７】
即ち、図１９（Ａ）に示すように、パイロットアバタが、カメラの撮影範囲にいる場合は、カメラを移動させない（但し、この場合でも、カメラを、パイロットアバタとの距離が、図１２および図１３で説明したβに維持されるように移動させるようにしても良い）。そして、同図（Ｂ）に示すように、パイロットアバタがカメラの撮影範囲外に出そうになったときに、カメラの移動を開始させ、パイロットアバタがカメラの撮影範囲外に出ないようにする。
【０２０８】
この場合も、幽体が、ふらふらした感じで、パイロットアバタを追いかけているような感覚を享受することができる。
【０２０９】
また、カメラの撮影範囲は、カメラを基準として定められる範囲であるが、そのような範囲から、パイロットアバタが出そうな場合の他、例えば、パイロットアバタを基準として定められる範囲を考え、カメラの移動は、パイロットアバタが動くことにより、そのような範囲から、カメラが出そうになった場合に開始させることも可能である。
【０２１０】
即ち、例えば、図２０（Ａ）に示すように、パイロットアバタの視野と同一の範囲を、パイロットアバタの背後に想定する。そして、パイロットアバタが動くことにより、同図（Ｂ）に示すように、その背後に想定した範囲（以下、適宜、反対視野という）外に、パイロットアバタが出そうになった場合に、カメラの移動を開始させ、カメラが反対視野の範囲外に出ないようにする。
【０２１１】
この場合も、幽体が、ふらふらした感じで、パイロットアバタを追いかけているような感覚を享受することができる。
【０２１２】
以上のように、パイロットアバタの視点とカメラの位置とを一致させる１人称モードと、それらを一致させない３人称モードとを設けるようにしたので、ユーザは、これらのモードを切り替えることで、自身が仮想世界にいるような感覚と、幽体離脱をしているかのような感覚とのいずれをも享受することができる。
【０２１３】
さらに、３人称モードとされたときには、アバタの視点（Eyepoint）に基づいて、ユーザに提供する画像を撮影するカメラの位置を制御するようにしたので、ユーザの視点を、ダイナミックに、幽体離脱をしている自分がパイロットアバタを追いかけているかのような感覚を得ることができるような適切な位置に変えることができる。
【０２１４】
なお、以上の各種の処理を実行するプログラムは、フロッピーディスク、CD-ROMディスク、その他の記録媒体に記録して提供したり、インターネット、その他のネットワークを介して伝送することで提供することができる。
【０２１５】
また、例えば、カメラの標準位置の計算などは、ブラウザおよびVRMLコンテンツのうちのいずれに行わせても良い。
【０２１６】
さらに、３人称モードとされたときの画像は、アバタの視点（Eyepoint）およびカメラの位置（Renderingpoint）という概念を用いなくても提供可能であるが、マルチユーザ環境においては、アバタの視点およびカメラの位置を導入し、これらを分離するようにしないと、３次元仮想空間に表示されたパイロットアバタを、他のユーザのクライアントＰＣに表示させることが困難となる。
【０２１７】
【発明の効果】
請求項１に記載の表示制御装置および請求項７に記載の表示制御方法、並びに請求項８に記載の記録媒体によれば、３次元仮想空間における自己を表す自己オブジェクトの視点と撮影手段の位置とが一致している状態の１人称モードと、一致していない状態の３人称モードとが切り替え可能であり、３人称モードとされたときに、自己オブジェクトの視点にしたがって、撮影手段の位置が制御され、３人称モードの状態において、自己オブジェクトの視点が変化したとき、所定の遅延時間をおいて撮影手段の移動が開始されるように、変化後の自己オブジェクトの視点に基づいて、撮影手段の移動が制御される。従って、ユーザの視点を、自己オブジェクトの視点にしたがって、ダイナミックに適切な位置に変えることができ、これにより、ユーザに、各種の感覚を享受させることが可能となる。
【図面の簡単な説明】
【図１】センサー、イベント、ルーティング、およびスクリプトの関係を説明する図である。
【図２】ルーティングを説明する図である。
【図３】本発明を適用した共有仮想空間提供システムの構成例を示すブロック図である。
【図４】図１のクライアントＰＣ１の構成例を示すブロック図である。
【図５】図３のシステムの動作を説明するディスプレイの写真である。
【図６】図３のシステムの動作を説明するディスプレイの写真である。
【図７】図３のシステムの動作を説明するディスプレイの写真である。
【図８】ブラウザの表示画面を示すディスプレイの写真である。
【図９】ブラウザの表示画面を示すディスプレイの写真である。
【図１０】３人称モードの処理を説明するためのフローチャートである。
【図１１】図１０におけるステップＳ１の処理の詳細を説明するためのフローチャートである。
【図１２】カメラの標準位置の計算方法を説明するための図である。
【図１３】カメラの標準位置の計算方法を説明するための図である。
【図１４】図１０におけるステップＳ６の処理の詳細を説明するためのフローチャートである。
【図１５】カメラの移動位置の計算方法を説明するための図である。
【図１６】パイロットアバタの動きとカメラの動きとの関係を示す図である。
【図１７】パイロットアバタの動きとカメラの動きとの関係を示す図である。
【図１８】ブラウザの表示画面を示すディスプレイの写真である。
【図１９】パイロットアバタの動きとカメラの動きとの関係を示す図である。
【図２０】パイロットアバタの動きとカメラの動きとの関係を示す図である。
【符号の説明】
１乃至３  クライアントＰＣ，  ７  インターネット，  １０  WWWサーバ，１２  共有サーバ，  ３０  CPU，  ３１  ハードディスク，  ３９  モデム，  ４５  CRTモニタ，  ４６  RAM，  ５１  切替ボタン，  ５２  パイロットアバタ
【図１】
0003928229.tif 000006
【図２】
0003928229.tif 000007
【図３】
0003928229.tif 000008
【図４】
0003928229.tif 000009
【図５】
0003928229.tif 000010
【図６】
0003928229.tif 000011
【図７】
0003928229.tif 000012
【図８】
0003928229.tif 000013
【図９】
0003928229.tif 000014
【図１０】
0003928229.tif 000015
【図１１】
0003928229.tif 000016
【図１２】
0003928229.tif 000017
【図１３】
0003928229.tif 000018
【図１４】
0003928229.tif 000019
【図１５】
0003928229.tif 000020
【図１６】
0003928229.tif 000021
【図１７】
0003928229.tif 000022
【図１８】
0003928229.tif 000023
【図１９】
0003928229.tif 000024
【図２０】
0003928229.tif 000025