インタラクタブル — MRTK3

MRTK は、Unity の XR Interaction ツールキットによって提供される XRBaseInteractable を基礎としています。 既存のインタラクタブルの動作と API は MRTK で完全にサポートされており、カスタムのインタラクタブルはすべて、既存の XRI Interactable の API に従います。

XRI を初めて使用する開発者には、まず Unity の XRI アーキテクチャに関するドキュメントを確認することを強くお勧めします。

XRI に含まれるインタラクタブルのメカニズムを拡張するために、MRTK では、高度な対話式操作を構築できる 2 つの基本クラスを提供します。1 つがもう 1 つを拡張します。

Interactables inheritance diagram

  • MRTKBaseInteractable : XRBaseInteractable
    • このクラスでは、さまざまな種類のインタラクターに対するフィルター処理とフラグ付けを提供します。 基本の XRI XRBaseInteractable ではインタラクターの種類を区別しませんが、MRTKBaseInteractable では、一般的な種類の対話式操作が発生しているかどうかを確認するための便利な関数が用意されています。 IsGazeHoveredIsGrabSelected などの便利なプロパティは、関係するインタラクターが特定のインターフェイス (対応する IGazeInteractorIGrabInteractor) を実装するかどうかのクエリを実行するためのショートカットです。 これらのフラグでは、interactorsHoveringinteractorsSelecting のリストを反復処理するよりもパフォーマンスが高くなります。 さらに、開発者が特定の入力モダリティを除外する場合は、MRTKBaseInteractable では、特定の種類のインタラクターをフィルター処理または拒否できます。
  • StatefulInteractable : MRTKBaseInteractable
    • MRTKBaseInteractable では、フラグとフィルターを追加し、インタラクタブルに状態をさらに追加しないようにしますが、StatefulInteractable では、切り替えや変数の選択などの便利なステートフル機能が導入されます。

状態とビジュアルの厳密な分離

MRTK 2.x では、多くの場合、インタラクタブルには、3D ボタンの圧縮、ホバー効果、または単なるクリック時の色の変更など、独自の視覚効果を駆動する役割がありました。 このアプローチの制限は、対話式操作のロジックがビジュアルに厳密にバインドされていることです。 ビジュアルを再設計する場合や、異なるサイズ、形状、変位などのボタンを使用する場合は、対話式操作のスクリプト自体を変更する必要があります。

MRTK3 では、インタラクタブルは純粋な状態と対話式操作です。インタラクタブルでは、内部状態に基づく視覚的な変更や効果をレンダリングしません。 これは純粋に、視覚的なプレゼンテーションのセットアップ間で移植性が高い、状態と対話式操作のロジックのコレクションです。

Strict isolation of state and visuals

同じ PressableButton スクリプトを使用して、低反発ボール、押下可能な "トラックパッド"のような平面、押した時にネットワークイベントを発行する抽象的な押下可能なものを構築できます。 PressableButton スクリプトでは、"場所" は気にしません。Canvas 内または Rigidbody 上にある可能性があります。

ビジュアルを駆動するために、別の "ビジュアル ドライバー" を使用して、インタラクタブルから状態をポーリングし、適切なフィードバックをレンダリングします。 StateVisualizer は、対話可能な状態から一般的なビジュアル フィードバック効果を駆動するのに推奨される低コードのメソッドですが、開発者は独自のカスタム ビジュアル ドライバーを自由に記述できます。 たとえば、ボタン コンポーネントでは、通常、高度な 3D とシェーダー ベースのフィードバック効果に StateVisualizer が使用されますが、コード内でシンプルなビジュアル ドライバーを作成する方法を示す例 BasicPressableButtonVisuals も提供されています。

選択、変数

基本の XRI 機能に対する StatefulInteractable の最も便利な追加機能は、変数 Selectedness のサポートです。 基本の XRI Interactable は選択されるか選択されないかのいずれかですが、MRTK の StatefulInteractable では、選択した任意の浮動小数点分数を指定できます。

ほぼすべての形式の入力がバイナリ状態ではなくなったため、この概念は、XR で作業する場合に便利です。 モーション コントローラーには、多くの場合、アナログ トリガー (またはアナログ グリップ) があり、手の対話式操作によって可変の "ピンチ性" が提供され、ボリュメトリックな押す対話式操作では、ボタンやプッシュ可能なサーフェスをさまざまな量で押し下げることができます。 これらの変数、アナログの対話式操作は XR のどこにでも表示され、MRTK は、開発者がこれらのアナログ入力の上に楽しい対話式操作を構築できるように準備されています。

さまざまなインタラクターと対話式操作の種類の範囲が幅広いことは、すべて、インタラクタブルの Selectedness 全体に貢献できます。 特に、IVariableSelectInteractor を実装するすべてのインタラクターは、通常、参加しているすべてのインタラクターの max() を通じて、アナログ選択の量に影響します。 この可変の量を、バニラスタイルのインタラクターからのバイナリの非変数選択と組み合わせます。

PressableButton のような派生クラスの場合、Selectedness() 関数はオーバーライドされ、選択された計算にさらに "成分" が追加されます。 IPokeInteractor を実装するインタラクターでは、物理的な場所と、インタラクタブルで物理的に押し下げている方法に基づいて Selectedness を提供できます。 他の派生クラスでは、他の任意の形式の選択を導入できます。

Variable selectedness

MRTK が提供するインタラクタブルの場合、Selectedness()isSelected は常に「同意します」。つまり、対応する XRI isSelectedinteractorsSelecting 内の付随するインタラクターなしで SelectThreshold より大きい値の Selectedness() を目にすることはありません。

重要

カスタムのインタラクタブルのサブクラスでは、XRI isSelected から完全に切断されている他の値に Selectedness を間違いなくオーバーライドできますが、Microsoft のインタラクタブルではこれを行っておらず、これを行わないことを強くお勧めします。 一般に、対応する インタラクター を持たない対話式操作を書くことはありません。 ほとんどの場合は XRI の選択で十分で、作成するカスタムの対話式操作はインタラクターとして記述する必要があります。

Selectedness() を決定する新しい方法をサポートするカスタムのインタラクタブルを作成する場合は、単にメソッドをオーバーライドし、新しい Selectedness と既存の選択量を組み合わせます。 StateVisualizer、または変数の選択をリッスンするその他のビジュアル レイヤーを使用している場合は、新しい選択の種類に応じて応答します。

UGUI イベントを XRI にマップする

場合によっては、マウス、ゲームパッド、タッチスクリーンの入力などの UGUI イベントにインタラクタブルが応答することが望ましい場合があります。 UGUI Selectable である UGUIInputAdapter は UGUI イベントを受け取り、存在する場合はそれらを CanvasProxyInteractor に転送します。

UGUI adapter flow

UGUIInputAdapter によって UGUI イベントが CanvasProxyInteractor に通知されると、関連するインタラクタブルに対して同等の XRI アクションが発行されます。 UGUI 入力アクションと XRI アクションの間のマッピングは、多少の損失があり、開発中の分野です。

このシステムを使用すると、イマーシブ プラットフォーム、手、モーション コントローラー、3D 入力用に構築された既存の XRI Interactable が、マウスやゲームパッドなどのアクセス可能な 2D コントロールと同等に反応できます。