VR I: deploying to headsets Project 3 launch

2:00 · Brief The frame budget is the design brief

On a monitor, a dropped frame is a hiccup. In a headset it's a lurch in your inner ear — miss frames in VR and you make people physically ill. That's why everything this week starts with arithmetic: 90 Hz means the entire world in about 11 milliseconds; 72 Hz gives you roughly 13.9. Every artistic choice you make from now on is spending that budget.

One API, two very different machines

We target both course headsets through OpenXR, the Khronos standard runtime API — write once against OpenXR and Quest, Vive, and most of the industry can run it. But the hardware underneath is not equivalent:

• Meta Quest — a standalone Android device with a mobile GPU. Your build is packaged like an Android app, and the mobile renderer's rules apply: aggressive polygon and shader budgets, careful light counts. This is real optimization discipline, and it's why Quest is the primary Project 3 target.
• HTC Vive — a display tethered to a PC that does the rendering. Big GPU, wider budgets, but a cable and a SteamVR runtime between you and the player.

The honest mental model: shipping to Quest is shipping to a phone strapped to a face. Megalights demos on the projector do not survive contact with a mobile GPU — the two rendering worlds have different physics, and Project 3 lives in the stricter one.

Comfort: what makes people sick

Simulator sickness comes mostly from vection — your eyes reporting motion your inner ear doesn't feel. The known mitigations are now standard practice: teleport locomotion as the safe default, snap turns over smooth turns, vignettes during any smooth movement, and never, ever taking the camera away from the player. Smooth locomotion is a legitimate artistic choice — but it's a choice you make deliberately, with comfort options, not a default you inherit.

2:45 · Guided lab From viewport to headset

Everyone stands inside their own level today. We go PC-VR first (fast iteration), then package to Quest (the real deployment). Start the Quest packaging early — first Android builds are slow.

1. Start from the VR Template — then loot it

   Create a new project from the VR Template (Games category) and play it in a headset first: it ships with OpenXR configured, a working VR pawn, and teleport locomotion. This is your reference implementation — study it, then migrate its VR pawn into a copy of your own project rather than rebuilding from zero.

2. Check the plugin stack

   In your project: Edit > Plugins, confirm OpenXR is enabled (the template enables it; a from-scratch project won't). Add the Meta/Quest support plugin if prompted for Android deployment. While you're there, verify Unreal MCP is still enabled for the 4:00 block.

3. VR-critical project settings

   In Project Settings, work through the VR checklist: enable Start in VR, and for the Quest target follow Epic's current mobile-VR recommendations (forward shading path, MSAA anti-aliasing, instanced stereo). Menu names shift between point releases — search the settings window rather than memorizing paths, and cross-check against the VR Template's config.

4. First contact: VR Preview on Vive

   With SteamVR (or your PC OpenXR runtime) running and the Vive connected, use the Play button's dropdown → VR Preview. Stand in your level. First homework of the body: check your door heights and ceiling — 1:1 scale errors that hid on the monitor are suddenly obvious.

5. Read the frame

   In the console: stat fps, then stat unit — Game, Draw, GPU times against your budget — then stat gpu to see where GPU time actually goes. Write down your three biggest costs; you'll compare them against the agent's claims at 4:00.

6. Prepare the Quest

   Quest deployment needs the Android toolchain (UE's setup docs walk through the exact SDK/NDK versions — follow them, don't improvise) and a headset in Developer Mode paired to your Meta account. Connect over USB-C, allow the debugging prompt in the headset, and confirm the device appears with adb devices.

7. Package and deploy

   Set the Android packaging format for Quest per Epic's Quest documentation (ASTC texture compression), then package or use Quick Launch onto the device. The first build is long — shaders and the Android toolchain — so let it run through the break. Launch from the headset's app library (unknown sources).

8. Profile on the device

   Frame times on your PC are fiction for Quest — profile on the hardware. Use stat unit in the on-device build and note how much of your PC performance survived. That gap is your optimization to-do list, and Project 3's performance budget is graded on-device.

4:00 · AI lab The agent as performance consultant

Performance is where agent overconfidence gets expensive: plausible-sounding optimization advice is cheap to generate and costly to follow. Today the agent proposes, the profiler disposes. You already measured your scene at step 5 — now see if the agent finds the same truth.

5:15 · Crit / share Headsets on, then declarations

Musical headsets: two minutes in a neighbor's space, one comfort note and one scale note for the author. Then Project 3 launches formally — each person states their declared track (interactive VR piece with three authored interactions, or the LED-wall VP collaboration) and one sentence of concept. Your interaction design spec is due before implementation begins; that's this week's homework.

Homework — due before Week 11

Resources

• Meta Quest developer documentation — Unreal setup, packaging, performance budgets, and the comfort guidelines every store submission is reviewed against.
• OpenXR (Khronos) — the standard underneath everything we deploy this phase.
• Epic Developer Community — Learning — search the XR development courses for current UE 5.8 VR setup walkthroughs.
• Counterpoint XR tracker — the market data behind Quest-first.
• 2026 headset preview — the hardware wave arriving while you build Project 3.