Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Il existe deux façons clés d’agir sur votre regard dans Unity : les mouvements de la 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 de développement logiciel (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 façons :
- Le mappage utilise des ID de pavé tactile distincts de la manette pour prendre en charge les contrôleurs avec des manettes et des pavés tactiles.
- 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.
| Input |
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 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 (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 |
| Stick numérique Y (haut : -1.0, bas : 1.0) | Axe 2 | Axe 5 | thumbstickPosition.y |
| Manette 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* | pavé tactilePressed |
| Pose de poignée ou pointeur 6DoF |
Prise en main uniquement : XR. InputTracking.GetLocalPosition XR. InputTracking.GetLocalRotation | Passez Grip ou Pointeur en tant qu’argument : sourceState.sourcePose.TryGetPosition sourceState.sourcePose.TryGetRotation |
|
| État de suivi | Précision de position et risque de perte de source disponibles uniquement via l’API mr spécifique |
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 commande, Oculus Touch et OpenVR.
OpenXR
Pour en savoir plus sur les bases des interactions de réalité mixte dans Unity, consultez le Manuel Unity pour Unity XR Input. Cette documentation Unity couvre les mappages entre les entrées spécifiques au contrôleur et les entrées inputFeatureUsageplus généralisables, la façon dont les entrées XR disponibles peuvent être identifiées et classées, la lecture 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 à inputFeatureUsagestandard, comme indiqué ci-dessous :
| InputFeatureUsage | Contrôleur HP Reverb G2 (OpenXR) | HoloLens Hand (OpenXR) |
|---|---|---|
| primary2DAxis | Joystick | |
| primary2DAxisClick | Joystick - Cliquez sur | |
| Déclencheur | Déclencher | |
| Poignée | Poignée | Pression ou pression d’air |
| primaryButton | [X/A] - Appuyez sur | Appuyez sur l’air |
| secondaryButton | [Y/B] - Appuyez sur | |
| gripButton | Poignée - Appuyer 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 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 poignée et la pose de pointeur. Les coordonnées de pose de poignée et de pose de pointeur sont exprimées par toutes les API Unity dans les coordonnées mondiales Unity.
Pose de la poignée
La position de poignée 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 la poignée est mieux utilisée pour restituer la main de l’utilisateur ou un objet tenu 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 origine et centre de rotation.
La pose de la poignée est définie spécifiquement comme suit :
- Position de la poignée : centroïde de la paume lorsque vous maintenez le 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.
- 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 votre main (comme si vous maintenez 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 poignée : 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 windows MR (sourceState.sourcePose.TryGetPosition/Rotation, demandant des données de pose pour le nœud Grip ).
Pose du pointeur
La pose du 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 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 pointer avec un rayon qui est 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 du pointeur est disponible dans Unity uniquement par le biais de l’API spécifique à Mr Windows, sourceState.sourcePose.TryGetPosition/Rotation, en passant 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
- Le but est de pointer dans 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. InputFeatureUsages liés aux poses de grip sont définis dans CommonUsages d’Unity.
Les poses fournies par inputFeatureUsages PointerPosition, PointerRotation, PointerVelocity et PointerAngularVelocity représentent toutes la pose de l’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 haptique dans le système d’entrée XR d’Unity, vous trouverez la documentation dans le Manuel Unity pour Unity XR Input - Haptics.
État de 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 de vision 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 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 le suivi explicite de l’état
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 |
|---|---|---|---|
| Haute précision | < 1.0 | Élevé | true |
| Haute précision (risque de perdre) | == 1,0 | Élevé | true |
| Précision approximative | == 1,0 | Approximative | true |
| Aucune position | == 1,0 | Approximative | 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 positions 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 sera bientôt incapable de 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 constant 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 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 s’en rendre compte. 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 donner à l’utilisateur un hitbox plus généreux 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 qui a été activé peut n’avoir 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 false.
API Unity courantes (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 SDK Oculus, le 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 commencez 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 d’axe/bouton 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 et développez les propriétés de la section Envoyer sous Axes. Modifiez la propriété Bouton positif ou Bouton positif de remplacement pour lire le bouton du joystick 14, comme suit :
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 d’autres boutons logiques en modifiant la propriété Size sous Axes.
Obtention de l’état d’appui 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);
Remarque
Le code ci-dessus représente la position de la poignée 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 poignée et la pose de pointeur (où pointe la pointe du contrôleur) peut différer d’un contrôleur à l’autre. À l’heure actuelle, l’accès à la pose de pointeur du contrôleur n’est possible que par le biais de l’API d’entrée propre à 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 progressivement supprimées 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 dès le 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 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 trame 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 obtenez représente une source d’interaction au moment actuel. InteractionSourceState expose des informations telles que :
Les types d’appuis qui se produisent (Sélectionner/Menu/Saisir/Pavé tactile/Manette)
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 pavé 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 avant
Lors de l’interrogation des données sources d’interaction des mains et des contrôleurs, les poses que vous obtenez sont des poses prédites pour le moment où les photons de ce cadre atteignent les yeux de l’utilisateur. Les poses prédites avant sont mieux utilisées pour le rendu du contrôleur ou d’un objet tenu à chaque image. Si vous ciblez une presse ou une mise en production 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 pour ce cadre actuel. Comme pour la pose source, cela est utile pour afficher un curseur, bien que le ciblage d’une presse ou d’une mise en production 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 tels 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’interrogation.
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 êtes abonné à un événement d’interaction, vous recevez le rappel le cas échéant. Dans l’exemple SourcePressed , cela se produit après la détection de la source 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 de gérer 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 inactive)
- InteractionSourcePressed (appuyez, appuyez sur un bouton ou « Sélectionner » énoncé)
- InteractionSourceReleased (fin d’un appui, d’un bouton relâché ou de la fin de « Sélectionner » énoncé)
- InteractionSourceUpdated (déplace ou modifie un état)
Événements pour les poses de ciblage historique qui correspondent le plus précisément à 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 de poche 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 avant, une autre prédiction de 10 à 20 ms est appliquée pour cibler l’heure à laquelle les photons du cadre actuel atteignent les yeux de l’utilisateur.
Cela signifie que l’interrogation vous donne une pose source ou une pose de tête de 30 à 40 ms d’où la tête et les mains de l’utilisateur étaient réellement de retour lorsque la presse ou la libération s’est produite. Pour l’entrée 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 avec précision en fonction de l’intention d’origine de l’utilisateur pour une main ou une pression de 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 mise en production avec des données de pose historiques provenant de la tête de l’utilisateur ou de son contrôleur :
La position de la tête au moment où un mouvement ou une pression de contrôleur s’est produit, qui peut être utilisé pour le ciblage 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; // ... } }La position source au moment où une pression sur le contrôleur de mouvement s’est produite, qui peut être utilisée pour le ciblage 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 poignée, 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.
Suivez les didacticiels
Des didacticiels 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
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 de MRTK. À partir de là, vous pouvez passer au bloc de construction suivant :
Ou passez à Mixed Reality fonctionnalités et API de la plateforme :
Vous pouvez toujours revenir aux points de contrôle de développement Unity à tout moment.