Camera rig

Every other sample hands the runtime a display rig: the canvas is a portal onto a virtual display, and the scene is authored to fit it. This one hands over its own camera instead — position, orientation and vertical FOV — and the runtime perturbs that frustum with the viewer's eyes. Drag to orbit; the framing stays yours, the stereo stays the runtime's.

Detecting DisplayXR Browser…

Convergence is the knob that matters

It is the distance where content sits on the glass — nearer pops out, further recedes. Left at the orbit distance the cube straddles the display. Wind it in and the cube leaps forward; wind it out and the whole scene sinks behind the panel. The runtime's comfort rule is ipd × metersToVirtual × diopters × 0.5 ≤ 1; the readout above turns red past it, which is where far content starts asking your eyes to diverge.

C — camera rig ⇄ display rig

The display rig it switches to is built to frame the cube identically at the home angle, so the cut is invisible standing still. Then orbit: the camera rig follows you around the cube, the display rig does not — it is a fixed window onto a fixed scene. That difference is the choice between the two.

attach sends an identity-posed rig and parents the eye cameras under the app camera instead, so three composes this frame's world pose. Toggle it while whipping the orbit around: without it the stereo trails the render by one frame.