Architecture de l’interacteur — MRTK3

MRTK s’appuie sur l’ensemble d’interacteurs proposés par XR Interaction Toolkit d’Unity. Les fonctionnalités de réalité mixte comme le suivi de la main articulée, le regard et le pincement nécessitent des interacteurs plus élaborés que l’ensemble fourni avec XRI par défaut. MRTK définit de nouvelles interfaces d’interacteur, classées généralement par la modalité d’entrée et les implémentations correspondantes.

Résumé et révision

Pour les développeurs qui débutent avec XRI, nous vous recommandons de consulter d’abord la documentation sur l’architecture XRI d’Unity. Les interacteurs MRTK sont des sous-classes d’interacteurs XRI existants ou des implémentations des interfaces d’interacteur XRI. Consultez la documentation d’Unity sur leur architecture d’interacteur qui s’applique également à MRTK.

Bons citoyens de XRI

Les interacteurs MRTK personnalisés se comportent bien par rapport aux interfaces d’interacteur XRI par défaut ; du point de vue des systèmes XRI, ils sont indisctinguishables des interacteurs « vanille ». L’inverse est également vrai ; Lors de la création d’interactables avancés dans MRTK, les interacteurs XRI par défaut fonctionnent toujours pour le pointage et la sélection de base. Cela fait partie de l’effort MRTK d’être entièrement compatible avec les projets XRI existants. Si vous disposez d’une application XRI, les interactions MRTK et les contrôles d’interface utilisateur fonctionnent avec votre configuration XRI « vanille » existante.

Abstraction de la modalité d’entrée

Le périphérique d’entrée, l’interacteur effectuant l’interaction et les événements d’interaction qu’ils génèrent sont tous isolés de manière architecturale dans XRI. Cette isolation est essentielle pour la stratégie d’abstraction d’entrée dans MRTK3 et nous permet d’écrire des interactions multiplateformes et inter-appareils qui fonctionnent bien dans tous les contextes.

À partir de MRTK v2, il existe un instinct courant pour les interactions de code spécifiques à un type d’entrée ou à un appareil particulier. De nombreux développeurs sont habitués à écrire des interactions qui réagissent spécifiquement à une capture proche, à un rayon lointain ou à un autre type d’entrée spécifique.

Bien que MRTK3 permette toujours de lever l’ambiguïté et de détecter des modes d’entrée individuels, le codage en dur des interactions vers des types d’entrée individuels spécifiques limite artificiellement et réduit la flexibilité de vos interactions. Vous trouverez plus d’informations à ce sujet dans la documentation sur l’architecture interactive, mais la clé pour les interacteurs est qu’ils n’ont généralement pas besoin de mapper 1:1 avec des périphériques d’entrée.

AttachTransform et inversion du contrôle

Une grande partie de ce que MRTK v2 a fait dans les « logiques de déplacement » dans le cadre de ObjectManipulator, Slideret ainsi de suite, est maintenant la responsabilité de l’interacteur lui-même. L’interacteur contrôle désormais son attachTransform pour définir le comportement d’un type spécifique de manipulation. Il n’est plus nécessaire d’écrire une logique d’interaction complexe sur l’interactable qui diffère entre les modalités d’entrée ; au lieu de cela, votre logique de manipulation unifiée peut écouter la attachTransformpose de , quelle que soit la modalité d’entrée ou l’appareil qui la pilote.

Par exemple, un GrabInteractorest attachTransform situé au point d’accaparement de la main/du contrôleur. Un XRRayInteractorest attachTransform situé au point d’accès à l’extrémité du rayon. Le CanvasProxyInteractorest attachTransform situé partout où la souris a cliqué. Pour tous ces différents interacteurs, l’interactable n’a pas à se soucier du type d’interacteur afin de répondre de manière appropriée aux manipulations.

Les requêtes attachTransform interactives et peuvent traiter tous les attachTransform mêmes, quel que soit le type d’interacteur.

Cette approche est essentielle pour la compatibilité avec les interacteurs XRI existants, ainsi que pour assurer la pérenne de vos interactions pour les modalités d’entrée qui n’ont pas encore été développées. Si une nouvelle méthode d’entrée est introduite, vous n’avez pas besoin de modifier les interactables existants si le nouvel interacteur génère un valide et bien comportementé attachTransform.

Ainsi, philosophiquement, le attachTransformest la logique d’interaction. Pour toutes les interactions personnalisées, privilégiez toujours l’écriture d’un nouvel interacteur avec une nouvelle attachTransform logique plutôt que de réécrire ou d’étendre les interactables à personnaliser pour votre nouvelle interaction. De cette façon, tous les éléments interactables existants peuvent profiter des avantages de votre nouvelle interaction au lieu de ceux que vous avez réécrits ou étendus.

XRControllers et liaison d’entrée

La plupart des interacteurs ne se lient pas directement aux actions d’entrée. La plupart dérivent de XRBaseControllerInteractor, ce qui nécessite un au-dessus de XRController l’interacteur dans la hiérarchie. Le XRController lie aux actions d’entrée, puis propage les actions pertinentes (sélection, etc.) vers le bas à tous les interacteurs attachés.

Néanmoins, certains interacteurs peuvent avoir besoin de liaisons d’entrée spéciales ou d’entrées supplémentaires que le XRController ne fournit pas. Dans ce cas, les interacteurs ont la possibilité de lier directement à leurs propres actions d’entrée uniques ou même d’utiliser d’autres sources non-Input-System pour la logique d’interaction. Les classes de base XRI préfèrent écouter les XRControllerliaisons de, mais ces comportements peuvent être remplacés pour utiliser des sources d’entrée externes ou alternatives.

Interfaces

XRI définit les valeurs de base IXRInteractor, IXRHoverInteractor, IXRSelectInteractoret IXRActivateInteractor. MRTK définit des interfaces supplémentaires pour les interacteurs. Certaines exposent des informations supplémentaires sur les interactions spécifiques à MRTK, tandis que d’autres sont simplement destinées à la catégorisation et à l’identification. Ces interfaces se trouvent toutes dans le package Core , tandis que les implémentations résident dans d’autres packages, y compris Input.

Importante

Bien que ces interfaces soient utiles si vous avez besoin de filtrer pour un type spécifique d’interaction, nous vous recommandons de ne pas coder en dur vos interactions pour écouter ces interfaces spécifiquement. Dans chaque situation, donnez toujours la préférence à l’interface XRI générique isSelected et isHovered, plutôt qu’à n’importe quelle interface spécifique à l’interaction.

Sauf si nécessaire, vous ne devez pas référencer les implémentations MRTK concrètes de ces interfaces dans des interactables, sauf si cela est absolument nécessaire. Dans tous les cas, il est préférable de référencer les interfaces. En référençant explicitement les types concrets, vos éléments interactables ne fonctionnent qu’avec les types existants actuels. En référençant uniquement les interfaces, vous garantissez la compatibilité avec les implémentations futures qui ne peuvent pas sous-classer les implémentations existantes.

IVariableSelectInteractor

Les interacteurs qui implémentent cette interface peuvent émettre une sélection de variable (c’est-à-dire analogique) sur des interactables. La variable select amount peut être interrogée avec la SelectProgress propriété . Les interacteurs MRTK qui implémentent cette interface incluent et MRTKRayInteractorGazePinchInteractor. Les interactables de base (les éléments interactables XRI par défaut, et MRTKBaseInteractable) ne seront pas affectés par la quantité de sélection de variables ; StatefulInteractabletoutefois, écoute cette valeur et calcule sa Selectedness en fonction de tous max() les interacteurs variables et non variables participants.

IGazeInteractor

Les interacteurs qui implémentent cette interface représentent le regard passif de l’utilisateur, distinct de toute manipulation ou intention. L’implémentation MRTK est FuzzyGazeInteractor, qui hérite de l’IRS XRRayInteractoret ajoute une logique de diffusion conique approximative. XRBaseInteractable indique IsGazeHovered lorsqu’un IGazeInteractor pointeur pointe.

IGrabInteractor

Les interacteurs qui implémentent cette interface représentent une interaction physique de saisie en champ proche. le attachTransform est défini comme le point d’accaparement. L’implémentation MRTK est GrabInteractor, qui sous-classe le XRI.XRDirectInteractor

IPokeInteractor

Les interacteurs qui implémentent cette interface représentent une interaction poking. Notez que cela n’implique pas nécessairement un doigt ! Les interacteurs arbitraires peuvent implémenter cette interface et offrir des interactions de poking à partir de sources autres que les doigts. Dans l’un des rares cas où la vérification des interfaces de l’interacteur est une bonne idée, des interactables comme PressableButton écouter IPokeInteractorpour s, en particulier, pour piloter la pression volumétrique. Tout interacteur qui implémente IPokeInteractor induira des pressions 3D sur les boutons.

IPokeInteractor expose la PokeRadius propriété , qui définit les caractéristiques de l’objet poking. Le poke est considéré comme centré sur le attachTransform et s’étend vers l’extérieur attachTransform du par le PokeRadius. Les interactables comme PressableButton décaler leur distance de poussée 3D par ce rayon, qui peut être déterminé par l’épaisseur physique du doigt de l’utilisateur dans le cas de pressions au doigt.

L’implémentation MRTK de cette interface est PokeInteractor. Dans notre projet de modèle, nous fournissons également un autre exemple de IPokeInteractor qui n’est pas piloté par les doigts ; PenInteractor fournit des interactions poke enracinées sur la pointe d’un stylet 3D virtuel.

IRayInteractor

Les interacteurs qui implémentent cette interface représentent une interaction de pointage basée sur le rayon. le attachTransform représente l’emplacement du rayon sur la surface de l’objet ciblé pendant une sélection.

L’implémentation MRTK de cette interface est MRTKRayInteractor, héritant directement du XRI XRRayInteractor.

Remarque

XRI XRRayInteractor n’implémente pas cette interface MRTK.

ISpeechInteractor

Les interacteurs qui implémentent cette interface représentent des interactions vocales. L’implémentation MRTK est SpeechInteractor.

Le MRTK SpeechInteractor, en interne, utilise PhraseRecognitionSubsystem et s’abonne aux événements d’inscription interactifs à partir du XRI XRInteractionManager. Toutefois, les interactables n’ont pas besoin de se soucier du sous-système qui effectue le traitement vocal ; ISpeechInteractorgénèrent les mêmes événements XRI (sélection, etc.) que n’importe quel autre interacteur.

IGazePinchInteractor

Cette interface est simplement une spécialisation de l’interface IVariableSelectInteractor . Les interacteurs qui implémentent cette interface sont implicitement des interacteurs à sélection variable. IGazePinchInteractorreprésente expressément une manipulation à distance indirectement ciblée. Un interacteur distinct basé sur le regard pilote la cible de l’interaction, et la manipulation est effectuée par une main ou un contrôleur. attachTransformse comporte de la même façon IRayInteractorattachTransform que le s ; il s’aligne sur le point d’accès sur la cible lorsqu’une sélection est lancée.

Lorsque plusieurs IGazePinchInteractors participent à une seule interaction, leurs attachTransforms sont décalés par leur déplacement du point médian entre tous les points de pincement participants. Ainsi, les interactables peuvent interpréter ces attachTransforms de la même façon qu’ils le feraient pour toute autre interaction multi-mains, comme les attachTransforms interactions de la prise de, ou les interactions de rayon.

L’implémentation MRTK est .GazePinchInteractor

IHandedInteractor

Certains interacteurs peuvent choisir d’implémenter IHandedInteractor l’interface pour spécifier explicitement qu’ils sont associés à une main particulière sur un utilisateur. Certains interacteurs ne sont pas associés à la remise en main et ne l’implémentent donc pas. Les exemples les plus évidents sont ceux comme SpeechInteractor ou FuzzyGazeInteractor.

Les interacteurs MRTK qui implémentent cette interface sont , HandJointInteractorun générique et abstrait XRDirectInteractor piloté par un joint de main arbitraire, le GazePinchInteractoret le MRTKRayInteractor.

Les interactables utilisent actuellement cette interface pour déclencher certains effets lorsqu’ils sont sélectionnés, qui doivent lever l’ambiguïté entre une main gauche ou droite. L’exemple le plus notable est l’effet d’impulsion dans la bibliothèque de composants d’expérience utilisateur.