Contrôleurs de mouvement dans Unity

  • Article

Il existe deux façons clés d’agir sur votre regard dans Unity : mouvements de la main et contrôleurs de mouvement dans HoloLens et HMD immersif. Vous accédez aux données des deux sources d’entrée spatiale via les mêmes API dans Unity.

Unity fournit deux méthodes principales pour accéder aux données d’entrée spatiales pour Windows Mixed Reality. Les API Input.GetButton/Input.GetAxis courantes fonctionnent sur plusieurs kits SDK Unity XR, tandis que l’API InteractionManager/GestureRecognizer spécifique à Windows Mixed Reality expose l’ensemble complet des données d’entrée spatiales.

API d’entrée Unity XR

Pour les nouveaux projets, nous vous recommandons d’utiliser les nouvelles API d’entrée XR depuis le début.

Vous trouverez plus d’informations sur les API XR ici.

Table de mappage de bouton/axe Unity

Le gestionnaire d’entrée d’Unity pour les contrôleurs de mouvement Windows Mixed Reality prend en charge les ID de bouton et d’axe répertoriés ci-dessous via les API Input.GetButton/GetAxis. La colonne « Windows MR-specific » fait référence aux propriétés disponibles hors du type InteractionSourceState . Chacune de ces API est décrite en détail dans les sections ci-dessous.

Les mappages d’ID de bouton/axe pour Windows Mixed Reality correspondent généralement aux ID de bouton/axe Oculus.

Les mappages d’ID de bouton/axe pour Windows Mixed Reality diffèrent des mappages d’OpenVR de deux manières :

  1. Le mappage utilise des ID de pavé tactile qui sont distincts de la manette, pour prendre en charge les contrôleurs avec des manettes et des pavés tactiles.
  2. Le mappage évite de surcharger les ID de bouton A et X pour les boutons Menu afin de les laisser disponibles pour les boutons ABXY physiques.
EntréeAPI Unity courantes
(Input.GetButton/GetAxis)		API d’entrée spécifique à Windows MR
(XR. WSA. Entrée)
Main gauche Main droite
Sélectionner le déclencheur enfoncé Axe 9 = 1,0 Axe 10 = 1,0 selectPressed
Sélectionner la valeur analogique du déclencheur Axe 9 Axe 10 selectPressedAmount
Sélectionner le déclencheur partiellement appuyé Bouton 14 (compat du boîtier de commande) Bouton 15 (compat du boîtier de commande) selectPressedAmount > 0.0
Bouton de menu enfoncé Bouton 6* Bouton 7* menuPressed
Bouton poignée enfoncé Axe 11 = 1,0 (aucune valeur analogique)
Bouton 4 (compat du boîtier de commande) 		Axe 12 = 1,0 (aucune valeur analogique)
Bouton 5 (compat du boîtier de commande) 		Saisi
Stick X (gauche : -1.0, droite : 1.0) Axe 1 Axe 4 thumbstickPosition.x
Manette Y (haut : -1.0, bas : 1.0) Axe 2 Axe 5 thumbstickPosition.y
Touche enfoncée Bouton 8 Bouton 9 thumbstickPressed
Pavé tactile X (gauche : -1.0, droite : 1.0) Axe 17* Axe 19* touchpadPosition.x
Pavé tactile Y (haut : -1.0, bas : 1.0) Axe 18* Axe 20* touchpadPosition.y
Pavé tactile tactile Bouton 18* Bouton 19* pavé tactileTouched
Pavé tactile enfoncé Bouton 16* Bouton 17* touchpadPressed
Pose de poignée 6DoF ou pose de pointeur Prise en main uniquement : XR. InputTracking.GetLocalPosition
XR. InputTracking.GetLocalRotation		 Passer grip ou pointeur en tant qu’argument : sourceState.sourcePose.TryGetPosition
sourceState.sourcePose.TryGetRotation
État de suivi Positionner la précision et le risque de perte de source uniquement disponibles via l’API spécifique à MR sourceState.sourcePose.positionAccuracy
sourceState.properties.sourceLossRisk

Notes

Ces ID de bouton/axe diffèrent des ID utilisés par Unity pour OpenVR en raison de collisions dans les mappages utilisés par les boîtiers de commande, Oculus Touch et OpenVR.

OpenXR

Pour en savoir plus sur les notions de base sur les interactions de réalité mixte dans Unity, consultez le Manuel Unity pour Unity XR Input. Cette documentation Unity couvre les mappages des entrées spécifiques au contrôleur vers les entrées InputFeatureUsageplus généralisables, comment les entrées XR disponibles peuvent être identifiées et classées, comment lire les données à partir de ces entrées, etc.

Le plug-in OpenXR Mixed Reality fournit des profils d’interaction d’entrée supplémentaires, mappés à inputFeatureUsagestandard, comme indiqué ci-dessous :

InputFeatureUsage Hp Reverb G2 Controller (OpenXR) HoloLens Hand (OpenXR)
primary2DAxis Joystick
primary2DAxisClick Joystick - Click
déclencheur Déclencheur
Poignée Poignée Appuyez ou pressez à l’air
primaryButton [X/A] - Appuyez sur Clic aérien
secondaryButton [Y/B] - Appuyez sur
gripButton Poignée - Appuyez sur
triggerButton Déclencheur - Appuyez sur
menuButton Menu

Pose de prise ou pose pointante

Windows Mixed Reality prend en charge les contrôleurs de mouvement dans divers facteurs de forme. La conception de chaque contrôleur diffère dans sa relation entre la position de la main de l’utilisateur et la direction « vers l’avant » naturelle que les applications doivent utiliser pour pointer lors du rendu du contrôleur.

Pour mieux représenter ces contrôleurs, il existe deux types de postures que vous pouvez examiner pour chaque source d’interaction: la pose de prise en main et la pose de pointeur. Les coordonnées de pose de prise et de pose de pointeur sont exprimées par toutes les API Unity dans les coordonnées mondiales Unity.

Pose de prise en main

La pose de prise représente l’emplacement de la paume de l’utilisateur, détectée par un HoloLens ou tenant un contrôleur de mouvement.

Sur les casques immersifs, la pose de prise en main est mieux utilisée pour restituer la main de l’utilisateur ou un objet tenu dans la main de l’utilisateur. La pose de la poignée est également utilisée lors de la visualisation d’un contrôleur de mouvement. Le modèle restituable fourni par Windows pour un contrôleur de mouvement utilise la pose de poignée comme origine et centre de rotation.

La pose de la poignée est définie spécifiquement comme suit :

  • Position de prise : centroïde de la paume lors de la tenue du contrôleur naturellement, ajusté à gauche ou à droite pour centrer la position à l’intérieur de la poignée. Sur le contrôleur de mouvement Windows Mixed Reality, cette position s’aligne généralement sur le bouton Saisir.
  • L’axe droit de la poignée : lorsque vous ouvrez complètement votre main pour former une pose à 5 doigts plat, le rayon qui est normal à votre paume (vers l’avant de la paume gauche, vers l’arrière de la paume droite)
  • Axe avant de la poignée : lorsque vous fermez partiellement votre main (comme si vous teniez la manette), le rayon qui pointe « vers l’avant » à travers le tube formé par vos doigts non-pouce.
  • Axe Haut de l’orientation de la prise en main : axe Haut impliqué par les définitions Droite et Avant.

Vous pouvez accéder à la pose de prise en main via l’API d’entrée inter-fournisseurs (XR) d’Unity. InputTracking. GetLocalPosition/Rotation) ou via l’API spécifique à Windows MR (sourceState.sourcePose.TryGetPosition/Rotation, demandant des données de pose pour le nœud Grip ).

Pose du pointeur

La pose de pointeur représente la pointe du contrôleur pointant vers l’avant.

La pose de pointeur fournie par le système est mieux utilisée pour raycast lorsque vous affichez le modèle de contrôleur lui-même. Si vous rendez un autre objet virtuel à la place de la manette, comme un pistolet virtuel, vous devez pointer avec un rayon qui est le plus naturel pour cet objet virtuel, comme un rayon qui se déplace le long du canon du modèle d’arme défini par l’application. Étant donné que les utilisateurs peuvent voir l’objet virtuel et non le contrôleur physique, pointer avec l’objet virtuel sera probablement plus naturel pour ceux qui utilisent votre application.

Actuellement, la pose de pointeur est disponible dans Unity uniquement via l’API spécifique à Windows MR, sourceState.sourcePose.TryGetPosition/Rotation, en passant dans InteractionSourceNode.Pointer comme argument.

OpenXR

Vous avez accès à deux ensembles de poses via les interactions d’entrée OpenXR :

  • La poignée pose pour le rendu des objets dans la main
  • L’objectif est de pointer vers le monde.

Pour plus d’informations sur cette conception et les différences entre les deux poses, consultez spécification OpenXR - Sous-chemins d’entrée.

Les poses fournies par InputFeatureUsages DevicePosition, DeviceRotation, DeviceVelocity et DeviceAngularVelocity représentent toutes la pose de la poignée OpenXR. InputFeatureUsages liés aux poses de prise en main sont définis dans CommonUsages d’Unity.

Les poses fournies par inputFeatureUsages PointerPosition, PointerRotation, PointerVelocity et PointerAngularVelocity représentent toutes la pose d’objectif OpenXR. Ces InputFeatureUsages ne sont pas définis dans les fichiers C# inclus, vous devez donc définir vos propres InputFeatureUsages comme suit :

public static readonly InputFeatureUsage<Vector3> PointerPosition = new InputFeatureUsage<Vector3>("PointerPosition");

Haptique

Pour plus d’informations sur l’utilisation de l’haptique dans le système d’entrée XR d’Unity, consultez le Manuel Unity pour Unity XR Input - Haptics.

État du suivi du contrôleur

Comme les casques, le contrôleur de mouvement Windows Mixed Reality ne nécessite aucune configuration de capteurs de suivi externes. Au lieu de cela, les contrôleurs sont suivis par des capteurs dans le casque lui-même.

Si l’utilisateur déplace les contrôleurs hors du champ d’affichage du casque, Windows continue de déduire les positions du contrôleur dans la plupart des cas. Lorsque le contrôleur a perdu le suivi visuel pendant suffisamment longtemps, les positions du contrôleur passent à des positions de précision approximative.

À ce stade, le système verrouille le corps du contrôleur à l’utilisateur, en suivant la position de l’utilisateur à mesure qu’il se déplace, tout en exposant l’orientation réelle du contrôleur à l’aide de ses capteurs d’orientation internes. De nombreuses applications qui utilisent des contrôleurs pour pointer et activer des éléments d’interface utilisateur peuvent fonctionner normalement avec une précision approximative sans que l’utilisateur ne le remarque.

Raisonnement sur l’état de suivi explicitement

Les applications qui souhaitent traiter les positions différemment en fonction de l’état de suivi peuvent aller plus loin et inspecter les propriétés de l’état du contrôleur, telles que SourceLossRisk et PositionAccuracy :

État de suivi SourceLossRisk PositionAccuracy TryGetPosition
Haute précision < 1.0 Élevé true
Haute précision (au risque de perdre) == 1.0 Élevé true
Précision approximative == 1.0 Approximatif true
Aucune position == 1.0 Approximatif false

Ces états de suivi du contrôleur de mouvement sont définis comme suit :

  • Haute précision : Bien que le contrôleur de mouvement se trouve dans le champ de vision du casque, il fournit généralement des positions de haute précision, basées sur le suivi visuel. Un contrôleur mobile qui quitte momentanément le champ de vision ou est momentanément masqué des capteurs du casque (par exemple, par l’autre main de l’utilisateur) continuera à retourner des poses de haute précision pendant une courte période, en fonction du suivi inertiel du contrôleur lui-même.
  • Haute précision (au risque de perdre) : Lorsque l’utilisateur déplace le contrôleur de mouvement au-delà du bord du champ de vision du casque, le casque ne pourra bientôt pas suivre visuellement la position du contrôleur. L’application sait quand le contrôleur a atteint cette limite de FOV en voyant sourceLossRisk atteindre 1.0. À ce stade, l’application peut choisir de suspendre les mouvements du contrôleur qui nécessitent un flux stable de poses de haute qualité.
  • Précision approximative : Lorsque le contrôleur a perdu le suivi visuel pendant suffisamment longtemps, les positions du contrôleur passent à des positions de précision approximative. À ce stade, le système verrouille le corps du contrôleur à l’utilisateur, en suivant la position de l’utilisateur à mesure qu’il se déplace, tout en exposant l’orientation réelle du contrôleur à l’aide de ses capteurs d’orientation internes. De nombreuses applications qui utilisent des contrôleurs pour pointer et activer des éléments d’interface utilisateur peuvent fonctionner normalement avec une précision approximative sans que l’utilisateur ne le remarque. Les applications avec des exigences d’entrée plus lourdes peuvent choisir de détecter cette baisse de haute précision à précision approximative en inspectant la propriété PositionAccuracy , par exemple pour offrir à l’utilisateur une hitbox plus généreuse sur les cibles hors écran pendant cette période.
  • Aucune position : Bien que le contrôleur puisse fonctionner à une précision approximative pendant une longue période, le système sait parfois que même une position verrouillée par le corps n’est pas significative pour le moment. Par exemple, un contrôleur activé n’a peut-être jamais été observé visuellement, ou un utilisateur peut poser un contrôleur qui est ensuite récupéré par quelqu’un d’autre. À ce moment-là, le système ne fournit aucune position à l’application, et TryGetPosition retourne la valeur false.

API Unity courantes (Input.GetButton/GetAxis)

Espace de noms :UnityEngine, UnityEngine.XR
Types : Entrée, XR. InputTracking

Unity utilise actuellement ses API Input.GetButton/Input.GetAxis générales pour exposer les entrées pour le Kit de développement logiciel (SDK) Oculus, le Kit de développement logiciel (SDK) OpenVR et Windows Mixed Reality, y compris les mains et les contrôleurs de mouvement. Si votre application utilise ces API pour l’entrée, elle peut facilement prendre en charge les contrôleurs de mouvement sur plusieurs kits SDK XR, y compris Windows Mixed Reality.

Obtention de l’état enfoncé d’un bouton logique

Pour utiliser les API d’entrée Unity générales, vous commencerez généralement par connecter des boutons et des axes aux noms logiques dans Unity Input Manager, en liant un ou des ID d’axe à chaque nom. Vous pouvez ensuite écrire du code qui fait référence à ce nom de bouton/axe logique.

Par exemple, pour mapper le bouton déclencheur du contrôleur de mouvement gauche à l’action Envoyer, accédez à Modifier > l’entrée des paramètres > du projet dans Unity, puis développez les propriétés de la section Envoyer sous Axes. Modifiez la propriété Bouton positif ou Alt Positive Button pour lire le bouton joystick 14, comme suit :

InputManager d’Unity
Unity InputManager

Votre script peut ensuite case activée pour l’action Envoyer à l’aide de Input.GetButton :

if (Input.GetButton("Submit"))
{
  // ...
}

Vous pouvez ajouter des boutons plus logiques en modifiant la propriété Size sous Axes.

Obtention de l’état enfoncé d’un bouton physique directement

Vous pouvez également accéder aux boutons manuellement par leur nom complet, à l’aide de Input.GetKey :

if (Input.GetKey("joystick button 8"))
{
  // ...
}

Obtenir la pose d’une main ou d’un contrôleur de mouvement

Vous pouvez accéder à la position et à la rotation du contrôleur à l’aide de XR. InputTracking :

Vector3 leftPosition = InputTracking.GetLocalPosition(XRNode.LeftHand);
Quaternion leftRotation = InputTracking.GetLocalRotation(XRNode.LeftHand);

Notes

Le code ci-dessus représente la prise en main du contrôleur (où l’utilisateur tient le contrôleur), ce qui est utile pour rendre une épée ou un pistolet dans la main de l’utilisateur, ou un modèle du contrôleur lui-même.

La relation entre cette pose de prise en main et la pose du pointeur (où pointe la pointe du contrôleur) peut différer d’un contrôleur à l’autre. À ce stade, l’accès à la pose de pointeur du contrôleur n’est possible que via l’API d’entrée mr spécifique, décrite dans les sections ci-dessous.

API spécifiques à Windows (XR. WSA. Entrée)

Attention

Si votre projet utilise l’un des XR. Les API WSA sont progressivement supprimées au profit du SDK XR dans les prochaines versions d’Unity. Pour les nouveaux projets, nous vous recommandons d’utiliser le Kit de développement logiciel (SDK) XR dès le début. Vous trouverez plus d’informations sur le système d’entrée XR et les API ici.

Espace de noms :UnityEngine.XR.WSA.Input
Types : InteractionManager, InteractionSourceState, InteractionSource, InteractionSourceProperties, InteractionSourceKind, InteractionSourceLocation

Pour obtenir des informations plus détaillées sur Windows Mixed Reality entrée manuelle (pour HoloLens) et les contrôleurs de mouvement, vous pouvez choisir d’utiliser les API d’entrée spatiale spécifiques à Windows sous l’espace de noms UnityEngine.XR.WSA.Input. Cela vous permet d’accéder à des informations supplémentaires, telles que la précision de la position ou le type de source, ce qui vous permet de distinguer les mains et les contrôleurs.

Interrogation de l’état des mains et des contrôleurs de mouvement

Vous pouvez interroger l’état de cette image pour chaque source d’interaction (main ou contrôleur de mouvement) à l’aide de la méthode GetCurrentReading .

var interactionSourceStates = InteractionManager.GetCurrentReading();
foreach (var interactionSourceState in interactionSourceStates) {
    // ...
}

Chaque InteractionSourceState que vous récupérez représente une source d’interaction au moment actuel. InteractionSourceState expose des informations telles que :

  • Quels types d’appuis se produisent (Sélectionner/Menu/Saisir/Pavé tactile/Stick)

    if (interactionSourceState.selectPressed) {
     // ...
}

  • Autres données spécifiques aux contrôleurs de mouvement, telles que les coordonnées XY et/ou l’état tactile du pavé tactile et/ou du bâton

    if (interactionSourceState.touchpadTouched && interactionSourceState.touchpadPosition.x > 0.5) {
     // ...
}

  • InteractionSourceKind pour savoir si la source est une main ou un contrôleur de mouvement

    if (interactionSourceState.source.kind == InteractionSourceKind.Hand) {
     // ...
}

Interrogation des poses de rendu prédictées

  • Lors de l’interrogation de données sources d’interaction à partir de mains et de contrôleurs, les poses que vous obtenez sont des poses prédites pour le moment dans le temps où les photons de ce cadre atteignent les yeux de l’utilisateur. Les poses prédictées sont mieux utilisées pour le rendu du contrôleur ou d’un objet conservé chaque image. Si vous ciblez une presse ou une publication donnée avec le contrôleur, cela sera plus précis si vous utilisez les API d’événement historique décrites ci-dessous.

    var sourcePose = interactionSourceState.sourcePose;
Vector3 sourceGripPosition;
Quaternion sourceGripRotation;
if ((sourcePose.TryGetPosition(out sourceGripPosition, InteractionSourceNode.Grip)) &&
     (sourcePose.TryGetRotation(out sourceGripRotation, InteractionSourceNode.Grip))) {
     // ...
}

  • Vous pouvez également obtenir la pose de tête prédite vers l’avant pour cette image actuelle. Comme pour la pose source, cela est utile pour le rendu d’un curseur, même si le ciblage d’une presse ou d’une publication donnée sera plus précis si vous utilisez les API d’événement historique décrites ci-dessous.

    var headPose = interactionSourceState.headPose;
var headRay = new Ray(headPose.position, headPose.forward);
RaycastHit raycastHit;
if (Physics.Raycast(headPose.position, headPose.forward, out raycastHit, 10)) {
     var cursorPos = raycastHit.point;
     // ...
}

Gestion des événements sources d’interaction

Pour gérer les événements d’entrée à mesure qu’ils se produisent avec leurs données de pose historiques précises, vous pouvez gérer les événements sources d’interaction au lieu d’interroger.

Pour gérer les événements sources d’interaction :

  • Inscrivez-vous à un événement d’entrée InteractionManager . Pour chaque type d’événement d’interaction qui vous intéresse, vous devez vous y abonner.

    InteractionManager.InteractionSourcePressed += InteractionManager_InteractionSourcePressed;

  • Gérez l’événement. Une fois que vous vous êtes abonné à un événement d’interaction, vous recevez le rappel le cas échéant. Dans l’exemple SourcePressed , cette opération se produit après la détection de la source et avant qu’elle soit relâchée ou perdue.

    void InteractionManager_InteractionSourceDetected(InteractionSourceDetectedEventArgs args)
     var interactionSourceState = args.state;

     // args.state has information about:
        // targeting head ray at the time when the event was triggered
        // whether the source is pressed or not
        // properties like position, velocity, source loss risk
        // source id (which hand id for example) and source kind like hand, voice, controller or other
}

Comment arrêter la gestion d’un événement

Vous devez arrêter la gestion d’un événement lorsque vous n’êtes plus intéressé par l’événement ou que vous détruisez l’objet qui s’est abonné à l’événement. Pour arrêter la gestion de l’événement, vous vous désabonnez de l’événement.

InteractionManager.InteractionSourcePressed -= InteractionManager_InteractionSourcePressed;

Liste des événements sources d’interaction

Les événements sources d’interaction disponibles sont les suivants :

  • InteractionSourceDetected (la source devient active)
  • InteractionSourceLost (devient inactif)
  • InteractionSourcePressed (appuyez, appuyez sur le bouton ou « Sélectionner » énoncé)
  • InteractionSourceReleased (fin d’un appui, bouton relâché ou fin de « Sélectionner » prononcé)
  • InteractionSourceUpdated (déplace ou modifie un état)

Événements pour les poses de ciblage historique qui correspondent le plus exactement à un communiqué de presse ou à un communiqué

Les API d’interrogation décrites précédemment donnent à votre application des postures prédictées. Bien que ces poses prédites soient idéales pour le rendu du contrôleur ou d’un objet portable virtuel, les futures poses ne sont pas optimales pour le ciblage, pour deux raisons clés :

  • Lorsque l’utilisateur appuie sur un bouton sur un contrôleur, il peut y avoir environ 20 ms de latence sans fil via Bluetooth avant que le système ne reçoive l’appui.
  • Ensuite, si vous utilisez une pose prédictée, une autre prédiction d’avance de 10 à 20 ms est appliquée pour cibler l’heure à laquelle les photons de l’image actuelle atteignent les yeux de l’utilisateur.

Cela signifie que l’interrogation vous donne une pose source ou une pose de tête qui est de 30 à 40 ms en avant d’où la tête et les mains de l’utilisateur étaient effectivement de retour lorsque la presse ou le communiqué s’est produit. Pour la saisie manuelle HoloLens, bien qu’il n’y ait pas de délai de transmission sans fil, il existe un délai de traitement similaire pour détecter la presse.

Pour cibler précisément en fonction de l’intention d’origine de l’utilisateur pour une main ou un contrôleur, vous devez utiliser la pose de la source historique ou la pose de la tête de cet événement d’entrée InteractionSourcePressed ou InteractionSourceReleased .

Vous pouvez cibler une presse ou une publication avec des données historiques de pose provenant de la tête de l’utilisateur ou de son contrôleur :

  • Pose de la tête au moment où un mouvement ou une pression du contrôleur s’est produit, qui peut être utilisé pour cibler afin de déterminer ce que l’utilisateur regardait :

    void InteractionManager_InteractionSourcePressed(InteractionSourcePressedEventArgs args) {
     var interactionSourceState = args.state;
     var headPose = interactionSourceState.headPose;
     RaycastHit raycastHit;
     if (Physics.Raycast(headPose.position, headPose.forward, out raycastHit, 10)) {
         var targetObject = raycastHit.collider.gameObject;
         // ...
     }
}

  • Pose source au moment où une pression sur le contrôleur de mouvement s’est produite, qui peut être utilisée pour cibler afin de déterminer ce vers quoi l’utilisateur pointait le contrôleur. Il s’agit de l’état du contrôleur qui a subi l’appui. Si vous effectuez le rendu du contrôleur lui-même, vous pouvez demander la pose de pointeur plutôt que la pose de prise, pour tirer le rayon de ciblage à partir de ce que l’utilisateur considérera comme la pointe naturelle de ce contrôleur rendu :

    void InteractionManager_InteractionSourcePressed(InteractionSourcePressedEventArgs args)
{
     var interactionSourceState = args.state;
     var sourcePose = interactionSourceState.sourcePose;
     Vector3 sourceGripPosition;
     Quaternion sourceGripRotation;
     if ((sourcePose.TryGetPosition(out sourceGripPosition, InteractionSourceNode.Pointer)) &&
         (sourcePose.TryGetRotation(out sourceGripRotation, InteractionSourceNode.Pointer))) {
         RaycastHit raycastHit;
         if (Physics.Raycast(sourceGripPosition, sourceGripRotation * Vector3.forward, out raycastHit, 10)) {
             var targetObject = raycastHit.collider.gameObject;
             // ...
         }
     }
}

Exemple de gestionnaires d’événements

using UnityEngine.XR.WSA.Input;

void Start()
{
    InteractionManager.InteractionSourceDetected += InteractionManager_InteractionSourceDetected;
    InteractionManager.InteractionSourceLost += InteractionManager_InteractionSourceLost;
    InteractionManager.InteractionSourcePressed += InteractionManager_InteractionSourcePressed;
    InteractionManager.InteractionSourceReleased += InteractionManager_InteractionSourceReleased;
    InteractionManager.InteractionSourceUpdated += InteractionManager_InteractionSourceUpdated;
}

void OnDestroy()
{
    InteractionManager.InteractionSourceDetected -= InteractionManager_InteractionSourceDetected;
    InteractionManager.InteractionSourceLost -= InteractionManager_InteractionSourceLost;
    InteractionManager.InteractionSourcePressed -= InteractionManager_InteractionSourcePressed;
    InteractionManager.InteractionSourceReleased -= InteractionManager_InteractionSourceReleased;
    InteractionManager.InteractionSourceUpdated -= InteractionManager_InteractionSourceUpdated;
}

void InteractionManager_InteractionSourceDetected(InteractionSourceDetectedEventArgs args)
{
    // Source was detected
    // args.state has the current state of the source including id, position, kind, etc.
}

void InteractionManager_InteractionSourceLost(InteractionSourceLostEventArgs state)
{
    // Source was lost. This will be after a SourceDetected event and no other events for this
    // source id will occur until it is Detected again
    // args.state has the current state of the source including id, position, kind, etc.
}

void InteractionManager_InteractionSourcePressed(InteractionSourcePressedEventArgs state)
{
    // Source was pressed. This will be after the source was detected and before it is
    // released or lost
    // args.state has the current state of the source including id, position, kind, etc.
}

void InteractionManager_InteractionSourceReleased(InteractionSourceReleasedEventArgs state)
{
    // Source was released. The source would have been detected and pressed before this point.
    // This event will not fire if the source is lost
    // args.state has the current state of the source including id, position, kind, etc.
}

void InteractionManager_InteractionSourceUpdated(InteractionSourceUpdatedEventArgs state)
{
    // Source was updated. The source would have been detected before this point
    // args.state has the current state of the source including id, position, kind, etc.
}

Contrôleurs de mouvement dans MRTK

Vous pouvez accéder au contrôleur de mouvement et de mouvement à partir du Gestionnaire d’entrée.

Avancer avec des tutoriels

Des tutoriels pas à pas, avec des exemples de personnalisation plus détaillés, sont disponibles dans la Mixed Reality Academy :

Entrée MR 213 - Contrôleur de mouvement
Entrée MR 213 - Contrôleur de mouvement

Point de contrôle de développement suivant

Si vous suivez le parcours de développement Unity que nous avons préparé, vous êtes en train d’explorer les blocs de construction de base MRTK. À partir de là, vous pouvez passer au module suivant :

Suivi du regard et des mains

Ou accéder aux API et fonctionnalités de la plateforme Mixed Reality :

Expériences partagées

Vous pouvez revenir aux points de contrôle de développement Unity à tout moment.

Voir aussi