This document is unofficially translated by users. Please refer to the original document here: http://developer.oculusvr.com/best-practices
Copyright © 2014 Oculus VR, Inc. All Rights Reserved.
-----------------
ポジション・トラッキング
-
レンダリングされたイメージはユーザの物理的な動作に直接対応させる必要があります。つまりバーチャルカメラの移動を補正してはいけません。頭部モデル全体に対して１つのグローバルなスケールで十分です（例．フィートからメートルへ変換、またはプレイヤーを拡大または縮小）が、瞳孔間距離（IPD）と独立して頭部の動作をスケールしてはいけません。
-
ポジション・トラッキングにより、ユーザは予想していなかった新たな視点を使用するようになります。オブジェクトの下や、突起物の上、壁の角から覗きこんだり、など出来ます。カリングやバックフェースレンダリングなど、対処方法を検討しておいて下さい。
-
一定の状況下でユーザはポジション・トラッキングを使用してバーチャル環境をクリッピングできるかもしれません（例．頭が壁やオブジェクトの中を突き抜ける）。私たちの経験から、ユーザはこういう状況があることを理解すると、ゲームデザイン上で何か有益なことがないかぎり自然に避ける傾向があります。そうとはいえ、開発者はカメラが物体の中をクリッピングする状況にどう対処するか計画すべきです。ひとつのアプローチは、ユーザにメッセージ表示をしてトラッキングできる領域から出たことを通知します（実際にはカメラで表示できる範囲にあるとしても）。
-
ユーザがカメラのトラッキング範囲の境界に近づくときに警告表示をします（到達する大分前にあらかじめ行う）。またトラッキング不能になることを避けるためにどうすべきかをユーザにフィードバックします。
-
ユーザがカメラのトラッキング範囲を出た場合にOculus Riftの画面でバーチャルな環境を表示しつづけることは推奨しません。トラッキング不能になる前に黒い画面へとフェードしたり画像を減衰（例えば明るさやコントラストを落としたり）させた方が遥かに快適です。ユーザに何が起きたかを伝えて、どのように直すことが出来るかの情報提供を行うようにして下さい。
-
ポジション・トラッキングを補正して増加させたり無効かすることは不快な体験につながります。出来るかぎりそのようなことは避けるとともに、画面を暗くするかせめてポジション・トラッキング不能の場合もSDKによりヘッドトラッキングで向きを維持してください。
レンダリングされたイメージはユーザの物理的な動作に直接対応させる必要があります。つまりバーチャルカメラの移動を補正してはいけません。頭部モデル全体に対して１つのグローバルなスケールで十分です（例．フィートからメートルへ変換、またはプレイヤーを拡大または縮小）が、瞳孔間距離（IPD）と独立して頭部の動作をスケールしてはいけません。
ポジション・トラッキングにより、ユーザは予想していなかった新たな視点を使用するようになります。オブジェクトの下や、突起物の上、壁の角から覗きこんだり、など出来ます。カリングやバックフェースレンダリングなど、対処方法を検討しておいて下さい。
一定の状況下でユーザはポジション・トラッキングを使用してバーチャル環境をクリッピングできるかもしれません（例．頭が壁やオブジェクトの中を突き抜ける）。私たちの経験から、ユーザはこういう状況があることを理解すると、ゲームデザイン上で何か有益なことがないかぎり自然に避ける傾向があります。そうとはいえ、開発者はカメラが物体の中をクリッピングする状況にどう対処するか計画すべきです。ひとつのアプローチは、ユーザにメッセージ表示をしてトラッキングできる領域から出たことを通知します（実際にはカメラで表示できる範囲にあるとしても）。
ユーザがカメラのトラッキング範囲の境界に近づくときに警告表示をします（到達する大分前にあらかじめ行う）。またトラッキング不能になることを避けるためにどうすべきかをユーザにフィードバックします。
ユーザがカメラのトラッキング範囲を出た場合にOculus Riftの画面でバーチャルな環境を表示しつづけることは推奨しません。トラッキング不能になる前に黒い画面へとフェードしたり画像を減衰（例えば明るさやコントラストを落としたり）させた方が遥かに快適です。ユーザに何が起きたかを伝えて、どのように直すことが出来るかの情報提供を行うようにして下さい。
ポジション・トラッキングを補正して増加させたり無効かすることは不快な体験につながります。出来るかぎりそのようなことは避けるとともに、画面を暗くするかせめてポジション・トラッキング不能の場合もSDKによりヘッドトラッキングで向きを維持してください。
付録 F - トラッキング
-
Oculus Riftのセンサーによりヨー、ピッチ、ロール情報が収集されます。
-
DK2 では6次元（D.O.F.）のポジション・トラッキングを実現
-
ユーザが初期ポジションをガイダンスを提供して自ら快適な開始位置を選択出来る
-
ポジション・トラッキングを無効かまたは修正しないで下さい。ユーザが現実世界で動作している時など特に注意が必要です。
-
ユーザがトラッキング範囲から出るときは警告を行い、トラッキング不能となる前に黒い画面を表示するなどして下さい。
-
ユーザはポジション・トラッキングにより事実上どこにでもバーチャルカメラを配置できます。ゲームのチートが見えてしまったり環境の中をクリッピングされないように気をつけて下さい。
-
ポジション・トラッキングが利用可能でない状況では、常にSDKにある頭部モデルに関するコードを実装して下さい。
-
エンジンのパイプライン全体を最適化してタイムラグや遅延を最小化して下さい。
-
レイテンシをさらに減らすにはOculus VRのプレディクティブ・トラッキングのコード（SDKにて利用可能）を実装して下さい。
-
レイテンシを避けることが完全に難しい状況では、せめて継続的にラグが発生しないようにして下さい。
Oculus Riftのセンサーによりヨー、ピッチ、ロール情報が収集されます。
- DK2 では6次元（D.O.F.）のポジション・トラッキングを実現
- ユーザが初期ポジションをガイダンスを提供して自ら快適な開始位置を選択出来る
- ポジション・トラッキングを無効かまたは修正しないで下さい。ユーザが現実世界で動作している時など特に注意が必要です。
- ユーザがトラッキング範囲から出るときは警告を行い、トラッキング不能となる前に黒い画面を表示するなどして下さい。
- ユーザはポジション・トラッキングにより事実上どこにでもバーチャルカメラを配置できます。ゲームのチートが見えてしまったり環境の中をクリッピングされないように気をつけて下さい。
ポジション・トラッキングが利用可能でない状況では、常にSDKにある頭部モデルに関するコードを実装して下さい。
エンジンのパイプライン全体を最適化してタイムラグや遅延を最小化して下さい。
レイテンシをさらに減らすにはOculus VRのプレディクティブ・トラッキングのコード（SDKにて利用可能）を実装して下さい。
レイテンシを避けることが完全に難しい状況では、せめて継続的にラグが発生しないようにして下さい。
方向トラッキング
Oculus Riftのヘッドセットはジャイロスコープ、加速度計、磁力計が含まれています。これらのセンサーから得られた情報をセンサー統合と呼ばれるプロセスを通して現実世界におけるユーザの頭部の向きを判定してユーザの視界をリアルタイムで同期します。これらのセンサーによりヨー、ピッチ、ロール動作を正確にトラッキングするデータが提供されるのです。
私たちはユーザの頭部と首のシンプルなモデルによりセンサー情報からの頭部の動作をカメラの動作への変換をシンプルにモデル化しました。以下、これを「頭部モデル」として言及しますが、首の位置（喉ぼとけのあたり）を軸にした3方向への動作を反映します。頭部の回転は目の位置を変化させて、動作による視差が発生することでデプス認識および快適さを生み出す重要なカギとなります。
ポジション・トラッキング
DK2によりOculus Riftによる6次元（D.O.F.）のポジショントラッキングが導入されています。DK2の赤外線を透過させる外装ケースの内部にはミクロな赤外線LEDが多数配置されていて、実空間における位置トラッキングを赤外線カメラによりトラッキングされます。ポジション・トラッキングはカメラのトラッキング範囲にあるかぎり、常にユーザの動作と1:1で対応すべきです。これらポジション・トラッキングの入力値をプレイヤーの動作に合わせて加工することは不快な体験につながります。SDKはいくつかの点やベクトルの組み合わせの情報にもとづいてユーザの頭部の空間における位置を返します。モデルは原点となる地点を中心にして定義されています。この原点の位置はおおよそユーザがカメラの前で快適な姿勢で座っているときの頭および首のピボット地点に配置されます。
開発する際は、ユーザが座っている位置やOculus Riftのセットアップ方法にもとづいて頭部モデルの原点の位置をリセットできる機能を提供すべきです。ユーザはゲームプレイの位置を変えたり移動することがあるので、いつでも原点の位置をリセットできるようにすべきです。しかし、この際にユーザが自分自身で、トラッキング範囲を出ることなくカメラの前の最適な位置をみつけるためのガイダンスを何らかの手段で提供すべきです。そうしないかぎり、ユーザはカメラのトラッキング範囲の境界に原点を気付かずにセットしてしまい、移動した瞬間にポジション・トラッキング不能となるかもしれません。実現のためにはゲームプレイとは別にカリブレーションのツールを提供するなどの方法が考えられます。
頭部モデルは主に3つのベクトルから構成されます。一つのベクトルはユーザの首の位置にマッピングされて、ポジション・トラッキング空間の原点を始点として、おおよそユーザの鼻筋の位置が終点となっています。二つのベクトルは目の中心を原点として、片方は右目、片方は左目を終点としています。ポジション・データに関して、より詳細なドキュメントはSDKの中で確認できます。
ポジション・トラッキングによって、より快適で没入感のあるゲームプレイの要素が実現されます。プレイヤーは体の位置をわずかに変えて、コクピットのコンソールを見たり、壁の角から覗きこんだりすることが出来ますし、体の位置をずらすことで発射物を回避するなど、多くのことが実現出来ます。ポジション・トラッキングは潜在的に大きな可能性を秘めていると同時に、多くの課題が新たに登場させています。
はじめに、ユーザはトラッキング・カメラの表示領域から出てポジション・トラッキング不能となることで不快な体験となるかもしれません。（方向トラッキングはDK1からの特許にもとづいたIMU技術によりカメラのトラッキング範囲の中でも外でも機能し、新たなカメラにもとづいた方向およびポジション・トラッキングが実装されています。）安定的で妨害されることのない体験を維持するためには、ユーザがカメラのトラッキング範囲から出てポジション・トラッキング不能となる前に警告を表示するべきです。さらにカメラの前でトラッキングされるうえで、より良い位置を確保するために何らかのフィードバックを受け取るべきです。
私たちの推奨として、トラッキング不能となる前にシーンを黒い画面へとフェードさせるほうが、ユーザが移動する際にポジション・トラッキングに反応しなくなるよりも、方向感覚を失ったり不快な視界となったりするよりも良い体験となるものだと考えています。SDKはポジション・トラッキング不能となったとき、デフォルトで方向トラッキングおよび頭部モデルを使用します。この対応により、DK1と同等の体験が再現されるものの、ポジション・トラッキングに反応してシーンのレンダリングがなされると考えていたユーザの期待に応えないことは、不快な体験につながります。
ポジション・トラッキングにより生じる二つ目の課題はユーザがバーチャルカメラの位置を過去には不可能であった不自然な位置に移動できるようになったことです。例えば、ユーザはカメラを移動させてオブジェクトの下を見たり、障害物の外側から見ることで従来のビデオゲームであれば隠されたはずの環境が見えてしまいます。反対に、これによって新たな相互作用の手段が生じるという側面もあります。例えば物理的することで隠れたままで覗きみる動作や環境にあるオブジェクトを観察出来ます。もう一方で、ポジション・トラッキングがなければ環境をデザインする際に通常は隠されるはずの部分がユーザによる技術的なチートが見つかってしまう場合が出てきます。このようにアートやアセットによってバーチャル環境におけるユーザの没入感が損なわれることのないように注意を払って下さい。
もうひとつ関連した問題は、ユーザが壁やオブジェクトに向かって体を前後に倒すことでバーチャル環境をクリッピングして突き抜けることが潜在的に発生することです。ひとつの対処方法はユーザがトラッキング範囲にいるかぎりはオブジェクトを突き抜けることが不可能となるように環境を設計することです。上記の推奨事項を遵守して、ユーザが何かを突き抜ける前にシーンを黒い画面にフェードさせます。他には、ユーザが最適な快適ゾーンである0.75-3.5メートルの範囲より近くまでオブジェクトに近づくことを防ぐ手法も似ているようですが、見ている側からするとすべてのものから遠ざけられて透明のバリアーに囲まれてるように感じさせるかもしれません。実験や試行を通じてユーザビリティと快適さのバランスをとった最適な解決策を見つけることが必要となります。
開発者の方がポジショントラッキングによる課題に新たな革新的解決策を模索すること推奨する一方で、ユーザからポジショントラッキングの手段を奪ったり、バーチャル環境がみえているときの性質を変化させることは推奨しません。バーチャル環境がポジショントラッキングに対して反応しないこと（または違和感をもって反応すること）は、特に現実世界で移動したときにユーザにとって不快な体験につながります。この課題に取り組むあらゆる手法において、何が起きているのかを適切にユーザにフィードバックして、通常の相互作用を取り戻せるようにすべきです。
レイテンシ
レイテンシとは、ユーザの頭の動作が画面表示される画像に反映されるまでの時間（motion to photon）として定義します。センサーの反応、統合、レンダリング、画像転送、そして画面レスポンスまでを含みます。
レイテンシを最小化することは没入感のあり快適なVRにとって極めて重要であり、Oculus Rift が実現するレイテンシの低いヘッドトラッキングはまさに他のテクノロジーとの大きな差別化要因といえます。ゲームの中で motion to photon レイテンシを最小化するほど、ユーザにとって没入感のあり快適なVR体験が実現されます。
我々は、レイテンシを、ユーザーの頭部が動いてからと更新された画像がスクリーンに表示される(「motion-to-photon」)までの合計時間と定義します。 これには、センサーのレスポンス、 統合、 レンダリング、画像転送、そしてディスプレイのレスポンスの時間が含まれます。
レイテンシによる作用へのアプローチのひとつとして、プレディクティブ （予測）トラッキングという技術があります。motion to photon パイプラインを縮めるまでにはいたらないものの、現在パイプラインにある情報を使用して次にユーザがみるであろう場所を予測します。この際にセンサーの読み取りから画面へのレンダリングに伴う遅延を考慮するために、レンダリングするタイミングにユーザが見る場所を予測して、センサーが読み取りした場所を描画そのものでなく予測された場所を描画します。開発者には、SDKで提供されているプレディクティブ トラッキングのコードを実装することを推奨します。この仕組みの詳細については Steve LaVAlle のブログ記事である http://www.oculusvr.com/blog/the-latent-power-of-prediction/ を参照したうえで、関連するSDK ドキュメンテーションを確認下さい。
Oculus ではリアリティあるVRの実現には20ms 以下のレイテンシがボーダーラインになると考えています。ボーダーラインの値を超えるとユーザは没入感や快適さをより少なく感じるようになります。さらにレイテンシが 60 ms を超えると、頭の動作とバーチャル世界のモーションが同期していないように感じられ、不快感と方向感覚の喪失を感じるようになります。レイテンシが大きいことはシミュレータ酔いの主要な要因となると考えられています。いずれにしてもレイテンシはユーザの操作感や存在そのものにとって破壊的になりえるものです。理想論としては0 ms に近ければ近いほど良い、ということは疑う余地がありません。もしレイテンシが回避できないものである場合はせめて継続的に発生しないほうがより快適となります。この理由からレイテンシについては出来るかぎり最小化し、継続的でないものとすることを目指すべきです。
レイテンシとは、ユーザの頭の動作が画面表示される画像に反映されるまでの時間（motion to photon）として定義します。センサーの反応、統合、レンダリング、画像転送、そして画面レスポンスまでを含みます。
レイテンシを最小化することは没入感のあり快適なVRにとって極めて重要であり、Oculus Rift が実現するレイテンシの低いヘッドトラッキングはまさに他のテクノロジーとの大きな差別化要因といえます。ゲームの中で motion to photon レイテンシを最小化するほど、ユーザにとって没入感のあり快適なVR体験が実現されます。
我々は、レイテンシを、ユーザーの頭部が動いてからと更新された画像がスクリーンに表示される(「motion-to-photon」)までの合計時間と定義します。 これには、センサーのレスポンス、 統合、 レンダリング、画像転送、そしてディスプレイのレスポンスの時間が含まれます。
レイテンシによる作用へのアプローチのひとつとして、プレディクティブ （予測）トラッキングという技術があります。motion to photon パイプラインを縮めるまでにはいたらないものの、現在パイプラインにある情報を使用して次にユーザがみるであろう場所を予測します。この際にセンサーの読み取りから画面へのレンダリングに伴う遅延を考慮するために、レンダリングするタイミングにユーザが見る場所を予測して、センサーが読み取りした場所を描画そのものでなく予測された場所を描画します。開発者には、SDKで提供されているプレディクティブ トラッキングのコードを実装することを推奨します。この仕組みの詳細については Steve LaVAlle のブログ記事である http://www.oculusvr.com/blog/the-latent-power-of-prediction/ を参照したうえで、関連するSDK ドキュメンテーションを確認下さい。
Oculus ではリアリティあるVRの実現には20ms 以下のレイテンシがボーダーラインになると考えています。ボーダーラインの値を超えるとユーザは没入感や快適さをより少なく感じるようになります。さらにレイテンシが 60 ms を超えると、頭の動作とバーチャル世界のモーションが同期していないように感じられ、不快感と方向感覚の喪失を感じるようになります。レイテンシが大きいことはシミュレータ酔いの主要な要因となると考えられています。いずれにしてもレイテンシはユーザの操作感や存在そのものにとって破壊的になりえるものです。理想論としては0 ms に近ければ近いほど良い、ということは疑う余地がありません。もしレイテンシが回避できないものである場合はせめて継続的に発生しないほうがより快適となります。この理由からレイテンシについては出来るかぎり最小化し、継続的でないものとすることを目指すべきです。
