以下、図面を参照しながら実施形態の説明を述べる。なお、以降、説明済みの要素と同一または類似の要素には同一または類似の符号を付し、重複する説明については基本的に省略する。例えば、複数の同一または類似の要素が存在する場合に、各要素を区別せずに説明するために共通の符号を用いることがあるし、各要素を区別して説明するために当該共通の符号に加えて枝番号を用いることもある。
(実施形態)
実施形態に係るデータ差し替え装置は、仮想的体験共有システムを構成する端末に組み込むことができる。かかるシステムは、図2に例示される。このシステムでは、端末200は互いに、例えばインターネットなどのネットワーク経由で接続されており、データを送受信できる。
なお、図2のシステムでは、データ伝送に伴う遅延を低減してリアルタイム性の高い仮想的体験を共有することなどを目的に、端末200同士がサーバを介してデータを送受信するC/S(Client / Server)型のネットワークではなく、端末200同士がデータを直接送受信するP2P(Peer to Peer)型のネットワークが採用されている。しかしながら、C/S型のネットワークを採用したとしても、本実施形態に係るデータ差し替え装置を組み込んだ端末200を用いて仮想的体験共有システムを構築することは可能である。
端末200は、ユーザの頭部に装着可能なHMD(第1のデバイス)10に表示されるVR/AR/MR画像を制御するように構成されたコンピュータであり、当該HMD10とユーザが把持可能なコントローラ(第2のデバイス)20とにそれぞれ接続されている。なお、コントローラ20は、ユーザ毎に、2つ(両手用)用意されてもよいし、1つ(片手用)用意されてもよい。また、コントローラ20は、手以外の部位に装着されてもよい。さらに、図2には示されていないものの、HMD10および/またはコントローラ20の位置を検出するための位置センサシステムに含まれる要素の1つであるベースステーションがさらに端末200に接続されてもよい。
端末200は、HMD10、コントローラ20、および/またはベースステーションと、例えばUSB(Universal Serial Bus)ケーブル、HDMI(登録商標)(High―Definition Multimedia Interface)ケーブル、などの有線通信手段により接続されてもよいし、例えばBlutooth、WirelessHD、WHDI(Wireless Home Digital Interface)、などの無線通信手段により接続されてもよい。
端末200は、後述されるようにHMD10の位置およびコントローラ20の位置に基づく値を持つ第1の制御データを取得し、当該第1の制御データを条件付きで第2の制御データに差し替える。後述するように、第2の制御データは、HMD10およびコントローラ20の少なくとも一方の位置に基づかない値を持つ。そして、端末200は、差し替えを行った場合には第2の制御データを他の端末200へ送信し、そうでない場合には第1の制御データを他の端末200へ送信する。
第1の制御データまたは第2の制御データを受信した他の端末200は、受信した制御データに基づいてユーザのアバター画像を生成する。すなわち、ユーザは、HMD10を装着した頭やコントローラ20を把持した手を動かすことで自らの分身であるアバターに自由な姿勢を取らせることができる。
さらに、端末200は、後述されるマイクロホンによって生成された音声データを他の端末200へ送信してもよい。他の端末200は、この音声データを再生して出力する。これにより、ユーザ間の音声チャット、またはライブなどの臨場感のあるイベントをVR/AR/MR空間において実現することが可能となる。
具体的には、他の端末200は、受信した制御データの示すHMD10の位置に応じてアバター画像の頭部の位置を決定し、当該制御データの示すコントローラ20の位置に応じてアバター画像の手の位置を決定する。例えばユーザがHMD10を頭部に装着し、かつ(右手用)コントローラ21および(左手用)コントローラ22(これらはいずれも前述のコントローラ20と同様であり得る)を両手に把持した状態で、図4に例示される姿勢を取ったとする。この場合に、ユーザのアバターは、図5に例示される姿勢を取ることになる。アバターの姿勢の制御には、例えばIK(Inverse Kinematics)技術を利用することができる。
HMD10は、アバター画像を含むVR/AR/MR画像を表示するための表示装置に加え、種々のセンサ、スピーカ、マイクロホン、などを含み得る。種々のセンサは、動きセンサ、装着センサ、または位置センサシステムに含まれる要素の一部(後述されるマーカーまたはカメラ)を含み得る。HMD10は、端末200から画像データおよび音声データを受け取って、これらを出力したり、各種センサのセンサデータを端末200へ送信したりする。
表示装置は、透過型ディスプレイであってもよいし、非透過型ディスプレイであってもよい。例えば、HMD10を装着したユーザの視界の少なくとも一部を覆うように表示装置のサイズおよび配置が定められる。表示装置は、左目用表示装置と右目用表示装置とで構成されてもよいし、両者が一体化されていてもよい。
動きセンサは、例えば、加速度センサ、ジャイロスコープ、磁気センサ、などであり得る。動きセンサによって検出されたセンサデータは、ユーザの頭部の姿勢(例えば傾き)の推定に利用することができる。具体的には、このセンサデータに基づいて、ユーザの頭部の3次元的な回転角であるYaw角、Roll角、およびPitch角が推定され、これに応じてユーザの視界を決定する仮想カメラの視軸およびアバターの頭部の姿勢が制御され得る。
装着センサは、ユーザがHMD10を装着/取り外したことを示すセンサデータ(イベントデータ)を発生する。装着センサの仕組みは任意であるが、例えば、HMD10に設けられたバネの弾性力の変化、HMD10の装着時にユーザの鼻などの身体の一部に接触するパッド間を流れる電流の変化、などに応じてイベントデータを発生することが可能である。
スピーカは、端末200から音声データを受け取り、これに基づいて音声を出力する。スピーカは、典型的にはヘッドホン型であるが、これ以外のスピーカシステムとして構成されてもよい。また、スピーカは、HMD10とは別体であってもよい。マイクロホンは、音声(主にユーザの発話)を収集する。マイクロホンは、収集した音声に基づいて音声データを生成し、端末200へ送る。
コントローラ20は、ユーザ入力を受け付けるボタンに加え、例えば、HMD10と同様の動きセンサ、位置センサシステムに含まれる要素の一部、などを含み得る。さらに、コントローラ20は、ユーザがコントローラ20を把持/手放したことを示すセンサデータ(イベントデータ)を発生する把持センサを含んでもよい。把持センサの仕組みは任意であるが、例えば、ユーザの把持力によりコントローラ20に加わる圧力の変化、コントローラ20の表面に設けられたセンサ電極と人体との間の静電容量の変化、などに応じてイベントデータを発生することが可能である。コントローラ20は、ユーザ入力データ、各種センサのセンサデータ、などを端末200へ送信したりする。
位置センサシステムは、例えばカメラ(ポジション・トラッキング・カメラ)とマーカー(トラッカーとも呼ばれる)との組み合わせにより実現される。マーカーは、赤外光または可視光のエミッタ(例えばLED(Light Emitting Diode))であってもよいし、カメラの撮影時にエミッタから発せられる赤外光または可視光を反射するための反射材であってもよい。カメラは、マーカーが赤外光を照射または反射する場合には赤外線センサであり得るし、マーカーが可視光を照射または反射する場合には可視光カメラであり得る。
典型的には、HMD10/コントローラ20に複数のマーカーが取り付けられ、カメラがHMD10/コントローラ20から離れた位置に設置された装置(ベースステーション)に取り付けられる。カメラの撮影画像に基づいて、HMD10/コントローラ20の位置を推定することができる。具体的には、ベースステーションは、撮影画像に基づいて検知点の位置、傾き、発光強度などを検出することができる。ベースステーションは、かかる検知点のデータに基づいてHMD10/コントローラ20の位置(座標)データを計算してもよいし、かかる計算は端末200に委ねられてもよい。なお、変形例として、カメラをHMD10/コントローラ20側に設け、マーカーをベースステーション側に設けることも可能である。また、HMD10およびコントローラ20に取り付けられるマーカーに加えて、ユーザの関節、抹消部などにさらなるマーカーが取り付けられてもよい。これにより、ユーザの姿勢をより正確に推定することが可能となる。
以下、端末200のハードウェア構成について説明する。端末200は、HMD10の制御装置となり得る種々の電子デバイス、例えば、PC(Personal Computer)、モバイル端末(例えば、タブレット、ファブレット、スマートフォン、ラップトップ、フィーチャーフォン、ウェアラブルデバイス、ポータブルゲーム機、など)、据え置き型ゲーム機、などであり得るが、これらに限られない。
なお、端末200は、HMD10または他のデバイス(コントローラ20、ベースステーション、など)と必ずしも別体でなくてもよい。例えば、端末200がHMD10またはベースステーションに内蔵されていてもよいし、端末200をコントローラ20として扱うこともあり得る。
端末200は、実施形態に係るデータ差し替え装置としての処理、入出力制御、通信制御、画像/音声処理、などを行うプロセッサを含む。ここで、プロセッサは、典型的にはCPU(Central Processing Unit)および/またはGPU(Graphics Processing Unit)であるが、マイコン、FPGA(Field Programmable Gate Array)、DSP(Digital Signal Processor)、またはその他の汎用または専用のプロセッサなどであってもよい。
また、端末200は、かかる処理を実現するためにプロセッサによって実行されるプログラムおよび当該プロセッサによって使用されるデータ、例えば、アバター、背景、などのVR/AR/MR体験を演出するための各種オブジェクトの基となる画像データを一時的に格納するメモリを含んでいる。メモリは、かかるプログラム/データが展開されるワークエリアを有するRAM(Random Access Memory)を含み得る。
なお、端末200は、全てのデータをオンメモリの状態で扱ってもよいし、一部のデータが補助記憶装置に退避されていてもよい。補助記憶装置は、例えば、端末200に内蔵または外付けされたHDD(Hard Disc Drive)、SSD(Solid State Drive)、フラッシュメモリなどであってもよいし、端末200からアクセス可能なデータベースサーバであってもよい。
端末200は、さらに、ネットワークに接続するための通信I/F(インタフェース)を利用可能である。通信I/Fは、端末200に内蔵されてもよいし、端末200に外付けされてもよい。通信I/Fは、他の端末200、および/または、外部装置、例えば、HMD10、コントローラ20、ベースステーション、などと通信をするためのモジュールであって、送受信のための信号処理回路、アンテナ、LAN(Local Area Network)端子などを含み得る。通信I/Fは、例えば移動通信などの広域通信用のモジュール、無線/有線LAN用のモジュール、Bluetooth(登録商標)用のモジュール、などであり得る。
端末200は、さらに、外部装置、例えば、HMD10、コントローラ20、ベースステーション、などにケーブル接続するための入出力I/Fを利用可能である。入出力I/Fは、USB端子、DVI(Digital Visual Interface)端子、HDMI端子、またはその他のデータ転送用ケーブルのための端子、などである。
端末200は、さらに、各要素、例えば、プロセッサ、メモリ、補助記憶装置、通信I/F、入出力I/Fなどの間でデータを転送するためのバスを含み得る。
続いて、実施形態に係るデータ差し替え装置を説明する。図1には、実施形態に係るデータ差し替え装置100の機能構成が例示される。データ差し替え装置100は、データ取得部101と、状態判定部102と、データ差し替え部103とを含む。
データ取得部101は、例えば前述の通信I/F、入出力I/F、またはプロセッサにより実現され得る。データ取得部101は、第1の制御データを取得し、これを状態判定部102へ送る。ここで、第1の制御データは、HMD10の位置とコントローラ20の位置とに基づく値を持つ。前述のように、HMD10/コントローラ20の位置は、位置センサシステムを用いて推定することができる。
外部装置、例えば、HMD10、コントローラ20および/またはベースステーションがHMD10/コントローラ20の位置を推定して第1の制御データを生成する場合には、データ取得部101はこの外部装置から第1の制御データを取得すればよい。他方、端末200(の図示されない位置推定部)が位置センサシステムの出力データ(例えば、検知点の位置、傾き、発光強度などを示すデータ)に基づいてHMD10/コントローラ20の位置を推定して第1の制御データを生成する場合には、データ取得部101は端末200のメモリまたは補助記憶装置から第1の制御データを取得すればよい。
上記説明では、データ差し替え装置100が第1の制御データを他の端末200へ送信する前に条件付きで差し替えを行うことが前提とされている。しかしながら、後述の変形例1において説明するように、端末200は自らの第1の制御データを差し替えずに他の端末200へ送信し、当該他の端末200に組み込まれたデータ差し替え装置100が受信した第1の制御データに対して条件付きで差し替えを行うようにすることも可能である。後者の構成を前提とすると、データ取得部101は、ネットワーク経由で受信された第1の制御データを取得することになる。
なお、HMD10/コントローラ20が前述の装着センサ/把持センサを含む場合には、データ取得部101はこの装着センサ/把持センサからのイベントデータをさらに取得し、状態判定部102へ送ってもよい。
状態判定部102は、例えば前述のプロセッサにより実現され得る。状態判定部102は、データ取得部101から第1の制御データ(およびイベントデータ)を受け取る。状態判定部102は、第1の制御データに関して既定の差し替え開始条件が満足するか否かを判定する。そして、状態判定部102は、判定結果を示すデータとともに第1の制御データをデータ差し替え部103へ送る。
ここで、状態判定部102は、第1の制御データに基づいて差し替え開始条件が満足するか否かを判定してもよいし、イベントデータに基づいて差し替え開始条件が満足するか否かを判定してもよい。差し替え開始条件は、例えば第1の制御データに忠実にアバターを制御すると当該アバターが不自然な姿勢を取ると予想される場合に満足するように定義され得る。
具体的には、状態判定部102は、差し替え開始条件の一例として、HMD10がユーザの頭部に装着されているか否かを判定してもよい。HMD10がユーザの頭から取り外されると、HMD10の位置は最早ユーザの頭部の位置に連動せず、極端に低い位置もしくは高い位置、またはユーザの手(より正確にはコントローラ20)の位置から極端に離れた位置に動かされる可能性がある。かかる場合に、HMD10の位置に合わせてアバターの頭部の位置を決定すると、アバターの姿勢が不自然なものとなる可能性がある。
状態判定部102は、例えば、HMD10の装着/取り外しイベント発生時に装着センサからの出力されるイベントデータに基づいて、HMD10がユーザの頭部に装着されているか否かを判定し得る。
また、ユーザは、頭部からHMD10を取り外す時にHMD10を頭よりも大幅に高い位置に持ち上げる可能性がある。そこで、状態判定部102は、差し替え開始条件の一例として、第1の制御データがHMD10の高さが既定の第1の高さ以上であることを示す値を持つか否かを判定してもよい。
第1の高さは、アバターの姿勢が不自然であると定義されないために要求される頭部の高さの上限値を意味し得る。第1の高さは、ユーザ単位で定められてもよいし、仮想的体験共有システム単位で定められてもよい。一例として、第1の高さは、ユーザ個人または平均的なユーザの頭部の高さにオフセットを加えた高さ、などであり得る。
また、ユーザは、頭部からHMD10を取り外した後、例えば床などの低地に置くことがあり得る。かかる場合に、HMD10の位置に合わせてアバターの頭部の位置を決定すると、アバターは例えば低地に頭部を付けて倒れ込んだような姿勢を取る可能性がある。
そこで、状態判定部102は、差し替え開始条件の一例として、第1の制御データがHMD10の高さが既定の第2の高さ未満であることを示す値を持つか否かを判定してもよい。図6の例では、第2の高さはH0に定められており、かつHMD10の高さはH0よりも低いので、状態判定部102は差し替え開始条件が満足すると判定する。
第2の高さは、アバターの姿勢が不自然であると定義されないために要求される頭部の高さの下限値を意味し得る。第2の高さは、ユーザ単位で定められてもよいし、仮想的体験共有システム単位で定められてもよい。一例として、第2の高さは、ユーザ個人または平均的なユーザの腰の高さ、膝の高さ、前屈時の頭部の高さ、などであり得る。
また、差し替え開始条件は、第1の制御データがHMD10の高さが上記第1の高さ以上または上記第2の高さ未満であることを示す値を持つこと、であってもよい。図8の例では、第1の高さおよび第2の高さはそれぞれH1およびH2に定められており、かつHMD10の高さはH1以上であるので、状態判定部102は差し替え開始条件が満足すると判定する。これにより、HMD10の高さが、前述の下限値から上限値までの範囲に入らない場合に、データの差し替えを行って、アバターの姿勢が崩壊するのを防止することができる。
また、ユーザは、頭部からHMD10を取り外す前に、手を自由にするためにコントローラ20を手放している可能性がある。そこで、状態判定部102は、差し替え開始条件の一例として、前述のHMD10の高さに関する条件のいずれかに加えて、第1の制御データがコントローラ20が静止していることを示す値を持つか否かを判定してもよい。コントローラ20が静止しているか否かは、例えば、第1の制御データにおけるコントローラ20の位置の履歴、コントローラ20の動きセンサまたは把持センサの出力データ、などに基づいて判定され得る。
さらに、ユーザがHMD10を頭部に装着し、かつ、コントローラ20を把持している限りは、両者の距離が極端に離れることはない。換言すれば、HMD10とコントローラ20との間の距離が極端に大きい場合には、HMD10およびコントローラ20の少なくとも一方はユーザに身に着けられていない可能性がある。故に、かかる場合に、HMD10/コントローラ20の位置データに忠実にアバターを制御すると、アバターが不自然な姿勢を取る可能性がある。そこで、状態判定部102は、差し替え開始条件の一例として、第1の制御データがHMD10とコントローラ20との間の距離が既定の距離以上であることを示す値を持つか否かを判定してもよい。
既定の距離は、アバターの姿勢が不自然であると定義されないために要求される頭と手との間の距離の上限値を意味し得る。既定の距離は、ユーザ単位で定められてもよいし、仮想的体験共有システム単位で定められてもよい。一例として、既定の距離は、ユーザ個人または平均的なユーザの頭部から手までの距離に基づいて定められ得る。具体的には、既定の距離は、頭部から手までの距離が最も大きくなる姿勢、例えば気をつけの姿勢を取った時のユーザの頭部から手までの距離にオフセットを加えた距離、などであり得る。
なお、状態判定部102は、一旦差し替え開始条件が満足すると判定した後は、既定の差し替え終了条件が満足するか否かを判定する。そして、状態判定部102は、一旦差し替え終了条件が満足すると判定した後は、再び差し替え開始条件が満足するか否かを判定する。差し替え終了条件は、例えば第1の制御データに忠実にアバターを制御したとしても当該アバターが不自然な姿勢を取らないと予想される場合に満足するように定義され得る。このように差し替え終了条件を定義することで、アバターを自然な姿勢(例えば直立)からダミーの姿勢(例えば屈む)に移行させた後に、不自然な姿勢を挟むことなく再び同一または異なる自然な姿勢(例えば立ち上がって手を振る)に復帰させることが可能となる。
差し替え終了条件は、典型的には差し替え開始条件の否定、すなわち差し替え開始条件が満足しないこと、に相当し得る。例えば、差し替え開始条件が「HMD10がユーザの頭部に装着されていること」である場合には、差し替え終了条件は「HMD10がユーザの頭部に装着されていないこと」に定められ得る。
しかしながら、差し替え終了条件は、差し替え開始条件の否定に相当しないこともあり得る。具体的には、差し替え開始条件が「第1の制御データが、HMD10の高さが第1の高さ以上であることを示し、かつ、コントローラ20が静止していることを示す値を持つこと」である場合に、差し替え終了条件は「第1の制御データが、HMD10の高さが第1の高さ未満(かつ第2の高さ以上)であることを示し、かつ、コントローラ20が静止していないことを示す値を持つこと」であってよい。
データ差し替え部103は、前述のプロセッサにより実現され得る。データ差し替え部103は、差し替え開始条件が満足すると判定された場合には第1の制御データを第2の制御データに差し替え、当該第2の制御データをデータ差し替え装置100の外部へ出力する。他方、データ差し替え部103は、差し替え開始条件が満足すると判定されなかった場合には第1の制御データをそのままデータ差し替え装置100の外部へ出力する。なお、データ差し替え部103は、データの差し替えを一旦開始すると、状態判定部102によって差し替え終了条件が満足すると判定されるまでデータの差し替えを継続する。ここで、第2の制御データは、アバターが不自然な姿勢を取らないようにするためのダミーデータであり、その具体例について以下に説明する。
例えば、差し替え開始条件が、HMD10がユーザの頭部に装着されていること、またはHMD10の高さに関するものである場合には、第2の制御データは、HMD10の高さに基づかない値を持ち得る。具体的には、第2の制御データは、HMD10の高さが、前述の第1の高さ未満の高さ、前述の第2の高さ以上の高さ、または第1の高さ未満かつ第2の高さ以上の高さであることを示す値を持ち得る。これにより、例えば、図6の例のようにHMD10の高さが第2の高さH0未満の場合にも、アバターの頭が不自然に下がることはなく、例えば図7のように屈んでいるような姿勢をアバターに取らせることができる。屈む姿勢以外にも、アバターの姿勢を制御するアルゴリズムおよび第2の制御データの示すHMD10の高さ次第で、アバターを座らせる、跪かせる、直立させる、など様々な姿勢を取らせることがあり得る。
また、差し替え開始条件が、HMD10とコントローラ20との間の距離に関するものである場合には、第2の制御データはHMD10およびコントローラ20の少なくとも一方の位置に基づかない値を持ち得る。具体的には、第2の制御データは、HMD10とコントローラ20との間の距離が既定の距離未満であることを示す値を持ち得る。
ユーザがHMD10を装着していない場合にはHMD10は静止していると予想できるし、ユーザがコントローラ20を把持していない場合にはコントローラ20は静止していると予想できる。そこで、第2の制御データは、HMD10およびコントローラ20のうち静止している一方または両方の位置に基づかない値を持っていてもよい。換言すれば、第2の制御データにおいて、第1の制御データにおけるHMD10およびコントローラ20のうち静止していないデバイス(非静止デバイス)の位置は維持され、そうでないデバイスの位置が非静止デバイスの位置から上記既定の距離未満にある位置に書き換えられ得る。HMD10/コントローラ20が静止しているか否かは、例えば第1の制御データにおけるHMD10/コントローラ20の位置の履歴、またはHMD10/コントローラ20の動きセンサまたは装着センサ/把持センサの出力データ、などに基づいて判定可能である。
続いて、このデータ差し替え装置100を組み込んだ端末200を説明する。図3には、データ差し替え装置100を組み込んだ端末200の機能構成が例示される。端末200は、データ差し替え装置100と、送信部201と、受信部211と、画像生成部212とを含む。
送信部201は、前述の通信I/Fにより実現され得る。送信部201は、データ差し替え装置100の出力データを受け取り、これをネットワーク経由で、通信相手となる他の端末200へ送信する。ここで、データ差し替え装置100の出力データは、前述のように、データの差し替えが行われた場合には第2の制御データであり、そうでない場合には第1の制御データである。
なお、送信部201は、第1または第2の制御データに加えて、マイクロホンによって生成された音声データを受け取り、これをネットワーク経由で通信相手となる他の端末200へ送信してもよい。
受信部211は、前述の通信I/Fにより実現され得る。受信部211は、通信相手となる他の端末200からネットワーク経由で、当該他の端末200のユーザのアバターを制御するための制御データを受信する。受信する制御データは、第1の制御データである可能性もあるし第2の制御データである可能性もあるが、いずれであろうとも後段の処理に影響はない。受信部211は、制御データを画像生成部212へ送る。
なお、受信部211は、制御データに加えて音声データを受信し得る。受信部211は、音声データを図示されない音声処理部へ送ってもよい。この音声処理部は、音声データを再生し、前述のスピーカに音声を出力させる。
画像生成部212は、前述のプロセッサにより実現され得る。画像生成部212は、例えば端末200のメモリまたは補助記憶装置に保存されているオブジェクトの画像データと、受信部211からの制御データとに基づいて、当該制御データに対応するユーザのアバター画像の制御を含む、VR/AR/MR画像の生成(更新)を行う。ここでの制御データは、データの差し替えが行われた場合には第2の制御データに相当し、そうでない場合には第1の制御データに相当する。画像生成部212は、生成した画像データをHMD10へ送る。
画像生成部212は、前述のように、制御データの示すHMD10/コントローラ20の位置に応じてアバター画像の頭部/手の位置を決定し、例えばIK技術を利用してアバターの姿勢を制御してもよい。
以下、図9を用いて、端末200の動作を説明する。図9の動作は、第1の制御データが生成される毎に行われる。
まず、データ差し替え装置100内のデータ取得部101は、第1の制御データを取得する(ステップS301)。それから、データ差し替え装置100内の状態判定部102は、既定の条件が満足するか否かを判定する(ステップS302)。既定の条件が満足する場合には処理はステップS303へ進み、そうでなければ処理はステップS303をスキップしてステップS304へ進む。
なお、ステップS302において既定の条件とは、差し替え開始条件が1度も満足していない場合には差し替え開始条件を意味し、差し替え開始条件が満足してから差し替え終了条件が満足するまでの間は差し替え終了条件の否定に相当する条件を意味し、差し変え終了条件が満足してから再び差し替え開始条件が満足するまでの間は差し替え開始条件を意味し得る。
ステップS303において、データ差し替え装置100内のデータ差し替え部103は、第1の制御データをHMD10およびコントローラ20の少なくとも一方の位置に基づかない値を持つ第2の制御データに差し替える。
次に、送信部201は制御データを送信し(ステップS304)、図9の動作は終了する。なお、ステップS304の前にステップS303が実行された場合には、送信部201は第2の制御データを送信する。他方、ステップS304の前にステップS303がスキップされた場合には、送信部201は第1の制御データを送信する。
以上説明したように、実施形態に係るデータ差し替え装置は、既定の差し替え開始条件が満足される場合に、HMDおよびコントローラの位置に基づく値を持つ第1の制御データをHMDおよびコントローラの少なくとも一方の位置に基づかない値を持つ第2の制御データへ差し替える。故に、このデータ差し替え装置によれば、例えば第1の制御データに忠実にアバターを制御すると当該アバターが不自然な姿勢を取るおそれがある場合に、当該第1の制御データの代わりにダミーの第2の制御データを用いて当該アバターを制御することができる。すなわち、HMDおよびコントローラの実際の位置とは無関係に、アバターの姿勢を不自然とならないように維持されるので、少なくともアバター画像の不自然さによるユーザの仮想的体験の劣化を防止することができる。
(変形例1)
前述の実施形態では、第1の制御データの送信元である端末において第1の制御データに対するデータの差し替えが条件付きで行われる。しかしながら、第1の制御データの送信元ではなく宛先である端末において、当該第1の制御データに対するデータの差し替えが行われてもよい。かかる変形例の端末400が図10に例示される。
端末400は、データ取得部402と、送信部201と、受信部211と、データ差し替え装置100と、画像生成部212とを含む。ここで、送信部201、受信部211、データ差し替え装置100および画像生成部212は、図3における同名の要素と同一または類似であるので、以降の説明では両者の相違点およびデータ取得部402を中心にて説明する。
データ取得部402は、例えば前述の通信I/F、入出力I/F、またはプロセッサにより実現され得る。データ取得部402は、第1の制御データを取得し、これを送信部201へ送る。前述のように、HMD10/コントローラ20の位置は、位置センサシステムを用いて推定することができる。
外部装置、例えば、HMD10、コントローラ20またはベースステーションがHMD10/コントローラ20の位置を推定して第1の制御データを生成する場合には、データ取得部402はこの外部装置から第1の制御データを取得すればよい。他方、端末200(の図示されない位置推定部)が位置センサシステムの出力データ(例えば、検知点の位置、傾き、発光強度などを示すデータ)に基づいてHMD10/コントローラ20の位置を推定して第1の制御データを生成する場合には、データ取得部402は端末200のメモリまたは補助記憶装置から第1の制御データを取得すればよい。
なお、HMD10/コントローラ20が前述の装着センサ/把持センサを含む場合には、データ取得部402はこの装着センサ/把持センサからのイベントデータをさらに取得し、送信部201へ送ってもよい。また、この場合に、送信部201は、宛先である端末400における既定の条件の判定のために、第1の制御データに加えてイベントデータを当該端末400へ送信し得る。さらに、受信部211も、他の端末400から送信された第1の制御データに加えて、イベントデータを受信し、データ差し替え装置100へ送り得る。
以上説明したように、この変形例では、第1の制御データの送信元ではなく宛先である端末においてデータ差し替え処理を分散的に行う。故に、この変形例によれば、送信元における負荷を削減することができる。
(変形例2)
前述の実施形態では、各端末はP2P型のネットワーク経由でデータを互いに伝送し合う。他方、各端末は、C/S型のネットワーク経由でデータを互いに伝送し合うことも可能である。そして、この場合に、データ差し替え装置100がサーバに組み込まれてもよい。そして、サーバは、第1の制御データを端末間で単純に中継するのではなく、送信元である端末から受信した第1の制御データに対して条件付きでデータの差し替えを行ってから第1または第2の制御データを宛先である端末へ送信してもよい。
この変形例のようにC/S型のネットワークを採用することで、P2P型のネットワークを採用した場合に比べて制御データの伝送遅延は大きくなる可能性があるが、サーバにおいてデータ差し替え処理を集中的に行うので、各端末における負荷を削減することができる。
上述の実施形態は、本発明の概念の理解を助けるための具体例を示しているに過ぎず、本発明の範囲を限定することを意図されていない。実施形態は、本発明の要旨を逸脱しない範囲で、様々な構成要素の付加、削除または転換をすることができる。
上述の実施形態では、いくつかの機能部を説明したが、これらは各機能部の実装の一例に過ぎない。例えば、1つの装置に実装されると説明された複数の機能部が複数の別々の装置に亘って実装されることもあり得るし、逆に複数の別々の装置に亘って実装されると説明された機能部が1つの装置に実装されることもあり得る。
上記各実施形態において説明された種々の機能部は、回路を用いることで実現されてもよい。回路は、特定の機能を実現する専用回路であってもよいし、プロセッサのような汎用回路であってもよい。
上記各実施形態の処理の少なくとも一部は、例えば汎用のコンピュータに搭載されたプロセッサを基本ハードウェアとして用いることでも実現可能である。上記処理を実現するプログラムは、コンピュータで読み取り可能な記録媒体に格納して提供されてもよい。プログラムは、インストール可能な形式のファイルまたは実行可能な形式のファイルとして記録媒体に記憶される。記録媒体としては、磁気ディスク、光ディスク(CD-ROM、CD-R、DVD等)、光磁気ディスク(MO等)、半導体メモリなどである。記録媒体は、プログラムを記憶でき、かつ、コンピュータが読み取り可能であれば、何れであってもよい。また、上記処理を実現するプログラムを、インターネットなどのネットワークに接続されたコンピュータ(サーバ)上に格納し、ネットワーク経由でコンピュータ(クライアント)にダウンロードさせてもよい。