インタラクタブル — MRTK3
MRTK は、Unity の XR Interaction ツールキットによって提供される XRBaseInteractable
を基礎としています。 既存のインタラクタブルの動作と API は MRTK で完全にサポートされており、カスタムのインタラクタブルはすべて、既存の XRI Interactable の API に従います。
XRI を初めて使用する開発者には、まず Unity の XRI アーキテクチャに関するドキュメントを確認することを強くお勧めします。
XRI に含まれるインタラクタブルのメカニズムを拡張するために、MRTK では、高度な対話式操作を構築できる 2 つの基本クラスを提供します。1 つがもう 1 つを拡張します。
MRTKBaseInteractable : XRBaseInteractable
- このクラスでは、さまざまな種類のインタラクターに対するフィルター処理とフラグ付けを提供します。 基本の XRI
XRBaseInteractable
ではインタラクターの種類を区別しませんが、MRTKBaseInteractable
では、一般的な種類の対話式操作が発生しているかどうかを確認するための便利な関数が用意されています。IsGazeHovered
やIsGrabSelected
などの便利なプロパティは、関係するインタラクターが特定のインターフェイス (対応するIGazeInteractor
やIGrabInteractor
) を実装するかどうかのクエリを実行するためのショートカットです。 これらのフラグでは、interactorsHovering
やinteractorsSelecting
のリストを反復処理するよりもパフォーマンスが高くなります。 さらに、開発者が特定の入力モダリティを除外する場合は、MRTKBaseInteractable
では、特定の種類のインタラクターをフィルター処理または拒否できます。
- このクラスでは、さまざまな種類のインタラクターに対するフィルター処理とフラグ付けを提供します。 基本の XRI
StatefulInteractable : MRTKBaseInteractable
-
MRTKBaseInteractable
では、フラグとフィルターを追加し、インタラクタブルに状態をさらに追加しないようにしますが、StatefulInteractable
では、切り替えや変数の選択などの便利なステートフル機能が導入されます。
-
状態とビジュアルの厳密な分離
MRTK 2.x では、多くの場合、インタラクタブルには、3D ボタンの圧縮、ホバー効果、または単なるクリック時の色の変更など、独自の視覚効果を駆動する役割がありました。 このアプローチの制限は、対話式操作のロジックがビジュアルに厳密にバインドされていることです。 ビジュアルを再設計する場合や、異なるサイズ、形状、変位などのボタンを使用する場合は、対話式操作のスクリプト自体を変更する必要があります。
MRTK3 では、インタラクタブルは純粋な状態と対話式操作です。インタラクタブルでは、内部状態に基づく視覚的な変更や効果をレンダリングしません。 これは純粋に、視覚的なプレゼンテーションのセットアップ間で移植性が高い、状態と対話式操作のロジックのコレクションです。
同じ 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 を提供できます。 他の派生クラスでは、他の任意の形式の選択を導入できます。
MRTK が提供するインタラクタブルの場合、Selectedness()
と isSelected
は常に「同意します」。つまり、対応する XRI isSelected
と interactorsSelecting
内の付随するインタラクターなしで SelectThreshold
より大きい値の Selectedness()
を目にすることはありません。
重要
カスタムのインタラクタブルのサブクラスでは、XRI isSelected
から完全に切断されている他の値に Selectedness
を間違いなくオーバーライドできますが、Microsoft のインタラクタブルではこれを行っておらず、これを行わないことを強くお勧めします。 一般に、対応する インタラクター を持たない対話式操作を書くことはありません。 ほとんどの場合は XRI の選択で十分で、作成するカスタムの対話式操作はインタラクターとして記述する必要があります。
Selectedness()
を決定する新しい方法をサポートするカスタムのインタラクタブルを作成する場合は、単にメソッドをオーバーライドし、新しい Selectedness と既存の選択量を組み合わせます。
StateVisualizer
、または変数の選択をリッスンするその他のビジュアル レイヤーを使用している場合は、新しい選択の種類に応じて応答します。
UGUI イベントを XRI にマップする
場合によっては、マウス、ゲームパッド、タッチスクリーンの入力などの UGUI イベントにインタラクタブルが応答することが望ましい場合があります。 UGUI Selectable
である UGUIInputAdapter
は UGUI イベントを受け取り、存在する場合はそれらを CanvasProxyInteractor
に転送します。
UGUIInputAdapter
によって UGUI イベントが CanvasProxyInteractor
に通知されると、関連するインタラクタブルに対して同等の XRI アクションが発行されます。 UGUI 入力アクションと XRI アクションの間のマッピングは、多少の損失があり、開発中の分野です。
このシステムを使用すると、イマーシブ プラットフォーム、手、モーション コントローラー、3D 入力用に構築された既存の XRI Interactable が、マウスやゲームパッドなどのアクセス可能な 2D コントロールと同等に反応できます。