以下、図面を参照しながら実施形態の説明を述べる。なお、以降、説明済みの要素と同一または類似の要素には同一または類似の符号を付し、重複する説明については基本的に省略する。例えば、複数の同一または類似の要素が存在する場合に、各要素を区別せずに説明するために共通の符号を用いることがあるし、各要素を区別して説明するために当該共通の符号に加えて枝番号を用いることもある。
(実施形態)
実施形態に係る端末は、仮想的体験共有システムを構成することができる。かかるシステムは、図2に例示される。このシステムでは、端末100は互いに、例えばインターネットなどのネットワーク経由で接続されており、データを送受信できる。
なお、図2のシステムでは、端末100同士がサーバを介してデータを送受信するC/S(Client / Server)型のネットワークではなく、端末100同士がデータを直接送受信するP2P(Peer to Peer)型のネットワークが採用されている。しかしながら、P2P型のネットワークに代えて、またはP2P型のネットワークに追加して、C/S型のネットワークを採用したとしても、本実施形態に係る端末100およびサーバを用いて仮想的体験共有システムを構築することは可能である。
ここで、P2P型のネットワークは、C/S型のネットワークに比べて種々のメリットがある。具体的には、かかるメリットとして、データ伝送に伴う遅延が低減するのでリアルタイム性の高い仮想的体験の共有に適していること、サーバが存在しないためC/S型のネットワークではサーバに集中していたトラフィックおよび負荷を分散することができること、単一障害点が存在しないこと、などを挙げることができる。
反面、P2P型のネットワークを採用すると、リンク数はユーザ数nに対してn×(n-1)/2個となり、非線形に増加することになる。故に、P2P型のネットワークでは通常はユーザ数が増えると音声データのトラフィック量は爆発的に増大するため、C/S型のネットワークを採用した場合に比べて音声データのトラフィック量の問題がより深刻となり得る。
端末100は、ユーザの頭部に装着可能なHMD10(第1のデバイス)に表示されるVR/AR/MR画像、およびスピーカ(これは、HMD10に内蔵されていてもよいし、HMD10とは別体であってもよい。)によって出力されるVR/AR/MR音声を制御するように構成されたコンピュータであり、当該HMD10とユーザが把持可能なコントローラ20(第2のデバイス)とにそれぞれ接続されている。なお、コントローラ20は、ユーザ毎に、2つ(両手用)用意されてもよいし、1つ(片手用)用意されてもよい。また、コントローラ20は、手以外の部位に装着されてもよい。さらに、図2には示されていないものの、HMD10および/またはコントローラ20の位置を検出するための位置センサシステムに含まれる要素の1つであるベースステーションがさらに端末100に接続されてもよい。
端末100は、HMD10、コントローラ20、および/またはベースステーションと、例えばUSB(Universal Serial Bus)ケーブル、HDMI(登録商標)(High―Definition Multimedia Interface)ケーブル、などの有線通信手段により接続されてもよいし、例えばBluetooth(登録商標)、WirelessHD、WHDI(Wireless Home Digital Interface)、などの無線通信手段により接続されてもよい。
端末100は、後述されるように、マイクロホンによって生成された音声データを他の端末100(宛先端末)へ既定の条件付きで送信する。他の端末100は、この音声データを再生して出力する。これにより、音声データのトラフィック量を抑制しながらも、ユーザ間の音声チャット、またはライブなどの臨場感のあるイベントをVR/AR/MR空間において実現することが可能となる。
また、アバターの姿勢を動的に制御するために、端末100は、後述されるようにHMD10の位置およびコントローラ20の位置に基づく値を持つ制御データを取得し、当該制御データを他の端末100(宛先端末)へ向けて送信してもよい。制御データは、アバターの姿勢を決定づける。
制御データを受信した他の端末100は、受信した制御データに基づいてユーザのアバター画像を生成する。すなわち、ユーザは、HMD10を装着した頭やコントローラ20を把持した手を動かすことで自らの分身であるアバターに自由な姿勢を取らせることができる。
具体的には、他の端末100は、受信した制御データの示すHMD10の位置に応じてアバター画像の頭部の位置を決定し、当該制御データの示すコントローラ20の位置に応じてアバター画像の手の位置を決定する。アバターの姿勢の制御には、例えばIK(Inverse Kinematics)技術を利用することができる。
HMD10は、アバター画像を含むVR/AR/MR画像を表示するための表示装置に加え、種々のセンサ、スピーカ、マイクロホン、などを含み得る。種々のセンサは、動きセンサ、装着センサ、または位置センサシステムに含まれる要素の一部(後述されるマーカーまたはカメラ)を含み得る。HMD10は、端末100から画像データおよび音声データを受け取って、これらを出力したり、各種センサのセンサデータを端末100へ向けて送信したりする。
表示装置は、透過型ディスプレイであってもよいし、非透過型ディスプレイであってもよい。例えば、HMD10を装着したユーザの視界の少なくとも一部を覆うように表示装置のサイズおよび配置が定められる。表示装置は、左目用表示装置と右目用表示装置とで構成されてもよいし、両者が一体化されていてもよい。
動きセンサは、例えば、加速度センサ、ジャイロスコープ、磁気センサ、などであり得る。動きセンサによって検出されたセンサデータは、ユーザの頭部の姿勢(例えば傾き)の推定に利用することができる。具体的には、このセンサデータに基づいて、ユーザの頭部の3次元的な回転角であるYaw角、Roll角、およびPitch角が推定され、これに応じてユーザの視界を決定する仮想カメラの視軸および/またはアバターの頭部の姿勢が制御され得る。
装着センサは、ユーザがHMD10を装着/取り外したことを示すセンサデータ(イベントデータ)を発生する。装着センサの仕組みは任意であるが、例えば、HMD10に設けられたバネの弾性力の変化、HMD10の装着時にユーザの鼻などの身体の一部に接触するパッド間を流れる電流の変化、などに応じてイベントデータを発生することが可能である。
スピーカは、端末100から音声データを受け取り、これに基づいて音声を出力する。スピーカは、典型的にはヘッドホン型であるが、これ以外のスピーカシステムとして構成されてもよい。マイクロホンは、音声(主にユーザの発話であるが、周囲の環境音を含み得る)を収集する。マイクロホンは、収集した音声に基づいて音声データを生成し、端末100へ送る。
コントローラ20は、ユーザ入力を受け付けるボタンに加え、例えば、HMD10と同様の動きセンサ、位置センサシステムに含まれる要素の一部、などを含み得る。さらに、コントローラ20は、ユーザがコントローラ20を把持/手放したことを示すセンサデータ(イベントデータ)を発生する把持センサを含んでもよい。把持センサの仕組みは任意であるが、例えば、ユーザの把持力によりコントローラ20に加わる圧力の変化、コントローラ20の表面に設けられたセンサ電極と人体との間の静電容量の変化、などに応じてイベントデータを発生することが可能である。コントローラ20は、ユーザ入力データ、各種センサのセンサデータ、などを端末100へ向けて送信する。
位置センサシステムは、例えばカメラ(ポジション・トラッキング・カメラ)とマーカー(トラッカーとも呼ばれる)との組み合わせにより実現される。マーカーは、赤外光または可視光のエミッタ(例えばLED(Light Emitting Diode))であってもよいし、カメラの撮影時にエミッタから発せられる赤外光または可視光を反射するための反射材であってもよい。カメラは、マーカーが赤外光を照射または反射する場合には赤外線センサであり得るし、マーカーが可視光を照射または反射する場合には可視光カメラであり得る。
典型的には、HMD10/コントローラ20に複数のマーカーが取り付けられ、カメラがHMD10/コントローラ20から離れた位置に設置された装置(ベースステーション)に取り付けられる。カメラの撮影画像に基づいて、HMD10/コントローラ20の位置を推定することができる。具体的には、ベースステーションは、撮影画像に基づいて検知点の位置、傾き、発光強度などを検出することができる。ベースステーションは、かかる検知点のデータに基づいてHMD10/コントローラ20の位置(座標)データを計算してもよいし、かかる計算は端末100に委ねられてもよい。
なお、変形例として、カメラをHMD10/コントローラ20側に設け、マーカーをベースステーション側に設けることも可能である。また、HMD10およびコントローラ20に取り付けられるマーカーに加えて、ユーザの関節、抹消部などにさらなるマーカーが取り付けられてもよい。これにより、ユーザの姿勢をより正確に推定することが可能となる。
以下、端末100のハードウェア構成について説明する。端末100は、HMD10の制御装置となり得る種々の電子デバイス、例えば、PC(Personal Computer)、モバイル端末(例えば、タブレット、ファブレット、スマートフォン、ラップトップ、フィーチャーフォン、ウェアラブルデバイス、ポータブルゲーム機、など)、据え置き型ゲーム機、などであり得るが、これらに限られない。
なお、端末100は、HMD10または他のデバイス(コントローラ20、ベースステーション、など)と必ずしも別体でなくてもよい。例えば、端末100がHMD10またはベースステーションに内蔵されていてもよいし、端末100をコントローラ20として扱うこともあり得る。
端末100は、例えば、入出力制御、通信制御(特に、音声データの送信制御)、画像/音声処理、既定の条件判定、などを行うプロセッサを含む。ここで、プロセッサは、典型的にはCPU(Central Processing Unit)および/またはGPU(Graphics Processing Unit)であるが、マイコン、FPGA(Field Programmable Gate Array)、DSP(Digital Signal Processor)、またはその他の汎用または専用のプロセッサなどであってもよい。
また、端末100は、かかる処理を実現するためにプロセッサによって実行されるプログラムおよび当該プロセッサによって使用されるデータ、例えば、アバター、背景、などのVR/AR/MR体験を演出するための各種オブジェクトの基となる画像データを一時的に格納するメモリを含んでいる。メモリは、かかるプログラム/データが展開されるワークエリアを有するRAM(Random Access Memory)を含み得る。
なお、端末100は、全てのデータをオンメモリの状態で扱ってもよいし、一部のデータが補助記憶装置に退避されていてもよい。補助記憶装置は、例えば、端末100に内蔵または外付けされたHDD(Hard Disc Drive)、SSD(Solid State Drive)、フラッシュメモリなどであってもよいし、端末100からアクセス可能なデータベースサーバであってもよい。
端末100は、さらに、ネットワークに接続するための通信I/F(インタフェース)を利用可能である。通信I/Fは、端末100に内蔵されてもよいし、端末100に外付けされてもよい。通信I/Fは、他の端末100、および/または、外部装置、例えば、HMD10、コントローラ20、ベースステーション、などと通信をするためのモジュールであって、送受信のための信号処理回路、アンテナ、LAN(Local Area Network)端子などを含み得る。通信I/Fは、例えば移動通信などの広域通信用のモジュール、無線/有線LAN用のモジュール、Bluetooth用のモジュール、などであり得る。
端末100は、さらに、外部装置、例えば、HMD10、コントローラ20、ベースステーション、などにケーブル接続するための入出力I/Fを利用可能である。入出力I/Fは、USB端子、DVI(Digital Visual Interface)端子、HDMI端子、またはその他のデータ転送用ケーブルのための端子、などである。
端末100は、さらに、各要素、例えば、プロセッサ、メモリ、補助記憶装置、通信I/F、入出力I/Fなどの間でデータを転送するためのバスを含み得る。
図1には、端末100の機能構成が例示される。端末100は、入力部101と、受信部102と、送信部103と、出力部104と、データ取得部111と、距離算出部112と、条件判定部113と、送信制御部114と、画像生成部115と、音声生成部116とを含む。
入力部101は、前述の入出力I/Fにより実現され得る。入力部101は、外部装置、例えば、HMD10、コントローラ20、ベースステーション、マイクロホン(HMD10に内蔵されていてもよいし、別体であってもよい)、などから種々のデータを受け付ける。入力部101は、受け付けたデータをデータ取得部111へ送る。
具体的には、入力部101は、アバター(端末100のユーザに関連付けられるアバターであり、以降は第1のアバターと称する)仮想空間における位置を示す位置データ、マイクロホンによって生成された第1のアバターの音声データ、第1のアバターの姿勢を制御するための制御データ(これは、位置データと統合されてもよいし、別個のデータであってもよい)、などを受け付け得る。
ここで、位置データは、例えば、HMD10および/またはコントローラ20の位置を示すデータであってもよいし、これらに基づいて生成されたデータであってもよい。制御データについても同様である。なお、外部装置と端末100との関係次第で、これらのデータの一部または全部が、入力部101ではなく受信部102によって受信されることもあり得る。
受信部102は、前述の通信I/Fにより実現され得る。受信部102は、ネットワーク経由で、他の端末100から、アバター(他の端末100のユーザに関連付けられるアバターであり、以降は他アバターと称する)の仮想空間における位置を示す位置データ、他アバターの制御データおよび/または音声データを受信し得る。受信部102は、受信したデータをデータ取得部111へ送る。
送信部103は、前述の通信I/Fにより実現され得る。送信部103は、送信制御部114によって制御され、第1のアバターの音声データ、位置データおよび/または制御データを宛先端末へ向けて送信する。
出力部104は、前述の入出力I/Fにより実現され得る。出力部104は、外部装置、例えば、HMD10、スピーカへ出力データ、具体的には、出力部104は、VR/AR/MR画像データをHMD10へ出力したり、VR/AR/MR音声データをスピーカへ出力したりする。さらに、出力部104は、HMD10および/またはコントローラ20へ、触覚フィードバック用のバイブレータ(図示されない)を振動させるための振動データを出力してもよい。
データ取得部111は、前述のプロセッサにより実現され得る。データ取得部111は、入力部101および受信部102から種々のデータを取得する。データ取得部111は、取得したデータを、距離算出部112、条件判定部113、画像生成部115および/または音声生成部116へ送る。
具体的には、データ取得部111は、第1のアバターの音声データ、位置データ、および制御データ、などに加えて、他アバターの音声データ、位置データ、および制御データ、などを取得し得る。
例えば、データ取得部111は、第1のアバターの位置データを距離算出部112および条件判定部113へ送り、第1のアバターの音声データおよび制御データを条件判定部113へ送り、他アバターの位置データを距離算出部112へ送り、他アバターの制御データを画像生成部115へ送り、他アバターの音声データを音声生成部116へ送り得る。
なお、外部装置、例えば、HMD10、コントローラ20および/またはベースステーションがHMD10/コントローラ20の位置を推定して第1のアバターの位置データ/制御データを生成する場合には、データ取得部111は入力部101または受信部102から位置データ/制御データを直接取得することができる。他方、端末100(の図示されない位置/姿勢推定部)が位置センサシステムの出力データ(例えば、検知点の位置、傾き、発光強度などを示すデータ)に基づいてHMD10/コントローラ20の位置を推定して第1のアバターの位置データ/制御データを生成する必要がある場合には、データ取得部111はこの位置/姿勢推定部へ位置センサシステムの出力データを送り、位置データ/制御データの生成を依頼してもよい。
距離算出部112は、前述のプロセッサにより実現され得る。距離算出部112は、仮想空間における2地点間の距離を算出する。具体的には、距離算出部112は、仮想空間における基準地点から第1のアバターまたは他アバターの居る地点までの距離を算出し得る。基準地点は、第1のアバターまたは他アバターの居る地点に定められてもよいし、いずれのアバターも居ない地点に定められてもよい。距離算出部112は、距離データを条件判定部113へ送る。なお、後述される既定の条件が、仮想空間における2地点間の距離と無関係のものである場合には、距離算出部112は不要となり得る。
条件判定部113は、前述のプロセッサにより実現され得る。条件判定部113は、データ取得部111から第1のアバターの音声データと、第1のアバターの制御データおよび/または位置データとを受け取り、さらに、距離算出部112から距離データを受け取り得る。条件判定部113は、第1のアバターの仮想空間における位置に関する既定の条件が満足するか否かを、第1のアバターの位置データおよび/または距離データに基づいて判定する。条件判定部113は、判定結果を示すデータとともに、第1のアバターの音声データ、位置データおよび/または制御データを送信制御部114へ送る。既定の条件は、ユーザの仮想的体験の毀損を防止しながら、同時に、共有対象となる音声データを間引くことを目的に定められ得る。
具体的には、既定の条件は、(1)第1のアバターの仮想空間における位置(以降、第1の位置と称する)が既定のゾーン内にあること、(2)仮想空間に存在する第1のアバターを含む複数のアバター(仮想空間に存在する全アバターであってもよいし、そうでなくてもよい)の仮想空間における位置を仮想空間における既定の地点から近い順にソートした場合に、第1の位置が既定の順位以上となること、(3)宛先端末としての他の端末100に関連付けられる他アバターの仮想空間における位置と第1の位置との間の距離が閾値未満で在ること、または(4)仮想空間に存在する第1のアバターを除く複数のアバター(仮想空間に存在する第1のアバターを除く全アバターであってもよいし、そうでなくてもよい)の仮想空間における位置と第1の位置との間の距離を昇順にソートした場合に、宛先端末としての他の端末100に関連付けられる他アバターの仮想空間における位置と第1の位置との間の距離が既定の順位以上となること、を含み得る。ただし、既定の条件は、これら(1)~(4)に限定されない。
既定の条件(1)について、図3を用いて説明する。既定のゾーンは、仮想空間における既定の地点からの距離に基づいて定められてよい。ただし、既定のゾーンは、これに限らず例えばゾーン内外の境界の座標を指定するなどして任意に定義されてよい。図3および図4乃至図6は、仮想空間を見下ろした俯瞰図であり、丸数字のマークはアバターの(頭部の)位置を表しており、便宜的にその数字をアバターの符号としても用いることとする。また、図3において、既定のゾーンは、×印で表される既定の地点から半径○○メートル以内、と定められている。図3の例では、アバター1の位置は既定のゾーン内になく、アバター2の位置は既定のゾーン内にある。故に、アバター1に関連付けられるユーザの端末100において、条件判定部113は既定の条件が満足しないと判定する。他方、アバター2に関連付けられるユーザの端末100において、条件判定部113は既定の条件が満足すると判定する。なお、既定の条件(1)において、宛先端末の区別はなく、判定結果は全ての宛先端末との関係で適用される。すなわち、アバター1に関連付けられるユーザの端末100はいずれの他の端末100にも音声データを送信せず、アバター2に関連付けられるユーザの端末100は全ての他の端末100へ音声データを送信する。
図3の例は、仮想空間において開催されるライブなどのイベントのように、各ユーザが特定のアバターの挙動に注目する場面に適している。図3の例によれば、既定のゾーンは仮想的なステージとみなすことができる。仮想ステージに登壇していないアバターの音声データは他の端末100へ送信されないため、仮想ステージに登壇しているアバターの音声が他のアバターの音声に埋もれにくくなる。すなわち、各ユーザは目的のアバターのトークや歌声に集中することができ、同時にシステム全体での音声データのトラフィック量を抑制することができる。また、仮想ステージを視覚的にも表現するために、VR/MR/AR画像データにおいて、既定のゾーンに仮想ステージを表すオブジェクトが配置されてもよい。さらに、既定のゾーン外の場所に仮想観客席を表すオブジェクトが配置されてもよい。なお、既定のゾーンは仮想ステージと一致させる必要はなく、例えば仮想観客席の最前列を含むようにしてもよい。これにより、仮想ステージに加えて仮想観客席に居るアバターの一部によるリアクションの音声データも共有されるので、臨場感を演出することが可能となる。
或いは、見方を変えれば、既定の地点は仮想マイクロホンの設置ポイントとみなすこともできる。仮想マイクロホンから遠くに居るアバターの音声データは他の端末100へ送信されないため、仮想マイクロホンに近くに居るアバターの音声が他のアバターの音声に埋もれにくくなる。すなわち、各ユーザは目的のアバターのトークや歌声に集中することができ、同時にシステム全体での音声データのトラフィック量を抑制することができる。仮想マイクロホンを視覚的にも表現するために、VR/MR/AR画像データにおいて、既定のゾーンの基準位置となる既定の地点に仮想マイクロホンを表すオブジェクトが配置されてもよい。
既定の条件(2)について、図4を用いて説明する。図4において、×印は既定の地点を表しており、当該地点とアバター1との距離はd10、当該地点とアバター2との距離はd20、当該地点とアバター3との距離はd30で表される。d20<d10<d30であり、既定の順位が2位であったとする。かかる既定の条件の下では、アバター1およびアバター2に関連付けられるユーザの端末100において、条件判定部113は既定の条件が満足すると判定する。他方、アバター3に関連付けられるユーザの端末100において、条件判定部113は既定の条件が満足しないと判定する。なお、既定の条件(2)においても、宛先端末の区別はなく、判定結果は全ての宛先端末との関係で適用される。すなわち、アバター3に関連付けられるユーザの端末100はいずれの他の端末100にも音声データを送信せず、アバター1およびアバター2に関連付けられるユーザの端末100は全ての他の端末100へ音声データを送信する。
図4の例でも、図3の例と同様に既定の地点は仮想マイクロホンの設置ポイントとみなすことができる。ただし、図4の例では、音声データの共有されるアバターの数は限られる。故に、仮想空間に存在するアバターの数の規模の増大に伴って音声データの共有されるアバターの数が増加し、ひいては音声データのトラフィック量が増大する、という事態を防ぐことができる。例えば、仮想空間に存在するアバターの数が5人であろうと500人であろうと、音声データの共有されるアバターの数は2名に制限することができる。なお、既定の条件(2)は既定の条件(1)と組み合わせられてもよい。例えば、仮想空間に存在する第1のアバターを含む複数のアバターは、既定のゾーン内に居る者に限られてもよい。
なお、既定の条件(2)について判定をするためには、第1のアバターの位置データに加えて複数のアバターの位置データを取得する必要がある。故に、位置データを伝送し合うことによるトラフィック量の増加は避けられない。しかしながら、位置データのサイズは一般的に音声データに比べて小さいし、位置データは常時送信する必要がない(例えば、変化が検知されたときに限って送信されてもよい)。故に、端末100同士が位置データを送信し合うことによるトラフィック量の増分は限定的である。
既定の条件(3)について、図5を用いて説明する。図5において、アバター1とアバター2の距離はd21、アバター1とアバター3との距離はd31で表される。d21<閾値<d31であったとする。かかる既定の条件の下では、アバター1に関連付けられるユーザの端末100において、条件判定部113は、アバター2に関連付けられるユーザの端末100との関係では既定の条件が満足すると判定し、アバター3に関連付けられるユーザの端末100との関係では既定の条件が満足しないと判定する。このように、既定の条件(3)および(4)では、条件判定部113は、宛先端末毎に、既定の条件が満足するか否かを判定する。換言すれば、端末100は、ある端末100へは音声データを送信するが、別の端末100へは音声データを送信しない可能性がある。
図5の例は、仮想空間においてアバター同士の会話(音声チャット)を楽しむ場面に適している。すなわち、端末100は、第1のアバターから遠くに居る他のアバターの音声データを受信しないため、第1のアバターに近くに居るアバターの音声が遠くに居るアバターの音声に埋もれにくくなる。すなわち、各ユーザは近くに居るアバターの話し声に集中することができ、同時にシステム全体での音声データのトラフィック量を抑制することができる。音声データの共有が可能なアバターを視覚的にも表現するために、VR/MR/AR画像データにおいて、音声データの共有ができる位置に居るか否かにより他のアバターの視覚的表現を異ならせてもよい。例えば、音声データの共有ができる位置に居ないアバターは通常よりも暗く描かれてもよいし、音声データの共有ができる位置に居るアバターには音声チャットが可能であることを示すアイコンが付加されてもよい。
既定の条件(4)について、図6を用いて説明する。図6において、アバター1とアバター2の距離はd21、アバター1とアバター3との距離はd31、アバター1とアバター4との距離はd41で表される。d21<d31<d41であり、既定の順位が2位であったとする。かかる既定の条件の下では、アバター1に関連付けられるユーザの端末100において、条件判定部113は、アバター2およびアバター4に関連付けられるユーザの端末100との関係では既定の条件が満足すると判定し、アバター3に関連付けられるユーザの端末100との関係では既定の条件が満足しないと判定する。
図6の例も、図5の例と同様に仮想空間においてアバター同士の会話(音声チャット)を楽しむ場面に適している。ただし、図6の例では、音声データの共有されるアバターの数は限られる。故に、仮想空間に存在するアバターの数の規模の増大に音声データの共有されるアバターの数が増加し、ひいては音声データのトラフィック量が増大する、という事態を防ぐことができる。例えば、仮想空間に存在するアバターの数が5人であろうと500人であろうと、音声データの共有されるアバターの数は2名に制限することができる。なお、既定の条件(4)は既定の条件(3)と組み合わせられてもよい。例えば、あるアバターと第1のアバターとの間の距離が既定の順位以上であっても、閾値を超える場合には当該アバターに関連付けられるユーザの端末100との関係で既定の条件が満足しないと判定されてよい。
ところで、条件判定部113による判定を免れるためのオブジェクト、例えば仮想ヘッドセット、仮想ピンマイク、などが定義されてもよい。これらのオブジェクトは、VR/MR/AR画像データ上で視覚的に表現され、ユーザは例えばコントローラ20を操作してアバターにこのオブジェクトを装着させることができる。なお、かかるオブジェクトの視覚的表現は、ヘッドセットまたはピンマイクに似せてもよいし、似せなくてもよい。また、かかるオブジェクトはどのアバターも装着可能としてもよいし、課金に応じるなどの何らかの既定の条件を満足したアバターに限って装着できるようにしてもよい。いずれにせよ、アバターがこのオブジェクトを装着している間は、当該アバターの音声データは当該アバターの位置に関わらず共有され得る。
具体的には、条件判定部113は、まず第1のアバターが仮想空間における既定のオブジェクト(これは、上記仮想ヘッドセットまたは仮想ピンマイクに相当する)を装着しているか否かを判定する。ここで、第1のアバターによる既定のオブジェクトの装着/取り外しイベントは、例えばコントローラ20からのユーザ入力データに基づいて検知され得る。条件判定部113は、第1のアバターが既定のオブジェクトを装着していると判定した場合には既定の条件が満足するか否かの判定を省略する。
そして、後述される送信制御部114は、条件判定部113によって第1のアバターが既定のオブジェクトを装着していると判定された場合には、全ての宛先端末との関係で既定の条件が満足すると判定された場合と同様に動作する。すなわち、送信制御部114は、第1のアバターの音声データを全ての宛先端末へ向けて送信することを決定する。
例えば、仮想空間において開催されるイベントの出演者のアバターがかかるオブジェクトを装着しておけば、当該アバターが仮想空間を広範に動き回ったとしても、各ユーザは当該アバターのトークや歌声を途切れることなく聞くことができる。また、前述の既定の条件(3)または(4)と組み合わせれば、例えば目的のアバターの音声が途切れることなく聞こえ、しかも付近のアバターのユーザと音声のやり取りが可能な、臨場感のある仮想的体験をユーザに提供することができる。
同様に、条件判定部113による判定を免れることのできるアバターが定義されてもよい。すなわち、このアバターの音声データは、当該アバターの位置に関わらず共有されてよい。例えば、仮想空間のホストとなるユーザのアバターの音声データが、当該アバターの位置に関わらず共有されてよい。
送信制御部114は、前述のプロセッサにより実現され得る。送信制御部114は、条件判定部113から第1のアバターの音声データと、第1のアバターの制御データおよび/または位置データとを、判定結果を示すデータとともに受け取る。送信制御部114は、判定結果に応じて、第1のアバターの少なくとも音声データを宛先端末へ向けて送信するか否かを決定する。送信制御部114は、宛先端末を示すデータ(例えば、アドレスデータ)と、当該宛先端末へ送るデータ(例えば、音声データ、位置データおよび/または制御データ)とを送信部103へ送る。
具体的には、送信制御部114は、宛先端末との関係で既定の条件が満足すると判定された場合には、第1のアバターの音声データを当該宛先端末へ向けて送信することを決定する。ここで、前述の種々のメリットを目当てに、送信制御部114は、ピア・ツー・ピア型のネットワーク経由で音声データを宛先端末へ向けて送信することを決定してもよい。他方、送信制御部114は、宛先端末との関係で既定の条件が満足しないと判定された場合には、第1のアバターの音声データを当該宛先端末へ向けて送信しないことを決定する。
なお、制御データおよび位置データのサイズは、一般的に音声データに比べて小さい。さらに、制御データおよび位置データのどちらも宛先端末へ向けて送信しなかったとすると、当該宛先端末に接続されたHMD10に表示される第1のアバターは静止したままとなり、当該宛先端末のユーザの仮想的体験を損ねかねない。そこで、制御データおよび/または位置データは判定結果に関わらず全ての宛先端末へ向けて送信されてよい。
すなわち、送信制御部114は、宛先端末との関係で既定の条件が満足すると判定された場合には、第1のアバターの音声データと、第1のアバターの制御データおよび/または位置データとを当該宛先端末へ向けて送信することを決定する。他方、送信制御部114は、宛先端末との関係で既定の条件が満足しないと判定された場合には、第1のアバターの音声データを当該宛先端末へ向けて送信せず第1のアバターの制御データおよび/または位置データを当該宛先端末へ向けて送信することを決定する。
画像生成部115は、前述のプロセッサにより実現され得る。画像生成部115は、例えば端末100のメモリまたは補助記憶装置に保存されているオブジェクト(アバターを含む)の画像データと、データ取得部111からの他アバターの制御データとに基づいて、VR/AR/MR画像データの生成(更新)を行う。VR/AR/MR画像データの生成には、制御データに対応する他アバターの姿勢の制御が含まれ得る。画像生成部115は、生成した画像データを出力部104経由でHMD10へ送る。
画像生成部115は、前述のように、制御データの示すHMD10/コントローラ20の位置に応じて他アバターの頭部/手の位置を決定し、例えばIK(Inverse Kinematics)技術を利用してアバターの姿勢を制御してもよい。
音声生成部116は、前述のプロセッサにより実現され得る。音声生成部116は、例えばデータ取得部111からの他アバターの音声データに基づいて、VR/AR/MR音声データの生成を行う。例えば、音声生成部116は、複数の他アバターの音声データを合成することで、音声データを生成してもよい。音声生成部116は、生成した音声データを出力部104経由でスピーカへ送る。
なお、音声生成部116は、データ取得部111から他アバターの位置データをさらに取得してもよい。そして、音声生成部116は、音像定位技術を利用して、他アバターの位置から音声が生じているとユーザに知覚されるように、当該他アバターの音声データを加工してもよい。これにより、視覚的に知覚されるアバターの位置と聴覚的に知覚されるアバターの位置とをマッチさせて、臨場感を演出することが可能となる。
以下、図7を用いて、端末100の動作を説明する。図7の動作は、定期的に行われてもよいし、第1のアバターまたは他アバターの位置データに変化があったことが検知されたタイミングで行われてもよい。
まず、データ取得部111は、第1のアバターの音声データおよび位置データを取得する(ステップS201)。次のステップS202において判定される既定の条件次第で、データ取得部111は、他アバターの位置データをさらに取得し得る。さらに、ステップS202へ進む前に、距離算出部112がステップS201において取得された位置データに基づいて、仮想空間における2地点間の距離を算出してもよい。
次に、条件判定部113は第1のアバターの位置に関する既定の条件が満足するか否かを判定する(ステップS202)。少なくとも1つの宛先端末との関係で既定の条件が満足すると判定された場合には、処理はステップS203へ進む。他方、全ての宛先端末との関係で既定の条件が満足しないと判定された場合には、図7の動作は終了する。なお、ステップS202の判定結果に関わらず、送信制御部114は、第1のアバターの制御データおよび/または位置データを各宛先端末へ向けて送信すると決定してもよい。
ステップS203において、送信制御部114は、既定の条件が満足すると判定された宛先端末へ向けて、ステップS201において取得された音声データを送信することを決定し、図7の動作は終了する。
以上説明したように、実施形態に係る端末は、当該端末のユーザに関連付けられる第1のアバターの仮想空間における位置が既定の条件を満足するか否かを判定し、当該既定の条件が満足しないと判定された場合に第1のアバターの音声データを宛先端末へ向けて送信しない。故に、この端末によれば、既定の条件が満足しないと判定された場合には、当該端末から宛先端末への音声データのトラフィックが生じない。他方、この端末は、限られたアバターの音声データに限って受信することになるので、例えば、仮想マイクロホンまたは第1のアバターの近くに居るアバターの音声が他のアバターの音声に埋もれにくくなる。従って、この端末によれば、ユーザは目的のアバターのトークや音声、または近くに居るアバターの話し声に集中することができ、同時にシステム全体での音声データのトラフィック量を抑制することができる。
(変形例1)
前述のように、図2のシステムではP2P型のネットワークが採用されているが、これに追加してC/S型のネットワークを採用したとしても、仮想的体験共有システムを構築することは可能である。この変形例1において、各端末100は、P2P型のネットワークおよびC/S型のネットワークのどちらかを選択して、データを宛先端末へ向けて送信する。
この変形例1によれば、図8に例示されるように、図2の仮想的体験共有システムにサーバ300を追加することが可能である。サーバ300は、送信元となる端末100からデータを受信し、これを宛先となる端末100へ送信する。
この変形例1において、端末100における送信制御部114は、宛先端末との関係で既定の条件が満足すると判定された場合には、P2P型のネットワーク経由で第1のアバターの音声データを当該宛先端末へ向けて送信することを決定する。他方、送信制御部114は、宛先端末との関係で既定の条件が満足しないと判定された場合には、C/S型のネットワーク経由で第1のアバターの音声データを当該宛先端末へ向けて送信することを決定してもよい。なお、第1のアバターの制御データおよび/または位置データは、第1のアバターの音声データと同じネットワーク経由で送信されてよい。
このように送信制御部114がP2P型のネットワークまたはC/S型のネットワークを選択して第1のアバターの音声データを送信すれば、当該音声データに関してP2P型のネットワークの種々のメリット(例えば遅延低減)を享受することはできないものの、全てのユーザが全てのアバターの音声データを共有することが可能となる。すなわち、ユーザは、より多くのアバターの音声を同時に聞くことができるので、賑やかさ、盛り上がり、一体感などを感じやすくなる。
以下、図9を用いて、変形例1に係る端末100の動作を説明する。図9の動作は、定期的に行われてもよいし、第1のアバターまたは他アバターの位置データに変化があったことが検知されたタイミングで行われてもよい。
まず、データ取得部111は、第1のアバターの音声データおよび位置データを取得する(ステップS401)。次のステップS402において判定される既定の条件次第で、データ取得部111は、他アバターの位置データをさらに取得し得る。さらに、ステップS402へ進む前に、距離算出部112がステップS401において取得された位置データに基づいて、仮想空間における2地点間の距離を算出してもよい。
次に、条件判定部113は第1のアバターの位置に関する既定の条件が満足するか否かを判定する(ステップS402)。既定の条件が満足すると判定された場合には、処理はステップS403へ進む。他方、既定の条件が満足しないと判定された場合には、処理はステップS404へ進む。なお、前述の既定の条件(3)または(4)のように、宛先端末間で判定結果が異なり得る場合には、宛先端末毎にステップS402と、ステップS403またはステップS404とを繰り返せばよい。
ステップS403において、送信制御部114は、既定の条件が満足すると判定された宛先端末へ向けて、P2P型のネットワーク経由で、ステップS401において取得された音声データを送信することを決定し、図9の動作は終了する。
ステップS404において、送信制御部114は、既定の条件が満足しないと判定された宛先端末へ向けて、C/S型のネットワーク経由で、ステップS401において取得された音声データを送信することを決定し、図9の動作は終了する。
(変形例2)
前述のように、図2のシステムではP2P型のネットワークが採用されているが、これに代えてC/S型のネットワークを採用したとしても、仮想的体験共有システムを構築することは可能である。さらに、この変形例2に係るサーバ500は、送信元端末から宛先端末へのデータの中継に留まらず、第1の実施形態において説明した端末100の機能の一部をも担う。
具体的には、この変形例2において、端末は、前述の既定の条件判定および送信制御を行う必要はない。すなわち、端末は、アバターの音声データ、制御データおよび位置データをサーバ500へ送信する。なお、後述するように、アバターの位置データ/制御データは、端末から受信したデータに基づいてサーバ500において生成されてもよい。
以下、サーバ500のハードウェア構成について説明する。サーバ500は、コンピュータであって、例えば、通信制御(特に、音声データの送信制御)、既定の条件判定、などを行うプロセッサを含む。
また、サーバ500は、かかる処理を実現するためにプロセッサによって実行されるプログラムおよび当該プロセッサによって使用されるデータを一時的に格納するメモリを含んでいる。
なお、サーバ500は、全てのデータをオンメモリの状態で扱ってもよいし、一部のデータが補助記憶装置に退避されていてもよい。補助記憶装置は、例えば、サーバ500に内蔵または外付けされたHDD、SSD、フラッシュメモリなどであってもよいし、サーバ500からアクセス可能なデータベースサーバであってもよい。
サーバ500は、さらに、ネットワークに接続するための通信I/Fを利用可能である。通信I/Fは、サーバ500に内蔵されてもよいし、サーバ500に外付けされてもよい。通信I/Fは、端末などと通信をするためのモジュールであって、送受信のための信号処理回路、アンテナ、LAN端子などを含み得る。
サーバ500は、さらに、各要素、例えば、プロセッサ、メモリ、補助記憶装置、通信I/F、などの間でデータを転送するためのバスを含み得る。
図10には、サーバ500の機能構成が例示される。サーバ500は、受信部501と、送信部502と、データ取得部511と、距離算出部512と、条件判定部513と、送信制御部514とを含む。ただし、距離算出部512、条件判定部513および送信制御部514は、図1における同名の要素と同一または類似であってよく、それぞれ前述のプロセッサにより実現され得る。
受信部501は、前述の通信I/Fにより実現され得る。受信部501は、ネットワーク経由で、送信元端末から、当該送信元端末のユーザに関連付けられるアバター(これは、第1の実施形態において説明した第1のアバターに相当する)の音声データ、位置データおよび制御データを受信し得る。受信部501は、受信したデータをデータ取得部511へ送る。
送信部502は、前述の通信I/Fにより実現され得る。送信部502は、送信制御部514によって制御され、アバターの音声データ、位置データおよび/または制御データを宛先端末へ向けて送信する。
データ取得部511は、前述のプロセッサにより実現され得る。データ取得部511は、受信部501から種々のデータを取得する。データ取得部511は、取得したデータを、距離算出部512および条件判定部513へ送る。
具体的には、データ取得部511は、アバターの音声データ、位置データおよび制御データを取得し、位置データを距離算出部512および条件判定部513へ送り、音声データおよび制御データを条件判定部513へ送り得る。
なお、端末が位置データ/制御データを送信する場合には、データ取得部511は受信部501から位置データ/制御データを直接取得することができる。他方、サーバ500(の図示されない位置/姿勢推定部)が位置センサシステムの出力データに基づいてHMD10/コントローラ20の位置を推定して位置データ/制御データを生成する必要がある場合には、データ取得部511はこの位置/姿勢推定部へ位置センサシステムの出力データを送り、位置データ/制御データの生成を依頼してもよい。
以上説明したように、変形例2に係るサーバは、第1の実施形態に係る端末と同様に、音声データの送信元端末のユーザに関連付けられる第1のアバターの仮想空間における位置が既定の条件を満足するか否かを判定し、当該既定の条件が満足しないと判定された場合に第1のアバターの音声データを宛先端末へ向けて送信しない。故に、このサーバによれば、第1の実施形態に係る端末と同様に、ユーザは目的のアバターのトークや音声、または近くに居るアバターの話し声に集中することができ、同時にシステム全体での音声データのトラフィック量を抑制することができる。なお、本変形例に係るサーバと第1の実施形態および変形例1に係る端末とを、「データ送信装置」と総称することも可能である。
上述の実施形態は、本発明の概念の理解を助けるための具体例を示しているに過ぎず、本発明の範囲を限定することを意図されていない。実施形態は、本発明の要旨を逸脱しない範囲で、様々な構成要素の付加、削除または転換をすることができる。
上述の実施形態では、いくつかの機能部を説明したが、これらは各機能部の実装の一例に過ぎない。例えば、1つの装置に実装されると説明された複数の機能部が複数の別々の装置に亘って実装されることもあり得るし、逆に複数の別々の装置に亘って実装されると説明された機能部が1つの装置に実装されることもあり得る。
上記各実施形態において説明された種々の機能部は、回路を用いることで実現されてもよい。回路は、特定の機能を実現する専用回路であってもよいし、プロセッサのような汎用回路であってもよい。
上記各実施形態の処理の少なくとも一部は、例えば汎用のコンピュータに搭載されたプロセッサを基本ハードウェアとして用いることでも実現可能である。上記処理を実現するプログラムは、コンピュータで読み取り可能な記録媒体に格納して提供されてもよい。プログラムは、インストール可能な形式のファイルまたは実行可能な形式のファイルとして記録媒体に記憶される。記録媒体としては、磁気ディスク、光ディスク(CD-ROM、CD-R、DVD等)、光磁気ディスク(MO等)、半導体メモリなどである。記録媒体は、プログラムを記憶でき、かつ、コンピュータが読み取り可能であれば、何れであってもよい。また、上記処理を実現するプログラムを、インターネットなどのネットワークに接続されたコンピュータ(サーバ)上に格納し、ネットワーク経由でコンピュータ(クライアント)にダウンロードさせてもよい。