東海エリアを中心に活躍するVRクリエイター集団のページ

モバイルVRアプリケーションの開発

モバイルVRアプリケーションの開発(現在機械翻訳)

ガイドラインとパフォーマンスガイドへようこそ

モバイルVRデザイン入門

このセクションでは、モバイル開発と言う固有ドメインでのVRアプリケーション開発のためのガイドラインが含まれています。

初期タイトルへのパフォーマンスアドバイス

パフォーマンスに関して保守的になりましょう。2スレッドがVRアプリケーションに割り当てられているにもかかわらず、我々が制御することができない多くの事(割り込み等)がAndroidシステム上で起こります。

いくつかのバックグラウンドタスクでも時折、GPUを使用しています。限度までパフォーマンスを搾り取ろうとすることは、間違いなく意図しないコマ落ちのを招き、エクスペリエンスの低下をもたらします。

あなたは、他のプラットホーム上では数年前には見なかったこれらの高性能制約の下で、高度なグラフィックス効果を使おうとして、比較してはいけません。VRエクスペリエンスの魔法による面白さは、よく設計されたシーンから産まれます。そして、主としてグラフィックスはユーザに対して注意をうながさないようにすべきです。

たとえあなたが60FPSを一貫して保っていても、積極的な(負荷のかかる美麗な)描画はより多くのバッテリーパワーを消費します。これで得られる描画品質の微妙な改善は、一般にバッテリ寿命を20分縮めるほどの価値はありません。

簡単なレンダリングを保ちましょう。全てのメッシュは一度づつ描かれるように単一のパスで、1ビューで描画します(半透明オブジェクトや、レンダーテクスチャを避ける)。パフォーマンスに関係なく、デプスバッファと複数のカメラ層をリセットするような技術はVRにとって良くありません。ジオメトリが正しく動作しない場合 – すべて単一のビュー(FPSの手など)にレンダリングします – それは、VRに知覚の問題が発生します、あなたはデザインを修正する必要があります。

あなたはパフォーマンス上の理由から、ブレンドの多くを扱うことができません。タイトルでナビゲーション機能を制限して、影響が全てのスクリーンを決してカバーしないと保証することができるならば、okです。

アルファテスト/pixel discard transparency を使用しないでください – エイリアシングがひどくなり、パフォーマンスはまだ問題がある可能性があります。アルファからのカバレッジが役に立ち、切り出されたジオメトリの多くを必要としないタイトルを設計することは、より良いです。

ほとんどのVRシーンが16ビットデプスバッファの解像度と2X MSAAで動作するように構築する必要があります。あなたの世界は主に圧縮テクスチャに予め使用している場合は、16と32ビットのカラーバッファの間にはほとんど違いが無いでしょう。

(描画負荷の大きな)”オープンワールド”よりも(オブジェクト数がカリング出来る)ささやかな”シーン”を好みましょう。少なくとも短期的には理論上と実践上の両方から、あなたはそうするすべきです。第一世代のタイトルは技術的に高度なチャレンジをするべきではなく、簡単に達成できる目標を持って取り組むべきです。

最高の見栄えのシーンを作るには、単一テクスチャのモデルを使いましょう。あなたはかなり多くのテクスチャを読み込むことができます – テクスチャ容量は128MBまでは大丈夫です。テクスチャ、または実際には現実の世界からサンプリングされたデータを焼いたグローバルイルミネーションを使用すると、あなたはまだ60 FPSステレオを実行し、合理的にフォトリアルなシーンを作ることができます。低コントラストなステレオ視は目障りにも見えるので、どのように作るかは重要な決定です。

パノラマ写真は、シーンのための優れた効率的な背景になるでしょう。あなたがグローバルイルミネーションについてあまりにえり好みしないのであれば、スワップ·アウト可能にしてしまったほうが、多くの場合良いです。シーン内全てをイメージベースライティングで行うのは、性能上は実用的ではありませんが、おそらく、画面全部を覆わないようなキャラクターだけに使うなら大丈夫です。

フレームレート

非同期タイムワープ(asynchronous TimeWarp)のおかげで、GearVRで見回す限り、レンダリング速度の速い遅いに関わらずjadder-free(なめらかな)な60FPSが体感できます。しかしこれはパフォーマンスについて気にしなくても良い、と言う事は意味しません。しかしAsync-Timewarpの仕組みは通常の使用時に、何らかの原因で処理落ちが発生した時にパフォーマンスを維持するためのマージンを稼ぎ出し、60 fpsを完全に保持していないアプリケーションのためのVRエクスペリエンスを維持するための物です。

もしもアプリケーションが60FPSで動いていなければ、アニメーション中のオブジェクトは飛び飛びに動いてしまいます。そしてGearVRを被ったまま素早く頭を振ると描画が追いつかない真っ暗が端の方に表れてしまいます。こういった時にプレーヤーはスムーズには感じず、ゲームパッドでのコントロールも難しいでしょう。けれどもAsynchronous TimeWarpはGPUパイプラインが(Vsync用に)空いているタイミングでは無くても画面を更新できます。これによって、通常のアプリケーション上のレンダリングよりも60FPSの描画を保ちやすくなっています。

積み重なったビュー(常に視界の片隅にマップがあるとか、UIが張り付く)の構成は60FPSが出ない場合には良くない。なぜなら描画が描き変わらない内に目だけが動いてしまった場合(処理落ちしたら)、GUIパネルやマップやプレーヤーの手など、最前面の絵が目の移動と一緒に動いてしまって違和感を引き起こすためです。(パフォーマンスが出ないなら、HUD的な絵は避ける、と書いてあります)

シーン

シーンごとの描画量の目標を以下に示します:

  • 50Kから100Kの triangles
  • 50Kから100Kの vertices
  • 50から100の draw calls

アプリケーションは、非常に単純なバーテックスシェーダーおよびフラグメントシェーダーを使用して、オーバードロー最小限に抑え、ドローコールの数を減らすことによって、より多くの三角形ポリゴンをレンダリングすることができます。しかし、小さなディテールやシルエットのエッジの多くはMSAAにもかかわらず、目に見えるエイリアシングになることがあります。

(描画品質に関しては)保守的であることが良いです!仮想現実体験の質は、レンダリングされた画像の品質によってだけでは決定されない。低遅延かつ高フレームレートというのは、そうでない場合よりも高品質で完全に没入体験を提供する上で重要なポイントです。

頂点処理は、タイリングアーキテクチャを有するモバイルGPU上で自由ではないので、頂点数に気を配りましょう。シーン内の頂点の数は、三角形の数と同じ位の数であると予想される。典型的なシーンでは、頂点の数は、三角形の倍の数を超えないようにしてください。(他の頂点と接続していない)単一な頂点の数を減らす為には、レンダリングするために必要ではない頂点をメッシュ上から削除しましょう(リトポすると良い)。

テクスチャは、理想的には、改善されたレンダリング性能と容量を1/8に圧縮出来るETC2形式でテクセルあたり4ビットで保存されている
32ビットRGBAテクスチャ上と比べてストレージスペースが大きく削減出来ます。テクスチャは512MBまでのロードは可能ですが、モバイルデバイスに関する利用可能な限られたストレージを考慮する必要がある。限られた移動だけを行うアプリケーションで一意なテクスチャー環境の場合は、テクスチャを128MBまでロードすることは合理的です。

直接テクスチャに鏡面や反射をベイクすることは制限されたモバイル向けアプリケーションに適しています。動的なシェーダベースの法線マップが貼られた上でスペキュラマップを動的に計算する表面のエイリアシングは、多くの場合、VRにとって良くありません。しかし単純な、なめらかな形状ならば、動的な鏡面の恩恵を受けることができます。

動的な影を持つ動的な照明は通常は良いアイデアではありません。これを実装する為の良いとされる技術の多くは、タイリングアーキテクチャと深度バッファ(これはモバイルGPUにとって高負荷)を使用する事になります。シーン内の単一の平行光のシャドウバッファのレンダリングは可能ですが、それよりはライティングとシャドウをベイクしてしまったほうが、通常より良い品質になります。

多くの三角形をレンダリングできるようにするために、可能な限りオーバードローを低減することが重要です。オーバードローが起きるシーンでは、不透明な幾何学的形状が著しくシェーディング操作の数を減らすために前面から背面に描画されることが重要である。単一の視点から表示されるシーンは、静的(static)に前面から背面への三角形ごとにレンダリングを保証するためにソートすることができます(z-sort)。複数のビューポートが存在するシーンは、実行時に動的(dynamic)に前面から背面へのソートされるジオメトリを合理的なサイズのブロックに分割する必要があるかもしれません。

解像度

光学系による歪みによって、画面上のピクセルの知覚サイズは、画面上でも変化します。
便利なことに、視野の中央のピクセル密度は、十分に高いです。しかし2560×1440の解像度をもってしても、ピクセルの見た目の大きさは、典型的な視距離での従来のモニタやモバイルデバイスに比べてまだ大きいです。

現在の画面と光学系を、中央のピクセルは視覚的には約0.06度をカバーするので、6000ピクセルの曲面のバーで覆ってしまえば視点中心で360度をカバーできるでしょう。中心から離れるにつれて、解像度サンプリング間のギャップは、1よりも大きくなってしまうので、エイリアシング回避の為にはミップマップを作成し、使用されるべきです。

一般的な目的のために、この密度でのレンダリングは、90度の視野角を得るには1500×1500解像度のバッファに加え、ミップマップを作成する必要があります。システムは、最大クロック·レートで些細なシーンでこれをすることはほとんど可能ですが、熱の制約がこれを持続不可能にします。

ほとんどのゲームスタイル3D VRコンテンツは、1024×1024の目のバッファ(eye-buffer)をターゲットにする必要があります。この解像度では、ピクセルは中央ではやや引き伸ばされ、唯一かろうじて縁で圧縮されるくらいなので、ミップマップ生成が不要です。あなたがパフォーマンスの余裕がたくさんある場合は、ディスプレイの解像度をより活用するために、このビットの増加を試すことができますが、それは消費電力と性能でコスト高である。

(ゲームスタイルではなくて)専用「ビューア」アプリ(電子書籍リーダー、画像ビューア、リモートモニタ·ビュー、エトセトラ)は、最高品質の描画を追及できます。実際に別々に歪めるの解像度の妥協と二重サンプリングを避けるためにタイムワープを使ったオーバーレイプレーンの使用を検討する必要があります。sRGBのフレームバッファとソーステクスチャを使用すると、最適な解像度に非常に近いサンプリングしたときの高コントラスト領域における「エッジクロール」効果を回避することが重要です。

ハードウェアの詳細(ここから機械翻訳)

AdrenoのSoCは- (512K-1MB)の可変サイズのフレームバッファを複数持っています。

PowerVRまたはMaliベースのGPUとは異なり、Adrenoはバッファに必要なピクセルあたりのバイトに基づいてバイナリサイズを可変に出来ます – 例えば4X MSAAで、32ビットカラー4X MRTで、32ビット深度ターゲットを実行しようと思うと16ビット深度のみのレンダリングに比べて40倍のタイル(framebuffer size)が必要になります。

頂点シェーダは、各頂点ごとに少なくとも二回実行されている。一度目は描画に必要かどうかを決定するパス、二度目はその頂点がカバーする三角形がどこに相当するかを計算する為である。

(binningって、複数ピクセルを一纏めにして1ピクセルを生成すること?)

定期的な頂点シェーダは、頂点位置を計算することに関連するコードのみにストリップダウンされている。いくつかの利点を提供することが独立した属性配列のレンダリング、未使用の属性を持つ頂点キャッシュを汚染しないようにするに。ビニングは、毎三角ベースではないごとの描画コールごとに行われているので、大きな表面を分割する利点はありません。シーンが立体視のために二回レンダリング、およびビニング処理は再びそれを倍増ので、(少なくとも)されているので、頂点処理は、ご想像よりも高価である。

すべてのビンを回避することは、メインメモリから埋め、不要なバッファは、パフォーマンスのために重要で書き込みます。ザ·

すべてのビンを回避することは、メインメモリから埋め、不要なバッファは、パフォーマンスのために重要で書き込みます。VrLibフレームワークは、最適にこれを処理していますが、それを自分で行っている場合、あなたがそれらを使用する前に、カラーバッファを無効にし、目のバッファレンダリングをフラッシュする前に、深度バッファを破棄していることを確認します。無効化が可能な場合は優先されるべきであるので、クリアはまだ、いくつかのパフォーマンスを要した。

そこに持っているのPowerVRチップのような専用の閉塞のハードウェアはありませんが、早期Zの除去は、大きく前面から背面へのオーダーが有益である呼び出しので、描画をソート、実行されます。

テクスチャ圧縮は、大幅なパフォーマンス上の利点を提供しています。ETC2圧縮テクスチャフォーマットを好むが、あなたは本当に滑らかなグラデーションを誇示したい場合は、すべての面に32ビット非圧縮テクスチャを含むシーンをレンダリングするのに十分な性能がまだある

GlGenerateMipmaps()は、高速かつ効率的である。あなたも、動的なテクスチャ用(および静的なテクスチャのためのコースの)ミップマップを構築する必要があります。残念なことに、Android上で、多くの動的な面(ビデオ、カメラ、UIなど)は全くミップレベルを持っていないSurfaceTextures/ samplerExternalOES、としてでてくる。別のテクスチャにコピーし、ミップマップを生成することがあり不便であり、注目すべきオーバーヘッドがかかりますが、それでも検討する価値があり。

sRGBの補正は、テクスチャサンプリングに関する無料ですが、sRGBのフレームバッファに描画するときにいくつかのコストを持っています。あなたは、高コントラストの画像の多くは、正しいガンマはレンダリングにエイリアシングを減らすことができているを持っている場合。もちろん、元のアートワークでシャープなコントラストの遷移を平滑化することもそれを助けることができます。

2X MSAAは、チップ上でフルスピードで実行されますが、それはまだタイルの数を増加させるため、いくつかのパフォーマンスコストがある。
4X MSAAは半分の速度で動作し、シーンは非常に多くを求めないでない限り、一般的には十分な速さではありません。

ユニバーサルメニュー

ユニバーサルメニューは、オクルスホーム、方向を変えるためのショートカット、そのようなパススルーカメラなどの機能を提供しています、サイレントとしないコンフォートモードオプション、などのWi-Fi信号強度及びバッテリレベルなどの様々なシステム状態インジケータと一緒。

モバイルSDKのバージョン0.5.0以降では、ユニバーサルメニューがオクルスホームとホライゾンと一緒にユーザーのデバイスにインストールされているオクルスシステム動作のアプリケーションの一部である。

 

ランタイムスレッド

VRスレッドは、UIスレッドによって生成され、初期化のために、定期的なフレームの更新、およびアイ·バッファを描画するための責任がありますされている。 AppInterface機能のすべては、VRのスレッドで呼び出されている。あなたは、別のスレッドですべてのヘビー級シミュレーションコードを置くべきなので、この1は、基本的には単にコードとシンプルなフレームハウスキーピングを描くん。現在、このスレッドは、より決定論的なスケジューリングを取得するためにリアルタイムSCHED_FIFOモードに設定することができるが、このスレッドで費やされる時間が制限される必要があるかもしれません。

非自明なアプリケーションでは、追加のスレッドを作成する必要があります – エトセトラ、スレッドでアプリのランチャー負荷JPG画像タイル、例えば、音楽プレーヤーアプリはデコードを実行し、スレッドで分析する。可能な限り、他のスレッドに関するのVRスレッドをブロックしない。それは世界のシミュレーション時間ステップが完了していない場合でも、少なくともVRスレッドを持つ新しいヘッドトラッキングを使用してビューを更新することをお勧めします。

非自明なアプリケーションでは、追加のスレッドを作成する必要があります – エトセトラ、スレッドでアプリのランチャー負荷JPG画像タイル、例えば、音楽プレーヤーアプリはデコードを実行し、スレッドで分析する。可能な限り、他のスレッドに関するのVRスレッドをブロックしない。それは世界のシミュレーション時間ステップが完了していない場合でも、少なくともVRスレッドを持つ新しいヘッドトラッキングを使用してビューを更新することをお勧めします。

Javaの(TTJ)スレッドにトークは、そのような音プールをプレイする音や質感に乾杯ダイアログのレンダリングとほぼすぐに返すことが保証されていないJavaの呼び出しを、発行するVRスレッドによって使用されます。

彼らは500 Hzで更新することができるように、センサは、独自のスレッドを持っている。

パワーマネジメント

電力管理は、モバイルVRの開発のために重要な考慮事項である。

あなたが合理的に42.6 GHzのCPUコアと600 MHzのGPUを見つけることを期待することができます – 現世代のモバイルデバイスは、あなたがあなたのポケットに固執することができます何かのために驚くほど強力です。十分に活用、彼らは実際にいくつかのケースではXBOX360やPS3よりも多くのパフォーマンスを提供することができます。

デバイスに関するガバナプロセスは、内部温度センサを監視し、一定レベル以上の温度上昇が誤動作または火傷表面温度を防ぐために、時対応策をとるように試みる。
この是正処置は、クロック·レートを下げることで構成されています。

あなたがリミッターにハード実行した場合、温度は、クロック·レートが低下したとしてもとして登山継続し、CPUクロックは300MHzのまですべての方法をドロップすることがあります。デバイスは、極端な条件の下でパニックすることがあります。VR性能は破滅的に道に沿って低下します。

VRアプリケーションのデフォルトクロックレートは、2つのコアで1.8GHzであり、GPUに関する389 MHzである。あなたは一貫してこれのほとんどを使用する場合は、最終的には最初は何の問題もない場合でも、熱知事に実行されます。典型的な症状は、良いプレーの10分後に貧弱なアプリのパフォーマンスです。あなたが探しlogcat出力をフィルタする場合、「熱」あなたが取られてセンサーの読み取りとアクションのさまざまな通知が表示されます。(logcatの詳細については、Androidのデバッグを参照してください:。Logcatを)

モバイルとPC/コンソール発症との決定的な違いは、最適化は、これまで無駄にしないことである。あなたが時間内にフレームを準備している場合あなたが利用可能な時間または10%の90%を使用した場合、電力の考慮がなければ、それは問題ではありません。モバイルでは、すべての操作は、バッテリーを消耗し、デバイスを加熱する。もちろん、最適化は、何か他のものを犠牲にして努力を伴うが、それはトレードオフに注意することが重要です。

固定クロックレベルAPI

固定クロックAPIは、アプリケーションが固定CPUレベルと固定GPUレベルを設定することができる。

デバイス温度は、CPUとGPUのクロックがレベルパワーセーブに変更されます、その時点で限界に達するまで、現在のデバイスで、CPUとGPUクロック·レートは、完全に、アプリケーションの設定値に固定されている。この変更は、(後述の「3.電源状態通知と軽減戦略」を参照)を検出することができる、といくつかのアプリは、おそらく30 FPSまたはモノスコレンダリングに変更することで、劣化した形で動作し続けることを選択することができる。他のアプリは、プレーを続行できないという警告画面を設置することもできます。

固定CPUレベルと固定クロックレベルAPIによって設定された固定GPUのレベルはありませんMHzの/ GHzのは、そのようにいくつかの努力が将来のデバイスと互換性を持たせるようにすることができる抽象的な数量です。初期のハードウェアについては、レベルは、CPUとGPUは0、1、2、または3であることができる。 0が最も遅いと最も電力効率的である。図3は、最も速く、最も熱いです。典型的には0と3のレベルの差は2倍程度である。

すべてではないクロックの組み合わせは、すべてのデバイスに有効です。例えば、最高GPUのレベルは2つの最高のCPUのレベルで使用するために使用できない場合があります。無効な行列の組み合わせが提供されている場合、システムは要求を認めることはありませんし、クロックの設定は、ダイナミックモードになります。VrLibは断言すると、この場合の警告を発行します。

次の表は、サポートされているサムスンのデバイスのためのクロックの組み合わせを示しています。

GPU 240 300 389 500
CPU レベル 0 1 2 3
884 0
1191 1
1498 2 注意
1728 3 注意

注:デバイスの初期リリースでは、組み合わせの2 CPU / 3 GPU(2,3)および3 CPU / 3 GPU(3,3)許可されています。彼らは過熱に迅速につながる可能性があるようにしかし、我々は、その使用を阻止する。

 

電源管理およびパフォーマンス

これは重要です – 消費電力を修正するSDKには魔法の設定はありません。

どのくらいあなたのゲームが熱限界に実行する前に再生できるようになりますと、あなたのアプリがやっているどのくらいの仕事の関数であり、クロックレートは何ですか。すべての方法がダウンのみの作業と同じ量の電力消費量を25%削減について得クロックレートを変更する。ほとんどの省電力、アプリ内の少ない仕事をしてから来ています。

あなたのアプリが(0,0)の設定で実行することができた場合は、熱の問題を持っていることはありません。これはまだ21GHzの周りでのコアと240 MHzのGPUであるため、そのレベルで高度なアプリケーションを作ることが確かに可能ですが、Unitybasedアプリケーションは、この設定を最適化することが困難な場合があります。

必要なGPU性能を低下させるための効果的なツールがあります – 4X MSAAを使用していない、タイムワープに関する色収差補正を使用し、目のターゲットの解像度を低下させない。16ビットカラーを使用し、深度バッファはまた、いくつかのを助けることができる。それはおそらく2倍MSAA下に行くには良い取引になることはありません – あなたは代わりに目のターゲットの解像度を減らす必要があります。これらはあなたがオーバードロー(特にブレンド粒子)と複雑なシェーダを減らすように、あなたのゲームで行うことができます物事のバランスをとるために必要なすべての品質のトレードオフである。常に確認してテクスチャが圧縮され、ミップマップされていることを確認。

一般的には、CPU負荷がGPUの負荷よりも熱の問題を引き起こすと思われる。必要なCPU性能を低下させることはそれほど簡単である。ユニティアプリは1コアが2 GHzで動作するよりも効率的に機能しない1 GHzで動作する二つのコアいるので、マルチスレッドレンダラーオプションを使用する必要があります。

あなたはあなただけ近接していないことが判明した場合、あなたはタイムワープは、余分なフレームを生成し、2にMinimumVsyncsを設定し、30 FPSであなたのゲームを実行する必要があるかもしれません。いくつかのものは、このような大丈夫うまくいくが、一部のインターフェイススタイルやシーン構造は限界を強調表示します。MinimumVsyncsの設定方法の詳細については、タイムワープテクニカルノートを参照してください。

だから、一般的なアドバイスは、次のとおりです:

おそらく長期間使用されるアプリケーションを作成する場合、ムービープレーヤーのように、非常に低いレベルを選ぶ。理想的には、(0,0)を使用したが、CPUが依然として主にアイドル状態である場合、それはおそらく、(0,2)まで、複数のグラフィックスを使用することが可能である。

クロック·レートが固定で、logcatで報告FPSとGPU回を観察する。それは過小評価であるように報告されたGPU時間は、オンチップ·メモリから戻ってメインメモリへのレンダリングの解決に費やした時間は含まれません。 GPU時間は12ミリ秒かそこらの下に滞在する場合は、おそらくあなたのGPUクロックレベルを減らすことができます。GPU時間は低いが、フレームレートが60 FPSない場合は、CPU制限されている。

常に配布用のアプリケーションの最適化されたバージョンを構築する。デバッグビルドがうまく行っても、それはより多くの電力を消費し、リリースビルドよりも多くのデバイスを加熱します。

それがうまく実行されるまで最適化します。ユニティ統合ガイドでは、モバイルSDKドキュメントで利用可能:アプリケーションのパフォーマンスを向上させる方法の詳細については、「モバイルのベストプラクティス」を参照してください。

電源状態の通知と軽減戦略

モバイルSDK電力レベル状態検出及び処理を提供する。

電力レベル状態は、デバイスが通常のクロック周波数で動作しているかどうかを意味するか、デバイスが熱閾値および熱スロット(パワーセーブモード)以上に上昇した場合に行われている。パワーセーブモードでは、CPUとGPUの周波数はレベルパワーセーブに切り替えられます。レベルはパワーセーブに固定CPU及びGPUのクロック·レベルを設定することと等価である(0,0)。温度が上昇し続けると、クロック周波数は、VRアプリケーションをサポートすることができない最小値に設定される。

私たちは熱スロットリングが行われていることを検出すると、アプリが劣化した方法で動作して継続するか、頭追跡エラーメッセージでオクルスメニューへへすぐに終了するには、いずれかの選択肢を持っています。

通常動作からアプリケーション最初の遷移がモードをパワーセーブ最初のケースでは、次のことが発生します:

  • ユニバーサルメニューは、デバイスが冷却する必要があることを示すdismissible警告メッセージを表示するようにもたらされるだろう。
  • メッセージが却下されると色収差が無効のため、アプリケーションは修正して30Hzののタイムワープモードで再開されます。
  • デバイスのクロック周波数を継続使用後の最小レベルに絞られている場合、非dismissibleエラーメッセージが表示され、ユーザーがデバイスのドッキングを解除する必要があります。

このモードでは、アプリケーションのパフォーマンス要件を低減するために、追加のアプリケーション固有の措置をとることを選択することができる。GetPowerSaveActive():ネイティブアプリケーションでは、パワーセーブモードがアクティブであるかどうかを検出するために、次のAppInterface呼び出しを使用することができます。ユニティでは、次のプラグインの呼び出しを使用することがあります:
OVR_IsPowerSaveActive()。詳細については、ムーンライト/ OVRModeParms.csを参照してください。

通常動作から電力へのアプリケーション移行がモードを保存する第二のケースでは、ユニバーサルメニューは、非dismissibleエラーメッセージを表示するように育てされ、ユーザーは継続するデバイスのドッキングを解除する必要があります。このモードが有効になっても、30Hzのタイムワープに低下したレベルでは良好に動作しない可能性があるアプリケーションを対象としています。

あなたはモード戦略パワーセーブを有効または無効にするには、次の呼び出しを使用することがあります:

ネイティブの場合は、すぐに頭追跡エラーメッセージを表示するモードの処理、または虚偽のパワーセーブのためにtrueにConfigureVrModeでmodeParms.AllowPowerSave()を設定する。

Unityのため、あなたは可能にしてもよいかOVR_VrModeParms_SetAllowPowerSaveを経由してモードハンドリングパワーセーブを無効にする()。詳細については、ムーンライト/ OVRModeParms.csを参照してください。

フロントバッファレンダリング

Androidの標準のOpenGL ESの実装トリプルバッファウインドウ表面。

トリプルバッファリングは、ほとんどのアプリケーションに議論の余地がトレードオフです増加滑らかさ、のための待ち時間が大きくなりますが、VRのために明らかに悪いです。重く決してGPUをロードしないとAndroidアプリケーションは、()の画素が、画面に変化開始時間に呼び出された同期は、時間eglSwapBuffersからの待ち時間の50ミリ秒を持っていることが強制的にでも、60 fpsで実行されている。

Androidは、おそらく厳密にダブルバッファモード、そしておそらくスワップ-涙オプションを提供する必要がありますが、それを使用すると、システムにバッファを提示した場合、それはしないだろう良いチャンスはあなたがすぐにそれを望むものがあることが悲しい真実である。あなたはそれが画面に走査されている間にレンダリングすることができ、単一のバッファ – 最良の場合は、すべてのバッファのない鎖を有していないことです。引き裂き線を避けるために、それは、現在スキャンアウトされていないウィンドウの領域に描画するアプリケーション次第である。

デバイスがヘッドセットである場合、モバイルディスプレイは、内部右側にホームボタンが下にあるときに上から下に縦長モードでスキャン、または残っている。VrLibは、表示VSYNCでタイムスタンプイベントを受信し、ビデオラスタは、与えられた時点でのスキャンがどこにあるかを決定するためにそれらを使用しています。現在のコードでは、右目が左目をワープするために表示されているまで、待機し、左目が右目をワープするために表示されているまで待機。最初のピクセルが画面に変更される前にこれが唯一の8ミリ秒のレイテンシを提供します。これは、画面のスキャン半分を表示するには、8ミリ秒かかるため、レイテンシはそれぞれの目渡ってその分異なります。

タイムワープ

タイムワープは、仮想現実ヘッドセットで使用されるレンズの光学収差を補正する。

仮想現実体験における存在の真の意味を作成するために、いわゆる「タイムワープ」を使用することができる。また著しくmotionto光子の遅延を減少させるために、最新の頭部追跡情報に基づいて立体画像を変換する。立体アイビューは、テクスチャにレンダリングされます。これらのテクスチャは、ヘッドセットで、広角レンズに起因する歪みを補正するためにディスプレイ上にワープされる。

動きの光子の遅延を減少させるために、更新された方向情報は、単にタイムワープを描画する前に、ヘッドセットのために取得され、変換行列は、彼らが、彼らがあるべき場所にレンダリングされた時点であったところから眼球テクスチャワープその算出され一度彼らが表示されます。多くの人々はこれについて最初の聴聞会に関する懐疑的であるが、態度の変化を、反りの画素がほぼ正確に正しいです。鋭い回転が縁でいくつかのピクセルの黒を残しますが、これは最小限に邪魔であることが判明した。

タイムワープは、それを行うことで、より遠く一歩を踏み出している「補間されたタイムワープ。」ビデオは約120本の走査線ミリ秒の速度で走査されるので、遠い右に走査線が左にラインより大きい待ち時間を有する。低迷LCDでは、これは本当に重要ではありませんが、さわやかなスイッチングOLEDに関するそれはそれはあなたがすぐに電源を入れたときに世界が微妙に伸びやせん断さのように感じさせる。これは、各眼、<8ミリ秒の予測の開始時に頭部の姿勢、及びそれぞれの目の終わり、<16ミリ秒を予測して補正される。これらの予測は、タイムワープ変換を計算するために使用され、反りが描かれ、各走査線のためにこれらの2つの値の間で補間される。

タイムワープは、目のテクスチャをサンプリングするためにワープされたテクスチャ座標を計算するフラグメントプログラムをフルスクリーンクワッドをレンダリングして、GPU上で実施することができる。しかし、パフォーマンスを向上させるためにタイムワープは、テクスチャ座標が設定が目のテクスチャをサンプリングしている画面全体にわたる三角形の均一テッセレーショングリッドをレンダリングします。ワープテクスチャ三角形のグリッドをレンダリングする基本的座標をタイムワープの区分線形近似になる。

タイムワープは、立体レンダリングを非同期に実行した場合、タイムワープはまた、知覚フレームレートを増加させ、一貫性のないフレームレートを平滑化するために使用することができる。デフォルトでは、タイムワープは、現在、ネイティブとユニティアプリケーションの両方のために非同期で実行されます。

タイムワープ最小Vsyncs

タイムワープMinimumVsyncsパラメータのデフォルト値は60 FPSターゲットの1である。2に設定するとWarpSwapはせいぜい30 FPSへのアプリケーションのフレームレートを保持するようになります。非同期タイムワープスレッドは60 fpsで追跡し、更新さ頭で新しいフレームをレンダリングしていきますが、アプリケーションは唯一の毎秒アイ·バッファの30の新しいステレオペアを生成する機会があります。あなたは、実験目的のために、より高い値を設定することができますが、ヒッピングアプリの唯一のまともな値は、1と2である。

あなたは、1〜4 MinimumVsyncsからサイクルにVrScene.apkで右トリガープラスDPAD右を押して、ネイティブアプリでは、これらの値を試すことができます。ユニティのアプリの場合は、ユニティ30HzのタイムワープSDK例を参照してください。

あなたはこれを明示的に設定することを検討可能性が2例があります:

アプリケーションが60 FPSにほとんどの時間を保持できない場合は、30 fpsですべての時間をクランプではなく、ユーザのために予測できないアプリの滑らかさや動作の変更を持っている方が良いかもしれません。ほとんどの場合、私たちは60 FPSを保持するための経験を簡素化することは正しい決断であると信じていますが、例外があるかもしれません。

30アプリケーションFPSでレンダリングすると、かなりの量の電力を節約し、デバイス上の熱負荷を軽減します。一部のアプリケーションでは、60 FPSをヒットすることはできますが、壊滅的なパフォーマンスに影響を持つことができ、すぐに熱の問題に遭遇する可能性 – あなたが時間の長時間再生できるようにしたい場合は、それが30 FPSをターゲットにする必要があるかもしれない。サーマルスロットル軽減戦略に関する詳細情報については、電源管理を参照してください。

60 fpsでレンダリングしない場合の結果

これらはあなたが明示的MinimumVsyncsを設定しているか、あなたのアプリはちょうどそれだけでそれは遅い起こっているかどうかを適用する。

視点が遠くすべてのジオメトリの場合、何がアニメーション化されず、ヘッドの回転速度が低い場合、視覚的な違いは存在しない。これらの条件のいずれかが存在しない場合には、バランスを取るために多かれ少なかれアーティファクトが存在する。

ヘッド回転速度が高い場合、画面の端に黒い目に見え用バッファが送信されてからの期間に応じて可変量だけ引き込まれる。これはまだ60 FPSで起こるが、合計時間が小さく、フレームからフレームへの一定であるので、それは気づくことはほとんど不可能である。低いフレームレートでは、あなたはそれが画面の端にスナップ見ることができます。

これには二つの緩和策があります:

その代わりにフレームは、ヘッドトラッキングモデルが照会さポイントとして表示されて起動するアイ·バッファが上に表示されますことを、すべてのフレームの中間点にある時間を使います時のどちらか”今”を使用して、または時間の。これはかなり一方積み上げなく、画面の両側に「レンダリングされていない領域を「配布する。

目のバッファに使用視野を大きくすると、それをより引き出すエッジオフより多くのクッションを与え、それに結合された。眼バッファの解像度を上げていない場合は、フレームレートが60未満である場合、ネイティブアプリケーションのために、我々は現在、これは効果的に画面中央の解像度を低下させる、FOVが10度を追加する。そこにヘッド回転速度に基づいて動的にFOVをスケーリングの値であるかもしれないが、あなたはまだ縁で初期のポップを見ること、およびFOVを変更すると、連続してより多くの目に見えるエッジアーティファクトとき主に安定した結果。

タイムワープは、現在位置の変化、唯一の態度を補償する試みません。私たちは、モバイルで実際の位置追跡を持っていない、まだ、私たちは頭/首の回転に基づいていくつかの眼球運動を提供したモデル、およびユーザが明示的にナビゲート目元を移動できるようにゲームを使用していますか。30目FPSで、タイムワープが態度に、各フレームの更新をスムーズになりますので、これらの値は、目の更新の間に全く変化しませんが、動きが唯一の他のすべてのフレームを変更します。

直進予想されるよりもむしろ良い作品によって本当に近く何もウォーキングが、壁の隣にsidesteppingすることは、かなり明白になります。オブジェクトに非常に近い効果を可視にしたときだけでも、あなたの頭を移動する。

このための魔法の解決策はありません。私たちは、タイムワープがデプスバッファ知らさ再投影を行う持っている携帯電話のパフォーマンスに余裕を持っていない、とそうすることはどのような場合に新たな視覚的アーチファクトを作成します。我々は、単一の深さと、シーン全体を扱い、その採用するが、それは現在スケジュールされていないでも動作するかもしれ単純化されたアプローチがあります。

それは言っても安全であること、アプリケーションがほぼそれが30 FPSの候補ではないことを、FPSの武器のように、ビューにこだわった重要なグラフィカルな要素を持っている場合。

ジョイパッドを使用して視点を回すと、あなたがVRでできる最も吐き気を催すものの間ですが、いくつかのゲームはまだそれを必要とする。アプリによって完全に処理すると、これは、位置変化ようなもの巻き取るので、彼らはジョイパッドを使用する際に、低フレームレートのアプリはユーザの頭部が動いていた、滑らかな「回転」が、分厚い回転を持っているでしょう。これに対処するために、タイムワープは、ジョイパッドヨーがスムーズにすべてのレンダリングされたフレームに関する推定することができるようにすることができ、「ExternalVelocity「マトリックスパラメータがあります。我々はまだこのためのユニティ·インターフェースを持っていません。

インワールドアニメーションは低いフレームレートで著しくchunkierのになりますが、その場で非常に気が散るという羽目になるません。彼らは、彼らが移動すると、あなたの頭にあなたがそれらを追跡する際に、前後に吃音ているように見えるので、軌道上のオブジェクトは、より問題である。

多くのアプリのために、平面視レンダリングはまだ30 FPSのレンダリングよりも良い経験になることがあります。節約は大きくないが、それは、多くの変数のない明確なトレードオフです。

あなたは60 FPSを下回る場合は、ユニティアプリは待ち時間のフレームが追加され、マルチスレッドレンダラー、なしの方が良いかもしれません。GPUパイプラインとマルチスレッドレンダラで30 FPSは、待ち時間の多くをすることになっており、タイムワープは態度のためにそれをすべて削除しますが、位置が頭部モデルを含め変更し、非常に遅れて感じることができる。

これは、すべての最前線であり、この指針の一部は投機的であることに注意してください。

タイムワープ色収差補正

タイムワープは、色収差補正を可能にするためのオプションがあります。

1920×1080副腎330がフルスピードで動作では、これはVSYNCあたり3.1ミリ秒に2.0ミリからタイムワープの実行時間が増加するので、それがデフォルトの動作ではないことを十分に大きなパフォーマンスコストですが、必要に応じて、アプリケーションは、それを有効にすることができます。

タイムワープデバッググラフ

タイムワープの詳細については、デバッググラフから得ることができる。

ネイティブアプリケーションでは、デバッググラフは右の肩+ DPADアップをオンにすることができます。凍結されたオフ/ランニング/間のこの意志サイクル。ユニティでは、プラグインのコールOVR_SetDebugMode(1、1)のデバッググラフを向けるだろう、とOVR_SetDebugModeは(0、1)それをオフにします。

グラフの各ラインは、画面上で片目を表します。緑色の線は目が、それが描かれた前回に比べて新しいフレームソースを有することを意味する。赤い線は、それが前のフレーム、現在の位置にワープ時間と同じテクスチャを使用していることを意味します。着実60 FPSのレンダリングアプリケーションは、すべての緑の線を持つことになります。赤と緑の線の均一な分布は、アプリケーションが、一般的に遅いことを意味します。レッドスパイクは、ガベージコレクションのような間欠動作が問題を引き起こしている可能性を意味します。背の高い赤線のペアは、フレーム全体がスキップされたことを意味します。 OSやグラフィックスドライバは、いくつかの予想外の競合を持っていない限り、これは起こるべきではありません。残念ながら、これはまだ時々起こるのでしょう。

水平な白い線は、前眼がスキャンアウトされる時間の約8ミリ秒を表し、赤または緑の線は、レンダリングが完了するまでタイムワープ動作の開始を表す。ラインは白線の内側に完全にある場合は、ターゲット·メモリがビデオにスキャンアウトされる前に描画が完了し、すべてのものが良いです。ラインは白線上に延びている場合、簡単に涙が画面上に表示されることがあります。

画面上で。

完璧な世界では、すべての行が短いと、グラフの一番下になります。ラインがウェル底の上に起動した場合はそれになりたいと思った時に、タイムワープはスケジュールされませんでした。ラインが異常に長い場合は、GPUは、コンテキストは、優先度の高いタイムワープコマンドに切り替えができるポイントに到達するために長い時間がかかったことを意味する。CPU負荷およびGPUパイプライン気泡が最大コンテキストスイッチ待ち時間に対してバランスされなければならない。

副腎は、タイリングアーキテクチャを使用し、タスクごとに非常に多くのタイリングビンを切り替えることができます。タイムワープは、高性能タスクとして実行されたが完了していることがタイルビンの最後のバッチのために待たなければならないれる。フォアグラウンドアプリケーションは、個々のタイルのビンは、非常に高価なものにレンダリングを行っている場合は、ここで問題を引き起こす可能性がある。最良の結果を得るには、高価なフラグメントプログラムを使用して高度にモザイク状のジオメトリで画面の一部をカバーすることは避けてください。

ユーザーインターフェイスのガイドライン

仮想現実でのグラフィカルユーザインタフェース(GUI)は、この文書のガイドラインに従うことによって軽減することができますユニークな課題を提示する。これは完全なリストではありませんが、バーチャルリアリティのGUI(VRGUIs)のFIRSTTIME実装者のためにいくつかのガイダンスや洞察力を提供しています。

文字:立体視で!

任意の単一の単語は、開発者が理解するのに役立つとVRGUIsの課題に対処することができれば、それは「立体的」である。それぞれの目のための1 – VRでは、すべてのものは、ビューの二点からレンダリングされなければならない。設計とVRGUIsを実装する場合は、この事実を頻繁に検討、彼らが実装する際に遭遇する前に光に問題をもたらすことができます。またVRGUIsに作用する基本的な制約を理解するのを助けることができる。特にゲーム – たとえば、立体的なレンダリングは、基本的には不可能正投影ヘッドアップディスプレイ(HUD)、3Dアプリケーションのための最も一般的なGUIの実装の1つを実装することができます。

インフィニティ問題

それ自体はどちらも正射影ものHUDは完全にVRで除外されているが、全体のHUDは、各鳥瞰図で同じ正投影を介して提示されている彼らの標準的な実装では、一般的である。

このように、HUDを投影すると、HUDを表示するときに無限に集中するユーザーが必要です。これは効果的にユーザの脳に関する限りとして、レンダリングされ、他のすべての背後にHUDを配置します。これは彼らの前に見えるの残りにもかかわらず、さらに離れて他のすべてのオブジェクトよりも長くHUDを知覚視覚系を、混乱させることができます。これは一般的に不快感を引き起こし、目の疲れに寄与し得る。

まれに、知覚の参照フレームの間に極端な乖離は、間質四次元立方体がhyperspatialウロボロスと呼ばれるに時空が折り畳まれている空間的·時間的な異常を引き起こす可能性 – これは時空自体のファブリックを脅かすことがあります。

ちょうど最後の部分について冗談。とにかく、正投影はその後視聴者から合理的な距離で、ワールド空間でレンダリングされ、表示され、個々の表面上で使用する必要があります。理想的な距離が変化するが、通常1〜3メートルの間である。この方法を用いて、通常の2次元GUIは、レンダリングされた世界に入れて、ユーザの視線方向は、GUIとの対話のためのポインティングデバイスとして使用することができる。

一般に、アプリケーションは、正射ながらVRモードで画面に直接何かを投影するという考えをドロップすべきである。それは常に、これは課題の独自のセットを提供しますが、その後ワールド空間に配置され、表面に投影した方が良いでしょう。

深度の深さ

ワールド空間でVRGUIを配置すると、奥行き閉塞の問題を提起する。多くの3Dアプリケーションでは、常にそれがと一致する、または別のレンダリングされた面によって閉塞されずにGUIを配置するユーザーのビューの前に十分なスペースがあることを保証するために、不可能でさえ、困難である。例えば、ユーザは、ゲームプレイ中にメニューを切り替えた場合、メニューは、ユーザーが直面している壁の背後に表示されている場合、それは問題がある。これは、デプステストなしでレンダリングしても問題が解決しなければならないことに思えるかもしれないが、それは立体的な分離がメニューがさらに離れて壁を超えて、ユーザーに示唆する無限大の問題と同様の問題を作成し、まだメニューはの上に描画します壁。

これにいくつかの実用的な解決策があります。

  • 一度深パスと2パスでVRGUI面をレンダリングして、一度の深さのVRGUIより視点に近い任意の表面とのブレンドスティプルまたは失敗するパスとの特別なシェーダを使用して、失敗する。
  • プロジェクトVRGUIは理想的な距離よりも近いジオメトリ上に表面。ジオメトリが表示VRGUIは、ユーザーの外になるように近づけることができる場合、これはすべての問題を解決しないかもしれないが、VRGUIsは世界への光の物理的な投影である前提としているすべてのゲームによくフィットしながら、それは彼らにバックアップする機会を与えることスペース。
  • VRGUIインターフェイスがアップするときに、別のシーンにユーザーを移動します。これは、インターフェイスがフェード黒を世界にフェージングのような単純なものかもしれません。
  • 、すなわち、立体的に世界をレンダリング停止同じビュー変換との両方の目のビューをレンダリング、VRGUIが表示されている間、その後立体的になく、デプステストせずにGUIを描画。これは世界がその背後にある2次元投影として表示されている間VRGUI面が深さを持ってできるようになります。
  • 実際のインワールドオブジェクトとしてVRGUIsを扱います。ファンタジーゲームでは、文字は、GUIが投影される際に本や巻物を、持ち出すことがあります。現代の設定では、これはキャラクターの手で開催されたスマートフォンかもしれません。おそらくデスクトップコンピュータ – – 他の例では、文字は、世界の特定の場所に移動する必要がある場合がありインターフェースと対話する。これら全ての場合において、アプリケーションはそのような終了し、常に、システムランチャに戻す機能として、基本的な機能をサポートする必要がある。

VRGUI表面のため十分なスペースが、存在しない場合には、一般的にすべてのVRGUIとの対話を拒否することが現実的とレンダリングではないあなたが世界観をレンダリングするとき、メニューのいずれかのタイプ(偶数設定メニュー)を表示する必要があることはありませんアプリケーションを持っていない限り。

バーチャルリアリティを見つめる

そこVRGUIと相互作用する複数の方法があるが、視線追跡が最も直感的であってもよい。ユーザの視線の方向は、マウスやタッチデバイスのタッチであるかのようにVRGUI内の項目を選択するために使用することができる。タッチデバイスとは異なり、ポインタが最初の「ダウン」イベントを開始せずにインタフェースを中心に移動させることができ、ため、マウスが少し良いアナロジーである。

VRの多くの事のように、カーソルを配置する視線の使用が考慮すべきいくつかの新しいプロパティがあります。項目を選択する視線方向を使用するときに、最初に、その視線がアイテムを選択するように指示されなければならない場所を示す凝視カーソルを有することが重要である。カーソルは、他のすべてのVRの表面のように、立体的にレンダリングされるべき。これは、ユーザーにカーソルがワールド空間のどこの固体指標を与える。テストでは、カーソルまたは十字線なし注視選択の実装は使用することがより困難であると報告され、より少ない、接地されています

視線方向は、カーソルを移動するため、カーソルが別の項目を選択するインタフェースに対して移動しなければならないので、第二に、そして、それはビュー内で常にインターフェイスを視聴者に提示することはできません。ある意味で、これは、ユーザーが常に離れて画面から自分の頭を回すことができるので、どちら従来の2DのGUIでは不可能ですが、違いがあります。彼らは見ているだけされない場合があり – 通常の2D GUIにより、ユーザは必ずしもそれを提示されているデバイスを見ていないときのインターフェースと対話することができるように期待していませんが、VR内のユーザーは、常にデバイスを見ているVRGUIで。これは、ユーザーインターフェイスを「失う」と、まだ利用可能で、ユーザーが期待するように、彼らは、メニューが表示されていないため、アプリケーションは、(入力を処理しない場合にはさらに混乱をもたらすことができるそれらの入力を消費実現しなかっできるようにすることができます彼らの現在のビュー)。

この問題を扱うには、いくつかの方法があります。

  • それは、ユーザーの視点から見ると、いくつかの視野の外になった場合は、インターフェイスを閉じます。インタフェースはゲームプレイを一時停止した場合、インターフェイスが閉じたときにゲームプレイだけで再開するので、これは、ゲームのための問題となる可能性がある
  • ユーザーはインターフェイスコントロールの内側に凝視カーソルを維持するか、それはまだユーザーに表示される場所画面の端にそれを維持いずれか、ターンとして自動的にビューとのインタフェースをドラッグします。
  • メニューモードであることをユーザーに示し、その後このアイコンが常に視野に追跡することができ、画面の周辺部にどこかにアイコンを置きます。

凝視カーソルを使用に伴う別の頻繁に予期しない問題は、デフォルトのアクションを処理する方法である。現代の2DのGUIで、ボタンまたはオプションは、多くの場合、GUIのダイアログが表示されたときにデフォルトで選択されて – おそらく、[OK]ボタンをユーザーが通常現在の設定を変更せずに進むことが予想されるダイアログで、またはそのダイアログ警告上のボタンをキャンセル破壊的な行動が取られようとしている。しかし、VRGUIsで、デフォルトのアクションは、それが表示されたときに凝視カーソルがインターフェイスで指している場所によって決定されます。ダイアログが凝視カーソルの下に、[OK]をクリックしてポップアップ表示される場合、[OK]のみVRGUIでデフォルトすることができます。アプリケーションは、(例えば、現在のピッチを無視して、水平面上に置くように)直接的に観察者の正面にVRGUIを置く以外はない場合、それは存在しない限り、デフォルトボタンの概念を持つことは実用的ではないそのようなVRGUIと対話するために使用することができるキーボードなどの入力の追加のフォーム。

PAGETOP
Copyright © 近未来ラボ All Rights Reserved.
Powered by WordPress & BizVektor Theme by Vektor,Inc. technology.