Virtual Reality | Étienne Peillard

Lab — 3D interaction: manipulation techniques

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

RVRA · RVSI · 3D interaction

Experimental task: Build a tower · 2 min per trial
Provided project: Unity 6.3 · XRI 3.3.0
OpenXR 1.16.0
Prerequisites: Unity and VR basics · Headset and controllers

You will compare manipulation techniques using a common task: build a tower of blue and yellow blocks in two minutes. The aim is to understand how selection, attachment points and distant interaction affect precision, speed and effort.

This lab follows the Unity and VR introductions. The task scene and scripts are provided: your work focuses on configuring and evaluating interactions.

Lab files Unity 6.3 project Scene, scripts and prefabs · ZIP · approx. 79 MB Lab report Original report template Questions and results · DOCX in English

Getting started Unity 3D Basics VR introduction Original handout · English PDF

IMT Atlantique · Brest Original lab by Cédric Fleury, for the RVRA course, RVSI track of the FISE programme.

Lab outline

The task: a two-coloured tower

The blue generator on the left produces blue blocks; the yellow generator on the right produces yellow blocks. Move them to the central platform to build your tower.

Each level contains two blocks of the same colour.
The blocks in each level are perpendicular to those in the previous level.
Colours alternate between levels: blue, yellow, blue…
Each trial lasts 2 minutes. At the end, count the complete levels still standing that meet these rules.

Scene from Cédric Fleury’s original lab. The handout mentions a record of 19 levels after two attempts: a historical reference, without a required target for this session.

1. Explore the project and basic interactions

Open the appropriate version

Download the Unity 6.3 project, extract it and add the Interaction3D folder through Unity Hub > Add project from disk. Select the folder containing Assets, Packages and ProjectSettings.
The project was saved with 6000.3.1f1. Use the version assigned for your session and keep a copy before converting it. Wait for package resolution and check Console for errors.
Open Assets/Scenes/Interaction.unity. Locate both generators, the platform, timer and controllers.
For a standalone Quest, check Unity’s Android modules, File > Build Profiles, the Android/Meta Quest platform, build scene and XR settings. If needed, follow the deployment section of the VR introduction. Use Build And Run with a headset prepared for development.

Provided configuration

Keep the project’s package versions

The Unity 6.3 project manifest contains XRI 3.3.0, OpenXR 1.16.0 and Input System 1.17.0. The imported Starter Assets remain in a folder named 3.1.2: this records the sample version when it was imported. Use these existing resources; do not automatically reimport samples from another version.

The project also contains the Oculus package. Check the active XR provider for your platform and avoid enabling multiple providers for the same headset. The VR introduction uses slightly different versions: follow its configuration method without blindly replacing this project’s packages or rig.

A Unity 2022.3.49f1 archive is also available for sessions using that editor; it contains XRI 3.1.2. Choose one archive as your starting point.

Try the task

The controls below follow the supplied handout for Touch controllers. Check the project’s bindings if you use other hardware.

Control	Action
Left thumbstick	Move through the scene.
X button	Switch navigation mode, including teleportation.
Right controller contact + index trigger	Grab a block or select a generator / Reset button.
Right B / left Y button	Switch the technique on the corresponding hand once several modes are configured.

Try continuous movement and teleportation. Find a position from which you can reach the generators and tower.
Generate a few blocks, grab and rotate them, then release them on the platform.
Reset the scene and complete a first timed trial. The supplied script starts the timer when the first block is generated after a reset.
Record your first score, then your best score after a few attempts. Use the same number of trials when comparing configurations.

Record — report part 1: both scores, your preferred navigation mode and why it suits this task.

2. Set up technique switching on each controller

The Controller Manager component (ControllerManager.cs) lets you switch interactors at runtime without rebuilding the application for each comparison.

Select the right controller, then the left, and locate Controller Manager and its Switch Mode action.
Each mode must be a direct child of its controller and have the ControllerMode tag. Use the existing Direct Interactor as an example.
Add subsequent modes as siblings of the Direct Interactor, in the order you want to test them. A tagged mode root can contain several components or child objects.
At startup, the script collects these children, disables the modes and enables the first one. B or Y cycles to the next while disabling the others. With only one mode, pressing the button makes no visible change.

Hierarchy example from the original handout. Object names may vary slightly.

Check: after adding a second mode, confirm in Play that only one mode root is active on each hand. Release held objects before switching. Tag the direct child: the script does not search grandchildren when building its mode list.

3. Change the blocks’ manipulation point

The initial grab brings a block towards its configured attachment point. Compare this with a grab that preserves the contact point.

Duplicate both generators. Make the new versions visually distinguishable while retaining a blue family and a yellow family.
In Assets/Prefabs, duplicate Blue_cube and Yellow_cube. Name the copies, for example, Blue_cube_Dynamic and Yellow_cube_Dynamic.
On each copy, enable Use Dynamic Attach in XR Grab Interactable. Explore Match Position, Match Rotation and Snap To Collider Volume. Change one setting at a time.
In each new generator’s Generate Cube component, assign the corresponding prefab to Cube. Keep the timer reference.
Grab blocks near their centre and near an end. Compare positioning and orientation with the original blocks, then repeat the task.

Record — part 3: benefits and limitations of Dynamic Attach when grabbing, rotating and placing blocks. Use concrete observations.

Reference: XR Grab Interactable — Unity documentation.

4. Add a virtual ray

Configure distant selection

Add an XR Ray Interactor as a child of the right controller: right-click in Hierarchy, XR > Ray Interactor. Name the mode Ray and tag its root ControllerMode.
In Interaction Layer Mask, allow the blocks’ and generators’ layers, but exclude the layer reserved for teleportation (Teleport or Teleport Layer, depending on the project).
Under Input Configuration, configure Select Input for the right trigger, reusing the action reference from the supplied Direct Interactor. Do not assume Select uses the same button as in the previous lab.
Disable UI Interaction for this activity. Check the ray’s origin, direction and line components.
Run the application, switch to Ray with B, and test distant generation and grabbing.

Check: the ray selects blocks and generators without triggering teleportation. A target must share an XRI interaction layer with the interactor and be detected by its physics raycast: Interaction Layer Mask and Raycast Mask are separate filters.

Compare variants

Duplicate the Ray mode under the same controller and name each variant clearly. Keep the inputs and filters unchanged so that only the option under study differs.

Variant	Setting to compare	Expected observation
Basic ray	Force Grab disabled	Manipulate the block at a distance.
Ray with retrieval	Force Grab enabled	The selected block comes to the hand.
Adjustable attachment	Manipulate Attach Transform enabled	Move the attachment using the thumbstick; check translation/rotation inputs.

Repeat a trial with each variant. Examine generator access, transport to the centre, block rotation and release accuracy. If the thumbstick controls several actions, inspect their bindings and possible conflicts with locomotion.

Record — part 4: benefits of the ray over direct grabbing, benefits of direct grabbing, advantages and drawbacks of Force Grab, usefulness of Manipulate Attach Transform, preferred configuration and best score.

Reference: XR Ray Interactor — Unity documentation.

5. Test Near Far

Find Right_NearFarInteractor in Assets/Samples/XR Interaction Toolkit/3.1.2/Starter Assets/Prefabs/Interactors. Add it under the right controller as a new mode.
Tag its root ControllerMode. Check right-hand references, Select inputs and interaction filters, as you did for the ray. Disable UI interaction to keep conditions consistent.
Select a nearby block, then a distant one. Observe how the technique combines near and distant interaction.
Compare Far Attach Mode = Near and Far: in the XRI 3.3 documentation, this setting controls retrieval to the hand or manipulation at a distance. The original handout calls this “Force Grab”; locate the corresponding setting in your installed component.
Complete the task with both variants. Create two modes if you want to compare them using B without rebuilding.

Record — part 5: the technique covered in class that is most similar, benefits and drawbacks for this task, and any difficulties when transitioning between near and far interaction. Support your answer with observations.

Reference: Near-Far Interactor — Unity documentation.

6. Use both hands

Add manipulation modes to the left controller too. Use Left_NearFarInteractor for Near Far, or adapt a ray’s inputs and handedness to the left hand.
Check tags and actions. Y switches the left mode and B the right; do not leave right-hand actions assigned to both hands.
Try a symmetric combination, then assign different roles to the hands: for example, retrieve blocks with one and position them with the other.
Compare these combinations with your best one-handed configuration using the same rules and duration.

The goal is to manipulate two blocks or distribute actions between hands. You do not need to enable simultaneous selection of the same block by both controllers.

Record — part 6: benefits of two techniques, most efficient combination, justification and best number of levels.

Compare results and write your report

Use the original report template in English and the questions on this page. See also the general report guidelines. Question numbering follows the handout: part 2 prepares the interactions and has no separate section in the template.

For each configuration, record the settings you actually tested:

Configuration	Left / right hand	Grab point	Options	Trial 1	Best score	Observations
Initial direct	Specify	Initial	Navigation mode	…	…	…
Dynamic direct	Specify	Dynamic	Attachment settings	…	…	…
Ray	Specify	Specify	Force Grab / attachment	…	…	…
Near Far	Specify	Specify	Far Attach Mode	…	…	…
Two hands	Specify	Specify	Chosen combination	…	…	…

Allow comparable short practice periods, reset between trials and record the number of repetitions. Separate measured performance from subjective experience: a technique can be fast while requiring more effort. Learning may improve scores throughout the session; a single best trial does not establish that one technique is generally superior.

Before finishing: save the scene, modified prefabs and Packages files. Your application should switch modes without rebuilding, generate both colours, reset the task and support one-handed and two-handed trials.

Troubleshooting

Symptom	Check
B / Y does nothing	Multiple direct children tagged ControllerMode, Switch Mode action and hierarchy order.
The ray is visible but cannot grab	Select Input, colliders, Interaction Layer Mask, Raycast Mask and the target’s interactable component.
The ray triggers teleportation	Exclude its layer from manipulation modes and check shared inputs.
A new generator produces the original blocks	The Generate Cube component’s Cube field and the prefab you actually edited.
Near Far uses the wrong hand	Left/right prefab, Handedness and action references.
Generation stops after time runs out	Use Reset before starting again: the supplied timer requires a reset.
The headset does not launch the scene	Build scene, platform, XR provider and connection; revisit the VR introduction.

Author and original resources

Original lab designed by Cédric Fleury for the RVRA course, RVSI track of the FISE programme at IMT Atlantique, Brest campus. Contact listed in the handout: cedric.fleury@imt-atlantique.fr.

This page provides a French and English web adaptation of the supplied handout and resources for the 2025–2026 academic year. The task and controller illustrations come from the original handout.

Original handout — English PDF.
Original report template — English DOCX.
Unity 6.3 project: project files retained; precompiled APK and macOS metadata removed to reduce the download size.
Original Unity 2022.3 project.

Lab — 3D navigation in virtual reality

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

RVRA · RVSI · 3D navigation

Goal: Compare locomotion techniques
Environment: Unity 6.3 · XRI 3.3.0
Provided project · VR headset
Prerequisites: Unity and VR basics

How can you move efficiently through a virtual environment? In this lab, you will test several navigation techniques, tune their parameters and compare their effects on target search, orientation and comfort.

The project provides a city and a small maze containing red buttons called “buzzers”. In the maze, measure the time needed to activate 8 buzzers. In the city, activate as many as possible in 2 minutes.

This lab builds on Unity 3D Basics and A First Virtual Reality Application. The search task is already implemented: your work focuses on locomotion techniques and their evaluation.

Lab files Download the project Unity 6.3 / 2022.3 · PDF · Report template Before you start A first VR application Tracking, controllers, teleportation and headset builds

Original lab by Cédric Fleury for the RVRA course, RVSI track, FISE, IMT Atlantique, Brest campus. Bilingual web adaptation of the supplied handout and projects.

Lab outline

Resources and starter project

Download both archives for one editor version and extract them into the same parent folder: their contents merge into Navigation3D. The resulting folder must contain Assets, Packages and ProjectSettings, including Assets/VRTemplateAssets. Add this Navigation3D folder to Unity Hub. Keep the two editor versions in separate folders.

Version	Project and scene	VR template assets
Unity 6.3 — main route	6000.3 project	6000.3 assets
Unity 2022.3 — alternative	2022.3 project	2022.3 assets

The downloads preserve the teaching files from the supplied projects. Builds, caches and local editor files have been omitted; Assets, Packages and ProjectSettings files are retained without modification.

Open and run the scene

Open Assets/Scenes/Navigation.unity. Wait for importing to finish and resolve blocking Console errors before building the application.
For a standalone Android headset, check the Android modules in Unity Hub and the target platform’s XR configuration. In File > Build Profiles (Unity 6) or Build Settings (2022.3), select Android or the appropriate headset profile. Make sure the Navigation scene is enabled.
If necessary, revisit the deployment steps in the introductory VR lab. Select the headset and choose Build And Run. Android settings apply to standalone builds; PC VR testing in Play requires the appropriate PC configuration and runtime.
In the headset, locate the score panel, timer, city, maze entrance and maze exit.

Interact and measure

Initial control	Effect
Left thumbstick	Move forward, backward and sideways.
Right thumbstick	Turn, in addition to physically rotating your head.
Right controller touching a buzzer + index trigger	Activate the target: it turns green.

Practise freely to understand the task and controls.
Maze: activate the buzzer in front of the score panel, find and activate the 8 buzzers in the maze, then record the time when you exit.
City: start a fresh attempt and record the number of buzzers activated in 2 minutes. Use the panel’s reset control between attempts.
Record your baseline results in part 1 of the report.

Environments used for the search task. Illustration from Cédric Fleury’s original handout.

2. Configure continuous movement

In Hierarchy, expand XR Origin, then Locomotion. Find Move and Turn, their providers and their action references.
Explore the inputs on both components to choose how commands are distributed between the left and right thumbsticks. Change one setting at a time and keep a way to restore the initial configuration.
Tune translation and turn speeds. Find a compromise between fast movement through streets, precision in corridors and comfort.
Perform both tasks with the same configuration and parameters in the city and maze.
In part 2 of the report, record the actions assigned to each thumbstick, the selected speeds, maze completion time and city score. Explain your choices.

Check: movement and turning respond independently; one input should not trigger competing behaviours.

The supplied NavigationModeManager script on Locomotion lets you switch techniques without rebuilding the application for each trial.

Inspect its Switch Mode action reference. The handout uses the Y button on the left controller; check the actual binding for your hardware.
Open the script: it checks the hosting object’s direct children and selects those tagged NavigationTechnique. At startup, it enables the first one; each press enables the next and disables the others.
Check the tag on Move, then on the techniques you want to include. Keep at least one correctly tagged child. Child order determines cycling order.
Keep the manager, shared actions and components required by all techniques enabled. Utility objects should not receive this tag.

Check: in Play or in the headset, press Y several times and observe which objects are active. Exactly one technique in the list should be active at a time. Turn can remain shared: check its inputs before reusing the right thumbstick for scaling.

4. Add teleportation

The Teleportation object is already present under Locomotion. You need to associate a selection ray with it and check its connections to teleportable surfaces.

Find Teleport Interactor under Assets/Samples/XR Interaction Toolkit/3.1.2/Starter Assets/Prefabs/Interactors and add it beneath the supplied rig’s left controller.
On XR Ray Interactor, set Interaction Layer Mask to include Teleport. Also check Raycast Mask and the ground colliders. XRI interaction layers and physics layers are separate filters.
Disable UI Interaction and Manipulate Attach Transform for this exercise. Assign Attach Transform and Ray Origin Transform to the appropriate left-controller transforms.
Under Input Configuration, assign both Select inputs to XRI Left Locomotion/Teleport Mode, as specified in the handout. Check the references in the project’s input action asset.
In the Disable Interactor script on Teleportation, assign the Teleport Interactor GameObject to Associated Interactor. Its active state will then follow the technique’s active state.
Check Teleportation’s NavigationTechnique tag, its provider and locomotion references. Check that the ground has a teleportation surface compatible with the Teleport interaction layer.
Switch to this mode with Y. Test several ground destinations, then return to continuous movement: the teleportation ray should be disabled.
Compare ray shapes and their range settings. For a straight ray, inspect Max Raycast Distance; for a curve, inspect its shape-specific parameters. Repeat both tasks with your chosen settings.

Record in part 4: ray shape and range, justification, maze time, city score, and benefits and drawbacks compared with continuous movement.

Reference: XR Ray Interactor — parameters and line types.

The goal is to change the user’s scale relative to the world to gain different viewpoints and travel greater distances. This control must remain available with continuous movement and teleportation.

Create a new child under Locomotion for scale control. Do not tag it NavigationTechnique: it must remain active when Y switches techniques.
Add the supplied ContinuousScaleChangeProvider script and assign its reference to the rig’s Locomotion Mediator.
In Input Actions, look for the scale action described in the handout, XRI RightHand Locomotion/scale, and check its existence and binding. If it is missing from your archive, create a Value / Vector2 action bound to the right thumbstick and enable its action map through the Input Action Manager. Assign it to Right Hand Scale Action. Avoid simultaneously triggering Turn with this input.
Read the script: action properties and thumbstick reading are supplied, but Update() still contains TODO steps.
Implement input reading, then uniform scaling of the XR Origin Transform. Use elapsed time so the rate is independent of frame rate. Apply strictly positive limits and gradual changes, and check the mediator reference before using it.
Start with small changes. Observe height, the point about which scaling occurs, interaction reach, apparent speed and collisions.
Adjust the Teleport Interactor, particularly its range and ray reference frame, to keep destinations usable at different scales. Check the calculated ray and its visible representation separately.
If possible, add a control that restores the initial scale, then test its usefulness when you lose your bearings.
Repeat the 2-minute city task with continuous movement + scaling, then teleportation + scaling.

Record in part 5: scores for both combinations, benefits and drawbacks of multi-scale navigation, which technique works best with it, and the usefulness of restoring the initial scale. Describe the adjustments you needed.

6. Test Grabbing-the-Air

This technique lets users move the virtual world through grabbing gestures, in translation and rotation.

Inspect Grab Move, already present under Locomotion, and its components’ actions. Check that it is included in the technique list.
Enable this mode with Y and identify the grabbing controls. Test movement with one hand, then two hands; observe movement direction and its effects on orientation.
Repeat at several scales, then find the 8 maze buzzers. Record the time and difficulties you encounter.
In the city, combine this technique with scale control and measure the score over 2 minutes.
To explore movement without being blocked by the ground or buildings, the handout suggests disabling the XR Origin’s CharacterController. Treat this as a separate trial, record the change in your report and re-enable it to restore the previous conditions.

Record in part 6: benefits, drawbacks, precision, physical effort and suitability for multi-scale navigation. Support your answers with situations observed in both environments.

Handout reference: Grabbing-the-Air — HCI Museum.

7. Bonus: World-in-Miniature with teleportation

Create a miniature representation of the city to help locate buzzers and select a distant destination.

Display a miniature world, separate from the full-size environment. Avoid duplicating the score logic, rig or main-scene interactions inside it.
Allow users to point at a location in the miniature with a virtual ray.
Convert the selected point from the miniature’s coordinate system to the world’s coordinate system, then move the rig to a valid destination. Account for the miniature’s translation, rotation and scale.
Check that the destination is accessible and that the miniature remains usable after travelling.
Compare this search aid with multi-scale navigation: target discovery, orientation and destination precision.

Sources from the handout: Stoakley, Conway and Pausch, Virtual Reality on a WIM, 1995, video demonstration and UnityWorldInMiniature example.

Report and discussion

Complete the original report template. Its questions are also covered throughout this page. Use the table below to gather results; include units, parameters and the number of attempts.

Condition	Maze: time for 8 buzzers	City: buzzers in 2 min	Settings and observations
Initial navigation	Measure	Measure	Supplied configuration
Configured continuous movement	Measure	Measure	Same parameters in both environments
Teleportation	Measure	Measure	Ray shape and range
Continuous + multi-scale	—	Measure	Scale limits and control
Teleportation + multi-scale	—	Measure	Ray adjustments
Grabbing-the-Air	Measure	Measure with multi-scale	One/two hands, collisions

Conclude by relating performance to each environment’s characteristics. Which technique would you choose for searching the city? For travelling through a narrow space? Discuss the trade-off between efficiency, orientation and comfort, and the limitations of your trials.

Troubleshooting and reminders

Problem	Checks
Camera stays still in the headset	Disable the simulator before building; check XR tracking and the target platform’s provider.
Y does not switch techniques	Active Switch Mode action, controller binding, direct children tagged `NavigationTechnique`, non-empty list.
Ray visible but teleportation fails	XRI Teleport layer, physics mask, ground collider and surface, Select actions, provider and mediator.
Ray appears in every mode	Associated Interactor reference and activation of Teleportation by the manager.
Scaling has no effect or throws an exception	Completed script, assigned mediator, active Vector2 action, correct XR Origin target.
Turning and scaling happen together	Right-thumbstick actions shared by Turn and the scale provider.
Changes do not appear in the headset	Save the scene, rebuild and install the correct scene from the correct project copy.

The supplied XR Interaction Simulator lets you check logic in the editor: enable it for testing without a headset and consult its control overlay. Disable it before headset trials and builds. Performance, perceived scale and comfort must be evaluated in the headset. Take breaks and stop a trial if you feel discomfort.

Documentation: XRI 3.3 locomotion for the Unity 6 project; XRI 3.1 manual for the 2022.3 alternative.

Credits: original handout, search task and starter projects by Cédric Fleury, RVRA course, RVSI track, FISE, IMT Atlantique — Brest campus. Script and action names are preserved to make it easy to connect this page to the original resources.

Lab — First virtual reality application

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

Getting started · Virtual reality

Estimated duration: 3 hours
Environment: Unity 6.3 LTS · URP
OpenXR · XRI 3.3.2
Level: VR beginner · Unity basics

You will build a small VR cube workshop: look around, teleport, grab and throw objects, spawn a cube with a controller button and change an object’s color by pointing at and selecting it.

This lab usually follows Unity 3D Basics. You should know how to create a scene, edit a Transform, add a component, make a prefab and attach a C# script. If you already have these skills, you can start here directly.

Allow approximately 3 hours, including installation and initial builds; adjust this estimate to the available hardware.

Before you start Unity 3D Basics Scenes, components, prefabs and first C# scripts Read first Lab report guidelines Report expectations and outline

Documentation Unity 6.3 manual XR Interaction Toolkit 3.3 OpenXR 1.16

Brest campus only School PC configuration

Lab outline

Continue with: the 3D Navigation lab compares continuous movement, teleportation, multi-scale navigation and Grabbing-the-Air in a city and maze.

1. Prepare the project and packages

Create a simple workshop

In Unity Hub, create a Universal 3D project with Unity 6.3 LTS (6000.3). Name it VRBasics.
In Assets, create Scenes, Materials, Prefabs and Scripts folders. Save the scene as Assets/Scenes/VRBasics.unity.
Add a Plane named Ground, position (0, 0, 0), scale (2, 1, 2): it measures 20 × 20 meters. Keep its collider.
Add a table using a Cube named Table, position (0, 0.75, 2), scale (1.5, 0.1, 0.8). Keep its Box Collider; this fixed table does not need a Rigidbody.
Add three cubes with side length 0.15, spaced across the table, at Y 0.9. Add a Rigidbody to each, with Use Gravity enabled and Is Kinematic disabled. Create differently colored Universal Render Pipeline/Lit materials and assign them. Here, 1 Unity unit represents 1 meter.

Check: in Play, the cubes drop slightly and rest on the table. Stop Play before continuing.

Install the XR stack

Open Window > Package Management > Package Manager, then Unity Registry. Use the following stable versions as the session reference; avoid pre versions and do not update packages during the lab.

Package	Identifier	Role / reference
Input System	`com.unity.inputsystem`	Actions and bindings; 1.20.0, as in the Unity lab.
XR Plug-in Management	`com.unity.xr.management`	Enable XR providers for each platform; Unity resolves a compatible version.
OpenXR Plugin	`com.unity.xr.openxr`	Communication with the XR system; 1.16.1.
XR Interaction Toolkit	`com.unity.xr.interaction.toolkit`	Interaction and locomotion; 3.3.2.

The Unity 6.3 pages list XRI 3.3.2 and OpenXR 1.16.1 as the reference versions released for this editor. Newer branches exist; this lab fixes a common baseline so everyone can find the same components and samples.

Install any missing packages. If needed, use Install package by name with the identifier and version above. Let Unity install their dependencies.
In Edit > Project Settings > Player > Other Settings > Configuration, check Active Input Handling = Input System Package (New). Accept a restart if requested.
In XR Interaction Toolkit > Samples, import Starter Assets and XR Interaction Simulator. Choose the latter carefully: XR Device Simulator is a separate sample containing the older simulator.
Open Edit > Project Settings > XR Plug-in Management > Project Validation. Select the platform to check, read the reported issues and apply the fixes relevant to the installed packages and samples. If a rule asks you to create a Teleport interaction layer, apply it. Return here after choosing the headset platform.
Record the installed versions. Keep Packages/manifest.json and Packages/packages-lock.json with the project so you can reproduce its configuration.

2. Set up the viewpoint and controllers

Delete the initial Main Camera, or disable its GameObject. Keep the light and ground.
In Project, open Assets/Samples/XR Interaction Toolkit/3.3.2/Starter Assets/Prefabs. Drag XR Origin (XR Rig) into Hierarchy.
Set the rig’s root Transform to position (0, 0, 0), rotation (0, 0, 0) and scale (1, 1, 1). In its XR Origin component, choose Requested Tracking Origin Mode = Floor for a headset using floor tracking. Check that Camera references the rig’s child camera.
Add GameObject > XR > XR Interaction Manager if the scene does not already contain one. Keep a single manager for this lab. You can assign it to the Interaction Manager field of the interactables you create later.
Expand the rig and locate the camera, left and right controllers, their interactors and the Locomotion group. Check that the rig’s Input Action Manager references XRI Default Input Actions, supplied by the Starter Assets. Keep the prefab’s action references.

Landmarks to find in Hierarchy — child object names may vary slightly:

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

First test without a headset

In Assets/Samples/XR Interaction Toolkit/3.3.2/XR Interaction Simulator, find the XR Interaction Simulator prefab. Drag it into the scene alongside the rig.
Enter Play and click inside Game. Use the simulator’s on-screen help to move the viewpoint, then simulate each controller. Tab switches between FPS mode and device manipulation; the controls shown in Game let you choose controllers. On an AZERTY keyboard, check or adjust the sample’s bindings if a key is difficult to reach.
Check that the viewpoint and both controllers respond. The simulator produces XR input; it does not replace the rig’s components.

Do not enable automatic simulator insertion in the XRI settings while also adding its prefab manually. Disable the simulator GameObject whenever testing with a headset and before building. Testing without a headset checks interaction behavior; perceived scale, tracking and comfort must be evaluated in the headset.

Reference: XR Interaction Simulator installation and controls.

3. Run the application on a headset

Perform this first test as soon as hardware is available. If headsets are shared, continue the exercises with the simulator while you wait.

Standalone Meta Quest: build and install an APK

The instructor or owner must prepare the headset for development: developer mode enabled, a USB data cable and the USB debugging prompt accepted inside the headset. In Unity Hub, check that your Unity installation includes Android Build Support, Android SDK & NDK Tools and OpenJDK.
Open File > Build Profiles, select Meta Quest, then Switch Platform. If you use the workstation’s Android profile, switch to it and apply the Quest settings below. Unity 6.3 provides a dedicated Meta Quest profile, based on Android, which installs OpenXR and preconfigures several settings.
In Project Settings > XR Plug-in Management, select the Android tab and enable OpenXR as the provider. Use this stack for the lab; leave the Oculus provider disabled.
Under XR Plug-in Management > OpenXR, still for Android, enable Meta Quest Support and add Oculus Touch Controller Profile to Interaction Profiles. Here, “Oculus Touch” names an OpenXR controller profile. Consult the Meta Quest Support settings for profiles specific to your hardware.
In Player > Other Settings, check Scripting Backend = IL2CPP and Target Architectures = ARM64. With the Meta Quest profile, keep its preconfigured graphics settings. With Android, apply OpenXR fixes appropriate to the headset. Return to Project Validation, select Android and fix blocking errors.
In Build Profiles > Scene List, add the open scene: VRBasics must be checked and first. Give the application a unique identifier, such as com.yourname.vrbasics, in Player settings.
Select the headset in Run Device, refreshing the list if needed, then choose Build And Run. Save the APK in a Builds folder at the project root, outside Assets. The first build often takes longer than subsequent builds.

Check: in the headset, look at the table, turn your head and move slightly within your physical play area. The viewpoint should follow your movements; the controllers should follow your hands. The cubes cannot be grabbed yet.

PC headset: test directly in the editor

On a workstation compatible with the headset and its PC software, select the PC platform and enable OpenXR in the PC tab of XR Plug-in Management. Configure a suitable controller profile, start the manufacturer’s OpenXR runtime, then enter Play with the simulator disabled. A Quest in Link mode also needs its connection to the PC software; simply connecting a USB cable does not create a PC VR session. Android settings do not configure PC testing.

4. Move by teleportation

In the rig’s Locomotion group, locate Locomotion Mediator, XR Body Transformer and Teleportation Provider. Check their references to the rig and mediator. Keep this XRI 3 structure: older tutorials using Locomotion System do not describe this configuration.
Add Teleportation Area to Ground. Assign the XR Interaction Manager and the rig’s Teleportation Provider to the corresponding fields. Check that the ground collider appears in Colliders, or leave automatic discovery if it finds it correctly.
Set its Interaction Layer Mask to Teleport. If this layer is missing, create it under Project Settings > XR Plug-in Management > XR Interaction Toolkit > Interaction Layers, then use it on both the surface and teleport ray.
On the rig’s controllers, find the dedicated teleport interactors. Their Interaction Layer Mask must include Teleport, and their Raycast Mask must include the ground’s physics layer. Keep the sample’s preconfigured Teleport Mode and confirmation actions. On each controller’s Controller Input Action Manager, uncheck Smooth Motion Enabled and Smooth Turn Enabled to start with teleportation and snap turning. The prefab initially enables continuous movement on the left and teleportation on the right.
In XRI Default Input Actions, find the XRI Left Locomotion and XRI Right Locomotion maps. Read the Teleport Mode and Teleport Mode Cancel bindings. With the standard thumbstick controller bindings, push the thumbstick forward to aim, then release to confirm; check the actual binding and the surface’s Teleport Trigger if behavior differs.
Test three destinations on the ground. Also aim at the table: it should remain a surface you cannot teleport onto. Watch the XR Origin’s root Transform during the test.

Distinguish two masks: a GameObject’s physics Layer and the Raycast Mask filter Unity collisions/raycasts; the Interaction Layer Mask filters XRI relationships. Creating a physics layer named Teleport does not create an XRI interaction layer. See interaction layers.

Check: a valid destination displays the ray’s visual feedback; confirming moves the rig onto the ground while preserving the headset’s tracked height. If the color does not change, check colliders and masks first, then actions.

Locate Snap Turn Provider, Continuous Turn Provider and the continuous movement provider (Dynamic Move Provider in the Starter Assets). Start with teleportation and snap turning; use the controllers’ Controller Input Action Manager settings to select snap turning and disable continuous movement. Check that only one turning mode is active.

Once the interaction works, briefly try continuous movement if you feel comfortable, then restore the initial configuration. Explain: what moves the camera when you walk physically? What happens when you push the thumbstick? Which mode makes distances and orientation easiest to understand?

Reference: Teleportation Area.

5. Grab and throw cubes

Add XR Grab Interactable to a cube. Keep its Box Collider, with Is Trigger disabled, and its Rigidbody. Assign the manager. Keep Interaction Layer Mask = Default for manipulable objects and check that the rig’s manipulation interactors accept this layer.
Choose Select Mode = Single and Movement Type = Velocity Tracking. Leave Throw On Detach enabled. This mode uses the Rigidbody during tracking and lets you start observing collisions; still avoid very fast movements through the table.
Test grabbing at close range with the controller’s grip, then releasing. Next, try at a distance using the rig’s manipulation ray. Inspect the Select binding in XRI Right Interaction or XRI Left Interaction to confirm which button is used.
Make a gentle throw away from yourself. The cube should fall and remain on the ground. Its velocity comes from the release tracked by XRI: no projectile script is needed here.
Turn the cube into a GrabbableCube prefab in Assets/Prefabs. Equip the other cubes in the same way or replace them with instances. Keep teleportation objects on their dedicated interaction layer.

Check: you can pick up a cube, put it on the table, pick it up again and throw it. Only one controller holds it at a time. On a copy, compare Velocity Tracking, Kinematic and Instantaneous: observe responsiveness and contact with the table, then restore the initial mode.

Question: how does moving a Transform differ from asking a Rigidbody to follow a target? Why might an object feel more responsive while also passing through obstacles more easily? See the XR Grab Interactable movement modes.

6. Spawn a cube with a controller action

You used a keyboard or mouse action in the Unity lab. The principle remains the same: an action represents an intention, and a binding connects it to a hardware control. Here, you will create a dedicated action so that pressing a button to grab an object does not also spawn a cube.

Define the action

In Assets, create an Input folder, then an asset through Create > Input Actions, named VRLabActions.
Double-click it and create an Action Map named Lab, then a Spawn action with Action Type = Button.
Add the binding <XRController>{RightHand}/secondaryButton: the right controller’s secondary button, usually B on Quest. Keep the action triggered on press; do not use a Value or Pass Through pose action.
Also add a <Keyboard>/n binding to check your script without a headset. Save the asset with Save Asset if autosave is disabled.

Write and connect ObjectSpawn

Create ObjectSpawn.cs using Create > Scripting > MonoBehaviour Script, then attach it to an empty GameObject named CubeSpawner. The file and class must have the same name.

Expose these fields in the Inspector:

using UnityEngine;
using UnityEngine.InputSystem;

// Fields to place inside the ObjectSpawn : MonoBehaviour class.
[SerializeField] private InputActionReference spawnAction;
[SerializeField] private GameObject cubePrefab;
[SerializeField] private Transform spawnPoint;

Your task:

Create an empty GameObject named SpawnPoint at the scene root, position (0, 1.2, 2), rotation (0, 0, 0), scale (1, 1, 1). Check in Scene that it is above the tabletop. It is not a child of the table, so it does not inherit its scale.
Assign VRLabActions > Lab/Spawn, the GrabbableCube prefab from Project and the SpawnPoint Transform to the script’s three fields.
In OnEnable, subscribe a named method, such as SpawnCube(InputAction.CallbackContext context), to spawnAction.action.performed, then enable the action with Enable().
In OnDisable, unsubscribe the same method with -=, then call Disable(). This component alone owns activation of this dedicated action. Do not call Disable() this way on an action shared by the rig. For this exercise, do not add VRLabActions to another Input Action Manager.
In the callback, use Instantiate(cubePrefab, spawnPoint.position, spawnPoint.rotation). Check references before using them and limit tests to a few cubes to avoid accumulating physical objects.

The snippets are guidance: complete the class and methods yourself. As in the Unity lab, wait for compilation and fix the first Console error before entering Play.

Check: pressing N spawns a single cube above the table; holding it should not spawn a cube every frame. Disable and re-enable CubeSpawner in the Inspector during Play: each press should still spawn just one cube. Then test the right secondary button in the headset. The spawned cube must be grabbable.

Explain: why use a named method so you can unsubscribe it? Why create a Spawn action instead of reusing Select? Reference: Input System actions.

7. Respond to hovering and selecting an object

Add a small colored marker to the table beside the cubes and keep it fixed. The goal is to show hover feedback, then persistently change its color with each selection.

Create a cube named ColorTarget, position (0.55, 0.95, 2), scale (0.2, 0.3, 0.2). Keep its Box Collider. Add XR Simple Interactable, assign the manager, and set Interaction Layer Mask = Default, Select Mode = Single. Do not add XR Grab Interactable: this marker stays on the table.
Create TargetFeedback.cs and attach it to the marker. Expose a Renderer reference, two persistent colors and a hover color. Assign the Renderer in the Inspector.
Write three public methods without parameters: BeginHover(), EndHover() and ToggleColor(). The first two change the hover state; the third toggles the persistent color. A shared method updates the appearance: hover color while pointing at the marker, persistent color otherwise. Leaving hover then reveals the last selected color correctly.
To isolate this marker’s color, you can obtain a material instance once through targetRenderer.material in Awake, keep it, then modify its color property. Destroy this instance in OnDestroy. Modifying sharedMaterial would also affect other objects using that asset; do not create a new instance every frame.
Expand Interactable Events on XR Simple Interactable. For each event, click +, drag the ColorTarget GameObject into the object field, then choose the appropriate TargetFeedback method:

XRI event	Method to call	Expected effect
First Hover Entered	`BeginHover()`	Enable visual feedback on the first ray/contact.
Last Hover Exited	`EndHover()`	Remove feedback after the last ray/contact leaves.
Select Entered	`ToggleColor()`	Toggle the persistent color once per selection.

The First/Last events prevent one controller leaving the marker from clearing hover while the other still points at it. In the UnityEvent function menu, select your methods’ parameterless versions.

Check: point at the marker with one controller, select it using the grip mapped to Select, then point away: the new color should remain. Point at it with both controllers and move only one away: hover feedback should remain active.

8. Check the application and report your results

Stop Play, save and disable the simulator. Rebuild the application and repeat the workflow on the target headset.

Test	Expected result
Turn and move your head	Tracked view, consistent height and scale.
Move both controllers	Visible poses and rays, without unexplained offsets.
Teleport onto the ground, then aim at the table	Ground accepted, table rejected, height preserved.
Grab, place and throw a cube	Manipulable object, contact with ground and table.
Press the Spawn button	One cube per press, at the intended point, grabbable.
Hover over and select the marker	Temporary hover feedback, selected color preserved afterward.

Follow your session’s lab report guidelines. Present the hardware and versions, a screenshot of the rig hierarchy, your scripts and the test results. Distinguish simulator, Play with a PC headset and standalone APK tests; identify hardware tests you could not perform.

In particular, answer these questions:

What does the XR Origin do compared with the tracked camera?
How does a physics layer differ from an XRI interaction layer?
What connects a physical button to your cube spawning method?
Why distinguish hovering, selection and activation?
Which movement mode would you choose for a first visit to your scene, and why?

Further exploration

Add a Teleportation Anchor to reach a fixed observation point and compare it with a free teleport area.
Add an XR Socket Interactor to store a cube at a precise location.
Add a World Space interface with an XR UI Input Module and a Tracked Device Graphic Raycaster; use the ray to operate a reset button.
Explore haptic feedback and check its effect in the headset, since the simulator cannot reproduce the sensation.
Continue with the VR comfort lab or the XR Engineering & Debugging lab to structure and instrument a larger application.

Troubleshooting

Fix the first red Console error first. When asking for help, always provide the step, active platform, versions and exact message.

Symptom	Priority checks
Camera does not move or has the wrong height	One rig and one active camera; XR Origin Camera reference; Floor/Device mode; simulator active only without a headset; OpenXR provider for the target platform.
Headset detected over USB but no VR in Play	A USB connection for APK installation does not provide PC VR. Check the PC runtime, Link mode if applicable and PC OpenXR provider, or use Build And Run for standalone mode.
Hands or rays do not respond	Input System enabled, Input Action Manager and sample actions; suitable OpenXR profiles; controllers awake; no old FPS camera active.
Simulator does not respond	Game has focus; only one simulator; preconfigured rig present; sample help and bindings; no competing headset session.
Ray visible but no teleportation	Ground collider, XRI Teleport layer on both sides, Raycast Mask, provider and mediator, Teleport Mode action, surface trigger mode.
Cube cannot be grabbed or passes through objects	Collider, Rigidbody, XR Grab Interactable, manager, manipulation masks and Select action; check Movement Type and gesture speed.
N works but the headset button does not	RightHand/secondaryButton binding, OpenXR profile, correct hand and APK rebuilt after changes.
No cube or several cubes per press	ObjectSpawn references, action enabled, single subscription and matching unsubscription; no instantiation in Update; no duplicate CubeSpawner.
All objects change color	The script probably modifies sharedMaterial; use a material instance kept for the marker.
APK cannot be built or headset is missing	Android modules for the correct editor, Project Validation errors, USB authorization, data cable, Run Device, IL2CPP/ARM64. On Linux, also check USB access permissions and any build tools requested by Unity.
Old scene appears in the headset	Active Scene List and profile, VRBasics saved, new Build And Run completed without errors.

Continue exploring

The 3D interaction: comparing manipulation techniques lab uses a timed construction task to compare direct grabbing, virtual rays, Near Far and two-handed interaction.

Reference documentation

Documentation checked on 15 October 2026. Use the 3.3 XRI branch to match the names in this lab.

Lab — Virtual reality engineering and debugging

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

Objective

This lab (~7 hours) aims to teach you how to develop and maintain a VR application with:

a clear architecture (separation of responsibilities, explicit dependencies),
an efficient iteration workflow (test as much as possible without a headset, debug builds),
basic observability (VR overlay, structured logs),
XR debugging practices,
an introduction to VR profiling (optional, depending on the time remaining).

The application is a VR solar system visualization workbench: a manipulable tabletop model, a world-space UI, viewing modes and time controls.

Prerequisites

Skills

C# / Unity basics (scenes, prefabs, scripts)
Git basics (commit, tag, push)
VR basics (comfort, world-space UI) are helpful but not essential

Tools

Unity LTS (2022.3 or 2023 LTS)
Unity packages:
- OpenXR
- XR Interaction Toolkit (XRI)
- Input System
An OpenXR-compatible VR headset

Resources

PlanetData.cs (provides data and orbital calculation functions)

Engineering rules (required)

In this lab, you must explicitly apply the following rules:

No implicit dependencies
- No FindObjectOfType, no GameObject.Find, no “magic” dependencies.
- Required references are injected through the Inspector or a bootstrapper.
No business logic in Update() by default
- Reserve Update() for continuous operations that are actually necessary.
- Prefer events, actions and controlled timers.
Separation of responsibilities
- Data models / services (calculations, time, conversion) ≠ views (GameObjects) ≠ controllers.
Debuggability
- Every critical behavior must produce useful logs.
- Implement a DebugOverlay visible in the headset.
Performance (optional)
- No avoidable per-frame allocations (strings/LINQ).
- Profiling is required (before/after evidence for one improvement).

Scenario: Solar System VR Workbench

You will develop a VR application containing:

a solar system tabletop model (with adjustable scale),
planets positioned at a given time t (calculation functions are already provided by PlanetData),
time controls (date + speed),
orbits that can be shown or hidden,
a “planet focus” mode (centering/inspection),
a world-space VR UI to control the application,
a debug overlay (FPS, state, recent events, warnings).

Lab structure

The lab consists of 5 main steps and 2 optional extensions.

Required:

1 — XR boot
2 — Architecture
3 — Events / simulation
4 — VR interactions
5 — UI + debug overlay

Optional (if time allows):

6 — Guided XR debugging
7 — Performance optimization

Submission organization (Git)

You must submit:

a Git repository (link),
Git tags for each step (v1.0, v1.1, … v2.0),
a short report (README or PDF):
- screenshots (headset view or mirror),
- implemented features,
- architecture diagram (simple and readable),
- a “debug story” (if you completed step 6),
- a “perf story” (if you completed step 7).

Tag reminder

At each step:

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

Useful concepts for this lab

Before starting, here are some important concepts we will use throughout the session. They are common in Unity projects and even more important in XR.

1 — Business logic

Business logic means the rules that define how your application works, independently of its visual presentation.

Examples in this lab:

Business logic:

calculating a planet’s position at a given date
changing the speed of time
showing or hiding orbits
changing the solar system’s scale

Display (not business logic):

moving a GameObject
changing UI text
showing a panel

Bad example

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

Calculation and display are mixed together.

Good example

DateTime currentTime;

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

The logic decides when to update; the view decides how to display the result.

2 — Separation of responsibilities

In a Unity project, it is very easy to put a lot of functionality in a single script. This works for small projects but quickly becomes difficult to maintain.

We therefore separate the roles.

Simple structure used in this lab

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

Model (data)

Contains only data.

Example:

TimeModel

currentTime

timeSpeed

A model normally does not depend on Unity.

Services

Contain calculations or rules.

Example:

PlanetEphemerisService

computePosition()

Controllers

Coordinate the application.

They receive events and update views.

Example:

SolarSystemController

Views

Visible Unity objects.

Examples:

PlanetView

OrbitRenderer

UI panels

Summary

Model → store state
Service → calculate
Controller → decide what to do
View → display

3 — Bootstrapper

The problem

Many Unity projects contain:

FindObjectOfType
GameObject.Find
Singletons used everywhere

These approaches work but make the project fragile.

A simple solution

Create an object that initializes the application.

This is called a Bootstrapper.

Example:

AppBootstrapper

Its role:

create services
connect objects
initialize data

Simple example

public class AppBootstrapper : MonoBehaviour
{
 public SolarSystemController controller;

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

Dependencies become visible and controlled.

4 — Events

Events allow different objects to communicate without being tightly coupled.

Without events:

UI → Manager → Controller → Camera

Everything depends on everything else.

With events:

UI → Event → Interested objects

Each system remains independent.

Example

public event Action<DateTime> OnTimeChanged;

When the date changes:

OnTimeChanged?.Invoke(newTime);

Another script can listen for this event:

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

5 — Actions

An Action is simply a function stored in a variable.

Example:

Action<DateTime> callback;

In Unity, actions are used for:

events
callbacks
UI interactions

6 — Managing simulation state

In this application, the central variable is not really a technical “timer”. What matters is simply the simulation date.

In other words, we manipulate a global state:

Simulated date → planet positions → display

When this date changes:

planet positions must be recalculated
some visualizations must be updated
the interface can display the new value

Instead of constantly recalculating in Update(), trigger an event only when the state changes.

Bad approach

void Update()
{
 UpdatePlanets(currentDate);
}

Each object constantly checks whether something has changed.

Recommended approach

Use an event to signal a state change.

public event Action<DateTime> OnTimeChanged;

When the date changes:

UI → PlanetManager → event → interested objects

Example:

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

This provides:

fewer unnecessary calculations
more readable code
easier debugging
better VR performance

7 — Why this matters even more in XR

In VR and XR:

builds take longer
bugs are harder to diagnose
performance is critical

A clear architecture makes it possible to:

test some parts without a headset
understand a bug quickly
modify an interaction without breaking the whole project

8 — ScriptableObject

A ScriptableObject is a Unity asset used to store editable parameters.

Unlike a MonoBehaviour, it is not attached to a GameObject.

Example in this lab:

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

Then create the asset in Unity:

Assets → Create → XR → Solar System Config

Assign it in the Inspector.

Benefits:

centralized configuration
editable without changing code
reusable across scenes

What to remember

Throughout the lab, keep asking yourself:

Does this script do too many things?
Does this code depend on another object unnecessarily?
Can I understand this system quickly?
Could I easily debug this on a VR headset?

If the answer to either of the last two questions is “no”, you probably need to simplify or separate responsibilities more clearly.

Step 1 — XR boot + minimal scene (Tag: v1.0) — ~45 min

Objectives

Have a working VR scene and a debuggable build pipeline.

Tasks

Create the Unity project.
Install and enable:
- OpenXR
- XR Interaction Toolkit
  - You can add the Starter Assets (for a complete XR rig) and the XR Simulator (to test without a headset) from the package samples.
- Input System
Configure the project:
- Enable the plug-in providers required for your headset (OpenXR, Oculus, etc.) in Player Settings / XR Plug-in Management.
Add a VR rig (XRI):
- XR Origin
- XR Interaction Manager
Create a Boot scene:
- ground + reference frame (for example, X/Y/Z axes to show the world origin in the scene)
- an interactable cube (grab) to validate XRI
Configure a debug build:
- Development Build
- Script Debugging
- (if possible) Autoconnect Profiler

Expected deliverables

Screenshot (headset mirror view or XR simulator) showing the cube being grabbed in VR
Repository tagged v1.0-boot (remember the .gitignore)

Step 2 — Architecture: models, services, controllers

Tag: v1.1-architecture — ~1h15

Objective

Before adding VR, interactions and UI, we will structure the application properly.

In XR projects, problems often come from:

scripts referencing each other in every direction
logic mixed with display code
invisible dependencies
code that cannot be tested without a headset

We will build a simple architecture:

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

1 — Folder organization

Create the following folders:

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

Purpose:

Folder	Role
Bootstrap	entry point
Models	simulation state
Services	calculations
Controllers	coordination
Views	Unity GameObjects
Config	editable parameters

2 — The time model

In our simulation, the central variable is simulated time.

Create:

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:

this script does not depend on Unity
it contains only state and events.

3 — Solar system configuration

Some parameters must be editable in Unity.

Create:

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;
}

Then create the asset:

Assets → Create → XR → Solar System Config

4 — Using the provided astronomical data

The lab already provides a class:

PlanetData.cs

It contains:

orbital parameters
orbit calculations
the following function:

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

⚠️ This class is the official source for planet positions. Students must not modify this file.

5 — Planet position service

Even though the function already exists, we access it through a service.

Why?

keep the architecture clean
allow the implementation to be replaced later
make testing easier

Create:

Scripts/Services/IPlanetEphemerisService.cs

using System;
using UnityEngine;

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

Implementation:

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);
 }
}

This service acts as an abstraction layer.

6 — Planet view

Create:

Scripts/Views/PlanetView.cs

using UnityEngine;

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

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

Role:

represent a planet in the scene
apply the calculated positions

7 — Solar system controller

The controller connects:

the model
the service
the views

Create:

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);
 }
 }
}

Responsibilities:

Element	Role
Model	simulation state
Service	position calculation
Controller	coordination
View	display

8 — Bootstrapper

Create:

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);
 }
}

Role:

create the main objects
connect dependencies
start the simulation

This is called the composition root.

9 — Scene setup

Create a GameObject:

App

Add:

AppBootstrapper

In the Inspector:

assign SolarSystemConfig
assign the PlanetView references

Possible structure:

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

Each planet has a:

PlanetView

10 — Quick test

Run the scene.

Expected result:

the planets appear
they are positioned correctly
a [BOOT] log appears

If nothing happens, check that:

the PlanetView references are assigned
the bootstrapper is active
the scene is saved

If you follow the steps carefully, you should notice a small bug. Modify the service to fix it.

11 — Architecture check

Your code must meet these requirements:

no FindObjectOfType
no GameObject.Find
visible dependencies
a model independent of Unity
logic separated from display

12 — Architecture diagram

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

Expected result

At the end of this step:

the application is structured
the planets use PlanetData
dependencies are explicit
the simulation is driven by a model

Git tag:

v1.1-architecture

Step 3 — Planet positioning + events

Tag: v1.2-events — ~1h15

Objective

Implement the main simulation flow:

time changes,
an event is triggered,
the controller updates the planets.

We deliberately avoid running all the logic in Update().

Expected flow:

TimeController
 ↓
TimeModel
 ↓
OnTimeChanged
 ↓
PlanetSystemController
 ↓
PlanetView

We already created most of these elements in the previous step. Now we need to connect them properly using events.

Responsibilities:

Element	Role
Model	time state
Service	position calculation
Controller	applies positions
View	moves objects

1 — Trigger updates through an event

This was already implemented in the previous step, but it is important to understand how it works.

In TimeModel:

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

In the controller:

timeModel.OnTimeChanged += UpdatePlanets;

The planets therefore update only when time changes.

2 — Advancing time

Create a small Unity component:

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);
 }
}

In AppBootstrapper:

timeController.Init(timeModel);

3 — Verification

When the scene starts, the Console should show:

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

The planets should move.

Checklist:

no FindObjectOfType
no GameObject.Find
updates go through OnTimeChanged
the PlanetView references are assigned

(Optional) Orbits

To display an orbit:

add a LineRenderer
calculate several positions
do not recalculate every frame

Principle:

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

Expected result

At the end:

the simulation is driven by TimeModel
the planets correctly follow the simulated time
updates go through the OnTimeChanged event
the architecture remains clear and testable

Your report must also include:

a simple diagram of the TimeModel → Controller → PlanetView flow
a short explanation of how it works
a screenshot of the application

Tag:

v1.2-events

Step 4 — VR interactions: grab / focus / scale

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

Objective

In this step, you will turn your simulation into an object that can be manipulated in VR.

The user must be able to:

move the solar system,
change its scale,
select a planet to obtain information.

The goal is to make these interactions work and integrate them cleanly into the project architecture.

XR interactions should trigger intentions, which are then applied by a clearly defined system (controller / manager), rather than directly manipulating all the objects in the scene.

Recommended flow:

XR Interaction
 ↓
Interaction script
 ↓
Controller
 ↓
Views

1 — Prepare a manipulable tabletop

To make interactions easier, organize the scene around a manipulable root object.

Create a structure similar to:

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

SolarSystemRoot becomes the object you will:

move
rotate
scale

All planets must be children of this object.

Why?

it makes interactions much simpler,
it avoids modifying each planet individually,
it provides a central point for controllers.

2 — Grab interaction

Objective

Allow the user to grab the solar system and move it through space.

Tasks

Create an object to serve as a manipulation handle.

Add an XR interactable that allows the user to:

grab the object with the controller,
move the entire system.

Some necessary components:

collider
rigidbody (often kinematic)
XR interaction component

Expected test:

the user can grab the object,
move it,
release it.

Best practices

do not attach this interaction directly to the planets,
keep a dedicated handle object,
add useful logs:

[XR] Table grabbed
[XR] Table released

3 — Scale control

Objective

Allow the user to zoom in / out on the solar system.

The scale must:

remain within reasonable limits,
be centralized in a single script,
produce useful logs.

Implementation

Create a system responsible for:

receiving a scale value,
clamping it if necessary,
applying the transformation to SolarSystemRoot.

For example, you could create a dedicated component:

ScaleController

This component could expose a method such as:

SetScale(float value)

This component is responsible for actually applying the scale.

User interaction

You are free to choose how to change the scale:

a VR UI slider
a + button
a rotating knob
a two-handed gesture (bonus)

In all cases:

the interaction must not manipulate the transform directly
it calls a controller

Expected logs

Examples:

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

4 — Selecting a planet

Objective

Allow the user to point at a planet with an XR ray and select it.

When a planet is selected:

an event must be triggered,
the system must know which planet is active.

Setup

Each planet must be able to:

be detected by a ray interactor,
signal its selection.

For example, you could create a script such as:

PlanetSelectable

This script can:

reference the PlanetView,
trigger an event or call a central system.

Important: the selection script must not contain all the focus or UI logic.

It only signals that a planet has been selected.

5 — Focus mode

Objective

When a planet is selected:

the planet must be highlighted (for example, centered, enlarged, etc.),
an information panel appears.

Implementation

Create a system responsible for focus.

For example:

FocusController

Possible responsibilities:

move the XR origin or camera,
activate an information panel,
record the active planet.

The panel could display:

planet name
distance from the Sun
orbital period
current simulated time

You can choose the exact content.

6 — Recommended organization

One possible division of responsibilities:

Element	Role
XR Interactable	capture the interaction
Interaction script	translate the user’s action
Controller	apply the logic
View	display the result

Example flow:

Ray Interactor
 ↓
PlanetSelectable
 ↓
PlanetSelectionSystem
 ↓
FocusController
 ↓
UI

7 — Checks

Before moving on to the next step, check:

Grab

the solar system can be moved
movement is stable
logs appear

Scale

the scale can change
limits are respected
transformations remain consistent

Focus

ray selection works
the correct planet is detected
visual feedback appears

Expected result

At the end of this step, the user can:

manipulate the solar system,
change its scale,
select a planet,
see associated information.

The architecture must remain:

readable,
decoupled,
debuggable.

Git tag:

v1.3-vr-interactions

Step 5 — World-space UI + instrumentation (Tag: v1.4) — ~1h00

Objectives

Make the application controllable and debuggable inside the headset.

Tasks

A) World-space UI

Create a VR panel with at least:

Date (or scrubbing)
Play/pause + speed (x1, x10, x100…)
Orbit visibility toggle
Reset viewpoint / reset scale

The UI panel can be an interactive world-space Canvas using the XR Interaction Toolkit.

B) DebugOverlay (required)

Create a discreet overlay displaying:

FPS / frame time (approximate)
Current date + speed
Last user action
Key warnings (scale out of bounds, suspected performance issues, event spam)

The DebugOverlay can be a simple TextMeshPro panel updated periodically.

Unity allows you to capture all logs (Debug.Log, warnings, errors) through:

Application.logMessageReceived

You can use this callback to:

capture important messages
keep recent logs
display them in the overlay

Example

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) Structured logs

All critical events must produce logs in the following format:

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

Expected deliverables

Screenshot showing the UI panel + debug overlay visible in VR
Tag v1.4-ui-debug

Step 6 — Guided XR debugging (Tag: v1.5) — (Optional)

Objectives

Learn a reproducible XR debugging method.

Required work

You must address at least 2 tickets from the following 3 (depending on the starter project provided by the instructor):

Ticket A — Input works in the Editor but not on the headset
Ticket B — Events fire twice after reloading the scene
Ticket C — Inconsistent scale/reference frames: objects appear “far away” or “huge”

For each ticket:

provide a minimal reproduction
describe the method (instrumentation → hypothesis → test → fix)
add a simple regression test (for example, log + guard + assert)

Expected deliverables

“Debug story” section in the README
Tag v1.5-debug-tickets

Step 7 — XR performance (Tag: v2.0) — (Optional)

Objectives

Identify and fix a typical VR performance problem (CPU/GPU/GC).

Tasks

Measure (Profiler):
- CPU main thread
- GC allocations
- scripts running in Update
Choose one bottleneck and improve it:
- orbit caching
- pooling
- reducing update frequency
- eliminating allocations
Demonstrate the improvement:
- before/after profiler screenshots
- describe the change (2–5 lines)

Expected deliverables

“Perf story” section in the README
Tag v2.0-final

Bonus tasks (optional)

Proper planet rotation (axial + orbital)
Skybox / celestial sphere
“Planet surface” mode (viewpoint, constellations)
Teleportation + comfort (snap turn, vignette)
Small in-VR “debug console” with category filters

Assessment criteria (indicative)

Architecture & code quality — 40%
VR interactions — 30%
Observability — 20%

Bonus:

Debugging (tickets + method)
Performance (measurement + improvement)

Quick checklist (before submission)

Public/private repository accessible, tags present
Application works on the headset
World-space UI works
DebugOverlay works
README includes screenshots + diagrams
No FindObjectOfType / GameObject.Find in the final code

Virtual Reality | Étienne Peillard

Lab — 3D interaction: manipulation techniques

The task: a two-coloured tower

1. Explore the project and basic interactions

Open the appropriate version

Try the task

2. Set up technique switching on each controller

3. Change the blocks’ manipulation point

4. Add a virtual ray

Configure distant selection

Compare variants

5. Test Near Far

6. Use both hands

Compare results and write your report

Troubleshooting

Author and original resources

Lab — 3D navigation in virtual reality

Resources and starter project

1. Test basic navigation

Open and run the scene

Interact and measure

2. Configure continuous movement

3. Switch between navigation techniques

4. Add teleportation

5. Add multi-scale navigation

6. Test Grabbing-the-Air

7. Bonus: World-in-Miniature with teleportation

Report and discussion

Troubleshooting and reminders

Lab — First virtual reality application

1. Prepare the project and packages

Create a simple workshop

Install the XR stack

2. Set up the viewpoint and controllers

First test without a headset

3. Run the application on a headset

Standalone Meta Quest: build and install an APK

PC headset: test directly in the editor

4. Move by teleportation

Compare navigation modes

5. Grab and throw cubes

6. Spawn a cube with a controller action

Define the action

Write and connect ObjectSpawn

7. Respond to hovering and selecting an object

8. Check the application and report your results

Further exploration

Troubleshooting

Continue exploring

Reference documentation

Lab — Virtual reality engineering and debugging

Objective

Prerequisites

Skills

Tools

Resources

Engineering rules (required)

Scenario: Solar System VR Workbench

Lab structure

Submission organization (Git)

Tag reminder

Useful concepts for this lab

1 — Business logic

Bad example

Good example

2 — Separation of responsibilities

Simple structure used in this lab

Model (data)

Services

Controllers

Views

Summary

3 — Bootstrapper

The problem

A simple solution

Simple example

4 — Events

Example

5 — Actions

6 — Managing simulation state