VR
oga at 23:07
様々な VR HMD やコンテンツを体験していると、本来リアルなシーンなのに人や風景が人形のように小さく見えることがあります。反対に、周囲に巨人が動き回っているように見える場合もあります。その原因は視差の違いにあります。

目と目の間隔は個人差があります。そのため、同じコンテンツでも視差による感じ方は人によって異なってきます。


● 視差と距離感

普段見ている景色は遠くにあるものほど視差が小さくなります。よって VR 空間内でも視差が現実よりも小さい場合は、物体が遠くにあるように感じます。

その極端な例が視差が無いモノラルな 360度写真や 360度動画です。VR で巨大な人が周りに立っているかのような 360度写真を何度か見たことがあるのではないでしょうか。

視差が無いということは現実だと極めて遠くにある場合に相当します。遠くにあるはずなのに、近くにある場合と変わらない大きさで見えているのだから「これは非常に巨大なものであるに違いない」と脳が勘違いしてしまうわけです。

逆に視差が大きいときは、より手前にある場合に相当します。近くにあるのに遠くにあるときと同じ大きさに見えているのだから、とても小さいものがそこにあるのだと感じてしまいます。


● 目と目の間隔 IPD

目と目の間隔 (IPD = 瞳孔間距離) は見え方に影響を与えます。個人差があるため、多くの VR System では目の間の距離を調節する仕組みが備わっています。IPD には 2種類あります。

物理 IPD HMD のレンズやモニタ間の距離
レンダリング IPD 仮想空間内に配置した、両目のカメラ間の距離

ハイエンド系の VR HMD では、直接物理 IPD を調節するための仕組みが用意されているものがあります。HTC Vive では右下にダイヤルが付いており、Oculus Rift でもスライドスイッチで調節することが可能です。この調節した値は API から読み取ることが可能で、レンダリング IPD にそのまま反映されます。

レンズを見やすい位置に調節できる上に、レンダリング IPD にも自動的に反映されるため手間がかかりません。逆に見かけの大きさに違和感があっても、物理 IPD とレンダリング IPD を意図的にずらすことができなくなっています。

物理 IPD の調節ができない機種でも、ソフトウエア的にレンダリング IPD の設定ができるものがあります。PS4 の PSVR では、設定の中に目と目の距離を測定するための機能が用意されています。Windows MR ではもっと単純で、設定画面の中で IPD を直接数値入力することができます。

Device 物理 IPD 調節 レンダリング IPD
HTC Vive ダイヤル 物理 IPD に連動
Oculus Rift スライドスイッチ 物理 IPD に連動
PSVR なし 目と目の距離測定機能
Windwos MR なし 設定画面で数値入力


●大きさの違和感を解消するための調節

VR 空間内で人や物の大きさが大きすぎたり小さすぎると感じる場合は、現実と IPD の値がずれていると考えられます。個人差があるので、他の人にはちょうどよく見える場合も自分には小さかったり大きく感じたりする場合があります。

大きく見える場合は視差が小さいので、レンダリング IPD を増やします。もし小さく見える場合は視差が大きいので、レンダリング IPD を減らす方向に調節します。

ただし、HTC Vive や Oculus Rift のように物理 IPD とレンダリング IPD が連動している場合はこの調節ができません。物理 IPD はレンズを通して映像が一番見えやすい位置に調節すべきで、レンダリング IPD だけ意図的にずらすことができないからです。

PSVR は数値入力できないので、目と目の距離を測定するツール上で調節することになります。少々手間がかかるのですが、「設定 → 周辺機器 → PlayStation VR → 目と目の距離を測定する」で写真から目の中心を割り出すときに、瞳の中心から外してあえて狭くしたり、広げることで調節ができます。

Device レンダリング IPD だけの微調整
HTC Vive なし
Oculus Rift なし
PSVR 目と目の距離を測定するツールで、間隔をずらす
Windwos MR 設定画面で数値入力

個人差があると思いますが、自分の場合 IPD をきちんと設定しても Oculus Rift は Vive よりもわずかに大きく見える傾向がありました。ただしどちらも比較的違和感が無い範囲での違いです。PSVR は全体的に小さく見えていました。Windows MR は一部の HMD しか試していませんが違和感ありませんでした。


なお、このようなレンダリング IPD 調節が有効なのはあくまで、ゲームのように 3D でリアルタイムレンダリングを行っている場合だけです。プリレンダリングされた動画や、実写の 360度動画や 360度写真は、撮影時にカメラ間の距離が決まってしまいます。コンテンツに依存するためあとから IPD を変更することができません。

ポジショントラッキング対応の HMD でも、ムービーでは頭の位置を水平に動かすことができないのと同じです。個人差があることを踏まえても、より良い VR 体験には リアルタイム 3D は欠かせない要素となっていると言えるでしょう。


関連エントリ
Oculus Go は VR ができる新しい携帯ゲーム機
Oculus Go と VR デバイスの種類


VR
oga at 23:25
Oculus Go は VR アプリの専用機であることと、23800円 (32GBモデル) という価格から考えると Vita や 3DS のような携帯ゲーム機の一種と言えるのかもしれません。それだけ手軽に楽しめるようになっています。気軽に持ち出して人に見せたり、勧めたくなるような魅力があります。

とはいえ Oculus Go はモバイル VR の範疇なのでそれなりに限界があります。興味が出てきたら、より性能が高い VR を体験してみるのも良いのではないでしょうか。一番良い体験ができるのはやはり VR ZONE などのアーケードでも使われている HTC Vive でしょう。

Oculus Go とハイエンド系 VR との大きい違いは、ヘッドセットやコントローラが回転しかできず、位置の特定に対応していないことです。360度周囲を見渡すことができますが、頭を前後左右に動かしても VR 空間内では動いたことになりません。頭の位置に合わせて周囲の空間の方が引きずられてついてくるような動きになります。脳の予測と差異が生じるため仮想空間の現実度がどうしても弱くなってしまいます。

落ち着いた場所でじっくり楽しむハイエンド VR と、どこでも手軽に体験できるモバイル VR とのプレイスタイルの違いと言えるかもしれません。

ただしコンテンツの作り方次第ではあるのですが、回転だけの 3DoF では酔いやすいコンテンツに注意が必要かもしれません。自分では VR 空間内で動くことができないので、Teleport や一般の 3D ゲームのような何らかの移動操作が必要になります。この移動操作によるカメラの動きは特に酔いの原因になりがちです。他に全く酔わない VR の手法としてルームスケールがあるのですが、ルームスケールの実現には位置判定 (6DoF) への対応が必要となります。


現在体験できる VR デバイスをいくつかのグループに分けてみました。上に行くほど高性能で、仮想空間の現実感が増します。下に行くほど仮想空間の嘘がばれやすくなります。


◎ ハイエンド VR (6DoF + 6DoF)

・PC の Desktop GPU によるレンダリング
・6DoF の移動ができるヘッドセット
・6DoF の移動ができるモーションコントローラ 2個以上
・ルームスケール対応
・PC が必要でケーブルがじゃま

頭を動かしても違和感がありません。手の位置が仮想空間内でも正確に反映されます。VR 酔いしないで歩き回れるルームスケールを実現することができます。外部センサーなどの設置が必要になることがあります。同じ括りにしていますがプラットフォーム毎に性能差がそれなりにあります。

Device RoomScale Motion Controller
HTC Vive 3個以上利用可能
Oculus Rift 2個
Windows MR 2個 範囲制限あり
PSVR 2個 範囲制限あり


◎ モバイル VR (3DoF + 3DoF)

・Mobile 向け GPU によるレンダリング
・3DoF の回転のみのヘッドセット
・3DoF の回転のみのモーションコントローラ 1個
・ケーブルが無く取り回ししやすい

PC 不要でコードがなく、気軽に楽しめるのが特徴です。コントローラの制限は変わりませんが、HMD だけ 6DoF になった Mirage Solo や Vive Focus も登場しています。

HMD Motion Controller
HTC Focus 6DoF 3DoF 1個
Mirage Solo 6DoF 3DoF 1個
Oculus Go 3DoF 3DoF 1個
GearVR 3DoF 3DoF 1個
Daydream 3DoF 3DoF 1個


◎ 簡易 VR (3DoF)

CardBoard のように一般のスマートフォンをそのまま利用するものがあります。専用ハードではないので視界の端が歪んでいたり描画遅延が大きかったりします。360度ビューアに近いと言えるかもしれません。


関連エントリ
Oculus Go と VR デバイスの種類


VR
oga at 00:09
Oculus Go 入手しました。名前が Oculus なので Oculus Rift との互換性を期待してしまいますが、実際は GearVR の専用機になります。

null

↑左が Oculus Go、右が Daydream View (2017)
Oculus Go の方が若干大きめ。左下の黒いのは GearVR コントローラ


Oculus Go には Snapdraogn 821 を搭載した Android デバイスが内蔵されており、Daydream で言えば Pixel 初代機や ZenFone AR と同じです。Galaxy だと S7 世代がほぼ近いスペックです。ただし Oculus Go の RAM は 3GB でした。

性能面では HTC Vive, Oculus Rift といった PC ハイエンド VR とは比較にならないものの、一体型の専用機なのでケーブルやアダプタの接続といった煩わしさが一切ありません。セットアップも専用機らしく簡単になっています。iOS や Android のコンパニオンアプリから行うので、Wi-Fi 設定も使い慣れた操作でできました。

さらに Oculus Go の手軽さを実感できるのはサウンドです。ヘッドホンが無くてもかぶるだけで音が聞こえてきます。

ケーブルレスの Daydream や GearVR でもヘッドホンは必要でした。本来 VR では音の効果は重要なのですが、Vive や Windows MR でもヘッドホンケーブルは絡まりやすく、開発中何度もテストするときはヘッドホンを使わない場合がほとんどです。便利なのでこのスピーカーは他の HMD にも付けて欲しいくらいです。


VR デバイスは機能面で大まかに分類すると 2種類あります。


◎ ハイエンド VR (6DoF + 6DoF)

・PC Desktop GPU
・Position Tracking 対応 HMD
・Position Tracking 対応 MotionController

HTC Vive, Oculus Rift, PSVR, Windwos MR



◎ Mobile VR (3DoF + 3DoF)

・Mobile GPU
・回転のみの HMD
・回転のみの MotionController

GearVR, Daydream (Smartphone), Oculus Go



スマートフォンは普段持ち歩くので HMD に装着したままにはできませんし発熱も結構気になります。Daydrream 対応機種もなかなか増えないので、Mobile VR の場合は手軽に使える Oculus Go のような専用機は良い選択かもしれません。

Snapdraogn 835 以降では Mobile VR でも 6DoF のデバイスがいくつか登場しています。モーションコントローラの制約はまだ残っています。


◎ Mobile VR (6DoF + 3DoF)

HTC Focus (Mobile GPU, 6DoF + 3DoF)
Daydream Mirage Solo (Mobile GPU, 6DoF + 3DoF)


その他の詳細なデバイス一覧はこちらにまとめています。


関連ページ
HMD VR / AR Device spec 一覧


最近のハイエンドスマートフォンは 6G ~ 8GB もの RAM を搭載しており PC との差がなくなってきました。termux というアプリを使えば Android 上でも開発環境を整えられるとのことなので、コンパイル時間を比べてみました。

Smartphone SoC RAM thread time1 time2
Galaxy S6 Edge Exynos 7420 3GB 8 77.8 79.8
ZenFone AR Snapdragon 821 8GB 4 118.3 127.7
Nexus 5X Snapdragon 808 2GB 6 195.6 181.0
Nexus 5 Snapdragon 800 2GB 4 244.1 233.0

・2回連続で計測しており単位は秒です。time1, time2 の値が小さい方が高速です。

big.LITTLE で 8 core の Galaxy S6 Edge が際立つ結果となっています。4 core PC で 30秒ほどなので十分なな速度と言えそうです。

今回のビルドは RAM 容量よりも Thread 数が有利に働いたようです。Galaxy S6 はビルドに 8 core 全部使われており、LITTLE core も使って並列度を増やした方が速いことが分かります。下記は Galaxy S6 と ZenFone AR でスレッド数を変えて試した結果です。bit.LITTLE を意識して制限するよりも全 core 使った方が高速でした。

↓Galaxy S6 Edge (4+4 big.LITTLE 8 core)

thread数 time
8 76.3
6 84.8
4 111.7

↓ZenFone AR (2+2 big.LITTLE 4 core)

thread数 time
5 128.9
4 118.3
3 142.0
2 174.0

以下はスマートフォン以外のデバイス含めてテストした結果です。

Smartphone (clang-6.0) SoC RAM CPU core thread time1 time2
Galaxy S6 Edge Exynos 7420 3GB A57 2.1 + A53 1.5 4+4 8 77.8 79.8
ZenFone AR Snapdragon 821 8GB Kyro 2.3 + Kyro 1.6 2+2 4 118.3 127.7
Nexus 5X Snapdragon 808 2GB A57 1.8 + A53 1.4 2+4 6 195.6 181.0
Nexus 5 Snapdragon 800 2GB Krait 400 2.2GHz 4 4 244.1 233.0
Tablet (clang-6.0) SoC RAM CPU core thread time1 time2
Tegra Note 7 Tegra 4 1GB Cortex-A15 1.8GHz 4 4 159.7 145.4
Fire HD 6 MT8135 1GB A15 1.5 + A7 1.2 2+2 4 203.3 202.5
Nexus 7 2013 Snapdragon 8064 2GB Krait 1.5GHz 4 4 262.2 260.5
Nexus 9 Tegra K1 2GB Denver 2.3GHz 2 2 317.7 356.8
Fonepad 7 ME372CL Atom Z2560 1GB Saltwell 1.6GHz 2 4 686.5 682.8
MeMO Pad 7 ME176C Atom Z3745 1GB Silvermont 1.33GHz 4 4 294.5 291.6
TV (clang-6.0) SoC RAM CPU core thread time1 time2
SHIELD TV Tegra X1 3GB A57 2.0GHz + A53 4+4 4 76.0 76.0
Nexus Player Atom Z3560 1GB Silvermont 1.8GHz 4 4 339.8 334.3
Fire TV Stick 2015 Broadcom 28155 0.5GB Cortex-A9 1.0GHz 2 2 596.7 569.2
SmartWatch (clang-6.0) SoC RAM CPU core thread time1 time2
FossilQ Marshal Snapdragon 400 0.5GB Cortex-A7 0.8GHz 4 2 810.5 810.7
SBC (clang-3.5) SoC RAM CPU core thread time1 time2
Dragonbaord 410c Snapdragon 410 1GB Cortex-A53 1.2GHz 4 4 117.3 118.7
Raspberry Pi 3 BCM2837 1GB Cortex-A53 1.2GHz 4 4 175.3 159.8
Raspberry Pi 2 BCM2836 1GB Cortex-A7 0.9GHz 4 4 337.1 301.2
Chromebook (clang-6.0) SoC RAM CPU core thread time1 time2
Chromebook Flip C101PA RK3399 4GB A72 1.8 + A53 2+4 6 106.0 105.1
Chromebook C720 Haswell 4GB Celeron 2955U 1.4GHz 2 2 220.7 219.3
PC (clang-3.8) SoC RAM CPU core thread time1 time2
X370GTN (W10+WSL) Ryzen 7 1800X 32GB Zen 3.7GHz 8 16 25.4 22.2
H97I-PLUS (W10+WSL) Core i7-4770 16GB Haswell 3.4GHz 4 8 28.7 28.2
A88M-ITX (W10+WSL) A10-7870K 8GB Steamroller 3.9GHz 4 4 65.9 61.6
MacBook Pro Core i5-3210M 2GB Ivy Birdge 2.5GHz 2 4 83.7 90.8
Q1900B-ITX (16.04LTS) Celeron J1900 8GB Silvermont 2.0GHz 4 4 112.2 108.8

・Chromebook は termux ではなく Crouton + Ubuntu を使用しています。


スマートフォンやタブレットは計測時のばらつきが結構あります。2回目以降の方が遅くなるケースも多く、形状が小さいデバイスほど発熱の影響を多く受けているものと思われます。

ARM で一番速かったのは Tegra X1 の SHIELD TV です。こちらは他の ARM デバイスと違い内蔵ファンによる熱対策が行われています。

キーボードがつながらないので実用性はほぼ無いものの Wear OS (Android Wear) の Smartwatch でも動きました。

null


関連エントリ
AMD CPU Ryzen とコンパイル時間の比較 (2)
AMD CPU Ryzen とコンパイル時間の比較
ARM Cortex-A53 の浮動小数点演算速度とコンパイル時間の比較
2955U vs N3150/J1900/Athlon5350 (コンパイル時間の比較)
Raspberry Pi 2 で速くなったコンパイル時間の比較
BayTrail vs Kabini (Celeron J1900 vs Athlon 5350)
コンパイル時間の比較 BayTrail
Atom vs Core i7


遅くなりましたが DirectX 12 の対応状況に Vega 56 のデータを追加しました。Vega (GCN 5) は FEATURE_LEVEL 12_1 に対応しており、ROV 等 D3D12 の機能を搭載しています。ただし ShaderModel は 5.1 のままでした。

Direct3D 12 (DirectX 12) GPU の対応

GeForce, Intel HD Graphcs のテスト結果も更新しています。新しいドライバでは GeForce の Maxwell, Pascal も ResourceBindingTier が Tier 3 に上がっていることがわかりました。また ShaderModel 6.0 (WaveOps == true) にも対応しているようです。

GPU Driver FeatureLevel ShaderModel
RADEON Vega GCN 5 18.3 12_1 5.1
RADEON RX Polaris GCN 4 18.3 12_0 5.1
RADEON R3/R7/R9 GCN 2 18.2 12_0 5.1
GeForce GTX 1000 Pascal 388.13 12_1 6.0
GeForce GTX 900 Maxwell 388.13 12_1 6.0
GeForce GTX 750Ti Maxwell 388.43 11_0 6.0
Skylake Intel HD Graphcis Gen 9 12_1 6.1
Broadwell Intel HD Graphcis Gen 8 11_1 5.1
Haswell Intel HD Graphcis Gen 7.5 11_1 5.1

Intel HD Graphcis も Skylake 世代からは ShaderModel 6.1 対応となっています。結果は今後ドライバの更新で変わる可能性があります。


関連ページ
Direct3D 12 (DirectX 12) GPU の対応

関連エントリ
Direct3D 12 GPU GeForce GTX 1070 Pascal と RADEON RX 480 Polaris


<<前のページ(日付が新しい方向) | 次のページ(日付が古い方向)>>