Virtual Reality | Étienne Peillard

TP — Interaction 3D : techniques de manipulation

Thu, 15 Oct 2026 00:00:00 +0000

RVRA · RVSI · Interaction 3D

Tâche expérimentale: Construire une tour · 2 min par essai
Projet fourni: Unity 6.3 · XRI 3.3.0
OpenXR 1.16.0
Prérequis: Bases Unity et VR · Casque et contrôleurs

Vous allez comparer des techniques de manipulation sur une tâche commune : construire une tour de blocs bleus et jaunes en deux minutes. L’objectif est de comprendre comment la sélection, le point de saisie et l’interaction à distance influencent la précision, la rapidité et l’effort.

Ce TP prolonge les initiations à Unity et à la VR. La scène et les scripts de la tâche sont fournis : votre travail porte sur la configuration des interactions et leur évaluation.

Fichiers du TP Projet Unity 6.3 Scène, scripts et prefabs · ZIP · environ 79 Mo Compte rendu Canevas original Questions et résultats · DOCX en anglais

Pour commencer Les bases d’Unity 3D Initiation VR Sujet original · PDF anglais

IMT Atlantique · Brest TP original de Cédric Fleury, cours de RVRA, parcours RVSI de la FISE.

Plan du TP

La tâche : une tour bicolore

Le générateur bleu à gauche produit des blocs bleus ; le générateur jaune à droite produit des blocs jaunes. Transportez-les sur la plateforme centrale pour construire la tour.

Chaque étage comporte deux blocs de même couleur.
Les blocs d’un étage sont perpendiculaires à ceux de l’étage précédent.
La couleur alterne d’un étage au suivant : bleu, jaune, bleu…
Un essai dure 2 minutes. À la fin, comptez les étages complets encore debout qui respectent ces règles.

Scène du TP original de Cédric Fleury. Le sujet mentionne un record de 19 étages après deux essais : un repère historique, sans objectif imposé pour cette séance.

1. Prendre en main le projet et les interactions de base

Ouvrir la bonne version

Téléchargez le projet Unity 6.3, décompressez-le, puis ajoutez le dossier Interaction3D dans Unity Hub > Add project from disk. Ouvrez le dossier qui contient Assets, Packages et ProjectSettings.
Le projet a été enregistré avec 6000.3.1f1. Utilisez la version prévue pour votre séance et conservez une copie avant toute conversion. Attendez la résolution des packages et vérifiez l’absence d’erreurs dans Console.
Ouvrez Assets/Scenes/Interaction.unity. Repérez les deux générateurs, la plateforme, le chronomètre et les contrôleurs.
Pour un Quest autonome, vérifiez les modules Android de Unity, File > Build Profiles, la plateforme Android/Meta Quest, la scène à construire et les réglages XR. Suivez si nécessaire la partie déploiement du TP d’initiation VR. Faites Build And Run sur le casque préparé pour le développement.

Configuration fournie

Conserver les versions du projet

Le manifeste du projet Unity 6.3 contient XRI 3.3.0, OpenXR 1.16.0 et Input System 1.17.0. Les Starter Assets déjà importés restent dans un dossier nommé 3.1.2 : ce nom indique la version du sample lors de son import. Utilisez ces ressources existantes ; ne réimportez pas automatiquement celles d’une autre version.

Le projet contient aussi le package Oculus. Vérifiez le fournisseur XR actif pour votre plateforme et évitez d’activer simultanément plusieurs fournisseurs pour le même casque. Le TP d’introduction VR utilise des versions légèrement différentes : reprenez sa méthode de configuration, sans remplacer aveuglément les packages ou le rig de ce projet.

Une archive pour Unity 2022.3.49f1 est également disponible pour les séances qui utilisent cet éditeur ; elle contient XRI 3.1.2. Choisissez une seule archive comme point de départ.

Essayer la tâche

Les commandes ci-dessous sont celles du sujet fourni pour les contrôleurs Touch. Vérifiez leurs bindings dans le projet si vous utilisez un autre matériel.

Commande	Action
Joystick gauche	Se déplacer dans la scène.
Bouton X	Changer de mode de navigation, notamment vers la téléportation.
Contact du contrôleur droit + gâchette de l’index	Saisir un bloc ou sélectionner un générateur / le bouton Reset.
Bouton B à droite / Y à gauche	Changer de technique sur la main correspondante, une fois plusieurs modes configurés.

Essayez la navigation continue puis la téléportation. Choisissez une position qui permet d’atteindre les générateurs et la tour.
Générez quelques blocs, saisissez-les, orientez-les puis relâchez-les sur la plateforme.
Réinitialisez la scène et réalisez un premier essai chronométré. Le script fourni démarre le chronomètre à la première génération de bloc après réinitialisation.
Notez votre premier score, puis votre meilleur score après quelques essais. Gardez le même nombre d’essais pour comparer les configurations.

À consigner — partie 1 du compte rendu : les deux scores, le mode de navigation préféré et les raisons de ce choix pour cette tâche.

2. Préparer le changement de technique sur chaque contrôleur

Le composant Controller Manager (ControllerManager.cs) permet de changer d’interactor en cours d’exécution, sans reconstruire l’application pour chaque comparaison.

Sélectionnez le contrôleur droit, puis le gauche, et repérez Controller Manager et son action Switch Mode.
Chaque mode doit être un enfant direct du contrôleur et porter le tag ControllerMode. Prenez le Direct Interactor existant comme exemple.
Ajoutez les prochains modes comme frères du Direct Interactor, dans l’ordre où vous voulez les tester. Vous pouvez placer un ensemble de composants sous une racine de mode portant le tag.
Au démarrage, le script recense ces enfants, désactive les modes puis active le premier. B ou Y passe au suivant en désactivant les autres. Avec un seul mode, le bouton ne produit aucun changement visible.

Exemple de hiérarchie issu du sujet original. Le nom des objets peut légèrement varier.

Vérification : après avoir ajouté un second mode, contrôlez en Play qu’une seule racine de mode est active sur chaque main. Relâchez les objets avant de changer de mode. Le tag doit être placé sur l’enfant direct, car le script ne parcourt pas les petits-enfants pour établir sa liste.

3. Modifier le point de saisie des blocs

La saisie initiale ramène le bloc vers son point d’attache configuré. Comparez-la à une saisie qui conserve le point de contact.

Dupliquez chacun des deux générateurs. Distinguez visuellement les nouvelles versions, tout en gardant une famille bleue et une famille jaune.
Dans Assets/Prefabs, dupliquez Blue_cube et Yellow_cube. Nommez les copies, par exemple, Blue_cube_Dynamic et Yellow_cube_Dynamic.
Sur chaque copie, dans XR Grab Interactable, activez Use Dynamic Attach. Examinez Match Position, Match Rotation et Snap To Collider Volume. Comparez leur effet, un réglage à la fois.
Dans le composant Generate Cube de chaque nouveau générateur, assignez le prefab correspondant au champ Cube. Conservez la référence au chronomètre.
Testez la saisie près du centre puis à une extrémité. Comparez le placement et l’orientation à ceux des blocs d’origine, puis refaites la tâche.

À consigner — partie 3 : avantages et limites de Dynamic Attach pour saisir, tourner et poser les blocs. Appuyez-vous sur des situations observées.

Référence : XR Grab Interactable — documentation Unity.

4. Ajouter un rayon virtuel

Configurer la sélection à distance

Ajoutez un XR Ray Interactor comme enfant du contrôleur droit : clic droit dans Hierarchy, XR > Ray Interactor. Nommez ce mode Ray et ajoutez le tag ControllerMode sur sa racine.
Dans Interaction Layer Mask, autorisez les couches des blocs et des générateurs, mais excluez la couche réservée à la téléportation (nommée Teleport ou Teleport Layer selon le projet).
Dans Input Configuration, configurez Select Input pour la gâchette droite, en reprenant la référence d’action du Direct Interactor fourni. Ne supposez pas que le binding Select du TP précédent utilise le même bouton.
Désactivez UI Interaction pour cette activité. Vérifiez l’origine et la direction du rayon ainsi que ses composants de ligne.
Exécutez, passez au mode Ray avec B, puis testez la génération et la saisie à distance.

Vérification : le rayon sélectionne les blocs et les générateurs, sans déclencher la téléportation. Un objet doit partager une couche d’interaction XRI avec l’interactor et être détectable par son raycast physique : Interaction Layer Mask et Raycast Mask sont deux filtres distincts.

Comparer les variantes

Dupliquez le mode Ray sous le même contrôleur et donnez un nom explicite à chaque variante. Conservez les entrées et les filtres pour ne changer que l’option étudiée.

Variante	Réglage à comparer	Observation attendue
Rayon de base	Force Grab désactivé	Manipulation du bloc à distance.
Rayon avec rappel	Force Grab activé	Le bloc sélectionné est ramené à la main.
Attache manipulable	Manipulate Attach Transform activé	Déplacement de l’attache au joystick ; vérifiez les entrées de translation/rotation.

Refaites un essai avec chaque variante. Examinez l’accès aux générateurs, le transport vers le centre, la rotation des blocs et la précision du relâchement. Si le joystick pilote plusieurs actions, vérifiez leurs bindings et leur concurrence avec la locomotion.

À consigner — partie 4 : bénéfices du rayon par rapport à la saisie directe, bénéfices de la saisie directe, intérêt et limites de Force Grab, utilité de Manipulate Attach Transform, configuration préférée et meilleur score obtenu.

Référence : XR Ray Interactor — documentation Unity.

5. Tester Near Far

Dans Assets/Samples/XR Interaction Toolkit/3.1.2/Starter Assets/Prefabs/Interactors, trouvez Right_NearFarInteractor. Ajoutez-le sous le contrôleur droit comme un nouveau mode.
Placez le tag ControllerMode sur sa racine. Vérifiez les références de main droite, les entrées Select et les filtres d’interaction, comme pour le rayon. Désactivez l’interaction UI pour garder les mêmes conditions.
Testez la sélection d’un bloc proche, puis d’un bloc éloigné. Observez comment la technique combine l’interaction de proximité et à distance.
Comparez Far Attach Mode = Near et Far : dans la documentation XRI 3.3, ce réglage contrôle le rappel à la main ou le maintien à distance. Le sujet original parle de l’option « Force Grab » ; repérez le réglage équivalent dans le composant installé.
Réalisez la tâche avec les deux variantes. Créez deux modes si vous souhaitez les comparer avec B, sans nouvelle compilation.

À consigner — partie 5 : technique vue en cours qui s’en rapproche le plus, avantages et inconvénients pour la tâche, et difficultés éventuelles lors des transitions proche/loin. Justifiez par vos essais.

Référence : Near-Far Interactor — documentation Unity.

6. Manipuler avec les deux mains

Ajoutez aussi des modes de manipulation au contrôleur gauche. Utilisez le prefab Left_NearFarInteractor pour Near Far, ou adaptez les entrées et la latéralité d’un rayon à la main gauche.
Vérifiez les tags et les actions. Y change le mode gauche et B le mode droit ; ne conservez pas les actions de la main droite sur les deux mains.
Testez une combinaison symétrique puis une combinaison où chaque main a un rôle différent : par exemple, approvisionner d’un côté et positionner de l’autre.
Comparez-les à votre meilleure configuration à une main, avec les mêmes règles et la même durée.

L’objectif est de manipuler deux blocs ou de répartir les actions entre les mains. Il n’est pas nécessaire d’activer la sélection simultanée d’un même bloc par les deux contrôleurs.

À consigner — partie 6 : bénéfices de deux techniques, combinaison la plus efficace, justification et meilleur nombre d’étages.

Comparer les résultats et rédiger le compte rendu

Utilisez le canevas original en anglais et les questions traduites dans cette page. Consultez aussi les consignes générales du compte rendu. La numérotation des questions reprend celle du sujet : la partie 2 prépare les interactions et ne possède pas de rubrique distincte dans le canevas.

Pour chaque configuration, gardez une trace des réglages réellement testés :

Configuration	Main gauche / droite	Point de saisie	Options	Essai 1	Meilleur score	Observations
Directe initiale	À préciser	Initial	Navigation choisie	…	…	…
Directe dynamique	À préciser	Dynamique	Réglages d’attache	…	…	…
Rayon	À préciser	À préciser	Force Grab / attache	…	…	…
Near Far	À préciser	À préciser	Far Attach Mode	…	…	…
Deux mains	À préciser	À préciser	Combinaison choisie	…	…	…

Prévoyez un court entraînement comparable, réinitialisez entre les essais et notez le nombre de répétitions. Distinguez la performance mesurée du ressenti : une technique peut être rapide tout en demandant davantage d’effort. L’apprentissage peut améliorer les scores au fil de la séance ; ne concluez pas à la supériorité générale d’une technique sur la base du seul meilleur essai.

Avant de terminer : conservez la scène, les prefabs modifiés et les fichiers Packages. Votre application doit permettre de changer les modes sans reconstruire, de générer les deux couleurs, de réinitialiser la tâche et de la réaliser avec une ou deux mains.

En cas de difficulté

Symptôme	Points à vérifier
B / Y ne change rien	Plusieurs enfants directs tagués ControllerMode, action Switch Mode et ordre dans la hiérarchie.
Le rayon est visible, mais ne saisit rien	Select Input, colliders, Interaction Layer Mask, Raycast Mask et composant interactable sur la cible.
Le rayon déclenche la téléportation	Exclure sa couche des modes de manipulation et vérifier les entrées partagées.
Le nouveau générateur produit les anciens blocs	Champ Cube du composant Generate Cube et prefab réellement modifié.
Near Far utilise la mauvaise main	Prefab gauche/droit, Handedness et références d’actions.
Plus de génération après la fin du temps	Utiliser Reset avant de relancer : le chronomètre fourni exige une réinitialisation.
Le casque ne lance pas la scène	Scène de build, plateforme, fournisseur XR et connexion ; reprendre le TP d’initiation VR.

Auteur et ressources originales

TP original conçu par Cédric Fleury pour le cours de RVRA, parcours RVSI de la FISE IMT Atlantique, campus de Brest. Contact figurant sur le sujet : cedric.fleury@imt-atlantique.fr.

Cette page en propose une adaptation web en français et en anglais, à partir du sujet et des ressources fournis pour l’année 2025–2026. Les illustrations de la tâche et des contrôleurs proviennent du sujet original.

Sujet original — PDF en anglais.
Canevas original du compte rendu — DOCX en anglais.
Projet Unity 6.3 : fichiers du projet conservés ; APK précompilé et métadonnées macOS retirés pour alléger l’archive.
Projet original Unity 2022.3.

TP — Navigation 3D en réalité virtuelle

Thu, 15 Oct 2026 00:00:00 +0000

RVRA · RVSI · Navigation 3D

Objectif: Comparer les locomotions
Environnement: Unity 6.3 · XRI 3.3.0
Projet fourni · Casque VR
Prérequis: Bases Unity et VR

Comment se déplacer efficacement dans un environnement virtuel ? Vous allez tester plusieurs techniques de navigation, régler leurs paramètres et comparer leurs effets sur la recherche de cibles, l’orientation et le confort.

Le projet propose une ville et un petit labyrinthe contenant des boutons rouges, les « buzzers ». Dans le labyrinthe, mesurez le temps nécessaire pour en activer 8. Dans la ville, activez-en le plus possible en 2 minutes.

Ce TP prolonge Les bases d’Unity 3D et Une première application de réalité virtuelle. La tâche de recherche est déjà implémentée : votre travail porte sur les techniques de locomotion et leur évaluation.

Fichiers du TP Télécharger le projet Unity 6.3 / 2022.3 · PDF · Compte rendu Avant de commencer Une première application VR Suivi, contrôleurs, téléportation et build casque

TP original : Cédric Fleury, cours de RVRA, parcours RVSI de la FISE IMT Atlantique, campus de Brest. Adaptation web bilingue à partir du sujet et des projets fournis.

Plan du TP

Ressources et projet de départ

Téléchargez les deux archives d’une même version et extrayez-les dans un même dossier parent : leurs contenus se réunissent dans Navigation3D. Le dossier final doit contenir Assets, Packages et ProjectSettings, avec Assets/VRTemplateAssets. Ajoutez ensuite ce dossier Navigation3D dans Unity Hub. Ne mélangez pas les deux versions.

Version	Projet et scène	Assets du template VR
Unity 6.3 — parcours principal	Projet 6000.3	Assets 6000.3
Unity 2022.3 — alternative	Projet 2022.3	Assets 2022.3

Les téléchargements conservent les fichiers pédagogiques des projets fournis. Les builds, caches et fichiers locaux de l’éditeur ont été écartés ; les fichiers Assets, Packages et ProjectSettings sont conservés sans modification.

Ouvrir et exécuter la scène

Ouvrez Assets/Scenes/Navigation.unity. Attendez la fin de l’import et corrigez les erreurs bloquantes de Console avant de construire l’application.
Pour un casque autonome Android, vérifiez les modules Android de Unity Hub et la configuration XR de la plateforme cible. Dans File > Build Profiles (Unity 6) ou Build Settings (2022.3), sélectionnez Android ou le profil adapté au casque. Vérifiez que la scène Navigation est cochée.
Reprenez si nécessaire les étapes de déploiement du TP d’introduction VR. Sélectionnez le casque, puis lancez Build And Run. Les réglages Android concernent le build autonome ; un essai PC VR dans Play nécessite une configuration et un runtime PC adaptés.
Dans le casque, repérez le panneau de score, le chronomètre, la ville, l’entrée et la sortie du labyrinthe.

Manipuler et mesurer

Commande initiale	Effet
Joystick gauche	Avancer, reculer, se déplacer latéralement.
Joystick droit	Tourner, en complément de la rotation réelle de la tête.
Contrôleur droit au contact d’un buzzer + gâchette sous l’index	Activer la cible : elle devient verte.

Faites un essai libre pour comprendre la tâche et les commandes.
Labyrinthe : activez le buzzer devant le panneau de score, trouvez et activez les 8 buzzers du labyrinthe, puis notez le temps à la sortie.
Ville : démarrez une nouvelle tentative et relevez le nombre de buzzers activés en 2 minutes. Utilisez la remise à zéro du panneau entre les tentatives.
Reportez vos résultats initiaux dans la partie 1 du compte rendu.

Environnements de la tâche de recherche. Illustration issue du sujet original de Cédric Fleury.

2. Configurer le déplacement continu

Dans Hierarchy, dépliez XR Origin, puis Locomotion. Repérez les objets Move et Turn, leurs providers et leurs références d’actions.
Explorez les entrées des deux composants pour choisir la répartition des commandes entre joysticks gauche et droit. Testez une modification à la fois et conservez un moyen de revenir à la configuration initiale.
Réglez la vitesse de translation et celle de rotation. Cherchez un compromis entre déplacement rapide dans les rues, précision dans les couloirs et confort.
Réalisez les deux tâches avec la même configuration et les mêmes paramètres dans la ville et le labyrinthe.
Dans la partie 2 du compte rendu, indiquez les actions assignées à chaque joystick, les vitesses retenues, le temps dans le labyrinthe et le score dans la ville. Justifiez vos choix.

Vérification : le déplacement et la rotation répondent séparément ; une seule commande ne doit pas déclencher deux comportements concurrents.

3. Basculer entre plusieurs techniques

Le script fourni NavigationModeManager, sur Locomotion, permet de changer de technique sans reconstruire l’application à chaque essai.

Inspectez sa référence Switch Mode. Le sujet prévoit le bouton Y du contrôleur gauche ; vérifiez le binding effectivement utilisé sur votre matériel.
Ouvrez le script : il parcourt les enfants directs de l’objet porteur et retient ceux dont le tag est NavigationTechnique. Au démarrage, il active le premier ; chaque appui active le suivant et désactive les autres.
Vérifiez le tag de Move, puis celui des techniques à intégrer. Gardez au moins un enfant correctement tagué. L’ordre des enfants détermine l’ordre de parcours.
Laissez le manager, les actions communes et les composants nécessaires à toutes les techniques actifs. Les objets utilitaires ne doivent pas recevoir ce tag.

Vérification : en Play ou au casque, appuyez plusieurs fois sur Y et observez les objets actifs. Une seule technique de la liste doit être active à la fois. Turn peut rester commun : contrôlez ses entrées avant de réutiliser le joystick droit pour l’échelle.

4. Ajouter la téléportation

L’objet Teleportation est déjà présent dans Locomotion. Vous devez lui associer un rayon de sélection et vérifier ses liens avec les surfaces téléportables.

Retrouvez Teleport Interactor dans Assets/Samples/XR Interaction Toolkit/3.1.2/Starter Assets/Prefabs/Interactors et ajoutez-le sous le contrôleur gauche du rig fourni.
Dans XR Ray Interactor, réglez Interaction Layer Mask pour inclure Teleport. Vérifiez aussi le Raycast Mask et les colliders du sol. Les couches d’interaction XRI et les couches physiques sont deux filtres distincts.
Désactivez UI Interaction et Manipulate Attach Transform pour cet exercice. Assignez Attach Transform et Ray Origin Transform aux transforms appropriés du contrôleur gauche.
Dans Input Configuration, assignez les deux entrées Select à XRI Left Locomotion/Teleport Mode, comme dans le sujet. Vérifiez les références dans l’asset d’actions du projet.
Dans le script Disable Interactor de l’objet Teleportation, affectez le GameObject Teleport Interactor au champ Associated Interactor. Son activation suivra ainsi celle de la technique.
Vérifiez le tag NavigationTechnique de Teleportation, le provider et ses références de locomotion. Vérifiez que le sol possède une surface de téléportation compatible avec la couche Teleport.
Passez à ce mode avec Y. Testez plusieurs destinations au sol, puis revenez au déplacement continu : le rayon de téléportation doit se désactiver.
Comparez les formes de rayon et leurs paramètres de portée. Pour un rayon droit, examinez Max Raycast Distance ; pour une courbe, examinez les paramètres propres à sa forme. Rejouez les deux tâches avec vos réglages retenus.

À consigner — partie 4 : forme et portée du rayon, justification, temps dans le labyrinthe, score dans la ville, avantages et limites par rapport au déplacement continu.

Référence : XR Ray Interactor — paramètres et types de ligne.

L’objectif est de modifier l’échelle de l’utilisateur dans le monde pour observer autrement et parcourir de plus grandes distances. Cette commande doit rester disponible avec le déplacement continu et la téléportation.

Créez un nouvel enfant sous Locomotion pour le contrôle d’échelle. Ne lui donnez pas le tag NavigationTechnique : il doit rester actif quand Y change de technique.
Ajoutez le script fourni ContinuousScaleChangeProvider et renseignez sa référence au Locomotion Mediator du rig.
Dans les Input Actions, recherchez l’action d’échelle prévue par le sujet, XRI RightHand Locomotion/scale, et contrôlez son existence et son binding. Si elle est absente de l’archive utilisée, créez une action Value / Vector2 liée au joystick droit et activez son action map via l’Input Action Manager. Assignez-la à Right Hand Scale Action. Évitez qu’elle déclenche aussi la rotation de Turn.
Lisez le script : les propriétés d’actions et la lecture des joysticks sont fournies, mais Update() contient encore les étapes TODO.
Complétez la lecture de l’entrée, puis la modification de l’échelle uniforme du Transform du XR Origin. Utilisez le temps écoulé pour que la vitesse ne dépende pas de la fréquence d’affichage. Imposez des bornes strictement positives et progressives, et vérifiez la référence au mediator avant de l’utiliser.
Testez d’abord de petites variations. Observez la hauteur, le point autour duquel l’échelle change, la portée des interactions, la vitesse apparente et les collisions.
Ajustez le Teleport Interactor, notamment sa portée et le repère utilisé par le rayon, pour conserver des destinations utilisables aux différentes échelles. Vérifiez séparément le rayon calculé et sa représentation visible.
Ajoutez si possible une commande qui restaure l’échelle initiale, puis testez son utilité lorsque vous perdez vos repères.
Rejouez la tâche de 2 minutes dans la ville avec déplacement continu + échelle, puis téléportation + échelle.

À consigner — partie 5 : scores des deux combinaisons, bénéfices et inconvénients du multi-échelle, technique la plus adaptée et intérêt d’une remise à l’échelle initiale. Décrivez aussi les adaptations nécessaires.

6. Tester Grabbing-the-Air

Cette technique permet de déplacer le monde virtuel par des gestes de saisie, en translation et en rotation.

Inspectez l’objet Grab Move, déjà présent dans Locomotion, et les actions de ses composants. Vérifiez son intégration à la liste des techniques.
Activez ce mode avec Y et identifiez les commandes de saisie. Testez le déplacement avec une main, puis deux mains ; observez le sens du déplacement et les effets sur l’orientation.
Répétez les essais à plusieurs échelles, puis cherchez les 8 buzzers du labyrinthe. Notez le temps et les difficultés rencontrées.
Dans la ville, combinez cette technique avec le contrôle d’échelle et mesurez le score sur 2 minutes.
Pour explorer le déplacement sans blocage par le sol ou les bâtiments, le sujet propose de désactiver le CharacterController du XR Origin. Faites-en un essai distinct, notez ce changement dans le rapport et réactivez-le pour revenir aux conditions précédentes.

À consigner — partie 6 : avantages, limites, précision, effort gestuel et pertinence pour la navigation multi-échelle. Appuyez vos réponses sur des situations observées dans les deux environnements.

Référence du sujet : Grabbing-the-Air — HCI Museum.

7. Bonus : World-in-Miniature et téléportation

Créez une représentation miniature de la ville pour faciliter la recherche des buzzers et choisir une destination à distance.

Affichez une miniature du monde, distincte du décor à l’échelle normale. Évitez d’y dupliquer la logique du score, le rig ou les interactions de la scène principale.
Permettez de viser un point de cette miniature avec un rayon virtuel.
Convertissez le point sélectionné du repère de la miniature vers celui du monde, puis déplacez le rig vers une destination valide. Prenez en compte translation, rotation et échelle de la miniature.
Vérifiez que la destination se trouve dans une zone accessible et que la miniature reste utilisable après le déplacement.
Comparez cette aide à la recherche avec la navigation multi-échelle : repérage des cibles, orientation et précision de la destination.

Sources du sujet : Stoakley, Conway et Pausch, Virtual Reality on a WIM, 1995, démonstration vidéo et exemple UnityWorldInMiniature.

Compte rendu et bilan

Complétez le modèle original. Il est fourni en anglais ; les questions correspondantes sont reprises en français dans cette page. Le tableau ci-dessous sert à rassembler vos résultats ; indiquez les unités, les paramètres et le nombre d’essais.

Condition	Labyrinthe : temps pour 8 buzzers	Ville : buzzers en 2 min	Réglages et observations
Navigation initiale	À mesurer	À mesurer	Configuration fournie
Continu configuré	À mesurer	À mesurer	Mêmes paramètres dans les deux environnements
Téléportation	À mesurer	À mesurer	Forme et portée du rayon
Continu + multi-échelle	—	À mesurer	Bornes et commande d’échelle
Téléportation + multi-échelle	—	À mesurer	Adaptations du rayon
Grabbing-the-Air	À mesurer	À mesurer avec multi-échelle	Une/deux mains, collisions

Concluez en reliant les performances aux caractéristiques de chaque environnement. Quelle technique choisiriez-vous pour une recherche dans la ville ? Pour un parcours dans un espace étroit ? Discutez le compromis entre efficacité, orientation et confort, ainsi que les limites de vos essais.

Dépannage et repères

Problème	Points à vérifier
Caméra immobile au casque	Désactiver le simulateur avant le build ; vérifier le suivi XR et le fournisseur de la plateforme cible.
Y ne change pas de technique	Action Switch Mode active, binding du contrôleur, enfants directs tagués `NavigationTechnique`, liste non vide.
Rayon visible mais téléportation impossible	Couche XRI Teleport, masque physique, collider et surface du sol, actions Select, provider et mediator.
Rayon présent dans tous les modes	Référence Associated Interactor et activation de l’objet Teleportation par le manager.
Échelle sans effet ou exception	Script complété, mediator assigné, action Vector2 active, XR Origin ciblé.
Rotation et échelle simultanées	Actions du joystick droit utilisées à la fois par Turn et le provider d’échelle.
Changements absents au casque	Sauvegarder la scène, reconstruire et réinstaller la bonne scène de la bonne copie du projet.

Le XR Interaction Simulator fourni permet de vérifier la logique dans l’éditeur : activez-le pour un essai sans casque et consultez son aide de commandes. Désactivez-le avant les essais casque et le build. La performance, l’échelle perçue et le confort doivent être évalués au casque. Faites des pauses et interrompez un essai en cas d’inconfort.

Documentation : locomotion XRI 3.3 pour le projet Unity 6 ; manuel XRI 3.1 pour l’alternative 2022.3.

Crédits : sujet, tâche de recherche et projets de départ de Cédric Fleury, cours de RVRA, parcours RVSI, FISE IMT Atlantique — campus de Brest. Les noms des scripts et des actions sont conservés pour faciliter le lien avec les ressources originales.

TP — Première application de réalité virtuelle

Thu, 15 Oct 2026 00:00:00 +0000

Premiers pas · Réalité virtuelle

Durée indicative: 3 heures
Environnement: Unity 6.3 LTS · URP
OpenXR · XRI 3.3.2
Niveau: Débutant VR · Bases Unity

Vous allez réaliser un petit atelier de cubes en VR : regarder autour de vous, vous déplacer par téléportation, saisir et lancer des objets, faire apparaître un cube avec un bouton du contrôleur et changer la couleur d’un objet en le visant.

Ce TP se place généralement après Les bases d’Unity 3D. Vous devez savoir créer une scène, régler un Transform, ajouter un composant, fabriquer un prefab et attacher un script C#. Si vous avez déjà ces bases, vous pouvez commencer directement ici.

Comptez environ 3 heures, installations et premiers builds compris ; adaptez ce temps au matériel disponible.

Avant de commencer Les bases d’Unity 3D Scènes, composants, prefabs et premiers scripts C# À consulter Consignes du compte rendu Attendus et canevas du rapport

Documentation Manuel Unity 6.3 XR Interaction Toolkit 3.3 OpenXR 1.16

Brest uniquement Configurer les PC de l’école

Plan du TP

Pour poursuivre : le TP Navigation 3D compare déplacement continu, téléportation, navigation multi-échelle et Grabbing-the-Air dans une ville et un labyrinthe.

1. Préparer le projet et les packages

Créer un atelier simple

Dans Unity Hub, créez un projet Universal 3D avec Unity 6.3 LTS (6000.3). Nommez le projet VRBasics.
Dans Assets, créez les dossiers Scenes, Materials, Prefabs et Scripts. Enregistrez la scène sous Assets/Scenes/VRBasics.unity.
Ajoutez un Plane Ground, position (0, 0, 0), échelle (2, 1, 2) : il mesure 20 × 20 mètres. Gardez son collider.
Ajoutez une table avec un Cube Table, position (0, 0.75, 2), échelle (1.5, 0.1, 0.8). Gardez son Box Collider ; aucun Rigidbody n’est nécessaire pour cette table fixe.
Ajoutez trois cubes de côté 0.15, espacés sur la table, avec Y 0.9. Ajoutez à chacun un Rigidbody, Use Gravity activé et Is Kinematic désactivé. Créez des matériaux Universal Render Pipeline/Lit de couleurs différentes et assignez-les. Ici, 1 unité Unity représente 1 mètre.

Vérification : en Play, les cubes tombent légèrement et reposent sur la table. Arrêtez Play avant de poursuivre.

Installer la pile XR

Ouvrez Window > Package Management > Package Manager, puis Unity Registry. Utilisez les versions stables suivantes comme référence de séance ; évitez les versions pre et ne mettez pas les packages à jour pendant le TP.

Package	Identifiant	Rôle / référence
Input System	`com.unity.inputsystem`	Actions et bindings ; 1.20.0, comme dans le TP Unity.
XR Plug-in Management	`com.unity.xr.management`	Activation des fournisseurs XR par plateforme ; version compatible résolue par Unity.
OpenXR Plugin	`com.unity.xr.openxr`	Communication avec le système XR ; 1.16.1.
XR Interaction Toolkit	`com.unity.xr.interaction.toolkit`	Interactions et locomotion ; 3.3.2.

Les pages Unity 6.3 donnent XRI 3.3.2 et OpenXR 1.16.1 comme versions de référence publiées pour cet éditeur. Des branches plus récentes existent ; ce TP fixe une base commune pour retrouver les mêmes composants et samples.

Installez les packages absents. Si nécessaire, utilisez Install package by name avec l’identifiant et la version indiqués. Laissez Unity installer leurs dépendances.
Dans Edit > Project Settings > Player > Other Settings > Configuration, vérifiez Active Input Handling = Input System Package (New). Acceptez le redémarrage s’il est demandé.
Dans la fiche de XR Interaction Toolkit > Samples, importez Starter Assets et XR Interaction Simulator. Choisissez bien ce dernier : XR Device Simulator est un autre sample, correspondant à l’ancien simulateur.
Ouvrez Edit > Project Settings > XR Plug-in Management > Project Validation. Sélectionnez la plateforme à vérifier, lisez les problèmes signalés et appliquez les corrections correspondant aux packages et samples installés. Si une règle demande de créer une couche d’interaction Teleport, appliquez-la. Revenez dans cette fenêtre après le choix de la plateforme casque.
Notez les versions effectivement installées. Packages/manifest.json et Packages/packages-lock.json doivent être conservés avec le projet pour retrouver cette configuration.

2. Installer le point de vue et les contrôleurs

Supprimez la Main Camera initiale, ou désactivez son GameObject. Gardez la lumière et le sol.
Dans Project, ouvrez Assets/Samples/XR Interaction Toolkit/3.3.2/Starter Assets/Prefabs. Glissez XR Origin (XR Rig) dans Hierarchy.
Réglez le Transform racine du rig sur position (0, 0, 0), rotation (0, 0, 0) et échelle (1, 1, 1). Dans son composant XR Origin, choisissez Requested Tracking Origin Mode = Floor pour un casque utilisant le suivi du sol. Vérifiez que Camera référence la caméra enfant du rig.
Ajoutez GameObject > XR > XR Interaction Manager si la scène n’en contient pas déjà un. Gardez un seul manager pour ce TP. Dans les interactables créés ensuite, vous pourrez le glisser dans Interaction Manager.
Dépliez le rig et repérez la caméra, les contrôleurs gauche et droit, leurs interactors et le groupe Locomotion. Vérifiez que l’Input Action Manager du rig référence XRI Default Input Actions, fourni par les Starter Assets. Gardez les références d’actions du prefab.

Repères à retrouver dans Hierarchy — les noms des enfants peuvent varier légèrement :

VRBasics
├── Directional Light
├── Ground
├── Table
├── Cubes
├── XR Interaction Manager
└── XR Origin (XR Rig)
 ├── Camera Offset
 │ ├── Main Camera
 │ ├── Left Controller …
 │ └── Right Controller …
 └── Locomotion …

Premier test sans casque

Dans Assets/Samples/XR Interaction Toolkit/3.3.2/XR Interaction Simulator, trouvez le prefab XR Interaction Simulator. Glissez-le dans la scène, à côté du rig.
Lancez Play et cliquez dans Game. Utilisez l’aide affichée par le simulateur pour déplacer le point de vue, puis simuler chaque contrôleur. Tab alterne les modes FPS et manipulation des périphériques ; les commandes affichées dans Game permettent de choisir les contrôleurs. Sur un clavier AZERTY, consultez ou adaptez les bindings du sample si une touche est peu accessible.
Vérifiez que le point de vue et les deux contrôleurs répondent. Le simulateur produit des entrées XR ; il ne remplace pas les composants du rig.

N’activez pas en même temps l’insertion automatique du simulateur dans les réglages XRI et le prefab ajouté manuellement. Désactivez le GameObject du simulateur pour chaque test avec un casque et avant le build. Le parcours sans casque vérifie les interactions ; l’échelle perçue, le suivi et le confort devront être évalués dans le casque.

Référence : installation et commandes du XR Interaction Simulator.

3. Exécuter une première fois sur le casque

Faites ce premier essai dès que vous disposez du matériel. Si les casques sont partagés, poursuivez les exercices avec le simulateur en attendant.

Meta Quest autonome : construire et installer un APK

Le casque doit être préparé pour le développement par l’enseignant ou son propriétaire : mode développeur activé, câble USB de données et autorisation de débogage USB acceptée dans le casque. Dans Unity Hub, vérifiez que l’installation de Unity possède Android Build Support, Android SDK & NDK Tools et OpenJDK.
Ouvrez File > Build Profiles, sélectionnez Meta Quest, puis Switch Platform. Si vous utilisez le profil Android du poste, basculez sur celui-ci et configurez les réglages Quest ci-dessous. Unity 6.3 fournit un profil Meta Quest dédié, fondé sur Android, qui installe OpenXR et préconfigure plusieurs réglages.
Dans Project Settings > XR Plug-in Management, onglet Android, activez OpenXR comme fournisseur. Utilisez cette pile pour le TP ; laissez le fournisseur Oculus désactivé.
Sous XR Plug-in Management > OpenXR, toujours pour Android, activez Meta Quest Support et ajoutez Oculus Touch Controller Profile dans Interaction Profiles. Le nom « Oculus Touch » désigne ici un profil de contrôleur OpenXR. Consultez les réglages Meta Quest Support pour les profils propres au matériel utilisé.
Dans Player > Other Settings, vérifiez Scripting Backend = IL2CPP et Target Architectures = ARM64. Avec le profil Meta Quest, conservez les réglages graphiques préconfigurés. Avec Android, appliquez les corrections OpenXR adaptées au casque. Revenez dans Project Validation, plateforme Android, et corrigez les erreurs bloquantes.
Dans Build Profiles > Scene List, ajoutez la scène ouverte : VRBasics doit être cochée et première. Donnez à l’application un identifiant unique, par exemple com.votreprenom.vrbasics, dans les réglages Player.
Sélectionnez le casque dans Run Device, actualisez la liste si nécessaire, puis faites Build And Run. Enregistrez l’APK dans un dossier Builds à la racine du projet, hors Assets. Le premier build est souvent plus long que les suivants.

Vérification : dans le casque, regardez la table, tournez la tête et déplacez-vous légèrement dans votre zone physique. Le point de vue doit suivre vos mouvements ; les contrôleurs doivent suivre vos mains. À ce stade, les cubes ne se saisissent pas encore.

Casque PC : tester directement dans l’éditeur

Sur un poste compatible avec le casque et son logiciel PC, sélectionnez la plateforme PC et activez OpenXR dans l’onglet PC de XR Plug-in Management. Configurez un profil de contrôleur adapté, démarrez le runtime OpenXR du constructeur, puis lancez Play, simulateur désactivé. Un Quest utilisé en mode Link nécessite aussi sa connexion au logiciel PC ; brancher simplement un câble USB ne crée pas une session PC VR. Les réglages Android ne configurent pas le test PC.

4. Se déplacer par téléportation

Dans Locomotion du rig, repérez Locomotion Mediator, XR Body Transformer et Teleportation Provider. Vérifiez leurs références au rig et au mediator. Conservez cette organisation XRI 3 : les anciens tutoriels utilisant Locomotion System ne décrivent pas cette configuration.
Sur Ground, ajoutez Teleportation Area. Renseignez le XR Interaction Manager et le Teleportation Provider du rig dans les champs correspondants. Vérifiez que le collider du sol figure dans la liste Colliders, ou laissez la recherche automatique si elle le prend bien en compte.
Réglez son Interaction Layer Mask sur Teleport. Si cette couche manque, créez-la dans Project Settings > XR Plug-in Management > XR Interaction Toolkit > Interaction Layers, puis utilisez-la sur la surface et le rayon de téléportation.
Sur les contrôleurs du rig, trouvez les interactors dédiés à la téléportation. Leur Interaction Layer Mask doit inclure Teleport, et leur Raycast Mask doit inclure le layer physique du sol. Gardez les actions Teleport Mode et de validation préconfigurées par le sample. Sur le Controller Input Action Manager de chaque contrôleur, décochez Smooth Motion Enabled et Smooth Turn Enabled pour commencer avec la téléportation et la rotation par crans. Le prefab active initialement le déplacement continu à gauche et la téléportation à droite.
Dans XRI Default Input Actions, retrouvez les actions des maps XRI Left Locomotion et XRI Right Locomotion. Lisez les bindings de Teleport Mode et Teleport Mode Cancel. Avec les bindings standards des contrôleurs à joystick, poussez le joystick vers l’avant pour viser, puis relâchez pour valider ; vérifiez le binding effectif et Teleport Trigger sur la surface si le comportement diffère.
Testez trois destinations sur le sol. Essayez aussi de viser la table : elle doit rester une surface non téléportable. Observez le Transform racine du XR Origin pendant le test.

Deux masques à distinguer : le Layer physique d’un GameObject et le Raycast Mask filtrent les collisions/raycasts Unity ; l’Interaction Layer Mask filtre les relations XRI. Créer une couche physique nommée Teleport ne crée pas la couche d’interaction XRI. Voir les couches d’interaction.

Vérification : une destination valide affiche le retour visuel du rayon ; la validation déplace le rig sur le sol sans perdre la hauteur suivie du casque. Si la couleur ne change pas, cherchez d’abord les colliders et masques, puis les actions.

Repérez Snap Turn Provider, Continuous Turn Provider et le fournisseur de déplacement continu (Dynamic Move Provider dans les Starter Assets). Commencez avec téléportation et rotation par crans ; utilisez les paramètres des Controller Input Action Manager des contrôleurs pour choisir la rotation par crans et désactiver le déplacement continu. Vérifiez qu’un seul mode de rotation est actif.

Une fois le parcours fonctionnel, essayez brièvement le déplacement continu si vous êtes à l’aise, puis revenez à la configuration initiale. À expliquer : qu’est-ce qui déplace la caméra quand on marche réellement ? Et quand on pousse le joystick ? Quel mode rend les distances et l’orientation les plus faciles à comprendre ?

Référence : Teleportation Area.

5. Saisir et lancer les cubes

Sur un cube, ajoutez XR Grab Interactable. Gardez son Box Collider, non trigger, et son Rigidbody. Renseignez le manager. Gardez Interaction Layer Mask = Default pour les objets manipulables et vérifiez que les interactors de manipulation du rig acceptent cette couche.
Choisissez Select Mode = Single et Movement Type = Velocity Tracking. Laissez Throw On Detach activé. Ce mode utilise le Rigidbody pendant le suivi et permet de commencer à observer les collisions ; il faudra tout de même éviter les gestes très rapides à travers la table.
Testez la saisie à proximité avec le grip du contrôleur, puis le relâchement. Essayez ensuite à distance avec le rayon de manipulation du rig. Inspectez le binding Select de la map XRI Right Interaction ou XRI Left Interaction pour confirmer le bouton utilisé.
Faites un lancer doux, à l’écart de vous. Le cube doit retomber et rester sur le sol. Le changement de vitesse vient du relâchement suivi par XRI : aucun script de projectile n’est nécessaire ici.
Faites du cube un prefab GrabbableCube dans Assets/Prefabs. Équipez les autres cubes de la même façon ou remplacez-les par des instances. Gardez les objets de téléportation sur leur couche dédiée.

Vérification : vous pouvez prendre un cube, le poser sur la table, le reprendre et le lancer. Un seul contrôleur le tient à la fois. Comparez, sur une copie, Velocity Tracking, Kinematic et Instantaneous : observez la réactivité et les contacts avec la table, puis restaurez le mode initial.

Question : quelle différence y a-t-il entre déplacer un Transform et demander à un Rigidbody de suivre une cible ? Pourquoi un objet peut-il sembler plus réactif tout en traversant plus facilement un obstacle ? Voir les modes de XR Grab Interactable.

6. Créer un cube avec une action du contrôleur

Vous avez utilisé une action clavier ou souris dans le TP Unity. Le principe reste le même : une action représente l’intention, un binding la relie à un contrôle matériel. Ici, vous allez créer une action dédiée afin qu’un appui pour saisir un objet ne crée pas aussi un cube.

Définir l’action

Dans Assets, créez un dossier Input, puis un asset Create > Input Actions, nommé VRLabActions.
Double-cliquez dessus et créez une Action Map Lab, puis une action Spawn, Action Type = Button.
Ajoutez le binding <XRController>{RightHand}/secondaryButton : bouton secondaire du contrôleur droit, généralement B sur Quest. Gardez le déclenchement à l’appui ; n’utilisez pas une action de pose de type Value ou Pass Through.
Ajoutez aussi un binding <Keyboard>/n pour vérifier votre script sans casque. Enregistrez l’asset avec Save Asset si l’enregistrement automatique n’est pas actif.

Écrire et brancher ObjectSpawn

Créez ObjectSpawn.cs avec Create > Scripting > MonoBehaviour Script, puis ajoutez-le à un GameObject vide CubeSpawner. Le fichier et la classe doivent porter le même nom.

Exposez dans l’Inspector :

using UnityEngine;
using UnityEngine.InputSystem;

// Champs à placer dans la classe ObjectSpawn : MonoBehaviour.
[SerializeField] private InputActionReference spawnAction;
[SerializeField] private GameObject cubePrefab;
[SerializeField] private Transform spawnPoint;

À réaliser :

Créez un GameObject vide SpawnPoint à la racine de la scène, position (0, 1.2, 2), rotation (0, 0, 0), échelle (1, 1, 1). Vérifiez dans Scene que ce point se trouve au-dessus du plateau. Il n’est pas enfant de la table et n’hérite donc pas de son échelle.
Assignez VRLabActions > Lab/Spawn, le prefab GrabbableCube depuis Project et le Transform SpawnPoint aux trois champs du script.
Dans OnEnable, abonnez une méthode nommée, par exemple SpawnCube(InputAction.CallbackContext context), à spawnAction.action.performed, puis activez l’action avec Enable().
Dans OnDisable, désabonnez la même méthode avec -=, puis appelez Disable(). Ce composant est le seul propriétaire de l’activation de cette action dédiée. Ne faites pas ce Disable() sur une action partagée du rig. N’ajoutez donc pas VRLabActions à un autre Input Action Manager pour cet exercice.
Dans la méthode appelée, utilisez Instantiate(cubePrefab, spawnPoint.position, spawnPoint.rotation). Vérifiez les références avant de les utiliser et limitez les essais à quelques cubes pour éviter d’accumuler des objets physiques.

Les extraits sont des repères : complétez vous-même la classe et les méthodes. Comme dans le TP Unity, attendez la compilation et corrigez la première erreur de Console avant de lancer Play.

Vérification : un appui sur N fait apparaître un seul cube au-dessus de la table ; le maintenir ne doit pas produire un cube à chaque frame. Désactivez puis réactivez CubeSpawner dans l’Inspector pendant Play : chaque appui doit encore produire un seul cube. Testez ensuite le bouton secondaire droit dans le casque. Le cube créé doit être saisissable.

À expliquer : pourquoi utiliser une méthode nommée pour pouvoir se désabonner ? Pourquoi créer une action Spawn plutôt que réutiliser Select ? Référence : actions de l’Input System.

7. Réagir au survol et à la sélection d’un objet

Ajoutez sur la table une petite borne colorée, à côté des cubes, qui reste fixe. L’objectif est de signaler le survol, puis de changer durablement sa couleur à chaque sélection.

Créez un cube ColorTarget, position (0.55, 0.95, 2), échelle (0.2, 0.3, 0.2). Conservez son Box Collider. Ajoutez XR Simple Interactable, manager assigné, Interaction Layer Mask = Default, Select Mode = Single. Ne lui ajoutez pas XR Grab Interactable : cette borne reste sur la table.
Créez TargetFeedback.cs et attachez-le à la borne. Exposez une référence au Renderer, deux couleurs persistantes et une couleur de survol. Assignez le Renderer dans l’Inspector.
Écrivez trois méthodes publiques sans paramètre : BeginHover(), EndHover() et ToggleColor(). Les deux premières changent l’état de survol ; la troisième alterne la couleur persistante. Une méthode commune met à jour l’affichage : couleur de survol si la borne est visée, sinon couleur persistante. Ainsi, quitter le survol révèle bien la dernière couleur choisie.
Pour isoler la couleur de cette borne, vous pouvez obtenir une seule fois une instance du matériau via targetRenderer.material dans Awake, la conserver, puis modifier sa propriété color. Détruisez cette instance dans OnDestroy. Modifier sharedMaterial changerait aussi les autres objets utilisant cet asset ; n’en créez pas une nouvelle à chaque frame.
Dépliez Interactable Events du XR Simple Interactable. Dans chaque événement, cliquez sur +, glissez le GameObject ColorTarget dans le champ objet, puis choisissez la méthode du composant TargetFeedback :

Événement XRI	Méthode à appeler	Effet attendu
First Hover Entered	`BeginHover()`	Activer le retour visuel au premier rayon/contact.
Last Hover Exited	`EndHover()`	Retirer le retour visuel après le dernier rayon/contact.
Select Entered	`ToggleColor()`	Alterner la couleur persistante une fois par sélection.

Les événements First/Last évitent qu’un contrôleur quittant la borne efface le survol alors que l’autre la vise encore. Dans le menu des fonctions UnityEvent, sélectionnez les versions sans paramètre de vos méthodes.

Vérification : visez la borne avec un contrôleur, sélectionnez-la avec le grip correspondant à Select, puis détournez le rayon : la nouvelle couleur doit rester. Visez-la avec les deux contrôleurs et retirez-en un seul : elle doit rester en survol.

8. Vérifier l’application et rendre compte

Arrêtez Play, sauvegardez et désactivez le simulateur. Reconstruisez l’application et refaites le parcours sur le casque cible.

Test	Résultat attendu
Tourner et déplacer la tête	Vue suivie, hauteur et échelle cohérentes.
Déplacer les deux contrôleurs	Poses et rayons visibles, sans décalage inexpliqué.
Téléporter sur le sol, puis viser la table	Sol accepté, table refusée, hauteur préservée.
Saisir, poser et lancer un cube	Objet manipulable et contacts avec le sol et la table.
Appuyer sur le bouton Spawn	Un cube par appui, créé au point prévu et saisissable.
Survoler et sélectionner la borne	Survol temporaire, couleur choisie conservée en sortie.

Suivez les consignes du compte rendu de votre séance. Présentez le matériel et les versions, une capture de la hiérarchie du rig, les scripts réalisés et les résultats des tests. Distinguez les essais simulateur, Play avec casque PC et APK autonome ; signalez les tests matériels que vous n’avez pas pu effectuer.

Répondez notamment aux questions suivantes :

Quel est le rôle du XR Origin par rapport à la caméra suivie ?
Quelle différence faites-vous entre layer physique et couche d’interaction XRI ?
Quel chemin relie un bouton physique à votre méthode de création de cube ?
Pourquoi distinguer le survol, la sélection et l’activation ?
Quel mode de déplacement choisiriez-vous pour une première découverte de votre scène, et pourquoi ?

Pour aller plus loin

Ajouter un Teleportation Anchor pour rejoindre un point d’observation et comparer avec une zone libre.
Ajouter un XR Socket Interactor pour ranger un cube à une position précise.
Ajouter une interface World Space avec un XR UI Input Module et un Tracked Device Graphic Raycaster ; utiliser le rayon pour actionner un bouton de remise à zéro.
Explorer le retour haptique et vérifier son effet sur le casque, puisque le simulateur ne restitue pas la sensation.
Poursuivre avec le TP sur le confort en VR ou le TP XR Engineering & Debugging pour structurer et instrumenter une application plus importante.

En cas de blocage

Corrigez d’abord la première erreur rouge de Console. Indiquez toujours l’étape, la plateforme active, les versions et le message exact lorsque vous demandez de l’aide.

Symptôme	Vérifications prioritaires
Caméra immobile ou mauvaise hauteur	Un seul rig et une seule caméra active ; référence Camera du XR Origin ; mode Floor/Device ; simulateur actif uniquement sans casque ; fournisseur OpenXR de la plateforme cible.
Casque détecté en USB mais aucune VR dans Play	Une connexion USB pour installer un APK ne suffit pas pour le PC VR. Vérifiez runtime PC, mode Link éventuel et fournisseur OpenXR PC, ou utilisez Build And Run pour l’autonome.
Les mains ou rayons ne répondent pas	Input System actif, Input Action Manager et actions du sample ; profils OpenXR adaptés ; contrôleurs réveillés ; aucune ancienne caméra FPS active.
Le simulateur ne répond pas	Game a le focus ; un seul simulateur ; rig préconfiguré présent ; aide et bindings du sample ; pas de session casque concurrente.
Rayon visible, aucune téléportation	Collider du sol, couche XRI Teleport des deux côtés, Raycast Mask, provider et mediator, action Teleport Mode, mode de déclenchement de la surface.
Un cube ne se saisit pas ou traverse le décor	Collider, Rigidbody, XR Grab Interactable, manager, masques de manipulation et action Select ; vérifier Movement Type et la vitesse du geste.
N fonctionne mais pas le bouton du casque	Binding RightHand/secondaryButton, profil OpenXR, test sur la bonne main et APK reconstruit après modification.
Aucun cube ou plusieurs cubes par appui	Références de ObjectSpawn, action activée, abonnement unique et désabonnement ; pas d’instanciation dans Update ; pas de doublon CubeSpawner.
La couleur change sur tous les objets	Le script modifie probablement sharedMaterial ; utiliser une instance conservée pour la borne.
APK impossible à construire ou casque absent	Modules Android du bon éditeur, erreurs de Project Validation, autorisation USB, câble de données, Run Device, IL2CPP/ARM64. Sur un poste Linux, vérifier aussi les droits d’accès USB et les outils de compilation demandés par Unity.
Ancienne scène dans le casque	Scene List et profil actifs, sauvegarde de VRBasics, nouveau Build And Run terminé sans erreur.

Pour poursuivre

Le TP Interaction 3D : comparer les techniques de manipulation propose une tâche de construction chronométrée pour comparer saisie directe, rayon virtuel, Near Far et utilisation des deux mains.

Documentation de référence

Documentation consultée le 15 octobre 2026. Utilisez la branche 3.3 de XRI pour suivre les noms de ce TP.

TP — Ingénierie et débogage en réalité virtuelle

Mon, 02 Mar 2026 00:00:00 +0000

Objectif

Ce TP (~7h) a pour objectif de vous apprendre à développer et maintenir une application VR avec :

une architecture claire (séparation des responsabilités, dépendances explicites),
une chaîne d’itération efficace (tester un maximum sans casque, builds debug),
une observabilité minimale (overlay VR, logs structurés),
des pratiques de debugging XR,
une introduction au profiling VR (optionnel selon le temps restant).

L’application développée est un atelier VR de visualisation du système solaire : un modèle “tabletop” manipulable, une UI en world-space, des modes de vue, et des contrôles temporels.

Pré-requis

Compétences

Bases C# / Unity (scènes, prefabs, scripts)
Notions Git (commit, tag, push)
Bases VR (confort, world-space UI) utiles mais pas indispensables

Outils

Unity LTS (2022.3 ou 2023 LTS)
Packages Unity :
- OpenXR
- XR Interaction Toolkit (XRI)
- Input System
Un casque VR compatible OpenXR

Ressources

PlanetData.cs (fournit les données et fonctions de calcul orbital)

Règles d’ingénierie (à respecter)

Dans ce TP, vous devez explicitement appliquer les règles suivantes :

Aucune dépendance implicite
- Pas de FindObjectOfType, pas de GameObject.Find, pas de dépendance “magique”.
- Les références nécessaires sont injectées via l’inspecteur ou via un bootstrapper.
Pas de logique métier dans Update() par défaut
- Update() est réservé aux besoins continus réellement nécessaires.
- Préférer événements, actions, timers contrôlés.
Séparation des responsabilités
- Modèle de données / services (calculs, temps, conversion) ≠ vues (GameObjects) ≠ contrôleurs.
Debuggabilité
- Tout comportement critique doit produire des logs exploitables.
- Mise en place d’un DebugOverlay visible dans le casque.
Performance (optionnel)
- Interdiction d’allocations évitables par frame (strings/LINQ).
- Profiling obligatoire (preuve avant/après sur un point).

Scénario : Solar System VR Workbench

Vous développerez une application VR contenant :

un “tabletop” du système solaire (échelle manipulable),
des planètes positionnées à un instant t (les fonctions de calcul sont déjà fournies par PlanetData),
un contrôle du temps (date + vitesse),
des trajectoires activables/désactivables,
un mode “focus planète” (centrage/inspection),
une UI VR (world-space) pour piloter l’application,
un overlay debug (FPS, état, derniers événements, warnings).

Organisation du TP

Le TP est structuré en 5 étapes principales et 2 extensions optionnelles.

Obligatoire :

1 — Boot XR
2 — Architecture
3 — Événements / simulation
4 — Interactions VR
5 — UI + Debug overlay

Optionnel (si temps restant) :

6 — Debugging XR guidé
7 — Optimisation de performance

Organisation du rendu (Git)

Vous devez livrer :

un repo Git (lien),
des tags Git à chaque étape (v1.0, v1.1, … v2.0),
un court compte-rendu (README ou PDF) :
- captures d’écran (dans le casque ou miroir),
- fonctionnalités implémentées,
- schéma d’architecture (simple, lisible),
- une “debug story” (si vous avez traité l’étape 6),
- une “perf story” (si vous avez traité l’étape 7).

Rappel tags

À chaque étape :

git add .
git commit -m "…"
git tag -a v1.x -m "…"
git push origin main
git push origin --tags

Concepts utiles pour ce TP

Avant de commencer le TP, voici quelques notions importantes que nous allons utiliser pendant toute la séance. Elles sont très courantes dans les projets Unity et encore plus importantes en XR.

1 — Logique métier

La logique métier correspond aux règles qui définissent comment fonctionne votre application, indépendamment de l’affichage.

Exemples dans ce TP :

Logique métier :

calculer la position d’une planète à une date donnée
changer la vitesse du temps
activer ou désactiver les trajectoires
changer l’échelle du système solaire

Affichage (pas logique métier) :

déplacer un GameObject
changer un texte dans l’UI
afficher un panneau

Mauvais exemple

void Update()
{
 planet.transform.position = PlanetData.ComputePosition(DateTime.Now);
}

Le calcul et l’affichage sont mélangés.

Bon exemple

DateTime currentTime;

void OnTimeChanged(DateTime t)
{
 currentTime = t;
 UpdateView();
}

La logique décide quand on met à jour, la vue décide comment on affiche.

2 — Séparation des responsabilités

Dans un projet Unity, il est très facile de mettre beaucoup de choses dans un seul script. Cela fonctionne pour de petits projets, mais devient rapidement difficile à maintenir.

On sépare donc les rôles.

Structure simple utilisée dans ce TP

Data / Model ←→ Services ←→ Controllers ←→ Views

Model (données)

Contient uniquement des données.

Exemple :

TimeModel

currentTime

timeSpeed

Un modèle ne dépend normalement pas de Unity.

Services

Contiennent des calculs ou des règles.

Exemple :

PlanetEphemerisService

computePosition()

Controllers

Coordonnent l’application.

Ils reçoivent des événements et mettent à jour les vues.

Exemple :

SolarSystemController

Views

Objets Unity visibles.

Exemples :

PlanetView

OrbitRenderer

UI panels

Résumé

Model → stocker l’état
Service → calculer
Controller → décider quoi faire
View → afficher

3 — Bootstrapper

Le problème

Dans beaucoup de projets Unity on trouve :

FindObjectOfType
GameObject.Find
des Singletons utilisés partout

Ces méthodes fonctionnent mais rendent le projet fragile.

Solution simple

Créer un objet qui initialise l’application.

C’est ce qu’on appelle un Bootstrapper.

Exemple :

AppBootstrapper

Son rôle :

créer les services
connecter les objets
initialiser les données

Exemple simple

public class AppBootstrapper : MonoBehaviour
{
 public SolarSystemController controller;

 void Start()
 {
 var timeModel = new TimeModel();
 controller.Init(timeModel);
 }
}

Les dépendances deviennent visibles et contrôlées.

4 — Événements

Les événements permettent à différents objets de communiquer sans être fortement couplés.

Sans événements :

UI → Manager → Controller → Camera

Tout dépend de tout.

Avec événements :

UI → Event → Objets intéressés

Chaque système reste indépendant.

Exemple

public event Action<DateTime> OnTimeChanged;

Quand la date change :

OnTimeChanged?.Invoke(newTime);

Un autre script peut écouter cet événement :

void Start()
{
 planetManager.OnTimeChanged += UpdatePosition;
}

5 — Actions

Une Action est simplement une fonction stockée dans une variable.

Exemple :

Action<DateTime> callback;

Dans Unity on les utilise pour :

événements
callbacks
interactions UI

6 — Gestion de l’état de la simulation

Dans cette application, la variable centrale n’est pas vraiment un “timer” technique. Ce qui compte est simplement la date de la simulation.

Autrement dit, on manipule un état global :

Date simulée → positions des planètes → affichage

Lorsque cette date change :

les positions des planètes doivent être recalculées
certaines visualisations doivent être mises à jour
l’interface peut afficher la nouvelle valeur

Plutôt que de recalculer en permanence dans Update(), on déclenche un événement uniquement quand l’état change.

Mauvaise approche

void Update()
{
 UpdatePlanets(currentDate);
}

Chaque objet vérifie en permanence si quelque chose a changé.

Approche recommandée

On utilise un événement qui signale un changement d’état.

public event Action<DateTime> OnTimeChanged;

Quand la date change :

UI → PlanetManager → événement → objets intéressés

Exemple :

void Start()
{
 PlanetManager.current.OnTimeChanged += UpdatePosition;
}

Cela permet :

moins de calculs inutiles
un code plus lisible
un débogage plus simple
de meilleures performances en VR

7 — Pourquoi c’est encore plus important en XR

En VR et XR :

les builds sont plus longs
les bugs sont plus difficiles à diagnostiquer
les performances sont critiques

Une architecture claire permet :

de tester certaines parties sans casque
de comprendre rapidement un bug
de modifier une interaction sans casser tout le projet

8 - ScriptableObject

Un ScriptableObject est un asset Unity utilisé pour stocker des paramètres éditables.

Contrairement à un MonoBehaviour, il n’est pas attaché à un GameObject.

Exemple dans ce TP :

[CreateAssetMenu(menuName = "XR/Solar System Config")]
public class SolarSystemConfig : ScriptableObject
{
 public float distanceScale;
 public float planetSizeScale;
 public bool showOrbits;
}

On crée ensuite l’asset dans Unity :

Assets → Create → XR → Solar System Config

Puis on l’assigne dans l’inspecteur.

Intérêt :

configuration centralisée
modifiable sans changer le code
partageable entre scènes.

Ce que vous devez retenir

Pendant ce TP, essayez de toujours vous poser ces questions :

Est-ce que ce script fait trop de choses ?
Est-ce que ce code dépend inutilement d’un autre objet ?
Est-ce que je peux comprendre ce système rapidement ?
Est-ce que je pourrais déboguer ça facilement sur un casque VR ?

Si la réponse est “non”, il faut probablement simplifier ou mieux séparer les responsabilités.

Étape 1 — Boot XR + scène minimale (Tag : v1.0) — ~45 min

Objectifs

Avoir une scène VR qui tourne et un pipeline de build déboguable.

À faire

Créer le projet Unity.
Installer et activer :
- OpenXR
- XR Interaction Toolkit
  - Vous pouvez ajouter les Starter Assets (pour avoir un XR Rig complet), et le XR Simulator (pour tester sans casque) depuis les samples du package.
- Input System
Configurer le projet :
- Activer les plugin-provider nécessaires pour votre casque (OpenXR, Oculus, etc.) dans Player Settings / XR Plug-in Management.
Ajouter un rig VR (XRI) :
- XR Origin
- XR Interaction Manager
Créer une scène Boot :
- sol + repère (axes X/Y/Z par exemple pour voir l’origine du monde dans la scène)
- un cube interactable (grab) pour valider XRI
Configurer le build debug :
- Development Build
- Script Debugging
- (si possible) Autoconnect Profiler

Rendu attendu

Capture (mode miroir dans le casque ou XR simulator) montrant le cube grab en VR
Repo taggé v1.0-boot (n’noubliez pas le .gitignore)

Étape 2 — Architecture : modèles, services, contrôleurs

Tag : v1.1-architecture — ~1h15

Objectif

Avant d’ajouter de la VR, des interactions et de l’UI, nous allons structurer correctement l’application.

Dans les projets XR, les problèmes viennent souvent de :

scripts qui se référencent dans tous les sens
logique mélangée avec l’affichage
dépendances invisibles
code impossible à tester sans casque.

Nous allons donc construire une architecture simple :

Bootstrapper
 ↓
Models / Config
 ↓
Services
 ↓
Controllers
 ↓
Views (Unity)

1 — Organisation des dossiers

Créer les dossiers suivants :

Scripts
 ├── Bootstrap
 ├── Models
 ├── Services
 ├── Controllers
 ├── Views
 └── Config

But :

Dossier	Rôle
Bootstrap	point d’entrée
Models	état de la simulation
Services	calculs
Controllers	coordination
Views	GameObjects Unity
Config	paramètres éditables

2 — Le modèle du temps

Dans notre simulation, la variable centrale est le temps simulé.

Créer :

Scripts/Models/TimeModel.cs

using System;

public class TimeModel
{
 public DateTime CurrentTime { get; private set; }

 public float TimeScale { get; private set; } = 1f;

 public bool IsPlaying { get; private set; } = true;

 public event Action<DateTime> OnTimeChanged;

 public void SetTime(DateTime t)
 {
 CurrentTime = t;
 OnTimeChanged?.Invoke(CurrentTime);
 }

 public void SetScale(float scale)
 {
 TimeScale = scale;
 }

 public void Play()
 {
 IsPlaying = true;
 }

 public void Pause()
 {
 IsPlaying = false;
 }
}

Important :

ce script ne dépend pas de Unity
il ne contient que l’état et les événements.

3 — Configuration du système solaire

Certains paramètres doivent être éditables dans Unity.

Créer :

Scripts/Config/SolarSystemConfig.cs

using UnityEngine;

[CreateAssetMenu(menuName = "XR/Solar System Config")]
public class SolarSystemConfig : ScriptableObject
{
 public float distanceScale = 0.000001f;
 public float planetSizeScale = 0.01f;
 public bool showOrbits = true;
}

Créer ensuite l’asset :

Assets → Create → XR → Solar System Config

4 — Utilisation des données astronomiques fournies

Le TP fournit déjà une classe :

PlanetData.cs

Elle contient :

les paramètres orbitaux
les calculs d’orbite
la fonction :

PlanetData.GetPlanetPosition(PlanetData.Planet planet, DateTime time)

⚠️ Cette classe est la source officielle des positions des planètes. Les étudiants ne doivent pas modifier ce fichier.

5 — Service d’accès aux positions planétaires

Même si la fonction existe déjà, on passe par un service.

Pourquoi ?

garder une architecture propre
pouvoir remplacer l’implémentation plus tard
faciliter les tests.

Créer :

Scripts/Services/IPlanetEphemerisService.cs

using System;
using UnityEngine;

public interface IPlanetEphemerisService
{
 Vector3 GetPlanetPosition(PlanetData.Planet planet, DateTime date);
}

Implémentation :

Scripts/Services/PlanetEphemerisService.cs

using System;
using UnityEngine;

public class PlanetEphemerisService : IPlanetEphemerisService
{
 public Vector3 GetPlanetPosition(PlanetData.Planet planet, DateTime date)
 {
 return PlanetData.GetPlanetPosition(planet, date);
 }
}

Ce service agit comme une couche d’abstraction.

6 — Vue planète

Créer :

Scripts/Views/PlanetView.cs

using UnityEngine;

public class PlanetView : MonoBehaviour
{
 public PlanetData.Planet planet;

 public void SetPosition(Vector3 pos)
 {
 transform.localPosition = pos;
 }
}

Rôle :

représenter une planète dans la scène
appliquer les positions calculées.

7 — Controller du système solaire

Le controller relie :

le modèle
le service
les vues.

Créer :

Scripts/Controllers/PlanetSystemController.cs

using System;
using UnityEngine;

public class PlanetSystemController
{
 TimeModel timeModel;
 IPlanetEphemerisService ephemeris;

 PlanetView[] planets;

 public PlanetSystemController(
 TimeModel timeModel,
 IPlanetEphemerisService ephemeris,
 PlanetView[] planets)
 {
 this.timeModel = timeModel;
 this.ephemeris = ephemeris;
 this.planets = planets;

 timeModel.OnTimeChanged += UpdatePlanets;
 }

 void UpdatePlanets(DateTime time)
 {
 Debug.Log("[TIME] Updating planets " + time);

 foreach (var planet in planets)
 {
 Vector3 pos =
 ephemeris.GetPlanetPosition(planet.planet, time);

 planet.SetPosition(pos);
 }
 }
}

Responsabilités :

Élément	Rôle
Model	état de la simulation
Service	calcul des positions
Controller	coordination
View	affichage.

8 — Bootstrapper

Créer :

Scripts/Bootstrap/AppBootstrapper.cs

using UnityEngine;
using System;

public class AppBootstrapper : MonoBehaviour
{
 public SolarSystemConfig config;

 public PlanetView[] planets;

 TimeModel timeModel;
 PlanetSystemController controller;

 void Start()
 {
 Debug.Log("[BOOT] Initializing application");

 timeModel = new TimeModel();

 var ephemeris = new PlanetEphemerisService();

 controller = new PlanetSystemController(
 timeModel,
 ephemeris,
 planets
 );

 timeModel.SetTime(DateTime.Now);
 }
}

Rôle :

créer les objets principaux
connecter les dépendances
démarrer la simulation.

C’est ce qu’on appelle le composition root.

9 — Mise en place dans la scène

Créer un GameObject :

App

Ajouter :

AppBootstrapper

Dans l’inspecteur :

assigner SolarSystemConfig
assigner les PlanetView.

Structure possible :

App
SolarSystem
 ├ Sun
 ├ Mercury
 ├ Venus
 ├ Earth
 ├ Mars
 ├ Jupiter
 ├ Saturn
 ├ Uranus
 └ Neptune

Chaque planète possède :

PlanetView

10 — Test rapide

Lancer la scène.

Résultat attendu :

les planètes apparaissent
elles sont positionnées correctement
log [BOOT].

Si rien ne se passe :

Checklist :

les PlanetView sont assignées
le bootstrapper est actif
la scène est sauvegardée.

Si vous suivez bien les étapes, vous devriez constater un petit bug. Modifiez le service pour le corriger.

11 — Vérification de l’architecture

Votre code doit respecter :

pas de FindObjectOfType
pas de GameObject.Find
dépendances visibles
modèle indépendant de Unity
logique séparée de l’affichage.

12 — Schéma de l’architecture

classDiagram class AppBootstrapper { +SolarSystemConfig config +PlanetView[] planets -TimeModel timeModel -PlanetSystemController controller +Start() } class TimeModel { +DateTime CurrentTime +float TimeScale +bool IsPlaying +OnTimeChanged : ActionDateTime +SetTime(DateTime) +SetScale(float) +Play() +Pause() } class SolarSystemConfig { +float distanceScale +float planetSizeScale +bool showOrbits } class IPlanetEphemerisService { +GetPlanetPosition(Planet, DateTime) Vector3 } class PlanetEphemerisService { +GetPlanetPosition(Planet, DateTime) Vector3 } class PlanetData { +GetPlanetPosition(Planet, DateTime) Vector3 } class PlanetSystemController { -TimeModel timeModel -IPlanetEphemerisService ephemeris -PlanetView[] planets +PlanetSystemController(TimeModel, IPlanetEphemerisService, PlanetView[]) } class PlanetView { +Planet planet +SetPosition(Vector3) } AppBootstrapper --> TimeModel : creates AppBootstrapper --> PlanetEphemerisService : creates AppBootstrapper --> PlanetSystemController : creates AppBootstrapper --> PlanetView : references inspector AppBootstrapper --> SolarSystemConfig : references asset PlanetSystemController --> TimeModel : subscribes PlanetSystemController --> IPlanetEphemerisService : uses PlanetEphemerisService ..|> IPlanetEphemerisService : implements PlanetEphemerisService --> PlanetData : calls PlanetSystemController --> PlanetView : updates

Résultat attendu

À la fin de cette étape :

l’application est structurée
les planètes utilisent PlanetData
les dépendances sont explicites
la simulation est pilotée par un modèle.

Tag Git :

v1.1-architecture

Étape 3 — Positionnement des planètes + événements

Tag : v1.2-events — ~1h15

Objectif

Mettre en place le flux principal de la simulation :

le temps change,
un événement est déclenché,
le contrôleur met à jour les planètes.

On évite volontairement de faire tourner toute la logique dans Update().

Flux attendu :

TimeController
 ↓
TimeModel
 ↓
OnTimeChanged
 ↓
PlanetSystemController
 ↓
PlanetView

On a déjà créé la plupart de ces éléments dans l’étape précédente, il s’agit maintenant de les connecter correctement avec des événements.

Responsabilités :

Élément	Rôle
Model	état du temps
Service	calcul des positions
Controller	applique les positions
View	déplace les objets

1 — Déclencher via un événement

Ceci a déjà été implémenté dans l’étape précédente, mais il est important de comprendre comment cela fonctionne.

Dans TimeModel :

public void SetTime(DateTime t)
{
 CurrentTime = t;
 OnTimeChanged?.Invoke(CurrentTime);
}

Dans le controller :

timeModel.OnTimeChanged += UpdatePlanets;

Ainsi les planètes se mettent à jour uniquement quand le temps change.

2 — Faire avancer le temps

Créer un petit composant Unity :

TimeController

public class TimeController : MonoBehaviour
{
 public float secondsPerDay = 1f;

 TimeModel model;
 DateTime current;

 public void Init(TimeModel m)
 {
 model = m;
 current = DateTime.Now;
 model.SetTime(current);
 }

 void Update()
 {
 if (!model.IsPlaying) return;

 current = current.AddDays(Time.deltaTime * secondsPerDay);
 model.SetTime(current);
 }
}

Dans AppBootstrapper :

timeController.Init(timeModel);

3 — Vérification

Quand la scène démarre :

Console :

[BOOT] Initializing application
[TIME] Updating planets ...

Et les planètes doivent se déplacer.

Checklist :

aucun FindObjectOfType
aucun GameObject.Find
la mise à jour passe par OnTimeChanged
les PlanetView sont assignées.

(Optionnel) Trajectoires

Pour afficher une orbite :

ajouter un LineRenderer
calculer plusieurs positions
ne pas recalculer chaque frame.

Principe :

for (int i = 0; i < samples; i++)
{
 var t = start.AddDays(i * 10);
 points[i] = ephemeris.GetPlanetPosition(planet, t);
}

Résultat attendu

À la fin :

la simulation est pilotée par TimeModel
les planètes suivent correctement le temps
la mise à jour passe par l’événement OnTimeChanged
l’architecture reste claire et testable.

Dans le rapport, vous devez également inclure :

un schéma simple du flux TimeModel → Controller → PlanetView
une courte explication du fonctionnement
une capture de l’application.

Tag :

v1.2-events

Étape 4 — Interactions VR : grab / focus / échelle

Tag : v1.3-vr-interactions — ~1h30

Objectif

Dans cette étape, vous allez transformer votre simulation en véritable objet manipulable en VR.

L’utilisateur doit pouvoir :

déplacer le système solaire,
modifier son échelle,
sélectionner une planète pour obtenir des informations.

Le but n’est pas seulement de faire fonctionner ces interactions, mais de les intégrer proprement dans l’architecture du projet.

Les interactions XR doivent déclencher des intentions, qui sont ensuite appliquées par un système clair (controller / manager), et non manipuler directement tous les objets de la scène.

Flux recommandé :

XR Interaction
 ↓
Script d’interaction
 ↓
Controller
 ↓
Views

1 — Préparer un “tabletop” manipulable

Pour faciliter les interactions, vous devez organiser la scène autour d’un objet racine manipulable.

Créer une structure proche de :

SolarSystemRoot
 ├ SolarSystem
 │ ├ Sun
 │ ├ Mercury
 │ ├ Venus
 │ └ ...
 └ Handle

SolarSystemRoot devient l’objet que vous allez :

déplacer
faire tourner
mettre à l’échelle.

Toutes les planètes doivent être enfants de cet objet.

Pourquoi ?

cela simplifie énormément les interactions,
cela évite de modifier chaque planète individuellement,
cela permet de garder un point central pour les contrôleurs.

2 — Interaction Grab

Objectif

Permettre à l’utilisateur de prendre le système solaire et le déplacer dans l’espace.

À faire

Créer un objet servant de poignée de manipulation.

Ajouter un interactable XR permettant :

de saisir l’objet avec le contrôleur,
de déplacer l’ensemble du système.

Quelques éléments nécessaires :

collider
rigidbody (souvent kinematic)
composant d’interaction XR.

Test attendu :

l’utilisateur peut attraper l’objet,
le déplacer,
le relâcher.

Bonnes pratiques

ne pas attacher cette interaction directement aux planètes,
garder un objet dédié (handle),
ajouter des logs utiles :

[XR] Table grabbed
[XR] Table released

3 — Contrôle de l’échelle

Objectif

Permettre à l’utilisateur de zoomer / dézoomer le système solaire.

L’échelle doit :

rester dans des limites raisonnables,
être centralisée dans un seul script,
produire des logs utiles.

À implémenter

Créer un système responsable de :

recevoir une valeur de scale,
la limiter si nécessaire,
appliquer la transformation à SolarSystemRoot.

Vous pouvez par exemple créer un composant dédié :

ScaleController

Ce composant pourrait exposer une méthode du type :

SetScale(float value)

C’est ce composant qui applique réellement l’échelle.

Interaction utilisateur

Vous êtes libres de choisir comment modifier l’échelle :

slider UI en VR
bouton +
rotation d’un knob
geste à deux mains (bonus)

Mais dans tous les cas :

l’interaction ne doit pas manipuler directement le transform
elle appelle un contrôleur.

Logs attendus

Exemples :

[INPUT] Scale requested
[XR] Scale applied
[WARN] Scale clamped

4 — Sélection d’une planète

Objectif

Permettre à l’utilisateur de pointer une planète avec un rayon XR et de la sélectionner.

Lorsqu’une planète est sélectionnée :

un événement doit être déclenché,
le système doit savoir quelle planète est active.

Mise en place

Chaque planète doit pouvoir :

être détectée par un ray interactor,
signaler sa sélection.

Vous pouvez par exemple créer un script du type :

PlanetSelectable

Ce script peut :

référencer la PlanetView,
déclencher un événement ou appeler un système central.

Important : le script de sélection ne doit pas contenir toute la logique de focus ou d’UI.

Il signale seulement une planète a été sélectionnée.

5 — Mode Focus

Objectif

Quand une planète est sélectionnée :

la planète doit être “mise en avant” (ex. centrée, agrandie, etc.),
un panneau d’information apparaît.

À implémenter

Créer un système responsable du focus.

Par exemple :

FocusController

Responsabilités possibles :

déplacer l’origine XR ou la caméra,
activer un panneau d’information,
enregistrer la planète active.

Le panneau peut afficher par exemple :

nom de la planète
distance au soleil
période orbitale
temps simulé actuel.

Le contenu exact est libre.

6 — Organisation recommandée

Une organisation possible des responsabilités :

Élément	Rôle
XR Interactable	capter l’interaction
Script d’interaction	traduire l’action utilisateur
Controller	appliquer la logique
View	afficher le résultat

Exemple de flux :

Ray Interactor
 ↓
PlanetSelectable
 ↓
PlanetSelectionSystem
 ↓
FocusController
 ↓
UI

7 — Vérifications

Avant de passer à l’étape suivante, vérifiez :

Grab

le système solaire peut être déplacé
le mouvement est stable
des logs apparaissent.

Scale

l’échelle peut changer
les limites sont respectées
les transformations restent cohérentes.

Focus

la sélection fonctionne avec le rayon
la bonne planète est détectée
un feedback visuel apparaît.

Résultat attendu

À la fin de cette étape, l’utilisateur peut :

manipuler le système solaire,
modifier son échelle,
sélectionner une planète,
voir des informations associées.

L’architecture doit rester :

lisible,
découplée,
déboguable.

Tag Git :

v1.3-vr-interactions

Étape 5 — UI world-space + instrumentation (Tag : v1.4) — ~1h00

Objectifs

Rendre l’application pilotable et déboguable dans le casque.

À faire

A) UI world-space

Créer un panneau VR permettant au minimum :

Date (ou scrub)
Play/pause + vitesse (x1, x10, x100…)
Toggle trajectoires
Reset viewpoint / reset scale

Le panneau UI peut être un Canvas world-space interactif avec le XR Interaction Toolkit.

B) DebugOverlay (obligatoire)

Créer un overlay discret affichant :

FPS / frame time (approx)
Date actuelle + vitesse
Dernière action utilisateur
Warnings clés (scale hors bornes, perf suspecte, event spam)

Le DebugOverlay peut être un simple panneau TextMeshPro mis à jour périodiquement.

Unity permet de récupérer tous les logs (Debug.Log, warnings, erreurs) via :

Application.logMessageReceived

Vous pouvez utiliser ce callback pour :

récupérer les messages importants
garder les derniers logs
les afficher dans l’overlay.

Exemple

using UnityEngine;
using TMPro;
using System.Collections.Generic;

public class DebugOverlay : MonoBehaviour
{
 public TextMeshProUGUI text;

 Queue<string> lines = new Queue<string>();

 public int maxLines = 15;

 void OnEnable()
 {
 Application.logMessageReceived += HandleLog;
 }

 void OnDisable()
 {
 Application.logMessageReceived -= HandleLog;
 }

 void HandleLog(string logString, string stackTrace, LogType type)
 {
 lines.Enqueue(logString);

 while (lines.Count > maxLines)
 lines.Dequeue();

 text.text = string.Join("\n", lines);
 }
}

C) Logs structurés

Tous les événements critiques doivent loguer au format :

[TIME] …
[INPUT] …
[XR] …
[PERF] …

Rendu attendu

Capture du panneau UI + overlay debug visibles en VR
Tag v1.4-ui-debug

Étape 6 — Debugging XR guidé (Tag : v1.5) — (Optionnel)

Objectifs

Apprendre une méthode de debug XR reproductible.

Travail demandé

Vous devez traiter au moins 2 tickets parmi les 3 suivants (selon starter fourni par l’enseignant) :

Ticket A — Input qui marche en Editor mais pas sur casque
Ticket B — Après reload scène, les events se déclenchent en double
Ticket C — Échelle/repères incohérents : objets “loin” ou “immenses”

Pour chaque ticket :

fournir un repro minimal
décrire la méthode (instrumentation → hypothèse → test → fix)
ajouter un test simple de non-régression (ex. log + guard + assert)

Rendu attendu

Section “Debug story” dans README
Tag v1.5-debug-tickets

Étape 7 — Performance XR (Tag : v2.0) — (Optionnel)

Objectifs

Identifier et corriger un problème perf (CPU/GPU/GC) typique VR.

À faire

Mesurer (Profiler) :
- CPU main thread
- GC alloc
- scripts en Update
Choisir un goulot et l’améliorer :
- caching trajectoires
- pooling
- réduction fréquence d’update
- suppression d’allocations
Prouver l’amélioration :
- capture du profiler avant/après
- décrire le changement (2–5 lignes)

Rendu attendu

Section “Perf story” dans README
Tag v2.0-final

Bonus (facultatifs)

Rotation propre des planètes (axiale + orbitale)
Skybox / voûte céleste
Mode “surface de planète” (point de vue, constellations)
Téléportation + confort (snap turn, vignette)
Mini “debug console” in-VR avec filtres par catégories

Critères d’évaluation (indicatif)

Architecture & propreté — 40%
Interactions VR — 30%
Observabilité — 20%

Bonus :

Debugging (tickets + méthode)
Performance (mesure + amélioration)

Checklist rapide (avant rendu)

Repo public/privé accessible, tags présents
App fonctionne sur casque
UI world-space OK
DebugOverlay OK
README avec captures + schémas
Pas de FindObjectOfType / GameObject.Find dans le code final

Virtual Reality | Étienne Peillard

TP — Interaction 3D : techniques de manipulation

La tâche : une tour bicolore

1. Prendre en main le projet et les interactions de base

Ouvrir la bonne version

Essayer la tâche

2. Préparer le changement de technique sur chaque contrôleur

3. Modifier le point de saisie des blocs

4. Ajouter un rayon virtuel

Configurer la sélection à distance

Comparer les variantes

5. Tester Near Far

6. Manipuler avec les deux mains

Comparer les résultats et rédiger le compte rendu

En cas de difficulté

Auteur et ressources originales

TP — Navigation 3D en réalité virtuelle

Ressources et projet de départ

1. Tester la navigation de base

Ouvrir et exécuter la scène

Manipuler et mesurer

2. Configurer le déplacement continu

3. Basculer entre plusieurs techniques

4. Ajouter la téléportation

5. Ajouter la navigation multi-échelle

6. Tester Grabbing-the-Air

7. Bonus : World-in-Miniature et téléportation

Compte rendu et bilan

Dépannage et repères

TP — Première application de réalité virtuelle

1. Préparer le projet et les packages

Créer un atelier simple

Installer la pile XR

2. Installer le point de vue et les contrôleurs

Premier test sans casque

3. Exécuter une première fois sur le casque

Meta Quest autonome : construire et installer un APK

Casque PC : tester directement dans l’éditeur

4. Se déplacer par téléportation

Comparer les modes de navigation

5. Saisir et lancer les cubes

6. Créer un cube avec une action du contrôleur

Définir l’action

Écrire et brancher ObjectSpawn

7. Réagir au survol et à la sélection d’un objet

8. Vérifier l’application et rendre compte

Pour aller plus loin

En cas de blocage

Pour poursuivre

Documentation de référence

TP — Ingénierie et débogage en réalité virtuelle

Objectif

Pré-requis

Compétences

Outils

Ressources

Règles d’ingénierie (à respecter)

Scénario : Solar System VR Workbench

Organisation du TP

Organisation du rendu (Git)

Rappel tags

Concepts utiles pour ce TP

1 — Logique métier

Mauvais exemple

Bon exemple

2 — Séparation des responsabilités

Structure simple utilisée dans ce TP

Model (données)

Services

Controllers

Views

Résumé

3 — Bootstrapper

Le problème

Solution simple

Exemple simple

4 — Événements

Exemple

5 — Actions

6 — Gestion de l’état de la simulation