以下、実施形態について、図面を参照しながら具体的に説明する。
(第1の実施形態)
[コンテンツ配信システムの全体構成]
図1は、第1の実施形態に係るコンテンツ配信システムの概略構成を示すブロック図である。また、図2は、図1のコンテンツ配信システムにおける配信者端末14、サーバ3およびユーザ端末22の内部構成を模式的に示すブロック図である。
このコンテンツ配信システムは、演者の動作に対応して動作する演者アバターをVR(Virtual Reality)空間に配置し、この演者アバターが配置されたVR空間をコンテンツとしてユーザに配信する。ユーザは自身のHMD(Head Mount Display)21あるいはユーザ端末22にコンテンツを出力させる。
以下では、コンテンツ配信システムが、VR空間としての仮想ライブ会場に演者アバターを配置し、コンテンツとして仮想ライブをユーザに配信する例を述べる。ユーザは仮想ライブを出力させることによって、仮想ライブに参加する。ユーザは、特定の会場に赴いて仮想ライブに参加してもよいし、自宅などで仮想ライブに参加してもよい。
また、本実施形態では、仮想ライブ会場には、演者アバターのみならず、仮想ライブに参加する各ユーザに対応するユーザアバターをも配置される。そして、仮想ライブに参加するユーザの反応が、演者、演者アバター、ユーザ、および/またはユーザアバターにフィードバックされ得る。以下、詳細に説明する。
図1に示すように、コンテンツ配信システムは、仮想ライブの配信を行う演者用の動作検出装置11、再生装置12、出力提示装置13および配信者端末14と、仮想ライブに参加する各ユーザが用いるHMD21、ユーザ端末22および出力提示装置23と、サーバ3とを備えている。なお、仮想ライブに参加するユーザの数は任意である。
[演者用の各装置の構成]
演者用の動作検出装置11は、スタジオにいる演者の実際の動作(発声を含む)をリアルタイムに検出し、検出した動作を示す動作情報を配信者端末14に送信する。動作検出装置11はウェアラブルセンサや入力装置から構成される。より具体的には、動作検出装置11は、演者に装着されて演者の視線や向きを検出するHMD、演者が仮想的なオブジェクトを手に持ったり離したりするためのコントローラ、演者の動きを検出するモーションセンサ、演者の一部または全体を撮影するカメラ、演者の声を取得するマイクなどを含み得る。
具体例として、演者が右手を挙げると、動作検出装置11は演者が右手を挙げたことを検出し、そのことを示す動作信号(動作情報)が配信者端末14に送信される。また、演者が声を出すと、動作検出装置11は演者の声を検出し、演者の声を示す動作信号(動作情報)が配信者端末14に送信される。このような動作信号(動作情報)に応じて、仮想ライブ会場で動作する演者アバターが生成される。また、このような動作信号に応じて、個々の端末(例えば個々のユーザ端末22)における再生速度やネットワーク経路の速度に依存せず、各再生端末(例えば個々のユーザ端末22)の環境において適切な速度でアニメーションが再生される。
演者用の再生装置12はディスプレイ121およびスピーカ122を含む。再生装置12のディスプレイ121には、配信者端末14によって生成される仮想ライブ会場の画像(映像)が表示される。スピーカ122からは、配信者端末14によって生成される仮想ライブ会場の音声が出力される。
演者用の出力提示装置13は、サーバ3からの出力提示情報(後述)に基づいて、仮想ライブ会場における演出に対するユーザの反応に応じたフィードバックを演者に与える。出力提示装置13は演者に作用するものであればよく、主として触覚デバイスが考えらえるが、音響デバイス、映像デバイス、電飾(発光デバイス)などであってもよい。
触覚デバイスは、演者に対するフィードバックとして、振動したり、電気刺激を与えたり、吸引力・剪断力・締め圧を与えたりするアクチュエータ搭載デバイスである。また、触覚デバイスは、演者が装着するものであり、例えばペンダント型(例えば、ペンダントの内側に複数の振動アクチュエータを設けたもの、以下同じ)、腕輪型、ブレスレット型、ネックレス型でもよいし、ジャケット型でもよい。
音響デバイスは、演者に対するフィードバックとして、スピーカからストリーミング音声を出力したり、事前に準備した音声効果を出力したりする。なお、出力提示装置13としての音響デバイスが、再生装置12におけるスピーカ122の機能、振動アクチュエータの制御機能、および電飾の制御機能を兼ねていてもよい。
映像デバイスは、平板ディスプレイ、HMD、AR(Artificial Reality)グラス、スマートウォッチなどである。そして、映像デバイスは、演者に対するフィードバックとして、ストリーミング動画、3Dレンダリングのためのアニメーション情報、そのために事前に用意した3D/2D画像素材を表示する。なお、出力提示装置13としての映像デバイスが、演者用のディスプレイ121の機能を兼ねていてもよい。
電飾は、演者に対するフィードバックとして、触覚デバイスと同期して発光したり、演者の動きと連動して発光したりする高輝度LEDやディスプレイなどである。電飾は複数の発光体から構成されてもよい。
なお、出力提示装置13自身が通信機能を有し、サーバ3から直接出力提示情報を受信できてもよいし、不図示の制御装置がサーバ3から出力提示情報を受信して出力提示装置13を制御してもよい。
配信者端末14は、通信部141と、記憶部142と、制御部143とを有する(図2参照)。
通信部141は、アンテナや通信ICなどから構成され、図1に示すようにネットワーク接続された動作検出装置11、再生装置12およびサーバ3との間でデータの送受信を行う。記憶部142は、RAM,ROMなどから構成され、各処理に必要なデータを記憶する。特に、記憶部142は、仮想ライブの配信を行う演者の情報(演者情報1421)と、仮想ライブに参加するユーザの情報(参加ユーザ情報1422)とを記憶する。
図3Aは、配信者端末14の記憶部142に記憶される演者情報1421のデータ構造を模式的に示す図である。図示のように、演者情報1421は、演者を特定する演者IDが、その演者に対応するアバター情報(例えば、アバターのモデルデータおよび音声)に関連付けられたものである。
図3Bは、配信者端末14の記憶部142に記憶される参加ユーザ情報1422のデータ構造を模式的に示す図である。図示のように、参加ユーザ情報1422は、参加するユーザを特定する参加ユーザIDが、仮想ライブ会場においてそのユーザに設定された仮想座席を特定する仮想座席IDと、そのユーザに対応するアバター情報(例えば、アバターのモデルデータおよび音声)とに関連付けられたものである。
なお、仮想ライブ会場における仮想座席とは、仮想ライブ会場において、ユーザに対応するユーザアバターが表示される仮想的な座席である。仮想ライブ会場における1つの仮想座席には2以上のユーザが設定され得る。1つの仮想座席に設定されるユーザ数に上限があってもよい。1つの仮想座席に2以上のユーザが設定される場合については、第2の実施形態において後述する。
図2に戻り、配信者端末14の制御部143は、演者情報取得部1431と、参加ユーザ情報取得部1432と、演者動作取得部1433と、VR空間生成部1434と、VR空間変更情報取得部1435と、VR空間変更部1436と、VR空間情報送信部1437とを有する。これら各部の一部または全部は、ハードウェアで実装されてもよいし、ソフトウェアで実現されてもよい。後者の場合、配信者端末14のプロセッサ(不図示)が記憶部142に記憶されたプログラムを実行することで、各部が実現されてもよい。
演者情報取得部1431は、演者からの操作に応じて、上述した演者IDおよびアバター情報を取得し、演者情報1421として記憶部142に記憶する。また、演者情報取得部1431は現在どの演者がコンテンツ配信を行っているかを把握する。
参加ユーザ情報取得部1432は、上述した参加ユーザID、仮想座席ID、および、アバター情報をサーバ3から取得し、参加ユーザ情報1422として記憶部142に記憶する。
演者動作取得部1433は動作検出装置11から演者の動作を示す動作情報を取得する。
VR空間生成部1434は、記憶部142に記憶された演者情報1421および参加ユーザ情報1422と、演者動作取得部1433が取得した動作情報とに基づいて、画像および音声から構成される仮想ライブ会場を生成する。具体的には、仮想ライブ会場は、現在コンテンツ配信を行っている演者に対応する演者アバターと、仮想ライブに参加するユーザの一部または全部に対応するユーザアバターとを含む。
そして、演者アバターは仮想ライブ会場における仮想舞台上で動作情報に応じて動作する。動作情報と、演者アバターの動作内容との関係は予め記憶部142にデータテーブルとして記憶されていてもよい。また、仮想ライブに参加する各ユーザに対応するユーザアバターが、当該ユーザに設定された仮想座席の位置に配置される。さらに、仮想ライブ会場は演者アバターの声や楽曲などの音声を含み得る。なお、記憶部142は、動作情報と動作内容を対応付けたデータテーブルを記憶する代わりに、機械学習がなされた学習済みモデルを記憶してもよい。この場合、動作情報が学習済みモデルに対する入力情報であり、動作内容が学習済みモデルからの出力情報である。
生成された仮想ライブ会場は、演者用の再生装置12、ユーザ用のHMD21およびユーザ端末22によって出力される。
VR空間変更情報取得部1435は、仮想ライブに参加しているユーザの反応に応じて仮想ライブ会場を変更するためのVR空間変更情報をサーバ3から取得する。仮想ライブ会場の変更とは、ユーザアバターの態様変更、演者アバターの態様変更、仮想ライブ会場に対する演出の実行などである。
VR空間変更部1436はVR空間変更情報に基づいて仮想ライブ会場を変更する。具体例として、VR空間変更部1436は、ユーザの反応に応じたVR空間変更情報に基づき、演者アバターやユーザアバターの表示態様を変更したり、仮想ライブ会場に花火を生じさせるなど所定の演出を実行したりする。
VR空間情報送信部1437は、VR空間生成部1434によって生成された仮想ライブ会場や、VR空間変更部1436によって変更された仮想ライブ会場を出力(画像表示および/または音声出力)するための情報(VR空間情報)をサーバ3に送信する。VR空間情報は、例えば動画像データおよび音声データから構成される。
以上述べた配信者用の動作検出装置11、再生装置12、出力提示装置13および配信者端末14は、コンテンツ作成用のスタジオに設置される。ただし、動作検出装置11として、スマートフォンやタブレット端末のようなモバイル機器を適用し、スタジオとは異なる場所(例えば、自宅)から演者がコンテンツ配信を行ってもよい。
[ユーザ用の各装置の構成]
続いて、図1のユーザ端末22について述べる。ユーザは、ユーザ端末22に仮想ライブ会場を出力させて仮想ライブに参加してもよいし、HMD21を用いてこれに仮想ライブ会場を出力させて仮想ライブに参加させてもよい。まずは、前者について説明する。
ユーザ端末22は、典型的にはスマートフォンやタブレット端末などのモバイル機器であるが、専用端末であってもよい。ユーザ端末22は、通信部221と、記憶部222と、センサ223と、タッチパネル224と、スピーカ225と、制御部226とを有する(図2参照)。
通信部221は、アンテナや通信ICなどから構成され、図1に示すようにネットワーク接続されたサーバ3との間でデータの送受信を行う。
記憶部222は、RAM,ROMなどから構成され、各処理に必要なデータを記憶する。
センサ223はユーザ端末22に内蔵され、あるいは外付けとされ、ユーザの動作を検出する。具体例として、センサ223は、ユーザを撮影するカメラ、ユーザの声(叫び声、声援、コールなど)や拍手を検出するマイクなどを含み得る。また、センサ223は、ユーザの動作を直接的に検出するものでなくてもよく、ユーザ端末22の振動を検出する振動センサ、ユーザ端末22の加速度を検出する加速度センサ、ユーザのヘルスケア情報(心拍や歩数など)を検出するヘルスケアセンサなどを含み得る。
これらのセンサ223で検出されるデータは、ユーザの動作の程度を示している。そして、仮想ライブが行われている間でのユーザの動作は、仮想ライブ会場における演出に対するユーザの反応に対応する。
タッチパネル224は入力インターフェースと出力インターフェースとを兼ねており、ユーザからタップ・スワイプ・長押しなどの操作を受け付けるとともに、制御部226からの制御に応じた画像を表示する。
スピーカ225は制御部226からの制御に応じた音声を出力する。
制御部226は、ライブ参加要求部2261と、反応データ生成部2262と、出力制御部2263とを有する。これら各部の一部または全部は、ハードウェアで実装されてもよいし、ソフトウェアで実現されてもよい。後者の場合、ユーザ端末22のプロセッサ(不図示)が記憶部222に記憶されたプログラムを実行することで、各部が実現されてもよい。
ライブ参加要求部2261は、仮想ライブへの参加を希望するユーザからのタッチパネル224への操作に応じて、仮想ライブへの参加をサーバ3に要求する。さらに、ライブ参加要求部2261は仮想ライブ会場における特定の仮想座席の指定を要求してもよい。
反応データ生成部2262は、センサ223によって検知されたデータに基づき、仮想ライブ会場における演出に対するユーザの反応に関連する反応データをサーバ3に送信する。反応データはセンサ223からのデータそのものであってもよい。あるいは、反応データ生成部2262はセンサ223によって検知されたデータに対してノイズ除去などの加工を行って反応データとしてもよい。
また、反応データの送信頻度は、実質的にリアルタイムでもよいし、一定期間ごとでもよいし、ユーザあるいはサーバ3からの要求をトリガとしてもよいし、反応データに大きな変化があった時点であってもよい。さらに、反応データの送信頻度は、仮想ライブで演奏される楽曲のリズムに応じた頻度でもよいし、主なる演者が実行する踊りなどの演出に応じた頻度であってもよいし、他のユーザの体験を記録したデータに基づいた頻度であってもよい。サーバ3からの要求は、仮想ライブ会場に流れる曲が開始するタイミングであってもよい。曲の開始に合わせてユーザが動作する可能性が高いためである。また、反応データの内容に応じた送信頻度であってもよいし、ユーザに応じた送信頻度(後述するアクティブ度が高いユーザは、高頻度とするなど)であってもよい。
上記の加工や送信頻度には種々考えられる。
例えば、反応データ生成部2262は、センサ223からのデータを意味や頻度といった圧縮済みデータに変換し、時間情報(time)、フロート(float)情報、テキスト情報などWebSocketで送信できる状態を反応データとしてもよい。また、反応データ生成部2262はセンサ223からのデータに基づいて特徴量を算出して反応データとしてもよい。
また、反応データ生成部2262は、センサ223からのデータが音声データの場合には、ノイズ除去処理の後、MFCC(Mel-Frequency Cepstrum Coefficients)によって周波数スペクトルに変換し、さらに動的閾値を用いて頻度および時刻情報に変換して反応データとしてもよい。この時刻情報が示す時刻は、リアルタイムライブが実行される場合には、通常、世界標準時にあたる時刻を使用する。しかし、時差などを考慮したタイムシフトでライブが再生される場合には、開始時刻がずれるように設定し、記録再生することも可能である。なお、上述した「Cepstrum」は「Cepstral」と同義である。
また、反応データ生成部2262は、センサ223からのデータが声援や笑い声などである場合、これらをリアルタイムにサーバ3に送信するのではなく、サーバ3からの要求と、それに対するユーザの許可によって送信するのが望ましい。
また、反応データ生成部2262は、センサ223からのデータが加速度センサからのXYZ各方向の加速度である場合、高周波成分を抽出し、そのマグニチュードを動的閾値を用いて頻度および時刻情報に変換して反応データとしてもよい。この場合、例えば、1/30秒あるいは1/60秒に1度の頻度でサーバ3に送信してもよい。
また、反応データ生成部2262は、センサ223からのデータがカメラからの顔画像および深度画像である場合、52点程度の特徴量(float)を1/75秒ごとに抽出し、有意な点(チャンネル)のみを選択して動的閾値を用いて頻度および時刻情報に変換して反応データとしてもよい。
なお、反応データをサーバ3に送信するか否かをユーザが選択できてもよい。また、特定のユーザのユーザ端末22における反応データ生成部2262が反応データを送信するようにしてもよい。特定のユーザとは、例えばユーザ属性(性別、年齢、ユーザ端末22が存在する地域、ユーザのお気に入り演者、過去の課金の多寡など)がある条件を満たすユーザや、サーバ3によってランダムに選択されたユーザである。
出力制御部2263は、タッチパネル224に所定の画面を表示させたり、スピーカ225から所定の音声を出力させたりする。例えば、出力制御部2263は、サーバ3からのVR空間情報に基づいて、仮想ライブ会場の画像をタッチパネル224に表示させ、仮想ライブ会場の音声をスピーカ25から出力させる。
図1に戻り、ユーザ用の出力提示装置23は、サーバ3からの出力提示情報に基づいて、仮想ライブ会場における演出に対するユーザの反応に応じたフィードバックをユーザに与える。フィードバック元のユーザとフィードバック先のユーザは一致することが想定されるが、他のユーザにフィードバックされてもよい。出力提示装置23はユーザに作用するものであればよく、演者用の出力提示装置13と同様なので詳細な説明は省略するが、触覚デバイス、音響デバイス、映像デバイス、電飾(発光デバイス)などである。
出力提示装置23自身が通信機能を有し、サーバ3から直接出力提示情報を受信できてもよい。あるいは、出力提示装置23とユーザ端末22とを接続する構成とし、ユーザ端末22がサーバ3から出力提示情報を受信し、この出力提示情報に基づいてユーザ端末22が出力提示装置23を制御してもよい。また、ユーザ端末22が出力提示装置23の機能を兼ねていてもよい。
なお、上述したように、仮想ライブに参加するユーザに対して、ユーザ端末22ではなくHMD21が仮想ライブ会場の画像を表示したり音声を出力したりしてもよい。この場合、HMD21が通信機能を有し、サーバ3から直接VR空間情報を受信し、仮想ライブ会場を出力させてもよい。あるいは、HMD21とユーザ端末22とを接続する構成とし、ユーザ端末22がサーバ3からVR空間情報を受信し、このVR空間情報に基づいてユーザ端末22がHMD21に仮想ライブ会場を出力させてもよい。また、HMD21が出力提示装置23の機能(映像デバイスあるいは音響デバイス)を兼ねていてもよい。以下では、主にユーザ端末22に仮想ライブ会場を出力するものとして説明するが、HMD21に仮想ライブ会場を出力する場合も同様に考えることができる。
[サーバ3の構成]
続いて、図1のサーバ3について述べる。サーバ3は、通信部31と、記憶部32と、制御部33とを有する(図2)。
通信部31は、アンテナや通信ICなどから構成され、図1に示すようにネットワーク接続された配信者端末14、HMD21、ユーザ端末22および出力提示装置23とデータの送受信を行う。なお、ネットワークは双方向通信できるものであればプロトコルに制限はないが、例えばWebSocketを用いることができる。
記憶部32は、RAM,ROM,HDDなどから構成され、各処理に必要なデータ(例えば、後述する参加ユーザ情報321や、種々のプログラム)を記憶する。特に、記憶部32は参加ユーザ情報321を記憶する。また、記憶部32には、GCPとして、判定、記録、課金、GeoIP、過去のライブにおけるアチーブメント、現在接続しているネットワークの経路や速度が記憶されていてもよい。
図4は、サーバ3の記憶部32に記憶される参加ユーザ情報321のデータ構造を模式的に示す図である。図示のように、参加ユーザ情報321は、参加ユーザIDが、そのユーザが用いるユーザ端末22を特定するユーザ端末IDと、そのユーザが用いる出力提示装置23を特定する出力提示装置IDとに関連付けられたものである。
図2に戻り、制御部33は、ライブ参加受付部331と、反応データ取得部332と、ユーザ特定部333と、出力提示情報生成部334と、VR空間変更情報生成部335と、VR空間情報配信部336とを有する。これら各部の一部または全部は、ハードウェアで実装されてもよいし、ソフトウェアで実現されてもよい。後者の場合、サーバ3のプロセッサ(不図示)が記憶部32に記憶されたプログラムを実行することで、各部が実現されてもよい。
ライブ参加受付部331はユーザ端末22におけるライブ参加要求部2261からの要求に応じて仮想ライブへの参加を受け付ける。また、ライブ参加受付部331は参加を受け付けた各ユーザの仮想ライブ会場における仮想座席を設定する。ライブ参加受付部331は、各ユーザからの希望に応じて仮想ライブ会場での仮想座席を設定してもよいし、任意に(例えばランダムに)設定してもよい。
仮想ライブへの参加は有料であってもよい。この場合、ライブ参加受付部331は公知の手法によって課金処理を行えばよい。仮想ライブへの参加費用は仮想座席に応じて異なっていてもよい。例えば、仮想ライブ会場における演者アバターとの距離が近い仮想座席ほど高く設定されてもよい。
そして、ライブ参加受付部331はライブ参加要求の受け付けに際して、参加ユーザID、ユーザ端末ID、出力提示装置ID、アバター情報を取得する。参加ユーザID、仮想座席ID、アバター情報は、配信者端末14に送信され、参加ユーザ情報1422として配信者端末14の記憶部132に記憶される。また、参加ユーザID、ユーザ端末IDおよび出力提示装置IDは、参加ユーザ情報321としてサーバ3の記憶部32に記憶される。
反応データ取得部332はユーザ端末22から反応データを取得する。なお、反応データ取得部332は、仮想ライブに参加している全ユーザのユーザ端末22から反応データを取得してもよいし、一部のユーザの端末から反応データを取得してもよい。
ユーザ特定部333は反応データが特定の条件を満たすユーザを特定する。本実施形態におけるユーザ特定部333は、感情が所定条件を満たすユーザ、より具体的には、盛り上がっている(アクティブである)と判断されるユーザを反応データに基づいて特定する。例として、ユーザ特定部333は、反応データに基づき、反応データから把握されるユーザの声や動きの大きさなどからアクティブ度を取得し、アクティブ度が閾値を超えるユーザを特定する。アクティブ度は、反応データと所定の関係式とに基づいて取得されてもよいし、反応データと学習済みモデルとに基づいて取得されてもよい。ユーザが特定された場合、ユーザ特定部333はアクティブなユーザの数を取得してもよい。あるいは、ユーザ特定部333はアクティブ度が高い順に予め定められた数だけのユーザを特定してもよい。また、閾値を複数設け、ユーザ特定部333は、アクティブ度が高いユーザと、アクティブ度が中程度のユーザなど、複数段階に分けてユーザを特定してもよい。さらに、ユーザ特定部333は、特定されたユーザと、そのアクティブ度を関連づけておいてもよい。
出力提示情報生成部334は、ユーザ特定部333によって特定されたユーザの出力提示装置23が当該ユーザに作用するよう、出力提示情報を生成する。そして、出力提示情報生成部334は、記憶部32に記憶された参加ユーザ情報321を参照し、当該ユーザの出力提示装置23に出力提示情報を送信する。このようにして、ユーザの反応に対するユーザへのフィードバックが実現される。特定されたユーザに特別なフィードバックが伝わるので、フィードバックを多様化できる。
また、出力提示情報生成部334は演者用の出力提示装置13が演者に作用するよう出力提示情報を生成し、送信してもよい。演者用の出力提示情報はユーザ端末22からの反応データ(あるいはアクティブ度)に基づくものであってよい。例えば、アクティブ度が高いほど、また、アクティブなユーザの数が多いほど、出力提示装置13によって大きな作用が演者に与えられるような出力提示情報が生成されてもよい。このようにして、ユーザの反応に対する演者へのフィードバックが実現される。
VR空間変更情報生成部335は、反応データ取得部332が取得した反応データや、ユーザ特定部333によって特定されたユーザに基づいて、仮想ライブ会場を変更するためのVR空間変更情報を生成し、配信者端末14に送信する。このVR空間変更情報に基づき、配信者端末14のVR空間変更部1436によって仮想ライブ会場が変更される。ユーザの反応と、生成されるVR空間変更情報との関係は、予め記憶部32に記憶されていてもよい。このようにして、ユーザの反応に対する仮想ライブ会場へのフィードバックが実現される。
VR空間情報配信部336は、配信者端末14からのVR空間情報を、演者用の再生装置12、HMD21およびユーザ端末22に配信する。具体的には、VR空間情報配信部336は、VR空間を出力するための動画像データおよび音声データを圧縮して、演者用の再生装置12などに配信する。
[仮想ライブへの参加要求および仮想座席の設定]
図5は、仮想ライブへの参加要求・受付手順の一例を示すフローチャートである。
仮想ライブへの参加受付可能期間において、仮想ライブへの参加を希望するユーザからの操作に応じて、ユーザ端末22のライブ参加要求部2261は仮想ライブへの参加要求をサーバ3に送信する(ステップS1)。参加受付可能期間は、仮想ライブ開始時刻より前の予め定めた期間であってもよいし、仮想ライブへの途中参加を可能とすべく仮想ライブ終了時刻より前までであってもよい。また、参加要求には、参加ユーザID、ユーザ端末ID、出力提示装置IDおよびアバター情報を含むものとする。
参加要求に応じて、サーバ3のライブ参加受付部331はユーザからの参加を受け付ける(ステップS11)。そして、ライブ参加受付部331はユーザが選択可能な仮想座席をユーザに提示するための情報をユーザ端末22に送信する(ステップS12)。
続いて、ユーザからの操作に応じて、ユーザ端末22のライブ参加要求部2261は仮想座席を選択する(ステップS2)。具体例として、ライブ参加要求部2261は仮想座席を選択するための画面をタッチパネル224に表示させる。この画面から、仮想ライブ会場における演者アバター(仮想舞台)と各仮想座席との位置関係が把握できるのが望ましい。ユーザはタッチパネル224を介した操作によって仮想座席を選択する。そして、選択された仮想座席を特定する情報がライブ参加要求部2261によってサーバ3に送信される。
これにより、サーバ3の参加受付部はユーザの仮想座席を確定する(ステップS13)。そして、ライブ参加受付部331は、参加ユーザID、ユーザ端末IDおよび出力提示装置IDを参加ユーザ情報321として記憶部32に記憶するともに、参加ユーザID、仮想座席IDおよびアバター情報を参加ユーザ情報1422として配信者端末14に送信する(ステップS14)。
[仮想ライブ会場の生成]
図6は、仮想ライブ会場を生成する手順の一例を示すフローチャートである。
仮想ライブの配信開始に先立って、配信者端末14のVR空間生成部1434は仮想ライブの配信を行う演者を特定する演者IDを取得し、記憶部142に記憶された演者情報1421のなかから当該演者IDと関連付けられたアバター情報を読み出す。また、VR空間生成部1434は記憶部142から参加ユーザ情報1422を読み出し、参加ユーザに対応するアバター情報を取得する(ステップS31)。
仮想ライブが開始すると、演者用の動作検出装置11は演者の動作を検出し、動作情報を配信者端末14に送信する(ステップS21)。これにより、配信者端末14の演者動作取得部1433は演者の動作情報を受信する(ステップS32)。
そして、VR空間生成部1434は、ステップS31で取得したアバター情報と、ステップS32で受信した演者の動作情報とに基づき、仮想ライブ会場を生成する。生成された仮想ライブ会場を出力するためのVR空間情報は、VR空間情報送信部1437によってサーバ3に送信される(ステップS33)。このVR空間情報を受信したサーバ3のVR空間情報配信部336は、VR空間情報を演者用の再生装置12、HMD21およびユーザ端末22に配信する(ステップS41)。これにより、演者用の再生装置12などに仮想ライブ会場が出力される(ステップS42)。
演者用の動作検出装置11から演者の動作情報がほぼリアルタイムに配信者端末14に送信され、配信者端末14のVR空間生成部1434はリアルタイムに仮想ライブ会場を生成する。これにより、演者の動作に応じて演者アバターがリアルタイムに動作する仮想ライブが提供される。
[表示される仮想ライブ会場]
ここで、VR空間生成部1434によって生成される仮想ライブ会場(ステップS33)について詳しく述べる。生成される仮想ライブ会場は演者アバターおよび各参加ユーザに対応するユーザアバターの少なくとも一部を含む。具体例として、仮想ライブ会場の前方に配置された仮想舞台上において、動作情報に応じて動作する演者アバターが配置される。また、各仮想座席には、当該仮想座席に設定された参加ユーザに対応するユーザアバターが配置される。このような仮想ライブ会場の見え方は演者および各ユーザに共通していてもよいが、互いに異なるのが望ましい。以下、後者について説明する。
図7Aは、演者用の再生装置12のディスプレイ121に表示される仮想ライブ会場を模式的に示す図である。図示のように、演者用には演者アバターの視点で仮想ライブ会場が見えるようにするのがよい。すなわち、演者用の再生装置12には、演者アバターは見えず、仮想座席に配置されたユーザアバターが表示される。
なお、1つの仮想座席に複数の参加ユーザが設定されている場合、VR空間生成部1434は、その仮想座席に対応する1つの仮想座席を仮想ライブ会場に設け、時間帯ごとに配置されるユーザアバターを切り替えてもよい。あるいは、VR空間生成部1434は、設定されている参加ユーザ数だけ仮想座席を仮想ライブ会場に設け、設定されている全参加ユーザに対応する全ユーザアバターを同時に配置してもよい。ただし、1つの仮想座席に設定される参加ユーザ数が多すぎると仮想ライブ会場上に仮想座席を配置するのが困難になるため、1つの仮想座席に設定され得る参加ユーザ数に上限を設けるのが望ましい。
なお、同一の3D空間上に配置するに最適な数には上限があるが、その数を大幅に上回る場合、仮想ライブ会場における舞台となる3D空間を複製し、後述する「仮想ライブ会場2」のような会場を、複製元となる後述の「仮想ライブ会場1」と並列した会場として生成し配置してもよい。またステージ上の主要な出演者や演出のみがそれぞれの仮想ライブ会場nに複製され(nは自然数)、個々個別の参加者はネットワーク速度や再生環境、混雑に適した快適な仮想ライブ会場に最適配置され視聴できる。
図7Bは、あるユーザ(例えば、図9Aのユーザアバター91に対応するユーザ)のユーザ端末22のタッチパネル224(あるいはHMD21、以下同じ)に表示される仮想ライブ会場を模式的に示す図である。図示のように、ユーザ用には当該ユーザに設定された仮想座席からの視点で仮想ライブ会場が見えるようにするのがよい。すなわち、ユーザ用のタッチパネル224には、自身に対応するユーザアバターは見えず、仮想舞台90上の演者アバター92と、少なくとも一部の他のユーザに対応するユーザアバター(符号を付していないアバター)とが見える。ただし、ユーザ用のタッチパネル224には、自身に対応するユーザアバターが見えていてもよい。
このように、演者あるいは各ユーザに適した仮想ライブ会場の表示(出力)がなされるようなVR空間情報がVR空間情報送信部1437によってサーバ3に送信され、配信される。そして、仮想ライブ配信中に、以下に述べるユーザ端末22からのフィードバック処理が行われる。
[フィードバック処理]
図8は、ユーザ端末22からのフィードバック処理を行う手順の一例を示すフローチャートである。この処理は図7に示す仮想ライブ会場の表示と並行して重畳的に行われる。
ユーザ端末22のセンサ223はユーザの動作を検出し、検出されたデータに基づいて反応データ生成部2262は反応データを取得する。この反応データはサーバ3に送信される(ステップS61)。
仮想ライブ配信中においては、ユーザは仮想ライブ会場における演者の演出に反応して動作する蓋然性が高い。そのため、仮想ライブ配信中にセンサ223によって検出されるデータは、仮想ライブ会場における演出に関連していると言える。したがって、反応データ生成部2262は、仮想ライブ配信中にセンサ223によって検出されたデータから、仮想ライブ会場における演出に対する反応に関する反応データを生成できる。
続いて、サーバ3の反応データ取得部332は反応データを受信する(ステップS71)。そして、ユーザ特定部333は、各ユーザ端末22からの反応データに基づき、盛り上がっているアクティブなユーザを特定する(ステップS72)。
そして、出力提示情報生成部334は、特定されたユーザ用の出力提示情報を生成し、当該ユーザの出力提示装置23に出力提示情報を送信する(ステップS73)。これにより、出力提示装置23が作動して発光したり触覚をユーザに与えたりする(ステップS80)。このようにして、ユーザの反応がユーザ自身にフィードバックされる。
なお、出力提示情報生成部334は特定されたユーザ以外のユーザの出力提示装置23には出力提示情報を送信しなくてもよい。この場合、アクティブなユーザの出力提示装置23のみが作動する。ただし、出力提示情報生成部334は、アクティブなユーザの数が所定値を超えたときなどには、アクティブでない(盛り上がっていない)ユーザの出力提示装置23にも出力提示情報を送信して作動させてもよい。
以下、ユーザに対するフィードバックの例をいくつか示す。
アクティブ度に対する閾値を複数設けるなどによって複数段階に分けてユーザを特定するなどにより、ユーザ用の出力提示情報をアクティブ度(あるいは反応データ)に応じたものとしてもよい。例えば、よりアクティブ度が高いユーザほど、つまり、ライブの盛り上がりに大きく貢献しているユーザほど、出力提示装置23によって大きな作用が与えられるような出力提示情報が生成されてもよい。具体例として、アクティブ度が高いユーザほど、出力提示装置23としての触覚デバイスがより大きく振動してもよい。あるいは、アクティブ度が高いユーザほど、出力提示装置23として電飾が明るく発光してもよい(例えば、より多くの発光体が増える、発光体における発光部分が大きくなるなど)。このように、フィードバックの程度をユーザのアクティブ度に応じたものとすることで、より多様なフィードバックを実現できる。
また、出力提示情報は特定されたユーザの仮想座席に応じたものであってよい。例えば、仮想ライブ会場における演者アバターとの距離が近い仮想座席が設定されたユーザほど、出力提示装置23によって大きな作用がユーザに与えられるような出力提示情報が生成されてもよい。
別の例として、アクティブでないユーザを特定し、盛り上がりを促すべく、そのようなユーザの出力提示装置23に出力提示情報を送信してもよい。このときの出力提示情報は、例えば、「一緒に盛り上がろう」といった盛り上がりを促すテキスト情報であってもよい。
図8に戻り、出力提示情報生成部334は、演者用の出力提示情報を生成し、演者の出力提示装置13に出力提示情報を送信する(ステップS74)。これにより、出力提示装置13は触覚や発光などの作用を演者に与える(ステップS81)。このようにして、ユーザの反応が演者にフィードバックされる。
以下、演者に対するフィードバックの例をいくつか示す。
演者用の出力提示情報はユーザ端末22からの反応データ(あるいはアクティブ度)に基づくものであってよい。例えば、アクティブ度が高いほど、および/または、アクティブなユーザの数が多いほど、出力提示装置13によって大きな作用が演者に与えられるような出力提示情報が生成されてもよい。
また、出力提示情報はユーザ特定部333によって特定されたユーザ(に設定された仮想座席の位置)に基づくものであってもよい。例えば、いずれのユーザがアクティブであるかを演者が認識できるような出力提示情報が生成される。すなわち、演者へのフィードバックとして、アクティブなユーザの位置を示す作用がなされてもよい。
具体的には、演者用の出力提示情報がアクティブなユーザの位置を示す情報を含む。これに応じて、演者用の出力提示装置13は、演者の体の一部分であって、アクティブなユーザの位置に対応する一部分に触覚的な作用を与えてもよいし、アクティブなユーザに対応する位置が発光してもよい。これにより、演者はどのユーザがアクティブであるかを把握できる。
より具体的な例として、演者からみて右手側の仮想座席に設定されたユーザのアクティブ度が高い場合、出力提示装置13によって演者の右半身に触覚が与えられるような出力提示情報、あるいは、スタジオの右側に設置された電飾が発光するような出力提示情報が生成されてもよい。
図8に戻り、VR空間変更情報生成部335はユーザの反応に応じて仮想ライブ会場を変更するためのVR空間変更情報を生成し、これを配信者端末14に送信する(ステップS75)。VR空間配信情報に応じて、配信者端末14のVR空間変更部1436は仮想ライブ会場を変更し、変更後の仮想ライブ会場を示すVR空間情報をサーバ3に送信する(ステップS82)。サーバ3のVR空間情報配信部336は、VR空間情報を演者用の再生装置12、ユーザ端末22およびHMD21(図8には不図示)に配信する(ステップS76)。これにより、変更された仮想ライブ会場が演者用の再生装置12、ユーザ端末22およびHMD21によって出力される(ステップS62,S83)。なお、図8で示されるステップの実行順序は、適宜変更可能である。例えば、テップS73、S74、S75の実行される順番は、任意であり、例えばステップS75、S74、S73の順に実行されてもよい。
以下、仮想ライブ会場変更の例をいくつか示す。
図9Aおよび図9Bは、仮想ライブ会場におけるユーザアバターの表示態様を変更する例を模式的に示す図である。図9Aは図7Aに対応しており、演者用の再生装置12におけるディスプレイ121に表示される仮想ライブ会場である。図9Bは図7Bに対応しており、ユーザ端末22のタッチパネル224(またはHMD21)に表示される仮想ライブ会場である。
図9Aおよび図9Bは、アクティブなユーザを特定する情報を含むVR空間変更情報が配信者端末14に送信され、配信者端末14のVR空間変更部1436がアクティブなユーザに対応するユーザアバター93の色を変更する例である。このような表示態様の変更により、アクティブなユーザを他のユーザや演者が認識できる。
表示態様の変更としては、色を変えるほか、特定の動作(ジャンプし始める、踊り始める、表情が変わるなど)をさせてもよいし、ユーザアバター93に対する付加的な表示(汗をかくなど)を行ってもよいし、表示位置を変えたり(仮想舞台に登るなど)、ユーザアバター93が光り始めたりしてもよい。さらに、表示態様に加えて/代えて、アクティブなユーザに対応するユーザアバター93が声援を発するなど音声態様が変更されてもよい。
図10Aおよび図10Bは、仮想ライブ会場におけるユーザアバター94および演者アバター92が相互作用するよう表示態様を変更する例を模式的に示す図である。図10Aは図7Aに対応しており、演者用の再生装置12におけるディスプレイ121に表示される仮想ライブ会場である。図10Bは図7Bに対応しており、ユーザ端末22のタッチパネル224(またはHMD21)に表示される仮想ライブ会場である。
図10Aおよび図10Bは、アクティブなユーザを特定する情報を含むVR空間変更情報が配信者端末14に送信され、配信者端末14のVR空間変更部1436がアクティブなユーザに対応するユーザアバター94および演者アバター92が互いに見つめ合うよう表示態様を変更する例である。具体的には、ユーザアバター94は演者アバター92からの視線を受けるよう表示態様が変更される。また、演者アバター92はアクティブなユーザに対応するユーザアバター94に視線を送るよう表示態様が変更される。
相互作用の例としては、視線を送り合うほか、手を振る、握手する、ハグするといった表示上の相互作用や、声をかけるといった音声上の相互作用があり得る。
演者アバターとユーザアバター94がハグを行う場合、そのことを示す出力提示情報が出力提示装置23によって生成されてもよい。ユーザは、出力提示装置23として上述したジャケット型の触覚デバイスを着用していれば、あたかも演者アバターと抱き合ったかのようなリアルな感覚を体感できる。
また、演者アバターがユーザアバター94に声をかける場合、そのことを示す出力提示情報が出力提示情報生成部334によって生成されてもよい。ユーザは、出力提示装置23として音響デバイスを含んでいれば、あたかも演者アバターから声をかけられたかのようなリアルな感覚を体感できる。
このように、VR空間変更情報と、出力提示情報とが対応あるいは関連していてもよい。これにより、仮想ライブ会場におけるフィードバックと同等のフィードバックを実空間においてもユーザが受けることが可能となる。特に、フィードバックが相互作用である場合に有効である。
また、相互作用でなく、アクティブなユーザに対応するユーザアバター94に対して、演者アバター92が一方的に視線を送るなどの作用を与えるような表示態様の変更であってもよい。この場合、演者アバター92のみ表示態様が変更されてもよい。あるいは、演者アバター92に対して、アクティブなユーザに対応するユーザアバター94が一方的に視線を送るなどの作用を与えるような表示態様の変更であってもよい。この場合、ユーザアバター94のみ表示態様が変更されてもよい。
図11Aおよび図11Bは、仮想ライブ会場に演出がなされるよう仮想ライブ会場の表示態様を変更する例を模式的に示す図である。図11Aは図7Aに対応しており、演者用の再生装置12におけるディスプレイ121に表示される仮想ライブ会場である。図11Bは図7Bに対応しており、ユーザ端末22のタッチパネル224(またはHMD21)に表示される仮想ライブ会場である。
図11Aおよび図11Bは、アクティブなユーザの数が所定値に達したことを示すVR空間変更情報が配信者端末14に送信され、仮想ライブ会場に花火95が打ち上がる演出が行われる例である。演出の例としては、花火95の他、ギフトを表示させるといった画像上の効果の他、音声上の効果も考えられる。
このような仮想ライブ会場の変更は、仮想ライブに参加しているユーザから課金が行われた場合、演者が有効な演出を行ったと判定された場合、仮想ライブ会場に流れる曲の開始タイミングに所定の反応データが得られた場合などに、VR空間変更部1436は事前に準備した音声効果を仮想ライブ会場に生じさせてもよい。
また、アクティブなユーザの数が多いほど仮想ライブ会場の視界が曇るなど、アクティブなユーザの数に応じた演出が行われてもよい。あるいは、仮想ライブ会場にアクティブなユーザの数に対応する指標(バーグラフや折れ線グラフなど)が表示されてもよい。
このように、第1の実施形態では、ユーザの反応がセンサ223によって取得され、演者、演者アバター、ユーザ、および/またはユーザアバターにフィードバックされる。
[変形例]
ユーザ用の出力提示装置23は、演者用の出力提示装置13と同様の構成でなくてもよい。例えば、ユーザ用の出力提示装置23は、電飾(発光デバイス)、発煙装置、および/または着火装置などであり、ユーザが赴いた特定の会場に設置された装置であってもよい。例えば、HMDを着用することなく特定の会場に赴いた複数のユーザは、HMDを着用した場合に比べて、仮想ライブ会場の演出を実感しづらい。しかしながら、このような複数のユーザが、出力提示装置23の出力(作動)を認識すれば、仮想ライブの演出に伴い盛り上がり易くなる。特にこのような出力提示装置23が大掛かりであるほど、盛り上がり易くなる。なお、ユーザの感情が所定条件を満たすことを契機とすることに加えて/代えて、仮想ライブで音楽が始まったことを契機として、または、演者アバターが踊り始めたことを契機として、このような出力提示装置23はユーザにフィードバックを与えてもよい。そのためには、例えば、VR空間生成部1434と出力提示情報生成部334とが協働し、フィードバックを与えるタイミングを示す情報が出力提示情報に含まれるようにすればよい。
また、図1および図2の構成は例示にすぎない。配信者端末14、サーバ3およびユーザ端末22の任意の1以上を情報処理装置と考えることができる。例えば、配信者端末14およびサーバ3が一体であってもよいし、配信者端末14の機能の一部がサーバ3またはユーザ端末22によって実行されてもよいし、サーバ3の機能の一部が配信者端末14またはユーザ端末22によって実行されてもよい。
例えば、図1および図2は、配信者端末14が仮想ライブ会場を生成し(レンダリングを行う)、サーバ3(ストリーミングサーバ)がコンテンツ配信を行うものであったが、サーバ3あるいはユーザ端末22がレンダリングを行ってもよい。
図12は、サーバ3がレンダリングを行うコンテンツ配信システムにおける配信者端末14、サーバ3およびユーザ端末22の内部構成を模式的に示す図である。なお、図12において、図2と同じ名称が付された各部は図2を用いて説明した動作と同等の動作を行うものとする。このコンテンツ配信システムでは、配信者端末14でなくサーバ3が仮想ライブ会場を生成してVR空間情報を配信する。
具体的には、配信者端末14における演者動作取得部1433は、動作検出装置11からの動作情報を取得し、これをサーバ3に送信する。一方、サーバ3の演者情報取得部1431および参加ユーザ情報取得部1432は、予め演者情報1421および参加ユーザ情報321,1421を取得し、これらを記憶部32に記憶している。また、サーバ3内に仮想ライブ会場を生成・配信するための各機能部が設けられている。これにより、サーバ3が動作情報に基づいて仮想ライブ会場を生成し、配信できる。
図13は、図12のコンテンツ配信システムにおいて、仮想ライブ会場を生成する手順の一例を示すフローチャートであり、図6と対応している。
仮想ライブの配信開始に先立って、サーバ3のVR空間生成部1434は仮想ライブの配信を行う演者を特定する演者IDを取得し、記憶部32に記憶された演者情報1421のなかから当該演者IDと関連付けられたアバター情報を読み出す。また、VR空間生成部1434は記憶部32から参加ユーザ情報1422を読み出し、参加ユーザに対応するアバター情報を取得する(ステップS31’)。
仮想ライブが開始すると、演者用の動作検出装置11は演者の動作を検出し、動作情報を配信者端末14に送信する(ステップS21)。配信者端末14の演者動作取得部1433は、動作検出装置11からの動作情報を取得し、これをサーバ3に送信する(ステップS32’)。これにより、サーバ3の演者動作取得部1433は演者の動作情報を受信する(ステップS32’’)。
そして、サーバ3のVR空間生成部1434は、ステップS31’で取得したアバター情報と、ステップS32’’で受信した演者の動作情報に基づき、仮想ライブ会場を生成する(ステップS33’)。生成された仮想ライブ会場を出力するためのVR空間情報が、VR空間情報配信部336によって演者用の再生装置12、HMD21およびユーザ端末22に配信される(ステップS41)。これにより、演者用の再生装置12などに仮想ライブ会場が出力される(ステップS42)。
図14は、図12のコンテンツ配信システムにおいて、ユーザ端末22からのフィードバック処理を行う手順の一例を示すフローチャートであり、図8と対応している。図8との違いは、図8のステップS82が省略され、サーバ3自身がVR空間を変更して配信する点(ステップS76’)である。
図15は、ユーザ端末22がレンダリングを行うコンテンツ配信システムにおける配信者端末14、サーバ3およびユーザ端末22の内部構成を模式的に示す図である。なお、図15において、図2と同じ名称が付された各部は図2を用いて説明した動作と同等の動作を行うものとする。このコンテンツ配信システムでは、演者の動作を示す動作情報がサーバ3(モーションサーバ)からユーザ端末22に送信され、ユーザ端末22が仮想ライブ会場を生成して出力する。
具体的には、配信者端末14における演者動作取得部1433は、動作検出装置11からの動作情報を取得し、これをサーバ3に送信する。サーバ3の演者動作取得部1433は動作情報を各ユーザ端末22に送信する。一方、ユーザ端末22の演者情報取得部1431および参加ユーザ情報取得部1432は、予め演者情報1421および参加ユーザ情報1422をサーバ3から受信し、これらを記憶部222に記憶している。また、ユーザ端末22の記憶部222には、演者の動作情報に応じて演者アバターを動作させたり、仮想ライブ会場を変更したりするためのプログラムが記憶されており、このプログラムの実行によってVR空間生成部1434およびVR空間変更部1436など、仮想ライブ会場を生成するための各機能部が実現される。
また、演者用の再生装置12に仮想ライブ会場を出力すべく、ユーザ端末22と同様、配信者端末14は演者情報1421および参加ユーザ情報1422を記憶しており、仮想ライブ会場を生成するための各機能部が設けられる。
図16は、図15のコンテンツ配信システムにおいて、仮想ライブ会場を生成する手順の一例を示すフローチャートであり、図6と対応している。
仮想ライブの配信開始に先立って、配信者端末14およびユーザ端末22のVR空間生成部1434は仮想ライブの配信を行う演者を特定する演者IDをサーバ3から取得し、記憶部142,222にそれぞれ予め記憶された演者情報1421のなかから当該演者IDと関連付けられたアバター情報を読み出す。また、VR空間生成部1434は記憶部142,222から参加ユーザ情報1422を読み出し、参加ユーザに対応するアバター情報を取得する(ステップS31,S31’)。
仮想ライブが開始すると、演者用の動作検出装置11は演者の動作を検出し、動作情報を配信者端末14に送信する(ステップS21)。配信者端末14の演者動作取得部1433は、動作検出装置11からの動作情報を取得し、これをサーバ3に送信する(ステップS32’)。これにより、サーバ3の演者動作取得部1433は演者の動作情報を受信し、これをユーザ端末22に送信する(ステップS321)。これにより、ユーザ端末22の演者動作取得部1433は動作情報を受信する(ステップS322)。
そして、ユーザ端末22のサーバ3のVR空間生成部1434は、ステップS31’で取得したアバター情報と、ステップS322で受信した演者の動作情報に基づき、仮想ライブ会場を生成する(ステップS33’)。これにより、ユーザ端末22に仮想ライブ会場が出力される(ステップS42)。
また、配信者端末14のサーバ3のVR空間生成部1434は、ステップS31で取得したアバター情報と、ステップS32’で受信した演者の動作情報に基づき、仮想ライブ会場を生成する(ステップS91’)。これにより、演者用の再生装置12に仮想ライブ会場が出力される(ステップS92)。
図15の構成によれば、演者の動作を配信者端末14が取得し、サーバ3を経由して各ユーザ端末22に送信される。動画そのものが送信されるわけではないので、サーバ3の通信量を減らすことができる。通信量の低減効果は、ユーザ端末22の台数が多いほど高まる。
図17は、図15のコンテンツ配信システムにおいて、ユーザ端末22からのフィードバック処理を行う手順の一例を示すフローチャートであり、図8と対応している。図8との違いは、サーバ3によって生成され送信されたVR空間変更情報(ステップS75)に基づき、ユーザ端末22におけるVR空間変更部1436および配信者用端末14におけるVR空間変更部1436がVR空間を変更する点(ステップS62,S82’)点である。
また、ユーザ特定部333は反応データに基づいてユーザを特定すればよく、盛り上がっているユーザに限られない。例えば、ユーザ特定部333は、悲しみや怒りなど他の感情が所定の条件を満たすユーザを特定してもよい。例えば、VR空間で追悼式が行われる場合、悲しみが深いユーザを特定し、そのユーザに出力されるフィードバックを抑えるようにしてもよい。別の例として、VR空間上で演者アバターを呼びかけ人とする政治デモが行われる場合、反応データとして心拍数あるいは体温の変化に基づいたデータに基づき、ユーザ特定部333は怒っているユーザを特定し、そのユーザに対応するユーザアバター(呼びかけ人に同調しているユーザアバター)を赤くするなどのフィードバックを行ってもよい。
(第2の実施形態)
上述した第1の実施形態は、各ユーザが自身のHMD21あるいはユーザ端末22にVR空間である仮想ライブ会場を出力するものであった。この場合、ユーザ毎に表示される仮想ライブ会場は異なる。これに対し、次に説明する第2の実施形態は、所定の会場にスクリーンを設け、このスクリーンに1つの仮想ライブ会場を出力するものである。以下、第1の実施形態との違いを中心に説明する。
図18は、第2の実施形態に係るコンテンツ配信システムの概略構成を示すブロック図である。配信者端末14、サーバ3およびユーザ端末22の内部構成は、図2に示すものと概ね同様である。図1との違いとして、コンテンツ配信システムは、実際の映画館などの会場に設置された1以上の(スピーカ付き)スクリーン41,42を備えている。これらのスクリーン41,42をディスプレイとして仮想ライブが出力される。以下、2つのスクリーン41,42があるとして説明する。
スクリーン41が設置された会場1(以下「実ライブ会場1」とも呼ぶ)において、スクリーン41から出力される仮想ライブ会場を鑑賞することによって、複数のユーザが仮想ライブに参加できる。以下、このようなユーザを「実ライブ会場1のユーザ」とも呼ぶ。スクリーン42が設置された会場2(以下「実ライブ会場2」とも呼ぶ)についても同様である。さらに、いずれの会場1,2にも行かず、自宅などで自身のHMD21やユーザ端末22に仮想ライブ会場を出力させることにより、仮想ライブに参加することもできる。以下、このようなユーザを「仮想ライブ会場のユーザ」とも呼ぶ。
このように、スクリーン41,42のそれぞれに出力される仮想ライブ会場が複数のユーザによって鑑賞されることを前提とする場合、仮想ライブ会場における各仮想座席にユーザを設定する手法は種々考えられる。以下、仮想ライブ会場における仮想座席と、各仮想座席に設定される参加ユーザとの関係を示す参加ユーザ情報1422の例をいくつか示す。
図19Aは、参加ユーザ情報1422のデータ構造の一例を模式的に示す図である。図示のように、本参加ユーザ情報1422は、参加するユーザを特定する参加ユーザIDが、実ライブ会場1,2のそれぞれにおいてそのユーザに設定された実際の座席(実座席)を特定する実座席IDと、仮想ライブ会場においてそのユーザに設定された仮想座席を特定する仮想座席IDと、そのユーザに対応するアバター情報とに関連付けられたものである。
参加する会場とは、ユーザが、実ライブ会場1において参加するのか、実ライブ会場2において参加するのか、仮想ライブ会場において参加するのか、である。また、実座席IDは実ライブ会場1,2に参加するユーザの参加ユーザIDにのみ関連付けられる。当然ではあるが、1つの実ライブ会場における実座席には、1人のユーザのみが設定される。実ライブ会場における実座席の位置と、仮想ライブ会場における仮想座席の位置とは対応関係にあってもよいし、無関係でもよい。
図19Aは、仮想ライブ会場における1つの仮想座席に任意の2以上のユーザが設定されることを許容する例である。図19Aの例では、仮想座席A01には、実ライブ会場1におけるユーザU11,U12と、実ライブ会場2におけるユーザU14と、仮想ライブ会場におけるユーザU16とが設定される。また、仮想座席A02には、実ライブ会場1におけるユーザU13と、実ライブ会場2におけるユーザU15と、仮想ライブ会場におけるユーザU17とが設定されている。以上のような仮想座席設定がなされるように、サーバ3のライブ参加受付部331は動作する。
仮想ライブ用の仮想ライブ会場の生成手順や、フィードバック処理の手順は、第1の実施形態(図6および図8)と同様であってよい。ただし、実ライブ会場1,2において仮想ライブに参加するユーザに対しては、VR空間情報を配信しなくてもよい。その代わりに、実ライブ会場1,2にそれぞれ設置されたスクリーン41,42にVR空間情報が配信され、出力される。仮想ライブ会場の見え方は各スクリーン41,42に共通していてもよいが、互いに異なるのが望ましい。
まずは、実ライブ会場1に設置されたスクリーン41に表示される仮想ライブ会場について説明する。
図20Aおよび図20Bは、スクリーン41に表示される仮想ライブ会場を模式的に示す図である。スクリーン41には、演者アバター92と、実ライブ会場1において仮想ライブに参加する少なくとも一部のユーザに対応するユーザアバターが表示される。各ユーザアバターは、対応するユーザの仮想座席に応じた位置に表示される。仮想ライブ会場における1つの仮想座席に複数のユーザが設定されている場合、実ライブ会場1において参加しているユーザに対応するユーザアバターが優先的に表示される。
図19Aの例では、仮想座席A02にはユーザU13,U15,U17が設定されているが、図20Aおよび図20Bに示すように、スクリーン41には、実ライブ会場1において仮想ライブに参加しているユーザU13に対応するユーザアバターX23が仮想座席A02の位置に表示される。
一方、仮想座席A01には、実ライブ会場1において仮想ライブに参加している複数のユーザ(2人のユーザU11,U12)が設定されている。この場合、図20Aに示すように、その仮想座席A01に対応する1つの仮想座席A01を仮想ライブ会場に設け、時間帯ごとに配置されるユーザアバターが切り替わってもよい(図20AではユーザU12に対応するユーザアバターX22が表示されている)。あるいは、図20Bに示すように、設定されている参加ユーザ数だけの仮想座席A01-1,A01-2を仮想ライブ会場に設け、設定されている全参加ユーザに対応するユーザアバターX21,X22を同時に配置してもよい。ただし、1つの仮想座席に設定される参加ユーザ数が多すぎると仮想ライブ会場上の配置が困難であるため、1つの仮想座席に設定される参加ユーザ数に上限を設けるのが望ましい。
実ライブ会場2に設置されたスクリーン42に表示される仮想ライブ会場についても同様である。すなわち、図20Cに示すように、図19Aの例では、仮想座席A01にはユーザU14に対応するユーザアバターX24が表示され、仮想座席A02にはユーザU15に対応するユーザアバターX25が表示される。
なお、演者用の再生装置12、および、仮想ライブ会場において仮想ライブに参加している各ユーザのHMD21あるいはユーザ端末22に出力される仮想ライブ会場は、第1の実施形態と同様である。
上述した例において、実ライブ会場1において仮想座席A02が設定されたユーザU13に対応するユーザアバターの表示態様が変更される場合、実ライブ会場2において同じく仮想座席A02が設定されたユーザU15や、仮想ライブ会場において同じく仮想座席A02が設定されたユーザU17に対応するユーザアバターの表示態様が変更されてもよいし、されなくてもよい。
すなわち、ある(実または仮想)ライブ会場におけるユーザアバターへのフィードバックは、他の(実または仮想)ライブ会場におけるユーザアバターへのフィードバックに反映されてもよいし、されなくてもよい。
また、ユーザ特定部333によって、実ライブ会場1におけるユーザU13はアクティブでないが、実ライブ会場2におけるユーザU15がアクティブであるとして特定された場合、スクリーン42における演者アバターのみの表示態様が変更(例えば、演者アバターが手を振る)されてもよいし、スクリーン41,42の両方における演者アバターの表示態様が変更されてもよい。
すなわち、ある(実または仮想)ライブ会場におけるユーザの反応が、他の(実または仮想)ライブ会場における演者アバターへのフィードバックに反映されてもよいし、されなくてもよい。また、仮想空間内に配置・出現したギフト等の3Dオブジェクトや演出は、通常は物理エンジンによって衝突や重力が実時間処理され、その後、かかる3Dオブジェクトに関するイベントの演出を開始するか否かが判定処理される。これらの処理は、スクリプトによって分岐処理可能であるが、一般的な処理であるため詳細な説明については割愛する。
図19Bは、参加ユーザ情報1422のデータ構造の別の例を模式的に示す図である。図19Bは、仮想ライブ会場における1つの仮想座席に、2以上のユーザが設定されることを許容するが、1つの実ライブ会場につき1人のみのユーザが設定される例である。ただし、仮想ライブに参加する複数のユーザが1つの仮想座席に設定されてよい。図19Bの例では、仮想座席A01には、実ライブ会場1におけるユーザU11と、実ライブ会場2におけるユーザU14と、仮想ライブ会場におけるユーザU16,U17とが設定される。なお、仮想座席A03には、実ライブ会場1においてはユーザU13が設定されているが、実ライブ会場2および仮想ライブ会場においては、いずれのユーザも設定されていない。
このような設定であれば、スクリーン41には、演者アバターと、実ライブ会場1において仮想ライブに参加する全ユーザに対応するユーザアバターを表示できる。例えば、図19Bにおける仮想座席A01に関し、実ライブ会場1におけるユーザU11に対応するユーザアバターはスクリーン41に表示されるが、実ライブ会場2におけるユーザU14に対応するユーザアバターはスクリーン41に表示されない。
同様に、スクリーン42には、演者アバターと、実ライブ会場2において仮想ライブに参加する全ユーザに対応するユーザアバターを表示できる。例えば、図16Bにおける仮想座席A01に関し、実ライブ会場2におけるユーザU14に対応するユーザアバターはスクリーン42に表示されるが、実ライブ会場1におけるユーザU11に対応するユーザアバターはスクリーン42に表示されない。
なお、実ライブ会場2において、仮想座席A03にはいずれのユーザも設定されていない。この場合、スクリーン42には仮想座席A03を空席としてもよいし、実ライブ会場1において仮想座席A03が設定されたユーザA13に対応するユーザアバターを表示してもよい。後者によれば、空席を少なく見せることができる。
なお、図19Bで示される参加ユーザ情報1422の「会場」の欄に、互いに異なる「仮想ライブ会場1」と「仮想ライブ会場2」がデータとして格納されてもよい。「仮想ライブ会場2」とは、3D空間上において、「仮想ライブ会場1」と空間的に互いに連通する空間(仮想ライブ会場1とは別の部屋のような形態)でもよいし、仮想ライブ会場1と同一の複製された3D空間であってもよい。「仮想ライブ会場1」と「仮想ライブ会場2」は、同時に利用し得る並列的な世界でもよい。
図19Cは、参加ユーザ情報1422のデータ構造のまた別の例を模式的に示す図である。図示のように、図19Aおよび図19Bと比較して、参加ユーザ情報は、参加ユーザIDに対して、仮想座席を独占するか否かを示す情報も関連付けられる。すなわち、図19Cは、仮想ライブ会場における1つの仮想座席を1ユーザが独占するか、複数のユーザが設定されるかを、当該仮想座席を最初に選択したユーザが指定できる例である。
図19Cの例では、仮想座席A01は独占されていないため、実ライブ会場1ではユーザU11が設定され、実ライブ会場2ではユーザU13が設定され、仮想ライブ会場ではユーザU15,U16が設定される。一方、仮想座席A02は実ライブ会場1において仮想ライブに参加するユーザU12によって独占されているため、実ライブ会場2においても、仮想ライブ会場においても、他ユーザの設定はできない。
この場合、ユーザU12が参加する実ライブ会場1に設置されたスクリーン41のみならず、他の実ライブ会場2に設置されたスクリーン42、および、仮想ライブ会場において仮想ライブに参加するユーザのHMD21あるいはユーザ端末22にも、ユーザU12に対応するユーザアバターが仮想座席A02に配置された仮想ライブ会場が出力される。
この場合、ユーザU12の反応(正確には、ユーザU12のユーザ端末22からサーバ3に送信される反応データに応じて、ユーザU12に対応するユーザアバターがフィードバックを受ける際、当該フィードバックの様子は他のスクリーン42などにも出力される。特に、演者アバターとユーザアバターとがハグなどの相互作用を行うようなフィードバック(表示態様の変更)である場合、何らの矛盾も生じない。したがって、1つの仮想座席が1人のユーザに独占的に設定されたことを条件として、VR空間変更部1436は演者アバターとユーザアバターとが相互作用を行うようにしてもよい。
このように、第2の実施形態では、1つのスクリーン41,42を複数のユーザが鑑賞する場合でも、ユーザの反応をセンサ223で取得し、演者、演者アバター、ユーザ、および/またはユーザアバターにフィードバックできる。
また、サーバ3あるいはユーザ端末22がレンダリングを行うようにするなど、第1の実施形態と同様の変形例を第2の実施形態に適用可能である。
なお、ユーザU12に対応するユーザアバターは、3D空間上の他の動的オブジェクトとの衝突イベントに応じてフィードバックを受けてもよいし、所定の制御スクリプトに応じてフィードバックを受けてもよい。
上述した実施形態は、本発明が属する技術分野における通常の知識を有する者が本発明を実施できることを目的として記載されたものである。上記実施形態の種々の変形例は、当業者であれば当然になしうることであり、本発明の技術的思想は他の実施形態にも適用しうることである。したがって、本発明は、記載された実施形態に限定されることはなく、特許請求の範囲によって定義される技術的思想に従った最も広い範囲とすべきである。