Oculus SDKのAsynchronous Timewarpの詳細説明
Timewarpは、最新のヘッドトラッキング情報に基づいて立体画像を変換し、表示遅延を大幅に低減します。 VRアプリケーションの遅延とぶれを低減します。
以降詳細です。後半に行けば行くほどアプリ開発者向けの内容になっていきます。（一部GearVR開発向けの内容を含みます）
ざっくりとどんなものか知りたい場合は以下の記事を参照してください。
https://vr-maniacs.com/entry/asynchronous-timewarp/
概要
VRゲームでは基本的に以下のような順番で処理が繰り返されます（以下ゲームループと呼びます）：
- ソフトウェアが頭の向きを検知
- CPUが両目用にシーンを処理
- GPUがシーンを描画
- Oculus Compositorがレンズに合わせて映像を歪め、ヘッドセットに表示
以下は基本的なゲームループの例を示しています：
フレームレートが維持されると、ゲーム体験は現実を帯び、楽しいものになります。 もし、これが時間通りに処理されないと、前のフレームが表示され、現在の姿勢とはずれた表示をしてしまう可能性があります。 次の図は、ゲームループにおいてぶれが生じたときの例を示しています：
あなたが頭を動かしても空間の描画が追いついていない場合、不快感を覚え没入感が損なわれることになります。
ATWは、頭の動きの変化を調整するために、レンダリングされた画像をわずかにずらす技法です。 画像は修正されていますが、頭はあまり動きませんので、変更はわずかです。
さらに、ユーザーのコンピュータ、ゲームデザイン、またはオペレーティングシステムの問題をスムーズにするために、ATWは、フレームレートが予期せず低下したときの「隙間」や瞬間を修正するのに役立ちます。
次の図は、ATWを適用した場合にフレームが欠落した時の例を示しています。
画面描画の合間に、Compositorは最後にレンダリングされたフレームにTimeWarpを適用します。 その結果、TimeWarpが適用されたフレームは、フレームレートに関係なく、常にユーザーに表示されます。 フレームレートが非常に悪い場合は、ディスプレイの周辺でちらつきが目立ちます。 しかし、画像はまだ安定しています。
ATWはOculus Compositorによって自動的に適用されます。あなたはこれを明示的に有効にしたり調整する必要はありません。 ATWは遅延を減らしますが、アプリケーションがフレームレートを作り出していることを確認してください。
訳注：以下はモバイルに特化した内容でPC版には当てはまらない内容が含まれています。
ディスカッション
立体画像として目から見える映像はテクスチャにレンダリングされます。この時、ヘッドセット内の広角レンズによって引き起こされる歪みを補正するよう、ディスプレイ上をワープされます。
Motion-to-photon delay（ユーザの動きが実際にディスプレイに反映されるまでの遅延）を低減するために、タイムワープを描画する直前の更新されたヘッドセットの方向情報が利用されます。そして、目への表示の用いるテクスチャがレンダリングされた時刻からディスプレイに表示されるはずの時刻への変換行列が計算されます。
多くの人々は最初にこれを聞いたとき懐疑的ですが、姿勢の変化に対して、ワープされたピクセルは大体正確です。急な回転では、端のいくつかのピクセルが黒く塗りつぶされますが、それはあまり気になりません。
タイムワープは、それを「補間されたタイムワープ」にすることによってさらに進歩しています。ビデオは約120スキャンラインで1ミリ秒の割合でスキャンされるため、右側のスキャンラインの方が左側のラインよりもレイテンシが長くなります。低速LCDでは、これは問題ではありませんが、鮮明なスイッチングOLEDでは、ユーザーは素早く回っているときに世界が微妙に伸びたり剪断されているように感じるかもしれません。これは、各眼の開始時の頭の姿勢、<8ミリ秒の予測、および<16ミリ秒の各眼の終わりを予測することによって補正されます。これらの予測は、タイムワープ変換を計算するために使用され、ワープは、描かれた各走査線に対してこれらの2つの値の間で補間されます。
タイムワープは、眼のテクスチャをサンプリングするために歪んだテクスチャ座標を計算するフラグメントプログラムによって、全画面の四角形をレンダリングするようGPU上に実装されるかもしれません。しかし、性能を向上させるために、タイムワープは、テクスチャ座標がアイテクスチャをサンプリングするように設定されている画面全体にわたって、均一にテッセレーションされた三角形のグリッドをレンダリングします。ワープテクスチャ座標を有する三角形のグリッドをレンダリングすると、基本的にタイムワープの区分的線形近似が得られます。
タイムワープが立体映像のレンダリングと非同期で実行される場合、それは知覚されるフレームレートを増加させ、不均一なフレームレートを平滑化するために使用してもよいでしょう。デフォルトでは、タイムワープは現在、ネイティブアプリケーションとUnityアプリケーションの両方に対して非同期に実行されます。
TimeWarpの最小Vsync
TimeWarp MinimumVsyncsパラメーターのデフォルト値は、60 FPSターゲットでは1になっています。これを2に設定すると、最大アプリケーションフレームレートが30FPS以下に低下します。非同期TimeWarpスレッドは、60FPSで更新されたヘッドトラッキングを使用して新しいフレームをレンダリングし続けますが、アプリケーションは毎秒30個の新しい両目用の映像を生成する機会があります。試験的な目的で高い値を設定できますが、アプリを出荷するための唯一の値は1と2です。
明示的に設定することを検討する2つのケースがあります：
ほとんどの場合、アプリケーションで60 FPSを保持できない場合は、アプリケーションの滑らかさや動作が予期せず変更されるのではなく、常に30 FPSで固定する方がよい場合があります。ほとんどの場合、60 FPSを保持するために経験を単純化することは正しい判断ですが、例外が存在する可能性があります。
アプリケーションのレンダリングFPSを30にすることは、大幅な電力を節約し、デバイスの熱負荷を低減します。一部のアプリケーションでは60 FPSに達することができますが、熱問題に迅速に対応するため、パフォーマンスに大きな影響を与える可能性があります。長時間再生できるようにするには、30 FPSをターゲットにする必要があります。熱スロットル軽減戦略の詳細については、「Power Management」を参照してください。
60 FPSでレンダリングしない場合の結果
これらの結果は、あなたが明示的にMinimumVsyncsを設定しているかどうかに関係なく適用されます。
視点がすべてのジオメトリから遠く離れている場合は、アニメーション化されるものは無く、頭の回転率も低く、視覚的な違いはありません。 これらの条件のいずれかが存在しない場合、バランスのとれたアーティファクトが大きくなるかまたは小さくなります。
頭の回転率が高い場合、アイバッファが提出されてからどれくらいの時間が経過したかに応じて、画面端の黒は視覚的に可変量だけ引き込まれます。これはまだ60FPSで行われますが、合計時間がフレームごとに小さくて一定であるため、気付くのはほとんど不可能です。 より低いフレームレートでは、画面の端にスナップするように見えます。
これには2つの緩和策があります：
1）ヘッドトラッキングモデルが照会された点としてフレームが表示され始める時点、または「今」のどちらかを使用する代わりに、アイバッファが表示されるすべてのフレームの中間点にある時間を使用する。これは、画面上に積み重なるのではなく、画面の両側に「未レンダリング領域」を分散させます。
2）それと相まって、アイバッファーに使用される視野を広げると、エッジから離れてより多くのクッションを取り除くことができます。 ネイティブアプリケーションでは、現在、フレームレートが60未満のときに視野を10度を広く取ります。アイバッファの解像度を上げないと、画面中央の実効解像度が低下します。頭の回転率に基づいて視野を動的にスケーリングすることは価値があるかもしれませんが、エッジには最初のポップが表示され続けることになり、視野を連続的に変更するとほとんど安定したときにエッジのアーティファクトが目立つようになります。
TimeWarpは現在、姿勢の変化のみを補正しようとしていません。 私たちはモバイルではまだ実際の位置をトラッキングしていませんが、ローテーションに基づいていくつかの目の動きを提供するヘッド/ネックモデルと、ユーザーが明示的に目の原点を移動することを可能にするアプリを使用しています。 これらの値は目の更新の間にまったく変わることはないので、30眼のFPSでは、TimeWarpは各フレームの姿勢をスムーズに更新しますが、動きは他のフレームごとにしか変化しません。
上記の文章は Oculus Mobile SDKに含まれるAsynchronous Timewarpの説明の日本語訳です。