JP2022137826A - ３ｄオブジェクトのストリーミング方法、装置、及びプログラム - Google Patents

Abstract

【課題】３Ｄ画像をサーバからクライアントに送る際のデータ転送量を削減可能な方法、装置、及びプログラムを提供する。【解決手段】サーバからクライアントへ、３Ｄオブジェクトを送信する本開示による方法は、前記サーバ上の前記３Ｄオブジェクトからカラー情報、アルファ情報及びジオメトリ情報を抽出することと、前記ジオメトリ情報を単純化することと、前記サーバから前記クライアントへ、前記カラー情報、前記アルファ情報及び前記単純化されたジオメトリ情報を含むストリームを符号化して送信することと、を含む。【選択図】図１３

Description

本開示は、３Ｄ（３次元）オブジェクトのストリーミング方法、装置及びプログラムに関する。

従来から３Ｄ画像をサーバからクライアントへ送信して表示するという技術はあるが、この場合、例えば、サーバ側で、３Ｄ画像を２Ｄ画像へ変換するという手法を使っていた（特許文献１）。

米国特許出願公開２０１０／０１３４４９４号明細書

解決しようとする従来の問題点は、３Ｄ画像の伝送において、画質を維持しながら、データ伝送に使用する帯域幅を減少することである。

本開示の一態様である方法は、サーバからクライアントへ、３Ｄオブジェクトを送信する方法であって、前記サーバ上の前記３Ｄオブジェクトからカラー情報、アルファ情報及びジオメトリ情報を抽出することと、前記ジオメトリ情報を単純化することと、前記サーバから前記クライアントへ、前記カラー情報、前記アルファ情報及び前記単純化されたジオメトリ情報を含むストリームを符号化して送信することと、を含む。

本開示の一態様である方法は、サーバ上にある３Ｄオブジェクトをクライアント上で再現する方法であって、前記サーバから前記３Ｄオブジェクトのカラー情報、アルファ情報及びジオメトリ情報を含む符号化されたストリームを受信することと、前記ストリームを復号し、そこから前記カラー情報、前記アルファ情報及び前記ジオメトリ情報を抽出することと、前記ジオメトリ情報に基づいて前記３Ｄオブジェクトの形状を再現することと、前記再現された３Ｄオブジェクトの形状の上に、前記カラー情報と前記アルファ情報を合成した情報を投影することにより前記３Ｄオブジェクトを再構成することと、を含む。

本開示の一態様であるサーバは、１つ以上のプロセッサ及びメモリを含むサーバであって、前記１つ以上のプロセッサが、前記メモリに記憶された命令を実行することによって、前記サーバ上の３Ｄオブジェクトからアルファ情報及びジオメトリ情報を抽出し、前記ジオメトリ情報を単純化し、前記サーバからクライアントへ、前記アルファ情報及び前記単純化されたジオメトリ情報を含むストリームを符号化して送信する。

本開示の一態様であるクライアントは、１つ以上のプロセッサ及びメモリを含むクライアントであって、前記１つ以上のプロセッサが、前記メモリに記憶された命令を実行することによって、サーバから３Ｄオブジェクトのカラー情報、アルファ情報及びジオメトリ情報を含む符号化されたストリームを受信し、前記ストリームを復号し、そこから前記カラー情報、前記アルファ情報及び前記ジオメトリ情報を抽出し、前記ジオメトリ情報に基づいて前記３Ｄオブジェクトの形状を再現し、前記再現された３Ｄオブジェクトの形状の上に、前記カラー情報と前記アルファ情報を合成した情報を投影することにより前記３Ｄオブジェクトを再構成する。

本開示の一態様によるプログラムは、上述のいずれかの方法をプロセッサによって実行するための命令を含む。

なお、これらの包括的又は具体的な態様は、システム、装置、方法、集積回路、コンピュータプログラム、又は、記録媒体で実現されてもよく、システム、装置、方法、集積回路、コンピュータプログラム及び記録媒体の任意な組み合わせで実現されてもよい。

クライアント上で３Ｄ画像を表示するためにサーバからクライアントへビデオデータ又はピクセルを送信する代わりに本開示によるコンテナストリームを送信することにより、サーバからクライアントへ送信される時間当たりのデータ量が減り、クライアント上での３Ｄ画像の表示品質及び応答性が向上する。

本開示の一実施例における更なる利点及び効果は、明細書及び図面から明らかにされる。かかる利点及び／又は効果は、いくつかの実施形態並びに明細書及び図面に記載された特徴によってそれぞれ提供されるが、１つ又はそれ以上の同一の特徴を得るために必ずしも全てが提供される必要はない。

本明細書において、説明の都合上サーバとクライアント間での３Ｄ画像（動画及び／又は静止画を含む）伝送を例に説明したが、本開示の適用は、クライアントサーバシステムに限定されず、１台のコンピュータから他のコンピュータへの伝送に適用可能であり、他のコンピュータは、単数であっても複数であってもよい。

本開示によるサーバ及びクライアントの機能ブロック図である。 図１で説明したサーバとクライアント間のデータの流れのうちサーバ側での処理を説明したフローチャートである。 図１で説明したサーバとクライアント間のデータの流れのうちクライアント側でデータの処理を説明したフローチャートである。 図１で説明したサーバとクライアント間のデータの流れのうちクライアント側でコマンドの処理を説明したフローチャートである。 本開示を適用したクライアントサーバシステムで、３Ｄシーン又は３Ｄオブジェクトをクライアント側で表示するためのデータの流れを記載した図である。 本開示によるジオメトリ情報の符号化及び復号のプロセスを示す図である。 本開示によるカラー情報／テクスチャ情報の符号化及び復号のプロセスを示す図である。 本開示によるジオメトリ、カラーパケット、メタデータ、及びコマンドの間のデータ同期を示す図である。 本開示によるデカール方法を示す図である。 本開示によるクライアントのハードウェア構成例を示す概略図である。 本開示によるサーバのハードウェア構成例を示す概略図である。 本開示にかかる情報処理システムの構成の一例を示す概略図である。 本開示によるサーバ側の処理のフローを表す概略図である。 本開示によるクライアント側の処理のフローを表す概略図である。 本開示に使用されるカメラの配置を表す図である。 本開示で使用されるＡＲＧＢシステムにおけるピクセル構成を示す図である。

＜１． ３Ｄストリーミング・システム・アーキテクチャ＞
図１は、本開示によるサーバ及びクライアントの機能ブロック図である。３Ｄストリーミングサーバ１００は、３次元（３Ｄ）ストリーミングサーバ内の機能構成を含み、３Ｄストリーミングクライアント１５０は、３Ｄストリーミングクライアント内の機能構成を含む。ネットワーク１２０は、サーバ１００とクライアント１５０との間にある有線又は無線のネットワークを表す。

本開示の対象となる１つのシステムは、サーバ側で３Ｄ画像を生成し、クライアント側でサーバから受信した３Ｄ画像の特徴量に基づいて３Ｄ画像を再構成し、表示する。クライアント機器としては、スマホ、携帯、タブレット、ノートパソコン、スマートグラス、ヘッドマウントディスプレイ、ヘッドセットなどの表示及び通信機能を有するあらゆる機器が対象となる。ここで、特徴量は、３Ｄ画像のカラー（色）情報、アルファ情報又はジオメトリ情報を含む。

＜１．２ ３Ｄストリーミングサーバ側の処理＞
図１の上半分は、３Ｄストリーミングサーバ１００での処理を説明する機能ブロック図である。ネットワークパケット受信ユニット１０８は、有線又は無線のネットワーク１２０を介して、クライアント１５０から命令及び／又はデータを含むパケットを受信する。ネットワークパケット受信ユニット１０８は、クライアントから受信した命令及び／又はデータをパケットから抽出し、クライアントからの命令及び／又はデータを処理する受信データ処理ユニット１０１に抽出したデータを送信する。抽出されたクライアントから命令及び／又はデータを受信した受信データ処理ユニット１０１は、受信したデータから必要な命令及び／又はデータをさらに抽出し、それらを３Ｄシーンデータ生成ユニット１０２に送る。次に、３Ｄシーンデータ生成ユニット１０２は、クライアント１５０から送られてきた要求にしたがって、サーバが有するそのクライアントからの要求に対応する３Ｄシーン（又は３Ｄオブジェクト）のデータを加工・修正などする。次に、３Ｄシーンデータ生成ユニット１０２から命令及び／又はデータを受け取った抽出ユニット１０３は、クライアントからの命令に従って更新した３Ｄシーンデータから必要なデータを抽出し、それらを３Ｄストリーム変換／符号化ユニット１０４へ送る。３Ｄストリーム変換／符号化ユニット１０４は、抽出ユニット１０３から受け取ったデータを３Ｄストリームに変換し、符号化することによって３Ｄストリーム１０５を生成する。３Ｄストリーム１０５は、次にネットワークパケット構成ユニット１０６に送られ、ネットワークパケット構成ユニット１０６によってネットワークパケットが生成される。ネットワークパケットは、ネットワークパケット伝送ユニット１０７へ送信される。ネットワークパケット伝送ユニット１０７は、受信したネットワークパケットを有線又は無線ネットワーク１２０を介して、１つ以上のクライアント１５０へ送信する。

＜１．３ ３Ｄストリーミングクライアント側の処理＞
図１の下半分は、３Ｄストリーミングクライアント１５０での処理を説明する機能ブロック図である。有線又は無線ネットワーク１２０を介してサーバ１００からパケットを受信したネットワークパケット受信ユニット１５２は、パケットから符号化された３Ｄストリームを抽出し、それを３Ｄストリーム復号ユニット１５４へ送る。符号化３Ｄストリームを受信した３Ｄストリーム復号ユニット１５４は、３Ｄストリームを復号し、復号された３Ｄストリームを３Ｄシーン再構成ユニット１５５へ送る。復号された３Ｄストリームを受信した３Ｄシーン再構成ユニット１５５は、サーバ１００から受信して復号された３Ｄストリームから３Ｄシーン（又は３Ｄオブジェクト）を再構成し、再構成された３Ｄシーンを表示ユニット１５６へ送る。表示ユニット１５６は、再構成された３Ｄシーンを表示し、ユーザに提示する。

一方、３Ｄストリーミングクライアント１５０からの３Ｄ表示（更新）要求は、アプリデータ出力ユニット１５３からネットワークパケット伝送ユニット１５１へ送られる。アプリデータ出力ユニット１５３で生成される３Ｄ表示（更新）要求データとしては、例えば、ユーザ入力又はカメラ／デバイスのポジション変更、又は表示の更新を要求するなどのコマンドが考えられる。３Ｄ表示要求を受信したネットワークパケット伝送ユニット１５１は、符号化及びパケット化などの必要な処理を行った３Ｄ表示（更新）要求を有線又は無線ネットワーク１２０を介して、３Ｄストリーミングサーバ１００に送る。

上述のサーバ１００に含まれるネットワークパケット構成ユニット１０６、及びネットワークパケット伝送ユニット１０７、上述のクライアント１５０に含まれるネットワークパケット受信ユニット１５２、及びネットワークパケット伝送ユニット１５１は、例えば、既存のオープンソースソフトウェアの対応する送受信モジュールに基づいて必要な改良を施してもよいし、一から専用に作成してもよい。

図２は、図１で説明したサーバとクライアント間のデータの流れのうちサーバ側での処理を説明したフローチャートである。スタート（９０１）で処理を開始する。先ず、図１で説明したネットワークパケット受信ユニット１０８が、クライアントから３Ｄシーンの書き換えコマンドなどを含むパケットを受信する（９０２）。次に、図１で説明した受信データ処理ユニット１０１が、受信したコマンドなどを処理して、その結果を出力する（９０３）。次に、図１で説明した３Ｄシーンデータ生成ユニット１０２が、受信したコマンドなどに従った３Ｄシーンデータを生成する（９０４）。次に、図１の抽出ユニット１０３が、３Ｄシーンの特徴量を抽出する（９０５）。ここで、特徴量とは、後述するコンテナストリームに含まれる、ジオメトリ、カラー、メタデータ、サウンド、コマンドなどのデータのことを指す。次に、図１の３Ｄストリーム変換／符号化ユニット１０４が、３Ｄ特徴量を含むデータを３Ｄストリームに変換し、符号化する（９０６）。次に、図１のネットワークパケット構成ユニット１０６が、３Ｄストリームからネットワークパケットを構成する（９０７）。次に、図１のネットワークパケット伝送ユニット１０７が、ネットワークパケットを送信する（９０８）。これでサーバ側の一連のデータ送信処理は、終了する（９０９）。

図２では、一例として、ステップ９０２から９０３までの処理とステップ９０４から９０８までの処理が逐次実行されるように記載されているが、ステップ９０２から９０３までの処理とステップ９０４から９０８までの処理が並行して実行されてもよいし、ステップ９０４の処理から開始されてもよい。

図３は、図１で説明したサーバとクライアント間のデータの流れのうちクライアント側でのデータの処理を説明したフローチャートである。スタート（１００１）で処理を開始する。先ず、図１で説明したネットワークパケット受信ユニット１５２が、サーバ１００から送られてきたパケットを受信する（１００２）。次に、図１で説明した３Ｄストリーム復号ユニット１５４が受信したパケットを復号し（１００３）、３Ｄシーンの特徴量を抽出する。次に、図１で説明した３Ｄシーン再構成ユニット１５５が、３Ｄシーンの特徴量などを使用して、クライアント上で３Ｄシーンを再構成し（１００４）、３Ｄシーンデータを生成する（１００５）。次に、図１で説明した表示ユニット１５６が、再構成された３Ｄシーンを表示して、ユーザに提示する（１００６）。これでクライアント側でのデータ処理は、終了する（１００７）。

図３では、一例として、ステップ１００２から１００４までの処理とステップ１００５から１００６までの処理が逐次実行されるように記載されているが、ステップ１００２から１００４までの処理とステップ１００５から１００６までの処理が並行して実行されてもよいし、ステップ１００５の処理から開始されてもよい。

図４は、図１で説明したサーバとクライアント間のデータの流れのうちクライアント側でコマンドの処理を説明したフローチャートである。スタート（１１０１）で処理を開始する。図１で説明したアプリデータ出力ユニット１５３が、画像処理アプリなどからの３Ｄシーンの書き換えコマンドなどを出力する（１１０２）。図１で説明したネットワークパケット伝送ユニット１５１は、アプリデータ出力ユニット１５３からコマンドなどを受け取り、パケットに変換し、変換したパケットを有線又は無線ネットワーク１２０へ伝送する（１１０３）。これでクライアント側でのデータ処理は、終了する（１１０４）。

図４では、一例として、ステップ１１０２の処理とステップ１１０３の処理が逐次実行されるように記載されているが、ステップ１１０２の処理とステップ１１０３の処理が並行して実行されてもよい。

＜２． 本開示の３Ｄストリームフォーマット＞
本開示による３Ｄストリームのフォーマットの特徴としては、主に以下のものがある。クライアント側で表示される３Ｄ画像の品質を落とさずに、限られたネットワークの帯域幅を使用して、これらを実現しているところに本開示の意義がある。

（１）サーバ側で３Ｄストリームを生成する。
サーバ側で３Ｄストリームを生成する際に、ＵＥ４又はＵｎｉｔｙなどの利用可能なエンジンを使用する。ここで、ＵＥとは、Ｅｐｉｃ Ｇａｍｅｓ社によって開発されているゲームエンジン、アンリアル・エンジン（Ｕｎｒｅａｌ Ｅｎｇｉｎｅ）のことであり、２０２０年５月にはＵＲ５がアナウンスされている。

（２）ネットワークを介した効率的な伝送がサポートされている。
従って、従来の方法に比べて、サーバからクライアントへ転送されるデータ量が少ない。これを実現するために、本開示では、コンテナストリームを使用する。

（３）様々なデバイスで動作可能である。
対象とする装置は、例えば、Ｕｎｉｔｙ（Ａｎｄｒｏｉｄ、Ｗｉｎｄｏｗｓ、ｉＯＳ）、ＷｅｂＧＬ、ＵＥ４又は５（Ａｎｄｒｏｉｄ、ｉＯＳ、Ｗｉｎｄｏｗｓ）が利用できる装置である。

（４）現代のＡＲ（拡張現実）デバイスに対して比較的軽量である。
すなわち、従来の方法と比べて、クライアント側での処理の負荷が小さい。これは、本開示のコンテナストリームの使用による。

（５）インタラクション（すなわち、双方向通信）をサポートする。
すなわち、ストリーミングがインタラクティブである。これは、コマンドがクライアントとサーバ相互間で送受信可能であることによる。

上述の特徴を実現するために、本開示はサーバとクライアント間で伝送する３Ｄストリームとして独自のコンテナストリームを開発した。この独自のコンテナストリームは、以下のような、ジオメトリ、カラー、メタデータ、サウンド、及びコマンドのうちのいくつかを含む。

（１）ジオメトリ：サーバ上での３Ｄシーンのストリーミングされたオブジェクトの外形に関する単純化された３Ｄデータである。ジオメトリのデータは、例えば、オブジェクトの形状を表すために使用されるポリゴンの頂点のアレイである。

（２）カラー：特定の位置にあるカメラで撮影したオブジェクトの色データである。

（３）メタデータ：３Ｄシーン、環境、個別のオブジェクト、ストリーム中のデータなどを説明するデータである。

（４）サウンド：サーバ側又はクライアント側の３Ｄシーンで発生するサウンド（音声）データである。サウンドは、サーバとクライアント相互間で双方向通信可能である。

（５）コマンド：コマンドは、サーバ側又はクライアント側の３Ｄシーン、システムイベント、ステータスメッセージ、カメラ及びユーザインプット、並びにクライアントのアプリケーションイベントなどを含む命令などである。コマンドは、サーバとクライアント相互間で双方向通信可能である。

従来のシステムでは、本開示による上述のコンテナストリームの代わりに、ビデオデータ自体又は各フレームのピクセルデータを送っていた。ここでコンテナストリームとは、サーバとクライアントとの間で転送されるデータの一塊のことを言い、データストリームとも言われる。コンテナストリームは、パケットストリームとしてネットワークを経由して転送される。

従来から使用されているこれらビデオデータ自体又は各フレームのピクセルデータは、たとえ圧縮されていたとしても、時間当たりの転送される容量が非常に大きく、サーバとクライアント間のネットワークの帯域幅が大きくないと伝送が遅れ、レイテンシが発生し、クライアント側での３Ｄ画像の再生がスムーズに行えないという問題点があった。一方、本開示のシステムで、サーバとクライアント間での転送で使用されるデータコンテナは、データサイズが従来のシステムよりも十分小さいので、サーバとクライアント間のネットワークの帯域幅を余り気にせずに、単位時間当たりのフレーム数を最低限確保できるので、クライアント側でのなめらか３Ｄ画像の再生が可能となる。

図５は、本開示を適用したクライアントサーバシステムで、３Ｄシーン又は３Ｄオブジェクトをクライアント側で表示するためのデータの流れを記載した図である。クライアント側は、スマホなどの端末装置１２２１が記載されており、端末装置１２２１とスマートグラス１２１０が無線ＬＡＮ又はブルートゥース（登録商標）などで無線通信又は有線通信１２２２を経由して接続されている。スマートグラス１２１０は、ユーザが手前側から見た図を表している。クライアントのスマートグラスの左眼には人１２１１－１とカーソル１２１２－１が投影されており、スマートグラスの右眼には人１２１１－２とカーソル１２１２－２が投影されている。スマートグラスのユーザには、右眼及び左眼の像が重なって立体的な人１２１４が少し離れたところに見えている。クライアント側のスマートグラス１２１０のユーザは、カーソル１２１２又は他の入力手段を使用して、クライアント側のスマートグラス１２１０中に表示された人１２１４に対して移動、回転、縮小・拡大、色（カラー）・テクスチャの変更、又はサウンドなどの操作を行うことができる。このようなクライアント上のオブジェクト（又はシーン）に対する操作が行われると、クライアントからサーバにネットワーク１２０経由でコマンド（又はサウンド）１２１３などが送信される。

クライアントからネットワーク１２０経由でコマンドなどを受信したサーバは、サーバ内のアプリ内の仮想的な画面１２０１上の対応する人１２０２の画像に対して、受信したコマンドなどに従った操作を行う。ここで、サーバは、通常表示装置を持っている必要がなく、仮想的な空間内の仮想的な画像を扱う。次に、サーバは、このコマンドなどの操作を行った後の３Ｄシーンデータ（又は３Ｄオブジェクトデータ）を生成し、そこから抽出した特徴量をコンテナストリーム１２０３としてネットワーク１２０経由でクライアントへ送信する。サーバから送られたコンテナストリーム１２０３を受信したクライアントは、コンテナストリーム１２０３に含まれるジオメトリ、カラー・テクスチャ、メタデータ、サウンド、及びコマンドに従って、クライアントの仮想画面中の対応する人１２１４のデータを書き換えて、再表示などする。この例において、オブジェクトは人であるが、オブジェクトは、ビル、自動車、動物、又は静物などの人以外でもよく、シーンは、１つ以上のオブジェクトを含む。

以下で図６～８を参照して、上述のコンテナストリームに含まれる「ジオメトリ」データと「カラー」データがどのように処理されるかを説明する。

＜３． ジオメトリの符号化及び復号プロセス＞
図６は、本開示による、ジオメトリデータの符号化及び復号のプロセスを示す図である。図６において、２０１～２０５の処理は、サーバによって行われ、２０７～２１１の処理は、クライアントによって行われる。

図６及び後述の図７及び８に記載の各処理は、ＣＰＵ及び／又はＧＰＵなどのプロセッサなどによって関連するプログラムを使用して実行される。本開示の対象となるシステムは、ＣＰＵ又はＧＰＵのいずれか一方のみを備えていてもよいが、以下では、説明の簡単化のため、ＣＰＵとＧＰＵをまとめてＣＰＵと記載する。

＜３．１ サーバ側の処理＞
ここでオブジェクトを有するシーンがあると仮定する。各オブジェクトは、１つ以上のデプスカメラで撮影されている。ここで、デプスカメラとは、奥行き情報を取得する深度（デプス）センサを内蔵したカメラのことを言う。デプスカメラを使用すると、通常のカメラが取得する２次元（２Ｄ）の画像に、奥行き情報を追加して、３Ｄの立体的な情報を取得することができる。ここでは、シーンの完全なジオメトリデータを取得するために、例えば６台のデプスカメラが使用される。撮影時のカメラの構成については、後述する。

サーバ側で撮影した画像からストリーム化３Ｄオブジェクトを生成し、カメラのデプス（深度）情報を出力する（２０１）。次に、カメラのデプス情報を処理して点群を生成し、点のアレイを出力する（２０２）。この点群は、オブジェクトの実際のジオメトリを表す三角形（三角形の頂点のアレイ）に変換され、三角形の群がサーバによって生成される（２０３）。ここでは、一例としてジオメトリを表す図形として三角形を使用したが、三角形以外の多角形を使用してもよい。

そして、三角形の群の各頂点のアレイのデータを使用してジオメトリデータをストリームに追加して、圧縮する（２０４）。

サーバは、圧縮されたジオメトリデータを含むコンテナストリームを、ネットワーク１２０を介して送信する（２０５）。

＜３．２ クライアント側の処理＞
クライアントは、サーバから送信された圧縮されたデータ、すなわちジオメトリデータを含むコンテナストリームを、ネットワーク１２０を介してサーバから受信する（２０７）。クライアントは、受信された圧縮されたデータを解凍し、頂点のアレイを抽出する（２０８）。

クライアントは、解凍されたデータの頂点のアレイを、管理されたジオメトリデータキューに入れ、ネットワーク経由で転送されている間に崩れたフレームシーケンスの順番を正しく整列させる（２０９）。クライアントは、正しく整列されたフレームシーケンスに基づいて、シーンのオブジェクトを再構成する（２１０）。クライアントは、再構成されたクライアント側の３Ｄオブジェクトをディスプレイに表示する（２１１）。

ジオメトリデータは、管理されたジオメトリデータキューに保存され、ストリーム中で受信した他のデータと同期される（２０９）。この同期については、図８を使って後述する。

本開示が適用されたクライアントは、受信した頂点のアレイに基づいてメッシュを生成する。言い換えれば、サーバからクライアントには、ジオメトリデータとして、頂点のアレイのみが送信されるので、通常、頂点のアレイの時間当たりのデータ量はビデオデータ及びフレームデータと比較してかなり少ない。一方、従来の他のオプションは、大量の三角形を所定のメッシュのデータに適用することであり、この方法はクライアント側での大量の処理を必要とするものであり、問題があった。

本開示が適用されるサーバは、シーン（通常は１つ以上のオブジェクトを含む）のうち変更が必要な部分（例えば、特定のオブジェクト）のデータをのみをクライアントへ送り、シーンのうち変更がない部分のデータをクライアントへ送らないので、この点でもシーン変更に伴うサーバからクライアントへの伝送データの量を削減することが可能となる。

本開示を適用したシステム及び方法では、ポリゴンメッシュの頂点のアレイをサーバからクライアントへ送信することを前提としている。そして、このポリゴンとして三角形のポリゴンを前提として説明したが、ポリゴンの形状は、三角形に限定されず四角形又は他の形状であってもよい。

＜４． カラー／テクスチャの符号化及び復号処理＞
図７は、本開示による、カラー情報／テクスチャ情報の符号化及び復号のプロセスを示す図である。図７において、３０１～３０３の処理は、サーバによって行われ、３０５～３０８の処理は、クライアントによって行われる。

＜４．１ カラーのサーバ側の処理＞
オブジェクトを有するシーンがあると仮定する。カメラからのビューを使用して、サーバは、シーンのカラーデータ、アルファデータ、及びデプスデータを抽出する（３０１）。ここで、アルファデータ（又はアルファ値）は、カラー情報とは別に、画素（ピクセル）ごとに設けられた付加情報を示す数値である。アルファデータは、特に透明度として利用されることが多い。また、アルファデータの集合は、アルファチャネルとも呼ばれる。

次に、サーバは、カラーデータ、アルファデータ、及びデプスデータのそれぞれをストリームに追加し、圧縮する（３０２－１、３０２―２、３０２－３）。サーバは、圧縮したカメラデータをコンテナストリームの一部として、ネットワーク１２０を経由してクライアントへ送信する（３０３）。

＜４．２ カラーのクライアント側の処理＞
クライアントは、ネットワーク１２０を経由して圧縮されたカメラデータ・ストリームを含むコンテナストリームを受信する（３０５）。クライアントは、フレームのセットを準備するのと同様に、受信したカメラデータを解凍する（３０６）。次に、クライアントは、解凍したカメラデータからビデオストリームのカラーデータ、アルファデータ、及びデプスデータをそれぞれ処理する（３０６－１、３０６－２、３０６－３）。ここで、これらの生の特徴量データは、再構成された３Ｄシーンに適用するために準備され、キューに入れられる。カラーデータは、テクスチャを有する再構成された３Ｄシーンのメッシュをラップ（ｗｒａｐ：包む）するために使用される。

また、デプスデータ及びアルファデータを有する追加の詳細情報が使用される。次に、クライアントは、ビデオストリームのカラーデータ、アルファデータ、及びデプスデータを同期させる（３０９）。クライアントは、同期したカラーデータ、アルファデータ、及びデプスデータをキューに保存し、カラーデータキューを管理する（３０７）。次に、クライアントは、カラー／テクスチャ情報をジオメトリへ投射する（３０８）。

図８は、本開示によるジオメトリパケット、カラーパケット、メタデータ、及びコマンドの間のデータ同期を示す図である。

クライアント側でデータを利用できるようにするためには、クライアント側で受信した３Ｄ画像を再生しながらストリーム中のデータの正しい内容を提供する方法でデータを管理する必要がある。ネットワークを経由するデータパケットは必ずしも信頼性の高い方法で転送されるわけではなく、パケットの遅延及び／又はパケットの順番の変更が発生する可能性がある。したがって、データのコンテナストリームをクライアントで受信している間、クライアントのシステムはどのようにデータの同期を管理するかを考える必要がある。本開示のジオメトリ、カラー、メタデータ、及びコマンドを同期するための基本的なスキームは、以下の通りである。このスキームは、ネットワーク・アプリケーションやストリーム用に作成されたデータ・フォーマットに対して標準的なものであってもよい。

図８を参照して、サーバ側から送信される３Ｄストリーム４１０は、ジオメトリパケット、カラーパケット、メタデータ、及びコマンドを含んでいる。３Ｄストリームに含まれるジオメトリパケット、カラーパケット、メタデータ、及びコマンドは、サーバ上で３Ｄストリームが作成された時点では、フレームシーケンス４１０に示されるように相互に同期が取れている。

このフレームシーケンス４１０において、時間は左から右に流れる。ところが、サーバから送信されたフレームシーケンス４１０が、クライアントで受信されたときには、ネットワークを経由する間に相互の同期が取れなくなる場合やランダムな遅延が発生する場合があり、そのことがクライアント側で受信された３Ｄストリーム４０１に示されている。すなわち、クライアントで受信された３Ｄストリーム４０１内では、ジオメトリパケット、カラーパケット、メタデータ、及びコマンドが、クライアントで作成されたときの３Ｄストリーム４１０とは、シーケンス内の順序又は位置が異なっている場所があることが分かる。

クライアントで受信された３Ｄストリーム４０１は、パケットキューマネージャ４０２によって本来の同期に戻るように処理され、フレームシーケンス４０３が生成される。パケットキューマネージャ４０２によって同期が復活され、且つ相互に異なる遅延が解消されたフレームシーケンス４０３では、ジオメトリパケット１、２、３が正しい順序・配置になり、カラーパケット１、２、３、４、５が正しい順序・配置になり、メタデータ１、２、３、４、５が正しい順序・配置になり、コマンド１、２が正しい順序・配置になる。すなわち、クライアント内で整列後のフレームシーケンス４０３は、サーバ内で作成されたフレームシーケンス４１０と同じ並びになる。

次に、同期された現在のフレームに対するデータを使用して、シーンが再構成される（４０４）。次に、再構成されたフレームをレンダリングし（４０５）、クライアントはシーンを表示装置上に表示する（４０６）。

図９は、シーケンス更新フロー５００の例を示す。図９では、時間は左から右に進んでいく。図９を参照して、先ずジオメトリが更新される（５０１）。ここでは、それと同期して（すなわち、横方向の位置が一致して）カラー／テクスチャが更新される（５０５）。次に、カラー／テクスチャが更新される（５０６）が、ジオメトリは、更新されない（例えば、カラーは変わったが、動きがない場合）。次に、ジオメトリが更新され（５０２）、それと同期してカラー／テクスチャが更新される（５０７）。次に、カラー／テクスチャが更新される（５０８）が、ジオメトリは、更新されない。次に、ジオメトリが更新され（５０３）、それと同期してカラー／テクスチャが更新される（５０９）。

図９から分かる通り、カラー／テクスチャが更新される度に、ジオメトリが更新される必要はなく、逆に、ジオメトリが更新される度に、カラー／テクスチャが更新される必要もない。ジオメトリの更新とカラー／テクスチャの更新とが同期してもよい。また、カラー／テクスチャの更新は、必ずしもカラー及びテクスチャが更新される必要はなく、カラー又はテクスチャのいずれか一方の更新であってもよい。この図では、カラー／テクスチャ更新が２回に対して、ジオメトリ更新が１回の頻度で記載されているが、これは一例であって、他の頻度であってもよい。

図１０は、本開示によるクライアントのハードウェア構成例を示す概略図である。クライアント１５０は、スマホや携帯電話などの端末であってもよい。クライアント１５０は、ＣＰＵ／ＧＰＵ６０１と、表示部６０２と、入出力部６０３と、メモリ６０４と、ネットワークインタフェース６０５と、記憶装置６０６を通常備えており、これらの構成要素は、バス６０７で相互に通信可能に接続されている。

ＣＰＵ／ＧＰＵ６０１は、ＣＰＵ単体又はＧＰＵ単体であってもよいし、ＣＰＵとＧＰＵが協働して動作するようになっている１つ又は複数の部品から構成されてもよい。表示部６０２は、通常カラーで画像を表示するための装置であり、本開示による３Ｄ画像を表示し、ユーザに提示する。図５を参照して、上述したように、クライアントは、クライアント端末とスマートグラスの組合せでもよく、その場合は、スマートグラスが表示部６０２の機能を有する。

入出力部６０３は、ユーザなどの外部とのインタラクションを行うための装置であり、クライアント１５０の内部又は外部にあるキーボード、スピーカー、ボタン、タッチパネルに接続されてもよい。メモリ６０４は、ＣＰＵ／ＧＰＵ６０１の動作に必要なソフトウェア及びデータを記憶するための揮発性メモリである。ネットワークインタフェース６０５は、クライアント１５０が外部のネットワークに接続し、通信するための機能を有する。記憶装置６０６は、クライアント１５０で必要なソフトウェア、ファームウェア、データなどを記憶するための不揮発性メモリである。

図１１は、本開示によるサーバのハードウェア構成例を示す概略図である。サーバ１００は、通常は、クライアントより高機能なＣＰＵを備え、通信速度も速く、より大容量の記憶装置を備える。サーバ１００は、ＣＰＵ／ＧＰＵ７０１と、入出力部７０３と、メモリ７０４と、ネットワークインタフェース７０５と、記憶装置７０６を通常備えており、これらの構成要素は、バス７０７で相互に通信可能に接続されている。

ＣＰＵ／ＧＰＵ７０１は、ＣＰＵ単体又はＧＰＵ単体であってもよいし、ＣＰＵとＧＰＵが協働して動作するようになっている１つ又は複数の部品から構成されてもよい。図１０に記載のクライアント装置は、表示部６０２を備えていたが、サーバの場合は、表示部は必須ではない。入出力部７０３は、ユーザなどとのインタラクションを行うための装置であり、キーボード、スピーカー、ボタン、タッチパネルに接続されてもよい。メモリ７０４は、ＣＰＵ／ＧＰＵ７０１の動作に必要なソフトウェア及びデータを記憶するための揮発性メモリである。ネットワークインタフェース７０５は、クライアントが外部のネットワークに接続し、通信するための機能を有する。記憶装置７０６は、クライアントで必要なソフトウェア、ファームウェア、データなどを記憶するための不揮発性記憶装置である。

図１２は、本開示にかかる情報処理システムの構成の一例を示す概略図である。サーバ１００と、クライアント１５０－１と、クライアント１５０－２とがネットワーク１２０によって互いに通信可能に接続されている。

サーバ１００は、例えば、サーバなどのコンピュータ装置であり、クライアント１５０－１とクライアント１５０－２からの画像表示要求などに応じて、動作して、クライアント１５０－１とクライアント１５０－２で表示するための画像に関連する情報を生成し、送信する。この例では、クライアントは２台記載されているが、１台以上であれば何台でもよい。

ネットワーク１２０は、有線又は無線のＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）であってもよく、クライアント１５０－１とクライアント１５０－２は、スマホ、携帯電話、スレートＰＣ、又はゲーム端末などであってもよい。

図１３は、本開示によるサーバ側の処理のフローを表す概略図である。サーバ側のシーン１３０１にあるオブジェクト１３０２から、ＲＧＢカメラを使用してカラー情報（１３０３）を抽出する（１３１０）。サーバ側のシーン１３０１にあるオブジェクト１３０２から、ＲＧＢカメラを使用してアルファ情報（１３０４）を抽出する（１３２０）。サーバ側のシーン１３０１にあるオブジェクト１３２０から、デプスカメラを使用して点群（１３０５）の情報を抽出する（１３３０）。次に、点群（１３０５）の情報を簡略化して、ジオメトリ情報（１３０６）を得る（１３３１）。

次に、得られたカラー情報（１３０３）、アルファ情報（１３０４）及びジオメトリ情報（１３０６）は、ストリームデータフォーマットへ処理され（１３０７）、３Ｄストリームのコンテナストリームとしてネットワークを経由してクライアントへ送信される（１３４０）。

図１４は、本開示によるクライアント側の処理のフローを表す概略図である。図１４は、本開示によるデカール方法に関連する。ここで、デカールとは、オブジェクト上にテクスチャやマテリアルを貼り付ける処理である。ここで、テクスチャとは、３Ｄ（３次元）ＣＧモデルの質感、模様、凹凸などを表現するために用いるデータなどのことを指す。また、マテリアルとは、オブジェクトの材質などのことであり、３ＤＣＧでは、例えば、物体の光学的特性、材質感のことを指す。

本開示のデカール方法が、従来のＵＶマッピングよりもプロセッサの処理として軽い理由を以下で説明する。現時点で、メッシュに色を設定するにはいくつかの方法がある。ここで、ＵＶとは、３ＤＣＧモデルにテクスチャをマッピングするとき、貼り付ける位置や方向、大きさなどを指定するために使う座標系のことである。２次元の直交座標系で、横方向の軸がＵ、縦方向の軸がＶとなる。ＵＶ座標系を使ったテクスチャマッピングのことをＵＶマッピングとよぶ。

＜５．１ 各頂点に色を設定する方法（従来の方法１）＞
対象となるクラウド内のすべての三角形に対して、色の値を頂点に保存する。しかしながら、頂点の密度が低い場合、解像度の低いテクスチャリングとなり、ユーザ・エクスペリエンスが低下する。逆に、頂点の密度が高い場合、画面上のすべてのピクセルに色を送るのと同じことになり、サーバからクライアントへ転送するデータ量が増える。一方、これは追加／基本カラーリングのステップとして使用することができる。

＜５．２ メッシュのＵＶに正しいテクスチャを設定する方法（従来の方法２）＞
正しいテクスチャをＵＶマッピングで設定するには、三角形の群のテクスチャを生成する必要がある。その後、現在のメッシュのＵＶマップを生成し、ストリームに追加する必要がある。モデルのオリジナルテクスチャは、シーンの雷などの情報が含まれておらず、高品質で詳細な３Ｄモデルのためには、大量のテクスチャが必要になるため、実質的に使用できない。この方法が採用されないもう一つの理由は、サーバ上でレンダリングされた３Ｄモデルで作成されたＵＶでオリジナルテクスチャが動作することである。一般的には、三角形の群を使い、異なるビューからカラーリングテクスチャを投影し、受信したＵＶテクスチャを保存して送信する。さらに、ＵＶテクスチャと同じ頻度でメッシュのジオメトリやトポロジーを更新する必要があるため、サーバとクライアント間で送受信するデータ量が増える。

＜５．３ メッシュにテクスチャを投影する（デカール）方法（本開示による方法）＞
ストリームの特定の位置からのカラー／テクスチャが、その位置に関するメタ情報とともにサーバからクライアントに送信される。クライアントは、このテクスチャを指定された位置からメッシュに投影する。この場合、ＵＶマップは不要である。この方法では、ストリーミングされた側（すなわち、クライアント側）にはＵＶ生成がロードされない。このデカールによるアプローチは、データフローの最適化の余地を提供できる（例えば、ジオメトリとカラーの更新は、異なる頻度で連続して行うことができる）。

図１４に記載のクライアント側の処理は、基本的に、図１３に記載のサーバ側の処理と逆の処理を行う。先ず、クライアントは、ネットワークを介してサーバが送信した３Ｄストリームであるコンテナストリームを受信する。次に、受信した３Ｄストリームからデータを復号し、オブジェクトを再構成するために、カラー情報、アルファ情報、ジオメトリ情報を復元する（１４１０）。

次に、先ず、カラー情報１４３１とアルファ情報１４３２が結合され、その結果としてテクスチャデータ生成される。次に、このテクスチャデータをジオメトリデータ１４３３に適用する（１４２０）。こうすることによって、サーバ上にあったオブジェクトがクライアント上で再構成される（１４４０）。サーバ側のシーンに複数のオブジェクトがある場合は、オブジェクト毎にこのような処理を適用する。

図１５は、本開示に使用されるカメラの配置を表す図である。対象となるシーン１５１０にあるオブジェクトのジオメトリ情報を取得するためには、１台以上のデプスカメラが使用される。デプスカメラは、毎フレーム、デプスマップを取得し、次に、これらのデプスマップは、点群に処理される。次に、点群は、単純化のため所定の三角形のメッシュに分割される。デプスカメラの解像度を変更することによって、三角形に分割されたメッシュの詳細度（細かさのレベル、粒度）を制御することが可能である。例えば、想定する標準的な設定では、２５６×２５６解像度の６台のデプスカメラを使用する（１５２１～１５２６）。しかしながら、必要なデプスカメラの台数と各カメラの解像度は、さらに最適化して、減らすことも可能であり、デプスカメラの台数及びその解像度によって、パフォーマンス、すなわち画質及び伝送データ量が変化する。

図１５には、一例として、６台のデプスカメラ（１５２１～１５２６）と１台の通常のカメラ（１５３０）を配置した構成が記載されている。通常のカメラ（すなわちＲＧＢカメラ）（１５３０）は、対象となるシーン１５１０にあるオブジェクトのカラー情報及びアルファ情報を取得するために使用される。

図１６は、本開示で使用されるＡＲＧＢシステムにおけるピクセル構成を示す図である。ＡＲＧＢシステムは、従来のＲＧＢ（赤、緑、青）の色情報に、透明度を表すアルファ情報（Ａ）を追加したものである。図１６に示した例では、アルファ、青、緑、赤のそれぞれが、８ビット（すなわち、２５６段階）で示され、すなわち、ＡＲＧＢ全体で、３２ビットの構成となっている。図１６の１６０１が各色又はアルファのビット数を示し、１６０２がそれぞれの色又はアルファを示し、１６０３は、全体として３２ビットの構成を示している。この例では、各色及びアルファが８ビット構成で、全体として３２ビットのＡＲＧＢシステムを説明しているが、これらのビット数は、所望の画質及び伝送データ量に従って、変更することができる。

アルファ情報は、カラーイメージに対して、マスク／セカンダリレイヤとして、使用することができる。現在のハードウェアエンコーダの制約により、アルファ情報を持つカラー情報に対してビデオストリームを符号化することは時間が掛かる。また、ビデオストリームに対するカラー及びアルファのソフトウェアエンコーダは、リアルタイムで符号化できず遅延が発生し、本開示の目的を達成できないので、現時点では本開示の代替案とはなり得ない。

＜６．１ 本開示による３Ｄストリーム・シーンのジオメトリの再構成の利点＞
本開示の方法を用いた３Ｄストリーム・シーンのジオメトリ再構成の利点は以下の通りである。本開示の方法は、「三角形の群（ｃｌｏｕｄ ｏｆ ｔｒｉａｎｇｌｅｓ）」を用いてシーンを再構成することによって、クライアント側で各シーンを再構成する。この革新的なアイデアの重要な点は、クライアント側で大量の三角形を使用する準備ができていることである。この場合、三角形の群に含まれる三角形の数は、数十万個でもよい。

クライアントは、ストリームから情報を取得するとすぐに３Ｄシーンの形状を作るために各三角形を適切な場所に配置する準備ができている。本開示の方法では、サーバからクライアントに、従来よりも少ないデータしか転送しないので、この方法の利点は、処理に必要な電力と時間を削減できることである。フレーム毎にメッシュを生成するという従来の方法ではなく、既存のジオメトリの位置を変更する。しかしながら、既存のジオメトリの位置を変更することで、シーン内で一度生成された三角形の群の位置を変更することができる。したがって、ジオメトリデータは、各三角形の座標を提供し、オブジェクトのこの位置の変更は、動的である。

＜６．２ 本開示による３Ｄストリーミングの利点＞
本開示の３Ｄストリーミングの利点は、６つの自由度（ＤｏＦ：Ｄｅｇｒｅｅ ｏｆ Ｆｒｅｅｄｏｍ）でもネットワークの遅延がより少ないことである。３Ｄストリーミング・フォーマットの利点の一つは、クライアント側にも３Ｄシーンがあることである。ミックス・リアリティ（ＭＲ）でナビゲートし、又は画像内を見て回るとき、重要な部分は、どのように３Ｄコンテンツが現実世界と接続されているか、そしてどのように「それに実際の位置が感じられる」である。言い換えれば、ユーザがいくつかの表示されたオブジェクトの周りを回っているときに、デバイスによる位置更新の遅れを認識しない場合、人間の脳はこのオブジェクトが本当にその場所にあると錯覚する。

現在、クライアント側のデバイスは７０～９０ＦＰＳ（１秒当たりのフレーム数）を目標にして、ユーザにこれを「本物」と思わせるために、ディスプレイ上の３Ｄコンテンツを更新する。今日では、１２ｍｓ以下の待ち時間で、リモートサーバー上でフレーム更新のフルサイクルを提供することは不可能である。実際、ＡＲデバイスのセンサは、１，０００ＦＰＳ以上の情報を提供している。そして、クライアント側で３Ｄコンテンツを同期させることは、現代のデバイスではすでに可能なので、本開示の方法では、クライアント側で３Ｄコンテンツを同期させることができる。そのため、３Ｄシーンを再構成した後、クライアント側で拡張コンテンツの位置情報を処理するのはクライアント側の仕事であり、リアリティに影響を与えないような合理的なネットワーク上の問題（例えば、伝送遅延）があれば、それを解決することができる。

＜本開示のまとめ＞
以下に本開示のまとめとしていくつかの実施例を付記する。

サーバからクライアントへ、３Ｄオブジェクトを送信する方法であって、前記サーバ上の前記３Ｄオブジェクトからカラー情報、アルファ情報及びジオメトリ情報を抽出することと、前記ジオメトリ情報を単純化することと、前記サーバから前記クライアントへ、前記カラー情報、前記アルファ情報及び前記単純化されたジオメトリ情報を含むストリームを符号化して送信することと、を含む、本開示による方法。

前記ジオメトリ情報を単純化することは、前記３Ｄオブジェクトから抽出された点群から三角形の頂点の情報に変換することである、本開示による方法。

前記ストリームは、さらに、メタデータ、サウンドデータ、及びコマンドのうちの少なくとも１つを含む、本開示による方法。

前記サーバが、前記クライアントから、前記サーバ上の３Ｄオブジェクトを書き換えるコマンドを受信する、本開示による方法。

前記サーバが前記クライアントから３Ｄオブジェクトを書き換えるコマンドを受信した場合、前記サーバは前記サーバ上の３Ｄオブジェクトを書き換え、前記書き換えた３Ｄオブジェクトから前記カラー情報、前記アルファ情報及び前記ジオメトリ情報を抽出し、前記ジオメトリ情報を単純化し、前記サーバから前記クライアントへ前記カラー情報、前記アルファ情報及び前記単純化されたジオメトリ情報を含むストリームを符号化して送信する、本開示による方法。

前記カラー情報及び前記アルファ情報は、ＲＧＢカメラで取得され、前記ジオメトリ情報は、デプスカメラで取得される、本開示による方法。

サーバ上にある３Ｄオブジェクトをクライアント上で再現する方法であって、前記サーバから前記３Ｄオブジェクトのカラー情報、アルファ情報及びジオメトリ情報を含む符号化されたストリームを受信することと、前記ストリームを復号し、そこから前記カラー情報、前記アルファ情報及び前記ジオメトリ情報を抽出することと、前記ジオメトリ情報に基づいて前記３Ｄオブジェクトの形状を再現することと、前記再現された３Ｄオブジェクトの形状の上に、前記カラー情報と前記アルファ情報を合成した情報を投影することにより前記３Ｄオブジェクトを再構成することと、を含む、本開示による方法。

前記再構成された３Ｄオブジェクトを表示装置上に表示する、本開示による方法。

前記表示装置がスマートグラスである、本開示による方法。

１つ以上のプロセッサ及びメモリを含むサーバであって、前記１つ以上のプロセッサが、前記メモリに記憶された命令を実行することによって、前記サーバ上の３Ｄオブジェクトからアルファ情報及びジオメトリ情報を抽出し、前記ジオメトリ情報を単純化し、前記サーバからクライアントへ、前記アルファ情報及び前記単純化されたジオメトリ情報を含むストリームを符号化して送信する、本開示によるサーバ。

１つ以上のプロセッサ及びメモリを含むクライアントであって、前記１つ以上のプロセッサが、前記メモリに記憶された命令を実行することによって、サーバから３Ｄオブジェクトのカラー情報、アルファ情報及びジオメトリ情報を含む符号化されたストリームを受信し、前記ストリームを復号し、そこから前記カラー情報、前記アルファ情報及び前記ジオメトリ情報を抽出し、前記ジオメトリ情報に基づいて前記３Ｄオブジェクトの形状を再現し、前記再現された３Ｄオブジェクトの形状の上に、前記カラー情報と前記アルファ情報を合成した情報を投影することにより前記３Ｄオブジェクトを再構成する、本開示によるクライアント。

本開示よる前記方法をプロセッサによって実行するための命令を含む、プログラム。

本開示はソフトウェア、ハードウェア、又は、ハードウェアと連携したソフトウェアで実現することが可能である。

本開示は、ソフトウェア、プログラム、システム、装置、クライアントサーバシステム、端末などに適用可能である。

１００ サーバ
１０１ 受信データ処理ユニット
１０２ ３Ｄシーンデータ生成ユニット
１０３ 抽出ユニット
１０４ ３Ｄストリーム変換／符号化ユニット
１０５ ３Ｄストリーム
１０６ ネットワークパケット構成ユニット
１０７ ネットワークパケット伝送ユニット
１０８ ネットワークパケット受信ユニット
１２０ 有線又は無線ネットワーク
１５０ クライアント
１５０－１ クライアント
１５０－２ クライアント
１５１ ネットワークパケット伝送ユニット
１５２ ネットワークパケット受信ユニット
１５３ アプリデータ出力ユニット
１５４ ３Ｄストリーム復号ユニット
１５５ ３Ｄシーン再構成ユニット
１５６ 表示ユニット
６０２ 表示部
６０３ 入出力部
６０４ メモリ
６０５ ネットワークインタフェース
６０６ 記憶装置
６０７ バス
７０３ 入出力部
７０４ メモリ
７０５ ネットワークインタフェース
７０６ 記憶装置
７０７ バス
１２０１ 画面
１２０２ 人
１２０３ コンテナストリーム
１２１０ スマートグラス
１２１１－１ 人
１２１１－２ 人
１２１２－１ カーソル
１２１２－２ カーソル
１２１３ コマンド
１２１４ 人
１２２１ 端末装置
１５２１～１５２６ デプスカメラ
１５３０ ＲＧＢカメラ

（１）サーバ側で３Ｄストリームを生成する。
サーバ側で３Ｄストリームを生成する際に、ＵＥ４又はＵｎｉｔｙなどの利用可能なエンジンを使用する。ここで、ＵＥとは、Ｅｐｉｃ Ｇａｍｅｓ社によって開発されているゲームエンジン、アンリアル・エンジン（Ｕｎｒｅａｌ Ｅｎｇｉｎｅ）のことであり、２０２０年５月にはＵＥ５がアナウンスされている。

Claims (12)

1. サーバからクライアントへ、３Ｄオブジェクトを送信する方法であって、
   前記サーバ上の前記３Ｄオブジェクトからカラー情報、アルファ情報及びジオメトリ情報を抽出することと、
   前記ジオメトリ情報を単純化することと、
   前記サーバから前記クライアントへ、前記カラー情報、前記アルファ情報及び前記単純化されたジオメトリ情報を含むストリームを符号化して送信することと、
   を含む、方法。
2. 前記ジオメトリ情報を単純化することは、前記３Ｄオブジェクトから抽出された点群から三角形の頂点の情報に変換することである、請求項１に記載の方法。
3. 前記ストリームは、さらに、メタデータ、サウンドデータ、及びコマンドのうちの少なくとも１つを含む、請求項１又は２に記載の方法。
4. 前記サーバが、前記クライアントから、前記サーバ上の３Ｄオブジェクトを書き換えるコマンドを受信する、請求項１乃至３のいずれか１項に記載の方法。
5. 前記サーバが前記クライアントから３Ｄオブジェクトを書き換えるコマンドを受信した場合、前記サーバは前記サーバ上の３Ｄオブジェクトを書き換え、前記書き換えた３Ｄオブジェクトから前記カラー情報、前記アルファ情報及び前記ジオメトリ情報を抽出し、前記ジオメトリ情報を単純化し、前記サーバから前記クライアントへ前記カラー情報、前記アルファ情報及び前記単純化されたジオメトリ情報を含むストリームを符号化して送信する、請求項１乃至４のいずれか１項に記載の方法。
6. 前記カラー情報及び前記アルファ情報は、ＲＧＢカメラで取得され、前記ジオメトリ情報は、デプスカメラで取得される、請求項１乃至５のいずれか１項記載の方法。
7. サーバ上にある３Ｄオブジェクトをクライアント上で再現する方法であって、
   前記サーバから前記３Ｄオブジェクトのカラー情報、アルファ情報及びジオメトリ情報を含む符号化されたストリームを受信することと、
   前記ストリームを復号し、そこから前記カラー情報、前記アルファ情報及び前記ジオメトリ情報を抽出することと、
   前記ジオメトリ情報に基づいて前記３Ｄオブジェクトの形状を再現することと、
   前記再現された３Ｄオブジェクトの形状の上に、前記カラー情報と前記アルファ情報を合成した情報を投影することにより前記３Ｄオブジェクトを再構成することと、
   を含む、方法。
8. 前記再構成された３Ｄオブジェクトを表示装置上に表示する、請求項７に記載の方法。
9. 前記表示装置がスマートグラスである、請求項８に記載の方法。
10. １つ以上のプロセッサ及びメモリを含むサーバであって、
    前記１つ以上のプロセッサが、前記メモリに記憶された命令を実行することによって、
    前記サーバ上の３Ｄオブジェクトからアルファ情報及びジオメトリ情報を抽出し、
    前記ジオメトリ情報を単純化し、
    前記サーバからクライアントへ、前記アルファ情報及び前記単純化されたジオメトリ情報を含むストリームを符号化して送信する、サーバ。
11. １つ以上のプロセッサ及びメモリを含むクライアントであって、
    前記１つ以上のプロセッサが、前記メモリに記憶された命令を実行することによって、
    サーバから３Ｄオブジェクトのカラー情報、アルファ情報及びジオメトリ情報を含む符号化されたストリームを受信し、
    前記ストリームを復号し、そこから前記カラー情報、前記アルファ情報及び前記ジオメトリ情報を抽出し、
    前記ジオメトリ情報に基づいて前記３Ｄオブジェクトの形状を再現し、
    前記再現された３Ｄオブジェクトの形状の上に、前記カラー情報と前記アルファ情報を合成した情報を投影することにより前記３Ｄオブジェクトを再構成する、クライアント。
12. 請求項１乃至９に記載のいずれかの方法をプロセッサによって実行するための命令を含む、プログラム。

Images