Interactionnables – MRTK3

MRTK s’appuie sur le XRBaseInteractable fourni par le kit de ressources XR Interaction de Unity. Le comportement et l’API de l’élément interactionnable existant sont entièrement pris en charge dans MRTK, et tous nos éléments interactionnables personnalisés obéissent à l’API de l’élément interactionnable XRI existant.

Pour les développeurs qui débutent avec XRI, nous vous recommandons fortement de consulter d’abord la documentation de l’architecture XRI d’Unity.

Pour développer les mécanismes interactionnables inclus dans XRI, MRTK propose deux classes de base sur lesquelles des interactions avancées peuvent être basées, l’une étendant l’autre.

• MRTKBaseInteractable : XRBaseInteractable
  • Cette classe offre un filtrage et un ajout d’indicateur pour différents types d’interacteurs. Bien que le XRI de base XRBaseInteractable ne fasse pas de distinction entre les types d’interacteurs, MRTKBaseInteractable fournit des fonctions pratiques permettant de vérifier si des types d’interactions courants se produisent. Des propriétés pratiques telles que IsGazeHovered ou IsGrabSelected sont des raccourcis pour interroger si un interacteur participant implémente une interface donnée (de manière correspondante IGazeInteractor ou IGrabInteractor). Ces indicateurs sont plus performants qu’une itération dans la liste de interactorsHoveringou interactorsSelecting. En outre, MRTKBaseInteractable peut filtrer/rejeter certains types d’interacteurs, si le développeur souhaite exclure certaines modalités d’entrée.
• StatefulInteractable : MRTKBaseInteractable
  • Bien que MRTKBaseInteractable se contente d’ajouter des indicateurs et des filtres, et évite d’ajouter un état supplémentaire à l’interaction, StatefulInteractable introduit des fonctionnalités avec état utiles, comme le basculement et la sélection de variable.

Séparation stricte de l’état et des éléments visuels

Dans MRTK 2.x, les interactionnables étaient souvent responsables de piloter leurs propres effets visuels, que ce soit en compressant un bouton 3D ou un effet de pointage, ou en modifiant la couleur en un clic. La limite de cette approche est que la logique d’interaction est étroitement liée aux éléments visuels. Si vous deviez redessiner le visuel ou utiliser un bouton de taille/forme/disposition/etc. différente, le script d’interaction lui-même devrait être modifié.

Dans MRTK3, les éléments interactionnables représentent un état et une interaction purs. L’élément interactionnable ne rend pas de changement visuel ou d’effet basé sur son état interne. Il s’agit uniquement d’une collection de logiques d’état et d’interaction hautement portables entre les configurations de présentation visuelle.

Le même script PressableButton peut être utilisé pour générer une balle souple, ou un plan de type pavé tactile sur lequel on peut appuyer, ou un élément abstrait sur lequel appuyer qui émet des événements réseau lorsqu’il est activé. Le script PressableButton ne s’occupe même pas de l’endroit où il se trouve, à l’intérieur d’un canevas, ou sur un corps rigide.

Pour générer des éléments visuels, un « pilote visuel » distinct est utilisé pour interroger l’état à partir de l’élément interactionnable et afficher le retour approprié. StateVisualizer est la méthode à faible code recommandée pour piloter des effets de retour visuel courants à partir de l’état de l’élément interactionnable, mais les développeurs sont libres d’écrire leurs propres pilotes visuels personnalisés. Par exemple, nos composants de bouton utilisent généralement StateVisualizer pour leurs effets avancés de commentaires basés sur un nuanceur et la 3D, mais nous fournissons également un exemple de BasicPressableButtonVisuals montrant comment un pilote visuel extrêmement simple peut être créé dans le code.

sélection des variables

StatefulInteractable, la fonctionnalité supplémentaire la plus utile sur la fonctionnalité XRI de base, constitue un support pour la variable Selectedness. Bien que les éléments interactionnables XRI de base soient sélectionnés ou non sélectionnés, les StatefulInteractable de MRTK peuvent être n’importe quelle fraction à virgule flottante de la sélection.

Ce concept est extrêmement utile lors du travail dans XR, car presque toutes les formes d’entrée ne sont plus des états binaires. Les contrôleurs de mouvement ayant souvent des déclencheurs analogiques (ou poignées analogiques), les interactions de main peuvent fournir un « pincement » variable, et les interactions par pression volumétrique peuvent enfoncer un bouton ou une surface enfonçable de façon variable. Partout dans XR, vous voyez ces variables et interactions analogiques, et MRTK est équipé pour aider les développeurs à créer de belles interactions en plus de ces entrées analogiques.

Un vaste éventail d’interacteurs et de types d’interactions peuvent contribuer ensemble à la sélectionnabilité globale d’un élément interactionnable. Plus précisément, tous les interacteurs qui implémentent IVariableSelectInteractor contribuent à la sélection analogique, généralement par le biais d’un max() de toutes les interacteurs participants. Cette contribution variable est combinée avec les sélections binaires, non variables provenant d’interacteurs de style vanille.

Pour les classes dérivées telles que PressableButton, la fonction Selectedness() est remplacée pour ajouter un « ingrédient » supplémentaire au calcul de la sélectionnabilité. Les interacteurs qui implémentent IPokeInteractor peuvent contribuer à la sélectionnabilité en fonction de leur emplacement physique et de la manière dont elles appuient physiquement sur l’élément interactionnable. D’autres classes dérivées peuvent introduire d’autres formes arbitraires de sélection.

Pour les éléments interactionnables fournis par MRTK, Selectedness() et isSelected seront toujours « D’accord », c’est-à-dire que vous n’observerez jamais une Selectedness() plus grande que le SelectThreshold sans un isSelected XRI correspondant et un interacteur associé dans interactorsSelecting.

Important

Vos sous-classes interactionnables personnalisées peuvent évidemment remplacer Selectedness par une autre valeur complètement déconnectée du isSelected XRI, mais nos interactions ne le font pas et nous le déconseillons fortement. En général, n’écrivez jamais d’interactions qui n’ont pas d’d’interacteur correspondant. Une sélection XRI sera le plus souvent suffisante, et tous les interactions personnalisées que vous générez devraient être écrites en tant qu’interacteurs.

Lors de la création d’un élément interactionnable personnalisé qui prend en charge une nouvelle méthode de détermination de Selectedness(), remplacez simplement la méthode et combinez votre nouvelle sélectionnabilité avec la quantité de sélection existante. Si vous utilisez StateVisualizer ou toute autre couche visuelle qui écoute une sélection variable, elle répond en conséquence à votre nouveau type de sélection.

Mapper des événements UGUI à XRI

Dans certains cas, il est souhaitable que des éléments interactionnables répondent à des événements UGUI, tels que la souris, la manette ou une entrée tactile. L’UGUIInputAdapter qui est un UGUI, reçoit des événements UGUI Selectable et les transfère à un CanvasProxyInteractor, s’il y en a un présent.

Quand le CanvasProxyInteractor est averti des événements UGUI par l’UGUIInputAdapter, il émet des actions XRI équivalentes sur l’élément interactionnable pertinent. Le mappage entre l’entrée UGUI et les actions XRI est un peu déficient, et fait l’objet d’un développement actif.

Avec ce système, des éléments interactionnables XRI existants conçus pour les plateformes immersives, les contrôleurs de mains et de mouvement, et les entrées 3D peuvent réagir aussi bien à des contrôles 2D accessibles, tels qu’une souris et une manette.