Share via

例外条件の処理

  • [アーティクル]

WLT は、ほとんどの場合、追跡エラーを検出すると、アプリケーションを経由せず、メッセージを表示することなく修正します。

ただし、一部の例外的な条件では、アプリケーションによる調整が必要な場合があるエラーが発生します。

追跡の停止は、このような状態の例です。

追跡は、さまざまな理由で失われる可能性が常にあります。 センサーが覆われていたり、照明が不十分であったり、カメラの周囲に追跡に利用できる視覚的特徴がなかったりする場合があります。

それらを軽減することを目的とした WLT の機能を含む、概念レベルでのこれらの例外的な条件の詳細については、このドキュメントの他の箇所で説明しています。

ここでは、アプリケーション開発者がこれらの機能を (任意で) 利用して、これらの例外的な状況でのアプリケーションの動作をカスタマイズする方法について詳しく説明します。

AttachmentPoints

ここでさらに詳しく説明するように、アタッチメント ポイントは WLT とアプリケーションの間のコントラクトで、例外的な状態が発生したことを通知するためのものであり、アプリケーションが応答に使用する適切なデータも含まれます。

アジャスター コンポーネント

このようなアプリケーションの応答の実装は、「アジャスター」コンポーネントの形式で利用できます。 それらの主なものは、AdjusterFixed コンポーネントです。

AdjusterFixed はそのまま使用できますが、このコンポーネントが何をするのかを理解することは、特に動作をさらにカスタマイズすることを望む開発者にとって有益な可能性があります。

Adjuster コンポーネントは次の 2 つの役割を果たしていることを認識することが重要です。

  1. 基になる AttachmentPoint を管理する。
  2. 例外的な条件に対するアプリケーションの応答の実装を提供する。

AttachmentPoint の管理

Start() および OnDestroy() メンバーを調べると、必要な AttachmentPoint の管理のほとんどをキャプチャできます。

Start() で、基になる AttachmentPoint が作成され、 AdjusterFixed のメンバー関数がコールバックとして提供されます (下記参照)。

OnDestroy() では、これらのコールバック接続が切断され、AttachmentPoint が解放されます。

条件処理コールバック

2 つのコールバックによって、このような例外的な状況でのアプリケーションの望ましい動作が実装されます。

追跡状態の処理

HandleStateAdjust() では、AdjusterFixed コンポーネントは、現在追跡されていないフラグメントに含まれるオブジェクトを無効にします。

        protected virtual void HandleAdjustState(AttachmentPointStateType state)
        {
            bool visible = state == AttachmentPointStateType.Normal;
            if (visible != gameObject.activeSelf)
            {
                gameObject.SetActive(visible);
            }
        }

この単純な動作は多くのアプリケーションに最適ですが、それだけでは十分でないことは容易に想像できます。

  1. オブジェクトは非表示にする必要がありますが、無効にはしないでください (更新を続行する必要があります)。
  2. オブジェクトを非表示にする別の方法が推奨されます (遠いクリッピング平面を超えてオブジェクトを移動するなど)。
  3. オブジェクトを非表示にするのではなく、別のマテリアル (X-ray マテリアルなど) でレンダリングする必要があります。
  4. オブジェクトを非表示にするのではなく、代替オブジェクトをレンダリングする必要があります。
  5. など

幸いなことに、アプリケーション開発者は、このような動作や、想像によってのみ制限される他の動作を自由に実装できます。

カスタム動作を指定する最も簡単な方法は、AdjusterFixed から派生したカスタム コンポーネントを実装することです。 その後、AttachmentPoint 管理を継承し、ハンドラーをオーバーライドしてカスタム動作を作成できます。

位置変更の処理

概念に関するドキュメントで説明されているように、WLT システムでは、オブジェクトを Frozen スペースに再配置することで、オブジェクトを物理的な世界の所定の位置に保持することが最適であると判断する場合があります。 その場合、AttachmentPoint メカニズムを介して、その状況をアプリケーションに通知します。

当然のことながら、アプリケーションはそのような調整を無視できます。 ただし、AdjusterFixed (および AdjusterMoving) コンポーネントによって提供される動作は、その位置変更変換をすぐに適用することです。

        protected virtual void HandleAdjustLocation(Pose adjustment)
        {
            Pose pose = gameObject.transform.GetGlobalPose();
            pose = adjustment.Multiply(pose);
            gameObject.transform.SetGlobalPose(pose);
        }

ほとんどの場合、アプリケーションはこれを望んでいます。 次に、誰かが AdjusterFixed の HandlePositionAdjust() 関数をオーバーライドする理由に関する疑問が生まれる可能性があります。

その答えは、アプリケーションが、位置の修正以外に、他のアクションを実行する必要がある場合があるということです。 一時的なマテリアルの影響は、変更が行われたことをユーザーに通知するのに役立つ可能性があります。 位置変更は数秒で展開される可能性があります。 または、位置変更の規模が大きすぎる場合、アプリケーションはオブジェクトを移動するのではなく、破棄しようとする場合があります。

AdjusterFixed と AdjusterMoving

AdjusterMoving コンポーネントを詳しく見ると、それが派生した AdjusterFixed コンポーネントとほぼ同じであることがわかります。

2 つのコンポーネントの違いは、AdjusterMoving では、ターゲットが常に環境を移動していることが前提となっていることです。 このため、更新するたびに、WLT システムに新しいポーズが通知されます。

AdjusterMoving のコストは、Update（） 関数内で行われる作業ではなく、主に関数が追加されることで発生します。 ただし、「ほとんど」静止していて、スクリプトからの移動が少ないオブジェクトの場合は、AdjusterFixed コンポーネントを使用して、オブジェクトが移動されるたびに AdjusterFixed.UpdatePosition() を呼び出すと便利な場合があります。

動作をカスタマイズする (必要な場合のみ)

繰り返しになりますが、ここでのパターンは、World Locking Tools 全体で一貫していることが期待されます。 WLT は、単純ですが、一般的に有用なベースライン動作を提供します。 この実装によって、次のいずれかが実現することが期待されます。

  1. アプリケーションのニーズを満たす。
  2. 強化できるベースライン実装を提供する。
  3. 使用しやすいサンプル実装を提供する。

関連項目