HoloLensの座標系(Coordinate systems)ドキュメントの日本語訳
MicrosoftのHolographicサイト上にあるHoloLensの座標系のドキュメントを自分の勉強のために翻訳したので一部公開します。利用にあたっての注意事項は文末に記載しています。
目次
座標系について
- 空間座標系について
- 静止座標系について
- 空間アンカー(Spatial anchors)
- 3.1. なぜ、シーンを通じて、一つだけの固定の座標系が使われないのか？
- 3.2. 空間アンカーにおける解決方法
- 3.3. 空間アンカーを用いた永続性
- 3.4. 空間アンカーの共有
- 3.5 最適解
- 従属座標系
- 頭部固定のコンテンツは非推奨
- トラッキングエラーの回避
- 6.1.デバイスが十分なセンサーデータを取得できない場合)
- 6.2.環境の大きな変化によって、トラッキングが正しく動かなくなってしまう場合
- 6.3.時間経過による環境変化によるトラッキングの失敗
- 6.4.空間の誤認識によるトラッキングの失敗)
- 関連ドキュメント
前提として
- 原文になかった文章をわかりやすくするための独自の補足追加は()内に記載しています。
- 各章の見出しに関しては原文を表示し、その後ろに()で訳文を記載しています。
- 個人的に重要と思う要素は流し読みできるように太字にしています。原文はboldになっていません。
- コーディング時にも利用しそうな重要な用語に関しては、原文のまま書いたり、以下のような翻訳を行っています。
| 原文 | 訳文 |
|---|---|
| Coordinate systems | 座標系 |
| Cartesian coordinate systems | 直交座標系(WikiPedia),デカルト座標系 |
| Spatial coordinate systems | 空間座標系 |
| Stationary frame of reference | 静止座標系 |
| Spatial anchors | 空間アンカー ※Unity上のholotoolkitではWorldAnchorsと呼ばれる |
| Attached frame of reference | 従属座標系 |
- 内容はたまに修正する事があるかもしれません。
それではどうぞ。
Coordinate systems(座標系について)
座標系の中核は、現実世界における本当のオブジェクトのようにホログラムが見えたり聞こえたりするように配置する事です。 これは利用者にとって実世界において意味のある場所や向きにホログラムを正確に配置するという事でもあります。
ホログラムを正しい位置と向きに配置したり、視線や手の位置のような要素の利用も含めて、HoloLensではその形状を表現するために様々な座標系を利用しています。
1.Spatial coordinate systems（空間座標系について）
多くの3Dアプリケーションは仮想空間上にオブジェクトの位置や向きを描画するために Cartesian coordinate systems(=直交座標系＝デカルト座標系)を利用しています。この座標系は３つの垂直な軸ををもっています。X,Y,Z軸と呼ばれるものです。
HoloLensにおいて、アプリケーションは仮想空間と現実空間の二つの空間を識別することになります。Windows holographicにおいては、現実空間の座標系をSpatial coordinate systemと呼んでいます。
Spatial coordinate systemでは座標系をメートル単位で表現します。 これは、２単位離れた場所に配置したオブジェクトは２メートル離れた場所に表示されることを意味します。これによって、実世界の単位を利用して簡単にオブジェクトを描画することができます。
一般論として、直交座標系においては右手系と左手系の２種類の座標系が使われることがあります。Windows Hologparicにおける空間座標系においては常に右手系の座標系（注釈あり）が使われます。 これはX軸の＋は右側、Y軸の＋は上側、Z軸の＋は奥側に向かうという意味です。
右手系と左手系どちらの直交座標系においても、X軸の＋は右側、Y軸の＋は上側なのですが、Z軸の＋が奥側か、あなた側（前側）かが異なります。 このことは、あなたの実際の右手と左手の指を使って確認することができます。
(座標系について：原文ではHoloLensは右手系とありますが、Z軸の＋が奥に向かうのは左手系だと思います・・。ちなみにUnityは左手系です。たぶん左手系の誤りだと思うのですが、いったん原文ママの右手系と表記しています。海外だと違うのかな・・)
2.Stationary frame of reference（静止座標系について）
実際の空間におけるホログラムの位置を表現するには、HoloLensデバイスの位置が動きまわっても、変化しない静止した座標系が空間上に必要なります。
そのために、システムは"Stationary frame of reference(静止座標系)"と呼ばれるシンプルな仕組みを提供します。HoloLensの座標系は利用者の周囲の実空間上に、変化せずに安定して位置を特定できる静止座標系 を提供します。
Unityのようなゲームエンジンにおいては、静止座標系はゲームエンジン内の原点座標として定義されます。各種オブジェクトは、この静止座標系 を元にして、位置を正確に配置することができ、実際の空間に配置するときも同じ座標系を用いて表示する場所を決めることができます。
アプリケーションは起動時に一つの静止座標系を生成し、起動後も動作している間はその座標系の中で動作していきます。
(訳者補足：基本的にはアプリ起動時のHololensのカメラの位置が原点となるようです。)
時間が経過していくと、座標系はよりユーザーの空間（環境）を学習していき、空間上の様々な座標や距離を起動時よりもより正確に特定することができるようになる場合があります。従って座標はユーザーがより広いエリアを歩き回ることにより、原点の座標が元の座標から補正（drift）されることがあります。
3.Spatial anchors（空間アンカー）
原点座標のズレを防いで正確なホログラムの位置を空間上の１点上で維持したり、システムがより空間を検知するためにSpatial anchorを用いることができます。
Spatial anchorはシステムが時間を超えて座標の追跡をするための、空間上の重要な座標点のことです。
ある空間アンカーはホログラムを他のアンカーや、参照静止点と関連して、正確な位置に配置するために必要な座標系を持っています。
空間アンカー座標を用いてホログラムを表示すれば、時間を超えて（アプリを終了させた後でも）ホログラムを継続的に正確な位置に表示することができます。
3.1. Why a single rigid coordinate system cannot be used for the whole scene (なぜ、シーンを通じて、一つだけの固定の座標系が使われないのか？)
最近のゲームやデータ可視化アプリ,VRアプリなどにおける、(空間座標を定めるための)典型的な方法は、いろいろなオブジェクトの座標を確実に配置できる、一つの絶対的な空間座標系を確立することです。
そうすれば、その空間上の二つのオブジェクトの位置や大きさの関係性を確実に安定して取得することができます。
あなたがこれらのオブジェクトを動かしたりしない限りは、これらの座標は常に安定した場所に配置されます。
もし、あなたが、完全にバーチャルな空間上への表示を行っている場合は、この絶対的な座標軸を利用することはいい方法でしょう。
それと比較して、Mixed-realityであるHololensでは、動的にセンサーが動作し、継続的に空間認識をしながら、あなたが作成したSpatial Anchorを把握して、現実世界を認識していきます。 その結果、あなたのアプリは時間の経過によって変化する空間上の関係性を把握しながらSpatial Anchorを配置する場所を用意しなくてはなりません。
例えば、ある時点で、デバイスが現実世界上で二つのオブジェクトの位置関係が４メートル離れていると認識したとして、その後、空間認識が進むことによって、実際は3.9メートル離れていると再認識したとします。 単一の固定した座標系が利用されている状態で、ホログラムが最初の時点で４メートル離れた状態で配置されていた場合、どちらか一方のオブジェクトは常に0.1メートル分オフセットされて表示されなくてはいけなくなります。
3.2.The solution: Spatial anchors (Spatial anchorsにおける解決方法)
Hololensでは、この問題を、ユーザが配置したホログラムの場所を重要な座標点としてSpatial anchorを生成させることによって解決します。
デバイスが空間を学習するにつれて、これらのspatial anchorは正確な座標を維持するために他のアンカーとの関係性を必要に応じて調整をしていくことになります。近くの空間アンカーの座標系もとにホログラムを配置することによって、ホログラムの正確な位置を安定的に確定することができます。
この、他アンカーとの関係性を元にした、空間アンカーの継続的な最適化は、空間アンカーと静止座標系の重要な違いです。
静止座標系を用いて配置されたホログラムは、他のホログラムと硬直的な関係性をもって配置されます。しかし、この方法では、時間が経った後に改めてホログラムを表示させた場合などに、ドリフトが発生する場合があります。
ある空間アンカーを用いて配置されたホログラムは、他の空間アンカーを用いたホログラムとの関係性においてドリフトすることがあります。これにより、例えば、ある空間アンカーは左位置の調整が必要で、別のアンカーは右に位置の調整が必要になる場合であっても、システムはそれぞれの空間アンカーの配置位置の補正が可能となります。
静止座標系と比較して、このことはユーザーの周辺における座標の安定的な最適化を行うことができます。これは時間が経過してもホログラムが正確な位置に配置されることに役立ちます。しかし、空間アンカーにおいて ホログラムが増大するレバーアーム効果(lever-arm effects,=応力中心距離の影響)によって、本来の位置から離れた場所に配置される場合がある事もあります。空間アンカーの原点の位置や向きのわずかな変化が、そのアンカーからの距離に比例して(テコの原理のように)拡大していくためです。この問題に対する、経験に基づく、大枠の指針としてはホログラムを空間アンカーの原点から3メートル以内程度に配置する事です。
3.3.Spatial anchor persistence(空間アンカーを用いた永続性 )
空間アンカーはアプリケーションが終了したりサスペンドしたときにでも重要な座標の位置を記憶しておく事にも役立ちます。
あなたのアプリが作成した空間アンカーを、アプリ内で"Spatial anchor store"を用いた永続化をすることによりディスクに保存しておく事で、後でそれを読み込んで復元する事ができます。
空間アンカーを一意に識別するために、アンカーをセーブ・ロードする際にアプリ内において一意の意味を持つキーとなる文字列を使います。 このキーはあなたの空間アンカーのファイル名になると考えてください。 その空間アンカーをその場所に表示したい3Dモデルなどと関連付けたい場合、あなたのアプリのローカルストレージにあなたの選んだキーと紐付けてセーブを行ってください。
アンカーストアを用いて永続化する事により、アプリの利用者はホログラムやワークスペースを配置した後に、時間が経ったり、いろいろな人が見ても、ホログラムが期待された場所に表示される事を確認できます。
3.4.Spatial anchor sharing(空間アンカーの共有 )
アプリケーションは空間アンカーを他のデバイスと共有する事もできます。 他のHololensに認識した空間と周囲のセンサーデータに加えて空間アンカーを転送する事により、両方のHoloLensは同じ場所に存在していると認識する事ができます。
共有された空間アンカーを用いてホログラムを表示する事により、両方のユーザーを実際の空間の同じ場所にホログラムが表示されている事を確認できるでしょう。
3.5.Best practices(最適解 )
静止座標系ではなく、空間アンカーを正しく利用するためのガイドラインとして、Spatial anchors best practices ページ(原文)を確認してください。
4. Attached frame of reference (従属座標系)
(メニューUIを表示する場合など)ホログラムをユーザーの頭部から一定の距離を保って浮遊した状態で常に表示するように設計したい場合があるでしょう。
この場合、ホログラムを "attached frame of reference(従属座標系)" としてユーザーが歩き回るのに合わせて移動するように配置する事ができます。
把握してくべき重要な事の一つは、 「従属座標系」は最初に生成された時に定義された固定された向きを持つことになります。
「従属座標系」はユーザーの頭部や体の向きが変わっても(相対的な座標の)向きが変わる事はありません。それにより、ユーザーは 「従属座標系」のおかげで、空間を歩き回ってもどこを向いていても、配置されたホログラムを持ち歩いているように、快適に閲覧する事ができます。
このようにユーザーとの関係性を用いて表示されるコンテンツは'body-locked' コンテンツと呼ばれるものです。
たとえデバイスが空間上でどこにいるか認識できなくても、この従属座標系を用いたホログラムは表示をする事ができます。この機能はユーザーが空間を認識できなかった場合に表示するフォールバックUI(縮退動作時のUI)として有効です。 すべてのアプリケーションはユーザーに対してこのような場合に、holographic shell(Hololensのデスクトップ環境)に誘導するなどのフォールバック機能を含めるべきです。
5. Head-locked content（頭部固定のコンテンツは非推奨）
私たちは、HMDに対して固定の位置に表示されるようなhead-lockedコンテンツを表示する事を推奨しません。一般的にhead-lockedコンテンツはユーザーを不快にし、現実世界に馴染むものではありません。
Head-lockedコンテンツは現実世界に固定配置されるか、ユーザーに追従するコンテンツに置き換えられるべきです。 例えばカーソルなどは現実世界の中でユーザーが注視している場所や位置に自然な大きさで表示されるようにするべきです。
6.Handling tracking errors (トラッキングエラーの回避)
ある環境においては、現実世界の正しい位置を把握できない可能性があります。この状態ではホログラムが表示されなかったり、正しい位置ではない場所に表示されることがあるかもしれません。
このような事が起きた場合にユーザー体験にどのような影響を与え、どのようにリカバーするべきかに関して、以下に記載してみます。
6.1.Device cannot track due to insufficient sensor data. (デバイスが十分なセンサーデータを取得できない場合)
時々デバイスのセンサーが自分がどこにいるか判断できない時があります。これは部屋が暗すぎる場合や、センサーが手や髪の毛で隠れてしまっている時に発生する事があります。もしくは、周辺の環境が十分なテクスチャを持っていない場合にも発生します。
こうなった場合、デバイスは現実世界に対して正しい位置にホログラムを配置したり自分の位置をトラッキングする事ができないかもしれません。 そのような時、空間アンカーや静止座標系を見つける事ができないでしょう。それでもbody-lockedコンテンツは表示する事ができます。
アプリケーション内において、どうすれば位置トラッキングを復旧させられるか、例えば「部屋を明るくしてください」や「センサーを隠さないでください」などのヒントになるような説明を、body-lockedコンテンツを用いたフォールバックを表示させるべきです。
6.2.Device tracks incorrectly due to dynamic changes in the environment.(環境の大きな変化によって、トラッキングが正しく動かなくなってしまう場合)
空間の環境が急激に変化した場合などに、トラッキングができなくなってしまう場合があります。例えば、部屋の中を多くの人が歩き回っている場合などです。
このような場合、デバイスが環境の変化を自ら検知しようとして、ホログラムの表示位置がジャンプしたりドリフトすることがあります。 このようなケースにあなたの状況がある場合は、変化の少ない環境でデバイスを利用する事をお勧めします。
6.3.Device tracks incorrectly because the environment has changed significantly over time(時間経過による環境変化によるトラッキングの失敗)
部屋の家具の配置や、壁に飾っているものが移動するなどして、環境が変化してしまった後にデバイスを利用する事があるかもしれません。
このような場合、ホログラムは元々の本来の位置からずれた場所に表示される可能性があります。 新しいスペースにユーザーが移動した時などに、最初に表示されるホログラムも表示位置がジャンプするかもしれません。これは、デバイスが認識している空間情報が維持できなくなり、ホログラムの表示位置を調整しながら 環境の再認識を行おうとしている事が原因です。
このような場合、もともと表示されているホログラムを一度削除するのが良いかもしれません。もし新たに配置したホログラムがそれでも移動したりジャンプしてしまう場合は、利用者にデバイス内の現在のスペース情報を削除するように伝えるようにしてください。 これはデバイスの Setting > System > Spacesから行う事ができます。
スペースを削除する事は、表示されているすべてのホログラムをすべて失ってしまう事も覚えておいてください。
6.4.Device tracks incorrectly due to identical spaces in an environment (空間の誤認識によるトラッキングの失敗)
独立した異なるSpaceが、同一の場所を記憶している場合もあります。 例えば、家の中に二つの独立した同じような部屋があって、同じようなコーナーエリアと大きなポスターがデバイスが認識できる範囲にあるとします。このような場合、デバイスは同じスペースとして認識することで混乱してしまう事があります。このような時、ホログラムが本来の場所と異なる場所に表示されてしまう原因となります。デバイス内部における空間認識表現が壊れてしまい、トラッキングができなくなってしまうことでしょう。
このような場合、デバイスの Setting > System > Spacesから現在のスペース情報を一度削除するのがよいでしょう。これによってデバイスは環境を別のものとして正常に認識できるかもしれません。ただし、この問題はまた独立した空間を誤って認識する事で再発するかもしれません。
7.See also(関連ドキュメント)
- World anchor in Unity(英語)
- Coordinate systems in DirectX(英語)
- Shared spatial anchors in DirectX(英語)
- Case study - Looking through holes in your reality(英語)
ご利用時の注意事項など
- 内容の正確さは保証するものではありません。原文も是非参照してください。
- また内容に関して誤りや最適訳などの提案があったら是非ご指摘いただけると助かります。
- 無断での全文転載などはご遠慮ください。事前に必ず連絡をお願いいたします。一部引用などはかまいません。うるさく言うつもりはないのですが、ひとまずそうさせてもらいます。
- 他のドキュメントなども、興味のあるものから翻訳しようかなぁとも考えていますが、協力していただける方がもしいたら、githubなどに移して進めるのも良いかななどとも考えています。
