2014年9月5日金曜日

【非公式翻訳】Oculus SDK ベータ版(バージョン 0.4.2)

このドキュメントは有志により翻訳されたもので、オフィシャルではありません。オリジナルのページはhttps://developer.oculusvr.com/?action=hist&ver=21を参照して下さい。
This document is unofficially translated by users. Please refer to the original document here: https://developer.oculusvr.com/?action=hist&ver=21
Copyright © 2014 Oculus VR, Inc. All Rights Reserved.

----------------------------------------------------------

バージョン 0.4.2 ベータ版 2014/9/4

新機能

  • Windows サービスとして OVRServiceLauncher を追加することで、いくつかのシステムで発生していたサービスが起動しない不具合を解消。
  • Oculus Configuration Utilityの設定で目までの最小距離(minimum eye relief)に新たな彩度設定を追加することで色収差の問題を改善。
  • Riftsaverモードを追加し、Directモードのときヘッドセット未使用時にOculus Riftディスプレイをオフに変更。

バグ修正

Oculus SDK

  • ビルトインのレイテンシ・テスターがランダムに作動を停止してDK2のリセットが必要となる問題を解消。最新のランタイム・インストーラによりファームウェアを2.12にアップデートすることが必要。
  • LibOVR Win32 Display のコードより全てのATL参照を削除。
  • Oculus Configuration Utility のデスクトップ・モードでCPU使用率が100%となる問題を修正。
  • サービス停止時にOculus Configuration Utilityがサービス停止時に発生するラグを修正。
  • Oculus ランタイム・サービス(現名称はOVRServer)にいくつかの修正を反映。

Unity

  • 64ビットクライアントを32ビットサービス使用時に発生するクラッシュや不具合を修正。
  • スクリプト初期化順によるNullReferenceException を修正
  • カメラのスタッターの機能をもつTimeWarp における競合状態を解消

2014年8月26日火曜日

Oculus VR ベストプラクティス ガイド【DK2】(非公式翻訳)

このドキュメントは有志により翻訳されたもので、オフィシャルではありません。オリジナルのページはhttp://developer.oculusvr.com/best-practicesを参照して下さい。
This document is unofficially translated by users. Please refer to the original document here: http://developer.oculusvr.com/best-practices
Copyright © July 2014 Oculus VR, LLC All Rights Reserved.

Special Thanks to Translators: @WheetTweet @___monta___


Oculus VR ベストプラクティス ガイド

2014年7月23日版


最新版およびもっとも最新の情報については下記サイトを訪問下さい:

作者 :
Richard Yao
Tom Heath
Aaron Davies
Tom Forsyth
Nate Mitchell
Perry Hoberman

このガイドの目的は開発者が次の観点を最大化するバーチャルリアリティを実現することです:

  • 眼球運動の快適さ - 目の疲れを回避
  • 身体的な快適さ - 方向感覚の欠如と吐き気
  • ポジティブなユーザ体験 - 楽しく、没入し魅力ある体験

注意:他のどのような媒体でもいえるように休憩なしの過剰な使用は開発者、エンドユーザ、あるいはデバイスそのもののためにも推奨しません。

ベストプラクティスの全体サマリ

レンダリング

  • Oculus VR の歪みシェーダを使用下さい。独自の歪みプログラムで近似すると、たとえ「あまり問題なく見える」 ようであってもユーザにとって不快感が生じる場合があります。
  • 投影行列は完全に正しいものとしましょう。頭部の動作に伴う現実世界の視線とのずれは小さな差異でも眼球運動の快適さや身体的な快適さを劣化させます。
  • バーチャルリアリティの没入感は開始から終了まで維持して下さい。Rift を通してユーザの視界に静的なイメージを固定表示しないで下さい(ユーザの頭の動きと連動しない全画面表示のスプラッシュスクリーンをなど)。不快な体験になりがちです。
  • 各々の目の映像は視点のみが違うようにすべきです。後処理エフェクト(例.ライトの歪み、ブルーム)は両方の目に漏れなく適用して、正しく統合された映像となるように z デプスも正しくレンダリングすべきです。
  • スーパーサンプリングおよびアンチエイリアスの使用により外見上の低解像度などは解消して下さい。特に各々の目の中心部では影響が大きいものです。

レイテンシの最小化

  • コードは最低でも Oculus Riftディスプレイのリフレッシュレート以上、垂直同期バッファなしで動作させて下さい。タイムラグやフレーム落ちはジャダーを生じるためバーチャルリアリティで不快感を生じます。
  • 理想的には、動作から表示までの目標時間(motion-to-photon)を 20ms 以下として下さい。(Oculus Riftのビルトインされたレイテンシ・テスターで測定できます)。コードを整理してセンサー融合(Riftセンサーの読み取り)からレンダリングまでの時間を最小化して下さい。
  • ゲームループのレイテンシは定数値でなく、時間の経過とともに変化します。SDKはいくつかのテクニックを駆使して(例.プレディクティブ・トラッキング、タイムワープ)、ユーザがレイテンシによる影響を受けないようにしていますが、体験をしている際にレイテンシのばらつきを最小化するようにしてください。
  • SDKのプレディクティブ トラッキングを使用し、関数呼び出しに対して正確な時間を引数として渡してください。プレディクティブ・トラッキングのパラメータはアプリケーションのレイテンシにより値が変化するためアプリケーションごとにチューニングする必要があります。
  • レイテンシの最小化および適切なレンダリングのためのコーディング手法を決定するうえでOculusRoomTinyのソースコードを参照して下さい。

最適化

  • レンダリング バッファ解像度を減らしてビデオメモリを節約しフレームレートを増加させてください。
  • ディスプレイ解像度を落とすことでパフォーマンス改善につながると考えがちですが、結果的には片目ごとのレンダリングバッファの解像度を犠牲にすることによる効果です。片目ごとのレンダリングバッファの解像度を落としつつディスプレイ解像度を維持することは、両方の解像度を落とす方法と比較して、視覚的な品質への影響がより少なくなります。

ヘッドトラッキングおよびビューポート

  • 環境の中でユーザの安定感を損なう機能は避けて下さい。ユーザ環境の水平線あるいは大きな物体を現実世界の動作と矛盾する形で回転させたり移動することは(回転や移動が不足する場合も含め)ユーザにとって不快感を生じる場合があります。
  • ディスプレイはヘッドトラッキングおよびビューポート変更に例外なく、常に反応すべきです。例えメニュー表示でゲームがポーズされたりカットシーンを表示させる場合もユーザは見回すことが出来るようにすべきです。
  • カメラの回転および移動はSDKのポジション・トラッキングを使用しながら頭部の動作と整合性をもって行なうべきです。差異が生じることは不快感を生じます。

加速

  • 加速は視覚と(内耳の)前庭覚との不整合を生じます。そのような不整合の時間および頻度は最小化して下さい。加速はできるかぎり短く(望ましくは瞬間的)、少ない頻度として下さい。
  • 「加速」とは正面にスピードアップするケースだけではありません。ユーザのあらゆる動作に当てはまります。減速したり停止したり、移動中または静止中に曲がったり、足踏みをしたり、横に押されたりすることも加速のパターンのひとつです。
  • 加速はできるかぎり必ずユーザが発動して制御するものとして下さい。カメラを揺らしたり、痙動したり、あるいは上下させることはプレイヤーにとって不快感を生じさせます。

速度

  • バーチャルリアリティでは固定位置から環境を眺めることがもっとも快適ですが、環境のなかでの動作が必要な場合、ユーザは一定速度で移動することがもっとも快適です。ユーザにとってバーチャル環境中の移動でもっとも快適となるのは現実世界での速度です。参考までに歩行速度は 1.4 m/s が平均的な歩行速度です。
  • 二つの地点間を歩かずにテレポートすることは場合により実験する価値はありますが、不快になることもあります。もしテレポートする場合は適切に視覚的なサイン告をあらかじめ示したうえでユーザが方向感覚を可能なかぎり維持できるようにしてください。
  • 一つの方向への移動するときに別の方向をみることは方向感覚の欠如を生じる場合があります。ユーザが移動方向と別の方向をみる必要性は最小化し、特に歩行速度より速い場合はなおさらです。
  • 垂直方向への振動は避けてください。0.2Hzの周波数で最も不快感を生じさせます。また、垂直方向への回転も避けてください。0.3Hzで最も不快感を生じさせます。

カメラ

  • カメラでズームインまたはズームアウトさせることはシミュレータ酔いの発症または悪化につながることがあり、特にカメラの動作速度が頭部の動作速度と異なる場合はなおさらです。今後の研究開発でユーザフレンドリーな実装方法が見つかるまでズーム効果を使用しないことを推奨します。
  • 第三者視点のコンテンツの場合、カメラの加速や動作がアバターのしていることに関わらず吐き気の原因となる場合があります。さらに、ユーザには常に環境を見回せるようにすべきであり、このことはコンテンツのデザイン自体にも影響する場合があります。
  • オイラー角はできるかぎり避け、望ましくはクォータニオンを使用して下さい。真っ直ぐ上や下をみることでカメラのテストを行い、安定させるとともに常に顔の向きと整合性をとってください。
  • 頭の揺れ(bobbing)は避けて下さい。垂直方向に小さく連続的な不快感を生じる加速が発生します。

シミュレータ酔い管理およびテスト方法

  • コンテンツのテストは偏りのない様々なユーザで行い、幅広い客層にとって快適であるようして下さい。開発者自身はテストにもっとも不向きです。繰り返しRiftに触れて、コンテンツに親しみを持つことでシミュレータ酔いに影響を受けにくくなっており、初めてのユーザと比べてコンテンツの不整合も気付きにくくなります。
  • 酔いに対する人々の反応や耐性は様々であり、視覚による乗り物酔いはコンピュータやテレビ画面と比較すると、バーチャル リアリティ ヘッドセットのほうが直ちに発生しやすいものです。客層は激しい体験を強く乗り越えようとはしません。
  • ユーザが視覚体験の強度を調整できるメカニズムの実装も考慮して下さい。これはコンテンツ依存となりますが、調整することとしては移動速度、加速の大きさ、表示された視野角の範囲などが含まれます。そのような設定のデフォルト値は強度の弱い体験とすべきです。
  • シミュレータ酔い管理にユーザが調整できる設定の全てにおいて、ユーザはリアルタイムで変更したいことがあります(例えば、バーチャルリアリティに慣れたり、疲れたりするため)。できるかぎり、ユーザがスタートからやり直しとなることなくゲーム内で設定変更できるようにして下さい。
  • ユーザの実世界の慣性系と一致するような独立した背景(skyboxのようにコントローラの入力では動かないが、ユーザの頭の動きによって動くもの)は、前庭系で視界の不整合を減らし、快適さを増すことができます(詳しくはAppendix Gを見てください)。
  • 高い空間周波数を持つイメージ(例:ストライプ、高解像度のテクスチャ)はバーチャル世界における知覚を高め、不快感を生じさせます。敏感なユーザにより快適な体験を提供するために、滑らかなテクスチャ(柄のあるものよりは原色のようなもの)を使う、あるいはオプションとして提供してください。
立体視の強度(「3D表示の度合」)  
  • パーソナライズされた現実味と正確にスケールされた世界においては、SDKで提供されるユーザプロファイルの顔中央から眼の距離を活用して下さい。
  • 近くでみると立体視を強く感じるものの、距離が離れるとすぐに消失することに留意して下さい。遠くにある数マイル離れた二つの山は机にある数インチ離れた二つのペンと同じ強度の感覚となります。
  • バーチャルカメラのあいだの距離を増すことによって立体視の強度が改善されることがあるものの、副作用には注意すべきです。はじめに、ユーザは通常よりも視点を収斂させる必要があり、これに合わせてカメラからオブジェクトを遠ざけないかぎり眼精疲労につながります。二つ目に、頭部の動作と眼の間の距離を同程度にスケールしない場合、視界における違和感や不快な体験につながります。

ユーザインタフェース

  • UIはバーチャル世界の3D部分であるべきで、理想的には視点から少なくとも 50cm 以上離すべきです。例えユーザの目の前に浮遊する平らなポリゴン、シリンダ、または球に描画された場合であっても同様です。
  • ユーザが眼球を回転しないとUIが見れない状況にしないで下さい。UIは画面の真ん中 1/3 の範囲に収めて下さい、そうでない場合も頭部の動作により確認できるようにすべきです。
  • 頭部の動作によりUI 要素が移動したり拡大/縮小する場合は注意して下さい(例えば、スクロールする長いメニューで頭を動かすことで読めるような場合)。ユーザの動作に対して正確に確実に反応させ、気が散る動作や不快感を生じることなく容易に読めるようにして下さい。
  • UI要素は3D世界に対して直感的で没入感を持たせるように考慮して下さい。例えば、残り弾数は浮いたHUDの上でなく、ユーザの武器の上に表示させるなど出来ます。
  • 照準線、目盛り線またはカーソルをターゲットするオブジェクトと同じ深度で描画して下さい。そうしない場合は目の焦点を合わせてない平面の深度にあるときにぼやけたり、さらに(または)二重のイメージとして映ったりします。

アバターの制御

  • Riftを被っているときは、ユーザ入力デバイスを見ることが出来ません。ユーザにはデフォルト入力方法など、慣れたコントローラの使用方法を許可して下さい。もしキーボードがどうしても必要ならば、ユーザは触覚によるフィードバックで操作しないといけないことを念頭に入れて下さい。
  • 頭部の動作そのものを入力制御として使用する、または制御するスキーム全体の中で文脈依存性を導入するの一つの方法として考慮下さい。

音声

  • 音声を設計するとき、ヘッドフォンを使用する場合は出力音源がユーザの頭部の動作に追従するけれど、スピーカーを使用するときは追従しないことを念頭に入れて下さい。ユーザがゲーム設定のなかで出力デバイスを選択できるようにして、ゲーム内の音声が正しい場所から発するよう、頭部の位置と出力音源の相対的な位置関係を考慮して下さい。
  • NPC(ノン・プレイヤー・キャラクター)の会話を中央あるいは左右のオーディオ・チャネルで均等に音声を出すことは一般的な実装方法であるもののVRで没入感を壊す場合があります。粗くともオーディオを空間化することでユーザ体験を改善出来ます。
  • オーディオ設計のときにポジション・トラッキングを考慮すべきであり、例えばユーザが音源に近寄るとたとえアバターが固定の場合でも音が大きくなるべきです。

コンテンツ

  • 距離に関して、現実世界における1メートルはUnityのおよそ1単位に相当させることを推奨します。
  • Oculus Rift DK2の光学設計ではユーザの眼からの距離が0.75メートルから3.5メートルの範囲であるオブジェクトを鑑賞することがもっとも快適です。環境全体のデプスはどの範囲をも占めることがあるとしても、ユーザが長時間鑑賞するオブジェクト(例えばメニューやアバター)はその範囲に収めるべきです。
  • 上記の快適な距離より近いオブジェクトに眼の焦点を当てると眼の水晶体の焦点があわず、はっきりとレンダリングされたオブジェクトがぼやけて見えるとともに眼の疲れにつながります。
  • 特にユーザの周辺で明視画像が使われると、敏感なユーザにははっきりわかるくらいにディスプレイのちらつきが起こります。このような不快感を生じさせないため、なるべく暗めの色を使ってください。
  • ユーザの身体を表現する仮想のアバターの使用には賛否両論があります。ユーザが肉体から抜け出たことを表現する方法として、VR体験において没入感を増し、ユーザの助けになるという意見がある一方で、実世界の身体と仮想の身体の不一致が、普段ない感覚(例えば、ユーザは椅子に座ったままなのに、アバターが歩いているのを上から見下ろしたり、見たりすること)を引き起こすとも言われています。自分の作品を設計するときは、これらの要素もよく考慮してください。
  • 他のシステムと同様に、解像度が問題となるところでは自身のアート作品のサイズやテクスチャに配慮して下さい(例えば、細いオブジェクトは避けて下さい)。
  • ユーザの現実世界から発生していない、予想しない垂直方向の加速、例えばボコボコや起伏のある地形の上を歩く、などは不快感を生じることがあります。歩く表面を平らにすることを考えたり、そのような地形を渡るときはユーザの視界をブレさせない、などして下さい。
  • ユーザが経験したことのない没入感を体験していることを意識して下さい。ゾッとしたり、ショッキングなコンテンツにより、過去のメディアでは実現できなかった度合いで、ユーザに重篤な効果があること(特にセンシティブなもの)を認識して下さい。プレイヤーにそのようなコンテンツがあることの警告を受けるようにして、心の準備があるのか選択できるようにして下さい。
  • コンテンツに深度の効果を出すため、立体視のエフェクトだけに依存しないで下さい。ライティング、テクスチャ、視差(ユーザの移動に合わせてオブジェクトが動くように見える事象)、および他の視覚的な機能は深度および空間の効果を出すにあたり等しく重要(あるいはより重要)です。 これらのデプスキューは立体視の向きや強度と整合性をとるべきです。
  • 環境や相互作用を設計する時、正面を向いたままの横移動(Strafe)、後退や、スピンの必要性など不快なVR体験となりがちなアクションは最小限にとどめて下さい。
  • 人が一般的に頭や体を動かすタイミングは、現在焦点を合わせているものから15-20度離れたものを注視するときです。ユーザにそのような視界の移動を強制させることを避けて、筋疲労や目の疲れを予防して下さい。
  • ユーザはどんなときでもどのような方向も見られることを忘れず、その際に没入感を壊すものは見せないで下さい(環境をレンダリングする際のチートなど)。

健康および安全

  • Riftの使用に伴う注意事項(付録 L)を良く読んで実践することで、自身、開発者、そしてユーザの健康および安全を保証して下さい。
  • 高解像度で1-30Hzの範囲での点滅や色の交互変化は止めてください。人によっては光過敏性てんかんを起こす場合があります。
  • 高解像度で高空間周波数の格子(例.微細な白黒の縞模様)を避けてください。この場合も、てんかん発作を起こす場合があります。

付録 A - ベストプラクティス ガイド 前書き


  • このガイドにより快適でユーザビリティの高い VR コンテンツを作成する手助けをします。最新の情報については http://developer.oculusvr.com/best-practices を参照して下さい。

これらの Appendix により Oculus Rift での バーチャルリアリティ(VR)体験についての前述で
ようやくされたベストプラクティスの詳細を見ていきます。ベストプラクティスとは高い品質を保証する手法であり、VR のように発展途上な媒体の場合は特に重要なものです。Oculus SDK の概要やドキュメンテーション、また統合ゲームエンジンライブラリ(例えば Unity, Unreal Engine, および UDK) のドキュメンテーションは http://developer.oculusvr.com に掲載しています。

VR は没入感を体現する媒体です。バーチャルな三次元世界(あるいは電子的に再現された現実世界)に完全に連れて行かれたかのようなセンセーションを巻き起こします。さらにスクリーンベースのメディアと比べて遥かに衝動的な体験を提供します。脳を継続的に騙し続けるにはディテールへの細かな配慮が必要です。例えるならば部屋の窓を通して中を覗きみることと、ドアの中に入って自由に動き回ること、ぐらいの違いがあります。

Oculus Rift はあるカテゴリーにおいて初めて実現された VR システムといえます。それは低価格で、高品質なデバイスにより幅広い視野角と最小限のラグ、というグループです。現在に至るまで VR は研究所や、政府機関、あるいは財力のある企業に限定されていました。Oculus Rift により、開発者、設計者、さらにアーティストがリーダーシップをとって、グローバルな顧客層に対して想像力溢れる世界が提供されています。

基本的なベストプラクティスを知らずに VR 体験を作り上げようとすることは、シミュレータ酔いの原因となり眼精疲労、方向感覚の欠如、吐き気が組み合わさります。歴史的に多くの問題は VR ハードウェアが最適化されないパラメータ設定、例えばシステムのレイテンシ等が根本原因となっています。Oculus Rift は VR デバイスの新世代の代表格であり、過去のシステムの欠点を克服しています。しかし、例えハードウェアに欠陥がなくとも、不適切に設計されたコンテンツにより快適な体験が実現されないことがあります。

VR は比較的難解で独特のルールがあるため、信頼ある見解を示すには十分に検証されていない側面があります。こういったケースにおいては、まだその状況であることともに理論上の見解とこれまでの観察を示しています。興奮できる快適な体験を設計するにあたりユーザテストは絶対的に不可欠です。メジャーな媒体として VR が普及するにはまだ歴史が浅く、信頼できる確立された手法が十分あるといえません。この点についてはOculus Rift コミュニティの皆様がフィードバックを下さることで、これら VR ベストプラクティスおよび適切な手法を成熟化できることを切に願っています。

忌憚のないご質問やご意見についてはbestpractices@oculusvr.comまで送信ください。

付録 B - 両眼視、ステレオ3D、およびデプス キュー



  • 両眼視差により立体感は脳内で判断されます
  • テクスチャおよびライティングにおいて、単眼のデプス キューを軽視すべきでありません
  • Oculus Rift ではユーザの眼からの距離が0.75メートルから3.5メートルの範囲がもっとも視界として快適です。(Unityにおいて1単位は1メートルに相当します)。
  • OVR 調整ツールを使用してバーチャルカメラ間の距離をユーザの瞳孔間の距離と一致させます
  • 確実各々の目の画像が整合して適切に統合されるようにして下さい。片方の目でのみ映る、または著しく異なる場合はひどく見えます

基本

両眼視は同時に二つの世界をそれぞれの目で見る際に、わずかな差異があり、脳内で統合的に判断して立体のステレオスコピック映像とする様子を表し、あるいはこの体験をステレオプシスとも呼びます。左右の目の視差により両眼非対応が生まれます。ステレオプシスが起きるのは現実的な物体を左右からみても、あるいは二つの平面画像を適切な差異(つまり非対応)でみても、同様に発生します。

Oculus Rift は二つの画像をそれぞれの目に表示して、短い距離で分けられた二つのバーチャルカメラで生成します。いくつかの用語の定義を順にみていきます。目の間の距離は瞳孔間距離(IPD)と呼ばれ、二つのバーチャルカメラの間の距離はカメラ間距離(ICD)と呼びます。IPDは 52mm から 78mm の間で変化するとはいえ平均的な IPD (米軍兵士4000名の統計)は 63.5mm であり、Oculus Rift の軸間距離(IAD) と一致します。IADとは Oculus Rift のレンズの中心間の距離です(本ガイドのバージョンでの定義)。


単眼デプス キュー

ステレオプシスは脳が処理する数多くのデプス キュー(奥行きの手掛かり)のうちのひとつです。他のデプスキューのほとんどは単眼です。つまり片目だけで視る、あるいは両目で平面画像を視たとしても立体を認識します。バーチャルリアリティにおいては、頭の動きによる遠近視差は立体視を必要としませんが、デプスを伝達し、ユーザに快適な体験を提供するためには極めて重要です。
他の重要なデプスキューに含まれるのは: 透視(遠くに向かうものは消失点に向かって見える)、相対スケール(遠くのものが小さく見える)、オクルージョン(近くのオブジェクトが遠くのオブジェクトの間の視界をふさぐ)、大気透視(大気の屈折により遠いオブジェクトがぼやける)、肌理(きめ)勾配(同じ肌理、つまりテクスチャなら遠いほど細かく見える)、そしてライティング(ハイライトおよびシャドウによりオブジェクトの形状と位置を認識する)があります。現世代の 2D コンテンツは既にこれらのデプスキューの多くを活用していますが、ここで言及している理由はステレオ 3D の斬新さを考慮すると重要性を軽視しがちであるためです。

Oculus Riftで快適に鑑賞するための距離


オブジェクトに焦点を合わせる(鑑賞する)ときに目の快適さを考えるうえで二つの課題が主に重要です。それは調節、輻輳の要求です。

調節の要求とは目が水晶体の形を調整して深度平面に焦点を合わせることです(調節とよばれるプロセス)。輻輳の要求とは目が内側に回転して特定の深度平面で交差するようにする度合を示します。現実世界では、これらの二つは強く相関していて、瞳孔近見反射と知られる現象があります。これは目の輻輳が目の調節に影響する度合、およびその逆の相関による現象です。
 
Oculus Riftは他の立体視技術(例.3D映画)と同様に調節の要求と輻輳の要求を分離する特殊な状況を作りだします。調節の要求は固定ですが、輻輳の要求は変動です。その理由は立体視の実際の映像は視界から一定距離に固定されているものの、各々の目に映し出されるそれぞれの映像は様々な深度平面の物体に対して視線の焦点を合わせるため、依然として目が回転することが必要です。

研究により、鑑賞する人が不快になる前に調節の要求と輻輳の要求が互いにどう異なるか調査がなされています。1)  現在のOculus Rift DK2の光学では1.3メートル先の画面をみていることと同等です。(製造上の公差およびOculus Riftのレンズの力からすれば、この数字も概算です)。眼精疲労を防止するには、ユーザが長時間焦点を当てることが分かっているオブジェクト(例.メニュー、環境上の関心事になるオブジェクト)はおおよそ0.75メートルから3.5メートル離れた距離にレンダリングされるべきです。

明らかに、完全なバーチャル環境においてはこの理想的に快適な範囲外でいくつかのオブジェクトをレンダリングする必要があります。ユーザが長期間これらのオブジェクトに長時間焦点を当てる必要がないかぎり、大きな問題ではありません。Unityでプログラミングするとき1単位は現実世界での1メートルに相当するため、オブジェクトは0.75から3.5単位だけトル離れた距離に配置すべきです。

今後の研究開発の一環としてOculus Rift の将来リリースでは光学を必然的に改善し快適な視点距離の範囲を広げていきます。この範囲がどのように変化しようとも2.5mは快適な距離であるべきであり、メニューやGUIのようにユーザが長時間焦点を当てるアイテムとして将来も問題なく見られることが保証される距離です。

聞いた話では、 Oculus Rift のユーザによってはバーチャル画面の深度平面に眼が遠近調節している際に世界の全てのオブジェクトが焦点が合っていることの不自然さについて言及している人がいます。これは潜在的に少数派のユーザでは適切に焦点を合わせることが難しいために、不満や眼精疲労につながります。

いくつかの開発者の発見によれば深度平面の効果はユーザがどこをみているか分かっている場合に没入感かつ快適さを伴います。 例えばユーザが表示したメニューの背景を人為的にブラーをかけたり、鑑賞するオブジェクトの深度平面の範囲外にあるオブジェクトにブラーをかけたりします。これにより現実世界での自然な視界での現象を再現するのみならず、ユーザの焦点の外にある目立つオブジェクトが邪魔となることを防止できます。

残念ながら、ユーザが非合理的、異常、または予見不能な動きを選択した場合まで制御することはできません。 VRにおいて目がオブジェクトから数インチ離れたところに立ち続けて一日中眺めることをするかもしれません。われわれはこのことが眼精疲労につながることを知っているものの、この特異な事象を防止するための極端な対策、例えば衝突判定によりオブジェクトの近くに近づけなくする対策は総合的なユーザ体験を損なうだけです。 開発者としてのあなたの役割は、ユーザが自らを快適でない状況に陥ることを回避させることです。

カメラ間の距離の効果


カメラ間の距離(つまり2つのレンダリングするカメラの間の距離)を変更すること、はユーザに影響を与える重要な方法段です。もし、カメラ間の距離が広いと、ハイパーステレオという、誇張された奥行きを経験することになり、狭いとハイポステレオという奥行きが感じられない状態になります。
カメラ間の距離を変更することはユーザにさらに2つ効果をもたらします。
一つ目の効果は、 与えられたオブジェクトを見つめるための視線の角度を変更します。カメラ間の距離を広げたら、ユーザは同じ物体を見る場合でもより視線を集中させる必要があり目の疲れを引き起こしかねません。
ふたつ目の効果は、仮想環境内でのサイズの感覚を変更できることです。
後者は、後続の「付録J コンテンツ作成 ユーザと環境のスケール」に記載しています。
仮想空間内のサイズ感覚と、奥行きを現実と一致させるために、カメラ間の距離をユーザの実際のIPDに設定してください。もし、スケール効果を適用するなら、頭全体のモデルを使って、正確にユーザの現実世界で頭を動かす感覚を適用するだけではなく、必ず距離に関係する我々のガイドも活用してください。


図 1: 左右のシーンカメラの間のカメラ間距離(ICD:左図) はユーザの瞳孔間距離(IPD:右図)と一致させるべきです。 ICDに適用するスケール係数はすべて頭部モデル全体」およびこのガイドを通じて提供された距離に関連したガイドラインに適用する必要があります。

二つのイメージを統合する際の潜在的な問題


しばしば現実世界において各々の目が異なる視点となるものの、それが問題になることは殆どありません。柱の陰から片目で覗き見ることは現実世界でもVRでも同様の体験ができます。実際、各々の目の異なる視点はメリットがあります。例えばFBIとなって(現実世界またはVR)背の高い草の中で隠れるとします。各々の目の異なる視点により草の間をみることが出来て、あたかも草がないかのような視界が得られます。2D画面のビデオゲームで同じことを行うとそれぞれの草の後ろは覆い隠されてしまいます。

それでもVRでは(他の立体視映像と同様に)ユーザにとって煩わしい潜在的に不自然な状況を生じるかもしれません。例えばレンダリングのエフェクト(ライトの歪み、パーティクルエフェクト、ライトブルーム、等)では正しい視差で両目に映るべきです。失敗した場合ちらつきや揺らめき(片目にしか何か映らないとき)が映ったり、誤った深度で浮かんだりします(もし視差が無効になっていたり、ポストプロセッシングエフェクトがオブジェクト上で描画すべきコンテキスト深度に正しくレンダリングされない場合、例えば反射シェーダパスの場合)。両目の映像が本来備わっている視点の違いによる立体視差以外の違いをなくすことが重要です。

複雑な3D環境ではより問題になりませんが、映像を正しく統合して解釈するにあたりユーザの眼から十分な情報を脳が得ることが重要です。3Dシーンを構成するラインやエッジは一般的に十分ですが、しかし広範囲の繰り返しパターンは目の映像を意図しない形で統合する要因となりうるので注意して下さい。深度に対する目の錯覚により誤認につながること(例えば、「ホロウマスク錯視」のように凹面が通常の凸面の表面として認識される錯視)も注意が必要であり、特に単眼のデプスキューが不足している場合です。

1 Shibata, T., Kim, J., Hoffman, D.M., Banks, M.S. (2011).  The zone of comfort: Predicting visual discomfort with stereo displays.  Journal of Vision, 11(8), 1-29.  

付録 C - 視野角およびスケール - SDK バージョン 0.4



  • 現実世界 FOV(視野角) およびバーチャル世界 FOV (以下、各々 cFOV と dFOV と略す)は必ず一致させる必要があります。要は、一般論としてデフォルトの FOV を変更しないことです。


正確性を期すため、「視野角」の異なる用法をきちんと区別することから始めます。ディスプレイの FOV (dFOV) の定義はユーザの視野角のうち VR コンテンツを占める部分、です。これはハードウェアおよび視覚の物理的な特徴といえます。もうひとつの FOV とはカメラの FOV (cFOV) であり、任意のタイミングでバーチャル世界の中でカメラがレンダリングする範囲、を意味します。全ての FOV は垂直、水平、かつ/または斜めの寸法により定義されます。

従来のスクリーンベースの CG ではカメラの cFOV を任意にセットすることは自由であり、例えば広角の魚眼レンズから狭角の望遠レンズまでセットできました。 コンピュータユーザの周辺視野はディスプレイのある部屋を見ることが出来て、通常はユーザの頭部の動作に対してモニターは反応しません。画像は没入感を伴うかもしれませんが、脳は現実のものと思い込むようなことはなく、cFOV と dFOV の差異はほとんどの人に影響ありません。

バーチャルリアリティの世界では外部の空間を見ることがありません。バーチャル世界は視野角の大部分を占めて、頭の動作に合わせた唯一の視覚的フィードバックとなります。このために cFOV と dFOV が完全に一致する必要があります。これらの二つの値の比はバーチャルリアリティの世界ではスケールと呼ばれます。スケールはつねに1.0 であるべきです。

Oculus Riftでは、最大のdFOVは画面、レンズ、およびユーザの目とレンズの間の距離により決定されます(一般的に目がレンズに近いほどdFOVが広がります)。コンフィグユーティリティはユーザが見ることのできる最大のdFOVを測定し、これをプロファイル情報として保存します。SDKはこの情報にもとづいてdFOVに合致するcFOVを推奨します。人によっては片目が他方の目よりスクリーンとの距離が近い場合があるため、各々の目が異なるdFOVを保有する場合があり、それは一般的なことです。

dFOV と cFOV の差異は非常に不快となりがちです。シーンのスケールは現実世界の縮尺と合わず映ることになり、デフォルトの歪み補正値はレンダリングされたシーンがワープするかのようになります。カメラの FOV を調整すると、シミュレータ酔いを引き起こす場合があり、前庭器-視覚反射(VOR)の不適応につながり、ひいては頭の動作の差異にオブジェクトに対する焦点が安定しなくなります。この不適用によりVR体験の際にユーザは不快に感じるかもしれず、Oculus Riftを取り除いた後の視覚運動の機能に影響するかもしれません。

SDKによりスケールを変更せずにcFOVおよびdFOVの補正が可能となり、視覚イメージの周りに黒い境界を追加することで実現されます。より小さな視覚イメージを使用することでレンダリングのパフォーマンスを向上や、特別なエフェクトとして働く手助けとなります。注意すべき点として40度の視覚イメージを選択した場合、スクリーンの大部分は黒画面となります(これは仕様どおりでバグではありません)。もうひとつ特筆すべき点として視覚イメージの大きさを縮小することでユーザは通常に視覚イメージが大きかったときよりも頭部の動作をより大きく行うことが必要であるため、筋力の疲れやシミュレータ酔いにつながるかもしれません。

いくつかのゲームでは双眼鏡や狙撃者の焦点合わせに「ズーム」モードが必要です。VRにおいて実現することはトリッキーであり、単純にズームを実装すると頭部の動作と見かけ上の世界のモーションの連携が崩れて不快感を生じる場合があるため、多大な注意が必要です。この点については将来的なブログ投稿やデモを見逃さないで下さい。

2 Stoffregen, T.A., Faugloire, E., Yoshida, K., Flanagan, M.B., & Merhi, O. (2008).  Motion sickness and postural sway in console video games.  Human Factors, 50, 322-331. 3 Draper, M.H., Viire, E.S., Furness, T.A., Gawron, V.J. (2001).  Effects of image scale and system time delay on simulator sickness with head-coupled virtual environments.  Human Factors, 43(1), 129-146. 4 Moss, J. D., & Muth, E. R. (2011). Characteristics of Head-Mounted Displays and Their Effects on Simulator Sickness. Human Factors: The Journal of the Human Factors and Ergonomics Society, 53(3), 308–319.

付録 D - レンダリング技法


  • 細かい表示を行う際には、Riftのスクリーン解像度(の低さ)に気を配ってください。文章を可読にするため十分大きく鮮明にし、ユーザーが注意を向ける部分では薄いオブジェクトや装飾的なテクスチャを避けてください。

ディスプレイ解像度


DK2のRiftは、1920×1080で低残像のOLEDディスプレイと75Hzのリフレッシュレートを備えています。1280×720で残像の残る、60Hzの液晶ディスプレイを備えたDK1を超えています。解像度が高くなることは、画像がよりクリアに鮮明に見え、低残像と高いリフレッシュレートが、DK1で見られた多くのモーションブラー(例えば、頭を動かした時に起こる残像)を除いてくれます。
DK1の解像度では個々のピクセルが見えてしまうため、スクリーンドア(網戸)効果というアーティファクトが引き起こされ、画像に黒い格子模様が重なって見えます。格子模様は実際にはピクセル感の空白です。一方、DK2では、 ペンタイル構造を持ちます。これはハニカム型効果を生み出します。ディスプレイのサブピクセル別の独特の構造により、赤色がこの効果を大きくします。
   
レンズ歪み効果と連携することで、細かいイメージ(テキストや細かいテクスチャ)によっては、コンピュータのモニタで見る場合とRiftを覗いて見る場合で異なって見えることがあります。開発中または調整中に、アートワークやアセットの見え方を確認するのは、バーチャルの質を保証するために必須です。

図2: DK1でみられるスクリーンドア(網戸)効果

ディスプレイのちらつきの理解と回避


低残像のDK2有機ELディスプレイには長所と短所がある。モーションブラーを低減させるメカニズム、つまりミリ秒サイクルでスクリーン全体の輝度の明暗切り替えは、敏感なユーザにとってのディスプレイのちらつきにも結びつく。ブラウン管モニター(そして実は、現在の有機ELディスプレイのいくつかも同様)で90年代に耐えられた人々はディスプレイのちらつきと、その潜在的な眼精疲労につながる作用に慣れています。ディスプレイのちらつきは一般的にスクリーン全体、またはその一部の急激な明暗の「パルス」として捉えることができます。一部の人々はちらつきにきわめて敏感であり、結果的に目の疲れ、疲労、頭痛を生じます。そうでない人々は、それにまったく気づかなかったり、ネガティブな症状が生じません。それでもディスプレイのちらつきを誰もが感じ取る可能性を高めたり、下げたりするいくつかの要素があります。

ユーザがちらつきを感じ取る度合はいくつかの要因から構成されます。ディスプレイが「オン」「オフ」モードの間を相互に切り替わる割合、「オン」モードのライトの明るさの度合、網膜のどの部分が刺激されたか、さらには日中における時間帯や個人の疲労度合でさえも要因に含まれます。

開発者にとって重要な情報が二つあります。ひとつめは、視界の中央より周辺部のほうがちらつきに敏感である、ということです。ふたつめは、スクリーン映像が明るいほどちらつきが大きくなることです。より明るい映像、特に周辺部の視野にある場合(例.明るく白い部屋に立っている、等)では明白にディスプレイのちらつきを感じ取る状況を作り出すかもしれません。出来るかぎり暗い色を使用して下さい(特にプレイヤーの視野の中央の外にある領域において)。

リフレッシュレートが高いほど、ちらつきを回避して感じ取りにくくなります。垂直同期あり、バッファーなし、75FPSを常に維持することが極めて重要であることの一つの理由はこのためです。時の経過とともにVRハードウェアが成熟すれば、多くの場合にリフレッシュレートおよびフレームレートは75FPSを超過します。

レンダリング解像度


DK2のRiftは1920×1080の解像度を持ちます。しかし、レンズの歪みは、スクリーン上にレンダリングされたイメージが通常に見えるようにRiftに送られなければならないことを意味します。伝送の間適切なピクセル深度を提供するには、左右の目に、画面の半分の解像度よりも大きな解像度のイメージをレンダリングすることが必要です。

性能の低いグラフィックボードでは、このような巨大なレンダリング対象によりフレームレートが低下しVR体験が劣化する可能性があるため、アプリケーションは解像度を落として性能[(フレームレート)]を向上させることを選択することもできます。このとき、Riftに送る解像度を下げるよりも、シーン内で用いられているテクスチャの解像度を下げるほうが好ましいと言えるでしょう。テクスチャの解像度を下げることでパフォーマンスを向上させつつ、できる限り視覚的なディティールを保つことができます。

この処理の詳細はSDKで説明されています。

動的にレンダリングされたインポスター/ビルボード


目からの距離が大きくなるほど深度の認識を感じにくくなります。目の近いところでは、立体視によって机にある二つのオブジェクトのどちらが近いかミリ単位で判別できるものです。目から遠くなるほど、これは難しいことであり、例えば公園の反対側にある二つの木を見た場合にはどちらがより離れているか判断するためには数メートル以上離れている必要があるかもしれません。さらにスケールを大きい場合、例えば遠くにある二つの山のどちらがより近いかを判断するにはキロメートル単位で離れている必要があるかもしれません。

深度の認識を相対的に感じ取る性質を逆用することで、マシンパワーを節約できます。すなわち3Dシーンを完全に作成せずに、代わりに「インポスター」(偽物)や「ビルボード」を使用する方法があります。例えば遠くの山を3Dでレンダリングする代わりに、左右の目の映像に一つポリゴンを置いて平面画像をレンダリングすることが出来ます。伝統的な3Dゲームと同様にVRで両方の目を騙すことが出来ます。

インポスターの有効性は関係するオブジェクトの大きさ、オブジェクトの内部および周辺のデプスキュー、登場時のコンテキストによって大きく異なることに注意して下さい。5) インポスターの見た目や感触がしっくり来るためには自身のアセットのテストを個別に実施する必要があります。目立たずにブレンドを行うためには、インポスターがカメラから適切な距離だけ離した位置としたうえで、実際のシーン要素とインポスターのシーン要素のインタフェースが没入間を損なわないことを慎重に確認して下さい。

ノーマルマップと視差マップの比較


「ノーマルマップ」と呼ばれるテクニックは3Dモデルに頂点情報の詳細を提供せずに、現実的なライティングのキューが深度およびテクスチャを伝達する手法です。現代のゲームで幅広く使用されているに関わらず、立体視で眺めたときは若干訴求力が弱くなります。ノーマルマップが両眼視差や動作視差の主要因とならないため、オブジェクトモデルに描画された平坦なテクスチャと同じ種類の映像を生じます。

「視差マップ」はノーマルマップの考え方を踏襲しながら、ノーマルマップで取り扱わないデプスキューに対応します。視差マップは、コンテンツ作成者により提供された追加の高低マップを使用することで、サンプリングした表面テクスチャの座標をシフトします。テクスチャ座標のシフトはシェーダのレベルで算出されたピクセル単位、または頂点単位でビュー方向を使用して適用されます。衝突平面に影響しない、きめ細かなディテールを持つ煉瓦の壁や敷石の通路といった表面を描画する場合に、視差マップはもっとも効果を発揮します。


付録 E - モーション

  • 頭や体以外は動かさずにユーザが周囲を見回せる環境がもっとも快適なVR体験です。
  • ユーザの動作が必要な場合、遅い移動速度 (歩行/ジョギングのペース) が新しいユーザにとっては最も快適です。
  • あらゆる加速は短く、また頻度を少なくします。
  • ユーザの動作およびカメラは必ず同期すべきです。
  • FPSゲームで頭を揺らす動作は使用しないで下さい。
  • 後ろ向きや横向きに移動する必要性を最小化した体験はもっとも快適です。
  • 画面の大部分を占める階段や繰り返しパターンといった動作を強く意識させるシチュエーションがあることを意識する。

動作のスピードおよび加速


ここで「動作」とは現実世界での動きにマッピングされないバーチャル環境でのあらゆる動きを指します。動作や加速の発生は、現実世界の体が固定されているにも関わらず主にバーチャル環境のなかをユーザのアバターが移動すること(移動または乗り物により)に起因します。このような状況はユーザの視界では空間上を移動していないにも関わらず、身体の感覚(前庭覚や固有受容)で全く逆を感じ取るため不快な体験となりがちです。視界と別に自己の動作があるという錯覚は「ベクション」と呼ばれ、シミューレータ酔いの主な発生原因です。

動作のスピードはシミュレータ酔いになるまでの時間に比例しますが、必ずしもその度合いや増加度合いとは相関しません。可能なかぎり動作のスピードを典型的な人間の移動速度に合わせること、最低でもユーザがそれを調整できるようにすることを推奨します(歩行は1.4 m/s、ジョギングは 3 m/s)。

VRコンテンツについては加速はより大きな問題です。この理由は人間の前庭器が反応するものとして加速が大きな要素であり、加速を実際に頭や体に加えることなく、加速を体験させようとすることは不快感を生じさせます。(その理由についての詳細なディスカッションについてはシミュレータ酔いの章を参照して下さい。

物理的な観点から加速とはユーザのバーチャル世界における任意の速度の変化を表します。通常は加速というものを前方方向への速度の増加として捉えることが多いものの、実際には移動速度の減少または停止、回転、ひねり、あるいは止まった状態からの回転、横方向あるいは縦方向への移動の開始(終了も同様)も含みます。Oculus VR の社内検証結果として瞬間的な加速のほうが徐々に加速するよりも快適であることが判明しています。加速がどれぐらいの長さであっても五感の間で矛盾を生じさせるため、加速の頻度、大きさ、長さにより不快感が増加します。いくつかの例外はありますが、できるかぎり加速の長さおよび頻度を最小化することを推奨します。

操作の自主性

ドライバーが同乗者と比べて車酔いしにくいことと同様に、ユーザが見る映像に対する操作の自主性を増やすことでシミュレータ酔いを防止することが出来ます。強制的に移動させられるのでなく、ユーザが自分で移動できるようにしてカメラを動かし回さないこと、例えばユーザが殴られたり打たれたりしないことです。通常の画面では見映えの良い効果かもしれませんが、VRにおいてはひどく酔うものです。同様にしてディスプレイをフリーズさせてユーザの頭の動作に反応しない状態を避けて下さい。一般論としてユーザの動作とカメラの動作が同期しないことはどのような理由であっても避けて下さい。

過去の研究によれば、ユーザにバーチャル体験に先立ってこれから起きることの予見や予兆となる視覚的な動作を行うアバターを提供することで、心の準備が出来て不快な体験が抑制されます。8) これは第三者視点のゲームでは予期せぬ利点であり、もしプレイヤーのアバターの動作によってカメラが何をするのか的確に予見できる場合、ユーザはバーチャル環境で近い将来に行う動作に対する心の準備が出来て、より快適な体験につながります。

頭揺れをなくす

いくつかのFPSゲームではカメラを緩やかに上下させることで歩く動作をシミュレーションしようとします。これはコンピュータまたテレビ画面で人間の動作として再現するには効果的かもしれませんが、没入感を伴うヘッドマウントVRにおいては問題になります。常に上下する動作はユーザのビューに対して加えられる新たな加速であり、すでに述べたように不快感を生じることになります。カメラの位置であれ回転であれ、現実世界でユーザが自ら動作していないことを起因として頭を揺らすような動作を導入することは避けることを推奨します。

正面および水平方向の移動

現実世界ではじっとしているか、前方に動くことが多いものです。後ろに移動することは少なく、水平方向に横移動(strafe)するということはほとんどありません。このため、動作することが必須である場合、正面方向へのユーザの移動がもっとも快適です。左右への水平の移動は、私たちが横に移動することが通常ないため、ユーザにとって視界からみる流れが不自然であるため問題となりがちです。

一般的には、人間の動作と同様の力学を模倣すべきです。人が現実世界で移動できる程度には限界があり、設計をする際にこのことを考慮すべきです。

階段(または急な坂)を上下に移動することも多くの人にとって不快となる場合があります。この感度はベクション(実際に移動することなく自己の動作を視覚的に認識すること)に関連していて、これはシミュレータ酔いの主要な要因となります。不慣れな垂直方向の加速の感覚に加えて、同じ方向に進んでいる際に階段の目立った端の部分が画面のディスプレイの大部分を占めるようになります。通常ユーザはこのような場面を見ることがなく、歩いているときにテクスチャ付の壁あるいは床を直接みるといったことは稀な状況です。開発する際に坂や階段の使用は控えめにすることを推奨します。同様に注意を払うべきなのは、ベクションを強く生じる他の映像であり、例えばエレベータシャフトを上に移動する際にユーザの周りの縞模様(ライトまたはテクスチャによる)が存在する場面です。

これのガイドラインが関連して影響を受ける場合があることを開発者として意識すべきです。例えば水平方向や後方への移動を操作方法から外すことは理論上は理想的におもえるかもしれませんが、そうすることで、同様の位置の変更をするためにユーザはより多くの動作をしないといけなくなります(すなわち、回転して前を向き、さらに回転する、など)。これによりユーザは視覚的な自己動作が可能となり結果的に、単に後方や左右にステップをするだけの場合と比べてベクションがより大きくなります。環境や体験を設計するときには、こういう課題により影響をあらかじめ最小化すべきです。

さらに複雑なアクションを単純化することで、ユーザが体験するベクションの程度を最小化するように考えるべきです。例えば障害物の操縦の自動化や効率化などです。ある調査では、プレイヤーはバーチャル障害物コースを操縦して、制御のスキームは次の二つのうちいずれか一つとすべきです:一つめは動作で3次元の自由度を提供する方法であり、二つめは6次元の自由度を提供する別の方法です。3次元の自由度を提供する制御スキームは、一見ユーザの選択肢を少なくする(さらに、それによってシミュレータ酔いを促進してしまう)ように最初は感じられるかもしれませんが、実際には無関係の視覚モーションを経験することを避けるため、シミュレータ酔いの頻度減少につながります。

異なるコンテンツの種類や状況を超えて推奨することが出来ない場面です。慎重な配慮やユーザテスト、そして反復的なデザインはユーザ体験や快適さを最適化するのに重要です。

9
Stanney, K.M. & Hash, P. (1998). Locus of user-initiated control in virtual environments: Influences on
cybersickness. Presence, 7(5), 447-459.

付録 F - トラッキング

  • 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 に近ければ近いほど良い、ということは疑う余地がありません。もしレイテンシが回避できないものである場合はせめて継続的に発生しないほうがより快適となります。この理由からレイテンシについては出来るかぎり最小化し、継続的でないものとすることを目指すべきです。

付録 G - シミュレータ酔い



  • 「シミューレーター酔い」はシミュレートされた環境の利用によって発生する不快感のことを指します
  • 視覚と体性感覚の相違が[酔いの]原因です
  • シミュレーター酔いの要因[とその解決法]の一部を以下に示します:
    • 加速: 加速度と加速の頻度を最小化してください
    • [ユーザーが]制御できる度合い: ユーザーから制御を奪わないでください
    • シミュレーター利用時間: ユーザーが休憩をとることを推奨してください
    • [眼の]高さ: 視野すべてを地面で覆うことを避けてください
    • 両眼視差: 人によっては立体視による映像が不快な場合があります
    • 視野角: 狭い視野角は不快感を低減するかもしれません
    • レイテンシ:レイテンシを最小化して下さい。ラグやフレーム落ちはVRにおいて不快な体験です
    • 歪み補正: Oculus VRの歪みシェーダーを利用してください
    • ちらつき: 明滅する画像を表示しないでください
    • 年齢: [ユーザーの]年齢とシミュレーター酔いとの関係は未だ不明です
    • 経験: VRを経験することでシミュレーター酔しにくくなります (これは開発者がテスターとして最悪であることを意味します)

解説

シミュレーター酔いは視覚により引き起こされる移動酔いで、日常的な移動酔いとは決定的に異なります。多くの人々が知っている移動酔いは実際の移動(ボートの揺れによる船酔いなど)により引き起こされますが、シミュレーター酔いの主な不快感はシミュレートされた環境の視覚情報がユーザーが実際には移動していないにも関わらず、移動の感覚を引き起こすことにより発生します。どちらの場合にも、視覚と前庭感覚の齟齬が存在します。さらにシミュレータ酔いは、眼精疲労などバーチャル環境の利用に特有の症状も含みます。一部のユーザーが短時間のヘッドセット利用で酔いを感じるのに対し、まったく酔いを感じないユーザーも存在します。

シミュレータ酔いはユーザーと開発者双方にとって大きな問題です。ユーザーが極めて体験したいと思う非常に魅力的なコンテンツであっても、シミュレーター酔いの不快感を耐えたいと思うことはありません。そのため、シミュレーター酔いの原因を理解し、低減するための対策を講じることは極めて重要です。しかし残念ながら、シミュレーター酔い(に限らずすべての移動酔い)の真の原因は研究の途上にあります。シミュレーター酔いと多くの要因の間には複雑な因果関係があり、ある要因により不快感を発生させることはあっても[あるいは容易でも]、不快感をなくすためには全ての要因に対処する必要があります。

シミュレーター酔いは多くの症状を示しますが、主な特徴は方向感覚の喪失(運動失調を含む)や、吐き気(自己移動の錯覚から生じると考えられている)、そして眼球運動の不快感(例: 眼球の過度な移動による眼精疲労)です。Simulator sickness questionnaire (SSQ)と呼ばれるアンケートの項目にもこれらは含まれており、バーチャル環境におけるユーザーの症候学的な研究に用いられています(11

シミュレータ酔いの要因

シミュレータ酔いが起きる原因を探しだすのは困難です。 違うユーザは違う体験をしますし、 症状が示されるのに数分から数時間の時間がかかります。  VR デザイナーとして、長い時間VRに浸り、仮想環境にさらされていると、脳は(VRの)効果に敏感でなくなっていきます(12。このため、VRに特化した開発者、ユーザは他のユーザよりも慣れていくものと予想します。この欠点は、コンテンツからユーザが不快感を経験するかどうかの判断において、VR初心者からコンテンツが不快感を生じるものかどうかフィードバックを得ないことは問題があります。

乗り物酔いの度合いは人により大きくバラツキがあり、シミュレータ酔いが起きやすい体験の強度に比例していきます。すなわち車両、遊具やその他の状況で乗り物酔いを起こしやすい人はOculus Riftを使用する際も慎重に使用すべきです(13 。このマニュアル全体にある注意事項に気をつけることも役に立つでしょう。

次のセクションはシミュレータ酔いの潜在的な要因とみなされる要素をリストアップしています。いくつかの要素は他のものよりも設計者が制御しにくいものですが、理解をすることで不快感を最小化することが出来ます。またここの情報の一部は他のセクションとも重複しますが、このセクションはシミュレータ酔いにおける役割についてより詳細な説明をしています。

動作の速度および加速

動作の速度はシミュレータ酔いになるまでの時間に比例しますが、必ずしもその度合いや増加度合いとは相関しません。より遅い動作(14 のほうが一般的により快適ですが、本当に気をつけるべきなのは加速であり、それは内耳の中の前庭器官が感じとる加速度です。前庭器官が感じないが視覚により感じられる加速度(直線であっても任意の角度方向へのものであっても)は感覚の間の矛盾を生じるため不快感につながることがあります。非公式な試験結果により、加速は長い時間かけて徐々に加速するより、瞬間的な加速ののほうが快適であることが示唆されています。不快感の増加度は加速の頻度、大きさ、時間の長さを変数とした関数です。
どのような加速であっても、加速している間は感覚の間で衝突が発生するため、できるかぎり避けることがベストです。(前庭器官は等速運動に反応しないため一定速度の動作は感覚の矛盾はより小さくなることに留意して下さい。)

ユーザによる自主的な制御

ユーザーからカメラの制御を奪ったり、ユーザーによって開始されていない方向にカメラを動かすと、シミュレータ酔いを引き起こすことがあります。いくつかの理論は、体感する動きを予期しコントロールする能力が乗り物酔いを防止する役割を果たすことを示唆しており、この原則はシミュレータ酔いにおいても同様であると思われます(15 。ゆえに、ユーザーの制御をはずれた予期しないカメラの動き(あるいは動きの停止)は不快感をもたらします。 アバターがカメラの動作を予見できるようにすることで、ユーザは視覚的な動作に対する準備ができるようになり、潜在的に体験の快適度を向上させます。

もしユーザーに見せる重要なイベント(カットシーンや重大な環境イベント)がある場合は、ユーザーの注視点を勝手に動かすことは避けて、代わりに、ユーザー自身が自分で注視点を動かすように促すサインを提供することを試みてください。たとえば、非プレイヤーキャラクター(NPC)に目標の方向を向かせたり、効果音によってイベントの合図をしたり、目標の近くにタスクに関係のあるターゲット(敵やアイテムのような)を配置することができます。

繰り返しますが、ユーザーの動きとカメラの動きを切り離さないでください。

時間

バーチャル環境により長く留まるほど、よりシミュレータ酔いをしやすくなります。ユーザーには常に、ゲームを中断し、都合の良いときにそのポイントに復帰する自由があるべきです。適切なタイミングでの休憩の提案、たとえばセーブポイントやアクションの休止は、そうしなければあなたのゲームに没頭してしまうかもしれないユーザーへの良い合図になります。

高度

ユーザーの高度、すなわちユーザーの視点の高さは、シミュレータ酔いにおける間接的な要因となり得ます。ユーザーの視点が低くなるほど、地平面の変化が高速になってユーザーの視界を占め、より激しい視覚の流れを引き起こします。これは不快感をもたらすことがあります。同じ理由で、階段を上ることも視野を覆う強烈な視覚の流れを引き起こし、不快なものとなります。

両眼視差

両眼視差はRiftの根幹のひとつであり、奥行き感を引き出すものですが、代償がないわけではありません。Appendix Cで述べたように、立体視イメージは、左右の目に一つの場所へ視点を集めることを強いる一方で、レンズはもう片方に視点を集めるように調整しています(あるいはそれ自身にフォーカスしています)。VRの中でデプスの最大幅を活用することは必須ですが、ユーザが0.75から3.5のUnity単位(メートル)の中で、拡張された期間(メニューや第三者視点のアバター)にフォーカスすることも重要です。

一部の人々は立体視の画像を見ることに不快感を覚え、さらに研究結果により映像の間の視差の度合を減らしてモノスコピック 17) (すなわちICDがゼロ)、あるいはマイクロステレオスコピック18)  (すなわちICDが小さい)である表示により体験をより快適に出来ます。Oculus RiftではIPDのスケールが頭部モデル全体に適用されることが重要です。

他でも言及されているように、Oculus RiftでのICDをコンフィグツールからユーザのIPDへとセットして実際のデプスおよびスケールが実現できます。目の間の距離(カメラの距離)に適用されるスケールは頭部モデル全体に必ず適用して頭部の動作がバーチャルのレンダリングカメラの適切な動作と連動させるべきです。

視野角

視野角には2種類あります。ディスプレイに対する視野角の面積(このガイドでディスプレイFOVまたはdFOVと呼ぶ)とグラフィックエンジンがディスプレイに描画する仮想環境の面積(カメラFOVまたはcFOVと呼ぶ)。

広いディスプレイFOVは動きの知覚に関する2つの理由により、シミュレータ酔いを引き起こすと見られる。まず、動きの知覚は周辺でより敏感であり、特に周辺領域の光の移動と微妙なフリッカーの両方から影響を受けやすい。次に、広いディスプレイFOVは、その全体が使用されると、狭いディスプレイFOVに比べてより多くの入力を視覚系に与える。そのような多くの入力はユーザーに動いている間隔を与え、身体(平衡感覚と固有受容)の感覚と矛盾し始め、不快にさせる。

ディスプレイFOVを減らすことで、シミュレータ酔いを軽減できるが、Riftの没入感と状況認識も軽減させる。(19 より妥協を好む敏感なユーザーに対応するには、表示視野角の調整機能を提供するべきです。

カメラFOVを調整した場合、頭の動きに対するバーチャル環境の不自然な動きにつながる場合があります(たとえば、もし10度の頭の回転が、現実においては通常15度の回転が必要なバーチャル世界の回転をもたらした場合)。不快な体験となることに加えて、前庭動眼反射と呼ばれる一時的ながら不適応な状態をもたらします。20) あなたの目と前庭器官は、通常、物体を注視し続けるために、頭を動かす間にどれほど目を動かすべきかを定めるため協調して働きます。 もしバーチャル環境がこの反射運動に注視の維持を失敗させるようであれば、Riftの使用中および使用後に不快な再調整プロセスが引き起こされるでしょう。

レイテンシおよびラグ

開発者はシステムの遅延の多くの部分についてコントロールすることができませんが(例えばディスプレイの更新頻度やハードウェア遅延のように)、あなたのVR体験が、最小要求スペックを満たすシステムにおいて必ずラグやフレーム落ちをしないようにすることは重要です。多くのゲームは、たくさんの、あるいは複雑な要素を処理しレンダリングするとスローダウンを引き起こします。これは伝統的なビデオゲームにおいてはささいな苛立ちですが、VRのユーザーには強烈な不快感として影響することがあります。

レイテンシの影響に関する過去の研究の知見はさまざまです。多くの専門家は、シミュレータ酔いを低減するために遅延を最小限にすることを推奨しています。なぜなら、頭の動きと対応するディスプレイの更新の間のラグは、前庭動眼反射における感覚の衝突とエラーを引き起こすからです。このためレイテンシを出来るかぎり最小化することを推奨します。

特筆すべきは、ヘッドマウントディスプレイに関するいくつかの研究が、48ミリ秒のように短いか300ミリ秒のように長いかに関わらず、ひとつの固定時間のレイテンシが同じ度合いのシミュレータ酔いを生むことを示唆していることです。21) しかし、コクピットやドライビングシミュレータにおける変動し予期できないレイテンシはより不快感を生みます。22)  これは、人間は予測可能な、または一貫性のある少しの遅れは慣れるが、変動したり、予測不可能なラグは平均的に不快感を増すことを示しています。

それでも、レイテンシ(および現実世界とVRの差異)に合わせることで、Oculus Riftを外して現実世界に戻ったときに更なに不快感を感じるプロセスになりえます。

その経験は、クルーズ船の乗り降りするときに似ています(訳注:そんなの知らないよ)。一定期間ボートのゆれによる船酔いを経験した後は、一般的に多くの人は、ゆれに慣れて、船酔いはおさまります。しかし、地上に戻ったときに、多くの人は新しい環境に再度慣れるために、船を下りるときの病に近い症状を経験します。23)  
仮想世界に出入りするときのそういった体の調整を少なくすることが良い方法です。モーションから映像へのレイテンシーを計測し、可能な限り短く一貫性を持たせるために、開発者はDK2の付属のレイテンシーテスターを使用することをお勧めいたします。より詳細なドキュメントはSDKをご参照ください。

歪み補正

Riftのレンズはディスプレイに表示される画像を歪めますが、これはSDKが提供するポストプロセスのステップによって補正されます。この補正がSDKのガイドラインと提供されているサンプルデモに従って正しく行われていることは極めて重要です。私たちの目は不適切な歪みをかけてもかなり正しく見えますが、それでもなお方向感覚の喪失と不快感を覚えます。ですので、仔細に注意を払うことは最重要です。すべての歪み補正の数値は物理デバイスと一致する必要があります。それらはユーザーが調整できないようにしてください(SDKのデモは、特に意味があってのことではなく、ただシーンの裏で何が起きているか示すために数値を操作できるようになっています)。

私たちは補正の設定をRiftの光学系にあわせて注意深く調整しており、補正の調整をさらに向上させるために継続的に作業しています。すべての開発者はRiftにコンテンツを正しく表示するためにオフィシャルのOculus VRの補正設定を使用するよう求められます。

ちらつき

ちらつきはシミュレータ酔いにおける眼球運動の重大な役割を担っています。これは高い輝度レベルによって悪化し、あなたの周辺視野において最も強く認識されます。ちらつきは時間とともに意識的には認識されなくなりますが、それはなお頭痛と目の疲れを及ぼします。

それらはバーチャル環境に多くの利点をもたらしますが、有機ELディスプレイは、CRTディスプレイと同等のある程度のフリッカー(ちらつき)をもたらします。人それぞれで感度は違いますが、DK2の75Hzのディスプレイパネルは、大多数の人がほとんどのちらつきを感じないくらい十分に高速なものです。今後の改善で、より高いリフレッシュレートとなり、よりちらつきをかんじにくくなります。これは開発者としてのあなたの手からいくぶん離れることですが、完全を期してここに含めました。

あなたの責任は意図的にちらつくコンテンツを制作することを控えることです。高いコントラスト、点滅(あるいは高速な変化)、とりわけ1~30Hzの範囲での刺激はてんかんを持っている人々に発作を引き起こし得ます。規則的なパターンが多いテクスチャ(白黒の縞模様など)は癲癇を持つ人々の発作の原因となります。

経験による慣れ

バーチャル環境に慣れ親しむに従って、シミュレータ酔いをしにくくなります。24) これまでの理論で学んできたとおり、典型的にはVRによる新たな体験をユーザが無意識に受け入れやすくなるメカニズムです。例えば、脳は不快感を生じた視覚的な異常でも、解釈を再度試みるので、ユーザの動作はより安定して効果的となるのでベクションが下がります。良い面としては、開発者はヘビーユーザ向けに強力に視覚的な体験を設計することに対して遠慮すべきではない、ということです。逆に悪い面としては、大多数のユーザはOculus RiftおよびVRゲームに順応して体験を受け入れるするのに時間がかかるということです。

これにはいくつかの悪影響があります。ひとつめは、自ら開発したゲームを繰り返しテストしたい開発者は新しいユーザと比べてシミュレータ酔いに耐性が出来るため、体験をシミュレータ酔いのしやすさの異なるグループの人々に対して体験が快適であるかテストする必要があるのです。ふたつめは、初心者ユーザはいきなり強烈なゲーム体験をすべきではなく、最初はより穏やかでスローペースな作用から始めてゲームに入りこむクッションとすべきです。さらに良い方法としては、このガイドにある推奨事項を実装して、体験の強度を調節できるようにユーザ自身が制御できるようにすべきです。三つめは、強烈なゲーム体験を含むゲームはユーザにゲームコンテンツに対する警告を発することで、もっとも心の準備が出来ているときにアプローチしてもらえるようにすべきです。

シミュレータ酔い対策

プレイヤー固定の背景(別名、個別の視覚的背景)


シミュレータ酔いの研究論文によりVRコンテンツで実装できるシミュレータ酔いを減少させる視覚的な手法が少なくともひとつ確立されています。実験により人々は個別の視覚的背景があったりなかったりするバーチャル環境に置かれます。25) これにより簡単な背景、例えばグリッドやスカイボックスのようにシミュレータの主要なコンテンツがユーザの現実世界の安定的な性質と合致して構成されました。例えば、ドライブシミュレータにより地平面、樹木、およびビルを通過することで動作を示すかもしれません。しかし、スカイボックスでは幾つかの雲が車が曲がってもユーザの前で固定されます。26) 個別の視覚的背景を持つバーチャル環境を使用することで、一般的な背景と比較してシミューレータ酔いを著しく減少させることが分かってきました。

これにより通常は不快感につながる感覚の矛盾に抗う形で、ユーザが視界と前庭感覚が整合性を保つように脳の解釈が促進されます。ユーザは背景の環境と固定されていますが、前掲がユーザの周りを移動しています。

われわれ特有の実装ではプレイヤー固定のスカイボックスがあり、プレイヤーが操作するメイン環境より遠くでレンダリングされます。予備実験の結果から多くの背景のタイプでこれは有効であり、現実的なもの(海、地平線、雲空)から人工的なものまで(黒グリッド付きの箱)まで有効です。プレイヤーがコントローラまたはキーボードにより移動または回転を前景で始めるやいなや、遠くの背景がプレイヤーの体の位置に対して固定されていることに気づきます。しかし、背景を頭部の動作により見回すことが出来ます。総合的な効果としてはプレイヤーは背景により構成された巨大な「部屋」にいる気持ちとなり、主要な前掲が周りをうごいているように感じます。

この手法はいくつかのテクノロジーにおいてシミュレータ酔いを減少させるのに有効であることが分かっており、Oculus Riftも例外ではありません。しかし、この手法に制限がないわけではありません。
シミュレータ酔い削減効果は、2つの要素を条件とします。上記で述べた背景の可視性と、プレーヤ前面の環境よりもより遠くに知覚される度合いです。全ての仮想環境が外側にあるわけではありませんが、そうでない場合、プレーヤ固定の背景は容易に見えるようになり、直感的にも何かがわかるようになります。これらの現実的な制約事項により全てのバーチャル環境へとグリッド付きの部屋のパターンを透明のオーバーレイとして適用し、その際は両眼視差と空気遠近法(例えばフォグ)でグリッドが遥か遠くに離れていることをデプスキューとして使用します。全般的には有効だったのですが、潜在的にユーザによる没入感を損なうかもしれません。さらにプレイヤーがグリッドを目と前景の環境の間にある(グリッドを不透明にする、等)というキューがあると、すべてを台無しにしてしまうことが分かりました。

それでも、正しく使用すればこの手法により開発者はプレイヤーに対してより幅広い体験を快適な体験を大きく損なわずに提供できるようになります。さらにユーザがバーチャル環境に慣れやすくなります。プレイヤーは初めてコンテンツに遭遇するときに固定された背景を有効にして、無効にするか効果を時間とともに減衰させる選択肢を提供できます。もっとも切迫感のあるVR体験であっても快適に楽しむことgあできない場合は無駄です。プレイヤーに固定された背景によりユーザの裾野を広げて、この工夫をしなければコンテンツが使用できないような敏感なユーザにも受け入れてもらえます。もし独立した視覚的背景がコンテンツで効果的に実装できる場合はプレイヤーが変更できる選択肢として含めると良いです。

新たなアプローチ


開発者は従来のゲーム体験がコンピュータ画面に映されるかのごとくVRを快適にするための手法を模索し始めています。次に紹介するのは、これまでに見てきたいくつかの手法です。あなた自身のコンテンツに適合しない場合もあるものの考慮できるように紹介します。

移動はベクション、そして結果的に不快な体験につながるため、一部の開発者はプレイヤーを空間上で異なる位置を移動するためにテレポートをするために幾つかの手法を実験してきました。この手法によりシミュレータ酔いを減少させるのに有効かもしれませんが、それでもユーザは方向感覚を失って混乱するかもしれません。27)  

ユーザが体験するベクションの度合を減少させるため、カメラを操作する亜種の試みも登場しています。「テレポート」モデルの代替策としてユーザを一人称ビューから、ユーザをアバターとして表示する「神様」ビューへと切り替えます。プレイヤーは新規の位置へとアバターを移動させて、新しい視点から再び一人称ビューへと戻します。

さらに別のアプローチにおいて、ユーザがバーチャル環境で曲がる方法を変更しています。スムーズに回転する代わりに、コントローラの左か右を押すことにより意図した方向にカメラが固定角度(例えば30度)にジャンプします。ポイントはユーザが回転においてさらされるベクションの度合の最小化であり、混乱を避けるために普通で予測可能な動作を作り出すことです。

このセクションで述べてきたすべての手法は不快な体験を減らすために、バーチャル環境における真実に近い、「現実的な」体験を犠牲にしています。これら手法のいずれかを実装するかはあなた自身の判断ですが、より多くのユーザにとって快適なコンテンツがより多く提供される価値はあるかもしれません。現実的であることを最大化するか、快適な体験であることを最大化するか、それらの妥協点としてはユーザが設定できるオンまたはオフのオプションとして提供することです。不快感を感じにくいユーザはより真実に近い体験を選択できますし、敏感なユーザはコンテンツを楽しめるようにオプションを有効にできるでしょう。

測定方法およびテスト手法


シミュレータ酔いの測定と評価には幅広い手法が用いられてきました。技術的な側面から、電気皮膚反応、脳波図、胃筋電図、および姿勢の安定性といった間接的な測定も行われてきました。研究論文のなかでもっとも頻繁に使用されている手法はシンプルなサーベイにあたるシミュレータ酔い質問票(SSQ)です。

他の質問票と同様に、シミュレータ酔い質問票には、回答者の自己診断による自身の考えや身体に対する見解を取り巻く有効性に内在する制約があります。しかしシミュレータ酔い質問票には数々の利点もあります。間接的な生理学的手法と異なり、シミュレータ酔い質問票は特殊器具やトレーニングを必要としません。鉛筆、紙とわずかな計算で事足ります。誰もが質問票の実施や点数計算、過去データに基づいた解釈を行うことが出来るのです。回答者にとって質問票は短く簡単であり、再生テスト数分間で完了します。、シミュレータ酔い質問票はテスターにとって僅かなコストで多くの情報が得られるものであり、再生テストでの快適さを評価するにあたりひとつの潜在的な選択肢のひとつです。

11
Kennedy, R. S., Lane, N. E., Berbaum, K. S., & Lilienthal, M. G. (1993). Simulator sickness questionnaire: An enhanced method for quantifying simulator sickness. The International Journal of Aviation Psychology, 3(3), 203-220.
12
Kennedy, R., Stanney, K., & Dunlap, W. (2000).  Duration and exposure to virtual environments: Sickness curves during and across sessions.  Presence, 9(5), 463-472.
13
Stanney, K. M., Hale, K. S., Nahmens, I., & Kennedy, R. S. (2003). What to expect from immersive virtual environment exposure: influences of gender, body mass index, and past experience. Human factors, 45(3), 504–20.
14
So, R.H.Y., Lo, W.T., & Ho, A.T.K. (2001).  Effects of navigation speed on motion sickness caused by an immersive virtual environment.  Human Factors, 43(3), 452-461.
15
Rolnick, a, & Lubow, R. E. (1991). Why is the driver rarely motion sick? The role of controllability in motion sickness. Ergonomics, 34(7), 867–79.
16
Lin, J. J., Abi-Rached, H., & Lahav, M. (2004, April). Virtual guiding avatar: An effective procedure to reduce simulator sickness in virtual environments. InProceedings of the SIGCHI conference on Human factors in computing systems (pp. 719-726). ACM.
17
Ehrlich, J.A. & Singer, M.J. (1996). Simulator sickness in stereoscopic vs. monoscopic helmet mounted displays. In: Proceedings of the Human Factors and Ergonomics Society 40th Annual Meeting.
18
Siegel, M., & Nagata, S. (2000). Just Enough Reality: Comfortable 3-D Viewing. IEEE Transactions on Circuits and Systems for Video Technology, 10(3), 387–396.
19
Draper, M.H., Viire, E.S., Furness, T.A., & Gawron, V.J. (2001). Effects of image scale and system time delay on simulator sickness within head-coupled virtual environments. Human Factors, 43 (1), 129-146.
20
Stoffregen, T.A., Draper, M.H., Kennedy, R.S., & Compton, D. (2002). Vestibular adaptation and aftereffects. In Stanney, K.M. (ed.), Handbook of virtual environments: Design, implementation, and applications (pp.773-790). Mahwah, New Jersey: Lawrence Erlbaum Associates, Publishers.
21
Draper, M.H., Viire, E.S., Furness, T.A., Gawron, V.J. (2001).  Effects of image scale and system time delay on simulator sickness with head-coupled virtual environments.  Human Factors, 43(1), 129-146.
22
Kolasinski, E.M. (1995).  Simulator sickness in virtual environments (ARTI-TR-1027).  Alexandria, VA: Army Research Institute for the Behavioral and Social Sciences.  Retrieved from http://www.dtic.mil/cgi- bin/GetTRDoc?AD=ADA295861
23
Reason, J.T. & Brand, J.J. (1975).  Motion Sickness.  Academic Press, Inc.
24
Welch, R.B. (2002). Adapting to virtual environments. In Stanney, K.M. (ed.). Handbook of Virtual Environments: Design, Implementation, and Application. Lawrence Erlbaum Associates, Publishers: Mahwah, NJ.
25
Prothero, J.D., Draper, M.H., Furness, T.A., Parker, D.E., & Wells, M.J. (1999). The use of an independent visual background to reduce simulator side-effects. Aviation, Space, and Environmental Medicine, 70(3), 135-187.
26
Lin, J. J.-W., Abi-Rached, H., Kim, D.-H., Parker, D.E., and Furness, T.A. (2002).  A “natural” independent visual background reduced simulator sickness.  Proceedings of the Human Factors and Ergonomics Society Annual Meeting, 46, 2124-2128

付録 H - ユーザインタフェース


  • ヘッドアップ ディスプレイ (HUD)
    • HUDを使わずに情報を3D環境の一部に統合してしまうのが理想的です
    • 照準はターゲットに直接描画する。一定距離離れたところに固定して描画しない
    • あらかじめHUDを環境の中に統合してしまうのは理想的です
    • 近い位置にある武器およびツールは眼精疲労につながります。アバターの一部にして使用しないときは隠しましょう
  • アバターには長所と短所があります。バーチャル世界にユーザを引き込む一方で、現実世界での体の動きとの差異が出るほど違和感を生じます。

ヘッドアップディスプレイ (HUD)

一般論として、Oculusで伝統的なHUDを使用することは推奨しません。その代りに開発者が環境そのものに情報を埋め込むことを推奨します。特定の伝統的な手法は立体視の要求をよく考慮した再設計を行えば機能するものの(照準について後に言及する例を参照のこと)、非VRのゲームからHUDを単純に移行することは新たな問題が生じて、現実的でなかったり、場合によっては不快にさえなったりします。

はじめに、HUDは3Dシーンの中の全てに対してオクルージョン(前に配置される)します。これは非立体視のゲームで問題になりません。それはユーザがHUDが実際に全ての前にあるものとして捉えるためです。残念ながら両眼視差(各々の目に投影される映像のわずかな差)をデプスキューとして加えることでシーンの要素がHUDよりもユーザ視点に近い位置に来ることで矛盾が生じることがあります。オクルージョンにもとづいてHUDはシーン要素よりも近いものとして認識され後ろにあるオブジェクトを隠しますが、それでも両眼視差によりHUDがオクルージョンをしているシーン要素より遠いと示されます。これはHUDあるいは環境全体の各々の目の映像を統合しようとすることを困難にしたり、さらには場合により不快感を生じさせるかもしれません。

HUDをユーザに極めて近い位置におくことによりオクルージョンと格差が解決される場合がありますが、別に推奨している最低限で75cmの距離に配置することが快適ということと矛盾します。 プレイヤーのクリッピング領域をHUDの深度にすることでも問題が生じることがあり、ユーザは環境上のオブジェクトが人工的に遠く感じるためです。特定の状況下ではこれらの問題が回避できて機能するかもしれませんが、HUDはVRにおいて洗練されてない過去の遺物とすぐさま感じるかもしれず、一般論としては別の方法で置き換えて廃止していくべきものであり、よりユーザフレンドリーな選択肢を優先すべきです。


図3: ヘルメット バイザーの中に表示された、かなりビジーなHUDの例

代わりに、立体視のあるシーンにHUDを統合する方法を検討してください。伝統的なゲームでは機能しなかった方法であっても、ユーザの頭の動作により自然で直観的な方法として情報を閲覧できるかもしれないことを覚えておくべきです。例えばHUD上のミニマップやコンパスの代わりに、プレイヤーはアバターの手やコクピットの中にある実際のマップやコンパスに目を落とせば目的が達成できるかもしれません。これはリアリティが必要ということで意味ではなく、敵のHPは頭の上を魔法のように浮かび上がるといった方法もあるでしょう。大事なことは情報を明確で快適な方法により提示して、プレイヤーが環境に関する情報を閲覧する際に、明確で統一されたイメージを持てるようにして阻害要因を作らないことです。

同様に照準合わせも立体視VRにおいて新たなチャレンジとなります。照準の十字線そのものはシーンのオブジェクト上に直接描画すべきであり、これにより照準合わせの際、ユーザが何かに眼を合わせたときに焦点を当てるようにすべきです。もし十字線が視線が調節および輻輳されているのと別な奥行きに描画された場合、ぼやけてにじむように見えてしまいます。  照準を伝統的なゲームと同様の方法で機能するためには、画面上でターゲットとするオブジェクトに直接描画する必要があり、望ましいのはユーザが狙いを定める際に焦点を合わせている位置とすることです。

十字線そのものは固定の大きさだったとして距離により大きかったり小さかったり出来ますし、ユーザからみたときに一定の大きさとすることも出来ますし、これはデザイナーにとっての美学による判断になります。  結論としていえることは、いくつかのパラダイムをVRに移行することは可能であるものの、新しいメディアの要求事項に合わせて注意深く修正して設計することが必要不可欠だということです。


アバター


アバターとはバーチャル世界におけるユーザの身体の視覚的な表現です。典型的にはユーザの位置、動作、およびジェスチャーに反応します。ユーザは自身のバーチャルな身体を見ることが出来て他のユーザがどのように見えるか、またどう作用するかを観察できます。VRは一人称視点での体験が多いため、多くのVRアプリケーションはユーザの表現のほとんどを排除することとなり、結果的にユーザはバーチャル空間上で身体がない状態になります。


図4: 画面の下に映っているユーザのアバター

アバターには長所と短所があります。アバターによりユーザはバーチャル世界における縮尺や体の大きさを強く認識できます。逆にアバターを現実的に提示することによって、ユーザの固有受容感覚(例.ずっと座っているのにゲームでは歩行する)と矛盾することは奇妙に感じます。Oculus Riftの公開デモにおいて、一般的にユーザは自身のバーチャルな身体をみることができることに対して肯定する反応が多く、美的な感情を引き出す手段としては成立します。まだ新しいメディアとして、体験のためにどういう方法がベストであるかのテストや評価が必要です。

首はある一定のところまでしか曲げることが出来ないためアバターの身体は画像のかなり端の方にしか映りません(図4)。全ての武器やツールはアバターに統合し、ユーザが手に持っていることを確認できるようにすべきです。開発者がボディ トラッキングで入力デバイスを使用した場合ユーザの手や他の身体の部分をトラッキングしたうえでアバターを更新して、その際のレイテンシを出来る限り小さくすべきです。

武器や道具

FPSでは武器は画面の下の方に表示され、あたかもユーザが持っていて照準合わせをしているようにしています。位置関係からいうと、武器はシーン上の何よりも視点に近いことになります。典型的な非立体視のゲームにおいて、それは何ら問題がなく通常の距離にて間近のオブジェクトがシーン上に重ねあわせて表示されることは受け入れられます。

しかし、これを立体視の実装とした場合、状況はもっと複雑になります。武器やツールのレンダリングをカメラの間近にすることで、武器とシーンの残り全体をみるうえでユーザは眼の輻輳を大きく変化させる必要があります。さらに武器が視点にあまりに近いために左右のビューが著しく異なるかもしれず、結果的にひとつの三次元ビューに統合することが難しくなるかもしれません。

もっとも快適だとわれわれが考えるアプローチは、すでに述べたようにカメラを頭はないが身体は完全にあるアバターの首の直ぐ上に配置することです。武器およびツールはユーザ アバターの一部としてレンダリングされます。武器を使用するときは持ち上げられますが、通常はビューに表示しません。

この他にも「チート」して武器およびツールをプレイヤーのビュー上でレンダリングする方法はありますが、特にそれを推薦しているわけではありません。ただ、もしかするとコンテンツによってはこの種のバリエーションが必要であったり、状況に合うような場合はあるかもしれません。ひとつの方法は2Dで武器をレンダリング、そのうえもしHUDがある場合はその奥に描画することです。すでに見てきた輻輳や映像の統合の問題と、武器を平らで不自然に見えることを天秤にかけて考える必要があります。

もうひとつの方法はマルチ リギングを用いることで、間近にあるオブジェクト(例としてコクピット、ヘルメット、銃)が主要な環境から切り離して独立した別のカメラを用いることです。この手法は視覚的な不具合、例えば手前にあるオブジェクトが奥にあるオブジェクトよりも立体的に遠くに見えてしまうなどのリスクが発生します。

繰り返しの実験およびユーザテストにより、これら以外の方法を使ったコンテンツにとっての最適な解決策が判明するかもしれませんが、現時点でのわれわれの推奨は武器およびツールをユーザアバターのコンポーネントとして実装することです。

付録 I - ユーザ入力とナビゲーション


  • 従来の入力方法でVRにとって理想的なものはありませんが、ゲームパッドが現状では最善の選択です。ここはイノベーションと研究が必要とされる分野です(Oculusでも行っています)。
  • ユーザーはRift装着中に入力デバイスを見ることはできません。見ることなく操作できる、慣れたコントローラーを使用させてあげてください。
  • Riftのセンサーを入力に活用してください(例: 頭を傾けて照準合わせをするなど)、しかし頭の動作とアバターの頭の動作との関係によって生じることのある不快感に注意してください。
  • 移動はVRならではの新たな問題を作り出します。
  • 切り替え可能な「戦車モード」の提供を考慮してください。正面方向を今向いている方向にリセットする手段を提供してください。

マウス・キーボード・ゲームパッド

ユーザーがOculus Riftを装着すると、外界に対して実質的に盲目になるということを把握しておくことは重要です。ユーザーはキーボード、マウス、ゲームパッド、モニターのいずれも見ることができません。一旦VRの中に入ると、これらのデバイスの操作は触覚だけを頼りに行うことになります。もちろん、これはそれほど珍しい状況ではありません。しかし、入力デバイスを触覚だけで操作することに慣れているとはいえ、手を最初に置くときや、位置を直すときには視覚を使うものです(キーボード上で手の位置を変えるときなど)。これはインタラクションデザインにおいて、重要な帰結をもたらします。例えば、ユーザーはキーの位置やホームポジションを触覚だけで探す必要があるため、キーボード入力は面倒なものになるでしょう。マウスは多少は使いやすいとはいえ、ユーザーがヘッドセットを装着する前にマウスの位置を覚えておく必要があります。

究極的な解とはいえないものの、ゲームパッドは現状もっとも評価されている入力手段です。ユーザーは両手でゲームパッドを握ることができ、デスク上の複雑なデバイスを使う上での人間工学的な配慮とは無縁です。ゲームパッドがシンプルであればあるほど、視覚的な頼り無しに利用することは快適となるでしょう。

VRとRiftの制約を考慮すると、ゲームパッドはキーボードやマウスに比べて好ましいと言えるでしょう。しかし、いずれの入力手段もVRにとって理想的ではなく、Oculus VRでは幅広いVRコンテンツに使用可能な革新的で直感的なインターフェースを研究中です。

新たな入力手段

マウスやコントローラーで照準合わをする代わりに、いくつかのVRゲームでは頭の向きと連動したカメラで狙うことができます。例えば、ユーザーが向いている方向の中心に追従する照準やカーソルで照準合わせをするなどの例があります。  内部では、この手法をRaycastingと呼んでいます。Oculusでのユーザテストの結果からRaycastは直観的でユーザフレンドリーな相互作用の手法となりえます。このために必要なことはユーザがターゲットを選択するためのカーソルを明瞭にして(ターゲット先のオブジェクトの深度でレンダリング)、見ている方向により生じる効果を適切に視覚的フィードバックを返すことです。例えば、もしメニューからアイテムを選択するのにこの手法をした場合、ターゲットの照準またはカーソルが合わさったときに視覚的に目立った方法で反応すべきです(例.アニメーションやハイライト)。さらに頭部の動作によるターゲットをする場合は精度に制限があることを意識して下さい。メニューの場合では、メニューアイテムは大きくしてユーザが正確にターゲットできるように十分な領域を確保すべきです。さらに、ユーザはターゲットを変更する意思がない場合も頭を動かす場合があり、例えばRaycastによる操作のメニュー外で周辺にツールチップなどヒント表示がなされる場合です。Raycastがあなたのコンテンツに合うか判断するには最終的にユーザテストが必要となります。

Riftのセンサーは向きと加速度(それに加えて将来的には位置)の情報は主に仮想カメラの向きと位置を合わせるために使われていますが、これらの測定値は独創的な入力手段に使うこともできます。たとえば注視や頭部・胴体による移動などがあり、具体的には、ユーザーが移動したい方向を向いて前傾姿勢を取るとその方向に動くなどです。  いくつかのコンテンツでは制御する手法が実装されているものの、伝統的な入力手法と比較した場合の快適さやユーザビリティはまだ不明のままです。

結論として、開発者は新たな入力手段を用いたコンテンツを公開する前に重点的なユーザーテストを行ってください。 例えば、頭を傾ける動作は理論上は合理的な制御の手法ですが、仮想的な回転中に頭の回転軸が身体の回転軸からずれることで「擬似コリオリ効果」が発生し、移動酔いが発生することが被験者実験の結果として報告されています(25 このように意図しない効果は知らないうちに新しい入力手段に内在しているかもしれず、ユーザテストの必要性を浮き彫りにしています。

ナビゲーション

VR内で移動するとき、ほとんどのユーザーは実際に立って歩くのではなく、何らかの入力によって移動するでしょう。よくあるのは、今時のFPSゲームのゲームパッド・キーボード・マウスなどによる入力手段をそのまま使うことです。残念なことに、このような従来型の移動方法は、スクリーンのある環境では効果的であるものの、没入感の高いVRでは不快感を生じる場合があります。前述したように、サイドステップや後ろ歩きなどによるシミュレーター酔いは、コンソールやPCゲームでは発生しないのですが、VRでは発生するのです。OculusではVR内での新しいナビゲーション手法を開発中です。

移動中のユーザーの快適性を向上させるため、新たな移動方法を検討されています。従来では、「前進」ボタンを押すと通常はカメラが向いている方向に進みます。しかし、移動は従来の入力デバイスで行い、向きの変更は頭で行う「戦車モード」や「戦車ビュー」を使うナビゲーションを使用しても良いかもしれません。例えば、ユーザーが「前進」だけを押し続けている間は直線状に進み、頭を向けることで進行方向を変えずに周囲を見渡すことができる方法もあります。店の中で棚と棚の間を歩いているときに、脚では通路く真っ直ぐに歩いているものの、それとは独立して、頭は横から横へと見回しているという状況と比べてみてください。

この新しい移動方法には利点もありますが欠点もあります。Oculus社の従業員の数名(とおそらくこの手法を実装した開発者)はこの手法は従来のナビゲーション方法より快適と感じたようです。しかし、不快感やユーザー体験におけるあらたな問題も発生します。特に、ユーザーが向いている方向に進みたいのに、椅子ごと身体と頭が回転してしまったせいで、違う方向に進んでしまう場合などです。そのため、この手法を用いる開発者は常に、ユーザーがアナログスティックの押し込みやボタンなどで簡単に「戦車」の向きをリセットできるようにしておくべきです。

様々な使用例における「戦車モード」の快適性と有効性が完全に解明されるにはさらなる研究が必要ですが、開発者は従来型の移動方法の他に、ユーザーが選択可能なオプションとしてこのような手法を取り入れることは十分考えられます。

現状、開発者がこのガイドで述べられているような問題について考慮した上でなら、従来型の移動方法が無難で多くのユーザーにとって利用しやすい手法と言えます。

コンテンツによっては、仮想空間内でユーザーを移動させる新しい方法も使用可能です。たとえば、ユーザーが新たなステージに進むたびに、異なる位置から始まるなどです。いくつかのゲームでは、暗闇にフェードアウトする表現が睡眠状態や意識の喪失を表すのに使われていて、ストーリーの進行に沿って別の時点で目覚めさせられます。これらの慣習は特に問題なくVRでも用いることができます。しかし、ユーザーを仮想空間で移動させる(ユーザーを30°右に回転させ、マップの別の位置に移すなど)のは戸惑いを与えるでしょうし、移動時にカメラの制御をユーザーから奪ってしまうと、それは不快なものとなるでしょう。

28
Dichgans, J. & Brandt, T. (1973). Optokinetic motion sickness and pseudo-coriolis effects induced by moving visual stimuli. Acta Oto-laryngologica, 76, 339-348.

付録J - コンテンツ作成



  • ユーザはいつでも、どの方向でもみられるようにすべきです。それにより没入感が維持されることに留意してください
  • ディテールにこだわったアートのアセットを作成すると、ピクセル密度による制約があることに注意して下さい。
  • ローポリゴンでの「チート」(例えばバンプマップや平面オブジェクト)はステレオ3D、特に視点から間近の場合は明らかにチートであることを見抜かれます。
  • 音声は没入感にとって決定的に重要です。音風景は慎重に設計を行いユーザが使用する出力デバイスを考慮に入れて下さい
  • Oculusのツールはメートル単位で動作します。Unity上での1単位は1メートルとして扱って下さい
  • 理想的な体験のために、Oculus調整ツールのSettingsを使用してバーチャル環境におけるユーザの大きさを設定して下さい(任意)


新たな需要

バーチャル世界の設計は要求の多いものです。デザイナーはユーザがどこをみるか直接制御することがより少ないものです。ユーザはいつでも、どの方向でも見回すことが出来るためです。すでに述べたように頭の動作に対するカメラの反応を制限することはVRにおいて非常に不快感を生じさせるかもしれません。物語の都合または技術的な目的でカメラの動作範囲を制限することは不可能です。任意のタイミングで見回すことでユーザの没入感を損なわないように注意して下さい。例えば環境におけるレンダリング上のチートを見抜かれる、といった場合です。ユーザの周囲のバーチャル世界は常に完全かつ継続的であるべきです。

出来るかぎり多くの動的システム、すなわち物理挙動、ライティング、天候、および崩壊を取り入れて下さい。立体視の効果は比較的近いオブジェクトでベストだということを理解して下さい。遠くに離れるほど、効果は平坦化されます。

アート アセット

将来のOculusRiftは解像度が改良されるでしょうが、ピクセル密度がOculusRiftに合うようになるまでに、まだ時間がかかります。今のOculusRiftは解像度が限られていますが、あなたがこの制限事項を気に留めている限り、完全な没入感を作りだすことができます。オブジェクトの大きさが単列のピクセルサイズに近づくほど、細かいレンダリングが問題になっていきます。オブジェクトがまばらに表示されるほど、OculusRiftで見たときの明瞭さは悪くなります。テキストの文字や、小さくまばらなオブジェクトはピクセル間に埋もれてしまう傾向があります。同様に、フェンスやパターンのようにまばらかつ繰り返される場合、オブジェクトの表示に問題が生じます。

あなたの世界を作るとき、デザインプロセスに沿って作られた全てのステージにおいて、OculusRift上の視界を確認してください。極端に小さなオブジェクトの配置は避けてください。可能であれば、まばらなオブジェクト表示も避けてください。 これらの提言は、テクスチャを配置する場合にも同様に当てはまります。

ゲームのようなリアルタイム3Dアプリケーションのほとんどは、許容できるフレームレートで複雑なシーンを表示しています。シーン表示を効果的に表現できるエフェクトによっては、明らかに偽の立体視3Dに見えてしまうものもあります。ビルボードスプライトは、特にそれらがくっきりとした表示のとき(例:雷や炎)、明らかに平坦に見えてしまいます。ビルボードはぼんやりしたもの、例えば煙、霧、遠くの背景などにのみ使うようにしてください。バンプマップ、視差マップ、実体形状が組合わさらない限り、VRにおいては効果的ではありません。
(この場合、視差マップが個々の仮想視点と一致しているかを確認してください)

現在のOculusRiftの限られた解像度では、非VRゲームで使われる多くのトリックはまだ使わないようにしてください。しかし、解像度が改善されれば、それらのトリックがユーザーに受け入れられるのは言うまでもないことです。

音声設計

音響は、バーチャル世界の体現における二つの原理様式の一つです。高品質の音響は、低品質な資格体験を補完します。また、音響リソースはたいていの場合、視覚のリソースよりもプロセッサの処理能力を必要としません。音響を重視するのは役に立つ開発戦略です。音響は、まず間違いなく視覚と同様に重要です。周囲から聴くことは、バーチャル世界への知覚を継続的にサポートします。周囲からの音を活用することで環境で心理的な状態を表すうえで概念的なの前兆とすることができます。

OculusRiftでの体験を補完する一つの自然な方法は、ヘッドフォンの着用です。多くのユーザはゲームプレイ中にヘッドフォンを好んで着けます。VRの世界では、ヘッドフォンやスピーカは空間的な音響において異なった要望があります。バーチャルマイクは、バーチャル世界でのカメラがユーザの目として振る舞うことと同様に、ユーザの耳として振る舞う必要があります。音響デザインは、ユーザがヘッドフォンを着けており、出力ソースはユーザの頭の動きと一緒に動く耳の動きに追随していること、を考慮すべきです。スピーカーシステムでは同様といえず、(バーチャル環境での静的なオブジェクトと同様に)頭部の動作に関わらず絶対位置は固定されます。

周辺の音声を拾うバーチャル”マイク”は、いつもユーザの位置に追随するべきです。しかし、この行動は、ヘッドフォンやスピーカとは異なっています。ユーザがヘッドフォンを着けるとき、バーチャルマイクはユーザの頭の向きに対して回転する必要があります。しかし、スピーカを使うとき、頭の動きはマイクの方向に対して影響を与えません(ただしスピーカーの位置によっては位置の調整が必要かもしれませんが)。 あなたの作るコンテンツは、スピーカかヘッドフォンを選択できるオプションを付けるなどして、ヘッドフォンとスピーカの両方をサポートする必要があります。

音響デザインをさらに発展させると 、頭部伝達関数(HRTF)の使用により、真の3D空間を作ることができます。多くのサウンドライブラリはすでにHTRFsをサポートしています(Miles、DirectSound、OpenALを含みます)。したがって開発者もこれらを使うべきです。

ユーザと環境のスケール

スケールはVRにおける重要な側面です。あたかも実世界のように、ユーザーは物体のサイズを自身の身体との関係から直感的に知覚します。そして、簡単に物体(あるいは世界全体)について、誤ったスケールが設定されていると見わけてしまいます。
大半のゲームにおいて、皆は間違いなく全て正しくスケールするでしょう。Oculus Riftのソフトウェアにおいては、内部カメラの距離や視野、大凡の測定される単位はメートルなので、メートルから利用する基準の単位にあわせてください。

VRにおいて、現実の物理的なサイズ尺度から自由になっているものが3つあります。地面からのユーザーの眼の高さ、頭の動きに反応したカメラの動きのサイズ、そして瞳孔間の距離(IPD)です。これらはSDKやユーザー情報から提供されますが、これらはアプリ上で様々な用途に用いられます。見当識障害(酔い)を防ぎ、快適性と没入感が最大になる現実世界の寸法で設定してありますので、デフォルトでは操作しないことを推奨します。

多くのゲームにおいて、ユーザの憑依するアバターはナラティブ性やプレイのために特定の高さが必要になることがあります。例えば、ユーザの視界から周囲にある特定の箇所を隠したい場合、あるいは周囲から得られる要素をきっちり表示するために特定の高さを求める場合です。 (ポジショントラッキングではユーザがゲームにおける現地点から動き回って障害物を眺めて回ることが出来ることに注意して下さい。プレイヤーのアバターの可動範囲に加えてカメラのトラッキング範囲も考慮して環境の設計を行って下さい。) ユーザを自身とは一致しない仮想空間上の高さに固定することでは問題は発生しないはずです(ベクションの強度が強まります)。地面にめり込んで視界がふさがれるようなことがない限り。しかしながら、快適さのためにユーザのIPDと頭の動きは失わせないようにすべきでしょう。

スケーリングにより世界を拡大縮小する形で"不思議の国のアリス"的なエフェクトを実現することがあるかもしれません。スケールは相対的なので、実際には2つの巨大/縮小感を実現する方法があります。世界をスケールするか、ユーザーをスケールするか(高さとICD(inter camera distanceにより)です。 例えば、カメラのICDを人間の縮尺より大きな値(例えば1メートル)とした場合バーチャル世界を「ミニチュア風」に映り、小さなオブジェクトを近くから眺めるような両眼視差を作り出すためです。ICDを小さくした場合、一部のユーザには逆効果があり、世界全体の縮尺が大きく見えるようになります(但しすぐにICDがゼロとなるためその効果度合は相対的に限られたものです)。

ICDを通してVRでの世界のスケールを変更することは容易ですが、正しい設定を行わないと快適な結果を得ることが出来ません。ユーザの頭部の位置と向きをSDKにより求めた場合、ユーザの頭部モデルに関する3つの値が返されます。 最初の値は「目の中央(center eye)」と呼ばれる地点でありおおよそOculus Riftユーザの鼻筋に相当する位置です。原点および目の中央の間のベクトルはモデルの首にあたります。さらにSDKにより目の中央より発して左右の瞳の位置へと向かう二つのベクトルが返されます。

環境を変更することなくプレイヤーの感じる大きさを変更するには、単に3つのベクトル(首、左の瞳、右の瞳)に同じスケールを乗算します。 その結果としてバーチャル世界のなかでユーザ頭部のスケールが大きくなる効果が得られます。オブジェクトの距離に関するルールもスケールに合わせて適用することを推奨します。つまり、もしユーザの頭部の値を倍の大きさにするとユーザが焦点を合わせるオブジェクトが1.5メートルから7メートル離れているように注意すべきです。

ユーザの頭部モデルで3つのベクトルをともに適切にスケールすることは重要です。ベクトルの一部だけのスケールを大きくした場合、頭部の動作に対して不自然な反応が得られてしまうかもしれません。例えば首のベクトルだけ乗算した場合、頷く動作でユーザの目が不自然なモーションをするかもしれません(キリンの首の上にあるかのごとく)。目のベクトルにのみ乗算した場合、首を動かす動作が不自然なモーションをするかもしれません(目が長い棒の先にあるような、例えばシュモクザメかのごとく)。われわれはこの効果は不快なものであることが分かっているためユーザがこれを使用することを禁止します。

もしUnityで作業をしている場合、現実の次元に最大限近づけるためにメートルのような単位を一つだけ扱ってください。もし現実のVR体験を開発する場合には設定することになるでしょう。もしファンタジーや代替現実によるVR体験を開発する場合には、別のスケール感覚を考えるかもしれません。リアルを追及するかどうかはさておき、アートの効果を意図したものに到達させるため、アートアセット上で早めにRiftに入って試してみることを推奨します。
世界のスケールが、意図している美的な効果を得つつ快適な体験となるようにバランスを保って下さい。

警告として、人々の知覚は仮想空間上の距離を甘く見がちで、完全に測定された空間上であったとしてもなお時々違和感を覚える、ということについての研究文献を書きとめておきます。(29(30  身近なオブジェクトはよくも悪くも視界における目印として機能します。もしオブジェクトと頭部モデルのいずれかのスケールが現実世界と差異が生じた場合、身近なオブジェクトである扉や持ち物や什器でそれは顕著になります。これは必ずしも悪いことを意味しません。身近なオブジェクトはスケールを変更したことを強調してバーチャル世界が現実世界と比べていかに大きいか小さいかを強く認識させます。

Oculus Riftが座ったままの体験であることによりスケールにおける困惑させられる問題が生じます。例えばVRにおいて座った状態で立った姿勢の人間を見つめると、直感的に相手が小人のように見えるかもしれません。Oculus Riftを被っているからといって脳は現実世界の身体が何をしているかを忘れません。バーチャル世界を解釈するときに座っていることを考慮に入れてしまうものです。興味不快ことに、このスケール効果に関する非公式な研究により、高い腰掛椅子に座っていることが低い椅子に座っていること(座っているときに目の高さの位置が変わらないとしても)に比べてVR世界の自然な感覚にあまり影響を及ぼさないことが分かっています。外部の開発者からの報告により、普通の椅子で同様の効果が見られており、ユーザの足が地面につかないようにする手法により(例えば足を吊り輪やパッドにより椅子から足がぶら下がるようにする)、目が地面から実際にどれだけ離れているかを身体に感じさせていると聞いています。本件についてはTom Forsyth氏がGDC 2014で公開した内容がありますので参考文献として紹介します。31)

29
Messing, R. & Durgin, F.H. (2005). Distance perception and the visual horizon in head-mounted displays. ACM Transcriptions on Applied Perception, 2(3), 234-250.
30
Willemsen, P., Colton, M. B., Creem-Regehr, S. H., & Thompson, W. B. (2004, August). The effects of head-mounted display mechanics on distance judgments in virtual environments. In Proceedings of the 1st Symposium on Applied Perception in Graphics and Visualization (pp. 35-38). ACM.
31

付録 K - (今のところの)効果的なVRについての考察



  • Riftによって、ユーザーの視覚的現実をかつて無いほど制御することができます。これは開発者にとって未踏の課題です。


「効果的なVRをどうすれば実現できるか?」とは、本が数冊書けるほど多くの文脈を持つ広範な問いです。VRはほとんど未開拓のメディアで、アーティストや開発者により最大限のポテンシャルを発揮させられるのを待つ状態です。

手始めに、VRは空間、大きさ、没入、インタラクションとナビゲーションについての新しい考え方を必要とするでしょう。例えば、スクリーンのあるメディアは、直角や直進運動に重きを置いており、スクリーンの縁は常に存在します。これが撮影監督のいうところの、ショットの「フレーム」に繋がります。しかしVRにはスクリーンも、物理的な境界もなく、よいカメラ アングルも存在しません。そして、ドアや窓のようなユーザーが覗くことのできる実世界の要素を使わない限り、「フレーム」は存在しないのです。

全てのメディアのうち、VRはおそらくもっとも実世界での体験に近いものでしょう。実世界と同じように、VRはユーザーを完全に没入的な環境で包み込みます。これによって、他のメディアでは不可能な体験を作り出すことができます。我々は、平らなスクリーンの前にあまりにも長く座りすぎました。ユーザーの上、下、そして背後の空間を活用することはこれまで以上に楽しくもあり、そして望まれていることなのです。

VRは物理的な実世界での体験を模倣しようとするメディアであるために、ユーザーはVR内でも外の現実と同じように振る舞えることを期待します。これは利点でもあり欠点でもあります。開発者はユーザーが慣れ親しんだ実世界の事象を使って誘導を行えますが、同時に、ユーザーの期待は現在可能なVR体験を上回ってしまうこともあるのです。没入感、操作性、そして体験のバランスをとることは、VRに向けたデザインの多くの課題の一つに過ぎません。

このガイドはVR体験のデザインに必須の、最も基礎的な事項を提供するために書かれています。VRが真に輝く体験を、そして世界を作り出すことはあなたにかかっています。我々をそれを見るのを待ちきれません!

Rift向けのVRコンテンツ作成についての最新情報や議論については、ぜひ http://developer.oculusvr.com/best-practices をご覧ください。

付録 L - 健康と安全に関する注意


これらの健康と安全に関する注意は正確性と完全性のため定期的に更新されます。最新版は www.oculusvr.com/warningsをご覧ください。

健康と安全に関する注意:負傷、疾病、経済的損失のリスクを低減するため、ヘッドセットを利用する前に以下の警告をよく読んでください。  


ヘッドセットを使用する前に


  • ヘッドセットに付属する、セットアップ及び使用に関する全ての指示に従ってください。
  • ヘッドセットはVR利用開始の前に、各ユーザーについてキャリブレーションを行ってください。キャリブレーションを行わない場合、不快感とシミュレーション酔いの可能性が増加します。
  • 現実世界で乗り物酔いしやすい人は、ヘッドセット使用中に不快感を生じる可能性が高いです。このような方は本章の警告をよく読んでその内容に従ってください。
  • 妊婦、老人、心不全もしくは他の重要な疾患を持つユーザーは、ヘッドセット利用前に医師に相談してください。

発作

警告:一部の人々(約4000人に1人の割合)において、光の明滅やパターンによって深刻な目眩、痙攣、癲癇の発作、意識の消失が引き起こされる場合があり、TVの視聴、ゲームプレイ、VR体験などの途中にこれらの発作が発生する可能性があります。これらの症状は過去に発作、意識消失、癲癇などの経験がなくとも発生する場合があります。
これらの症状は子供および20歳以下の若い人に見られます。過去にこれらの経験があるユーザーはヘッドセットの利用前に医師に相談してください。

子供による利用

警告:本製品は視覚の発達段階の重要な時期にあるため、7歳未満の児童によって利用されるべきではありません。ヘッドセットを利用中、あるいは利用あとに次のいずれかの症状のある7歳以上の子供についても保護者による監視が必要です。また子供が利用中に休憩をとっていることを確認して下さい。手と視覚の関係、バランス感覚、並行作業の能力に悪影響を及ぼすことが分かっているため長時間の利用は避けて下さい。保護者はこれらの能力が低下していないか、利用中または利用後にきちんと子供の監視をして下さい。

一般的な説明と注事項

傷害または不快感を減らすために、ヘッドセットを利用中に常に次の説明にしたがって、注意事項を遵守する必要があります。

  • 安全な状況で利用して下さい:ヘッドセット向けのコンテンツは没入的なVR体験を発生させるため、周囲の実際の環境を把握することが困難になります。ヘッドセット利用時には常に周囲の環境に注意し、必ず座った状態で利用してください。人が近くにいないこと、階段、バルコニー、窓、家具、が無いことを確認してください。また、ヘッドセット利用中もしくは利用直後に、衝突する、躓く、横転させる可能性のある物体が周囲に無いことを確認し、ヘッドセット利用中は鋭利な物体やその他の危険な物体を扱わないでください。歩行時やサイクリング、ドライブのように注意を要する状況ではヘッドセット装着しないで下さい。
  • ヘッドセットが水平かつ快適に頭に装着されていることを確認して、はっきりとしたぶれてない映像が見えていることを確認して下さい。
  • 身体が慣れるようにヘッドセットを利用する際は徐々に行ってください。最初は一回に数分だけ利用して、バーチャルリアリティに慣れてくるにつれて徐々にヘッドセットを利用する時間を増加させてください。
  • 快適なバーチャルリアリティ体験は運動感覚と平衡感覚が正常である必要があります。疲労時、不眠時、飲酒や薬の影響があるとき、二日酔い時、消化器系に問題がある時、精神的なストレスや不安のあるとき、風邪、インフルエンザの時、頭痛時、偏頭痛時、耳の痛みがある時は症状を悪化させるためヘッドセットを利用しないで下さい。
  • 必要だと思わなくても少なくとも10分から15分の休憩を30分おきにとってください。個人差があるため、不快感を感じるときはより頻繁により長時間の休憩をとってください。
  • 大音量で音を聞くことで、聴力に回復できないダメージを及ぼす場合があります。BGMや大音量に長時間さらされる場合、実際の大きさをより静かなものと感じてしまうことがあります。バーチャルリアリティの没入感のある特性のため、周囲の環境への意識を維持できるようにヘッドセットは大音量で使用しないようにして、聴力へのダメージが残るリスクを避けて下さい。

不快感

警告:ヘッドセット利用者に次のいずれかの症状が生じた場合、ただちに利用を中断して下さい。発作、意識喪失、眼精疲労、目や筋肉の痙攣、不随意運動、視覚の変化、ぼやけ、二重に見える、視覚異常、眩暈、方向感覚の喪失、平衡感覚の喪失、手と視覚の協調関係の障害、過度の発汗、唾液の増加、吐き気、立ち眩み、頭または目の不快感や痛み、眠気、倦怠感、乗り物酔いに近い症状。

  • バーチャルリアリティに晒されたときの症状は船酔いの体験と類似して、利用後数時間後に症状が顕著になる場合があります。前述の症状のほかに過度のな向けや並行作業を行う能力を低下させます。これらの症状は現実世界で通常の活動をする際に傷害の危険に晒される可能性を高めます。
  • 症状から完全に回復するまで、車の運転や機械の操作をしないで下さい。また、視覚的または身体的な負担の大きい活動をしないで下さい。(例.症状があることにより死亡、人身事故、公共物への損害につながる活動)
  • 全ての症状が完全に回復するまで数時間ヘッドセットを利用しないで下さい。使用を再開する前に、ヘッドセットをきちんと設定して下さい。
  • 症状が出やすいコンテンツの種類は個人により出やすさが異なるため、症状の出る直前に利用したコンテンツにはよく注意して下さい。
  • 深刻または持続的な症状が出る場合は医師の診察を受けて下さい。

反復的な緊張による損傷:

ゲーム中、筋肉や関節、皮膚などに痛みが発生する場合があります。 もしプレイ中に体の一部に疲れや痛み、あるいは刺痛やしびれ、炎症、こわばりといった症状を感じた場合、利用を中止して数時間の休息を入れてください。もしプレイ中やプレイ後にも上記の症状や不快感が続く場合、 プレイを中止し医師の診察を受けて下さい。

無線干渉

ヘッドセットはペースメーカーを含む周辺の電子機器に影響を与える可能性のある電磁波を発生させる場合があります。ペースメーカーやその他の医療インプラントを所持している場合、ヘッドセットの無線機能を利用する前に、医師もしくは医療機器の製造者へ問い合わせてください。

感電

感電のリスクを低減するため以下の指示に従ってください。
  • ヘッドセットを水中や湿気のある場所で使用しないでください。
  • ヘッドセットを掃除する前に、電源を抜き、乾いた布のみを使用してください。
  • ヘッドセットを炎やその他の熱源に近づけないでください。
  • ヘッドセットを改造、あるいは分解しないでください。
  • ケーブルが損傷していたりワイヤーがむき出しになっている製品は使用しないでください。
  • 電源アダプタはヘッドセット付属のものを使用してください。

日光によるダメージ:

ヘッドセットを直射日光の下に放置しないでください。ヘッドセットが損傷する恐れがあります。  

Copyright © July 2014 Oculus VR, LLC

ブックマークに追加

このエントリーをはてなブックマークに追加

自己紹介

自分の写真
Unity3D公式マニュアル翻訳やってる人がスマホ(iPhone, Android)のゲーム開発しています。気軽に面白く初心者が遊べる内容がモットー。Blogでは開発情報をひたすら、Twitterではゲーム作成の過程で参考にしている情報を中心につぶやきます

ページビューの合計

過去7日間の人気投稿