Meta Quest 3

Last Updated: 03/10/2025, Connor Flick

Overview

The Meta Quest 3 is a stand-alone, VR-focused HMD successor to the Oculus Quest 2, rebranded to fit with Meta's (previously Facebook's) emphasis on virtual and augmented reality. The device adds additional cameras and sensors on the front to allow a higher-fidelity "passthrough" mode for AR apps,  providing color and improved visual quality alongside improved FOV and processing. This, in turn, allows for the "mixed reality" (MR) experiences Meta boasts, allowing users to quickly switch between VR and AR. Most software for the Quest 3 is able to run on-headset, without being attached to a separate PC. It is the more expensive, higher-quality option compared to the Quest 3S.

How to Run Software on the Quest 3

There are, broadly, four options.

• Publish to Store

  • Become a Meta developer, then submit your app to the Horizon store and receive approval

  • Longest and most complex process, but makes your app easiest to access on the Quest 3

• Sidequest

  • This app lets you sideload apps onto the Quest 3 using .apk files

  • Simple approach once setup, although inital setup is complex and loading multiple apps may result in conflicts

  • Wiki tutorial is here, with potential fixes for issues here

• Streaming/Link

  • App runs locally on a PC, streams to a headset

  • Requires a strong connection (wired or wireless) and a PC capable of running VR software; has the most performance issues

  • Apps like Steam Link or Virtual Desktop may allow this to be more effective wirelessly/remotely

• WebXR

  • Quest 3 broadly supports WebXR experiences in both AR and VR

  • Users may access software from the headset browser, rather than through a local file or app

Accessories

None Required!

Optional:

• Charging Dock ($60) -- Organized station for recharging headset and touch controllers

• Meta Quest Elite Strap ($70 - $130) -- Strap, with or without expansion battery, for improved ergonomics and playtime

• Prescription Lenses ($50) -- Lenses for using Quest without glasses. May be anti-fog or anti-oil

  • Notably, the Quest 3 may be used while wearing glasses or contacts.

• Facial Interfaces ($15 - $70) -- Surrounding covers for lenses for comfort and immersion. May provide increased comfort, ergonomics, or breathability. 

Attributions

Header Image: IHazACatNamedMax / Wikimedia Commons / Source Link

Developing for Quest 3 with Unity (OpenXR), added by Korey Sam, Spring 2026

The recommended development stack for Quest 3 in Unity is Unity 6.x + OpenXR + Meta XR SDK (All-in-One) + MR Utility Kit (MRUK). Meta recommends the Unity OpenXR plugin going forward; the Oculus XR plugin is legacy.

Key development lessons from building a data visualization project on Quest 3:

Passthrough and Mixed Reality Capabilities

The Quest 3 color passthrough camera system enables true mixed reality (MR) development, allowing virtual objects to coexist with the user's real environment. This is a major upgrade from Quest 2's grayscale passthrough. In our stock market visualization project, we used passthrough to anchor a tabletop bar chart to the user's physical desk, creating an MR data analysis experience where the user sees their real room with virtual bars, labels, and UI overlaid on top. The MR Utility Kit (MRUK) provides scene understanding APIs that detect real surfaces (tables, walls, floors). For tabletop MR experiences, passthrough lets users see their physical desk while interacting with virtual data overlays. This grounding in the physical environment significantly improves spatial awareness and comfort compared to fully immersive VR.

TrackingSpace Hierarchy: Objects named OVRRightControllerVisual or OVRControllerPrefab are NOT the transforms receiving live controller tracking. The actual tracked poses are under [BuildingBlock] Camera Rig > TrackingSpace. Use CenterEyeAnchor (headset), LeftHandAnchor (left controller), and RightHandAnchor (right controller) as the source of truth. Parent laser rays to RightHandAnchor, not to visual prefabs. The correct hierarchy is: [BuildingBlock] Camera Rig > TrackingSpace > CenterEyeAnchor (headset pose; use as Event Camera for world-space UI) > LeftHandAnchor (left controller tracked pose) > RightHandAnchor (right controller tracked pose). In our project, the controller ray initially appeared near the player's feet and did not rotate with wrist movement. The fix was parenting the RayOrigin object directly under TrackingSpace > RightHandAnchor.

Quest-Safe Shaders: A mesh or line can exist but be invisible in-headset if it has no valid material or shader. Pink geometry means a missing or incompatible shader. Unlit/Color is a reliable fallback. Always assign materials explicitly. The Standard/Lit shader family used on desktop will not render on Quest's mobile GPU. When porting from desktop to Quest, replace all Standard/Lit materials with Unlit/Color or a custom mobile-friendly shader. Runtime-created primitives (e.g., bars from GameObject.CreatePrimitive) get a default Standard shader material which may not render on Quest. Always assign a Quest-compatible material explicitly in the spawning code.

LineRenderer Configuration: If Use World Space is enabled, the line is pinned to world coordinates and will not move with the controller. Turn Use World  Set the LineRenderer material to Unlit/Color, width to 0.003-0.005, and parent the GameObject to the same RayOrigin under RightHandAnchor. This produces a thin Meta-style laser pointer that follows the controller correctly and should be styled thin and bright, similar to the native Quest system pointer.Space OFF for any laser/ray attached to a controller.

World-Space UI Setup: For controller-driven world-space UI on Quest, set Canvas to World Space with OVRRaycaster, Event Camera to CenterEyeAnchor, and EventSystem to OVRInputModule. Avoid multiple conflicting input modules. A common pitfall: when the Quest slider or button does not respond to the controller ray, the problem is almost never with the UI element itself. It is almost always an EventSystem/raycaster/camera configuration issue. Our project used world-space UI for the time scrubber slider, info panel, and modal legend overlay. All three required proper OVR event wiring to respond to controller interaction.

Runtime-Generated Geometry: Objects spawned dynamically at runtime (e.g., data visualization bars, labels) will not appear in the scene hierarchy before Play mode. Fix orientation and spawning in code. In our project, HistoricalBarSystem.cs dynamically creates 7 bar GameObjects and 7 TextMeshPro labels at runtime. When labels appeared flat (rotated 90 degrees), the fix was changing localRotation in the spawning code, not rotating scene objects. Placement ownership is equally important: if multiple scripts can move your root visualization object, the experience will behave unpredictably. In our project, a stale VizInFrontOfUser.cs script was still active alongside the intended placement system, causing the visualization to fly away at startup. The fix was identifying and disabling the duplicate placement script so only one system owned the root transform.

Meta Quest Developer Hub (MQDH): Device logs through MQDH are useful for catching transform spam, startup issues, and script conflicts. When something flies away or behaves unexpectedly, check  Best practice: always run MQDH logging during Quest testing sessions. Filter by your app's tag to catch initialization errors, null references, and unexpected transform modifications. Save logs for each session to compare behavior across builds. MQDH confirmed which transforms were receiving live controller tracking data vs. which were static, helped identify that OVRControllerPrefab objects were NOT receiving tracking while TrackingSpace > RightHandAnchor was the correct tracked transform, and caught initialization-order errors where scripts tried to access the bar array before HistoricalBarSystem had finished spawning objects.the logs.

Placement Ownership: If multiple scripts can move your root visualization object, the experience will behave unpredictably. Designate one single system to own placement.

Build and Export Workflow: File > Build Settings > ensure scene is in Scenes In Build > set platform to Android > click Build to output an .apk. Test with MQDH, then upload to Google Drive for class distribution.