Quest’s passthrough mode has always let your app blend a virtual scene with the real world the headset’s cameras see — but until the Passthrough Camera API, that real-world view was something your app could only display, not actually read. This tutorial covers the difference, and how to pull real camera frames into your own code.
Passthrough rendering vs. passthrough as data
Standard passthrough, the kind every mixed-reality Quest app already uses, is a rendering feature: the system composites the headset’s camera view with your virtual content and displays the result, but your application code never touches the raw image. The Passthrough Camera API is a different thing entirely — it exposes the actual camera frames as data your app can read, process, and feed into whatever you want: a computer-vision model, a QR/barcode scanner, a color picker, or a custom recording pipeline. Think of it as the difference between watching through a window and being handed the photograph.
Turning it on
In Unity, camera access is enabled on the Camera Rig, not configured per-script. On your OVRCameraRig (or equivalent rig object), enable OVR Manager → Enabled Passthrough Camera Access, then add a PassthroughCameraAccess component — part of Meta’s Mixed Reality Utility Kit (MRUK) — to a GameObject in your scene. The API depends on your application already running with passthrough enabled; it’s an extension of passthrough, not a standalone capability.
One version note worth knowing before you start: Camera2 support (and its Unity extension) requires Horizon OS v74 or later, and a newer 1280×1280 resolution option became available starting with HzOS v83, alongside the original 1280×960. Meta’s own guidance is not to hardcode a resolution — request WebCamTexture with no explicit width/height (or both set to 0) and it automatically selects the highest resolution the running headset supports.
// Request the highest available resolution rather than hardcoding one
WebCamTexture passthroughCamera = new WebCamTexture();
passthroughCamera.Play();
What you can build once you’re reading real frames
Meta’s own sample project, Unity-PassthroughCameraApiSamples, ships five examples that sketch the range here: a basic CameraViewer that just displays the raw feed, and MultiObjectDetection, which feeds camera data into Unity Sentis for on-device object recognition. That second example is the more interesting direction for most creative-technology work — once your app can see what the headset’s cameras see, you can run your own detection, tracking, or classification model against the physical room the user is standing in, rather than relying only on what Quest’s built-in scene understanding already surfaces.
Two things to know before you build
The Passthrough Camera API is not supported in the XR Simulator — you’ll need a physical headset to test against, which is a real workflow cost compared to iterating in-editor. And because the API hands you actual camera image data, Meta classifies it as Device User Data under its Developer Data Use Policy — worth reading closely before you build anything that stores or transmits frames, since the privacy obligations here are stricter than for synthetic tracking data like hand joints or controller poses.