JP2007018517A

JP2007018517A - ３次元オブジェクト共有処理方法及び記憶媒体

Info

Publication number: JP2007018517A
Application number: JP2006189839A
Authority: JP
Inventors: Mitsunori Hirata; 光徳平田; Yuichi Sato; 裕一佐藤
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2006-07-10
Filing date: 2006-07-10
Publication date: 2007-01-25

Abstract

【課題】３次元オブジェクト共有処理方法に関し、ウィンドウサイズやメニューバーの位置は任意な状態で、コンピュータ間で３次元オブジェクトをインタラクティブに、且つ、各ローカルサイトにおける操作に対応できるように共有する。
【解決手段】ネットワークを介して接続された複数のコンピュータシステムの間で３次元オブジェクトを共有する処理方法において、各コンピュータにおいて行われる３次元オブジェクトに対する操作コマンドにより発生する３次元オブジェクトの変化を示す選択部品の番号及び部品位置座標を含む変化情報に基づいて、各コンピュータにおいて保持される３次元オブジェクトのデータが一致するよう更新し、受信側のコンピュータにおいて、動的間引き同期処理、ＬＯＤ動的間引き同期処理、長時間処理同期処理、停止位置同期処理、パス再生同期処理及び待機同期処理の少なくとも１つの処理を行うように構成する。
【選択図】図１３

Description

本発明は３次元オブジェクト共有処理方法及び記憶媒体に係り、特にコンピュータ上で構築された３次元オブジェクトをネットワークで繋がったコンピュータ同士で共有して処理を行う３次元オブジェクト共有処理方法、及びコンピュータにこのような３次元オブジェクト共有処理方法で３次元オブジェクトの処理を行わせるプログラムを格納したコンピュータ読み取り可能な記憶媒体に関する。

本明細書では、３次元オブジェクトとは、３次元グラフィックスモデル等の抽象モデルを意味する。又、３次元オブジェクトの処理とは、３次元オブジェクトに対して移動、回転、拡大、縮小、視点変更、クリッピング、干渉チェック、アノテーション等のコンピュータ上で処理可能な任意の操作を行うことを意味する。更に、本発明になる３次元オブジェクト共有処理方法及び記憶媒体の適用分野としては、例えば設計や製造分野において遠隔地間で同時に行うデザインのレビュー及び会議、ロボット等の遠隔操作、コンピュータゲーム等が挙げられる。

従来の３次元オブジェクト共有処理方法は、大別すると３種類の方法に分類することができる。

第１の方法は、ウィンドウイベント及びディスプレイイベントを制御するコマンドを共有しているコンピュータ間で、逐一やり取りをしながら描画オブジェクトを共有する。このような方法は、例えばマイクロソフト社のＮｅｔＭｅｅｔｉｎｇ、富士通株式会社のＬｉｖｅＨｅｌｐやＴｈｅＣｏｌｌａｂｏ等で採用されている。

この第１の方法では、オペレーティングシステム（ＯＳ）上でディスプレイイベントを支配する全てのコマンドをやり取りするため、非常に大きな通信帯域を必要し、通常はＬＡＮ環境以外で使用することは想定されていない。又、３次元グラフィックスボードを搭載したコンピュータでこの第１の方法を採用すると、ディスプレイコマンドは、ＯＳではなく３次元グラフィックスボード上で処理されるため、３次元グラフィックスボードを搭載したコンピュータ上のグラフィックスをネットワークで繋がったコンピュータ同士で共有することができない。このため、グラフィックスオブジェクトの共有は、ディスプレイイベントをＯＳ上でソフト的に処理するコンピュータ同士のみに限られてしまい、３次元グラフィックスボードを使用する高速レンダリングによるグラフィックスオブジェクトのコンピュータ同士での円滑な共有は実現できない。

第２の方法は、コンピュータ間で共有するべき３次元オブジェクトは、ネットワークで繋がったコンピュータのメモリ上にローカル的に持たせ、コンピュータ間では、オブジェクトの移動、回転等の基本的な変換量のみをやり取りする。このような方法は、例えば特許文献１等にて提案されている。

この第２の方法では、オブジェクトの移動、回転等の基本的な変換量のみをコンピュータ同士でやり取りするため、移動、回転等の基本的なオブジェクト操作以外のオブジェクト操作をコンピュータ間で共有することはできない。又、各ローカルサイト（コンピュータ）のＣＰＵの性能、描画性能等の性能条件がコンピュータ間で均一でないと、コンピュータ間でオブジェクトの共有状態にずれを生じてしまう。

第３の方法は、上記第２の方法のようにオブジェクトの移動、回転等の基本的な変換量をコンピュータ間でやり取りする代わりに、マウス位置Ｘ，Ｙとボタンの上げ、下げ状態等のマウスイベントやキーボードイベント等の入力操作イベントのみをコンピュータ間でやり取りする。このような方法は、例えば特許文献２等にて提案されている。第３の方法では、オブジェクトをロードしているアプリケーションの操作自体を全てコンピュータ間で共通化する。

第３の方法によれば、コンピュータ間でアプリケーションを共有するため、プログラミング量が少なくて済み、共有しようとする各アプリケーションから殆ど独立した、所謂「共有通信系」を構築することができる。但し、例えばＶｉｓｕａｌＣ＋＋標準のＧＵＩ系を持つアプリケーションの場合、この第３の方法を採用するためには、アプリケーションのウィンドウサイズやメニューバーの位置等の表示条件が、全てのローカルサイトにおいて一致していることが前提条件であり、これによってユーザの自由度は制限される。
米国特許第５，８２１，９２５号公報米国特許第５、８４４、５５３号公報特開平６−３３３０２１号公報篠原克也，外２名、"仮想現実感のネットワーク化"、「情報処理学会研究報告」、社団法人情報処理学会、１９９２年５月１５日、Ｖｏｌ．９２、Ｎｏ．３５、ｐｐ．５７−６２

上記第１〜第３の方法では、いずれも各ローカルサイトにおける性能条件や表示条件等の均一性に関わらず、コンピュータ間で３次元オブジェクトをインタラクティブに、円滑に、且つ、各ローカルサイトにおける如何なる操作にも対応できるように柔軟に共有することはできないという問題があった。又、マウスイベントで共有使用とする場合に、アプリケーションのウィンドウサイズやメニューバーの位置が一致していることが前提条件であり、ユーザが自由にサイズや位置を変えられないという問題もあった。

そこで、本発明は、ウィンドウサイズやメニューバーの位置は任意な状態で、コンピュータ間で３次元オブジェクトをインタラクティブに、円滑に、且つ、各ローカルサイトにおける如何なる操作にも対応できるように柔軟に共有することが可能な３次元オブジェクト共有処理方法及び記憶媒体を提供することを目的とする。

上記の課題は、ネットワークを介して接続された複数のコンピュータシステムの間で３次元オブジェクトのデータを共有する３次元オブジェクト共有処理方法であって、各コンピュータシステムにおいて行われる３次元オブジェクトに対する操作に関する操作コマンド及び該操作により発生する３次元オブジェクトの変化を示す選択部品の番号及び部品位置座標を含む変化情報に基づいて、各コンピュータシステムにおいて保持される３次元オブジェクトのデータが一致するよう更新するステップを含む３次元オブジェクト共有処理方法によって達成できる。

３次元オブジェクト共有処理方法は、各コンピュータシステムにおいて、前記変化情報の送受信を、内部データの更新処理及び描画処理より前に行うステップを含んでも良い。

３次元オブジェクト共有処理方法は、各コンピュータシステムにおいて、送受信するデータサイズを変化させるステップを含んでも良い。

３次元オブジェクト共有処理方法は、送信側のコンピュータシステムからの前記操作コマンド及び変化情報を受信する受信側のコンピュータシステムにおいて、ダミーメニューウィンドウを表示して送信側の操作を再現するステップを含んでも良い。

３次元オブジェクト共有処理方法は、送信側のコンピュータシステムではマウスカーソルの動きに関するデータを間引き、受信側のコンピュータシステムでは受信したマウスカーソルの動きに関するデータを補間するステップを含んでも良い。

３次元オブジェクト共有処理方法は、受信側のコンピュータシステムにおいて、動的間引き同期処理、ＬＯＤ動的間引き同期処理、飛ばし同期処理、長時間処理同期処理、停止位置同期処理、パス再生同期処理及び待機同期処理の少なくとも１つの処理を行うステップを含んでも良い。

上記の課題は、コンピュータに、上記いずれかの３次元オブジェクト共有処理方法により３次元オブジェクトのデータを処理させるプログラムが格納されたコンピュータ読み取り可能な記憶媒体によっても達成できる。

従って、本発明によれば、コンピュータ間で３次元オブジェクトをインタラクティブに、円滑に、且つ、各ローカルサイトにおける如何なる操作にも対応できるように柔軟に共有することが可能な３次元オブジェクト共有処理方法及び記憶媒体を実現することができる。

本発明によれば、ウィンドウサイズやメニューバーの位置は任意な状態で、コンピュータ間で３次元オブジェクトをインタラクティブに、円滑に、且つ、各ローカルサイトにおける如何なる操作にも対応できるように柔軟に共有することが可能な３次元オブジェクト共有処理方法及び記憶媒体を実現できる。

以下、図面と共に、本発明になる３次元オブジェクト共有処理方法及び記憶媒体の各実施例を説明する。

図１は、本発明になる３次元オブジェクト共有処理方法の第１実施例を適用可能なサーバ・クライアントシステムを示す図である。同図に示すサーバ・クライアントシステムでは、複数のコンピュータシステム１−１〜１−ｎが、ＬＡＮ、ＷＡＮ等のネットワーク２を介して接続されている。説明の便宜上、コンピュータシステム１−１がサーバを構成し、他のコンピュータシステム１−２〜１−ｎがクライアントを構成するものとする。勿論、コンピュータシステム１−１は、サーバ及びクライアントの両方の機能を有する構成であっても良い。本実施例では、説明の便宜上、コンピュータシステム１−１〜１−ｎが全て同じ基本構成を有するものとするが、サーバを構成するコンピュータシステム１−１とクライアントを構成するコンピュータシステム１−２〜１−ｎとは、互いに異なる基本構成を有しても良い。又、コンピュータシステム１−１〜１−ｎのうち、２以上のコンピュータシステムが互いに異なる基本構成を有しても良い。

図２は、コンピュータシステム１−１〜１−ｎとして使用されるコンピュータシステム１を示す斜視図である。同図に示すコンピュータシステム１は、ＣＰＵやディスクドライブ装置等を内蔵した本体部１０１、本体部１０１からの指示により表示画面１０２ａ上に画像を表示するディスプレイ１０２、コンピュータシステム１に種々の情報を入力するためのキーボード１０３、ディスプレイ１０２の表示画面１０２ａ上の任意の位置を指定するためのマウス１０４、外部のデータベース等にアクセスして他のコンピュータシステムに記憶されているプログラム等をダウンロードするモデム１０５を備えている。

ディスク１１０等の可搬型記録媒体に格納されるか、モデム１０５等の通信装置を使って他のコンピュータシステムの記録媒体１０６からダウンロードされる、コンピュータシステム１に本発明になる３次元オブジェクト共有処理方法に基づいた処理を行わせるプログラムは、コンピュータシステム１に入力されてコンパイルされる。本発明になる記憶媒体は、プログラムを格納した、例えばディスク１１０等の記録媒体からなる、コンピュータ読み取り可能な記憶媒体である。本発明になる記憶媒体を構成する記録媒体は、ディスク１１０、ＩＣカードメモリ、フロッピーディスク（「フロッピー」は登録商標）、光磁気ディスク、ＣＤ−ＲＯＭ等の可搬型記録媒体に限定されるものではなく、モデム１０５やＬＡＮ等の通信装置や通信手段を介して接続されるコンピュータシステムでアクセス可能な各種記録媒体を含む。

図３は、コンピュータシステム１の本体部１０１内の要部の構成を示すブロック図である。同図中、本体部１０１は、大略バス２００により接続されたＣＰＵ２０１と、ＲＡＭやＲＯＭ等からなるメモリ部２０２と、ディスク１１０用のディスクドライブ装置２０３と、ハードディスクドライブ装置２０４とからなる。尚、図２では図示を省略するが、ディスプレイ１０２、キーボード１０３、マウス１０４等は、ＣＰＵ２０１に接続されている。

図４及び図５は、図１に示すサーバ・クライアントシステムにより会議を行う場合のシステム全体の動作を説明するための図である。具体的には、図４は、サーバとして機能するコンピュータシステム（以下、サーバシステムと言う）１−１の動作を説明するフローチャートであり、図５は、クライアントとして機能するコンピュータシステム（以下、クライアントシステムと言う）１−ｎの動作を説明するフローチャートである。説明の便宜上、初期状態の３次元オブジェクトに関するデータは、予め各コンピュータシステム１−１〜１−ｎに保持されているものとする。この初期状態の３次元オブジェクトに関するデータは、予めサーバシステムから各クライアントシステムに供給しても、１つのクライアントシステムからサーバシステム及び他の全てのクライアントシステムに供給されるようにしても良い。要は、会議が開始されるまでに、サーバシステム及び全てのクライアントシステムにおいて、初期状態の３次元オブジェクトに関する同一のデータが保持されていれば良い。

尚、説明の便宜上、会議では、各クライアントシステムのユーザに共通な３次元オブジェクトを見ながら３次元オブジェクトに操作を加えるものとする。各クライアントシステムのユーザ（会議参加者）の顔等の表示は、周知の方法で行っても、行わなくても良い。

図４において、ステップＳ１で、富士通株式会社のＴｈｅＣｏｌｌａｂｏ（コラボ）のサーバ処理が起動され、ステップＳＴ１でコラボサーバ処理が行われる。ステップＳＴ１は、ユーザ管理を行うステップＳ２と、コラボサーバ設定を行うステップＳ３とからなる。ステップＳ２のユーザ管理では、登録するユーザの設定を行う。ステップＳ３のコラボサーバ設定では、ネットワークの設定等を行う。ステップＳＴ１のコラボサーバ処理の後、ステップＳ４は、データ通信処理を行い、各クライアントシステムとの間で必要なデータ通信処理が行われる。

図５において、ステップＳ１１でシステムへログインされると、ステップＳ１２でシステムの自動起動が行われ、ステップＳＴ１１のコラボのクライアント処理が行われる。ステップＳＴ１１は、ログイン画面表示を行うステップＳ１３と、ログイン処理を行うステップＳ１４とからなり、会議への各種リクエストを受け付ける。ステップＳ１４のログイン処理では、ユーザＩＤやパスワード等の入力が行われる。尚、ステップＳＴ１１及び後述するステップＳＴ１２〜ＳＴ１６は、夫々サーバシステムのステップＳ４で行われるデータ通信処理により、サーバシステムとの間で必要なデータ通信処理を行う。

ステップＳＴ１１の後、ステップＳＴ１２の会議管理表処理が行われる。このステップＳＴ１２は、ステップＳ１５〜Ｓ２０，Ｓ２４を含む。ステップＳ１５は、会議一覧表示を行い、登録済み会議の一覧を表示する。ステップＳ１６は、会議作成を行い、会議の参加メンバーや議長等の情報を設定する。ステップＳ１７は、資料管理を行い、資料（データ）をサーバシステムに登録する。ステップＳ１８は、資料取得を行い、資料（データ）をサーバシステムからダウンロードする。ステップＳ１９は、議長判定を行い、クライアントシステムのユーザが議長であるか否かを判定する。ステップＳ１９の判定結果がＹＥＳであると、ステップＳ２０は、会議を開催し、処理は後述するステップＳＴ１３の会議状態表処理やステップＳＴ１４の３次元共有ビューアアプリケーション（以下、単に３次元共有ビューアと言う）の処理へ進む。他方、ステップＳ１９の判定結果がＮＯであると、ステップＳ２４は開催中の会議に参加し、処理は後述するステップＳＴ１５の会議状態表処理やステップＳＴ１６の３次元共有ビューアの処理へ進む。

ステップＳＴ１３は、会議状態表示を行うステップＳ２１と、会議終了処理を行うステップＳ２２とを含む。ステップＳ２２は、データ保存コマンドや終了コマンドをステップＳＴ１４の３次元共有ビューアに渡す。

他方、ステップＳＴ１５は、会議状態表示を行うステップＳ２５と、会議からの退席処理を行うステップＳ２６とを含む。ステップＳ２６は、終了コマンドをステップＳＴ１６の３次元共有ビューアに渡す。

図６は、サーバシステムにおけるサーバ処理を説明する図である。サーバ処理は、コア（Ｃｏｒｅ）層、ユーザ（Ｕｓｅｒ）層、コラボ（Ｃｏｌｌａｂｏ）層、ＧＵＩ層とからなり、スレッドやプロセスの生成、データの流れ及びファイルアクセスは、同図中、夫々実線、細かい破線及び破線で示す矢印で示すように行われる。尚、梨地で示す部分は、各種インタフェース（Ｉ／Ｆ）を示す。

図７は、クライアントシステムにおけるサーバ処理を説明する図である。クライアント処理は、コア（Ｃｏｒｅ）層、ユーザ（Ｕｓｅｒ）層、コラボ（Ｃｏｌｌａｂｏ）層、ＧＵＩ層とからなり、スレッドやプロセスの生成、データの流れ及びファイルアクセスは、同図中、夫々実線、細かい破線及び破線で示す矢印で示すように行われる。尚、梨地で示す部分は、各種インタフェース（Ｉ／Ｆ）を示す。コラボ層のＩ／Ｆは、図５に示すステップＳＴ１２，ＳＴ１３及びＳＴ１５，ＳＴ１４及びＳＴ１６に夫々対応する会議管理のＩ／Ｆ，状態表示のＩ／Ｆ，３次元共有ビューアのＩ／Ｆと連動しており、更にテキストエディタ及びリモート管理のＩ／Ｆとも連動している。

サーバシステム及びクライアントシステムは、図５においてステップＳ１４で正しいパスワードが入力されると、接続が許可されて図８に示すように接続される。図８は、サーバシステム及びクライアントシステムの接続状態を説明する図である。図８中、破線で示す矢印は、ソケット通知を示し、細かい破線で示す矢印は、メッセージ通知を示す。図８において、サーバシステム１−１は、メインスレッド１１、接続受入スレッド１２及び受信スレッド１３を含み、破線で囲まれた部分は通信コア１４を構成する。

サーバシステムのメインスレッド１１は、アプリケーションにより、同図に示す如き通信開始関数、接続受入スレッド作成、受信関数、受信、送信関数、送信等に関する処理を行う。接続受入スレッド１２は、同図に示す如きソケット作成、接続要求待ち、受信スレッド生成、アプリケーションへの通知等に関する処理を行う。又、受信スレッド１３は、同図に示す如き受信待ち、アプリケーションへの通知等に関する処理を行う。

クライアントシステムのメインスレッド２１は、アプリケーションにより、図８に示す如き通信開始関数、ソケット作成、接続要求、受信スレッド生成、受信関数、受信、送信関数、送信等に関する処理を行う。又、受信スレッド２３は、同図に示す如き受信待ち、アプリケーションへの通知等に関する処理を行う。

このように、本実施例では、送信側のコンピュータシステムが自分自身にデータを転送する無駄を省いて、受信側の各コンピュータシステムに操作コマンド及び変化情報を一斉に送信するための手段を、通信Ｉ／Ｆに持たせることができる。操作コマンドは、３次元オブジェクトに対する操作に関するコマンドであり、変化情報は、この操作により発生する３次元オブジェクトの変化を示す、選択部品の番号や部品位置座標等の情報である。又、サーバシステムとクライアントシステムとの接続には、図８に示すように、通信Ｉ／Ｆがマルチスレッドで送信処理を並行に行えるようにすることができる。

図８に示すサーバシステム及びクライアントシステムの接続状態を簡略化して示すと、図９に示すようになる。図９中、図７及び図８と同一部分には同一符号を付し、その説明は省略する。サーバシステムへの接続が確保された後は、クライアントシステムの３次元共有ビューア同士で通信を行う。各クライアントシステムでは、３次元共有ビューアと３次元オブジェクトデータとを保持し、この通信では、３次元共有ビューアの操作コマンド及び変化情報のみを送受信することで、３次元共有ビューアの操作をクライアントシステム間で共有することができる。

本実施例の運用時には、各クライアントシステムにおいて、３次元共有ビューア及びメモ帳等のアプリケーションの、合計２つのアプリケーションが起動されており、３次元共有ビューアは共有操作されている。メモ帳のアプリケーションは、各クライアントシステムにおけるローカル処理により、会議中に必要なメモを作成することができる。１つのクライアントシステムにおいてこのようなメモを作成している間でも、他のクライアントシステムで行われる３次元共有ビューアの操作の状況を画面で確認することができる。つまり、複数のクライアントシステム間で３次元共有ビューアを共有中に、ローカルな操作を行うことができる。又、クライアントシステム間で、ウィンドウのサイズや位置、個々のツールバー等が異なる場合でも、１又は複数のクライアントシステムで行われる３次元共有ビューアの操作の状況を、各クライアントシステムにおいて確実に確認することができる。

１つのクライアントシステムの３次元共有ビューアは、通信Ｉ／Ｆを介して、他のクライアントシステムの３次元共有ビューアと操作コマンド及び変化情報のみを送受信することで、全ての操作を共有する。３次元共有ビューアに関しては、３次元共有ビューアサーバは存在せず、図１０に示すように、全てのコンピュータシステムにおける３次元共有ビューア実行モジュールがクライアントとして動作する。図１０及び後述する図１１は、夫々クライアントとして動作する３次元共有ビューアを説明する図であり、同図中、図１と同一部分には同一符号を付し、その説明は省略する。

操作権を切り換えることにより、操作権を取ったクライアントシステムが送信側となり、その他のクライアントシステムが受信側となると共に、操作コマンド及び変化情報のみを送信側と受信側とで送受信することで共有操作を行う。例えば、クライアントシステム１−２が操作者となると、クライアントシステム１−２からの操作コマンド及び変化情報は、図１０に示すように、他のクライアントシステム１−１，１−３，１−４に送信される。

又、クライアントシステム１−３が操作者となると、クライアントシステム１−３からの操作コマンド及び変化情報は、図１１に示すように、他のクライアントシステム１−１，１−２，１−４に送信される。送信側と受信側との間の切り換えは、３次元共有ビューア中の操作者フラグを用いて判定する。図１２からもわかるように、送信側の送信データ作成部２５から受信側へ操作コマンド及び変化情報が送信されると、受信側の受信データ解釈部２６は操作コマンド及び変化情報に応じた処理を実行して、３次元オブジェクトの共有操作を可能とする。図１２は、操作コマンドの共有を説明する図であり、同図中、図１と同一部分には同一符号を付し、その説明は省略する。

図１２において、送信側のクライアントシステム１−３には送信データ作成部２５が設けられ、受信側のクライアントシステム１−２には受信データ解釈部２６が設けられている。送信データ作成部２５からのデータは、クライアントシステム１−３の通信ポート２８から出力され、通信Ｉ／Ｆ２７を介してクライアントシステム１−２の通信ポート２９に供給され、受信データ解釈部２６に達する。

尚、変化情報とは、３次元共有ビューアの内部状態を示す全ての情報である。従って、変化情報は、例えば３次元オブジェクトである選択部品の番号、部品移動の場合はＸ，Ｙ，Ｚの位置座標、部品回転の場合はＸ，Ｙ，Ｚ軸周りの回転角度である。又、変化情報は、視点の位置、回転角度、並進関節であれば関節位置、回転関節であれば関節回転角度等である。

図１３は、送信データ作成部２５の動作を説明するフローチャートである。同図中、送信側のクライアントシステムにおいて、３次元オブジェクトに対して操作が行われると、ステップＳ３１は、操作コマンドの判定を行い、操作コマンドがメインメニューやツールバー等に対する操作コマンドであるか否かを判定する。ステップＳ３１の判定結果がＹＥＳであると、処理はステップＳ３２へ進み、操作コマンド番号セット処理が行われる。ステップＳ３２の後、処理は後述する送信データ作成処理ＳＴ２１のステップＳ３９へ進む。

他方、ステップＳ３１の判定結果がＮＯであると、３次元オブジェクトに対して直接操作が行われているので、ステップＳ３３で変化情報の判定を行う。判定された変化情報の種類に応じて、ステップＳ３４〜Ｓ３８のいずれか１つのステップの処理が行われる。ステップＳ３４は、３次元オブジェクトの部品位置データの更新処理Ｐ１を行う。同様に、ステップＳ３５，Ｓ３６は、夫々３次元オブジェクトの部品位置データの更新処理Ｐ２，Ｐ３を行う。ステップＳ３７は、後述する動的間引き同期処理を行い、ステップＳ３８は、後述する飛ばし同期処理を行う。ステップＳ３４〜Ｓ３８のいずれか１つのステップの処理が行われた後、処理は送信データ作成処理ＳＴ２１へ進む。

送信データ作成処理ＳＴ２１では、ステップＳ３９において、操作コマンド及び変化情報を他のクライアントシステムに送信して、３次元オブジェクトに対して行われた操作を他のクライアントシステムに反映させるか否かを判定する。つまり、ステップＳ３９は、３次元オブジェクトに対して行われた操作が、送信側のクライアントシステムの操作者によるものであるか否かを判定する。ステップＳ３９の判定結果がＹＥＳであると、ステップＳ４０は、データ構造体作成処理を行い、３次元オブジェクトを構成する各部品の位置に関するデータのデータ構造体を作成する。又、ステップＳ４１は、送信データセット処理を行い、送信する操作コマンド番号及びデータ構造体に対する変化情報をセットする。ステップＳ４２は、セットされたデータ、即ち、操作コマンド番号及び変化情報を、受信側のクライアントシステムへ例えばネットワーク２を介して送信する。

ステップＳ４２の後、又は、ステップＳ３９の判定結果がＮＯであると、ステップＳ４３は、全体データ更新処理を行い、３次元オブジェクトに対して行われた操作に応じて３次元オブジェクト全体に関するデータを更新し、ステップＳ４４は、更新された３次元オブジェクトデータの描画処理を行うことで、ディスプレイ１０２上に更新された３次元オブジェクトを表示する。

図１４は、受信データ解析部２６の動作を説明するフローチャートである。受信側のクライアントシステムが送信側のクライアントシステムからのデータを受信すると、受信データ解釈処理ＳＴ２２が行われる。ステップＳ５１は、送信側のクライアントシステムから送信されてくるデータを読み取る、データ読み取り処理を行う。ステップＳ５２は、読み取ったデータに基づいて、操作コマンドがメインメニュー、ツールバー等に対する操作コマンドであるか否かを判定する。ステップＳ５２の判定結果がＹＥＳであると、処理はステップＳ５３へ進み、操作コマンド番号セット処理が受信データセット処理として行われる。ステップＳ５３の後、処理はステップＳ５４へ進み、セットされた操作コマンド番号に対応する操作コマンドを実行する、操作コマンド実行処理を行い、処理は終了する。

他方、ステップＳ５２の判定結果がＮＯであると、３次元オブジェクトに対して直接操作が行われているので、ステップＳ５３で変化情報セット処理が受信データセット処理として行われる。この場合、ステップＳ５３の後、処理はステップＳ５５へ進み、全体データ更新処理を行い、３次元オブジェクトに対して行われた操作に応じて３次元オブジェクト全体に関するデータを更新する。又、ステップＳ５６は、更新された３次元オブジェクトデータの描画処理を行うことで、ディスプレイ１０２上に更新された３次元オブジェクトを表示し、処理は終了する。

このように、送信側から送信する操作コマンドに対応する受信データ解釈部を受信側に設けることで、３次元オブジェクトの任意の操作が、３次元共有ビューア間で共有可能となる。従って、例えば２つのクライアントシステム間で対応する操作コマンドやメニューを作成しておけば、互いに異種のアプリケーション間でも３次元オブジェクトの操作自体を共有することができる。

次に、送信側のクライアントシステムにおいて、図１３に示すステップＳ４３による全体データ更新処理及びステップＳ４４による描画処理を行う前に、ステップＳ４２によるデータ送信を行うことのメリットについて、図１５及び図１６と共に説明する。

図１５は、描画処理の後に行うデータ送信を説明する図である。特に大規模製品モデル等の場合、構成部品数が多くなるので、全体データ更新処理や描画処理に時間がかかる。このため、送信側のクライアントシステムにおいて全体データ更新処理及び描画処理を行ってからデータ送信を行うと、受信側のクライアントシステムにおいて全体データ更新処理及び描画処理が行われるまでには、図１５に示すように、時間がかかる。

図１６は、描画処理の前に行うデータ送信を説明する図である。特に大規模製品モデル等の場合、構成部品数が多くなるので、全体データ更新処理や描画処理に時間がかかる。しかし、送信側のクライアントシステムがデータ送信を行ってから全体データ更新処理及び描画処理を行うと、受信側のクライアントシステムにおいて全体データ更新処理及び描画処理が行われるまでには、図１６に示すように、図１５の場合と比較すると時間がかからず、送信側と受信側との間の処理実行時間差を非常に小さくすることができる。

又、３次元共有ビューアのサイズが大きい場合には、ファイルを開くのに時間がかかる。そこで、このような場合には、送信側のクライアントシステムにおいてファイルを選択した直後に、先に受信側のクライアントシステムの３次元共有ビューアにファイル名を送信しておくことで、送信側と受信側との間の処理実行時間差を減少させることができる。この場合、送信側でファイルを開き終わってからデータ送信を行い、受信側ではデータを受信してからファイルを開くようにすれば、送信側と受信側との間の処理実行時間差を更に減少させることができる。

次に、送信側のクライアントシステムと受信側のクライアントシステムとの間で送受信されるデータのデータサイズについて説明する。データサイズは、固定でも良いが、本実施例では、データサイズを必要に応じて変化させることで、データ転送負荷を軽減する。

送受信データのデータ構造体は、図１３に示すステップＳ４０によるデータ構造体作成処理により、必要最小限に任意に設定される。例えば、３次元オブジェクトの部品選択であれば、部品番号の１変数（ｉｎｔ：４バイト）のみを送信する。部品位置情報（Ｘ，Ｙ，Ｚ）の場合でも、２４バイト（ｄｏｕｂｌｅ：８バイト×３）程度と非常に小さくできる。又、３次元オブジェクトの回転や並進関節であれば、関節値（ｄｏｕｂｌｅ：８バイト）のみを送信する。このように、必要に応じてデータサイズを変化させることで、ネットワーク２にかかるデータ転送負荷を抑制することができる。転送データを極限まで削減することで、本実施例をＬＡＮ内のみならず、ファイヤーウォール（Ｆ／Ｗ）を超えたＷＡＮ環境での使用も可能となる。

次に、効率的な共有操作について説明する。本実施例では、共有操作を効率的に処理するために、３次元オブジェクトに操作を加える際に用いるメインメニュー、ポップアップメニュー、ツールバーの操作コマンドを、ＯｎＣｏｍｍａｎｄで一括捕獲し、この操作コマンドのイベントＩＤを捕らえて操作コマンドの送受信を行う。一般的に、Ｗｉｎｄｏｗｓ（登録商標）等のＯＳ上で動作するコンピュータシステムのアプリケーションは、処理が行われると必ずコントロールへの通知とＯＮＣＯＭＭＡＮＤエントリ用にメッセージマップを処理し、適切なメンバ関数を呼び出すＯｎＣｏｍｍａｎｄ関数内を通る。これらのメンバ関数は、アプリケーションの以下の関数で捕らえられる。

ＢＯＯＬＣｍａｉｎＦｒａｍｅ：：ＯｎＣｏｍｍａｎｄ（ＷＰＡＲＡＭｗＰａｒａｍ，ＬＰＡＲＡＭ１Ｐａｒａｍ）
ＢＯＯＬＣＳＭＲＶｉｅｗ：：ＯｎＣｏｍｍａｎｄ（ＷＰＡＲＡＭｗＰａｒａｍ，ＬＰＡＲＡＭ１Ｐａｒａｍ）
ＢＯＯＬＣＳｍｒＴｒｅｅＶｉｅｗ：：ＯｎＣｏｍｍａｎｄ（ＷＰＡＲＡＭｗＰａｒａｍ，ＬＰＡＲＡＭ１Ｐａｒａｍ）

ＣｍａｉｎＤｒａｍｅ：：ＯｎＣｏｍｍａｎｄの一例を図１７に示す。図１７は、送信側のクライアントシステムのコマンド処理を示す図であり、ＣＤＭＲＶｉｅｗ：：ＯｎＣｏｍｍａｎｄ等も同様に行われる。又、図１８は、受信側のクライアントシステムの受信処理を示す図であり、図１９は、受信側のクライアントシステムのアプリケーション中のコマンド処理内に入るコマンド処理を示す。

図１７に示すコマンド処理は、送信側、即ち、操作者であれば、コマンド用データ構造体を確保するステップと、ＭＡＩＮＦＲＡＭＥのコマンドをセットするステップと、実行するべきコマンドのパラメータをセットするステップと、コマンドを送信するステップとからなり、送信側自身、即ち、操作者自分自身の処理を実行する。

図１８に示す受信処理は、ＩＦＶＰＳ＿ＯＮＣＯＭＭＡＮＤの場合、受信データを読み取るステップと、コマンド処理を実行するステップとからなる。

図１９に示すコマンド処理は、コマンドの種別（ｋｉｎｄ）に応じて場合分けされ、ＩＦＶＰＳ＿ＭＡＩＮＦＲＡＭＥの場合にはＭＡＩＮＦＲＡＭＥへメッセージを送り実行するステップと、ＩＦＶＰＳ＿ＶＩＥＷの場合にはＶＩＥＷへメッセージを送り実行するステップとからなる。

コマンド処理において、ＯｎＣｏｍｍａｎｄの中では、クライアントシステム自身の処理を実行可能である。このため、受信側のクライアントシステムにおいてもメニュー操作が実行可能であり、送信側と受信側とで、操作のずれを発生する可能性がある。そこで、このような操作のずれを防止するには、受信側でのメニュー操作を禁止するための処理を図１７及び図１８に示す処理に追加すれば良い。

図２０は、受信側でのメニュー操作を禁止する処理を含む、送信側のクライアントシステムのコマンド処理を示す図である。又、図２１は、受信側でのメニュー操作を禁止する処理を含む、受信側のクライアントシステムの受信処理を示す図である。この場合、受信側でダイアログ等を出さずに結果のみを実行するコマンドは、送信しないようにしている。

図２０に示すコマンド処理は、送信側、即ち、操作者の場合に実行されるステップと、受信側の場合に実行されるステップと、コマンド実行中が通知されている場合に実行されるステップと、自分自身だけでコマンドを実行して関数から抜けるステップとからなる。操作者の場合に実行されるステップは、送信しないコマンドであると、送信しないのでファイルチューザが開かないようにするために、自分自身だけでコマンドを実行して関数から抜けるステップと、コマンド用データ構造体を確保するステップと、実行するべきコマンドのパラメータをセットするステップと、コマンドを送信するステップとを含む。受信側の場合に実行されるステップは、受信側で実行可能なメニューであると自分自身だけでコマンドを実行するステップと、操作者以外の操作を禁止するために関数から抜けるステップとを含む。コマンド実行中が通知されている場合に実行されるステップは、受信側でも同じコマンドを実行するステップを含む。

図２１に示す受信処理は、コマンドの種別（ｕｓＫｉｎｄ）に応じて場合分けされ、ＩＦＶＰＳ＿ＯＮＣＯＭＭＡＮＤの場合、データを読み取るステップと、フラグを退避するステップと、フラグをコマンド実行中に通知するステップと、コマンドの処理を実行するステップと、退避フラグを戻すステップとからなる。

尚、図１７のコマンド処理では、包括関数によりダイアログの操作を共有化している。具体的には、ダイアログの既存関数を、引数を持つ１つの包括関数で包んで、操作コマンド種別の場合分けに応じた処理を行う。

ところで、本実施例では、操作コマンドをクライアントシステム間で共有するため、受信側のクライアントシステムでは操作の実行結果のみが実施される。しかし、これでは受信側のクライアントシステムにおいて、メインメニューやポップアップメニューを開いたり、これらのメニュー上でマウスカーソルを移動することができない。そこで、本実施例では、受信側のクライアントシステムにおいて、実メニューの上にダミーメニューウィンドウを表示し、マウスカーソルはこのダミーメニューウィンドウ上で移動させる。この結果、受信側のクライアントシステムでは、送信側のクライアントシステムにおけるメインメニューやポップアップメニュー等に対応するダミーメニューが表示され、送信側と同じマウスカーソルの移動を受信側のダミーメニュー上で実現できるので、受信側と送信側とで操作の共有感を高めることができる。

本実施例では、メインメニュー、ポップアップメニュー、ツールバー等については、操作コマンドのイベントＩＤを捕らえて送受信し、クライアントシステム間で実行するコマンドの共有を行う。しかし、殆どのダイアログの大きさは、通常は同じである。そこで、ダイアログの大きさが異なる場合には、上記の如きコマンドの共有を行い、ダイアログの大きさが同じ場合には、ダイアログ上の操作に関してはマウスイベントの共有を行うことができる。この場合、マウスイベントは、マウスの位置や、押し上げ、押し下げ、移動等のマウスの状態を示す。尚、クライアントシステム間での画面解像度の相違は、正規化処理を行うことで吸収可能である。

マウスイベントを共有する場合、ＯＳレベルでマウスイベントを発行すると、受信側クライアントシステムにおいてマウスカーソルが送信側の操作に応じて強制的に移動されてしまう。このような場合、３次元オブジェクトを複数のクライアントシステムで共有中似、受信側のクライアントシステムにおいてローカルな独立した操作を行うことができなくなってしまう。そこで、マウスイベントを発行する場合、ＯＳレベルではなく、アプリケーションレベルで発行することが、ローカルな操作を可能とする意味からも望ましい。

次に、各ローカルサイトのクライアントシステム内で、別のディレクトリにある３次元オブジェクトのデータに対してファイル操作を一斉に行う動作を説明する。

各ローカルサイトにおいて、クライアントシステム各自が３次元オブジェクトの形状データ、アセンブリデータ等のデータのファイルを開くのでは、何度も同じような操作が行われるため、非効率的である。又、３次元共有ビューアのデータの格納場所は、各ローカルサイトで異なる場合もある。特に、大規模製品モデルを扱う場合には、クライアントシステムのハードディスクドライブ装置に十分な記憶容量がない場合や、他のデータと明確に区別したい場合等には、３次元共有ビューアのデータを他のデータと異なる格納場所に格納する場合もある。そこで、本実施例では、送信側のクライアントシステムの操作者が開いたファイルチューザからファイル名を取り出して送信し、受信側の各クライアントシステムでは、受信したファイル名を予め設定してあるデータディレクトリに付け替えて、読み込み、保存、部品交換、部品追加等のファイル操作を一斉に行う。

図２２は、一斉ファイル操作を説明する図である。ここでは、説明の便宜上、操作者はＤ：￥ｕｓｅｒｓ￥Ｄａｔａ￥ＭｏｄｅｌＡ．ａｓｙなるドライブにデータを格納し、受信側のユーザ１は操作者とは異なるＦ：￥ｕｓｅｒｓ￥Ｖｉｅｗｅｒ￥ＭｏｄｅｌＡ．ａｓｙなるドライブにデータを格納しているものとする。

図２２において、操作者側のクライアントシステムでの処理は、Ｄ：￥ｕｓｅｒｓ￥Ｄａｔａ￥ＭｏｄｅｌＡ．ａｓｙを選択して開くステップと、ＭｏｄｅｌＡ．ａｓｙを取り出して送信するステップとからなる。他方、ユーザ１側のクライアントシステムでの処理は、ＭｏｄｅｌＡ．ａｓｙを受信するステップと、予め設定しておいたデータディレクトリの情報を取り出すステップと、両者を結合してＦ：￥ｕｓｅｒｓ￥Ｖｉｅｗｅｒ￥ＭｏｄｅｌＡ．ａｓｙを開くステップとからなる。尚、他のユーザ２等のクライアントシステムにおける処理は、ユーザ１側の処理と同様である。

上記の如く、予めデータディレクトリを設定しておく処理を説明する。データを受信後、各ユーザは、３次元共有ビューアデータディレクトリパスを、図５に示すステップＳＴ１２に対応するＣｏｌｌａｂｏ＿ｄａｅｍｏｎのプロパティ設定の「参照」ボタンを押すことで、ファイルチューザから選択して指定することができる。図２３は、ディレクトリの設定を説明する図である。

ユーザ１の場合を例にとって説明すると、Ｆ：￥ｕｓｅｒｓ￥Ｖｉｅｗｅｒ￥ＭｏｄｅｌＡ．ａｓｙでは、上記の操作を行うと、Ｆ：￥ｕｓｅｒｓ￥Ｖｉｅｗｅｒ￥をこのユーザ１の３次元共有ビューアのデータディレクトリとして、Ｃｏｌｌａｂｏ＿ｄａｅｍｏｎが自動的にログイン中のユーザのレジストリ情報に記録する。

図２４は、ディレクトリ選択処理を説明する図である。同図に示すように、ディレクトリ選択処理は、３次元共有ビューアのデータを選択した場合には、ファイルチューザのディレクトリを得るステップと、レジストリ情報を記録するステップとからなる。

３次元共有ビューアを起動後には、レジストリ情報を読み、レジストリ情報中のディレクトリからデータを読み込む。又、データディレクトリパスを、受信ファイル格納場所として設定しておけば、会議中に変更されて送信されたファイルのデータを直ちに読み込むことができる。データディレクトリに関しては、次のような運用形態が可能である。

（１）３次元オブジェクトの形状データが、会議の参加者、即ち、各ユーザのクライアントシステムに送信されたと仮定し、Ｃｏｌｌａｂｏ＿ｄａｅｍｏｎでシステムを接続後、プロパティで３次元共有ビューアデータディレクトリパスを変更する。対象データディレクトリが異なる場合には、３次元共有ビューアデータディレクトリパスを変更する。

（２）一度設定したＦ：￥ｕｓｅｒｓ￥Ｖｉｅｗｅｒ￥をｔｍｐのデータディレクトリと仮定し、全ての３次元共有ビューアデータＭｏｄｅｌＡ．ａｓｙ，ＭｏｄｅｌＢ．ａｓｙ，ＭｏｄｅｌＣ．ａｓｙ等を入れる。３次元共有ビューアからのアセンブリロード時には、アセンブリだけが表示されるので、対象データは容易に選択できる。

（３）データディレクトリに、ｕｓｅｒｓ￥ＭＯ＿ＤＲＩＶＥ２，ｕｓｅｒｓ￥ＥＮＧＩＮＥ等のディレクトリ名を付けて保存しておき、会議前にｕｓｅｒｓ￥ＥＮＧＩＮＥからｕｓｅｒｓ￥Ｖｉｅｗｅｒといった具合にディレクトリ名を変更する。この際、Ｃｏｌｌａｂｏ＿ｄａｅｍｏｎのプロパティの３次元共有ビューアデータディレクトリパスは、以前と同じ設定のままで良い。

次に、一斉ファイル開くについて、図２５〜図２８と共に説明する。図２５及び図２６は送信側の処理を示し、図２５は開くファイル選択処理、図２６はファイル開く処理を示す。図２７はコマンド実行処理を示す。又、図２８は受信側の受信処理を示す。

図２５の開くファイル選択処理は、図２３に示す如きメニューにおいて「開く」のボタンを押すことで行われる。開くファイル選択処理は、ユーザが操作権を持っていなければ、操作権ロックがされていない限り操作者とみなすステップと、ファイルチューザを開くステップと、レジストリのデータディレクトリパスをセットするステップとからなる。

図２６のファイル開く処理は、ファイルチューザを開いてファイルを選択することで行われる。ファイル開く処理は、例えばＤ：￥ｕｓｅｒｓ￥Ｄａｔａ￥ＭｏｄｅｌＡ．ａｓｙ等のディレクトリ及びファイル名を獲得するステップと、操作者であると、ディレクトリ部分を除いて例えばＭｏｄｅｌＡ．ａｓｙ等のファイル名を獲得すると共に、読み込み実行前にファイル名を送信するステップと、読み込み処理を行うステップとからなる。

図２７のコマンド実行処理は、受信側で何度も同じ「開く」のボタン操作を行うことを避け、受信側でファイルチューザを開かないようにするために行われる。コマンド実行処理は、操作者の場合に行われるステップと、受信側の場合に行われるステップと、コマンド実行中が通知されている場合に受信側でも同じコマンドを実行するステップと、自分自身だけコマンドを実行して関数から抜けるステップとからなる。操作者の場合に行われるステップは、送信しないコマンドであると、送信しないのでファイルチューザを開かないようにするために、自分自身だけコマンドを実行して関数から抜けるステップと、送信するコマンドであると送信するステップとを含む。又、受信側の場合に行われるステップは、受信側で実行可能なコマンドならばコマンドを実行するステップと、操作者以外の操作を禁止するために関数から抜けるステップとを含む。

図２８の受信処理は、「開く」のボタンが押されたことを示す操作コマンドが受信されると、例えばＭｏｄｅｌＡ．ａｓｙ等の受信したファイル名をセットするステップと、レジストリ情報の読み取り関数や例えばＦ：￥ｕｓｅｒｓ￥Ｖｉｅｗｅｒ￥等のレジストリのデータディレクトリパスをセットするステップと、例えばＦ：￥ｕｓｅｒｓ￥Ｖｉｅｗｅｒ￥ＭｏｄｅｌＡ．ａｓｙ等のディレクトリパス及びファイル名の作成処理を行うステップと、設定ディレクトリからファイルを開く処理を行うステップとからなる。

次に、重要なファイルに上書きされるのを防止するため、上書き保存を使用不可能にして別名保存を行う、一斉別名保存について、図２９〜図３２と共に説明する。

図２９は、操作側で行われる別名保存処理を説明する図である。同図に示す別名保存処理は、ファイルチューザを開いてファイル名を入力すると行われる。別名保存処理は、ファイルチューザを開くステップと、操作者であると、ディレクトリ部分を除いてファイル名を獲得する処理を行うと共に、別名保存コマンドとファイル名を送信するステップと、自分自身にアセンブリデータを保存するステップとからなる。

受信側で何度も同じ「別名保存」操作を行うことを避け、受信側ではファイルチューザを開かないようにするためには、図２７の場合と同様に、図３０に示すように処理を変形すれば良い。具体的には、別名保存処理は、操作者の場合に行われるステップと、受信側の場合に行われるステップとを含むようにする。操作者の場合に行われるステップは、送信しないコマンドであると、送信しないのでファイルチューザを開かないようにするために、自分自身だけコマンドを実行して関数から抜けるステップを含む。又、受信側の場合に行われるステップは、受信側で実行可能なコマンドならばコマンドを実行するステップと、操作者以外の操作を禁止するために関数から抜けるステップとを含む。

図３１は、一斉別名保存の場合の受信側の処理を説明する図であり、図３２は、別名保存処理を説明する図である。図３１に示す受信処理は、「別名保存」のボタンが押されたことを示す操作コマンドが受信されると、例えばＭｏｄｅｌＢ．ａｓｙ等の受信したファイル名をセットするステップと、既にファイルが開けられているのでセットされている例えばＦ：￥ｕｓｅｒｓ￥Ｖｉｅｗｅｒ￥等のレジストリのデータディレクトリパスを得るステップと、例えばＦ：￥ｕｓｅｒｓ￥Ｖｉｅｗｅｒ￥ＭｏｄｅｌＢ．ａｓｙ等のディレクトリパス及びファイル名の作成処理を行うステップと、別名保存処理を実行するステップとからなる。

別名保存処理は、図３２に示すように、コマンド（ｃｏｍｍａｎｄ）で場合分けして、ＩＤ＿ＦＩＬＥ＿ＳＡＶＥ＿Ａｓの場合には、設定ディレクトリ及びファイル名でファイルを保存するステップを含む。

次に、会議管理との連携機能を、図３３及び図３４と共に説明する。図３３は、会議状態通知処理を説明する図であり、図３４は、リセット処理を説明する図である。

システムの会議管理及び３次元共有ビューア間で連携するべき動作は、通信Ｉ／Ｆにより３次元共有ビューアに通知される。この通知を行う場合には、図３３に示すような関数を通るので、場合分けをして３次元共有ビューアの処理を実行する。

図３３に示す会議状態通知処理は、ｉＣｈａｎｇｅＩｎｇで場合分けをして、リセットの場合に操作者ならばリセット処理を実行するステップと、会議終了の場合に議長ならば操作権を取るステップと、別名保存処理を実行するステップと、３次元共有ビューアを閉じるステップとからなる。尚、その他の場合の処理の説明は省略する。

３次元共有ビューア上に操作権、操作権ロック、リセット等のツールバーがあり、リセット処理はリセットのツールバーを選択することで行われる。リセット処理は、操作権を持っている操作者のみにより選択可能である。操作者がリセット処理を選択すると、以前に開いたファイルを操作者が操作しているクライアントシステム自分自身で再読み込みすることで、初期状態となる。

図３４に示すリセット処理は、操作権があり、且つ、ファイル名が空でなければ、以前開いたファイルのあるディレクトリへ移動するステップと、ディレクトリ及び以前開いたファイル名を作成するステップと、操作者が操作しているクライアントシステム自分自身で再読み込みを行い、ファイル名とファイルを開くコマンドを送信するステップとからなる。尚、他の受信側のクライアントシステムの３次元共有ビューアは、上記のファイル開く処理の場合と同様に、操作側と同じファイルを開く。

システムの会議管理で議長が「会議終了」を実行すると、「別名保存」を行うかを尋ね、別名保存が選択されると別名保存処理を行った後に３次元共有ビューアを閉じる。他方、議長以外の一般の参加者であれば、別名保存処理は行わずに３次元共有ビューアを閉じる。この時、議長のクライアントシステムにおいてのみ、ファイルが保存される。次回の会議で使用するファイルであれば、別途ファイルの送信を行う必要がある。これは、最終状態を保存し忘れることを防止するためである。会議によっては、最終状態の保存が不要であることもあり、このような場合には、別名保存処理をキャンセルすれば良い。ファイルを次回の会議で使用するために、他のクライアントシステムにおいても保存する必要があれば、操作者が会議の終了前に別途別名保存処理を行えば、各クライアントシステムにおいてもファイルが保存され、別途ファイルの送信を行う必要がなくなる。

次に、送信側では間引き処理を行い、受信側では補間処理を行って、マウスカーソルをスムースに移動可能とする固定間引き同期処理について説明する。

システムのＷＡＮ環境での使用を考えた場合、ファイヤーウォールを抜けるためのＳＯＣＫＳや、ＷＡＮ回線の通過により、通信効率が低くなる。ＷＡＮで信頼性の高いＴＣＰ通信の場合は、３次元共有ビューアのマウスカーソルの動きが間欠的になり、スムースな連続移動ができない。そこで、アプリケーション中で頻繁に通るマウスカーソル移動の部分については、送信側では間引き処理を行い、受信側では補間処理を行う。送信側は、データ送信量及び送信回数を減らすために、時間による間引き処理を行って、一定時間毎にマウス位置のデータを送信する。他方、受信側は、補間処理を行って、一定時間毎にマウスカーソルを移動することにより、マウスカーソルをスムースに移動する。

受信側のマウスカーソル移動の応答は、間引き処理及び補間処理が行われない場合には、ＬＡＮ環境では次のような状態である。つまり、ＴＣＰの場合、マウスカーソルの動きが鈍く、飛び飛びとなってしまうが、ＳＯＣＫＳを使用することにより、ファイヤーウォールを超えたＷＡＮ環境でも使用できる。又、ＵＤＰの場合、マウスカーソルの動きがスムースであるが、ファイヤーウォールを超えたＵＤＰの通信は不可能であり、ＷＡＮ環境での使用は実現できなかった。

これに対し、送信側の間引き時間と、受信側の補間時間とを変化させることにより、組み合わせに応じて次のように状態となる。
・頻繁にマウスカーソルが止まるように見える。
・たまにマウスカーソルが止まるように見える。
・マウスカーソルの動きがスムースになる。
・マウスカーソルの動きが直線的で、見にくい。

本発明者らの実験によると、ＷＡＮ環境での使用に耐え得るようにチューニングしてマウスカーソルの動きをスムースするには、送信側の間引き時間を例えば２００ｍｓ毎、受信側の補間時間を例えば２０ｍｓ毎に設定すると良いことがわかった。

次に、受信データのバッファリングによりマウスカーソルをスムースに移動する処理について説明する。

受信データのバッファリングを行わない場合には、頻繁にマウスカーソルが止まるように見える。又、連続的にマウスを動かしている場合、マウスカーソルの動きがどんどん遅れて行く。これに対し、受信データを例えば図３に示すメモリ部２０２等でバッファリングすると、データの受信時間のばらつきがバッファリングにより吸収され、マウスカーソルの動きがスムースになる。そこで、マウス移動のデータをバッファリングにより、ある程度保持してから実行することで、マウスカーソルをスムースに移動することができる。本発明者らによる実験結果によると、受信側のデータバッファリング時間は、例えば４００〜６００ｍｓに設定すると良いことがわかった。

次に、図１３に示すステップＳ３７で行われる動的間引き同期処理について説明する。動的間引き同期処理は、遠隔地間で共有している３次元オブジェクトをスムースに違和感なく同期させて描画するための処理である。

グラフィック性能の違うコンピュータシステムで３次元共有ビューアを共有すると、性能の低いコンピュータシステムの描画処理が他のコンピュータシステムに比べて遅れてしまう。そこで、グラフィック性能差のあるコンピュータシステム間でもスムースに３次元共有ビューアの共有を行うために、部品移動、部品回転、視点移動、視点回転等の連続的な操作時に、予め各コンピュータシステムの描画時間を計測しておくことで、グラフィック性能差に応じた間引き回数を算出し、受信側では間引いて描画する動的間引き同期処理を行う。

図３５は、動的間引き同期処理の原理を説明する図である。同図中、ハッチングで示す矩形は、画面中に表示される３次元オブジェクトを模式的に示し、ＰＣ１，ＰＣ２は夫々コンピュータシステムを示す。ＰＣ１はＰＣ２よりグラフィック性能が高いため、図示の場合には、ＰＣ１が５回描画処理を行う間に、ＰＣ２は３回しか描画処理を行うことができないので、ＰＣ２については描画処理をＰＣ１より２回分間引くことで、高性能のグラフィックスボードを搭載しているＰＣ１と搭載していなＰＣ２との間でも、３次元オブジェクトのスムースな共有を可能とする。グラフィック性能の低いＰＣ２の方の描画時間をＴ２、グラフィック性能の高いＰＣ１の方の描画時間をＴ１とすると、ＰＣ２の描画処理をＴ２／Ｔ１で示される間引き回数だけ間引けば良い。描画時間の計測については、図３６と共に後述する。

ところで、３次元共有ビューアの部品移動や回転等の基本関数は、殆どが移動量を用いる差分駆動型であるが、差分データのままで上記動的間引き同期処理を行うと、クライアントシステム間で最終状態にずれが発生してしまう。このため、差分データは位置・姿勢情報に変更してから送信する必要がある。例えば、ＭｏｖｅＰｏｓ等のコマンドが差分駆動（ΔＸ）であったものは、位置駆動（Ｘ＝Ｘｐｒｅ＋ΔＸ）に修正する必要がある。そこで、例えば部品回転のダイアログ内の処理を解析し、差分駆動後の姿勢情報を送信し、受信側でその位置まで差分駆動させることで、動的間引き同期処理を実現する。

上記固定間引き同期処理では、送信側で各クライアントシステムのグラフィック性能に関わらず、一定時間毎に間引き処理を行う。これに対し、動的間引き同期処理では、グラフィック性能の低いクライアントシステムについては間引き処理を行うが、グラフィック性能の高いクライアントシステムに対しては間引き処理を行わないので、グラフィック性能の高いクライアントシステムの性能をフルに生かすことができる。

図３６は、動的間引き同期処理の受信側の処理を説明するフローチャートである。同図中、図４と同一部分には同一符号を付し、その説明は省略する。尚、送信側の処理は、基本的には図１３に示す処理と同様であるため、その図示及び説明は省略する。

図３６において、ステップＳＴ３１は、ステップＳ６０，Ｓ６１を含む前処理１を行い、ステップＳＴ３２は、ステップＳ６２〜Ｓ６４を含む前処理２を行う。

ステップＳ６０は、ファイル開く処理を行い、ステップＳ６１は、描画時間計測処理を行う。描画時間計測処理による受信側のクライアントシステムの描画時間の計測は、例えば最終的に描画するべきポリゴン数が変化する新規読み込み、追加読み込み、部品追加、部品交換時に行うことができる。尚、計測結果には、例えば０．１秒以下の誤差を含むが、この誤差を吸収するには、描画処理を複数回行って描画時間の平均値を求めて使用すれば良い。

ステップＳ６２は、操作者切替処理を行い、ステップＳ６３は、新たに操作権を持った操作者のクライアントシステムの描画時間を受信する。ステップＳ６４は、描画時間計測処理で求められた描画時間と、受信された操作者の描画時間とに基づいて、間引き回数計算処理を行って間引き回数を求める。

ステップＳＴ２２−１の受信データ解釈処理において、ステップＳ５３の後には、ステップＳ５９により動的間引きを行うか否かを判定する。ステップＳ５９の判定結果がＮＯであると、処理はステップＳ５５へ進む。他方、ステップＳ５９の判定結果がＹＥＳであると、処理はステップＳＴ３３の動的間引き同期処理に進む。ステップＳＴ３３は、ステップＳ６５〜Ｓ６８を含む。

ステップＳ６５は、ＣＰＵ２０１の内部タイマで計測されている間引き回数が、ステップＳ６４で求められた間引き回数に達したか否かを判定し、判定結果がＹＥＳであると、処理は終了する。ステップＳ６５の判定結果がＮＯであると、間引き処理を行って、ステップＳ６６及びステップＳ６７は夫々ステップＳ５５及びステップＳ５６と同様な全体データ更新処理及び描画処理を行う。又、ステップＳ６８は、内部タイマの計測値を１だけインクリメントするタイマ増加処理を行い、処理はステップＳ６５へ戻る。

次に、上記動的間引き同期処理を行う際に、ＬＯＤ（ＬｅｖｅｌＯｆＤｅｔａｉｌ）を併用するＬＯＤ動的間引き同期処理について、図３７及び図３８と共に説明する。図３７は、ＬＯＤ動的間引き同期処理の原理を説明する図であり、図３８は、ＬＯＤ動的間引き同期処理の受信側の処理を説明するフローチャートである。

ポリゴン・リダクション・アルゴリズムを用いると、例えば３５万ポリゴンからなる３次元オブジェクトを４万ポリゴン程度にスムースに減らすことができ、描画速度もその分向上する。しかし、ポリゴン数を減らしすぎると、３次元オブジェクトが製品モデルの場合には、製品モデルとしての見栄えが悪くなり、他方、ポリゴン数があまり多いと描画速度が遅くなり、ポリゴン・リダクション・アルゴリズムを用いた意味がなくなってしまう。

そこで、見栄えや描画速度の観点から、３次元オブジェクトを構成する各部品のポリゴン数を丁度良い比率で減らすために幾つかのレベルを用意して、３次元オブジェクトと視点との距離等に応じてポリゴン・リダクション・レベルを変えて描画するのが、コンピュータグラフィックス（ＣＧ）分野で用いられるＬＯＤである。例えば、元の３５万ポリゴンで描画するレベルをレベル０、４万ポリゴン程度に減らして描画するレベルをレベル２、その中間の１０万ポリゴン程度で描画するレベルをレベル１とする。レベル２の場合、単純に約１／９倍にはならないが、例えば約１／５倍にはなり、かなり描画時間を短縮することができる。従って、ＬＯＤを採用することで、上記動的間引き同期処理における間引き回数を少なくして、よりスムースに、且つ、違和感なく、クライアントシステム間で同期した描画処理を行うことができる。

図３７において、描画速度の速いコンピュータシステムＰＣ１で３次元オブジェクト（この場合は車）がＬＯＤのレベル０で描画されており、位置がΔＰだけ変化したとする。この位置変化に対応する変化情報を受信した描画速度の遅いコンピュータシステムＰＣ２では、コンピュータシステムＰＣ１のグラフィック性能がコンピュータシステムＰＣ２の３倍であると仮定すると、ＬＯＤのレベル２にして描画時間を約１／５倍にすれば、間引くことなく描画処理を行うことができる。又、コンピュータシステムＰＣ１のグラフィック性能がコンピュータシステムＰＣ２の１０倍であると仮定すると、ＬＯＤのレベル２にして描画時間を約１／５倍にすれば、ＬＯＤを採用しない場合には１０回毎にしか描画処理が行われないのに対し、２回毎に描画処理を行うことができる。図３７は、コンピュータシステムＰＣ２において、移動中の３次元オブジェクトがＬＯＤのレベル２で描画される様子を示している。

従って、ＬＯＤ動的間引き同期処理によると、ＬＯＤを採用しない動的間引き同期処理の場合と比較すると、間引き回数が減り、その分３次元オブジェクトがスムースに描画される。

図３８に示すステップＳＴ３７は、図３５に示すステップＳＴ３２の代わりに前処理２−１を実行する。前処理２−１は、ステップＳ７１〜Ｓ７４からなる。ステップＳ７１は、ＬＯＤ作成処理を行い、ＬＯＤレベルを作成する。ステップＳ７２は、ＬＯＤレベル設定処理を行い、使用するＬＯＤレベルを設定する。ステップＳ７３は、描画時間を計測し、ステップＳ７４は、間引き回数計算処理を行って、設定されたＬＯＤレベル及び計測された描画時間に基づいて、間引き回数を計算する。受信側のその他の処理は、図３６の場合と同じであるので、その図示及び説明は省略する。

次に、移動、回転等の３次元オブジェクトに対する操作の停止時に、遠隔地間で共有している３次元オブジェクトをスムースに、且つ、違和感なく同期させて描画するための飛ばし同期処理について、図３９及び図４０と共に説明する。

図３９は、飛ばし同期処理の原理を説明するための図である。グラフィック性能の異なるコンピュータシステム間で３次元共有ビューアを共有すると、グラフィック性能の低いコンピュータシステムＰＣ２の描画処理はグラフィック性能の高いコンピュータシステムＰＣ１の描画処理より遅れる。そこで、部品の移動中にＰＣ１の操作が止まると、ＰＣ２は途中のコマンドを飛ばして最後の優先コマンドを実行する、図３９に示す如き飛ばし同期処理を行う。この飛ばし同期処理と、上記動的間引き同期処理とを併用すれば、グラフィック性能の低いコンピュータシステムＰＣ２であっても、グラフィック性能の高いコンピュータシステムＰＣ１とスムースに３次元共有ビューアを共有することができる。

図４０は、飛ばし同期処理の受信側の処理を説明するフローチャートである。同図中、図３６と同一部分には同一符号を付し、その説明は省略する。

図４０において、ステップＳＴ２２−２の受信データ解釈処理では、ステップＳ５２の判定結果がＮＯであると、ステップＳ７９で飛ばし同期処理を行うか否かを判定し、判定結果がＮＯであると、処理はステップＳ５３へ進む。他方、ステップＳ７９の判定結果がＹＥＳであると、ステップＳＴ３９は、ステップＳ８０を含む飛ばし同期処理を行う。ステップＳ８０は、例えば受信側の３次元共有ビューアの通信Ｉ／Ｆ内にバッファリングされている操作コマンドのうち、最後の優先コマンドを除く操作コマンド（受信データ）を削除して、優先コマンドを実行する。ステップＳ８０の後、処理はステップＳ５３へ進む。

次に、各ローカルサイトのクライアントシステムのＣＰＵ性能が均一でない場合に、計算時間のかかる処理をスムースに、且つ、違和感なく同期される長時間処理同期処理を、図４１及び図４２と共に説明する。

図４１は、ＣＰＵ性能差による処理のずれを説明する図である。同図中、コンピュータシステムＰＣ１のＣＰＵ性能がコンピュータシステムＰＣ２のＣＰＵ性能より高いと、ＰＣ１で処理が終了して次の処理を行っている間も、ＰＣ２では最初の処理を行っている。このため、コンピュータシステムＰＣ１，ＰＣ２間で３次元共有ビューアの共有状態にずれを発生してしまう。つまり、操作者が例えばモデル読み込み操作を行い、会議に参加した全てのクライアントシステムでモデル読み込みが終了していない時に次の操作に移ると、共有状態に破綻が起きる可能性がある。

そこで、このような場合には、長時間処理同期処理を行えば良い。図４２は、長時間処理同期処理の原理を説明する図である。同図に示すように、長時間処理が発生する場合には、全参加者のクライアントシステムの処理が終了するまで、「待機中人数／参加人数」等のダイアログを表示して、次の操作を待たせる。更に、会議中にある参加者が退席した場合等にも、参加人数を自動的に減算して変更することで、同様な緒時間処理同期処理を可能とすることができる。

次に、停止位置同期処理について、図４３〜図４７と共に説明する。停止位置同期処理は、動作パスを持つ製品モデルデータの再生状態から停止状態になった場合に、止める位置（パス番号）を送受信してその位置で止める処理である。

会議中は、消費する記憶容量を抑制するために、動作パス作成を禁止しても、製品モデルの動作を議論する会議等では、動作パス再生を共有して議論する必要がある。そこで、動作パス作成はスタンドアローンの３次元共有ビューアで行うものとし、アセンブリデータと同様に事前配信済みの動作パスデータを開くと動作パス再生を共有できるようにする。動作パス再生機能の共有において、事前配済みの同じ動作パスを各クライアントシステムで同時に再生しても、グラフィック性能に差があると性能の低いクライアントシステムでの再生が遅れてしまい、再生にずれが発生してしまう。このため、再生を途中で停止させた場合にも、停止位置がずれてしまう。

そこで、停止状態になった場合には、止める位置（パス番号）を送受信し、その位置で止める停止位置同期処理を、図４３及び図４４に示すように行う。図４３は、グラフィック性能の高いコンピュータシステムＰＣ１で操作が行われ、操作者からグラフィック性能の低いコンピュータシステムＰＣ２へ停止位置（パス番号）を送信する場合を示す図である。又、図４４は、グラフィック性能の低いコンピュータシステムＰＣ２で操作が行われ、操作者からグラフィック性能の高いコンピュータシステムＰＣ１へ停止位置（パス番号）を送信する場合を示す図である。図４３及び図４４において、「停止番号」は停止位置を示すパス番号であり、「再生中番号」は再生中のパス番号である。

図４５は、図４３及び図４４の停止位置同期処理を説明するフローチャートである。同図中、図１３及び図１４と同一部分には同一符号を付し、その説明は省略する。

図４５において、ステップＳ４８は、パスの再生／停止処理を行う。ステップＳ２１−１の送信データ作成処理は、停止位置コマンド及び停止パス番号を送信するステップＳ４９を含む。他方、ステップＳ２２−３の受信データ解釈処理は、停止位置コマンド及び停止パス番号を受信したか否かを判定するステップＳ８１を含み、判定結果がＹＥＳとなると、処理はステップＳ４１−１の停止位置同期処理に進む。

停止位置同期処理は、ステップＳ８３〜Ｓ８９を含む。ステップＳ８３は、停止位置を判定し、停止パス番号が受信側のパス番号より小さい場合は処理がステップＳ８４へ進み、停止パス番号が受信側のパス番号より大きい場合は処理がステップＳ８５へ進み、停止パス番号と受信側のパス番号とが一致する場合は処理がステップＳ８８へ進む。ステップＳ８４は、１ステップ（コマ）前へ戻り、ステップＳ８５は、１ステップ（コマ）次へ進む。ステップＳ８４又はＳ８５の後、ステップＳ８６は、パスデータセット処理を行ってパスデータをセットする。又、ステップＳ８７は、全体データ更新処理を行い、処理はステップＳ８３へ戻る。ステップＳ８８は、描画処理を行い、ステップＳ８９は、パス停止処理を行って、処理は終了する。

更に、停止位置同期処理は、動作パス再生途中において、例えば１０回毎といった具合に、定期的に行って停止位置のずれを防止するようにしても良い。図４６は、停止位置同期処理を動作パス再生途中に、１０回毎に行う場合を示す図である。

図４７は、図４６の停止位置同期処理を説明するフローチャートである。同図中、図４５と同一部分には同一符号を付し、その説明は省略する。

図４７において、ステップＳＴ２１−２の送信データ作成処理は、パス再生処理を行うステップＳ９０を含む。又、送信側の処理には、ステップＳ９１及びステップＳ９２が含まれる。ステップＳ９１は、パス番号判定処理を行い、パス番号が１０の倍数であるか否かを判定する。ステップＳ９１の判定結果がＹＥＳであると、ステップＳ９２は、現在位置コマンド及び停止パス番号を送信する。この場合、ステップＳＴ４１−１の停止位置同期処理には、ステップＳ８９が含まれない。

次に、動作パスを持つ製品モデルの再生中に、動的間引き同期処理を適用するパス再生同期処理を、図４８と共に説明する。図４８は、パス再生同期処理を説明するフローチャートである。同図中、図４５と同一部分には同一符号を付し、その説明は省略する。

動的間引き同期処理を採用すると、描画速度の遅いコンピュータシステムであっても、３次元オブジェクトの概略の動きを他のコンピュータシステムと同期して確認することができる。しかし、概略の動きの中で、ある部分では、より厳密な移動パスを確認したい場合もある。そこで、再生同期処理は、より厳密な移動パスを確認したい部分では、一時停止して、前後に１コマずつ順逆再生することで、移動パスを確認可能とする。

図４８において、ステップＳＴ４５は、パス再生処理を行うステップＳ９６と、パス番号判定処理を行うステップＳ９７を含む。ステップＳ９７は、パス番号が１０の倍数であるか否かを判定する。ステップＳ９７の判定結果がＮＯであると、処理はステップＳ４３へ進む。他方、ステップＳ９７の判定結果がＹＥＳであると、ステップＳＴ２１−１の送信データ作成処理が行われる。送信データ作成処理は、再生位置コマンド及び再生パス番号を送信するステップＳ９９を含む。又、ステップＳＴ２２−４の受信データ解釈処理は、再生位置コマンド及び再生パス番号を受信したか否かを判定するステップＳ９５を含む。ステップＳ９５の判定結果がＹＥＳであると、ステップＳＴ４１−２の再生同期処理が行われる。

再生同期処理は、ステップＳ８３−１〜Ｓ８８−１を含む。ステップＳ８３−１は、再生位置を判定し、再生パス番号が受信側のパス番号より小さい場合は処理がステップＳ８４−１へ進み、再生パス番号が受信側のパス番号より大きい場合は処理がステップＳ８５−１へ進み、再生パス番号と受信側のパス番号とが一致する場合は処理がステップＳ８８−１へ進む。ステップＳ８４−１は、１ステップ（コマ）前へ戻り、ステップＳ８５−１は、１ステップ（コマ）次へ進む。ステップＳ８４−１又はＳ８５−１の後、ステップＳ８６−１は、パスデータセット処理を行ってパスデータをセットする。又、ステップＳ８７−１は、全体データ更新処理を行い、処理はステップＳ８３−１へ戻る。ステップＳ８８−１は、描画処理を行い、処理は終了する。

次に、動作パスを持つ製品モデルデータの再生中に、コンピュータシステムの中で最も描画速度の遅いコンピュータシステムに合わせて再生を行う待機同期処理について、図４９〜図５２と共に説明する。図４９は、待機同期処理を説明する図であり、図５０は、待機同期処理を説明するフローチャートである。又、図５１はコンピュータシステムの仕様（以下、スペックと言う）を示す図であり、図５２は、スペックリストの作成及び更新を説明する図である。

部品移動、部品回転や視点変更では、最終状態が重要であるため、途中の状態は間引いても問題はない。しかし、動作の検証を行うためのパス再生の場合には、全ての動きが見えることが望ましい。そこで、このような要望がある場合には、図４９に示すように、参加者の中で最も描画速度の遅いコンピュータシステムに合わせて、描画速度の速いコンピュータシステムの描画処理を待機させる。同図中、ＰＣ１は描画速度の速いコンピュータシステムを示し、ＰＣ２は描画速度の遅いコンピュータシステムを示し、ハッチングで示す期間は待機期間を示す。これにより、例えば製品モデルの組み立てシーケンス等の動作確認を行いたい場合でも、グラフィック性能に差のあるコンピュータシステム間で、同期した描画処理を実現できる。

図５０において、ステップＳＴ５１の前処理１は、ステップＳ１０１〜Ｓ１０３を含む。ステップＳ１０１は、ファイル開く処理を行い、ステップＳ１０２は、描画時間計測処理を行う。ステップＳ１０３は、描画時間送信処理を行う。

ステップＳＴ５２の前処理２は、ステップＳ１０４〜Ｓ１０５を含む。ステップＳ１０４は、他のコンピュータシステム（他者）の描画時間を受信する処理を行い、ステップＳ１０５は、コンピュータシステムのスペックリスト（ＰＣスペックリスト）作成処理を行う。ＰＣスペックは、例えば図５１に示す如く、ユーザ番号、ＣＰＵ数、ＣＰＵ周波数、ＣＧ描画時間（秒）、ＣＰＵ処理時間（秒）等の情報を含む。ＰＣスペックリストは、ＰＣスペックからなるリストである。ステップＳ１０６は、描画速度が最も遅いコンピュータシステムの描画時間から、操作されているコンピュータシステムの描画時間を減算して待機時間を求める、待機時間計算処理を行う。このようにして求められた待機時間は、後述するステップＳＴ５５のパス再生処理で使用される。

ステップＳＴ５３の前処理３は、ステップＳ１０７〜Ｓ１０９を含む。ステップＳ１０７は、退席処理を行って、会議から退席した参加者を通知する。ステップＳ１０８は、途中参加処理を行って、会議に途中参加した参加者を通知する。ステップＳ１０９は、退席者や途中参加者に応じて、ＰＣスペックリストを更新するＰＣスペックリスト更新処理を行う。

各コンピュータシステムの描画時間に関するＰＣスペックリストの作成及び更新を、図５２と共に説明する。同図中、（ａ）はユーザ１，２の会議参加時に作成されるＰＣスペックリスト、（ｂ）はユーザ３が会議に途中参加した時に更新されたＰＣスペックリスト、（ｃ）はユーザ２が会議から退席した時に更新されたＰＣスペックリストを示す。

図５２（ａ）において、ユーザ３，４，...が存在する場合には、ユーザ１，２のリストにユーザ３，４，...のリストが続くようにＰＣスペックリストを作成する。

ユーザ１，２の会議中に、ユーザ３が途中参加すると、再度ファイルを開き直すので、その時に一旦リストを削除して、初期状態と同様にリストを作成し直すことで、図５２（ｂ）に示すようにＰＣスペックリストを更新する。この場合、ユーザ１，２のデータをユーザ３に送信する方法と比べると、処理の統一及び簡略化が可能となる。尚、ＣＧ描画時間のデータ送信は重複するが、途中参加者は頻繁に発生するものではなく、又、ＣＧ描画時間のデータ送信時間は途中参加者のために送信される最新アセンブリデータファイルの送信時間に比べて無視できる程度に短いので、不都合は発生しない。

会議中に退席者が出ると、図５２（ｃ）に示すように、ＰＣスペックリスト内部のデータを更新する。この場合、退席者であるユーザ２が会議から退席する際に、３次元共有ビューアは自動的に他の３次元共有ビューアに退席を通知する。退席を通知された３次元共有ビューアは、退席者番号のＰＣスペックリストの例えば描画時間を０にする。退席者のＰＣスペックリストは、リスト最後尾に配置し直され、描画時間判定でそれ以降のＰＣスペックリストを参照する必要がなくなる。これにより、複数の退席者が出た場合の待機時間計算処理を効率化することができる。又、更新されたＰＣスペックリストの中で、最も描画速度の遅いコンピュータシステムを判定できるので、その判定結果に基づいて以後のパス再生時のパス待機時間が再決定することができる。

図５０の待機同期処理の説明に戻ると、ステップＳＴ２２−５の受信データ解釈処理は、パス再生コマンド又はパス停止コマンドを受信したか否かを判定するステップＳ１１１を含む。ステップＳ１１１の判定結果がＹＥＳであると、ステップＳＴ５５のパス再生処理が行われる。パス再生処理は、ステップＳ１１３〜Ｓ１１８を含む。

ステップＳ１１３は、パス再生を行うか否かを判定し、判定結果がＮＯであると、処理は終了する。他方、ステップＳ１１３の判定結果がＹＥＳであると、ステップＳ１１４は、パスデータセット処理によりパスデータをセットする。ステップＳ１１５は、全体データ更新処理を行い、ステップＳ１１６は、描画処理を行う。ステップＳ１１７は、待機同期処理を行うか否かを判定し、判定結果がＮＯであると、処理はステップＳ１１３へ戻る。ステップＳ１１７の判定結果がＹＥＳであると、ステップＳ１１８は、ステップＳ１０６で求めた待機時間に基づいて、待機時間だけ処理を停止し、処理はステップＳ１１３へ戻る。

図５３は、本発明になる３次元オブジェクト共有処理方法の第２実施例を適用可能なサーバ・クライアントシステムを示す図である。同図中、図１と同一部分には同一符号を付し、その説明は省略する。図５３に示すサーバ・クライアントシステムでは、複数のコンピュータシステム１−１〜１−３が、ＬＡＮ９−１を介して接続されており、第１のシステムを構成する。又、複数のコンピュータシステム１−４，１−５が、ＬＡＮ９−２を介して接続されており、第２のシステムを構成する。第１及び第２のシステムは、ＷＡＮ等のネットワーク２を介して接続されている。説明の便宜上、コンピュータシステム１−１がサーバを構成し、他のコンピュータシステム１−２〜１−５がクライアントを構成するものとする。勿論、コンピュータシステム１−１は、サーバ及びクライアントの両方の機能を有する構成であっても良い。本実施例では、説明の便宜上、コンピュータシステム１−１〜１−５が全て同じ基本構成を有するものとするが、サーバを構成するコンピュータシステム１−１とクライアントを構成するコンピュータシステム１−２〜１−５とは、図５４に示すように互いに異なる基本構成を有しても良い。又、コンピュータシステム１−１〜１−６のうち、２以上のコンピュータシステムが互いに異なる基本構成を有しても良い。

次に、会議への途中参加者に、会議の最新の状態を通知する処理について説明する。図５４に示すように、会議に遅刻したユーザ（途中参加者）は、ディスプレイ１０２に表示された会議管理ウィンドウ内に配置された「参加」ボタンを押して、既に開催中の会議に途中参加する。３次元共有ビューアが起動された後、途中参加者は「途中参加」ボタンを押す。途中参加者が会議の参加者として予め登録されていれば、３次元オブジェクトデータは予めこの途中参加者のクライアントシステムに配信済みである。従って、途中参加者には、３次元オブジェクトデータの最終状態（３次元共有ビューアアセンブリファイル）と現在の視点を配信すれば良い。尚、途中参加者が途中参加のための処理を行っている間は、データ配信のためにある程度は時間がかかるので、他の参加者との同期を取るために、会議を一時的に中断する。会議が一時的に中断されている間は、「途中参加中」のダイアログを参加者全員に表示して、３次元共有ビューアの操作を禁止して、途中参加のための処理が終了するまで待ち状態とする。

途中参加のための処理（以下、途中参加処理と言う）を、クライアントシステムの３次元共有ビューアで管理する場合、次のようなステップを実行すれば良い。

ステップｓｔ１：途中参加者のクライアントシステムにおいて、途中参加者が会議管理ウィンドウの「参加」ボタンを押す。

ステップｓｔ２：途中参加者のクライアントシステムから３次元共有ビューアへ途中参加要求を送信する。

ステップｓｔ３：各３次元共有ビューアは、途中参加者のクライアントシステムからの途中参加要求を受信する。

ステップｓｔ４：途中参加者のクライアントシステムの３次元共有ビューアから、自分以外のクライアントシステムへ途中参加中であることを送信する。

ステップｓｔ５：各クライアントシステムにおいて、例えば「途中参加中、一時中断します」なるメッセージダイアログを表示すると共に、３次元共有ビューアの操作を禁止する。

ステップｓｔ６：クライアントシステムが操作者又は議長のシステムであれば、３次元共有ビューアの最終状態の保存命令を送信する。

ステップｓｔ７：操作者又は議長以外の各クライアントシステムにおいて、３次元共有ビューアの最終状態を保存する。

ステップｓｔ８：予め設定されている保存ディレクトリへデータ配信を行い、操作者又は議長のクライアントシステムから途中参加者のクライアントシステムへアセンブリデータを送信する。

ステップｓｔ９：各クライアントシステムにおいて、ファイルを一斉に開く。

ステップｓｔ１０：「途中参加中、一時中断します」なるメッセージダイアログの表示を消し、会議を再開する。

他方、途中参加処理を、サーバシステムの３次元共有ビューアで管理する場合、次のようなステップを実行すれば良い。尚、以下の説明で、ｓｔが付されたステップはクライアントシステムで実行され、ｓｔｓが付されたステップはサーバシステムで実行される。

ステップｓｔ１１：途中参加者のクライアントシステムにおいて、途中参加者が会議管理ウィンドウの「参加」ボタンを押す。

ステップｓｔ１２：途中参加者のクライアントシステムから３次元共有ビューアへ途中参加要求を送信する。

ステップｓｔｓ１３：サーバシステムの３次元共有ビューアは、途中参加者のクライアントシステムからの途中参加要求を受信する。

ステップｓｔｓ１４：サーバシステムの３次元共有ビューアから、途中参加者以外のクライアントシステムへ途中参加中であることを送信する。

ステップｓｔ１５：各クライアントシステムにおいて、例えば「途中参加中、一時中断します」なるメッセージダイアログを表示すると共に、３次元共有ビューアの操作を禁止する。

ステップｓｔｓ１６：サーバシステムにより、途中参加者のクライアントシステムから最も近いクライアントシステムを自動検索して、会議情報を獲得する。

ステップｓｔｓ１７：サーバシステムにより、途中参加者のクライアントシステムに最も近いクライアントシステムへ、３次元共有ビューアの最終状態の保存命令を送信する。

ステップｓｔ１８：途中参加者のクライアントシステムに最も近いクライアントシステムにおいて、３次元共有ビューアの最終状態を保存する。

ステップｓｔ１９：予め設定されている保存ディレクトリへデータ配信を行い、途中参加者のクライアントシステムに最も近いクライアントシステムから、途中参加者のクライアントシステムへアセンブリデータを送信する。

ステップｓｔｓ２０：サーバシステムは、各クライアントシステムにおいてファイルを一斉に開かせる。

ステップｓｔｓ２１：サーバシステムは、各クライアントシステムにおいて「途中参加中、一時中断します」なるメッセージダイアログの表示を消させ、会議を再開させる。

上記の途中参加処理では、途中参加者がボタンを押す等の操作をして途中参加要求を行うが、以下の如く、途中参加要求を自動的に行う構成とすることもできる。つまり、開催中の会議に操作者がいるか、或いは、ファイルが開いている、といういずれかの条件が満足されていれば、会議が進行中であり、且つ、途中参加者があるとみなして、自動的に途中参加処理を行う自動途中参加処理を実行しても良い。

例えば、ユーザＡ，Ｂで会議を進行中に、ユーザＣが会議に途中参加したい場合、ユーザＣのクライアントシステムにおける３次元共有ビューアの画面を、ユーザＡ，Ｂのクライアントシステムにおける３次元共有ビューアの画面と同一にする。ユーザＣのクライアントシステムにおける会議状態モジュールは、自分自身及び他のユーザＡ，Ｂのクライアントシステムの３次元共有ビューアへ、会議への途中参加を通知する。各３次元共有ビューアでは、対応するクライアントシステムの状態を判別して、自動的に次のような処理を行う。

即ち、途中参加者があると、ダイアログを送信して３次元共有ビューアの操作を禁止する。又、ユーザＡ又は議長のクライアントシステムの３次元共有ビューアの状態を一度アセンブリファイルとして保存し、このアセンブリファイルを途中参加者であるユーザＣへ転送する。そして、各３次元共有ビューアでは、一斉にファイルを開く。尚、ユーザＢ及びユーザＡ，Ｃ以外のユーザが存在する場合には、ユーザＡのクライアントシステムにおけるファイル保存時に、共有コマンドによりユーザＢ及びユーザＡ，Ｃ以外のユーザのクライアントシステムにおいても同様にファイル保存を行う。

上記第１実施例と共に説明した如く、操作コマンドを操作者以外に一斉送信する処理と、各ローカルサイトのクライアントシステム内の別ディレクトリにある３次元オブジェクトデータを一斉に読み込む処理とを併用することで、各クライアントシステムに操作コマンドをファイル名と共に一斉送信して、参次元オブジェクトのアセンブリデータを保存させることができる。この時、同時に視点の保存機能を用いることで、最終画面を得ることができる。

従って、上記の如き自動途中参加処理は、途中参加者の会議状態モジュール、途中参加者の３次元共有ビューア及び途中参加者以外の参加者の３次元共有ビューアにおいて行う、次のようなステップにより実現できる。

途中参加者の会議状態モジュール：
ステップｓｔ３１：起動直後に３次元共有ビューアに途中参加要求送信する。

途中参加者の３次元共有ビューア：
ステップｓｔ３２：途中参加要求を受信する。

ステップｓｔ３３：例えば、「自分が途中参加中...」なるダイアログを表示し、他の３次元共有ビューアに途中参加コマンドを送信する。

途中参加コマンドを受信した途中参加者以外の参加者の３次元共有ビューア（操作者の場合）：
ステップｓｔ３４：例えば、「ユーザが途中参加中...」なるダイアログを表示する。

ステップｓｔ３５：３次元共有ビューアの最終状態（アセンブリファイル）を一度ファイル保存する。

ステップｓｔ３６：アセンブリファイルを途中参加者へファイル送信する。

ステップｓｔ３７：一斉にファイルを再度開く。

ステップｓｔ３８：例えば「ユーザが途中参加中...」なるダイアログの表示を消す。

途中参加コマンドを受信した途中参加者以外の参加者の３次元共有ビューア（操作者がおらず、ファイルが開いている場合で、且つ、ユーザが議長である場合）：
ステップｓｔ４１：例えば、「ユーザが途中参加中...」なるダイアログを表示する。

ステップｓｔ４２：操作者となる。

ステップｓｔ４３：３次元共有ビューアの最終状態（アセンブリファイル）を一度ファイル保存する。

ステップｓｔ４４：アセンブリファイルを途中参加者へファイル送信する。

ステップｓｔ４５：一斉にファイルを再度開く。

ステップｓｔ４６：操作権を放棄し、元の状態に戻す。

ステップｓｔ４７：例えば「ユーザが途中参加中...」なるダイアログの表示を消す。

途中参加コマンドを受信した途中参加者以外の参加者の３次元共有ビューア（上記以外の場合）：
ステップｓｔ５１：例えば「ユーザが途中参加中...」なるダイアログを表示し、待機する。

ステップｓｔ５２：操作者又は議長の一斉別名保存コマンドを受信し、自分のクライアントシステム上に最終状態を保存する。

ステップｓｔ５３：一斉に開くコマンドを受信してファイルを開く。

ステップｓｔ５４：例えば「ユーザが途中参加中...」なるダイアログの表示を消す。

上記の如き途中参加処理及び自動途中参加処理の切替設定は、例えば会議管理モジュールで会議を作成する際に、属性フラグとして３次元共有ビューア種類を選択する項目と同時に設定することもできる。この場合、設定が自動であれば、自動途中参加処理が自動的に開始される。又、設定が手動の場合は、途中参加者が「途中参加」のボタンを押すことで開始される。

次に、途中参加者が予め会議の参加者として登録されている場合に、途中参加に必要なデータを、途中参加者のクライアントシステムに最も近いクライアントシステムから逐次転送する、途中参加データ転送処理について説明する。

上記自動途中参加処理は、途中参加者以外の参加者に意識させないことが望ましい。そこで、途中参加データ転送処理は、途中参加中のダイアログが表示されたり、他の参加者の操作を中断させないようにするために、途中参加に必要なデータを、途中参加者のクライアントシステムに最も近いクライアントシステムから逐次転送する。３次元オブジェクトに関する差分データを送り続け、途中参加者のクライアントシステムにおける３次元オブジェクトの状態が他の参加者のクライアントシステムにおける状態と一致した時点で、自動途中参加処理が完了したものと判断する。

途中参加データ転送処理は、以下のステップにより実現できる。

ステップｓｔ６１：途中参加者が、会議管理ウィンドウの「参加」ボタンを押すと、途中参加者のクライアントシステムの３次元共有ビューアにより例えば「途中参加中」なるメッセージを送信し、同時に各３次元共有ビューアの操作を禁止する。

ステップｓｔ６２：途中参加者のクライアントシステムの３次元共有ビューアは、最も近いクライアントシステムを、例えばサーバシステムに問い合わせる。

ステップｓｔ６３：最も近いクライアントシステムは、３次元共有ビューアの最終状態を保存する。

ステップｓｔ６４：最も近いクライアントシステムは、途中参加者のクライアントシステムへデータを配信しる。

ステップｓｔ６５：途中参加者のクライアントシステムは、受信したデータを予め設定されている保存ディレクトリに保存する。

ステップｓｔ６６：データ配信中に、最も近いクライアントシステムにおいて変化があると、３次元オブジェクトの最後の位置や姿勢等のデータを送信するか、或いは、動作パスコマンドを送信し続ける。最も近いクライアントシステムから最終状態を送信すると、フラグを立てて、この状態で操作者の操作コマンドを受信すると、３次元共有ビューアから途中参加者のクライアントシステムへコマンドを送信する。

ステップｓｔ６７：途中参加者のクライアントシステムの３次元共有ビューアは、コマンドを受信して、バッファリングデータがなくなるまで３次元オブジェクトの再生を行う。

ステップｓｔ６８：途中参加者のクライアントシステムの３次元共有ビューアは、差分データを受信しなくなると、他の参加者のクライアントシステムと同じ状態になったことを判断して、途中参加が完了したとみなす。

ステップｓｔ６９：途中参加者のクライアントシステムの３次元共有ビューアは、「途中参加中」のダイアログの表示を消す。

次に、途中参加者が予め会議の参加者として登録されていない場合の未登録参加者の途中参加処理について説明する。途中参加者が予め会議の参加者として登録されていない場合には、３次元オブジェクトデータを途中参加者のクライアントシステムに転送する必要がある。しかし、３次元オブジェクトの部品数が多いと、ファイル転送に時間がかかるので、ファイル転送を行う前に、次のような処理を行い、この処理の後で、上記の如く途中参加者が予め会議の参加者として登録されている場合と同様な処理を行えば良い。

会議の参加者と共通の３次元オブジェクトデータ（形状データやアセンブリデータ）を持たない新たな参加者が会議に途中参加する場合には、操作者又は議長のクライアントシステムの３次元共有ビューアからＣＧ部分をイメージ出力して、ｊｐｇ形式又はｂｍｐ形式で新な参加者のクライアントシステムへ転送する。又、新たな参加者のクライアントシステムへは、例えば「会議最新状態の画像が受信されました」なるメッセージを送信して表示させる。この場合、ｊｐｇファイルを選択すると、関連付けられていればＷＥＢブラウザが開き、そうでなければｊｐｇ用のアプリケーションが起動される。ｂｍｐファイルを選択すると、関連付けられていればペイントツールが開き、そうでなければｂｍｐ用のアプリケーションが起動される。ｊｐｇ形式を採用すると、ファイルサイズが例えば６４ＫＢとなり、ｂｍｐ形式を採用すると、ファイルサイズが例えば３７２ＫＢとなるので、ｊｐｇ形式を採用した方がファイルサイズを小さくすることができる。

会議用ファイルは、例えば新たな参加者に最も近いクライアントシステムから新たな参加者へ自動的に送信しても、サーバクシステムから手動で受信するようにしても良い。後者の場合、サーバシステムは、例えば「会議用ファイルを受信してから継続を押して下さい」なるメッセージを新たな参加者のクライアントシステムに表示させ、新たな参加者が会議用ファイルをサーバシステムから受信した後に「継続」のボタンを押すと、上記の如き途中参加者が予め登録されている場合と同様な途中参加処理が行われて、新たな参加者のクライアントシステムにおいても３次元オブジェクトデータが最新状態となる。

次に、動作パス記録が可能な場合に、途中参加者に３次元オブジェクトの最新の状態を配信する最新状態配信処理について説明する。

クライアントシステムの記憶容量が十分大きい場合には、動作パスの記録が可能であるため、３次元オブジェクトの最終状態（アセンブリファイル）のみを配信するか、最終状態又は操作履歴（パスファイル）をデータサイズに応じて切り替えて配信するようにしても良い。会議終了後に、議長の動作パス付きアセンブリデータを各参加者のクライアントシステムに配信すれば、会議終了後に各ローカルサイトで動作パスを確認することができる。

３次元共有ビューアを共有するモードと、共有しない非共有モードとは、任意に切り替え可能な構成としても良い。つまり、非共有モード中、ローカルサイトでモード切替操作を行い、モードの切り替え後は途中参加処理の応用により、各ローカルサイトの状態を一致させてモードを共有モードに切り替えることができる。この場合、３次元共有ビューアは、非共有モード／共有モードの切り替え用に、「共有停止／開始」ボタンを持たせれば良い。共有モードの停止と開始は、参加者が自分１人だけで３次元共有ビューアを操作したい場合には「共有停止／開始」ボタンで停止を指定することで、非共有モードに切り替える。他方、共有モードの開始を指定すると、途中参加処理の場合と同様の処理で、共有モードに切り替えられる。

上記モードの切り替えは、同期処理と高速データ転送が関連する。共有モードに復帰する際に、途中参加処理と同様に最新アセンブリデータの転送を行い、各参加者に持たせることができる。会議中に、他の参加者を待たせることはできるだけ避けたいので、独自に状態を確認したい参加者は、会議参加後に別の３次元ビューアをスタンドアローンで操作して見たい部分を確認すれば良い。

次に、メール連携処理について、図５５〜図５８と共に説明する。図５５は、メール着信を説明する図、図５６は、ＷＥＢブラウザを説明する図、図５７は、データ自己解凍を説明する図、図５８は、データの保存先を説明する図である。

メール着信、ＷＥＢからのダウンロード、自己解凍処理を実行すると、３次元オブジェクトデータが自己解凍される。その後、バッチ処理が自動的に起動され、会議開始時刻設定ファイルを指定場所にコピーして、会議環境を自動的に設定する。会議の自動起動に必要な会議開始時刻の設定ファイルも、同様に指定場所にコピーする。

図２３に示す如き会議開催通知のメールが着信すると、メールのＵＲＬから図２４に示す如きＷＥＢブラウザを開いて、３次元共有ビューアデータをダウンロードする。３次元オブジェクトデータの自己解凍は、３次元共有ビューアを起動することで行われ（ＳＡＩＫＵＤＡＴＡＶＰＳ．ｅｘｅ）、例えば図５７に示すメニュー中、「はい」のボタンを押すことで自己解凍が行われる。自己解凍されたデータの保存先は、例えば図２６に示すメニューの場合にはＣ：￥ＶＰＳ＿ＴＥＭＰなるディレクトリであり、これで良ければ「ＯＫ」のボタンを押す。保存先を変えたい場合には、「参照（Ｂ）」のボタンを押して設定する。その後、バッチ処理が自動起動され、会議開始時間設定ファイルをＣ：￥ｗｉｎｎｔにコピーする。コピーされた会議開始時間設定ファイルは、後述するシステムの自動起動処理で使用される。尚、会議主催者は、会議に必要なデータ圧縮やバッチ処理を行う前処理を実行する必要があることは、言うまでもない。

会議開催通知のメールに添付した実行形式から、即時に会議を起動する構成としても良い。この場合、会議で開くべきファイル名をバッチ処理に書き込んでおけば、３次元共有ビューアはそのファイルを引数として実行し、起動すると同時に自動的にファイルを開く。これにより、通常は操作者がファイルチューザでディレクトリを移動してファイルを選択していた操作を、自動化することができる。

次に、システムの自動起動処理について、図５９〜図６２と共に説明する。図５９は、自動起動処理を説明する図、図６０は、５分前起動確認処理を説明する図、図６１は、１分前起動確認処理を説明する図である。又、図６２は、会議開催（参加）処理を説明する図である。

自動起動処理は、会議開始時間になると、自動的にシステムを起動する処理である。この場合、各クライアントシステム及びサーバシステムの時刻管理にずれが存在すると、システムは同時に立ち上がらない。そこで、ネットワークを介してグリニッジ時刻を獲得して、各クライアント及びサーバシステムの時刻合わせを行う。各クライアント及びサーバシステムは、ローカル時刻を表示する機能を備える。

会議に自動起動機能を設定しておくと、ログオン時に起動するＣｏｌｌａｂｏ＿ｄａｏｍｏｎから図５９に示す自動起動処理が起動され、会議開始時刻になると３次元共有ビューアを自動起動する。会議開始時刻は、会議設定ファイルに書かれている。会議開始時刻の例えば５分前には、図６０に示す５分前起動確認メニューを表示して、会議を開始するかをユーザに問い合わせる。図６０中、「はい（Ｙ）」のボタンを押すと、直ちに３次元共有ビューア（ＮｅｔＣｏｌｌａｂｏｒａｔｉｏｎ）を起動する。他方、図６０中、「いいえ（Ｎ）」のボタンを押すと、更に待機を続ける。会議開始時刻の例えば１分前には、図６２に示す１分前起動確認メニューを表示して、会議を開始するかをユーザに問い合わせる。図６１中、「はい（Ｙ）」のボタンを押すと、直ちに３次元共有ビューア（ＮｅｔＣｏｌｌａｂｏｒａｔｉｏｎ）を起動する。他方、図６１中、「いいえ（Ｎ）」のボタンを押すと、更に待機を続ける。又、図５９において、自動起動ダイアログ中の「実行」ボタンを押すと、上記の会議開始時間以外の時間であっても、直ちに３次元共有ビューア（ＮｅｔＣｏｌｌａｂｏｒａｔｉｏｎ）を起動して、会議を開始する。

つまり、Ｃｏｌｌａｂｏ＿ｄａｅｍｏｎは、会議開始時間になるか、或いは、図５９の自動起動ダイアログ中の「実行」ボタンを押すと、図６２に示す会議開催（参加）処理の中で、プロセス起動によって別モジュールの実行形式である会議管理と３次元共有ビューアを起動する。

次に、サイズ及び縦横比が異なる画面上でマウスカーソルが３次元オブジェクトの同じ位置を指す場合の処理について、図６３及び図６４と共に説明する。図６３は、異なる描画領域サイズにより発生する問題を説明する図であり、図６４は、異なる描画領域サイズでも３次元オブジェクトの同じ位置を指す処理を説明する図である。図６３及び図６４の夫々において、（ａ）は送信側の描画領域を示し、（ｂ）は受信側の描画領域を示す。

本実施例では、現在のマウスカーソル位置と３次元描画領域の中心からの差分に、各３次元共有ビューアの３時点描画領域の縦横の短い辺の比率を乗算することで、サイズ及び縦横比が異なる場合でも、マウスカーソルが指す位置を一致させる。

３次元描画領域サイズが異なるが、部品サイズは同じ場合、図６３（ａ）に示すように、描画領域の左上基準の３のマウスカーソル位置は、同図（ｂ）の描画領域では中心付近を指す。別の方法で、同図（ｂ）の描画領域中、横方向の長さの３／４のマウスカーソル位置としても、部品から外れてしまう。この状態では、同図（ａ），（ｂ）とで部品に対するマウスカーソル位置が異なり、３次元部品上の同じ点Ｐを指し示すことができない。３次元オブジェクトが多数の部品から構成されていると、一方が例えば部品番号５番を指し、他方が例えば部品番号７番を指してしまうこととなるという問題が発生する。

そこで、本実施例では、各ローカルサイトのユーザが、３次元共有ビューア画面を好きなサイズにしている場合には、３次元描画領域のサイズが異なり、それに伴って３次元オブジェクトのサイズを拡大又は縮小するようにする。描画領域の左上基準の座標値では、マウスカーソルの指す位置が、描画領域のサイズに応じてずれる。このため、現在のマウスカーソル位置Ｐ_ｐと３次元描画領域の中心Ｐ_ｇからの差分Ｐ_ｇｐに、各ローカルサイトにおける３次元描画領域の縦横の短い辺の比率を乗算することで、サイズ及び縦横比が異なる場合でも、マウスカーソルが指す位置を図６４（ａ），（ｂ）に示すように一致させる。これは、３次元共有ビューアの３次元描画処理では、３次元オブジェクトのサイズが描画領域の縦横の短い辺によって確定する特性を利用するものである。

受信側の描画領域における点Ｐは、受信側の描画領域の中心をＰ_ｇ、送信側の描画領域の中心点からの差分をＰ_ｇｐ、縦横の短い辺の比率をｍｉｎ＿ｌｅｎｇｔｈ＿ｒａｔｅ、受信側の縦横の短い辺をｍｉｎ＿ｌｅｎｇｔｈ、送信側の縦横の短い辺をｏｐ＿ｍｉｎ＿ｌｅｎｇｔｈとすると、つぎの式（１）及び式（２）で表される。

Ｐ_ｐ２＝Ｐ_ｇ２＋Ｐ_ｇｐ２＝Ｐ_ｇ２＋Ｐ_ｇｐ＊ｍｉｎ＿ｌｅｎｇｔｈ＿ｒａｔｅ
式（１）
ｍｉｎ＿ｌｅｎｇｔｈ＿ｒａｔｅ＝ｍｉｎ＿ｌｅｎｇｔｈ／ｏｐ＿ｍｉｎ＿ｌｅｎｇｔｈ
式（２）

次に、３次元ポインティング機能により指し示すポイントを明確にする処理を、図６５〜図６７と共に説明する。図６５は、針による３次元ポインティングを説明する図、図６６は、円錐による３次元ポインティングを説明する図、図６７は、注釈機能による３次元ポインティングを説明する図である。

３次元オブジェクト上で選択した点を中心に、図６５に示すように３次元の針、又は、図６６に示すように３次元の円錐を表示し、方向を変更することで、指し示すポイントを明確にすることができる。更に、図６７に示すように３次元ビューアは持つ３次元注釈機能を用いて、指し示すポイントを明確にすることもできる。

次に、２次元ポインティング機能により指し示すポイントを明確にする処理を、図６８と共に説明する。図６８は、２次元長方形によるポインティングを説明する図である。

図３５に示すように、３次元描画領域上に２次元の長方形、或いは、マウスカーソルの移動軌跡を結んだラフスケッチ等で上書きすることで、指し示すポイントを明確にして、３次元オブジェクト上の着目点を明確に伝達することができる。

次に、強制拡大により注目領域を一致させる処理について説明する。３次元オブジェクトの共有中に、受信側で別作業をしていて３次元描画領域を小さくしていると、良く見えないために干渉箇所等を明確に伝達できない場合がある。そこで、操作が「強制拡大」のボタンを押すと、強制的に相手の３次元描画領域を操作者と同じ大きさに拡大させる処理を行う。この場合、３次元描画領域のみ合わせる処理を行っても、操作者が画面サイズの情報を送信して、受信側で画面サイズを合わせる処理を行っても良い。

次に、操作権切替処理を、図６９と共に説明する。図６９は、操作権切替処理を説明する図である。

複数の参加者が一斉に操作を行おうとして、操作が混乱するのを防ぐため、「操作権取得」のボタンを押した参加者が操作権を持つと共に、３次元オブジェクトを共有する権限を持つようにする。この場合、フラグ判定を行って、操作権を持たない参加者が３次元共有ビューアを操作しようとした場合には排他制御を行って、操作を禁止するようにする。但し、この操作権を持たない参加者も、「操作権取得」のボタンを押すことで、直ちに前の操作者から操作権を取得することができる。又、「操作権ロック」のボタンを設け、このボタンが押されると操作権の移動を禁止するようにしても良い。図６９は、操作権の切り替えの状態を示す。

又、上記の操作権切替処理は、「操作権取得」のボタンを押すことなく、自動的に切り替えるようにしても良い。例えば、操作者以外の参加者がマウスカーソルを動かして、マウスカーソルを３次元共有ビューア上に入れたら自動的に操作権を取得するようにすることができる。

以上、本発明を実施例により説明したが、本発明は上記実施例に限定されるものではなく、本発明の範囲内で種々の変形及び改良が可能であることは、言うまでもない。

本発明になる３次元オブジェクト共有処理方法の第１実施例を適用可能なサーバ・クライアントシステムを示す図である。コンピュータシステムを示す斜視図である。コンピュータシステムの本体部内の要部の構成を示すブロック図である。会議を行う場合のサーバの動作を説明するフローチャートである。会議を行う場合のクライアントの動作を説明するフローチャートである。サーバシステムにおけるサーバ処理を説明する図である。クライアントシステムにおけるクライアント処理を説明する図である。サーバシステム及びクライアントシステムの接続状態を説明する図である。図８に示す接続状態を簡略化して示す図である。クライアントとして動作する３次元共有ビューアを説明する図である。クライアントとして動作する３次元共有ビューアを説明する図である。操作コマンドの共有を説明する図である。送信データ作成処理を説明するフローチャートである。受信データ解釈処理を説明するフローチャートである。描画処理の後に行うデータ送信を説明する図である。描画処理の前に行うデータ送信を説明する図である。送信側のクライアントシステムのコマンド処理を示す図である。受信側のクライアントシステムの受信処理を示す図である。受信側のクライアントシステムのコマンド処理を示す図である。受信側でのメニュー操作を禁止する処理を含む、送信側のクライアントシステムのコマンド処理を示す図である。受信側でのメニュー操作を禁止する処理を含む、受信側のクライアントシステムの受信処理を示す図である。一斉ファイル操作を説明する図である。ディレクトリ設定を説明する図である。ディレクトリ選択処理を説明する図である。一斉ファイル開くの開くファイル選択処理を説明する図である。一斉ファイル開くのファイル開く処理を説明する図である。一斉ファイル開くのコマンド実行処理を説明する図である。一斉ファイル開くの受信処理を説明する図である。一斉別名保存の別名保存処理を説明する図である。別名保存処理の変形例を説明する図である。一斉別名保存の受信処理を説明する図である。別名保存処理を説明する図である。会議状態通知処理を説明する図である。リセット処理を説明する図である。動的間引き同期処理の原理を説明する図である。動的間引き同期処理の受信側の処理を説明するフローチャートである。ＬＯＤ動的間引き同期処理の原理を説明する図である。ＬＯＤ動的間引き同期処理の受信側の処理を説明するフローチャートである。飛ばし同期処理の原理を説明するための図である。飛ばし同期処理の受信側の処理を説明するフローチャートである。ＣＰＵ性能差による処理のずれを説明する図である。長時間処理同期処理の原理を説明する図である。グラフィック性能の高いコンピュータシステムからグラフィック性能の低いコンピュータシステムへ停止位置を送信する場合を示す図である。グラフィック性能の低いコンピュータシステムからグラフィック性能の高いコンピュータシステムへ停止位置を送信する場合を示す図である。図４３及び図４４の停止位置同期処理を説明するフローチャートである。停止位置同期処理を動作パス再生途中に、１０回毎に行う場合を示す図である。図４６の停止位置同期処理を説明するフローチャートである。パス再生同期処理を説明するフローチャートである。待機同期処理を説明する図である。待機同期処理を説明するためのフローチャートである。コンピュータシステムのスペックを示す図である。スペックリストの作成及び更新を説明する図である。本発明になる３次元オブジェクト共有処理方法の第２実施例を適用可能なサーバ・クライアントシステムを示す図である。会議への途中参加を説明する図である。メール着信を説明する図である。ＷＥＢブラウザを説明する図である。データ自己解凍を説明する図である。データの保存先を説明する図である。自動起動処理を説明する図である。５分前起動確認処理を説明する図である。１分前起動確認処理を説明する図である。会議開催（参加）処理を説明する図である。異なるＣＧ描画サイズにより発生する問題を説明する図である。異なるＣＧ描画サイズでも３次元オブジェクトの同じ位置を指す処理を説明する図である。針による３次元ポインティングを説明する図である。円錐による３次元ポインティングを説明する図である。注釈機能による３次元ポインティングを説明する図である。２次元長方形によるポインティングを説明する図である。操作権切替処理を説明する図である。

符号の説明

１，１−１〜１−ｎコンピュータシステム
２ネットワーク
９−１，９−２ＬＡＮ
２０１ＣＰＵ

Claims

ネットワークを介して接続された複数のコンピュータシステムの間で３次元オブジェクトのデータを共有する３次元オブジェクト共有処理方法であって、
各コンピュータシステムにおいて行われる３次元オブジェクトに対する操作に関する操作コマンド及び該操作により発生する３次元オブジェクトの変化を示す選択部品の番号及び部品位置座標を含む変化情報に基づいて、各コンピュータシステムにおいて保持される３次元オブジェクトのデータが一致するよう更新するステップと、
受信側のコンピュータシステムにおいて、動的間引き同期処理、ＬＯＤ動的間引き同期処理、長時間処理同期処理、停止位置同期処理及びパス再生同期処理の少なくとも１つの処理を行うステップとを含む、３次元オブジェクト共有処理方法。
各コンピュータシステムにおいて、前記変化情報の送受信を、内部データの更新処理及び描画処理より前に行うステップを含む、請求項１記載の３次元オブジェクト共有処理方法。
各コンピュータシステムにおいて、送受信するデータサイズを変化させるステップを含む、請求項１又は２記載の３次元オブジェクト共有処理方法。
送信側のコンピュータシステムではマウスカーソルの動きに関するデータを間引き、受信側のコンピュータシステムでは受信したマウスカーソルの動きに関するデータを補間するステップを含む、請求項１〜３のいずれか１項記載の３次元オブジェクト共有処理方法。
コンピュータに、請求項１〜４のいずれか１記載の３次元オブジェクト共有処理方法により３次元オブジェクトのデータを処理させるプログラムが格納された、コンピュータ読み取り可能な記憶媒体。