本開示の以下の実施態様は、ヘッドマウントディスプレイ(HMD)用の予測的RFビーム形成に関するデバイス、方法、及びシステムを提供する。
様々な実施態様において、方法、システム、画像撮影オブジェクト、センサ、及び関連するインターフェースオブジェクト(たとえば、グローブ、コントローラ、周辺デバイスなど)は、ディスプレイ画面上に実質的にリアルタイムにレンダリングされるように構成されるデータを処理するように構成される。このディスプレイは、ヘッドマウントディスプレイ(HMD)のディスプレイ、セカンドスクリーンのディスプレイ、ポータブルデバイスのディスプレイ、コンピュータディスプレイ、ディスプレイパネル、1人または複数人のリモート接続されたユーザ(たとえば、対話体験においてコンテンツを視聴または共有し得る人々)のディスプレイなどであり得る。
しかしながら、本開示がこれらの具体的な詳細の一部または全部がなくても実施され得ることは当業者には明らかであろう。他の例では、本開示を不必要に不明瞭にしないように、よく知られている処理動作については詳細に説明していない。
図1に、本開示の一実施態様による、ヘッドマウントディスプレイ(HMD)を介して仮想環境と対話するためのシステムを示す。ヘッドマウントディスプレイ(HMD)102を装着したユーザ100が示されている。HMD102は眼鏡、ゴーグル、またはヘルメットと同じように着用され、ビデオゲームまたは他のコンテンツをユーザ100に表示するように構成される。HMD102はユーザの目のすぐ近くに表示機構を設けることによって、非常に没入感のある体験をユーザに提供する。このようにして、HMD102はユーザの視野の大部分または全体さえも占有する表示領域を、ユーザのそれぞれの目に対して設けることができる。
図示の実施態様では、HMD102はコンピュータ106に無線で接続される。コンピュータ106は当技術分野で知られている任意の汎用または専用コンピュータ、たとえば、限定はしないが、ゲームコンソール、パーソナルコンピュータ、ラップトップ、タブレットコンピュータ、モバイルデバイス、携帯電話、タブレット、シンクライアント、セットトップボックス、メディアストリーミングデバイスとすることができる。一実施態様では、コンピュータ106はビデオゲームを実行し、HMD102によりレンダリングされるビデオゲームのビデオ及び音声を出力するように構成することができる。送受信機110はビデオゲームのビデオ及び音声をHMD102に無線送信して、その上にレンダリングできるようにするように構成される。送受信機110は、HMD102へのデータの無線送信のための送信機と、HMD102によって無線送信されたデータを受信するための受信機とを含む。
いくつかの実施態様では、HMD102は代替の機構またはチャネルを介して、たとえば、HMD102とコンピュータ106との両方が接続されたネットワーク112を介して、コンピュータと通信し得る。
ユーザ100は、ビデオゲームに入力を提供するためのインターフェースオブジェクト104を操作し得る。加えて、カメラ108はユーザ100が位置する対話型環境の画像を撮影するように構成することができる。これらの撮影画像を分析して、ユーザ100、HMD102、及びインターフェースオブジェクト104の位置及び動きを決定することができる。様々な実施態様において、インターフェースオブジェクト104は、インターフェースオブジェクトの位置及び向きを決定できるようにするための、追跡可能なライト及び/または慣性センサ(複数可)を含む。
ユーザがHMD102に表示された仮想現実シーンとインターフェースをとる方法は異なることができ、インターフェースオブジェクト104に加えて他のインターフェースデバイスを使用することができる。たとえば、様々な種類の片手用ならびに両手用コントローラを使用することができる。いくつかの実施態様では、コントローラに関連付けられたライトを追跡するか、またはコントローラに関連する形状、センサ、及び慣性データを追跡することによって、コントローラはそれだけで追跡することができる。これらの様々な種類のコントローラ、さらには単純に、実施され1つまたは複数のカメラによってキャプチャされるハンドジェスチャを使用することによって、HMD102上に提示される仮想現実環境とインターフェースをとり、制御し、操作し、対話し、参加することが可能になる。
加えて、HMD102は、HMD102の位置及び向きを決定するために追跡することが可能な1つまたは複数のライトを含み得る。カメラ108は、対話型環境から音をキャプチャするための1つまたは複数のマイクロフォンを含むことができる。マイクロフォンアレイによってキャプチャされた音は、音源の位置を特定するために処理され得る。特定された位置からの音を選択的に利用または処理して、特定された位置からではない他の音を排除することができる。さらに、カメラ108は、複数の画像撮影デバイス(たとえば、カメラのステレオペア)、IRカメラ、深度カメラ、及びそれらの組み合わせを含むように定義することができる。
他の実施態様では、コンピュータ106は、ネットワーク112を介してクラウドゲームプロバイダ114と通信するシンクライアントとして機能する。そのような実施態様では、一般的に言えば、クラウドゲームプロバイダ114は、ユーザ102によってプレイされているビデオゲームを維持し実行する。コンピュータ106は、HMD102、指向性インターフェースオブジェクト104、及びカメラ108からの入力をクラウドゲームプロバイダに送信し、クラウドゲームプロバイダは入力を処理して実行中のビデオゲームのゲーム状態に影響を及ぼす。実行中のビデオゲームからの出力、たとえば、ビデオデータ、音声データ、及び触覚フィードバックデータは、コンピュータ106に送信される。コンピュータ106は送信前にデータをさらに処理し得、またはデータを関連するデバイスに直接送信し得る。たとえば、ビデオストリーム及び音声ストリームはHMD102に提供され、振動フィードバックコマンドはインターフェースオブジェクト104に提供される。
いくつかの実施態様では、HMD102、インターフェースオブジェクト104、及びカメラ108は、それら自体が、たとえばクラウドゲームプロバイダ114と通信するためにネットワーク112に接続されるネットワークデバイスであり得る。いくつかの実施態様では、コンピュータ106は、ビデオゲーム処理を別段実行せず、ネットワークトラフィックの通過を円滑化する、ルータなどのローカルネットワークデバイスであり得る。HMD102、インターフェースオブジェクト104、及びカメラ108によるネットワークへの接続は、有線または無線であり得る。
加えて、本開示における実施態様はヘッドマウントディスプレイを参照して説明する場合があるが、他の実施態様では、非ヘッドマウントディスプレイ、たとえば、限定はしないが、ポータブルデバイススクリーン(たとえば、タブレット、スマートフォン、ラップトップなど)、あるいは本実施態様による対話型シーンまたは仮想環境のビデオをレンダリングし、及び/またはその表示を提供するように構成することができる他の任意の種類のディスプレイに置き換えられ得ることは理解されよう。
仮想環境の視聴時に高品質のユーザ体験を提供するためにHMDに送信されなければならない、特にビデオデータ(たとえば、画像データ及び音声データを含む)の形態のデータ量は非常に大きい。この理由で、現在のHMD技術では、ビデオデータを生成するコンピュータとHMDとの間の有線接続が必要となる。しかしながら、上述のように、HMDへの有線接続はユーザの動きの自由を損ね、HMDを介して非常に効果的にレンダリングすることが可能な本来の没入体験を低下させる。
高品質の体験に必要なデータ量を確実に伝送することが可能な無線接続を提供するには、広いデータ帯域幅のために高い信号対雑音比を提供しつつ、ユーザの動きに応じてHMDが動く場合のHMDへの高い接続安定性を維持することに関する問題を克服する必要がある。これを実現するために、本開示の実施態様は、予測的ビーム形成を使用したHMDへの無線データ送信を提供する。すなわち、いくつかの実施態様では、HMDの追跡された動きを分析してHMDの将来位置を予測し、ビーム形成を使用してRF信号をHMDの予測将来位置の方へ予測的に誘導する。これにより、HMDの位置をより良く追跡するように予期してRF信号を誘導することによって、RF信号強度が維持される。
本開示における説明を容易にする目的で、HMDの実際の位置または予測位置を、RF信号が向けられるべき現実世界空間内の位置として参照する。しかしながら、HMDの位置はより具体的には、HMD上の、内部の、または相対的な特定の位置、たとえば、HMDの一部である受信機アンテナの位置、HMDのディスプレイ部分の位置、HMDの中心などを指す場合があることを理解されたい。
引き続き図1を参照すると、本開示の実施態様による、HMDへのデータ送信のための予測的ビーム形成のための手順の概要が示されている。HMD102の位置は任意の種々の技術を使用して追跡できることを理解されたい。図示の実施態様では、HMD102は、HMDの1つまたは複数の慣性センサから生成された慣性データ116をコンピュータ106に送信する。さらに、コンピュータ106は、HMD102及びユーザ100が配置された対話型環境の画像を撮影するように構成されるカメラ110から撮影画像データ118を受信する。慣性データ116及び/または画像データ118は、HMD102と、その位置、向き、及び動きとを特定し追跡するためにコンピュータ106によって分析される。
HMDの予測将来位置は、HMD102の追跡された動きを使用して決定される。例として、コンピュータ106によってHMD102の追跡された動きに基づいて動きベクトルを生成することができる。この動きベクトルをHMD102の現在位置に適用して、HMDの将来位置を予測することができる。HMDの予測将来位置を使用して、コンピュータ106は、送受信機110のビーム形成方向をHMDの予測将来位置の方へ向けるように構成されるビーム形成データ120を生成する。送受信機のビーム形成方向を予測的に向けることによって、強い無線信号を維持することができ、その理由は、HMD102の動きが予期され、信号のビーム形成方向がそのような動きに遅れなくなり、HMDのそのような動きと同時に及び/または予期して動くことができるためである。本開示では、送受信機110のビーム形成パラメータ(たとえば、方向及び角度広がり)が参照される。そのようなビーム形成パラメータが、送受信機の一部である送信機及び受信機の一方または両方に適用できることは理解されよう。おおまかに言って、コンピュータからHMDへのビデオデータの送信に焦点を合わせた実施態様では、送受信機の送信機による送信に関してビーム形成を論じ得る。しかしながら、ビーム形成に関するいかなるそのような議論も、送受信機の受信機による信号受信にも適用できることを理解されたい。
いくつかの実施態様では、カメラ108及び送受信機110を同一のデバイス内に統合して、カメラ及び送受信機が互いに固定の空間関係を有するようにし、より具体的には、カメラによる画像撮影と、送受信機によるRFビーム形成とが、互いに対して空間的に既知となるようにする。そのような実施態様では、HMDの位置はカメラによる撮影画像から決定することができ、送受信機によるビーム形成は、追加の較正を必要とせずにHMDの方へ適切に向けることができる。
他の実施態様では、送受信機110及びカメラ108は、ローカル環境内の異なる場所に配置することができる別々のデバイスである。そのような実施態様では、カメラによる画像撮影と、送受信機によるRFビーム形成との空間関係を決定するために較正が実行され得る。一実施態様では、これは、カメラからの撮影画像を分析してカメラに対するHMDの位置を決定し、決定されたHMDの位置に対する最適なビーム形成方向を決定するためのテストを実行し、これらの情報を関連付けることによって実行することができる。そのような手順は、より正確な較正結果を実現するために、HMDの複数の位置に対して実行され得る。
いくつかの実施態様では、信号品質フィードバック122が、たとえば送受信機110またはネットワーク112を介して、HMD102からコンピュータ106に提供される。信号品質フィードバック122は無線伝送の品質(たとえば、信号強度、誤り率など)を示すものであり、十分なデータ伝送レートを提供するために、ビーム形成方向がHMD102の方へ効果的に誘導されているか否かを評価するのに使用可能な情報を提供する。
図2A−1及び図2A−2に、本開示の一実施態様による、ヘッドマウントディスプレイ(HMD)を示す。特に図2A−1はPlaystation(登録商標)VRヘッドセットを示し、これは本開示の実施態様によるHMDの一例である。図示のように、HMD102は複数のライト200A−Hを含む。これらのライトのそれぞれは、特定の形状を有するように構成され得、同一のまたは異なる色を有するように構成することができる。ライト200A、200B、200C、及び200DはHMD102の前面に配置される。ライト200E及び200FはHMD102の側面に配置される。そして、ライト200G及び200Hは、HMD102の前面及び側面に広がるように、HMD102の角部に配置される。ユーザがHMD102を使用する対話型環境の撮影画像においてライトを識別できることは理解されよう。ライトの識別及び追跡に基づいて、対話型環境におけるHMD102の位置及び向きを決定することができる。画像撮影デバイスに対するHMD102の特定の向きに応じて、いくつかのライトが見えたり見えなかったりすることはさらに理解されよう。また、画像撮影デバイスに対するHMD102の向きに応じて、ライトの異なる部分(たとえば、ライト200G及び200H)が画像撮影のために露光され得る。
一実施態様では、ライトは、HMDの現在の状態を周囲の他の人々に示すように構成することができる。たとえば、ライトの一部または全部は、特定の色配置、強度配置を有するように構成され得、点滅し、特定のオン/オフ構成を有し、またはHMD102の現在の状態を示す他の配置を有するように構成され得る。例として、ライトは、ビデオゲームの活発なゲームプレイ(一般には、活発なタイムライン中またはゲームのシーン内で発生するゲームプレイ)中に、ビデオゲームの他の活発でないゲームプレイの状況、たとえば、メニューインターフェース内の移動またはゲーム設定の変更など(この間にゲームのタイムラインまたはシーンは不活発であるかまたは一時停止され得る)とは異なる構成を表示するように構成することができる。また、ライトはゲームプレイの相対的な激しさのレベルを示すように構成され得る。たとえば、ゲームプレイの激しさが増加した場合、ライトの強度または点滅速度が増加し得る。このようにして、ユーザの外部の人は、HMD102上のライトを見て、ユーザが激しいゲームプレイに積極的に取り組んでおり、その時に邪魔されたくないと思い得ることを理解し得る。
HMD102は1つまたは複数のマイクロフォンをさらに含み得る。図示の実施態様では、HMD102は、HMD102の前面に画定されたマイクロフォン204A及び204Bと、HMD102の側面に画定されたマイクロフォン204Cとを含む。マイクロフォンのアレイを利用することによって、各マイクロフォンからの音を処理して音源の位置を決定することができる。この情報は、たとえば、不要な音源の排除、音源と視覚識別との関連付けなど、様々な方法で利用することができる。
また、HMD102は1つまたは複数の画像撮影デバイスを含み得る。図示の実施態様では、HMD102は画像撮影デバイス202A及び202Bを含むように示されている。画像撮影デバイスのステレオペアを利用することによって、環境の3次元(3D)画像及びビデオをHMD102の視点から撮影することができる。そのようなビデオをユーザに提示して、HMD102の装着中に、ユーザに「ビデオシースルー」能力を提供することができる。すなわち、ユーザは厳密な意味ではHMD102を透かして見ることはできないが、それにもかかわらず、画像撮影デバイス202A及び202B(あるいは、以下の図3に示すHMD102の外側本体に配置された1つまたは複数の正面カメラ108'など)によって撮影されたビデオは、あたかもHMD102を透かして見ているかのようにHMD102の外部の環境を見ることができることと機能的に同等なものを提供することができる。そのようなビデオは、拡張現実体験を提供するために仮想要素で拡張することができ、または他の方法で仮想要素と組み合わせまたはブレンドされ得る。図示の実施態様では、2つのカメラがHMD102の前面に示されているが、HMD102上に設置され、任意の方向を向けられた任意数の外向きのカメラが存在し得ることは理解されよう。たとえば、他の実施態様では、環境の追加のパノラマ画像撮影を提供するためにHMD102の側面に取り付けられたカメラが存在し得る。
図2Bに、HMD102のユーザ100がクライアントシステム106とインターフェースをとり、クライアントシステム106が、セカンドスクリーン207と呼ばれるセカンドスクリーンディスプレイにコンテンツを提供する一例を示す。クライアントシステム106は、HMD102からセカンドスクリーン207へのコンテンツの共有を処理するための集積電子機器を含み得る。他の実施態様は、クライアントシステムと、HMD102及びセカンドスクリーン207のそれぞれとの間でインターフェースをとる別個のデバイス、モジュール、コネクタを含み得る。この一般的な例では、ユーザ100はHMD102を装着しており、コントローラを使用してビデオゲームをプレイしており、コントローラは指向性インターフェースオブジェクト104でもよい。ユーザ100による対話型プレイによってビデオゲームコンテンツ(VGC)が生成され、これはHMD102に対して対話形式で表示される。
一実施態様では、HMD102内に表示されているコンテンツは、セカンドスクリーン207に共有される。一例では、セカンドスクリーン207を見ている人は、ユーザ100によってHMD102内で対話形式でプレイされているコンテンツを見ることができる。他の実施態様では、他のユーザ(たとえばプレイヤー2)は、クライアントシステム106と対話してセカンドスクリーンコンテンツ(SSC)を生成することができる。プレイヤーがコントローラ104(または任意の種類のユーザインターフェース、ジェスチャ、音声、または入力)とも対話することによって生成されるセカンドスクリーンコンテンツはSSCとしてクライアントシステム106へ生成され得、SSCはHMD102から受信されたVGCと共にセカンドスクリーン207上に表示することができる。
したがって、同一の場所にいるかまたはHMDユーザから離れている場合がある他のユーザによる対話は、HMDユーザと、セカンドスクリーン207上でHMDユーザによってプレイされているコンテンツを見ている場合があるユーザとの両方にとって、ソーシャルで、対話的で、より没入感のあるものとすることができる。図示のように、クライアントシステム106はインターネット210に接続することができる。インターネットは様々なコンテンツソース220のコンテンツへのアクセスをクライアントシステム106に提供することもできる。コンテンツソース220は、インターネットを介してアクセス可能な任意の種類のコンテンツを含むことができる。
そのようなコンテンツは、限定なしに、ビデオコンテンツ、映画コンテンツ、ストリーミングコンテンツ、ソーシャルメディアコンテンツ、ニュースコンテンツ、フレンドコンテンツ、広告コンテンツなどを含むことができる。一実施態様では、クライアントシステム106を使用して、ゲームプレイ中の対話に関連付けられたマルチメディアコンテンツがHMDに提供されるように、HMDユーザ用のコンテンツを同時に処理することができる。そして、クライアントシステム106は、セカンドスクリーンへのビデオゲームコンテンツとは無関係であり得る他のコンテンツを提供することもできる。クライアントシステム106は、一実施態様では、コンテンツソース220のうちの1つ、もしくはローカルユーザ、またはリモートユーザからセカンドスクリーンコンテンツを受信することができる。
図3に、本開示の一実施態様による、実行中のビデオゲームと連動するHMD102の機能を概念的に示す。実行中のビデオゲームは、ビデオゲームのゲーム状態を更新するための入力を受け取るゲームエンジン320によって定義される。ビデオゲームのゲーム状態は、たとえば、オブジェクトの存在及び位置、仮想環境の状況、イベントのトリガ、ユーザプロファイル、ビューの視点など、現在のゲームプレイの様々な側面を定義するビデオゲームの様々なパラメータの値によって少なくとも部分的に定義することができる。
図示の実施態様では、ゲームエンジンは、例として、コントローラ入力314、音声入力316、及びモーション入力318を受け取る。コントローラ入力314は、手持ち式ゲームコントローラ(たとえば、Sony DUALSHOCK(登録商標)4ワイヤレスコントローラ、Sony PlayStation(登録商標)Moveモーションコントローラ)、または指向性インターフェースオブジェクト104などの、HMD102から分離したゲームコントローラの操作から定義され得る。例として、コントローラ入力314は、方向入力、ボタン押下、トリガ起動、動き、ジェスチャ、またはゲームコントローラの操作から処理される他の種類の入力を含み得る。音声入力316は、HMD102のマイクロフォン302から、もしくは画像撮影デバイス108に含まれるマイクロフォンから、またはローカル環境内の他の場所から処理することができる。モーション入力318は、HMD102に含まれるモーションセンサ300から、またはHMD102の画像を撮影したときに画像撮影デバイス108から処理することができる。ゲームエンジン320は、ゲームエンジンの構成に従って処理される入力を受け取って、ビデオゲームのゲーム状態を更新する。ゲームエンジン320はゲーム状態データを様々なレンダリングモジュールに出力し、これらはゲーム状態データを処理して、ユーザに提示されるコンテンツを定義する。
図示の実施態様では、ビデオレンダリングモジュール322は、HMD102上に提示されるビデオストリームをレンダリングするように定義される。ビデオストリームはディスプレイ/プロジェクタ機構310によって提示され、ユーザの目306によって光学系308を通して見られ得る。音声レンダリングモジュール304は、ユーザにより聴取される音声ストリームをレンダリングするように構成される。一実施態様では、音声ストリームは、HMD102に関連付けられたスピーカー304を介して出力される。スピーカー304は、オープンエアスピーカー、ヘッドフォン、または音声を提示することが可能な他の任意の種類のスピーカーの形態を取り得ることを理解されたい。
一実施態様では、ユーザの視線の追跡を可能にするために、視線追跡カメラ312がHMD102に含まれる。視線追跡カメラは、ユーザの視線方向を決定するために分析される、ユーザの目の画像を撮影する。一実施態様では、ユーザの視線方向に関する情報を利用してビデオレンダリングに影響を及ぼすことができる。たとえば、ユーザの目が特定の方向を見ていると決定された場合、その方向のビデオレンダリングは、ユーザが見ている領域においてさらなる細部またはより速い更新を提供することなどによって優先または強調することができる。ユーザの視線方向は、ヘッドマウントディスプレイに対して、ユーザが位置する現実環境に対して、及び/またはヘッドマウントディスプレイ上にレンダリングされている仮想環境に対して定義できることを理解されたい。
おおまかに言って、視線追跡カメラ312によって撮影画像の分析は、単独で考慮すると、HMD102に対するユーザの視線方向を提供する。しかしながら、HMD102の追跡された位置及び向きと組み合わせて考慮すると、ユーザの現実世界の視線方向を決定することができ、その理由は、HMD102の位置及び向きはユーザの頭の位置及び向きと同義であるためである。すなわち、ユーザの現実世界の視線方向は、ユーザの目の位置の動きを追跡すること、及びHMD102の位置及び向きを追跡することから決定することができる。仮想環境のビューがHMD102上にレンダリングされた場合、ユーザの現実世界の視線方向を利用して、仮想環境におけるユーザの仮想世界の視線方向を決定することができる。
加えて、触覚フィードバックモジュール326は、HMD102またはユーザによって操作される他のデバイス、たとえば、指向性インターフェースオブジェクト104のいずれかに含まれる触覚フィードバックハードウェアに信号を提供するように構成される。触覚フィードバックは、たとえば、振動フィードバック、温度フィードバック、圧力フィードバックなどの様々な種類の触感の形態を取り得る。指向性インターフェースオブジェクト104は、そのような形態の触覚フィードバックをレンダリングするための対応するハードウェアを含むことができる。
図4に、本開示の実施態様による、HMDの将来位置の予測に基づく送信機のビーム形成方向の調整を示す。図示の実施態様では、HMD102は、3次元空間内の初期位置Aに示されている。HMD102はユーザの制御下で任意の方向に動かすことができ、したがって、送信ビームをHMD102の方へ誘導することが望ましい。
いくつかの実施態様では、HMD102の現在の動きを示す動きベクトル400が決定される。HMDの現在の動きは、HMD102の1つまたは複数の慣性センサによって生成されるデータからだけでなく、(たとえば、ライトまたはHMDの他の認識可能な部分の動きを追跡するために)HMDの撮影画像を分析することからも決定することができる。いくつかの実施態様では、動きベクトル400は、HMDの動きの空間的(3次元(3D))方向と、動きの速さとの両方を示す速度ベクトルである。動きベクトル400をHMDの現在位置Aに適用して、HMDの予測将来位置Bを決定することができる。すなわち、HMDの動きの方向及び速さを使用して現在位置Aから外挿することによって、将来位置Bが予測される。
いくつかの実施態様では、動きベクトル400自体は、HMD102の決定された加速度に基づいて予測される。すなわち、HMDの速度の変化(方向及び速さの変化を含む)を、より早い時点でのHMDの以前に決定された速度、及び/または加速度検知ハードウェア(たとえば1つまたは複数の加速度計)から決定して、HMDの現在の加速度を定義することができる。この加速度を直前の動きベクトルに適用して動きベクトル400を決定することができ、動きベクトル400を現在位置に適用して上述のように将来位置を予測する。
図示の実施態様では、送受信機110の初期のビーム形成方向402は、図示のようにHMDの初期位置Aの方へ向けられている。HMDの予測将来位置Bに基づいて、ビーム形成方向は、更新されたビーム形成方向404によって示されるように、将来位置Bの方へ向けられるように調整される。ビーム形成方向の調整は、HMD102の実際の将来位置が分かる前に行われる予測的な方法で実行されることは理解されよう。HMDの将来位置を予期し、それに応じてビーム形成方向を予測的に誘導することによって、送受信機110とHMD102との間の無線通信を改善することができ、その理由は、RFビーム形成を介して提供される改善された帯域幅が、その方向をHMD102の方へ継続的に誘導することによって維持されるためである。
ビーム形成方向は予測的に調整されるので、HMDの実際の動きに様々な度合いで一致するまたはしない場合があることは理解されよう。しかしながら、本開示の実施態様によれば、その後の予測位置は、最新の利用可能な情報に基づいて(たとえば、カメラからの撮影画像の分析を介して)決定される既知の現在位置から決定することができる。したがって、所与の調整されたビーム形成方向はHMDの実際の動きと詳細に一致しない場合があるが、その後のビーム形成方向の調整は、HMDの実際の既知の位置に少なくとも部分的に基づくので、ビーム形成方向の継続的な調整は、HMD102の実際の位置から過度にずれやすくはならならない。
いくつかの実施態様では、ビーム形成更新レートは約10から100ミリ秒のオーダーであるので、HMDの将来位置が予測されるレートはビーム形成更新レートと一致する。いくつかの実施態様では、予測レートは、カメラのフレームレート、たとえばいくつかの実施態様では60、120、または240Hzと一致するように構成される。したがって、この予測は、次のフレームにおけるHMDの位置を予測することになる。
いくつかの実施態様では、HMD102の慣性センサは、カメラ108よりも、動きを検出するためのより優れた能力を有し得る。たとえば、カメラはその解像度(たとえば、いくつかの実施態様では720pまたは1080pの解像度)によって制限され得るので、慣性センサはカメラ108よりも小さい動きに反応し得る。さらに、慣性センサのサンプルレートは、カメラのフレームレートよりもかなり高い場合がある。たとえば、カメラは約60、120または240Hzのフレームレートを有し得、慣性センサは1000Hzを超えるサンプルレートを有し得る。さらに、カメラは、位置及び/または動きを決定するために、(たとえば、撮影画像を分析するために)より長い処理時間を必要とし得る。このように、慣性センサは、カメラ108よりも速い過渡応答で、動きに対してより敏感であり得る。
しかしながら、相対運動を検出する慣性センサは、時間が経つにつれてドリフト効果を起こしやすい場合があるので、HMDの位置の決定を行うのにもっぱら信頼されているわけではない。一方、カメラ108はHMDの位置の正確な決定を行うのにより適しており、その理由は、ローカル環境内の固定オブジェクトが、ローカル環境内のHMDの位置を決定するためのアンカーとして機能することができるためである。
したがって、様々な実施態様において、別々または組み合わせでの慣性センサデータ対画像撮影データの使用は、時間と共に変化し得る。たとえば、いくつかの実施態様では、慣性センサのサンプルレートは、カメラのフレームレートよりもN倍速い場合がある。したがって、HMDの予測位置は、慣性センサのサンプルレートと一致するレートで決定することができるが、N回ごとの予測位置は、カメラからの画像撮影データを考慮に入れる(たとえば、HMDの実際の位置を検証し、それに基づいて予測位置が決定される)。HMDの各予測位置を使用して、送受信機110のビーム形成方向をそれに応じて調整することによって、HMDの予測位置の方へ向けるようにすることができることは理解されよう。このように、ビーム形成方向の調整は、カメラのフレームレートよりも速いレートで行われ得る。
関連する実施態様では、HMDの予測位置が決定されるレートは慣性センサのサンプルレートと必ずしも一致しないが、それでもなおカメラのフレームレートよりは速く、及び/または予測位置の決定が撮影画像データを考慮に入れるレートよりも速い。慣性センサのサンプルレート及びカメラのフレームレートはこれらのデバイスの動作範囲内で設定可能にすることができ、これを必要に応じて制御して、前述の位置予測を可能にすることができることは理解されよう。
いくつかの実施態様では、慣性センサのより高速なサンプリングレートを利用して動きベクトルの決定を改善し、たとえば、(撮影画像に対して追加的にサンプリングされた)慣性センサデータに基づいて現実空間におけるHMDの加速度を考慮に入れることによって行う。このようにして、動きベクトル400は、HMDの実際の動きと一致するようにより良く調整され得、それによってHMDのより正確な予測位置が可能になる。
いくつかの実施態様では、カメラからの撮影画像データを処理し分析するのに必要な時間は、撮影画像データを使用したHMDの位置の決定がHMDの実際の動きよりもかなりの程度遅れ得るようなものである。したがって、いくつかの実施態様では、撮影画像データは、HMDの過去位置を決定するために分析されるが、(慣性センサデータに基づいて)予測将来位置を決定するための現在位置としては利用されない。むしろ、HMDの過去位置をHMDの以前の予測位置などに対して検証するために、撮影画像データの分析が実行され利用される。たとえば、HMDの以前の予測位置が所定量を超えて過去位置と異なる場合、HMDの位置の現在の予測はそのような情報に基づいて調整され得る。
加えて、以下でさらに詳細に論じるように、HMDの位置の予測は予測モデルを使用し得る。予測モデルの精度は、カメラからの撮影画像データを使用して決定されたHMDの過去位置と、同時刻の以前の予測位置との比較に基づいて評価され得る。予測モデルはそのような比較に基づいて改善された結果を提供するように調整され得る。
図5A及び図5Bに、本開示の実施態様による、HMDの動きに基づくビーム形成角度広がりの調整を示す。本開示では、ビーム形成方向とは、ビーム形成送受信機110のメインローブのピーク強度方向を指すことは理解されよう。しかしながら、ビーム形成方向を調整することに加えて、メインローブの角度幅/広がりであるビーム形成角度広がりを調整することもできる。電磁ビームの角度広がりは様々な定義、たとえば、「半値全幅」(FWHM:full width at half maximum)(または「電力半値ビーム幅」(HPBW:half power beam width))定義などを使用して定義することができ、これは角度広がりを最大強度の半分におけるビームの全幅として定義するものである。
いくつかの実施態様では、角度広がりはHMD102の速さに基づいて調整される。たとえば、図5Aにおいて、ユーザ100によって操作されるHMD102は、動きベクトル500によって示される第1の速さを有する。それに応じて、送受信機110のビーム形成角度広がりは、角度広がり502を有するように制御される。図5Bにおいて、ユーザ100によって操作されるHMD102は、動きベクトル504によって示される、第1の速さより速い第2の速さを有する。それに応じて、送受信機110のビーム形成角度広がりは、角度広がり502よりも広い/大きい角度広がり506を有するように制御される。現在説明している実施態様は、HMDの速さが増加するにつれて角度広がりが増加するように、HMDの速さと正に相関するようビーム形成広がりを調整することを企図している。これは無線接続の安定性を維持するために有用であり、その理由は、HMDの可能性のある将来位置の範囲はHMDの速さが速いほど大きくなる傾向を有し得るので、そのような状況下でより大きい角度幅を有するビーム形成角度広がりはメインローブの広がりの中にHMDを維持する可能性が高いためである。
関連する実施態様では、ビーム形成角度広がりを決定する目的で、送受信機に対するHMDの横方向の速さが、他の方向におけるHMDの速さに対して優先される。HMD102が送受信機110へ向かってまたは離れて動いている場合、HMDが送受信機110に対して横方向に動いている場合とは対照的に、HMDが送受信機のメインローブから出る可能性が低くなり得ることは理解されよう。したがって、いくつかの実施態様では、送受信機110に対するHMD102の横方向の動きが考慮され、ビーム形成角度広がりは横方向の速さと正の相関で調整される。
いくつかの実施態様では、送受信機110のビーム形成角度広がりは、横方向の速さが増加するにつれて角度広がりが増加するように、送受信機に対するHMDの横方向の速さに応じて、他の非横方向のHMDの速さを排除して調整される。他の実施態様では、送受信機110のビーム形成角度広がりは、HMDの速さが増加するにつれて角度広がりが増加するような正の相関で、HMDの速さに応じて調整されるが、HMDの横方向の速さが、角度広がりを決定する目的で、他の方向のHMDの速さよりも大きく重み付けられる。
いくつかの実施態様では、送受信機からのHMDの距離はビーム形成角度広がりに影響を及ぼす。たとえば、HMDが送受信機に近い場合、HMDが動くと、HMDが送受信機から遠い場合と比べて、HMDが送受信機のメインローブから外に出やすくなり得る。したがって、いくつかの実施態様では、ビーム形成角度広がりは、送受信機からのHMDの距離が減少するにつれて角度広がりが増加するように、送受信機からのHMDの距離に対して逆相関で調整される。
関連する実施態様では、この概念は、HMDの検出された動きに基づいて応用することができる。たとえば、いくつかの実施態様では、送受信機へ向かうHMDの半径方向の動きが検出された場合に角度広がりが増加し、送受信機から離れるHMDの半径方向の動きが検出された場合に角度広がりが減少するように、送受信機へ向かう/離れるHMDの半径方向の動きに基づいてビーム形成角度広がりが調整される。さらに、角度広がりの増加または減少の量は、それぞれ送受信機へ向かうまたは離れるHMDの半径方向の動きの速さに正に相関させることができる。
図5Cは、本開示の実施態様による、HMDの速さに対する送受信機のビーム形成角度広がりを示すグラフである。おおまかに言って、角度広がりはHMDの速さに正に相関し、HMDの速さが増加するにつれて送受信機の角度広がりも増加する。しかしながら、特定の最小の速さを下回ると、角度広がりは最小値に維持される。そして特定の最大の速さを上回ると、角度広がりは最大値に維持される。いくつかの実施態様では、HMDの速さは、具体的には送受信機に対するHMDの横方向の速さである。本開示の原理によれば、HMDの速さは、たとえば現在の速さ及び/または加速度などの要因に基づいて予測された速さであり得、したがって、速さに基づく角度広がりの調整を予測的に実行できることは理解されよう。
図5Dは、送受信機からのHMDの半径方向距離に対する送受信機のビーム形成角度広がりを示すグラフである。図示のように、角度広がりは全体的に送受信機からのHMDの半径方向距離と逆相関し、半径方向距離が増加するにつれて角度広がりは全体的に減少する。しかしながら、特定の最小半径方向距離を下回ると、角度広がりは最大値に維持される。そして特定の最大半径方向距離を上回ると、角度広がりは最小値に維持される。本開示の原理によれば、送受信機からのHMDの半径方向距離は、たとえば現在の動き及び加速度などの様々な要因に基づいて予測された半径方向距離であり得、したがって、半径方向距離に基づく角度広がりの調整を予測的に実行できることは理解されよう。
いくつかの実施態様では、角度広がりは、データレートなどの他の要因に基づいて決定することができる。図5Eは、本開示の実施態様による、送信データレートに対する送受信機のビーム形成角度広がりを示すグラフである。おおまかに言って、角度広がりは送信データレートと逆相関し、データレートが増加するにつれて角度広がりは減少する。角度広がりを狭めると帯域幅を広げることができ、ただし、角度広がりは狭くなる。したがって、このようにデータレートに応じて角度広がりを変化させることによって、信号がHMDの方へ適切に向けられた場合に利用可能な帯域幅と、HMDの動きに対する無線接続の許容範囲との間にはトレードオフがある。いくつかの実施態様では、特定の最小データレートを下回ると、角度広がりは最大値に維持される。そして特定の最大データレートを上回ると、角度広がりは最小値に維持される。
ビーム形成角度広がりの調整に関する上述の実施態様は、限定なく例として提供している。本開示の範囲に入るさらなる実施態様は、互いに排他的ではない前述の実施態様のいずれかの組み合わせによって包含される。
いくつかの実施態様では、ビーム形成方向及び/または角度広がりは、ユーザの視線方向に基づいて調整することができる。図6A、図6B、及び図6Cに、本開示の実施態様による、ユーザ100の視線方向に基づいてビーム形成方向が調整されるシナリオを示す。図6Aに、HMD102を装着しているユーザ100の俯瞰図を示す。ユーザ100は視線方向600を有するように示されている。送受信機110は、HMD102の方へ向けられたビーム形成方向602を有するように構成される。送受信機の角度広がりはHMD102をほぼ中心とすることは理解されよう。
図6Bでは、ユーザ100は視線方向を右へ視線方向606に動かしている。ユーザ100の視線方向の変化は、ユーザが、たとえば、おおよそ新たな視線方向の方向に動こうとしていることを示し得る。したがって、いくつかの実施態様によれば、送受信機110のビーム形成方向はユーザの視線方向の変化に応答して調整される。引き続き図6Bを参照すると、視線方向606がユーザ100の右側に動いたので、ビーム形成方向608は同様の方向に動かされ、更新されたビーム形成方向608に応答的に変更される。ビーム形成方向608は変更されているが、その角度広がり610は、HMD102が依然としてメインローブ内に位置するようなものであり、HMDが実際にはまだ新たな位置に動いていないので、HMDとの無線接続が維持される。ビーム形成方向はユーザの視線方向の変化に基づいて予測的に動かされていることは理解されよう。HMDの位置は変化していないが、ビーム形成方向は予測的に調整され得、ただしHMD102を送受信機110の角度広がり内に維持する範囲内である。
図6Cでは、ユーザ100は、たとえば追加的に頭を回転させることによって、視線方向を視線方向612にさらに動かしている。ユーザは次いで、符号614で示す新たな位置に移動する。ユーザ100が移動すると、送受信機のビーム形成方向は、強い無線接続を維持するために方向616に予測的に動かされる。
いくつかの実施態様では、ユーザの視線方向(及び/またはその変化)は、HMDの将来位置を予測する目的で考慮することができる他の要因である。視線方向は、予測将来位置を決定するための追加で説明する要因と組み合わせて重み付けすることができ、それに応じてビーム形成方向を調整することができる。さらに、追加の実施態様では、ユーザの視線方向を利用してビーム形成角度広がりに影響を及ぼすことができる。
いくつかの実施態様では、HMDの位置は時間と共に追跡することができ、対話型環境内でのHMDの位置の分布を決定することができる。HMDの将来位置は、HMDの過去位置分布に少なくとも部分的に基づいて決定することができる。
図7に、本開示の実施態様による、HMDの位置分布を示す部屋700の俯瞰図を示す。部屋700は、HMDがユーザによって操作され、カメラ108及び送受信機110が配置された、対話型の現実環境を定義する。線704a−e及び706a−dは、部屋700内のHMDの過去位置に基づく位置分布の等高線である。すなわち、対話中のHMDの位置は、たとえば周期的な間隔でHMDの位置を記録することによって時間と共に追跡されており、部屋700内の位置の分布は、発生の密度(単位面積当たりの発生数)もしくは頻度または確率が、線704a−eまたは706a−dのうちの所与の1つに沿って同一またはほぼ同一であるようなものである。図示の実施態様では、図示した最も高い等高値は線704a及び706aのものであり、線704b、c、及びd、ならびに線706b、c、及びdでは値が減少していく。図示の実施態様では、線704eは図示した最も低い等高値を表している。
領域708及び710が、HMDに関して最も高い分布密度の位置を示すことは理解されよう。換言すれば、HMDは、領域708及び710の単位面積内に位置する確率が、部屋700の他の領域の単位面積内に位置する確率よりも統計的に高い。図示の実施態様では、カウチ/椅子702が部屋700内に示されている。ユーザはカウチ702に座りながらHMDを使用してかなりの時間を費やし得るので、領域710及びその周辺領域は、カウチ702上の中央の座る位置に対応する。領域708及びその周辺領域はカウチの前にあり、それによって、ユーザがHMDを使用しながらカウチの前に立っている領域を示し得る。
いくつかの実施態様では、位置分布は、HMDの予測将来位置を決定するための要因として利用される。たとえば、確率または重みは、HMDがある位置に位置する尤度を示す位置の関数として決定することができ、これはHMDの予測将来位置を決定するための要因として使用することができる。
関連する実施態様では、所与の対話型アプリケーションについて、複数のユーザにわたるHMDの位置/動きパターンを決定することができ、たとえば複数のHMDに関する位置/動き情報を記録し、そのような情報をサーバにアップロードして処理及び分析することによって行う。位置/動き情報は対話型アプリケーションの状態に関連付けられ、それによって、(たとえば、対話型アプリケーションによって定義される仮想環境内の特定の時間的または地理的位置における)対話型アプリケーションの所与の状態についてのHMDの位置/動きパターンを決定することができる。これにより、特定のアプリケーション状態についてのHMDの位置及び動きに関するクラウドソースのデータを提供することができ、これを利用して、対話型アプリケーションとの対話中の特定のユーザのHMDの将来位置及び動きを予測することができる。
図8に、本開示の実施態様による、予測モデルを使用したビーム形成パラメータの決定を概念的に示す。予測モデル800は、1つまたは複数の入力を使用してHMDの将来位置及び/または動き(たとえば速度、加速度)を予測するように構成される。
例として、そのような入力は、モーションデータ808(たとえば、速度(方向及び速さ)、加速度、回転など)、位置データ810(たとえば、3D座標、相対位置情報、過去位置情報など)、視線方向812、ユーザバイオメトリクス814(たとえば、身長、体重、心拍数、呼吸、瞳孔拡張など)、ユーザプロファイル/履歴(たとえば、ユーザの嗜好、ユーザの動き/ジェスチャパターンなど)、ならびにアプリケーション状態818(たとえば、アプリケーション変数状態、仮想オブジェクト状態など)のいずれかを含むことができる。
予測モデルの出力に基づいて、送受信機のビーム形成パラメータが調整され(符号802)、これはメインローブの方向及び/または角度広がりの調整を含むことができる。HMDがビーム形成メインローブ内に留まり、継続して強力な無線接続が提供されるようにするために、ビーム形成調整がHMDの実際の動きと同時にまたはその前にすら実行できるように、送受信機のビーム形成が予測的に調整されることは理解されよう。
動作804において、フィードバックデータを処理して、ビーム形成調整の有効性及び/または予測モデルの精度を評価することができる。いくつかの実施態様では、フィードバックデータは、送受信機からHMDによって受信された無線信号の品質を示す、HMDによって取得された信号品質測定値を含む。例として、そのような信号品質測定値は、信号強度、信号対雑音比、帯域幅、誤り、または送受信機によって送信され、HMDによって受信される無線信号の品質の他の測定値を含むことができる。送受信機の信号品質を評価することによって、ビーム形成調整の有効性及び/または予測モデルの精度を評価することができる。
いくつかの実施態様では、フィードバックデータは、HMDの実際の位置及び/または動きを示す位置及び/または動きデータを含み、これを予測モデルによって生成された予測位置/動きと比較して、予測モデルの精度を評価することができる。
上記に基づいて、次いで動作806において、予測モデル800を調整してその精度を向上させることができる。いくつかの実施態様では、予測モデルを改善するために機械学習技術を利用することができる。
図9に、本開示の実施態様による、予測将来位置を使用してビーム形成パラメータを調整するための方法を示す。方法動作900において、HMDを含む現実世界の対話型環境の画像がカメラによって撮影される。方法動作902において、HMDの慣性運動が、HMDの1つまたは複数の慣性センサによって検知される。方法動作904において、HMDの検知された慣性運動と、HMDの撮影画像との一方または両方に少なくとも部分的に基づいて、HMDの現在位置が決定される。
方法動作906において、HMDの検知された慣性運動と、HMDの撮影画像との一方または両方に少なくとも部分的に基づいて、動きベクトルが生成される。方法動作908において、動きベクトル及びHMDの現在位置を使用してHMDの将来位置が予測される。方法動作910において、方向及び/または角度広がりなどの送受信機の1つまたは複数のビーム形成パラメータが、HMDの予測将来位置に基づいて調整される。
本開示では、HMDの将来位置を予測し、RFビーム形成方向を予測将来位置の方へ誘導することに関して実施態様を全体的に説明しているが、いくつかの実施態様では、必ずしも特定の将来位置が決定されるわけではないことを理解されたい。むしろ、予測的な方法でのビーム形成方向の調整は、特定の将来位置を具体的に決定または特定することなく、様々な入力パラメータに基づいて実現される。そのような実施態様におけるビーム形成方向は、入力に基づいて、予測将来位置が決定された場合にそこへ向かうように予測的に誘導されることは理解されよう。
図10に、本開示の実施態様による、コンピュータとHMDとの間に無線通信を提供するためのシステムを概念的に示す。コンピュータ106はカメラ108及び送受信機110に接続される。上述のように、カメラ108及び送受信機110は、いくつかの実施態様では同一のデバイスの一部であり得、または他の実施態様では別々のデバイスであり得る。カメラ108は、コンピュータ106から受信した命令を処理して、カメラ106の動作パラメータ、たとえば、絞り、センサゲインなどを制御するように構成されるコントローラ1026を含む。送受信機110は、コンピュータ106からの命令を処理して、送受信機の送信機1030及び受信機1032の制御を含む送受信機110の動作を制御するように構成されるコントローラ1028を含む。送信機1030及び受信機1032が、本開示の原理によるビーム形成をもたらすように構成できることは理解されよう。
おおまかに言って、コンピュータ106は、対話型アプリケーション1016(たとえば、ビデオゲーム)を実行して、HMD102のディスプレイ1048にレンダリングするためにHMD102に無線送信されるビデオデータ(画像及び音声データを含む)を生成する。送受信機110のビーム形成方向及び/または広がりは、無線受信可能範囲及びHMDへの指向性を維持するように調整される。HMDは、たとえば1つまたは複数の加速度計1040、ジャイロスコープ1042、及び磁力計1044を含む様々な慣性センサ1038を含む。慣性センサ1038から処理されたデータはHMDによって、HMDの送受信機1034から送受信機110への送信を介してコンピュータ106に通信される。コンピュータ106は、HMDからの慣性センサデータを処理して、たとえばHMDの動きを決定または特定するように構成されるセンサデータプロセッサ1000を含む。
カメラ108は、ユーザがHMDを操作する対話型の現実環境の画像を撮影するように構成される。カメラ108によって撮影された画像は、たとえばHMD102のライト1046を識別することによってHMDを識別するなどのために、画像分析器1002によって処理される。
追跡ロジック1004は、HMDの位置、向き、及び/または動きをさらに分析、特定及び/または定量化するように構成される。この目的で、位置分析器1006は、慣性センサデータ及び撮影画像データに基づいてHMDの位置を決定するように構成される。向き分析器は、慣性センサデータ及び撮影画像データに基づいてHMDの向きを決定するように構成される。動き分析器は、慣性センサデータ及び撮影画像データに基づいてHMDの動きを決定するように構成される。
予測ロジック1018はモデルを使用して、前述のHMD102の位置、向き及び動きなどの様々な入力に基づいてHMD102の将来位置及び/または動きを予測する。いくつかの実施態様では、予測ロジック1018は、ユーザ設定1014または対話型アプリケーション1016からの情報などの追加の入力を使用する。たとえば、対話型アプリケーション1016は、対話型アプリケーションの現在の状態に基づいて、HMDの将来の予想位置または動きに関する情報を提供し得る。ビーム形成プロセッサ1020は、HMDの予測将来位置及び/または動きに基づいて、ビーム形成パラメータ及びその調整を決定するように構成される。方向処理モジュール1022は、送受信機110のビーム形成方向及びその調整を決定するように構成される。広がり処理モジュール1024は、送受信機110の角度広がり及びその調整を決定するように構成される。更新されたビーム形成パラメータは送受信機110のコントローラ1028に通信され、それによって、ビーム形成方向を更新された方向に誘導/更新すること、及び/または角度広がりを更新することなどの、送受信機のパラメータの調整がもたらされる。
いくつかの実施態様では、HMD102は、送受信機110から受信した信号の品質を評価するように構成される信号分析器1036を含む。たとえば、信号分析器1036は送受信機110からの無線信号を分析してその信号強度を決定し得る。この情報をコンピュータ106にフィードバックとして戻すことによって、強い信号が維持されているか、及びビーム形成方向及び角度広がりの予測的調整が有効であるかの評価を可能にすることができる。いくつかの実施態様では、フィードバックデータは、HMD102へのビデオデータの送信に利用されるものとは別の通信チャネル及び/または別の通信プロトコル/コンテキストを介して提供される。たとえば、いくつかの実施態様では、フィードバックデータは、(送受信機110を介して送信されるのではなく)ネットワーク112を介してHMDからコンピュータ106に送信される。例として、ネットワーク112は、HMD102がそれを通してネットワーク112に無線アクセスする無線ルータまたは他の無線ネットワーキングデバイスを含み得る。また、コンピュータ106は有線または無線接続を介してネットワーク106にアクセスし得る。
フィードバックデータを提供する目的での代替通信プロトコル/コンテキストの使用は、送受信機110を介した無線接続が失われた場合に有益であり、その場合、コンピュータ106へ戻る通信のための代替経路が可能である。フィードバックデータ、及び他の種類のデータを送信するための帯域幅要件は、ビデオデータの送信に必要な要件よりもかなり狭くできることは理解されよう。したがって、(たとえば、ビデオデータをHMDに送信するのに使用されるものよりも)帯域幅が狭い通信コンテキスト、たとえば従来のWiFi(登録商標)ネットワーク接続を介したフィードバックデータの送信は、そのような目的には十分な場合がある。
いくつかの実施態様では、フィードバックデータの送信は、HMDへのビデオデータの無線送信に使用されるものとは別の周波数帯域で行われる。たとえば、ビデオデータは60GHzの周波数帯域でHMDに送信され得、フィードバックデータは異なる周波数帯域、たとえば2.4GHzまたは5GHzの帯域で送信される。そのような実施態様では、送受信機110の送信機1030及びHMDの送受信機1034の対応する受信機は60GHzで動作するように構成され、送受信機110の受信機1032及びHMDの送受信機1034の対応する送信機は異なる周波数帯域で動作するように構成されることは理解されよう。
既に述べたように、いくつかの実施態様では、ビーム形成が送受信機110によって送信及び受信両方の目的で利用される。しかしながら、いくつかの実施態様では、ビーム形成は送受信機110によって送信のみのために選択的に利用することができ、ビーム形成は受信のためには利用されない。このようにして、(たとえば、メインローブがHMDを適切に追跡するのに失敗したために)HMDの送信が損なわれたり失われたりしても、HMDから送受信機へ戻る通信は維持される可能性が高い。他の実施態様では、ビーム形成は、送信対受信について異なる方法で利用することができる。たとえば、送受信機110による受信のためのビーム形成の角度広がりは、送受信機110による送信のためのビーム形成の角度広がりよりも大きくなるように構成され得る。これにより、受信の指向性に関していくらかの利益を提供しながらも、(HMDへの送信と比べて)HMDからの通信を受信するためのより高い信号安定性を与えることができる。
さらに他の実施態様では、送受信機110による信号受信の品質は、送受信機のビーム形成方向がHMDの方へ効果的に誘導されているか否かを示す追加のフィードバックデータとして機能することができる。
本開示の実施態様は、指向性信号送信及び/または受信を実現するための信号処理技術としてビーム形成を使用する。ビーム形成技術は、送信素子または受信素子のフェーズドアレイを動作させて、所望の方向にかつ所望の角度幅にわたって建設的干渉を意図的に生じさせることを必要とする。ビーム形成は、送信及び受信の両方に対する空間的選択性を実現するために使用することができる。おおまかに言って、送信ビーム形成は、複数の空間的に分離されたアンテナのそれぞれにおける信号の位相及び相対振幅を制御することを必要とし、受信ビーム形成は、位相及び振幅が調整されたそのようなアンテナから受信した信号を結合することを必要とする。ビーム形成の基本的な議論は、"A Primer on Digital Beamforming," Toby Haynes,Spectrum Signal Processing,March 26,1998(http://www.spectrumsignal.com/publications/beamform_primer.pdf)を参照して見つけることができ、その開示は引用により組み込まれている。
実施態様は概して、HMDの位置及び動きを決定する目的で慣性データ及び撮影画像データを使用することに関して説明しているが、本開示の原理は、HMDの位置/向き及び/または動きを決定するための任意の知られている方法と共に利用できることを理解されたい。たとえばいくつかの実施態様では、HMDは、当技術分野で知られている同時位置決め地図作成(SLAM:simultaneous localization and mapping)技術などを使用した動き及び位置追跡に利用することができる1つまたは複数の外向きカメラを含む。いくつかの実施態様では、認識可能なオブジェクト(たとえば、エミッタ(たとえば、RF、IR、可視スペクトル、レーザ、超音波、磁気など)、ライト、反射物体、タグ、成形物体、パターンなど)をローカル環境に配置して、そのような追跡を支援することができる。そのようなオブジェクトは、HMDに取り付けられた適切なセンサ(たとえば、カメラ、フォトセンシングダイオード、磁気センサ、マイクロフォンなど)によって検出することができる。そのようなセンサは、HMDの周りに分散された1つまたは複数のセンサ、またはHMDの位置特定及び追跡を可能にするために協調して動作することが可能な所定の構成のセンサのアレイを含むことができることは理解されよう。本開示の原理による予測的RFビーム形成を可能にして、完全に無線で動作するHMDを可能にするために、HMDの位置特定及び追跡のための任意の知られている方法を利用することができる。そのような実施態様の全ては本明細書では詳細に説明していないが、当業者には容易に明らかになり、本開示の一部として理解されよう。
図11Aは、本開示の実施態様による、送受信機110の送信機1030などの、ビーム形成送信機の構成要素を示す概略図である。符号化器1100は、無線送信すべき情報(たとえば、HMDに送信すべきビデオデータ)を受け取り、符号化するように構成される。符号器1100は、たとえばブロック符号化、圧縮、誤り低減のための冗長性の付加などを実行して、送信すべき情報をフォーマットし、または他の方法で処理し得る。変調器1102は、たとえば2進数を搬送波周波数にマッピングすること(たとえば、パルス振幅変調(PAM)、位相シフトキーイング(PSK)など)によって、符号化データを波形に変換する。いくつかの実施態様では、搬送波周波数は搬送波発振器1104によって生成される。具体的には示していないが、いくつかの実施態様では、変調器によって生成された波形は、周波数アップコンバート及び/または増幅することができる。
波形はビーム形成器1106に供給され、ビーム形成器1106は波形を複数の振幅調整器1108a−dと、複数の移相器1110a−dとに並列に供給する。振幅調整器及び移相器は、アンテナアレイ1114の各アンテナ1116a−dに対する波形の振幅及び位相の個別調整/チューニングを可能にする。対応する増幅器1112a−dを設けて調整された波形を増幅することによって、アンテナ1116a−dを介して送信できるようにする。アンテナアレイ1114のアンテナ1116a−dは、所定の構成で空間的に配置される。上述のように、アンテナアレイのアンテナから位相及び振幅が調整された信号を送信することによって、所望のビーム形成効果を生み出す建設的干渉及び相殺的干渉のパターンを有する波面が生成される。
図11Bは、本開示の実施態様による、送受信機110の受信機1032などの、ビーム形成受信機の構成要素を示す概略図である。アンテナアレイ1120は複数のアンテナ1122a−dを含む。アンテナアレイ1120によって受信された信号はビーム形成器1124に供給され、ビーム形成器1124は、複数の位相調整器1126a及び振幅調整器1128aを介して受信した信号の位相及び振幅をアンテナごとに個別に調整する。調整された信号は次いで結合器1130を介して結合され、結合器1130は結合された信号の増幅も行い得る。具体的には示していないが、いくつかの実施態様では、結合された信号は周波数ダウンコンバート及び/または別々に増幅することができる。
復調器1132は結合された信号を復調して符号化データを抽出し、復号器1134は符号化データを復号して元の情報を抽出する。
いくつかの実施態様では、アンテナアレイ1114(送信機アンテナアレイ)とアンテナアレイ1120(受信機アンテナアレイ)とは別々のデバイスである。しかしながら、他の実施態様では、アンテナアレイ1114及び1120は、たとえば、送信信号及び受信信号を適切に振り向けるように構成されるダイプレクサを有する同一のデバイスである。様々な実施態様において、アンテナアレイは、本開示の原理によるビーム形成を可能にするように所定の構成で配置された複数のアンテナを有するマイクロストリップ/パッチアンテナアレイまたは他の種類のアンテナアレイであり得る。当技術分野で知られているパッチアンテナは、数十から数百の個別のアンテナ素子を有し得る。
いくつかの実施態様では、(たとえば、ビデオデータをHMDに送信するための)本開示の原理による無線通信は、60GHzの周波数帯域にわたって行われる。いくつかの実施態様では、無線通信は他の周波数帯域にわたって行われ、さらに異なる周波数帯域の組み合わせを利用し得る。
図12Aに、本開示の実施態様による、複数のアンテナアレイを有するHMDを概念的に示す。図示のように、HMDは、HMD102の前部に配置されたアンテナアレイ1200と、HMD102の上部に配置されたアンテナアレイ1202と、HMD102の側部に配置されたアンテナアレイ1206と、HMD102の後部に配置されたアンテナアレイ1208とを含む。アンテナアレイは、送受信機1034による信号受信及び/または信号送信の目的でどのアンテナアレイがアクティブであるかを管理するセレクタ1210に接続される。ユーザ100が対話型の現実環境内で動くと、HMDの位置及び向きは変化し得、それによって、どのアンテナアレイが最適な位置にあるかが変わる。いくつかの実施態様では、最適な位置にあるアンテナアレイは、送受信機に最も近いか、または送受信機に最良の見通し線を提供するアンテナアレイであり得る。それに応じて、セレクタ1210は、様々なアンテナアレイ間で切り替えて、最も適した位置にあるものを選択するように構成することができる。いくつかの実施態様では、セレクタ1210は、各アンテナアレイ1200、1202、1206、及び1208からの受信信号強度を継続的に測定し、最大の信号強度を提供するものを決定し、必要であれば現在のアンテナアレイの使用から、最大の信号強度を提供するアンテナアレイの使用に切り換えるように構成される。
符号1204に示されているのは、1つのアンテナアレイの拡大図である。各アンテナアレイは複数の個別のアンテナ素子1205を含むことができる。
図12B、図12C、及び図12Dに、本開示の実施態様による、HMD上のアクティブアンテナアレイの切り替えを示す、対話型の現実環境におけるHMDの俯瞰図を示す。図12Bでは、HMD102の前面は送受信機110の方を向いている。本開示の実施態様によれば、送受信機110はビーム形成方向1220がアンテナアレイ1200の方へ向けられており、これはHMDの現在のアクティブアンテナアレイであり、そこから受信された信号が処理されてビデオデータが抽出/復号され、HMD上にレンダリングされる。さらなるアンテナアレイ1206a、1206b、及び1208は現在非アクティブ状態にあり、すなわち、これらのアンテナアレイから受信された信号は、アンテナアレイ1200の場合のようにビデオレンダリングのために特段処理されない。しかしながら、アンテナアレイ1206a/b及び1208の信号を監視し続けて、たとえば、それらの信号強度を決定することによって、どのアンテナアレイが所与の瞬間に最適な位置にあるかを決定し得る。
図12Cでは、HMDは時計方向に回転しており、それによってアンテナアレイ1200が動かされている。送受信機はそれに応じてビーム形成方向1222がアンテナアレイ1200へ向けられるように調整され、本明細書で論じる原理に従って予測的に誘導され得る。アンテナアレイ1200はアクティブアンテナアレイとして留まり、その他は非アクティブである。
しかしながら、図12Dでは、HMD102は、アンテナアレイ1206aが現在最も近い点まで回転しており、最も遮られていない見通し線を送受信機110に提供する。したがって、アクティブアンテナアレイは、アンテナアレイ1200からアンテナアレイ1206aに切り替えられる。加えて、送受信機のビーム形成方向は、アレイ1200の代わりに新たにアクティブになったアンテナアレイ1206aの方へ向け直される。
いくつかの実施態様では、対話型環境におけるHMDの向き(たとえば、送受信機に対する向き)は、前述のように慣性データ及び撮影画像データを使用して決定できることは理解されよう。次いで、HMDの向きを利用して、どのアンテナアレイがHMDによる信号受信に最も適しているかを決定することができる。加えて、現在説明しているアンテナ切り替え方式は、HMDの予測された将来の向きに基づいてアンテナアレイがアクティブ化または非アクティブ化されるように、予測的に実行することができる。
図13に、本開示の実施態様による、(たとえばHMDの)ディスプレイのリフレッシュを示す。多くのディスプレイでは、ディスプレイのコンテンツは行単位でレンダリングされ、これはスキャンアウト、リフレッシュまたは更新とも呼ばれる。上から下の順に1行ずつレンダリングされる。各行において、その行に関連付けられたピクセルは左から右にリフレッシュされる。この種類のレンダリングは、ディスプレイ上の全てのピクセルに対して同一のリフレッシュ周波数を提供する。
本明細書に提示した実施態様はディスプレイ内に異なる領域を定義し、各領域内のピクセルは異なるレンダリング優先度が与えられる。レンダリング優先度は、ピクセルの表示方法を決定する。一実施態様では、ピクセルのレンダリング優先度が高いほど、そのピクセルはより頻繁にリフレッシュされる。
本明細書で使用される場合、ディスプレイ上の特定された領域に対するレンダリングポリシーは、特定された領域がスキャンアウトされる方法を決定する。レンダリングポリシーは、領域が表示されるべき方法を特定する1つまたは複数の値(または画質設定)を含む。一実施態様では、レンダリングポリシーは、領域についての画面更新の周波数(たとえば、毎秒30回であるが、他の値も可能である)、レンダリング解像度、領域における画像のレンダリングの複雑度、レンダリング順序値、またはユーザのビューをレンダリングするために使用される画像データの画質及び/または量に影響を及ぼし得る他の設定のうちの1つまたは複数を含む。
レンダリング解像度によって、領域内の全てのピクセルが個別にリフレッシュされるか否かが決まる。最大解像度(たとえば100%)では、領域内の全てのピクセルが色及び明るさの個々の値と共にリフレッシュされる。しかしながら、領域の解像度を下げられることもあり(たとえば64%)、これは領域内のピクセルの一部のみがパスごとにリフレッシュされることを意味する。たとえば、50%のレンダリング解像度では、領域内のピクセルの半分が1サイクルでリフレッシュされ、残りの半分が次のサイクルでリフレッシュされる。
領域内の画像のレンダリングの複雑度は、領域内のピクセルのピクセル値を生成するために必要な処理量に基づく。たとえば、均一な色の背景領域、または背景画像のピクセル値で塗りつぶされた領域は、動くアバターを含む領域よりもレンダリングが複雑にならない。アバターのいくつかの属性に応じて複雑度が大きく増加し得、たとえば、アバターが自由になびく長い髪を含む場合、アバターが体毛のある動物である場合などである。さらに、鏡を含む領域は、鏡の画像がユーザの視線に依存するので、ピクセル値を決定するための処理も複雑になり得、鏡の向きを決定するための計算が必要となり得る。
他の実施態様では、領域の定義は、ピクセル情報を記憶するために使用されるメモリセルの数を減らすことによって変更される。この場合、領域の定義が最大値を下回った場合、ピクセルデータを記憶するために使用されるメモリがそれに応じて減少する。たとえば、25%の定義を有する領域は、100%の定義に関連付けられたメモリの25%しか使用しない。これは、領域内の4ピクセルのグループのスキャンに同一のピクセルデータが使用されることを意味する。
また、ディスプレイ技術により、領域に関連付けられたソースメモリをアップスケーリングすることによって、ピクセル領域を埋めることができる。他の実施態様では、アップスケーリングまたはダウンスケーリングのための様々な方法が使用され得、たとえば、ニアレストネイバー補間、ミップマッピングを使用したニアレストネイバー、バイリニアフィルタリング、トリリニアフィルタリング、または異方性フィルタリングなどがある。
たとえば、バイリニアフィルタリングは、第2の複数のピクセルを使用してディスプレイの領域上に第1の複数のピクセルを表示する場合にテクスチャを平滑化するためのテクスチャフィルタリング方法であり、ここで第2の複数のピクセルのピクセル数は第1の複数のピクセルのピクセル数と異なる。換言すれば、第2の複数のピクセルは、第1の複数のピクセルの(アップまたはダウン)スケーリングを必要とする。
多くの場合、画面上にテクスチャのある形状を描画する場合、テクスチャは歪みなく記憶された通りに正確に表示されない。このため、ほとんどのピクセルは、テクセル(テクスチャ空間の単位)がそれぞれのセル内のどこかに位置する点であると仮定して、テクセル間にあるテクスチャ上の点を使用することが必要になってしまう。バイリニアフィルタリングはこれらの点を使用して、ピクセルが表す点(通常、ピクセルの中央または左上)に最も近い4つのテクセル間でバイリニア補間を実行する。
1つの領域の解像度または定義を低下させることによって、ユーザにより良い体験を提供するためにより重要となる画面上の他の領域に計算リソースが割り当てられ得る。
レンダリング順序値は、領域がレンダリングされる順序を定義するためにコンピューティングデバイスによって割り当てられる値である。一実施態様では、コンピューティングデバイスは各領域にレンダリング順序値を提供し、次いで、レンダリング順序値によって定義された順序で全ての領域がスキャンアウトされる。換言すれば、コンピューティングデバイスは、レンダリングされる全ての領域のソートされたリストを生成する。
一実施態様では、1つまたは複数のレンダリングルールがレンダリングポリシーを定義する。たとえば、レンダリングポリシーは、1つのルール(たとえば、ピクセルを左から右へ、及び上から下へ表示する)を含み得、または2つ以上のルールを含み得る。たとえば、第1のルールは、ディスプレイの中央の領域がディスプレイの周辺の領域よりも高い優先度を有することを定義し得、第2のルールは、ゲームキャラクタがいる領域がゲームキャラクタがいない領域よりも高いレンダリング優先度を有することを定義し得る。
図14に、本開示の実施態様による、HMDのディスプレイ上に表示されるゲームシーンを示す。いくつかの実施態様では、視線追跡及びHMD動き追跡を使用して、HMDディスプレイ1402上の異なる領域のスキャンアウトを優先させる。
一実施態様では、画面は複数の領域またはセクションに分割され、領域は異なる優先度及び異なる解像度レベルで更新される。これは、一部の領域が他の領域よりも頻繁に、またはより高い解像度でリフレッシュされ得ることを意味する。
ユーザが視線を変更しようとしている場合に、目の動きと比較して頭の動きがわずかであっても、頭を同一の方向に動かす生来の本能があるので、HMD追跡はユーザが視線を投影しようとしている場所を決定するのを支援する。たとえば、ユーザがまっすぐ前を見ており、頭が(HMDと共に)左へ動き始めた場合、コンピューティングデバイスは、ユーザが視線を左に動かすことになると予測する。この検出に応答して、画面の左側の領域は画面の右側の領域よりも高い優先度でレンダリングされる。実際に、シーンが左にシフトすると、画面の右縁の方の領域が視野から消える可能性が非常に高い。
異なる領域のスキャンアウトを優先することにより、ユーザが見ている場所またはユーザが次に見ようとしている場所に焦点を合わせることによってユーザにより良い体験を与え、コンピュータリソースをより効率的に利用して、ユーザのビューをより高速かつより高品質にレンダリングすることが可能になる。
本明細書に記載の実施態様に従ってビデオデータがHMDに無線送信される場合、帯域幅は限られている場合があり、及び/またはユーザの動きに応じて変化し得るので、利用可能な無線伝送帯域幅を効率的に利用することがさらに重要となることは理解されよう。このように、本明細書に記載の優先レンダリング方法はより効率的なデータ使用を可能にし、これにより、ユーザ体験全体を向上させることができ、たとえば、より滑らかな視聴体験のためのより高いフレームレート及び/またはより少ないドロップフレームが可能になる。
視線の動きよりもHMDの動きを検出する方が速いことがあるので、HMD動き追跡は重要である。場合により、HMDを視覚的に追跡するコンピューティングデバイスは、HMDよりも多くの計算リソースを有するので、コンピューティングデバイスはHMDの動きを検出し、HMDの動きに基づいてHMDの軌道を予測することができる。加えて、HMDは視線の現在位置に関する情報をコンピューティングデバイスに提供し、コンピューティングデバイスは視線の軌道をより良く予測するために両方の情報源を組み合わせることができる。
図14に、仮想現実ゲームの画面を示す。本明細書で提示する実施態様は、画面がコンピューティングデバイスによって生成されたシーンだけを表示する、仮想現実ディスプレイを参照して説明する。しかしながら、本明細書に提示する原理は、画面上のビューが現実世界の画像とコンピューティングデバイスが生成した画像との組み合わせである、拡張現実ゲームにも適用され得る。一実施態様では、ゲームは広範な仮想世界でプレイされる。ユーザは常に仮想世界の一部のみを見ており、ユーザは仮想世界を動き回ることができる。ユーザが仮想世界を動き回ると、仮想世界の他の部分が現れる。
いくつかの実施態様では、現在のユーザの視点1404には、ユーザの視点1404の外側の領域よりも高いレンダリング優先度が与えられる。ユーザの視点は、ユーザが視野の焦点を合わせているディスプレイ上の領域として定義される。したがって、ゲーム対話のほとんどはユーザの視点1404内で行われる。もちろん、ユーザの視線は視点1404を中心とする。
多くの人々は視野内で、左へ約90°から右へ約90°までの領域を見ることができる。しかしながら、ユーザの視野の周辺の領域ははっきりとは知覚されないが、人はそれらの周辺領域内で何らかの動きまたは変化を感じ得る。
図14に示す実施態様では、視点は画面上の長方形のセクションとして定義され、ユーザの視線はこの長方形のセクション内の中心にある。しかしながら、他の種類の視点領域が定義され得る。たとえば、一実施態様では、視点領域は、画面上のユーザの注視点の周りの円として定義される。視野角は、両目の中点から画面上の注視点までの線を基準にして定義される。そして、視点円の半径は視野角で決まる。いくつかの実施態様では、視野角は5°から45°の範囲の値を有し得るが、他の値も可能である。
いくつかの実施態様では、レンダリングポリシーは、ゲームキャラクタがいる領域が、ゲームキャラクタがいない領域よりも高いレンダリング優先度を与えられることを要求する。他の実施態様では、他のレンダリングポリシーは、ゲームキャラクタと、ゲームによって重要なゲームオブジェクトとしてランク付けされた特別なゲームオブジェクトとにより高いスキャンアウト優先度を与える。たとえば、重要なゲームオブジェクトは、出口ドア、車内または機内のナビゲーションコンソール、癒し系(soothing)ゲーム上のターゲット、敵機などであり得る。一般に、重要なゲームオブジェクトとは、ユーザが作用することができるオブジェクトであり、重要でないゲームオブジェクトとは、シーンを埋めるために背景にレンダリングされるものである。
図14では、領域1406(ゲームキャラクタ1410及び1412を含む)及び領域1408(ゲームキャラクタ1414を含む)はゲームキャラクタがいる領域であり、ディスプレイの残りの部分よりも高いレンダリング優先度が与えられる。もちろん、いくつかの実施態様では、これは最終的なレンダリング優先度を計算する際の一要因にすぎず、その理由は、レンダリング優先度は他のルールによって、たとえば、ユーザが視線または頭を動かしている場合などに変更され得るためである。
一実施態様では、ユーザが頭を速く動かすと画面上のぼけが発生し得、その理由は、速い動きはディスプレイの速い更新を必要とし、HMDがユーザの動きに追いつくための十分な計算リソースを有さない場合があるためである。HMDが速い動きをしている間のぼけを回避するために、レンダリングポリシーはユーザの動きに関連する領域のより高速なリフレッシュを開始し、他のいくつかの領域はより低い周波数またはより低い解像度でリフレッシュされ得る。HMDが動くのを止めると、より高品質のスキャンアウト画像が回復される。
さらに、ユーザの視線の軌道を予測するために、コンピューティングデバイスは、所定の期間にわたってユーザの視線の軌道を追跡し、また、所定の期間(または他の一定の期間)にわたってHMDの軌道を追跡することに留意されたい。過去データを使用して、視線の動き及びHMDの動きにおけるトレンドを分析することによって、ユーザの視線の軌道を予測する。
図14に示す実施態様は例示的であることに留意されたい。他の実施態様は、異なる種類の視点領域、異なる種類のディスプレイ、異なるレンダリングポリシーなどを利用し得る。したがって、図14に示す実施態様は、排他的または限定的なものではなく、むしろ例示的または説明的なものと解釈されるべきである。
図15に、本開示の実施態様による、優先レンダリングのためのディスプレイ内の領域の生成を示す。図15の実施態様では、等しいサイズの複数の領域が画面1502上に定義されている。例示的な実施態様では、30個の領域(6×5)を生成するグリッドが画面上に定義されている。他の実施態様では、画面上に定義される領域は同一のサイズではない。たとえば、典型的には中央の領域は、より良いユーザ体験を提供するためにより重要であるので、ディスプレイの中央の領域はディスプレイの外側の領域よりも小さい。結果的に、これらの中央の領域にはより高いレンダリング優先度が与えられる。
いくつかの実施態様では、ゲーム行動に基づいて、またはユーザがしていることに基づいて、いくつかの領域にはより高いレンダリング優先度が与えられる。たとえば、図6を参照して上記で論じたように、ユーザの頭の動きを検出し、これを使用して、ユーザの視線が存在すると予測される領域の優先度を高める。
一実施態様では、ゲームキャラクタがいる領域は、ゲームキャラクタがいない領域よりも高い優先度が与えられる。図15の例示的な実施態様では、領域1504及び1506の内側の領域はゲームキャラクタの一部を含む。一実施態様では、レンダリングポリシーは、領域1504及び1506のレンダリングの優先度を高めるルールを含む。他のレンダリングポリシーは、画面中央の領域に高いレンダリング優先度を与え、ディスプレイの周辺の領域に低いレンダリング優先度を与える。
一実施態様では、各領域のレンダリングポリシーは、優先度を決定する複数の要因またはルールを考慮して計算される。次式を使用して、領域riのレンダリングポリシーrp値を決定する。
rp(ri)=f(rule1(ri),rule2(ri),...,rulen(ri))
ここで、rp(ri)は領域riのレンダリングポリシーであり、rule1−rulenはレンダリングポリシーを決定するために定義されたポリシールールである。たとえば、1つのルールは、ディスプレイの中央の領域により高いレンダリング優先度が与えられることを指示してもよく、2つ目のルールは、ゲームキャラクタがいる領域により高いレンダリング優先度が与えられることを決定してもよく、3つ目のルールは、注視点付近の領域により高い優先度を与えてもよく、4つ目のルールは、ユーザが自分の頭を動かしている場合に、頭が向きを変えると予測される領域により高いレンダリング優先度が与えられることを決定してもよい、などといった具合である。
一実施態様では、レンダリングポリシーは、領域に対する画面更新の周波数、レンダリング解像度、及びレンダリング順序値のうちの1つまたは複数を含む。一実施態様では、領域に対するレンダリングポリシーを計算するために、各ルールに重みが与えられる。いくつかの実施態様では、重みは過去の体験に基づいて動的に調整され得る。
図16は、本開示の実施態様による、HMD上に画像をレンダリングするためのフローチャートである。このフローチャートの様々な動作は順次的に提示し説明しているが、当業者であれば、動作のいくつかまたは全てが異なる順序で実行され、組み合わせもしくは省略され、または並列に実行され得ることを理解するであろう。
動作1602において、この方法は、HMD内の1つまたは複数の第1のカメラを使用してユーザの視線を追跡する。動作1602から、この方法は動作1604に進み、ここでこの方法はHMDの動きを追跡する。動きを追跡することは、HMD内にない第2のカメラ(たとえば、図1のカメラ108)で撮影されたHMDの画像を分析することを含む。
動作1604から、この方法は動作1606に進み、ここでユーザの視線の動き(たとえば、視線の予測軌道)が視線及びHMDの動きに基づいて予測される。さらに、動作1606からこの方法は動作1608に進み、ここでHMDのディスプレイ上に定義された複数の領域に対するレンダリングポリシーが決定される。レンダリングポリシーは、視線の予測された動きに基づいて決定される。
動作1608から、この方法は動作1610に進み、以前に計算されたレンダリングポリシーに基づいてディスプレイ上に画像をレンダリングする。また、一実施態様では、HMDが動いている場合に領域のレンダリング解像度が減少し、HMDが静止した場合に領域のレンダリング解像度が増加する。
いくつかの実施態様では、HMDの動きに関する慣性情報が受信され、慣性情報はHMD内の慣性センサによってキャプチャされる。他の実施態様では、HMDの動きは、HMD内にない第2のカメラで撮影されたHMDの画像を分析することによって追跡される。さらに他の実施態様では、HMDの動きは、慣性情報と、第2のカメラで撮影された画像の画像分析の結果とを組み合わせることによって追跡される。
さらに他の実施態様では、HMD上に画像をレンダリングするための方法を提示する。この方法は、HMD内のディスプレイによって生成されたビューを見ているユーザの視線を追跡するための動作を含む。さらにこの方法は、ユーザの視線に基づいて、ディスプレイ上にレンダリングされている複数のゲームオブジェクトにレンダリング優先度値を割り当てるための動作を含む。各ゲームオブジェクトのレンダリング優先度値は、レンダリング周波数及びレンダリング解像度を定義する。また、この方法は、ゲーム内の各ゲームオブジェクトの重要度値に基づいてレンダリング優先度値を変更するための動作を含む。他の動作では、この方法は、レンダリング優先度値に従ってディスプレイ上に複数のゲームオブジェクトをレンダリングする。
他の実施態様では、実際のソース画像は、ソース画像と、そのソース画像がレンダリングされている領域とに基づいて変更される。たとえば、ゲームキャラクタを正視していない(たとえば、ゲームキャラクタがユーザの視野の中心に近くない場合)場合よりも、ゲームキャラクタを正視している(たとえば、ゲームキャラクタがユーザの視野の中心に近い)場合に、ゲームキャラクタがより詳細にレンダリングされる。
音像定位とは、検出された音の位置または発生源を方向及び距離に関して特定する聴取者の能力を指す。それはまた、仮想3D空間における聴覚刺激の配置を模擬するための、音響工学における方法を指し得る。人間の聴覚系は、両耳間の時間差及びレベル差、スペクトル情報、タイミング分析、相関分析、及びパターンマッチングを含む、音源定位のためのいくつかの手がかりを使用する。
人間には2つの耳があるが、音の位置を3次元で、すなわち、範囲(距離)、上下方向、前後、ならびに左右を特定することができる。脳、内耳、及び外耳は連携して、位置に関する推論を行う。人間は、片耳から得られる手がかりを取得し(片耳の手がかり)、両耳で受け取った手がかりを比較することによって(差異の手がかりまたは両耳の手がかり)、音源の位置を推定する。差異の手がかりの中に、到着の時間差と強度差とがある。片耳の手がかりは、音が外耳道に入って聴覚系により処理される前に元の原音が内部で修正される人間の解剖学的構造と、音源との間の相互作用からもたらされる。これらの修正は音源の位置を符号化し、音源の位置と耳の位置とを関連付けるインパルス応答を介してキャプチャされ得る。このインパルス応答は頭部インパルス応答(HRIR)と呼ばれる。任意の原音とHRIRとの畳み込みによって、音は、聴取者の耳が受信機の位置にある状態で音が音源の位置で再生されていたならば聴取者に聞こえていたはずの音に変換される。HRIRを使用して仮想サラウンド音を生成することができる。
音像定位関数f(本明細書では別名、音像関数、定位関数、時には単に「関数」という)は、音と、その音の発生源として知覚される空間内の位置とに基づいて定位音(localized sound)を生成する関数またはアルゴリズムである。定位音は、スピーカーを通して再生された場合、音が実際にはスピーカーから発生していても、音が所望の位置から発生したという印象を聴取者に与える。関数fは数学的に次のように表すことができる。
ls=f(s,l) (1)
ここでsは音(たとえば、犬の鳴き声)であり、lはその音が本来発生するはずの位置であり、lsは定位音である。音像定位関数の一例は頭部伝達関数(HRTF)であり、これは、耳が空間内のある点から音をどのように受け取るかを特徴付ける応答である。両耳についての一対のHRTFを利用して、空間内の特定の点から来たように思われるバイノーラル音を合成し得る。HRTFは、自由大気(free air)中のある方向からの音に対する、鼓膜に到達する音への修正として記述することもできる。これらの修正には、聴取者の外耳の形状、聴取者の頭及び体の形状、音が再生される空間の音響特性などがある。これら全ての特性は、音が来ている方向を聴取者がどれほど正確に言い当てられるかに影響する。各人の身体的な違いのために、各人は異なるHRTFを有する。音像定位のための本発明の実施態様はHRTFを使用して説明するが、聴取者の身体的特徴を説明する他の任意の形態の音像定位を本発明の実施態様と共に使用することができる。
図17に、音がヘッドフォン1716から直接来たと知覚するのではなく、あたかも音が仮想位置「A」から発出しているかのように、ヘッドフォン1716によって配信された音をユーザ102が知覚するよう、ヘッドフォン1716に配信される音が修正される本発明の一実施態様を示す。ローカルの対話型環境におけるHMD102及び/またはヘッドフォン1716(ヘッドセット、イヤフォン、またはイヤピースとも呼ばれる)の位置が追跡される。いくつかの実施態様では、ヘッドフォンの位置は、HMDを追跡することから推測または推論され得ることは理解されよう。ヘッドフォンの位置が分かると、コンピュータ106は、音が仮想位置Aから来ているとユーザに信じさせるために、(たとえば、ユーザのHRTFを使用して)音を操作して定位音を生成する。
図17に示す実施態様では、(音声データ/信号の形態の)定位音はヘッドフォン1716によるレンダリングのために無線送信され、これは無線でも有線でもよい。いくつかの実施態様では、音声データ/信号はHMD102に無線送信され、次いでHMD102は音声データ/信号をヘッドフォン1716に(たとえば有線接続を介して)送信して音をレンダリングし得る。いくつかの実施態様では、音声データ/信号は、ヘッドフォンへ送信する前にHMD102によってさらに処理される。たとえば、HMDによって受信される無線送信される音声データは、音声に対する無線帯域幅要件を低減するために、圧縮音声フォーマットへデジタルに符号化され得る。したがって、HMD102は符号化された音声データを復号して、ヘッドフォンに送信されるアナログ音声信号を生成し得る。定位音がヘッドフォン1716によって再生されると、ユーザはその音を仮想位置Aから来たものと知覚する。
他の実施態様では、音声データ/信号は、HMD用のものとは別の無線伝送信号を使用してヘッドフォンに直接無線送信される。そのような実施態様では、画像データ及び音声データは、別々の伝送信号を使用して、それぞれHMD102及びヘッドフォン1716に別々に送信される。しかしながら、本明細書に記載のビーム形成技術が両方に適用できることは理解されよう。
異なる人々は異なるHRTFを有し、ユーザのHRTFが利用された場合に、最も迫力のある体験が提供される。一実施態様では、ユーザのHRTFが利用できない場合に、標準HRTFが利用される。標準HRTFは人間の平均的な特性を考慮したものである。ユーザのHRTFは利用されないが、標準HRTFはなおもユーザにリアルな体験を提供することができる。また、較正方法を利用して、音像定位体験を特定のユーザ用にさらにカスタマイズすることによって、そのユーザのHRTFを開発することができる。
ヘッドフォンの位置を追跡するための複数の方法が存在し、これらはユーザの耳の位置を定義する。一般に、本明細書ではユーザの耳の位置を追跡すると称し、その理由は、耳の位置によって音がどのように定位されるかが決まるためである。説明を容易にするために、本明細書では、ユーザの位置を追跡する、ユーザの頭の位置を追跡する、HMDの位置を追跡する、またはユーザが装着しているヘッドフォンの位置を追跡する、と称することがある。耳の位置は頭、ユーザ、HMDまたはヘッドフォンの位置から推測できるので、これらの追跡方法は全て等価である。
図17の実施態様では、ヘッドフォン1716は、発光ダイオード(LED)1714などの光源を含むことができる。カメラ108はユーザ100が位置する空間の画像を撮影し、次いでコンピュータ106は画像分析を実行してLED1714の位置を決定する。画像内のより明るい部分は、LEDの位置を特定するのに役立つ。また、カメラ108からヘッドフォンまでの距離は、カメラ108によって撮影された画像内のLED1714のサイズに基づいて推定される。LED1714の位置が決定されると、ヘッドフォンの物理的特性に従って、LEDが両耳の間かつ両耳を結ぶ線の数インチ上に位置すると仮定することによって、ユーザの耳の位置が推定される。
図17に示す実施態様は例示的であることに留意されたい。他の実施態様は、ユーザの耳の位置を追跡するために異なる方法を利用し得、または追跡方法の組み合わせを利用して精度を高めることができる。たとえば、位置追跡は、顔認識、超音波通信、RFID、赤外光、全地球測位システム(GPS)などを使用して実行することができる。したがって、図17に示す実施態様は、排他的または限定的なものではなく、むしろ例示的または説明的なものと解釈されるべきである。
音響投影(sound projection)はユーザに迫力のある体験を提供し、聴取体験からヘッドフォンを「消失」させる。ユーザは、耳付近に位置する2つのスピーカー要素から音が来ていると感じず、むしろ空間内の特定の点から音が来ていると感じ、この特定の点は状況に応じて、ポータブルデバイス、ゲームの仮想要素、仮想ユーザなどに関連付けることができる。仮想音源が変化するにつれて、またはユーザの位置が変化するにつれて、音響投影は音が正しい位置から発出しているように感じられるよう適応する。
図18に、本開示の実施態様による、ユーザがHMDを介してリアルな音の配信と共にVR環境を見ていることを示す。プレイヤー100は部屋の中にいるが、本明細書では仮想シーンとも呼ばれる仮想現実は、部屋の物理的境界を超えて広がり得る。仮想シーンの基準点1802はテーブル1804の上に位置している。一実施態様では、点P01802は基準点であって、座標(X0=0,Y0=0,Z0=0)を有する座標原点でもある。プレイヤー1806bはプレイヤー100と同じゲームをプレイしているが離れた場所におり、プレイヤー1806bはプレイヤー100に対してゲーム内の仮想要素として描写されている。プレイヤー1806bはポータブルデバイス1808bを保持しており、これはプレイヤー1806bが位置する物理空間内の他の基準点に同期されている。
1つ例示的な実施態様では、(HMDの画面を透かして見られる)仮想シーンのジオメトリは少なくとも部分的に基準点に基づくので、仮想シーンは基準点に関するものである。たとえば、仮想シーン内の仮想オブジェクトの座標は基準点に対して決定され得る。
座標は任意の測定基準を使用して測定することができる。しかしながら、視覚的な例を提供するために、また、使用される実際の座標を限定せずに、仮想シーンの座標がメートルで測定される場合、座標(1,0,0)を有するオブジェクトは基準点の1メートル右に位置することになる。もちろん、現実または仮想オブジェクトの座標は、仮想オブジェクトがシーン内を動く場合など、シーンが変化したときに動的に更新され得る。また、その変化は、コンピュータによって設定された行為によって定義されるか(たとえば、対話型プログラム)、ユーザの行為によって駆動されるか、またはその両方の組み合わせとすることができる。加えて、明確にするために、対話型プログラムは任意の種類のプログラム、たとえば、ビデオゲーム、ビジネスプログラム、インターネットインターフェース、または単に、データ、他のユーザ、プログラム、あるいは表示またはスピーカーによる投影がされてもされなくてもよいオブジェクトへのアクセスを提供するグラフィカルユーザインターフェースとすることができる。
またさらに、他の実施態様は異なる座標系を有するか、またはスケーリングを使用し得る。たとえば、座標系は、デカルト座標系の代わりに、極座標系、球面座標系、放物線座標系などとすることができる。加えて、基準点は座標系の原点である必要はなく、他の場所に配置することができる。一例を提供するために、基準点を座標(5,5,5)に配置することによって、5メートルを超える点で負の座標値を使用しなければならなくなる前に、各方向に5メートルのバッファを使用可能にすることができる。他のシナリオでは、仮想オブジェクトは一定の縮尺で生成され、座標も一定の縮尺で測定される。たとえば、仮想オブジェクトは1:10の縮尺で構築され得、ジオメトリの軸も1:10の縮尺を有することができ、その結果、座標(1,0,0)を有するオブジェクトは「現実」世界では1メートル離れており、仮想世界では10メートル離れている。
図18では、仮想オブジェクトは、ヘリコプター1814a−1814c、雲、鳥、太陽1816などを含む。プレイヤー1806aがポータブルデバイス1808aを動かすと、あたかもプレイヤーが仮想世界の中へのカメラを持っているかのように仮想シーンのビューが変化する。デバイス1808aに表示されるビューは基準点を含んでも含まなくてもよいことに留意されたい。部屋はテーブル1804以外の他の静的オブジェクト、たとえば、テレビ1812及び窓1810を含む。
図18に示すように、仮想オブジェクトは空間内のどこにでも配置することができる。ポータブルデバイスがカメラを含む場合、室内の静的特徴をポータブルデバイスが使用して、カメラからのビューで慣性測定値を調整することによって、現在位置の正確な測定値を維持することができる。ポータブルデバイスにおける画像分析は、窓の縁、光源、テーブルの縁、壁の絵、テレビなどを検出することができる。
コンピュータ/ゲームコンソール106は、拡張現実環境を配信するための情報をポータブルデバイス1808aと交換する。この情報は、ゲーム情報、ユーザ追跡、ポータブルデバイスの位置、仮想オブジェクトの位置、リモートプレイヤーの位置などのうちの1つまたは複数を含む。
一実施態様では、ゲームコンソール106は、プレイヤー100の耳の位置を追跡する。ゲーム内で音(たとえば、ヘリコプターが飛行する音)が生成された場合、ゲームコンソール106は音の発生源の仮想空間内の座標を決定する。耳の位置及び音の発生源の位置が分かると、ゲームコンソール106は、音の発生源と、音を知覚している耳との間の相対位置を決定する。
一実施態様では、ユーザ100はヘッドフォン1716を装着している。ユーザのHRTFを使用して、音を、ユーザには音の発生源から来たように感じられる定位音に変換する。(場合により上述のようにHMDを介して)ヘッドフォン1716に送信される定位音は、音の発生源の位置を模擬するための、ヘッドフォンの各個別のスピーカーについての異なる音響信号を含む。
他の実施態様では、定位音はスピーカー1820によって生成される。ゲームコンソール106は、室内のスピーカー1820の位置に関する情報を有する。この場合もやはり、ユーザのHRTFを使用して、音を、ユーザには音の発生源から来たように感じられる定位音に変換する。スピーカー1820に送信される定位音は、音の発生源の位置を模擬するための、各スピーカー1820についての異なる音響信号を含む。
この場合、定位音はヘッドフォンではなくスピーカーに配信される。スピーカーを使用する音像定位のためのアルゴリズムと、ヘッドフォンを使用するものとは類似しているが、スピーカーの場合、位置は固定されているのに対し、ユーザの位置は変化し得る。各スピーカーから来る音には移動時間が存在し、これは音像定位アルゴリズムによって考慮される必要がある。ヘッドフォンの場合、ユーザが動くとヘッドフォンが動くので、位置を追跡する必要がある。
音像定位アルゴリズムはユーザのHRTF、ならびにユーザの耳の現在位置を使用して、イヤフォン用の定位音を生成する。イヤフォンによって再生される定位音の音響信号は、仮想オブジェクトの空間内の仮想位置に関する音響的な手がかりをユーザに提供する。
一実施態様では、音を発生しているオブジェクトまたは人物がHMD102のディスプレイ上に、またはゲームコンソール106に接続されたディスプレイ207(たとえば共有/ソーシャルスクリーン)内に表示されている場合、定位音の音響信号はより大きい音量で配信される。HMDはある意味では指向性マイクロフォンとしても機能する。音の発生源がHMDのディスプレイ上にない場合、音量は小さくなる。HMDは指向性マイクロフォンとして機能しているので、ユーザがHMDを動かすと、ユーザは音の発生源の所在についての音響的な手がかりを得る。
リモートプレイヤー1806bに、プレイヤー100の物理空間内の位置が割り当てられる。音像定位は、プレイヤー1806bまたはポータブルデバイス1808bから来るように感じられる音を生成することを含む。たとえば、プレイヤー1806bが話すと、その発話はポータブルデバイス1808bによってキャプチャされ、次いでゲームコンソール106に送信される。ユーザ1806bからの発話は次いで、HRTFまたは他の何らかの音像定位アルゴリズムを使用して変換され、図示した仮想シーンに示されるように、あたかもプレイヤー1806bがプレイヤー100の近くに立っているかのように、発話がユーザ100に配信される。
一実施態様では、ユーザを追跡するためにGPSが使用される。たとえば、HMDまたはゲームコンソール内のGPSモジュールを使用して、ユーザのGPS位置を決定する。ユーザ1806bが離れた場所(たとえば、数マイル離れた場所)にいる場合、ユーザ1806bのGPS位置を音響効果に使用することができる。たとえば、ユーザ1806bは、リモートプレイヤーによって発砲されるゲームの大砲を持っている。効果音は、ユーザ1806bの実際の位置からの大砲の発砲を模擬する。発砲のショットが最初に聞こえ、その後、砲弾がプレイヤー1806bの場所からプレイヤー100の場所まで空中を移動するときに、砲弾の音が続く。砲弾が空中を移動するにつれて、現実生活のように音の強度が増す。最後に、砲弾が標的に当たった場合に爆発が聞こえ、標的がユーザの近くにいる場合は、音が大音量で配信されることになる。
図19は、本発明の実施態様による、音源を模擬するための音像定位アルゴリズムのフローチャートである。動作1902において、ユーザの頭の空間内での位置が特定され、ここでユーザは2つのスピーカーを含むヘッドフォンを装着している。前述のように、超音波、画像分析、RFID、GPS、赤外線などの複数の方法を利用してヘッドフォンの位置を決定することができる。さらに、動作1904において、スピーカーに配信すべき音が決定され、各スピーカーはユーザの片耳に関連付けられる。換言すれば、一方のスピーカーは左耳の隣に位置し、他方のスピーカーは右耳の隣に位置する。動作1906において、音の発出位置が決定される。音の発出位置とは、音がその音の発生源から来ているという印象をユーザが得るようにユーザに配信されることになる音の仮想的な発生源を定義する空間内の点を指す。
動作1908において、各スピーカー用の音響信号が、空間内での頭の位置、音、空間内の発出位置、及びユーザの聴覚特性に基づいて確立される。ユーザの聴覚特性は、音がどこから来るかをユーザがどのように定位するかに影響を及ぼすユーザの身体的側面を定義する。一実施態様では、ユーザの聴覚特性は、ユーザの両耳に関する一対のHRTFによって定義される。
動作1908の後、この方法は動作1910に進み、ここで音響信号が2つのスピーカーに送信される。音響信号が2つのスピーカーによって再生された場合、音は空間内の発出位置から発生しているように感じられる。
図20に、本開示の実施態様による、受け取った音のユーザの知覚に基づいて音像定位関数を選択するための方法を示す。ヘッドフォンによるバーチャルサラウンドは、人のHRTF(または他の何らかの音像定位関数)の正確な測定と共に最良に動作する。HRTFを測定するプロセスは困難である(すなわち、このプロセスは、小型のマイクロフォンを人の耳に入れ、背筋を伸ばして座った状態で、スピーカーを頭の周りの様々な位置及び距離に動かすことを必要とする)。本発明の実施態様は、ユーザの集団について測定されたHRTFのデータベースを利用する。一実施態様では、モーションコントローラを利用して、データベースの1つまたは複数のHRTFに基づく、ユーザの音像定位関数を生成する。ユーザのHRTFは実際には測定されないが、ユーザに「効果的な」1つまたは複数のHRTFを見つけることによって、定位音の配信を行うリアルなバーチャルサラウンドシステムが提供される。
何百万人のユーザに対して音像定位関数を有することは現実的ではない。本発明の実施態様は、人々の代表的なセグメントに対して測定された音像定位関数を利用し、次いで特定のユーザに対してこれらの関数のうちの1つを選択するためのテストが実行される。
図20の実施態様では、ユーザ100は室内におり、HMD102及びヘッドフォン1716を装着している。ヘッドフォンの代わりに複数のスピーカー2002を使用して較正プロセスが実行されてもよいことに留意されたい。コンピュータシステムはヘッドフォン1716を介して音を再生し、ユーザは、音源であったとユーザが思う方向2008aにコントローラ104aを向けるように求められる。ユーザによって音の発生源として特定された方向2008aに基づいて、システムはこの方向に合致する1つまたは複数の音像定位関数をデータベースから選択する。換言すれば、ユーザ100による各応答の後、システムはユーザ100の特性を満たす可能性がある音像定位関数を絞り込む。
一実施態様では、ユーザに2つの選択肢が提供される。ユーザがどこから音が来ているか分からない場合、ユーザが分からないことを示すためにコントローラの第1のボタンが押される。一方、ユーザが方向を特定した場合、ユーザは音の方向を指しながら第2のボタンを押す。これにより人々は、音像定位関数(たとえば、HRTF)のデータベースを検索することによって適切な音像定位関数を見つけ、ユーザ入力(たとえば、コントローラによって特定された方向)に最も近く合致する関数を見つけることが可能になる。
このプロセスは様々な位置にある他の音を使用して繰り返される。コントローラの位置(たとえば104b、104c)に基づいて音ごとに新たな方向(たとえば2008b、2008c)が得られ、音像定位関数を分析して、その位置に最も合致するものを見つける。一実施態様では、最も合致するものは、全てのテスト音に対して最良の全体的な性能を提供する音像定位関数である。
他の実施態様では、この特定のユーザについての関数は音像関数の組み合わせであり、ここで、ユーザの周囲の空間はセクタに分割され、各セクタから来る音はそのセクタに関連付けられた関数を使用し、各セクタは異なる関連付けられた関数を有する。一実施態様では、補間が使用され、いくつかのセクタは2つ以上の関数からの補間を使用する。所望の目標は完璧に選択された関数を得ることではなく、むしろ目標は、特定のゲームまたはある範囲のゲームに必要な3D体積を埋めるのに十分な、様々な位置におけるいくつかの許容できる関数を得ることである。特定数の離散的な伝達関数がただ1つの関数を選択するよりも優れていると考えられる場合、ただ1つの関数を選択する必要はない。一実施態様では、ユーザの周囲の3−D空間全体に対してテストを行うことは非常に退屈であるので、実際のテストが実行されていない領域のギャップを埋めるために補間が使用される。
各テストで再生される音は、同一の音であるが異なる位置から投影され得、または異なる音声周波数のデータを取得するために、音は位置ごとに変化し得る。これにより、ユーザは全ての音がまったく同一であり、音が同一の場所から来ていると感じないので、ユーザの混乱を減らし得る。
1つの伝達関数が全てのテスト音についてのユーザの音響特性と適切に合致しない場合、一実施態様では、ユーザに対して計算された音像関数は、音が来ている領域だけではなく、生成されている音の種類(たとえば、音についての支配的な周波数)も考慮に入れた関数の組み合わせとなる。たとえば、3−D空間内の特定のスポットでは、第1の関数が低周波数の音に使用され、第2の関数が高周波数または中周波数の音に使用され得る。
ユーザ100に関連する関数は既知ではないので、データベースから音像定位関数f1を選択して較正プロセスを開始する。ユーザが104aを方向2008aに向けると、システムは、f1を使用して音が生成された場合に、どの定位関数fuまたは複数の関数がこの応答をもたらし得るかを分析する。換言すれば、システムはf1をデータベース内の他の関数に関連付ける必要がある。sがテスト用に選択された音(たとえば、犬の鳴き声)であり、l1が音の位置であり、ls1がスピーカーに配信される定位音である場合、式(1)は次のようになる。
ls1=f1(s,l1) (2)
ユーザが方向2008aを指すと、方向2008aに基づいて位置l2が計算される。fuがこのユーザ及び位置l2について音sに合致する関数である場合、次式が得られる。
ls1=fu(s,l2) (3)
これは、同一の音のテスト(たとえば、犬の鳴き声)の場合、f1及びfuはスピーカーに送られる同一の音を生成するはずであるが、音像定位関数が異なるためにユーザに知覚される位置が変化することを意味する。換言すれば、関数f1を有するユーザはl1から来る音を知覚し、関数fuを有するユーザはl2から来る音を知覚する。
式(2)及び式(3)を組み合わせると、以下の恒等式が得られる。
f1(s,l1)=fu(s,l2) (4)
f1、s、l1、及びl2は既知であるので、式(4)を利用してfuを得ることができる。しかしながら、fuは位置l2ではこのユーザに効果的であるが、fuは他の位置では効果的でない場合があることに留意されたい。データベース内の多くの関数について式(4)が満たされ得るので、異なる位置でテストを継続することにより、システムは、可能性のある関数の中でこのユーザにさらに効果的なものを選択することが可能になる。一実施態様では、テストプロセスは、1つの最終的な関数(ユーザの特性により良く合致するもの)が選択されるまで、効果的でない関数を排除して継続する。
一実施態様では、同一の関数f1が全てのテストに使用される。他の実施態様では、システムがこのユーザにとって最も効果的な1つまたは複数の関数の微調整を開始すると、テストごとに使用される関数が変化する。たとえば、2回目のテストでは、前回のテストで得られた選択された関数fuが、f1の代わりに2回目のテストに使用される。2回目のテストの後、2つの測定値に基づいて新たな関数fu2が選択される。そして、このプロセスを繰り返して、全てのテストの測定値に基づいて、各テスト後に新たな関数を計算する。
較正が行われている間にユーザが頭を動かすと、その動きによって結果が変わり得ることに留意されたい。一実施態様では、音は短く、頭の動きの影響は排除され、またはかなり低減される。他の実施態様では、ユーザの頭が追跡され、これはテスト中に耳の位置が分かっていることを意味する。一実施態様では、ユーザの撮影画像を分析することによって頭部追跡が実行されるが、磁力計付きヘッドフォンなどを使用するなど、他の方法も利用され得る。
図21は、本発明の実施態様を実装するためのコンピュータシステムの簡易な概略図である。本明細書に記載の方法は、従来の汎用コンピュータシステムなどのデジタル処理システムを使用して実行され得ることを理解されたい。1つまたは複数の特定の機能を実行するように設計またはプログラムされた専用コンピュータが代替で使用され得る。コンピューティングデバイス106はプロセッサ2132を含み、プロセッサ2132は、メモリ2134、永久記憶デバイス2158、及びコンピューティングデバイス106内の、またはこれに接続された他のモジュールに結合される。音像定位コンピュータプログラム2136はメモリ2134内に存在するが、永久記憶デバイス2158に存在することもできる。
コンピューティングデバイス106は、音声/超音波キャプチャデバイス2108、画像撮影デバイス108、及びディスプレイ207と通信する。一実施態様では、音声キャプチャデバイス2108、画像撮影デバイス108、RFIDモジュール2106、及びディスプレイ207は、コンピューティングデバイス106内に組み込まれ得、または別個のユニットであり得る。一実施態様では、超音波キャプチャデバイスはマイクロフォンを含み、他の実施態様では、超音波キャプチャデバイスはマイクロフォンアレイを含む。
デバイス位置追跡モジュール724は、HMD102、ヘッドフォン1716、コントローラ104などのデバイスの位置を決定する。位置追跡には複数の技術、たとえば、超音波、GPS、RFID、画像分析、三角測量、慣性など、またはそれらの組み合わせを使用することができる。頭部追跡モジュール2138は、ユーザの片耳または両耳の位置を決定する(これはヘッドフォンの位置を決定することによって間接的に決定され得る)。頭部追跡モジュール2138は、たとえば、画像認識、RFID、超音波、赤外線、三角測量などの1つまたは複数の異なる技術を使用して、またはHMDもしくはヘッドフォンなどのユーザにより装着されたデバイスの追跡に基づいて、ユーザの耳の位置を決定し得る。
音響投影モジュール2116は、音像定位を実行するために、音響システムへの配信が意図された音響信号を修正して、修正された音響信号を受け取ったユーザが、音が意図された位置から発出しているという印象を受けるようにする。音響投影モジュール2116は、デバイス位置追跡モジュール2124及び頭部追跡モジュール2138によって提供された位置情報を使用して音声信号を修正する。
永久記憶デバイス2158は、フロッピー(登録商標)ディスクドライブまたは固定ディスクドライブなどの永続的なデータ記憶デバイスを表し、これはローカルでもリモートでもよい。ネットワークインターフェース746はネットワーク接続を提供して、他のデバイスとの通信を可能にする。プロセッサ2132は、汎用プロセッサ、専用プロセッサ、または専用にプログラムされた論理デバイスで具現化され得ることを理解されたい。入出力(I/O)インターフェース2142は、たとえば、ディスプレイ207、キーボード2152、マウス2150、超音波キャプチャデバイス2108、画像撮影デバイス108、スピーカー1820、ヘッドフォン1716、ボタン、センサ、タッチスクリーン2156などの様々な周辺機器との通信を提供する。ユニバーサルシリアルバス(USB)モジュール2144は、USBデバイスへの接続を提供する。
HMD102及び/またはディスプレイ207は、本明細書に記載のユーザインターフェースを表示するように構成される。キーボード2152、マウス2150、及び他の周辺機器は、情報をプロセッサ2132に通信するためにI/Oインターフェース2142に結合される。外部デバイスとの間のデータは、I/Oインターフェース2142を介して通信され得ることを理解されたい。本発明は、有線または無線ネットワークを介してリンクされたリモート処理デバイスによってタスクが実行される分散コンピューティング環境で実施することもできる。
データベース2110は、複数の異なるユーザに関連する複数の音像定位関数を含む。一実施態様では、音像定位関数は、複数のユーザについて得られた測定されたHRTF関数であるが、他の音像定位関数を利用することもできる。ユーザ用の音像定位関数であって、他のユーザ用に得られた既存の関数を活用したものを、データベース2110を使用して構築することができる。
図21に示す実施態様は例示的であることに留意されたい。他の実施態様は、異なるモジュールを利用すること、または1つのモジュールによって実行されるいくつかの機能を有することなどが可能である。したがって、図21に示す実施態様は、排他的または限定的なものではなく、むしろ例示的または説明的なものと解釈されるべきである。
図22に、本発明の実施態様を実装するために使用され得るデバイスのアーキテクチャを示す。ヘッドマウントディスプレイはコンピューティングデバイスであり、コンピューティングデバイス上に通常見られるモジュール、たとえば、プロセッサ2204、メモリ2216(RAM、ROMなど)、1つまたは複数のバッテリ2206あるいは他の電源、及び永久記憶装置2248(ハードディスクなど)を含む。
通信モジュールは、HMDが他のポータブルデバイス、他のコンピュータ、他のHMD、サーバなどと情報を交換することを可能にする。通信モジュールは、ユニバーサルシリアルバス(USB)コネクタ2246、通信リンク2252(Ethernet(登録商標)など)、超音波通信2256、Bluetooth(登録商標)2258、及びWiFi2254を含む。
ユーザインターフェースは入力モジュール及び出力モジュールを含む。入力モジュールは、入力ボタン、センサ及びスイッチ2210、マイクロフォン2232、タッチ感応スクリーン(図示しないが、これはHMDを構成または初期化するために使用され得る)、フロントカメラ2240、リアカメラ2242、視線追跡カメラ2244を含む。キーボードまたはマウスなどの他の入出力デバイスは、USBまたはBluetoothなどの通信リンクを介してポータブルデバイスに接続することもできる。
出力モジュールは、ユーザの目の前に画像をレンダリングするためのディスプレイ2214を含む。いくつかの実施態様は、1つのディスプレイ、2つのディスプレイ(各眼に1つ)、マイクロプロジェクタ、または他のディスプレイ技術を含み得る。他の出力モジュールは、発光ダイオード(LED)2234(これはHMDの視覚追跡にも使用され得る)、振動−触覚フィードバック2250、スピーカー2230、及びスピーカーまたはヘッドフォンに配信される音に対して音像定位を実行する音像定位モジュール2212を含む。ヘッドフォンなどの他の出力デバイスを、通信モジュールを介してHMDに接続することもできる。
動き追跡を容易にするために含まれ得る要素は、LED2234、1つまたは複数の視覚認識用オブジェクト2236、及び赤外ライト2238を含む。
異なるデバイスからの情報は、HMDの位置を計算するために位置モジュール2228によって使用することができる。これらのモジュールは、磁力計2218、加速度計2220、ジャイロスコープ2222、全地球測位システム(GPS)モジュール2224、及びコンパス2226を含む。加えて、位置モジュールは、カメラ及びマイクロフォンでキャプチャされた音または画像データを分析して、位置を計算することができる。またさらに、位置モジュールは、ポータブルデバイスの位置または近傍の他のデバイスの位置を決定するためのテスト、たとえば、WiFiのpingテストまたは超音波テストを実行することができる。
仮想現実生成器2208は、位置モジュールによって計算された位置を使用して、前述の仮想現実または拡張現実を生成する。仮想現実生成器2208は、他のコンピューティングデバイス(たとえば、ゲームコンソール、インターネットサーバなど)と協働して、ディスプレイモジュール2214用の画像を生成し得る。リモートデバイスは、画面上にゲームオブジェクトを生成するための画面更新または命令を送信し得る。
図22に示す実施態様はHMDの例示的な実施態様であることを理解されたい。他の実施態様は、異なるモジュール、モジュールのサブセットを利用するか、または関連するタスクを異なるモジュールに割り当て得る。したがって、図22に示す実施態様は、排他的または限定的なものではなく、むしろ例示的または説明的なものと解釈されるべきである。
図23は、本開示の様々な実施態様による、ゲームシステム2300のブロック図である。ゲームシステム2300は、ネットワーク2315を介して1つまたは複数のクライアント2310にビデオストリームを提供するように構成される。ゲームシステム2300は典型的には、ビデオサーバシステム2320と、任意選択のゲームサーバ2325とを含む。ビデオサーバシステム2320は、ビデオストリームを1つまたは複数のクライアント2310に最低限のサービス品質で提供するように構成される。たとえば、ビデオサーバシステム2320は、ビデオゲーム内の状態または視点を変更するゲームコマンドを受信し、この状態の変更を反映した更新されたビデオストリームをクライアント2310に最短の遅延時間で提供し得る。ビデオサーバシステム2320は、まだ定義されていないフォーマットを含む、多種多様な代替のビデオフォーマットのビデオストリームを提供するように構成され得る。さらに、ビデオストリームは、多種多様なフレームレートでユーザに提示するように構成されるビデオフレームを含み得る。典型的なフレームレートは、30フレーム毎秒、60フレーム毎秒、120フレーム毎秒である。ただし、より高いまたはより低いフレームレートが、本開示の代替の実施態様に含まれる。
本明細書で個別に2310A、2310Bなどと呼ぶクライアント2310は、ヘッドマウントディスプレイ、端末、パーソナルコンピュータ、ゲームコンソール、タブレットコンピュータ、電話、セットトップボックス、キオスク、無線デバイス、デジタルパッド、スタンドアロンデバイス、手持ち式ゲームプレイデバイス、及び/または同様のものを含み得る。典型的には、クライアント2310は、符号化されたビデオストリームを受信し、そのビデオストリームを復号し、その結果得られるビデオをユーザ、たとえばゲームのプレイヤーに提示するように構成される。符号化されたビデオストリームを受信する処理、及び/またはビデオストリームを復号する処理は、典型的には、個々のビデオフレームをクライアントの受信バッファに記憶することを含む。ビデオストリームは、クライアント2310に統合されたディスプレイ上で、またはモニタもしくはテレビなどの別個のデバイス上でユーザに提示され得る。クライアント2310は2人以上のゲームプレイヤーをサポートするように任意選択で構成される。たとえば、ゲームコンソールは、2人、3人、4人またはそれ以上の同時プレイヤーをサポートするように構成され得る。これらのプレイヤーはそれぞれ別々のビデオストリームを受信し得、あるいは単一のビデオストリームが、各プレイヤー専用に生成された、たとえば各プレイヤーの視点に基づいて生成されたフレームの領域を含み得る。クライアント2310は任意選択で地理的に分散している。ゲームシステム2300に含まれるクライアントの数は、1または2から数千、数万、またはそれ以上まで幅広く変化し得る。本明細書で使用する場合、「ゲームプレイヤー」という用語はゲームをプレイする人を指すために使用され、「ゲームプレイデバイス」という用語はゲームをプレイするために使用されるデバイスを指すために使用される。いくつかの実施態様では、ゲームプレイデバイスは、ゲーム体験をユーザに配信するために協働する複数のコンピューティングデバイスを指す場合がある。たとえば、ゲームコンソール及びHMDはビデオサーバシステム2320と協働して、HMDを通して見るゲームを配信し得る。一実施態様では、ゲームコンソールはビデオサーバシステム2320からビデオストリームを受信し、ゲームコンソールはビデオストリームまたはビデオストリームへの更新を、レンダリングのためにHMDに転送する。
クライアント2310は、ネットワーク2315を介してビデオストリームを受信するように構成される。ネットワーク2315は、電話ネットワーク、インターネット、無線ネットワーク、電力線ネットワーク、ローカルエリアネットワーク、ワイドエリアネットワーク、プライベートネットワーク、及び/または同様のものを含む任意の種類の通信ネットワークであり得る。典型的な実施態様では、ビデオストリームは、TCP/IPまたはUDP/IPなどの標準プロトコルを介して通信される。あるいは、ビデオストリームは独自の規格を介して通信される。
クライアント2310の典型的な例は、プロセッサ、不揮発性メモリ、ディスプレイ、復号ロジック、ネットワーク通信機能、及び入力デバイスを含むパーソナルコンピュータである。復号ロジックは、ハードウェア、ファームウェア、及び/またはコンピュータ可読媒体に記憶されたソフトウェアを含み得る。ビデオストリームを復号(及び符号化)するためのシステムは、当技術分野においてよく知られており、使用される特定の符号化方式に応じて変わる。
クライアント2310は、必須ではないが、受信したビデオを修正するように構成されるシステムをさらに含み得る。たとえば、クライアントは、さらなるレンダリングを実行し、あるビデオ画像を他のビデオ画像に重ね合わせ、ビデオ画像を切り取り、及び/または同様のことを行うように構成され得る。たとえば、クライアント2310は、Iフレーム、Pフレーム、及びBフレームなどの様々な種類のビデオフレームを受信し、これらのフレームをユーザに表示するための画像に処理するように構成され得る。いくつかの実施態様では、クライアント2310のメンバーは、さらなるレンダリング、シェーディング、3−Dへの変換、または同様の演算をビデオストリームに実行するように構成される。クライアント2310のメンバーは、任意選択で2つ以上の音声またはビデオストリームを受信するように構成される。クライアント2310の入力デバイスは、たとえば、片手ゲームコントローラ、両手ゲームコントローラ、ジェスチャ認識システム、視線認識システム、音声認識システム、キーボード、ジョイスティック、ポインティングデバイス、フォースフィードバックデバイス、動き及び/または位置検知デバイス、マウス、タッチスクリーン、ニューラルインターフェース、カメラ、未開発の入力デバイス、ならびに/あるいは同様のものを含み得る。
クライアント2310によって受信されたビデオストリーム(及び任意選択で音声ストリーム)は、ビデオサーバシステム2320によって生成され提供される。本明細書の他の場所でさらに説明しているように、このビデオストリームはビデオフレームを含む(また、音声ストリームは音声フレームを含む)。ビデオフレームは、ユーザに表示される画像に有意義に寄与するように構成される(たとえば、適切なデータ構造のピクセル情報を含む)。本明細書で使用する場合、「ビデオフレーム」という用語は、ユーザに表示される画像に寄与する、たとえば、これを生じさせるように構成される情報を主に含むフレームを指すために使用される。「ビデオフレーム」に関する本明細書の教示の大部分は、「音声フレーム」に適用することもできる。
クライアント2310は典型的にはユーザから入力を受け取るように構成される。これらの入力は、ビデオゲームの状態を変更するか、または他の方法でゲームプレイに影響を及ぼすように構成されるゲームコマンドを含み得る。ゲームコマンドは入力デバイスを使用して受け取ることができ、及び/またはクライアント2310上で実行される計算命令によって自動的に生成され得る。受け取られたゲームコマンドは、クライアント2310からネットワーク2315を介してビデオサーバシステム2320及び/またはゲームサーバ2325に通信される。たとえば、いくつかの実施態様では、ゲームコマンドはビデオサーバシステム2320を介してゲームサーバ2325に通信される。いくつかの実施態様では、ゲームコマンドの別々のコピーがクライアント2310からゲームサーバ2325及びビデオサーバシステム2320に通信される。ゲームコマンドの通信は任意選択で、そのコマンドの識別情報に依存するものである。ゲームコマンドは任意選択で、音声ストリームまたはビデオストリームをクライアント2310Aに提供するために使用されるものとは異なる経路または通信チャネルを経由してクライアント2310Aから通信される。
ゲームサーバ2325は任意選択で、ビデオサーバシステム2320とは異なるエンティティによって運用される。たとえば、ゲームサーバ2325は多人数参加型ゲームの発行元によって運用され得る。この例では、ビデオサーバシステム2320は、任意選択でゲームサーバ2325によりクライアントと見なされ、ゲームサーバ2325の視点からは、従来技術のゲームエンジンを実行する従来技術のクライアントに見えるように任意選択で構成される。ビデオサーバシステム2320とゲームサーバ2325との間の通信は任意選択でネットワーク2315を介して行われる。したがって、ゲームサーバ2325は、ゲーム状態情報を複数のクライアントに送信する従来技術の多人数参加型ゲームサーバとすることができ、複数のクライアントのうちの1つがゲームサーバシステム2320である。ビデオサーバシステム2320は、ゲームサーバ2325の複数のインスタンスと同時に通信するように構成され得る。たとえば、ビデオサーバシステム2320は、複数の異なるビデオゲームを異なるユーザに提供するように構成することができる。これらの異なるビデオゲームのそれぞれは、異なるゲームサーバ2325によってサポートされ、及び/または異なるエンティティによって発行され得る。いくつかの実施態様では、ビデオサーバシステム2320のいくつかの地理的に分散したインスタンスが、ゲームビデオを複数の異なるユーザに提供するように構成される。ビデオサーバシステム2320のこれらのインスタンスのそれぞれは、ゲームサーバ2325の同一のインスタンスと通信し得る。ビデオサーバシステム2320と1つまたは複数のゲームサーバ2325との間の通信は、任意選択で専用の通信チャネルを介して行われる。たとえば、ビデオサーバシステム2320は、これら2つのシステム間の通信専用の広帯域幅チャネルを介してゲームサーバ2325に接続され得る。
ビデオサーバシステム2320は、少なくともビデオソース2330、I/Oデバイス2345、プロセッサ2350、及び非一時的記憶装置2355を備える。ビデオサーバシステム2320は、1つのコンピューティングデバイスを含むか、または複数のコンピューティングデバイス間に分散され得る。これらのコンピューティングデバイスは、任意選択でローカルエリアネットワークなどの通信システムを介して接続される。
ビデオソース2330はビデオストリーム、たとえば、ストリーミングビデオまたは動画を形成する一連のビデオフレームを提供するように構成される。いくつかの実施態様では、ビデオソース2330はビデオゲームエンジン及びレンダリングロジックを含む。ビデオゲームエンジンはプレイヤーからゲームコマンドを受け取り、受け取ったコマンドに基づいてビデオゲームの状態のコピーを維持するように構成される。このゲーム状態は、ゲーム環境内のオブジェクトの位置、ならびに典型的には視点を含む。ゲーム状態はオブジェクトの特性、画像、色及び/またはテクスチャも含み得る。ゲーム状態は典型的にはゲームルール、ならびにゲームコマンド、たとえば、移動、方向転換、攻撃、フォーカス設定、対話、使用、及び/または同様のものに基づいて維持される。ゲームエンジンの一部は任意選択でゲームサーバ2325内に配置される。ゲームサーバ2325は、地理的に分散したクライアントを使用する複数のプレイヤーから受信したゲームコマンドに基づいて、ゲームの状態のコピーを維持し得る。これらの場合、ゲーム状態はゲームサーバ2325によってビデオソース2330に提供され、ゲーム状態のコピーが記憶され、レンダリングが実行される。ゲームサーバ2325は、ネットワーク2315を介してクライアント2310から直接ゲームコマンドを受信し得、及び/またはビデオサーバシステム2320を介してゲームコマンドを受信し得る。
ビデオソース2330は典型的にはレンダリングロジック、たとえば、ハードウェア、ファームウェア、及び/または記憶装置2355などのコンピュータ可読媒体に記憶されたソフトウェアを含む。このレンダリングロジックは、ゲーム状態に基づいてビデオストリームのビデオフレームを生成するように構成される。レンダリングロジックの全部または一部は、任意選択でグラフィック処理ユニット(GPU)内に配置される。レンダリングロジックは典型的には、ゲーム状態及び視点に基づいて、オブジェクト間の3次元空間関係を決定すること、及び/または適切なテクスチャを適用することなどを行うように構成される処理段階を含む。レンダリングロジックは生ビデオを生成し、これは通常はクライアント2310へ通信する前に符号化される。たとえば、生ビデオは、Adobe Flash(登録商標)規格、.wav、H.264、H.263、On2、VP6、VC−1、WMA、Huffyuv、Lagarith、MPG−x.Xvid.FFmpeg、x264、VP6−8、realvideo、mp3などに従って符号化され得る。符号化処理は、任意選択でリモートデバイス上の復号器への配信のためにパッケージ化されたビデオストリームを生成する。ビデオストリームは、フレームサイズ及びフレームレートによって特徴付けられる。典型的なフレームサイズは800×600、1280×720(たとえば720p)、1024×768を含むが、他の任意のフレームサイズが使用され得る。フレームレートは1秒あたりのビデオフレーム数である。ビデオストリームは異なる種類のビデオフレームを含み得る。たとえば、H.264規格は「P」フレーム及び「I」フレームを含む。Iフレームはディスプレイデバイス上の全てのマクロブロック/ピクセルをリフレッシュするための情報を含み、Pフレームはそのサブセットをリフレッシュするための情報を含む。Pフレームは典型的にはIフレームよりもデータサイズが小さい。本明細書で使用する場合、「フレームサイズ」という用語は、フレーム内のピクセル数を指すものとする。「フレームデータサイズ」という用語は、フレームを記憶するのに必要なバイト数を指すために使用される。
代替の実施態様では、ビデオソース2330はカメラなどのビデオ記録デバイスを含む。このカメラは、コンピュータゲームのビデオストリームに含めることができる遅延ビデオまたはライブビデオを生成するために使用され得る。結果的に得られるビデオストリームは、レンダリングされた画像と、スチルカメラまたはビデオカメラを使用して記録された画像との両方を任意選択で含む。ビデオソース2330はまた、ビデオストリームに含められる、以前に記録されたビデオを記憶するよう構成される記憶デバイスを含み得る。ビデオソース2330はまた、人などのオブジェクトの動きまたは位置を検出するように構成される、動きまたは位置検知デバイスと、検出された動き及び/または位置に基づいてゲーム状態を決定するまたはビデオを生成するように構成されるロジックとを含み得る。
ビデオソース2330は、他のビデオ上に配置されるように構成されるオーバーレイを提供するように任意選択で構成される。たとえば、これらのオーバーレイは、コマンドインターフェース、ログイン命令、ゲームプレイヤーへのメッセージ、他のゲームプレイヤーの画像、他のゲームプレイヤーのビデオフィード(たとえば、ウェブカメラビデオ)を含み得る。タッチスクリーンインターフェースまたは視線検出インターフェースを含むクライアント2310Aの実施態様では、オーバーレイは仮想キーボード、ジョイスティック、タッチパッド、及び/または同様のものを含み得る。オーバーレイの一例では、プレイヤーの声が音声ストリーム上にオーバーレイされる。ビデオソース2330は任意選択で1つまたは複数の音声ソースをさらに含む。
ビデオサーバシステム2320が2人以上のプレイヤーからの入力に基づいてゲーム状態を維持するように構成される実施態様では、各プレイヤーは位置及び視野の方向を含む異なる視点を有し得る。ビデオソース2330は、各プレイヤーに各自の視点に基づいて別々のビデオストリームを提供するように任意選択で構成される。さらに、ビデオソース2330は、各クライアント2310に異なるフレームサイズ、フレームデータサイズ、及び/または符号化を提供するように構成され得る。ビデオソース2330は3−Dビデオを提供するように任意選択で構成される。
I/Oデバイス2345は、ビデオサーバシステム2320が、たとえば、ビデオ、コマンド、情報の要求、ゲーム状態、視線情報、デバイスの動き、デバイスの位置、ユーザの動き、クライアント識別情報、プレイヤー識別情報、ゲームコマンド、セキュリティ情報、音声、及び/または同様のものなどの情報を送信及び/または受信するように構成される。I/Oデバイス2345は典型的にはネットワークカードまたはモデムなどの通信ハードウェアを含む。I/Oデバイス2345は、ゲームサーバ2325、ネットワーク2315、及び/またはクライアント2310と通信するように構成される。
プロセッサ2350は、本明細書で論じるビデオサーバシステム2320の様々な構成要素内に含まれるロジック、たとえばソフトウェアを実行するように構成される。たとえば、プロセッサ2350は、ビデオソース2330、ゲームサーバ2325、及び/またはクライアントクオリファイア(Qualifier)2360の機能を実行するようにソフトウェア命令でプログラムされ得る。ビデオサーバシステム2320は、プロセッサ2350の2つ以上のインスタンスを任意選択で含む。プロセッサ2350はまた、ビデオサーバシステム2320によって受信されたコマンドを実行し、または本明細書で論じるゲームシステム2300の様々な要素の動作を調整するようにソフトウェア命令でプログラムされ得る。プロセッサ2350は1つまたは複数のハードウェアデバイスを含み得る。プロセッサ2350は電子プロセッサである。
記憶装置2355は非一時的なアナログ及び/またはデジタル記憶デバイスを含む。たとえば、記憶デバイス2355は、ビデオフレームを記憶するように構成されるアナログ記憶デバイスを含み得る。記憶装置2355はコンピュータ可読デジタル記憶装置、たとえば、ハードドライブ、光学ドライブ、またはソリッドステート記憶装置を含み得る。記憶装置2315は、(たとえば、適切なデータ構造またはファイルシステムによって)ビデオフレーム、人工フレーム、ビデオフレームと人工フレームとの両方を含むビデオストリーム、音声フレーム、音声ストリーム、及び/または同様のものを記憶するように構成される。記憶装置2355は任意選択で複数のデバイス間に分散される。いくつかの実施態様では、記憶装置2355は、本明細書の他の場所で論じているビデオソース2330のソフトウェアコンポーネントを記憶するように構成される。これらのコンポーネントは、必要な場合に供給されるように準備された形式で記憶され得る。
ビデオサーバシステム2320は任意選択でクライアントクオリファイア2360をさらに含む。クライアントクオリファイア2360は、クライアント2310Aまたは2310Bなどのクライアントの能力をリモートで特定するように構成される。これらの能力は、クライアント2310A自体の能力と、クライアント2310A及びビデオサーバシステム2320の間の1つまたは複数の通信チャネルの能力との両方を含むことができる。たとえば、クライアントクオリファイア2360は、ネットワーク2315を介した通信チャネルをテストするように構成され得る。
クライアントクオリファイア2360は、クライアント2310Aの能力を手動または自動で特定(たとえば、発見)することができる。手動の特定は、クライアント2310Aのユーザと通信することと、能力を提供するようにユーザに依頼することとを含む。たとえば、いくつかの実施態様では、クライアントクオリファイア2360は、クライアント2310Aのブラウザ内に画像、テキスト、及び/または同様のものを表示するように構成される。一実施態様では、クライアント2310Aはブラウザを含むHMDである。他の実施態様では、クライアント2310Aは、HMDに表示され得るブラウザを有するゲームコンソールである。表示されたオブジェクトは、ユーザがクライアント2310Aのオペレーティングシステム、プロセッサ、ビデオ復号器の種類、ネットワーク接続の種類、ディスプレイ解像度などの情報を入力することを要求する。ユーザによって入力された情報はクライアントクオリファイア2360に返信される。
自動の特定は、たとえば、クライアント2310A上でエージェントを実行することによって、及び/またはテストビデオをクライアント2310Aに送信することによって行われ得る。エージェントは、ウェブページに埋め込まれた、またはアドオンとしてインストールされたjava(登録商標) scriptなどの計算命令を含み得る。エージェントは任意選択でクライアントクオリファイア2360によって提供される。様々な実施態様では、エージェントは、クライアント2310Aの処理能力、クライアント2310Aの復号及び表示能力、クライアント2310Aとビデオサーバシステム2320との間の通信チャネルの遅延時間の信頼性及び帯域幅、クライアント2310Aのディスプレイの種類、クライアント2310Aに存在するファイアウォール、クライアント2310Aのハードウェア、クライアント2310A上で実行されるソフトウェア、クライアント2310A内のレジストリエントリ、及び/または同様のものを知ることができる。
クライアントクオリファイア2360は、ハードウェア、ファームウェア、及び/またはコンピュータ可読媒体に記憶されたソフトウェアを含む。クライアントクオリファイア2360は任意選択で、ビデオサーバシステム2320の1つまたは複数の他の要素とは別のコンピューティングデバイス上に配置される。たとえば、いくつかの実施態様では、クライアントクオリファイア2360は、クライアント2310とビデオサーバシステム2320の2つ以上のインスタンスとの間の通信チャネルの特性を特定するように構成される。これらの実施態様では、クライアントクオリファイアによって発見された情報を使用して、ビデオサーバシステム2320のどのインスタンスがストリーミングビデオをクライアント2310のうちの1つに配信するのに最も適しているかを決定することができる。
本開示の実施態様は、手持ち式デバイス、マイクロプロセッサシステム、マイクロプロセッサベースのまたはプログラム可能な家電製品、ミニコンピュータ、メインフレームコンピュータなどを含む様々なコンピュータシステム構成を使用して実施され得る。本開示は、有線または無線ネットワークを介してリンクされたリモート処理デバイスによってタスクが実行される分散コンピューティング環境で実施することもできる。
上記の実施態様を念頭に置いて、本開示はコンピュータシステムに記憶されたデータに作用する様々なコンピュータ実施動作を採用できることを理解されたい。これらの動作は、物理量の物理的操作を必要とするものである。本開示の一部を形成する本明細書に記載の動作のいずれもが有用な機械動作である。本開示はまた、これらの動作を実行するためのデバイスまたは装置に関する。装置は要求された目的に合わせて専用に構築することができ、または装置は、コンピュータに記憶されたコンピュータプログラムによって選択的に起動もしくは構成される汎用コンピュータとすることができる。具体的には、様々な汎用機械を、本明細書の教示に従って記述されたコンピュータプログラムと共に使用することができ、または必要な動作を実行するためのより専門化された装置を構築するとより便利であり得る。
本開示は、コンピュータ可読媒体上のコンピュータ可読コードとして具現化することもできる。コンピュータ可読媒体はデータを記憶することが可能な任意のデータ記憶デバイスであり、このデータは後でコンピュータシステムによって読み取ることができる。コンピュータ可読媒体の例には、ハードドライブ、ネットワーク接続記憶装置(NAS)、読み出し専用メモリ、ランダムアクセスメモリ、CD−ROM、CD−R、CD−RW、磁気テープ、及び他の光学及び非光学データ記憶デバイスがある。コンピュータ可読媒体は、コンピュータ可読コードが分散して記憶され実行されるようにネットワーク結合コンピュータシステム上に分散されたコンピュータ可読有形媒体を含むことができる。
方法の動作は特定の順序で説明したが、他のハウスキーピング動作が動作間に実行され得、または動作がわずかに異なる時刻に行われるように調整され得、もしくはオーバーレイ動作の処理が所望の方法で実行される限り、処理に関連する様々な間隔での処理動作の実施を可能にするシステムにおいて分散され得ることを理解されたい。
理解を明確にするために前述の開示をある程度詳細に説明したが、添付の特許請求の範囲内で特定の変更及び修正を実施できることは明らかであろう。したがって、本実施態様は限定的ではなく例示的と見なされるべきであり、本開示は本明細書で与えた詳細に限定されるべきではなく、本開示の範囲及び均等物内で修正され得る。