スペース ピン
解決する問題
スケール エラー
ホログラムを現実世界の特徴と一致させる従来の空間アンカー アプローチは、小さなスケールではうまく機能しますが、スケールが拡大して 1 m 以上の範囲になるにつれて困難になります。
頭部トラッキング空間のスケール エラーは、空間アンカーが、わずか数メートルの長さの仮想オブジェクトの一方の端を現実世界の特徴と完全に一致させている場合でも、もう一方の端が対応する現実世界の特徴と一致していない可能性があることを意味します。 この不一致は、頭部トラッキング空間を移動した距離が、物理空間を移動した距離と異なる傾向があり、+-10% の誤差の範囲があるために発生します。 多くの場合、実際のエラーは、これより少なくなりますが (多くの環境とデバイスの特性に依存します)、一般的に重要であり、プロジェクトのスケールが大きくなるにつれて際限なく大きくなります。
別の言い方をすると、HoloLens を身に着けているユーザーが現実世界で 10 m 歩いた場合、頭部トラッカーによって報告される仮想空間内の移動距離は、9 m から 11 m の間になります。 ユーザーが 50 m 歩いた場合、エラーは +-5 m に増加します。 ユーザーが歩く距離が長くなるにつれて、エラーが大きくなります。
したがって、現実空間で一方の端がメジャーの端に完全に位置合わせされた 10 m のビーム (モデリング空間内) の場合、もう一方の端は 9 〜 11 m のどこかでメジャーに登録されます。
同じ理由から、空間アンカーを使用してロックされた各世界の複数のオブジェクトは、仮想空間では現実空間とは異なる距離になります。
任意の座標系
もう一つの懸念事項があります。 HoloLens の Unity 座標系は不確定です。 これは、アプリケーションの開始時点での頭部のポーズのみに基づいて設定されます。
この任意性は、多くのタスクでは問題ではありません。 部屋の空間マッピングに光線を照射し、それが当たった位置にホログラムを配置することが目的である場合、当たった位置の数値は関係ありません。
同様に、ユーザーの周囲に UX 要素を出現させる場合、UX 要素を配置するための絶対座標は重要ではなく、ユーザーに対して相対的な座標のみが重要です。
ただし、より複雑なシナリオでは、予測できない座標系によって複雑になる可能性があります。 オブジェクトの大規模なコレクション (ユーザーの机やオフィス全体など) を物理空間に固定された関係を持つ仮想空間に読み込むには、モデリング空間オブジェクトを頭部ベースの座標フレームに合わせて調整するためのある程度の補正変換が必要です。
多くの場合、この補正は、すべてのオブジェクトを 1 つの Unity 変換にアタッチし、その 1 つの変換を調整して、現実世界に合わせて仮想オブジェクトの位置と方向を設定することで行います。
同様に、カメラの階層内の 1 つの変換を使用してカメラを調整できるので、ユーザーが現実世界の参照ポイントを見ているときに、目的のモデリング座標を持つ仮想オブジェクトが、その見ている特徴に重ねて表示されます。
解決策
スペース ピン留め機能は、これらの問題の両方を一度に解決します。 これは、ワールド ロック ツールのグローバル空間のロックされた世界の性質と、その空間の任意性の両方を活用することで行います。
Unity 空間を現実世界に合わせる
その中心にあるワールド ロック ツールは、安定したワールド ロック座標系を提供します。 仮想オブジェクトが現実世界の特徴に登録されて、ワールド ロック空間に配置された場合、そのオブジェクトは時間が経過してもその現実世界の特徴に登録されたままになります。
しかし、その目標を満たすスペースは無限に存在します。 実際、1 つのワールドロック空間がある場合、任意の位置と回転で変換すると、同じように有効なワールド ロック空間が作成されます。
スペース ピン機能は、ワールド ロック変換の不確定な性質を取り除く別の制約を適用します。
この制約は、スペース ピンの "近く" にあるときに、ワールド ロック空間内のスペース ピンのポーズは、モデリング空間内のスペース ピンのポーズと同じになるという制約です。
グローバル座標 (0, 0, 1) でモデル化された Unity シーン内の立方体について考えてみます。 シーンが HoloLens に読み込まれるとき、立方体は最初の頭部ポーズの 1 m 前に表示されます。 最初の頭部のポーズに応じて、それは物理的な部屋のどこかにあります。
スペース ピンを使用すると、その立方体を、たとえば特定の机の隅といった現実世界の部屋の特徴にロックできます。 空間アンカーを使用してキューブをロックする場合とは異なり、スペース ピンは、キューブが机の隅に位置合わせされるように Unity 空間全体を移動します。 そのため、たとえば、Unity で立方体に対して相対的にモデル化された他の机上のアイテムは、実際の机上全体に適切に配置されます。
スケール エラーに対処する
1 つのスペース ピンでは、仮想座標と現実世界の間の関係の不確定性が解消されますが、スケール エラーには対処されません。
つまり、原点を物理的な世界の位置と方向に合わせて移動した場合でも、現実世界で 10 m 歩いたときに、仮想空間ではユーザーが 9 m しか移動できない可能性があります。
この場合、複数のスペース ピンによって完全に解決できます。 ユーザーが特定のスペース ピンの近くにいる場合は、世界はそのスペース ピンに従って整列されます。 他のスペース ピンは、正しく配置されませんが、離れた場所にあるため、一般的に認識できないので許容可能であるとみなします。
ユーザーがスペース ピン間を移動すると、スムーズな補間により、空間内の任意のポイントでスケール エラーが最小化されます。 適切な密度のスペース ピンを参照ポイントとして使用することで、現実世界と仮想の特徴の不整合が頭部トラッキング エラーの程度まで減少します。
スペース ピンの必要な密度は、環境がサポートするトラッキング品質とアプリケーションの精度要件の両方に依存しますが、ここで示すいくつかの数値は予想を設定するのに役立つ場合があります。 十分な照明とトラッキング可能な見える特徴を備えたオフィス環境では、スペース ピン間の間隔が 10 m であれば、10 m 以上で 10 ～ 20 cm 蓄積されるエラーが、ミリメートルのエラー (最大エラー 0.5cm、エンドポイントで0.0 cm) まで低下します。
永続化
スペース ピン機能は、ワールド ロック ツールの残りの部分である永続化と連携して機能します。 スクリプトからの保存と読み込みを呼び出すための手動呼び出しと、セッションごとの自動的な保存と読み込みのフラグの両方があります。
ワールド ロック ツール マネージャーの AutoSave/AutoLoad 機能を有効にした場合、仮想世界と現実世界の完全な空間配置を後続のセッションで復元できます。
実際には、永続化とは、1 つまたは少ない数の暫定セッションを使用して、物理環境の適切なスキャンを確立し、その物理環境を Unity のモデリング座標空間と一致させることを意味します。 その後のセッションでは、それ以上のユーザーの操作を行わなくとも、現実世界に正しく一致した仮想環境が読み込まれます。
補間と捕外
補間と捕外は、どちらも、直接測定が行われていないデータ値を推定するための手法です。 これまでに説明したように、スペース ピンは、測定が行われた場所です。 仮想座標は目的の座標であり、物理座標は、それらの仮想座標を表示する測定された座標です。
以下で説明するように、システムは補間を実行しますが、捕外は実行しません。 一般的に、補間は捕外よりも安全で安定しています。 提供される部分線形補間は、ほとんどのアプリケーションのニーズを満たします。 捕外は安全性が低く、理想的な実装には通常、アプリケーション レベルでの知識が必要です。 したがって、以下で説明するように、捕外はアプリケーションで処理する必要があります。
アプリケーションが捕外ピンを追加しない場合、ピンの境界の外側では、空間は最も近い境界の値によって排他的にピン留めされます。 ピンが A と B の 2 つしか存在しない場合、ユーザーが A から B に移動すると、A で指定された配置と B で指定された配置の間でピン留めがブレンドされます (補間)。 ただし、ユーザーが B を渡した場合、ピン留めは B で指定された配置に正確に固定されます (定数拡張)。
補間
ピン間の 2D 領域では、空間ローカライズが線形補間されます。 スペース ピンが正確に配置され、トラッキング エラーが領域に均等に分散されている場合、スペース ピン間に適用される修正は正確に正しくなります。
ここでは、均等なエラーの分散という想定は正確には正しくないことを強調しておく必要があります。 ただし、近似として、線形モデルは優れた修正結果を提供します。
捕外
システムは、スペース ピンの凸包の外側にある定数値拡張を使用して組み込みの捕外サービスを提供することはありません。 この近似は、アプリケーションが提供するスペース ピンの外側にスケール エラーが発生しないと仮定すること (当然ながら誤り) と同じです。
ただし、アプリケーションがエラー分布に関する知識を持っている場合、または推定値で十分な場合は、周囲にスペース ピンを追加することで、必要な捕外を作成できます。
捕外の例
シーンに 4 つのスペース ピンがあり、端が 4 m の長さの正方形に配置されているとします。
ここで、ユーザーが移動する実際の空間は 12 m x 12 m で、空間の中心を囲む 4 つのピンに対応する物理マーカーを使用するとします。
アプリケーションが一定のエラーの近似値で十分である場合は、12 x 12 m の空間全体をカバーするために 4 つ以上のスペース ピンを追加するために必要なすべての情報が含まれています。
4 x 4 の正方形の角にあるピンに、主な方角 (NE、NW、SW、SE.) のラベルを付けます。 また、各ポイントで仮想位置にも virtualNE などのラベルを付け、各ポイントの物理位置に physicalNE などのラベルを付けます。
1 つの戦略は、4 つの基点 (outerNE、outerNW、outerSW、outerSE) を追加して、内側の正方形を囲む 12 m x 12 m の正方形を作成する外側の基点を追加することです。 これらの各仮想位置と物理位置は、計算が簡単です。 次に outerNE の例を示します。
virtualOuterNE = virtualNE + (virtualNE - virtualSW);
physicalOuterNE = physicalNE + (physicalNE - virtualSW);
20 x 20 m の外側の空間を作成するには、適用されるデルタのスケールを変更するだけです。
scale = (outerSize - innerSize) / innerSize / 2;
virtualOuterNE = virtualNE + (virtualNE - virtualSW) * scale;
physicalOuterNE = physicalNE + (physicalNE - virtualSW) * scale;
outerSize が 20 m、innerSize が 4 m の場合、スケールは 2 です。
別の戦略として、次に示すように、角に加えて 8 つのポイントを追加する方法があります。 既存のピン位置からの新しいピン位置の計算は、上記とまったく同じです。 通常、ピンを追加すると安定性が向上しますが、精度が向上するとは限らない点に注意してください。
シーンのサブセットの位置合わせ
ここまでの説明は、WorldLockingManager.GetInstance() によって所有および管理されているグローバル AlignmentManager に関連しています。 前に説明したように、これにより、グローバル Unity 座標空間全体が戦略的な参照ポイントで物理的な特徴にピン留めされます。
ただし、同じ概念をシーンのサブセットに適用する場合があります。
たとえば、2 台の自動車の注釈を読み込むシナリオを考えてみましょう。 2 台の物理的な自動車の正確な配置は、販売店ごとのレイアウトによって異なる可能性があるので、事前に知ることはできません。 ただし、物理的な車両の 1台が導入された後には、その導入ポーズに対して相対的なすべてのコンポーネント パーツの位置が分かります。
このシナリオでは、スペース ピンを使用して、各車両の仮想的なシャーシと注釈を個別にピン留めすることができます。 各車両の仮想表現全体を Unity でセットアップし、実行時に物理的な車両にマップすることができます。 この配置は、MRTK UX を使用して手動で行うことも、QR コードやその他の戦略を使用して自動化することもできます。 仮想参照ポイントと物理参照ポイントの間のデータの対応がどのように決定されるかに関係なく、スペース ピン API を使用して WLT に供給されると、WLT は、知覚的に最適化された方法で、仮想オブジェクトと物理オブジェクトを位置合わせします。
グローバル座標空間を配置する場合は、調整ノード (通常はカメラの親の親) を操作することによって配置を行います。 そのノードは、WLT の使用のために予約されていると見なされます。 その変換よってそれ以外の改ざんを行うと、未定義の動作が発生します。
同様に、サブツリーを配置する場合、配置は、配置するサブツリーの (サブ) ルートで変換を所有する必要があります。 その変換よって外部の改ざんを行うと、未定義の動作が発生します。
独立した空間がピン留めされる場合、その前のグローバル空間がピン留めされている間にそれらがドラッグされます。 ただし、独立した空間がピン留めされると、物理的な世界にピン留めされていると見なされます。そのため、その後に、グローバル空間の物理的世界へのピン留めを変更しても影響はありません。