World Locking Tools の概念
問題
日常の物理的な世界では、空間は、静止座標系によって厳密に規程されています。 静止座標系のモーションレス オブジェクトは、永久に同じ座標を保持します。 特定の構成で配置されたオブジェクトのグループは、その構成を維持します。 同じ速度で移動する 2 つのオブジェクトは、固定されたオフセットを互いに維持します。
これらの法則や同様の法則は、存在の基礎となる部分であり、これらが保持されなくなった場合、世界に対する直感は信頼できなくなります。
以前のソリューション
Unity の "グローバル座標空間" と "空間アンカー" は、センサーの誤りやドリフトによって発生する問題のさまざまな側面に対応します。
Unity のグローバル座標空間は、ホログラフィック オブジェクトが互いに固定された状態を維持する、安定した座標系を提供します。 この空間内のオブジェクトは互いに一貫性を持って動作しますが、物理的な世界との一貫性は保証されず、一般的に提供されることもありません。 一貫性の欠如は、特にユーザーが動き回っているときに発生します。
Unity の空間アンカーは、ユーザーが移動しているときに物理世界でのホログラムの位置を維持できますが、仮想世界内での自己一貫性が犠牲になります。 異なる複数のアンカーが、常に互いに相対的に移動します。 それらはグローバル座標空間の中でも移動するために、配置のような単純なタスクが困難になり、物理的なシミュレーションで問題が発生します。
問題の原因
ここでは HoloLens テクノロジを中心に説明しますが、これらの概念は、特に慣性システムによって強化されたインサイドアウト方式のマーカーレス トラッキング手法に一般的に適用されます。
HoloLens は、その周囲に見える特徴に対して相対的に位置を決定するのに非常に優れています。 拡張機能により、それらの見える同じ特徴に基づいて、他の仮想オブジェクトを配置する能力にも優れています。 ユーザーがほぼ一定の位置に座っているか立っている場合、デバイスは、表示されている物理的な参照ポイントに登録された仮想オブジェクトを維持するのに優れています。 物理的なテーブルに置かれた仮想のコップは、ほとんどの場合、テーブルの表面で同じ位置に置かれます。
このとき、HoloLens はその同じ小さいボリュームに限定され、参照用に一定の表示機能のセットが表示されます。 しかし、他にも興味深いシナリオがあります。
ユーザーが立ち上がって部屋の中を移動したり、場合によっては他の部屋に移動したりするとき、HoloLens は、視界から消える古い特徴と、視界に入ってくる新しい特徴を切り替える必要があります。 実装の詳細については説明しませんが、切り替え中はトラッキングの精度が大幅に低下することがわかります。
コンテキストの単純なシナリオを次に示します。
図
ユーザーはポイント A にいます。見回すと、多くの有効な見える参照特徴があるため、ヘッド トラッキングの品質は非常に高く、配置されたホログラムはそのままになります。
その後、ユーザーは、物理空間を 10 メートル歩いてポイント B に移動します。ただし、移動中のトラッキングは忠実性が低いので、その結果、ユーザーがポイント B に到達した後に、デバイスは 9 メートルだけ移動したことを登録します。 これはわかりやすくするために大きな量にしていますが、このような場合には +-10% の距離エラーが許容されるデバイスの仕様と一致しています。
ポイント B でデバイスが周囲を検知したときに、有効な見える特徴が記録されます。 ポイント B でのホログラムのトラッキングと安定性も優れています。
ユーザーが特定のポイントにいる間は、そのポイントの周囲のものがよく見えます。 しかし、不整合があります。 物理空間内のポイント A と B の間の 10 メートルですが、仮想空間では 9 メートルしかありません。 これは一般的に "スケールの問題" と呼ばれますが、"距離の問題" はより正確である可能性があります。 この問題については、この後で説明します。
シナリオに戻ります。次のアクションとして、ユーザーはポイント A に歩いて戻ります。今度は、トラッキング エラーのために、物理空間で B から A まで 10 m 歩いたときに、仮想空間では最大10.5 m が追加されます。 これは、A から B に行ってまた A まで完全に歩いたときに、加算される距離は 0.0 m になるはずなのに、最大 1.5 m の正味距離が加算されることを意味します。 これは明らかな問題です。 歩く前にポイント A に置かれたホログラムは、現在ポイント A から 1.5 m 離れた位置に表示されています。
ここで空間アンカーが役に立ちます。 歩いて B に戻ってきた後、システムはポイント A に戻ったことを認識しますが、ヘッドの Unity 座標は 1.5 m 変更されています。 ただし、ポイント A のホログラムに空間アンカーがアタッチされている場合、空間アンカーは、"私はポイント A にいて、ヘッドはポイント A にあるが、座標は、ヘッドの座標と 1.5 m 異なっている。 座標を 1.5 m 変更するだけで、もう一度一致させることができる" と認識することができます。ユーザーの左側で 1 m 離れているポイント C の空間アンカーも同じプロセスを経ます。 基本的に、空間アンカーは、ポイント A が Unity 空間内のどこにあるかを常に再定義するので、ヘッドの座標は常に正しくなります。 また、各空間アンカーは、物理的世界での場所に対して個別にこの調整を行います。
Unity 用の World Locking Tools
World Locking Tools は、ユーザーが移動するときに、広げられる空間アンカーの内部提供を続けます。 これにより、フレームごとに、カメラの座標とそれらの空間アンカーが分析されます。 これは、すべての空間アンカーが、ヘッドの座標と一致させるためにいつ 1.5 m 移動するか検出し、"前回ここにいたときと異なる座標にあるヘッドを補正するために、世界のすべてのものの座標を変更する代わりに、単にヘッドの座標を変更しよう" と言います。
これは、物理空間で固定されたままになるように Unity 空間全体で空間アンカーにホログラムをドラッグさせる必要があるのではなく、Unity ワールド空間全体が物理空間にロックされることを意味します。 ホログラムが Unity 空間でモーションレスである場合は、その周囲の物理的な特徴に対して相対的にモーションレスな状態が維持されます。 また、重要な点として、これは周囲の仮想的な特徴に対して相対的に固定されたままです。
これは明らかに、内部ではより複雑になります。 たとえば、空間アンカーの問題は、それらが互いに独立して移動するため、常に互いに一致するとは限らないということです。 基になる FrozenWorld エンジンは、これらの不一致を調整して、最も知覚的に正しいカメラの補正を見つけ出し、フレームごとにそれを実行します。
スケールの問題の再発
ユーザーがポイント A からポイント B まで歩いて、ポイント A に戻った場合、システムには、移動中に発生した誤差を修正するための十分な情報があります。 システムはポイント B がどこにあるかを知らない場合があります (一般的に、ポイント A に対して相対的なポイント B の位置を正確に認識しません) が、それがポイント A であるかどうかは認識しています。 ポイント A に戻ったとき、物事が以前の状態とほぼ同じであると想定します。 そうでない場合は、システムがそのようにすることができます。
では、ポイント B はどうでしょうか。 システムは 10 m の移動を 9 m のみであると考えました。 また、その 9 m が正しいかどうかを知る方法はありません。正しくない場合に、どの程度の相違があるかを知ることもできません。 空間アンカーはここでは役に立ちません。 空間アンカーにはヘッド トラッカーと同じ問題があります。それぞれは、物理的な世界のどこにあるかを (見える特徴に対して相対的に) 認識していますが、1 つの空間アンカーは別の空間アンカーについて何も知りません。 具体的に言うと、空間アンカーは互いにどれだけ離れているか知りません。
これは多くの形式では不便な場合がありますが、オブジェクトまたはオブジェクトの体系のサイズが 1 m より大きい場合、遮断の問題になります。 部屋、建物、机のセット、または車のモデルを考えてみましょう。 空間アンカーは、物理的な世界の特徴を使用して登録されているモデルの 1 つの端を保持できますが、モデルのもう一方の端に達した時点で、重大なエラーが蓄積されている可能性があります。 この場合、もう一方の端は正しく配置されません。 このエラーは、デバイスごとに異なり、また同じデバイスでも実行のたびに異なる場合もあります。
これまでに説明したように、問題の解決に必要な最小限の情報は導入されていません。
World Locking Tools は、スペース ピン API によりこの問題を解決します。これにより、アプリケーションは、物理的な世界とホログラフィック世界に関する十分な情報を提供して、移動距離のエラーを修正することができます。 これにより、大きなホログラムが物理的な世界全体に合わせて表示されるようになります。
基本的なシステムについて
World Locking Tools の概念の概要がわかったので、一歩下がって基本的なシステムを見てみましょう。 基本操作によって提供されるサービスと提供されないサービスについて理解すると、後で高度な概念の適切な使用方法を判断し、これらの高度な手法が特定のアプリケーションに必要かどうかを判断するのに役立ちます。