Contrôleurs de mouvement dans Unity

Il existe deux façons clés d’agir sur votre regard dans Unity, les mouvements de main et les contrôleurs de mouvement dans HoloLens et le HMD immersif. Vous accédez aux données pour les 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 spatiale 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 de données d’entrée spatiales.

API d’entrée XR Unity

Pour les nouveaux projets, nous vous recommandons d’utiliser les nouvelles API d’entrée XR à partir du 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 Windows Mixed Reality contrôleurs de mouvement prend en charge les ID de bouton et d’axe répertoriés ci-dessous via les API Input.GetButton/GetAxis. La colonne « Spécifique à Windows MR » 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 Tableaux.

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

  1. Le mappage utilise des ID de pavé tactile distincts du stick, pour prendre en charge les contrôleurs avec des pavés tactiles 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 appuyé 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 enfoncé Bouton 14 (compat du boîtier de commande) Bouton 15 (compat du boîtier de commande) selectPressedAmount > 0.0
Bouton de menu appuyé 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
Pouce Y (haut : -1.0, bas : 1.0) Axe 2 Axe 5 thumbstickPosition.y
Touche numérique 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* touchpadTouched
Pavé tactile enfoncé Bouton 16* Bouton 17* touchpadPressed
Pose de poignée 6DoF ou pose de pointeur Pose de poignée 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, Tableaux tactiles et OpenVR.

OpenXR

Pour en savoir plus sur les interactions de réalité mixte dans Unity, consultez le Manuel Unity pour Unity XR Input. Cette documentation Unity traite des mappages d’entrées spécifiques au contrôleur vers des entrées plus généralisables InputFeatureUsage, comment les entrées XR disponibles peuvent être identifiées et classées, comment lire des 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 à des éléments InputFeatureUsagestandard, comme indiqué ci-dessous :

InputFeatureUsage Contrôleur HP Reverb G2 (OpenXR) HoloLens Hand (OpenXR)
primary2DAxis Joystick
primary2DAxisClick Joystick - Clic
déclencheur Déclencheur
poignée Poignée Appui à l’air ou presser
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 poignée et pose pointant

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 naturelle « vers l’avant » 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 poignée et la pose de pointeur. Les coordonnées de pose de poignée et de pointeur sont exprimées par toutes les API Unity dans les coordonnées mondiales Unity.

Pose de poignée

La pose de poignée représente l’emplacement de la paume des utilisateurs, détectée par un HoloLens ou contenant un contrôleur de mouvement.

Sur les casques immersifs, la pose de poignée est mieux utilisée pour restituer la main de l’utilisateur ou un objet conservé dans la main de l’utilisateur. La pose de 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 son origine et son centre de rotation.

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

  • Position de la poignée : le centroïde de paume lors de la tenue du contrôleur naturellement, ajusté à gauche ou à droite pour centrer la position dans la poignée. Sur la Windows Mixed Reality contrôleur de mouvement, cette position s’aligne généralement sur le bouton Saisir.
  • Axe droit de l’orientation de la poignée : lorsque vous ouvrez complètement votre main pour former une pose plate à 5 doigts, 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 l’orientation de la poignée : lorsque vous fermez partiellement la main (comme si le contrôleur tient le contrôleur), le rayon qui pointe « vers l’avant » à travers le tube formé par vos doigts non-pouces.
  • Axe haut de l’orientation de la poignée : axe haut implicite 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 d’Unity (XR). 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 de 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 affichez un autre objet virtuel à la place du contrôleur, tel qu’une arme virtuelle, vous devez pointer avec un rayon le plus naturel pour cet objet virtuel, tel qu’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 par le biais de l’API spécifique à Mr Windows, sourceState.sourcePose.TryGetPosition/Rotation, en passant InteractionSourceNode.Pointer en tant qu’argument.

OpenXR

Vous avez accès à deux ensembles de postures par le biais d’interactions d’entrée OpenXR :

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

Vous trouverez plus d’informations sur cette conception et les différences entre les deux postures dans la spécification OpenXR - Sous-chemins d’entrée.

Les poses fournies par InputFeatureUsages DevicePosition, DeviceRotation, DeviceVelocity et DeviceAngularVelocity représentent toutes la pose de poignée OpenXR. Les inputFeatureUsages liées aux postures de poignée sont définies dans commonUsages d’Unity.

Les postures 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");

Haptics

Pour plus d’informations sur l’utilisation de haptics dans le système d’entrée XR d’Unity, la documentation est disponible dans 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 externe. 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 à déduire les positions du contrôleur dans la plupart des cas. Lorsque le contrôleur a perdu le suivi visuel pendant suffisamment de temps, les positions du contrôleur sont passées à des positions approximatives de précision.

À ce stade, le système verrouille le contrôleur à l’utilisateur, en suivant la position de l’utilisateur lorsqu’il se déplace, tout en exposant l’orientation réelle du contrôleur à l’aide de ses capteurs d’orientation interne. De nombreuses applications qui utilisent des contrôleurs pour pointer et activer des éléments d’interface utilisateur peuvent fonctionner normalement alors qu’elles sont approximatives sans que l’utilisateur ne 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 sur l’état du contrôleur, telles que SourceLossRisk et PositionAccuracy :

État de suivi SourceLossRisk PositionAccuracy TryGetPosition
Précision élevée < 1.0 Élevé true
Précision élevée (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 :

  • Précision élevée : Bien que le contrôleur de mouvement se trouve dans le champ d’affichage du casque, il fournit généralement des positions de haute précision, en fonction du suivi visuel. Un contrôleur de déplacement qui quitte momentanément le champ de vue ou qui est momentanément masqué à partir des capteurs du casque (par exemple par l’autre côté de l’utilisateur) continuera à retourner des poses de haute précision pendant un court laps de temps, en fonction du suivi inertiel du contrôleur lui-même.
  • Précision élevée (risque de perdre) : Lorsque l’utilisateur déplace le contrôleur de mouvement au-delà du bord du champ de vue 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 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 de temps, les positions du contrôleur sont passées à des positions approximatives de précision. À ce stade, le système verrouille le contrôleur à l’utilisateur, en suivant la position de l’utilisateur lorsqu’il se déplace, tout en exposant l’orientation réelle du contrôleur à l’aide de ses capteurs d’orientation interne. De nombreuses applications qui utilisent des contrôleurs pour pointer vers et activer des éléments d’interface utilisateur peuvent fonctionner normalement alors qu’elles sont approximatives sans que l’utilisateur ne remarque. Les applications avec des exigences d’entrée plus lourdes peuvent choisir de détecter cette baisse de précision élevée à précision approximative en inspectant la propriété PositionAccuracy , par exemple pour donner à l’utilisateur un hitbox plus généreux sur les cibles hors écran pendant ce temps.
  • Aucune position : Bien que le contrôleur puisse fonctionner à une précision approximative pendant un certain temps, 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 qui a été activé n’a peut-être jamais été observé visuellement, ou un utilisateur peut mettre un contrôleur qui est ensuite récupéré par quelqu’un d’autre. À ce stade, le système ne fournira aucune position à l’application, et TryGetPosition retournera false.

API Unity communes (Input.GetButton/GetAxis)

Namespace: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) Ergonomies, 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 appuyé 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 à des noms logiques dans unity Input Manager, en liant un bouton ou des ID d’axe à chaque nom. Vous pouvez ensuite écrire du code qui fait référence à ce nom logique de bouton/axe.

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 > de projet dans Unity et 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 vérifier l’action Envoyer à l’aide d’Input.GetButton :

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

Vous pouvez ajouter d’autres boutons logiques en modifiant la propriété Size sous Axes.

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

Vous pouvez également accéder manuellement aux boutons 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 pose de poignée du contrôleur (où l’utilisateur maintient le contrôleur), qui est utile pour restituer une épée ou une arme dans la main de l’utilisateur, ou un modèle du contrôleur lui-même.

La relation entre cette pose de poignée et la pose de pointeur (où la pointe du contrôleur pointe) peut différer entre les contrôleurs. À ce stade, l’accès à la pose de pointeur du contrôleur n’est possible que par le biais de l’API d’entrée spécifique à MR, 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 supprimées progressivement en faveur du SDK XR dans les futures versions d’Unity. Pour les nouveaux projets, nous vous recommandons d’utiliser le Kit de développement logiciel (SDK) XR à partir du début. Vous trouverez plus d’informations sur le système d’entrée XR et les API ici.

Namespace: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 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 ce frame 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 dans le temps. InteractionSourceState expose des informations telles que :

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

    if (interactionSourceState.selectPressed) {
         // ...
    }
    
  • Autres données spécifiques aux contrôleurs de mouvement, telles que le pavé tactile et/ou les coordonnées XY du stick et l’état tactile

    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 postures de rendu prédites vers l’avant

  • Lors de l’interrogation des données sources d’interaction à partir des mains et des contrôleurs, les poses que vous obtenez sont prédites vers l’avant pendant le moment où les photons de ce cadre atteignent les yeux de l’utilisateur. Les poses prédites vers l’avant sont les plus utilisées pour le rendu du contrôleur ou un objet maintenu par image. Si vous ciblez une presse ou un communiqué donné avec le contrôleur, cela sera le 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 ce cadre actuel. Comme avec la pose source, cela est utile pour le rendu d’un curseur, bien que le ciblage d’une presse ou d’un communiqué donné soit 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 d’historique 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 avez souscrit à un événement d’interaction, vous obtenez le rappel le cas échéant. Dans l’exemple SourcePressed , il s’agit d’une fois la source détectée et avant sa libération ou sa perte.

    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 (source devient active)
  • InteractionSourceLost (devient inactif)
  • InteractionSourcePressed (appuyez, appuyez sur le bouton ou « Sélectionner » énoncé)
  • InteractionSourceReleased (fin d’un appui, d’un bouton relâché ou de la fin de l’énoncé « Sélectionner »)
  • InteractionSourceUpdated (déplacement ou modification d’un état)

Événements pour le ciblage historique pose qui correspondent le plus précisément à une presse ou un communiqué

Les API d’interrogation décrites précédemment donnent à votre application des postures prédites par transfert. Bien que ces poses prédites soient optimales 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 sur Bluetooth avant que le système ne reçoive l’appui.
  • Ensuite, si vous utilisez une pose prédite avant, il y aurait un autre 10 à 20 ms de prédiction avant 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 vers l’avant de l’endroit où la tête et les mains de l’utilisateur étaient réellement de retour lorsque la presse ou le communiqué s’est produit. Pour l’entrée manuelle holoLens, alors qu’il n’existe aucun délai de transmission sans fil, il existe un délai de traitement similaire pour détecter la pression.

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

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

  • La pose de la tête au moment où un mouvement ou une pression de contrôleur s’est produite, qui peut être utilisé pour cibler pour 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;
             // ...
         }
    }
    
  • La pose source au moment où une pression de contrôleur de mouvement s’est produite, qui peut être utilisée pour cibler pour déterminer à quel point l’utilisateur pointait le contrôleur. Il s’agit de l’état du contrôleur qui a connu la presse. Si vous affichez le contrôleur lui-même, vous pouvez demander la pose de pointeur plutôt que la pose de poignée, pour tirer le rayon de ciblage à partir de ce que l’utilisateur considérera 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 didacticiels pas à pas, avec des exemples de personnalisation plus détaillés, sont disponibles dans la Mixed Reality Academy :

Mr Input 213 - Contrôleur de mouvement
Mr Input 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 mis en place, vous êtes au milieu de l’exploration des blocs de construction principaux MRTK. À partir de là, vous pouvez passer au module suivant :

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

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

Voir aussi