Contrôleurs de mouvement dans Unity
Il existe deux façons clés de prendre des mesures sur votre regard dans Unity, les mouvements de main et les 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 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 spatiale.
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 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 « 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 Kets.
Les mappages d’ID de bouton/axe pour Windows Mixed Reality diffèrent des mappages d’OpenVR de deux façons :
- Le mappage utilise des ID de pavé tactile distincts du stick, pour prendre en charge les contrôleurs avec des touches tactiles et des pavés tactiles.
- Le mappage évite de surcharger les ID de bouton A et X pour les boutons Menu pour les laisser disponibles pour les boutons ABXY physiques.
| Entrée | API 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 un 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ée | 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 |
| Pouce 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 à pouce 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 |
|
Remarque
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 commandes, Vpns Touch 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 Mixed Reality OpenXR fournit des profils d’interaction d’entrée supplémentaires, mappés aux éléments InputFeatureUsagestandard, comme indiqué ci-dessous :
| InputFeatureUsage | Contrôleur HP Reverb G2 (OpenXR) | HoloLens Hand (OpenXR) |
|---|---|---|
| primary2DAxis | Joystick | |
| primary2DAxisClick | Joystick - Clic | |
| trigger | Déclencheur | |
| poignée | Poignée | Appuyez ou appuyez sur l’air |
| primaryButton | [X/A] - Appuyez sur | Cliquer dans l’air |
| secondaryButton | [Y/B] - Appuyez sur | |
| gripButton | Poignée - Appuyez sur | |
| triggerButton | Déclencheur - Appuyez sur | |
| menuButton | Menu |
Pose de poignée par rapport à la 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 de 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 poses 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 en tenant 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 la paume lors de la tenue du contrôleur naturellement, ajusté à gauche ou à droite pour centrer la position dans 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 l’orientation de l’poignée : lorsque vous ouvrez complètement votre main pour former une pose plate à 5 doigts, le rayon normal de 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 votre main (comme si elle 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 poignée par le biais de l’API d’entrée inter-fournisseurs d’Unity (XR). InputTracking. GetLocalPosition/Rotation) ou via l’API spécifique à MR Windows (sourceState.sourcePose.TryGetPosition/Rotation, demandant des données de pose pour le nœud Grip ).
Pose de pointeur
La pose de pointeur représente l’extrémité 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 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 poses 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 vers le monde.
Vous trouverez plus d’informations sur cette conception et les différences entre les deux poses 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 entréesFeatureUsages liées aux postures de poignée sont définies dans CommonUsages d’Unity.
Les poses fournies par InputFeatureUsages PointerPosition, PointerRotation, PointerVelocity et PointerAngularVelocity représentent toutes la pose de but 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, vous trouverez la documentation dans le manuel Unity pour l’entrée XR Unity - 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 longtemps, les positions du contrôleur tombent à des positions de précision approximative.
À ce stade, le système verrouille le contrôleur à l’utilisateur, suivi de la position de l’utilisateur lorsqu’il se déplace, tout en exposant la véritable orientation 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 tout en exactitude approximative sans que l’utilisateur note.
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 fournira généralement des positions de haute précision, basées sur le suivi visuel. Un contrôleur de déplacement qui laisse momentanément le champ de vue ou est momentanément masqué à partir des capteurs du casque (par exemple, par l’autre main de l’utilisateur) continuera de retourner des poses de haute précision pendant un court instant, en fonction du suivi inertiel du contrôleur lui-même.
- Précision élevée (au 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 la version 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 tombent à des positions approximatives de précision. À ce stade, le système verrouille le contrôleur à l’utilisateur, suivi de la position de l’utilisateur lorsqu’il se déplace, tout en exposant la véritable orientation 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, tandis qu’elles sont en précision approximative sans que l’utilisateur note. Les applications avec des exigences d’entrée plus lourdes peuvent choisir de détecter cette baisse de la précision élevée à la précision approximative en inspectant la propriété PositionAccuracy , par exemple pour donner à l’utilisateur une zone d’accès plus généreuse sur les cibles hors écran pendant ce temps.
- 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 déposer 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 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) Occus, 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 à 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 > du projet dans Unity et développez les propriétés de la section Envoyer sous Axes. Modifiez la propriété Bouton Positif ou Bouton Positif Alt pour lire le bouton joystick 14, comme suit :
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);
Remarque
Le code ci-dessus représente la pose de poignée du contrôleur (où l’utilisateur contient le contrôleur), qui est utile pour rendre 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 KIT de développement logiciel (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.
Espace de noms : UnityEngine.XR.WSA.Input
Types : InteractionManager, InteractionSourceState, InteractionSource, InteractionSourceProperties, InteractionSourceKind, InteractionSourceLocation
Pour obtenir des informations plus détaillées sur les entrées manuelles Windows Mixed Reality (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. InteractionSourceState expose des informations telles que :
Quels types de presses se produisent (Select/Menu/Grasp/Touchpad/Thumbstick)
if (interactionSourceState.selectPressed) { // ... }Autres données spécifiques aux contrôleurs de mouvement, telles que les coordonnées XY du pavé tactile et/ou du stick numérique 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 poses de rendu prédites vers l’avant
Lors de l’interrogation des données sources d’interaction provenant des mains et des contrôleurs, les poses que vous obtenez sont prédites à l’avance pour le moment où les photons de ce cadre atteignent les yeux de l’utilisateur. Les poses prédictées vers l’avant sont mieux utilisées pour le rendu du contrôleur ou d’un objet détenu chaque image. Si vous ciblez une presse ou une publication donnée 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 cette trame actuelle. Comme pour la pose 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é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 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és)
- InteractionSourceReleased (fin d’un appui, d’un bouton libéré ou de la fin de l’énoncé « Sélectionner »)
- InteractionSourceUpdated (déplace ou modifie un état)
Événements pour les positions de ciblage historique 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 poses 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 la pression.
- Ensuite, si vous utilisez une pose prédite vers l’avant, il y aurait un autre 10-20 ms de prédiction avant appliquée pour cibler l’heure à laquelle les photons du cadre actuel atteindreont 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 avant à partir de l’endroit où la tête et les mains de l’utilisateur ont réellement été de retour lorsque la presse ou le communiqué s’est produit. Pour l’entrée manuelle holoLens, bien qu’il n’y ait aucun 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 d’origine de l’utilisateur pour une pression de main ou de contrôleur, vous devez utiliser la pose de source historique ou la pose de tête à 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 historique à 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 du contrôleur s’est produit, 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 à quoi l’utilisateur pointait le contrôleur. Il s’agit de l’état du contrôleur qui a connu la presse. Si vous effectuez le rendu du 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 l’extrémité 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 mouvement et au contrôleur 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
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 en train d’explorer les blocs de construction principaux MRTK. À 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.