Contrôleurs de mouvement dans Unity

il existe deux façons principales d’agir sur votre point d'intergression, les gestes manuels et les contrôleurs de mouvement dans HoloLens et les HMDs immersifs. 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 d’entrée. GetButton/input. GetAxis courantes fonctionnent sur plusieurs kits de développement logiciel (sdk) XR unity, tandis que l’api InteractionManager/GestureRecognizer propre à Windows Mixed Reality expose l’ensemble complet des données d’entrée spatiale.

API d’entrée Unity XR

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

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

Bouton Unity/table de mappage des axes

le gestionnaire d’entrée d’unity pour Windows Mixed Reality contrôleurs motion prend en charge les id de bouton et d’axe listés ci-dessous via les api Input. GetButton/GetAxis . la colonne « Windows propre à MR » fait référence aux propriétés disponibles à partir du type InteractionSourceState . Chacune de ces API est décrite en détail dans les sections ci-dessous.

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

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

  1. Le mappage utilise des ID de pavé tactile distincts du stick analogique, pour prendre en charge des contrôleurs avec Thumbsticks et des pavés tactiles.
  2. Le mappage évite de surcharger les ID de bouton A et X pour les boutons de menu afin de les rendre disponibles pour les boutons ABXY physiques.
Entrée API Unity courantes
(Input. GetButton/GetAxis)
Windows API d’entrée spécifique à MR
XR. WSA. Entrée
Main gauche À 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 enfoncé Bouton 14 (compatibilité du boîtier de l’option) Bouton 15 (compatibilité du boîtier de l’option) selectPressedAmount > 0,0
Bouton de menu enfoncé Bouton 6 * Bouton 7 * menuPressed
Bouton de préhension enfoncé Axe 11 = 1,0 (aucune valeur analogique)
Bouton 4 (compatibilité du boîtier de l’option)
Axe 12 = 1,0 (aucune valeur analogique)
Bouton 5 (compatibilité du boîtier de l’option)
saisi
Stick analogique X (gauche :-1,0, droite : 1,0) Axe 1 Axe 4 thumbstickPosition. x
Joystick Y (haut :-1,0, bas : 1,0) Axe 2 Axe 5 thumbstickPosition. y
Stick analogique appuyé 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 touché Bouton 18 * Bouton 19 * touchpadTouched
Pavé tactile enfoncé Bouton 16 * Bouton 17 * touchpadPressed
pose de la poignée ou du pointeur 6DoF Poignée de pose uniquement : XR. InputTracking. GetLocalPosition
XR. InputTracking.GetLocalRotation
Poignée ou pointeur en tant qu’argument : SourceState. sourcePose. TryGetPosition
sourceState.sourcePose.TryGetRotation
État du suivi Précision de la position et risque de perte de source uniquement disponible via une 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 les OpenVR en raison de collisions dans les mappages utilisés par les boîtiers de soucodeurs, Oculus touch et OpenVR.

OpenXR

Pour connaître les principes de base des interactions de réalité mixte dans Unity, visitez le Manuel Unity pour l’entrée Unity XR. Cette documentation Unity couvre les mappages entre les entrées spécifiques au contrôleur et les InputFeatureUsages plus généralisables, la manière dont les entrées XR disponibles peuvent être identifiées et catégorisées, comment lire les données à partir de ces entrées, et bien plus encore.

Le plug-in OpenXR de réalité mixte fournit des profils d’interaction d’entrée supplémentaires, mappés à des InputFeatureUsage standard, comme indiqué ci-dessous :

InputFeatureUsage Contrôleur de réverbération HP G2 (OpenXR) HoloLens Main (OpenXR)
primary2DAxis Croix
primary2DAxisClick Manette de jeu-clic
déclencheur Déclencheur
délicat Délicat Appuyez ou appuyez sur l’air
primaryButton [X/A]-Appuyez sur Clic aérien
secondaryButton [Y/B]-Appuyez sur
gripButton Appuyez sur la poignée
triggerButton Déclencher-appuyer sur
menuButton Menu

Poignée de pose et pose de pointage

Windows Mixed Reality prend en charge les contrôleurs de mouvement dans un large éventail de facteurs de forme. La conception de chaque contrôleur diffère dans sa relation entre la position de l’utilisateur et la direction « 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 genres de poses que vous pouvez examiner pour chaque source d’interaction, le pose de la poignée et le pointeur se posent. Les coordonnées de pose de la poignée et du pointeur sont exprimées par toutes les API Unity dans les coordonnées universelles Unity universel.

Poignée de pose

la poignée représente l’emplacement de la paume des utilisateurs, qu’elle soit détectée par un HoloLens ou qu’elle détient un contrôleur de mouvement.

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

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

  • Position de la poignée: le centre de la poche quand il maintient le contrôleur naturellement, ajusté à gauche ou à droite pour centrer la position au sein de la poignée. sur le contrôleur de mouvement Windows Mixed Reality, cette position s’aligne généralement avec le bouton de saisie.
  • 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 normal à votre paume (en avant à partir de la poche de gauche, en arrière depuis la paume de droite)
  • Axe avant de l’orientation de la poignée: quand vous fermez partiellement votre main (comme si vous détenir le contrôleur), le rayon qui pointe vers l’avant dans le tube formé par vos doigts non thumbs.
  • Axe vers le haut de l’orientation: l’axe vers le haut, impliqué dans les définitions Right et Forward.

Vous pouvez accéder à la poignée à l’aide de l’API d’entrée entre fournisseurs de l’unité Unity (XR. InputTracking. GetLocalPosition/rotation) ou à l’aide de la Windows API propre à MR (sourceState. sourcePose. TryGetPosition/rotation, demandant des données de pose pour le nœud de poignée ).

Pose du pointeur

Le pointeur de pose représente l’extrémité du contrôleur pointant vers l’avant.

Le pointeur fourni par le système est le mieux utilisé pour raycast lorsque vous effectuez le rendu du modèle de contrôleur lui-même. Si vous effectuez le rendu d’un autre objet virtuel à la place du contrôleur, tel qu’un pistolet virtuel, vous devez faire pointer un rayon qui est le plus naturel pour cet objet virtuel, tel qu’un rayon qui traverse le canon du modèle de pistolet défini par l’application. Étant donné que les utilisateurs peuvent voir l’objet virtuel et non le contrôleur physique, le fait de pointer avec l’objet virtuel sera probablement plus naturel pour ceux qui utilisent votre application.

actuellement, le pointeur de pose est disponible dans unity uniquement par le biais de la Windows API spécifique à MR, sourceState. sourcePose. TryGetPosition/Rotation, en passant InteractionSourceNode. pointeur comme argument.

OpenXR

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

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

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

Les poses fournies par les InputFeatureUsages DevicePosition, DeviceRotation, DeviceVelocity et DeviceAngularVelocity représentent toutes la pose de la poignée OpenXR. Les InputFeatureUsages relatives aux poses de poignée sont définis dans les CommonUsagesd’Unity.

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

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

Haptique

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

État du suivi du contrôleur

à l’instar des 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 en dehors du champ de vue du casque, Windows continue à déduire les positions des contrôleurs dans la plupart des cas. Lorsque le contrôleur a perdu le suivi visuel suffisamment longtemps, les positions du contrôleur sont découpées à des positions de précision approximatives.

À ce stade, le système va verrouiller le contrôleur à l’utilisateur, en effectuant le suivi de la position de l’utilisateur lors de son déplacement, 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 remarque.

Raisonnement sur le suivi de l’État explicitement

Les applications qui souhaitent traiter différemment les positions 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 du suivi SourceLossRisk PositionAccuracy TryGetPosition
Haute précision < 1,0 Élevé true
Haute précision (risque de perte) = = 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 : Alors que le contrôleur de mouvement se trouve dans le champ de vision du casque, il fournit généralement des positions à grande précision, en fonction du suivi visuel. Un contrôleur mobile qui laisse momentanément le champ de vue ou est momentanément masqué des capteurs du casque (par exemple, par l’autre côté de l’utilisateur) continue à retourner des poses de grande précision pendant une brève période, en se basant sur le suivi inertiel du contrôleur lui-même.
  • Haute précision (risque de perte) : 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 la position du contrôleur. L’application sait quand le contrôleur a atteint cette limite d’aide en regardant le SourceLossRisk REACH 1,0. À ce stade, l’application peut choisir de suspendre les gestes de contrôleur qui nécessitent un flux constant de poses de haute qualité.
  • Précision approximative : Lorsque le contrôleur a perdu le suivi visuel suffisamment longtemps, les positions du contrôleur sont découpées à des positions de précision approximatives. À ce stade, le système va verrouiller le contrôleur à l’utilisateur, en effectuant le suivi de la position de l’utilisateur lors de son déplacement, 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, tout en ayant une précision approximative, sans que l’utilisateur ne remarque. Les applications avec des exigences d’entrée plus lourdes peuvent choisir de déterminer ce déplacement de la haute précision à une précision approximative en inspectant la propriété PositionAccuracy , par exemple pour accorder à l’utilisateur un hitbox plus généreux sur les cibles hors écran pendant cette période.
  • Aucune position : Alors que le contrôleur peut fonctionner à des fins de 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 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 moment-là, le système ne fournit pas de position à l’application, et TryGetPosition retourne la valeur false.

API Unity courantes (Input. GetButton/GetAxis)

Espace de noms : UnityEngine, UnityEngine. XR
Types: Input, XR. InputTracking

unity utilise actuellement ses api d’entrée. GetButton/input. GetAxis pour exposer l’entrée pour le kit de développement logiciel (sdk) Oculus, le kit de développement logiciel (sdk) OpenVR et le Windows Mixed Reality, y compris les contrôleurs mains et motion. Si votre application utilise ces API pour l’entrée, elle peut facilement prendre en charge des contrôleurs de mouvement sur plusieurs kits de développement logiciel (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 commencez généralement par associer des boutons et des axes aux noms logiques dans le Gestionnaire d’entrée Unity, en liant un bouton ou des ID d’axe à chaque nom. Vous pouvez ensuite écrire du code qui fait référence à ce nom d’axe/bouton logique.

par exemple, pour mapper le bouton de déclenchement du contrôleur de mouvement gauche à l’action envoyer, accédez à modifier > Project Paramètres > entrée dans unity, puis développez les propriétés de la section Submit sous Axes. Modifiez le bouton positif ou la propriété ALT positive du bouton pour lire le bouton de la manette de jeu 14, comme suit :

InputManager d’Unity
InputManager Unity

Votre script peut ensuite Rechercher l’action envoyer à l’aide de Input. GetButton:

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

Vous pouvez ajouter des boutons logiques en modifiant la propriété taille sous axes.

Obtention directe d’un état enfoncé d’un bouton physique

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

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

Obtention d’une main ou d’une pose de 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 poignée du contrôleur (où l’utilisateur détient le contrôleur), qui est utile pour le rendu d’une arme ou d’un pistolet dans la main de l’utilisateur, ou un modèle du contrôleur lui-même.

La relation entre cette poignée se pose et le pointeur pose (où l’extrémité du contrôleur pointe) peut varier d’un contrôle à l’autre. À ce stade, l’accès au pointeur du contrôleur est possible uniquement via 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, elles sont en passe en faveur du kit de développement logiciel (SDK) XR dans les futures versions 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 les Windows Mixed Reality d’entrée (pour HoloLens) et les contrôleurs de mouvement, vous pouvez choisir d’utiliser les api d’entrée spatiale propres à l’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 genre de source, vous permettant de distinguer les mains et les contrôleurs.

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

Vous pouvez interroger l’état de ce frame pour chaque source d’interaction (contrôleur de main ou 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 à l’instant courant. InteractionSourceState expose des informations telles que :

  • Quels sont les types d’enfoncement (Select/menu///-pavé/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 et l’État touché

    if (interactionSourceState.touchpadTouched && interactionSourceState.touchpadPosition.x > 0.5) {
         // ...
    }
    
  • InteractionSourceKind à savoir si la source est une main ou un contrôleur de mouvement

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

Interrogation pour les poses de rendu prédits par progression

  • Lors de l’interrogation des données sources d’interaction à partir de mains et de contrôleurs, les poses que vous recevez sont des poses prédites pour le moment où les photons de ce frame atteindront les yeux de l’utilisateur. Les poses préprédits sont préférables pour le rendu du contrôleur ou de l’objet détenu dans chaque frame. Si vous ciblez une pression ou une mise en route donnée avec le contrôleur, celles-ci seront plus précises si vous utilisez les API d’événements historiques 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éprédite pour ce frame actuel. Comme avec la source, cela est utile pour le rendu d’un curseur, bien que le ciblage d’une presse ou d’une version donnée soit plus précis si vous utilisez les API d’événements historiques 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 de source d’interaction

Pour gérer les événements d’entrée à mesure qu’ils se produisent avec leurs données d’historique exactes, vous pouvez gérer les événements de source d’interaction au lieu d’interroger.

Pour gérer les événements de source d’interaction :

  • Inscrivez-vous pour 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 êtes abonné à un événement d’interaction, vous obtiendrez le rappel le cas échéant. Dans l’exemple SourcePressed , c’est une fois que la source a été détectée et avant qu’elle soit libéré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 si vous détruisez l’objet qui s’est abonné à l’événement. Pour arrêter la gestion de l’événement, vous devez vous désabonner de l’événement.

InteractionManager.InteractionSourcePressed -= InteractionManager_InteractionSourcePressed;

Liste des événements de source d’interaction

Les événements de la source d’interaction disponibles sont les suivants :

  • InteractionSourceDetected (la source devient active)
  • InteractionSourceLost (devient inactif)
  • InteractionSourcePressed (appuyez sur, appuyez sur le bouton ou sélectionnez « Sélectionner »)
  • InteractionSourceReleased (fin d’un TAP, d’un bouton relâché ou d’une fin de « SELECT »)
  • InteractionSourceUpdated (déplace ou change un État)

Les événements pour le ciblage historique posent qui correspondent le plus précisément à une pression ou à une mise en sortie

Les API d’interrogation décrites précédemment fournissent à votre application des poses préprédits. Bien que ces éléments prédits soient les plus adaptés pour le rendu du contrôleur ou d’un objet de poche virtuel, les nouvelles poses ne sont pas optimales pour le ciblage, pour deux raisons principales :

  • quand 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 la presse.
  • Ensuite, si vous utilisez une pose préprédite, il y aura une autre 10-20 ms de prédiction de transfert appliquée pour cibler le moment où les photons du frame actuel atteindront les yeux de l’utilisateur.

Cela signifie que l’interrogation vous donne une source de pose ou de tête qui est de 30-40 ms à partir de là où la tête et la mains de l’utilisateur ont été retirées lorsque l’appui ou la mise en place a eu lieu. pour une entrée de 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 avec précision en fonction de l’intention initiale de l’utilisateur pour une presse ou un contrôleur, vous devez utiliser la base de l’historique de la source ou de l’en-tête à partir de cet événement d’entrée InteractionSourcePressed ou InteractionSourceReleased .

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

  • L’en-tête pose au moment où un mouvement ou un contrôleur s’est produit, ce qui peut être utilisé pour cibler pour déterminer à quoi l’utilisateur a Gazing :

    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 source pose au moment où une pression du contrôleur de mouvement s’est produite, qui peut être utilisée pour le ciblage afin de déterminer le point de contrôle de l’utilisateur sur le contrôleur. Il s’agit de l’état du contrôleur qui a rencontré la presse. Si vous effectuez le rendu du contrôleur lui-même, vous pouvez demander le point de pose plutôt que le pose de la poignée pour faire tourner le ciblage de la cible à partir de ce que l’utilisateur prendra en compte l’astuce 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 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 disposé, vous êtes au cœur de l’exploration des blocs de construction MRTK Core. À partir d’ici, vous pouvez passer au composant 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