The gap
The string autofocus does not appear anywhere in this repository — not in Runtime/, not in Editor/, not in docs~/, not in any sample. The feature is not un-visualised; it is absent.
$ grep -rni "autofocus" --include="*.cs" --include="*.md" .
(no matches)
Convergence is authored manually: DisplayXRCamera.invConvergenceDistance on the camera-centric rig, display-plane-relative geometry on the display-centric rig. Both are static once set. A scene whose subject moves in depth — an orbiting model viewer, a character walking toward the viewer, anything with a camera dolly — drifts out of the comfort budget with no correction, and the author's only recourse is to hand-tune convergence for the worst case and accept a flat result everywhere else.
Prior art
The legacy Leia Unity plugin shipped this. In LeiaInc/LeiaUnitySimpleSDK:
Display centric autofocus warning window (#148) — 2024-11-05Fix autofocus sample scene (#145) — 2024-10-25
So there is a reference implementation, a sample scene, and — notably — a warning window, meaning the previous design already understood that autofocus needs to tell the author when it can't do its job. That existing design should be the starting point rather than a fresh derivation.
Proposal
Two parts, and the second is the reason to file this against the editor rather than only the runtime:
1. The behaviour. Track scene content in depth and drive convergence to keep the subject near the display plane, within the comfort budget. Needs a defined subject (explicit target transform, and/or a sampled depth region), a rate limit so convergence doesn't snap, and a defined failure mode when the scene cannot be made comfortable at any convergence — which is what the legacy warning window existed to surface.
2. The gizmo. Autofocus is a control loop, and a control loop the author cannot see is one they cannot debug. The Scene view should show what it is currently locking onto, where it is driving the convergence plane, and when it has given up. DisplayXRGizmoHelpers already draws the convergence plane for both rigs (DisplayXRCamera.cs:270-292, DisplayXRDisplay.cs:287-292) — the autofocus visualisation should ride on that rather than introduce a parallel one.
Relationship to the comfort-bounds gizmo (#315)
Autofocus is what moves content into the comfort budget; the comfort-bounds gizmo is what shows the budget. They're separable — either is useful alone — but they read best together, and both want the same disparity model.
The gap
The string
autofocusdoes not appear anywhere in this repository — not inRuntime/, not inEditor/, not indocs~/, not in any sample. The feature is not un-visualised; it is absent.Convergence is authored manually:
DisplayXRCamera.invConvergenceDistanceon the camera-centric rig, display-plane-relative geometry on the display-centric rig. Both are static once set. A scene whose subject moves in depth — an orbiting model viewer, a character walking toward the viewer, anything with a camera dolly — drifts out of the comfort budget with no correction, and the author's only recourse is to hand-tune convergence for the worst case and accept a flat result everywhere else.Prior art
The legacy Leia Unity plugin shipped this. In
LeiaInc/LeiaUnitySimpleSDK:Display centric autofocus warning window (#148)— 2024-11-05Fix autofocus sample scene (#145)— 2024-10-25So there is a reference implementation, a sample scene, and — notably — a warning window, meaning the previous design already understood that autofocus needs to tell the author when it can't do its job. That existing design should be the starting point rather than a fresh derivation.
Proposal
Two parts, and the second is the reason to file this against the editor rather than only the runtime:
1. The behaviour. Track scene content in depth and drive convergence to keep the subject near the display plane, within the comfort budget. Needs a defined subject (explicit target transform, and/or a sampled depth region), a rate limit so convergence doesn't snap, and a defined failure mode when the scene cannot be made comfortable at any convergence — which is what the legacy warning window existed to surface.
2. The gizmo. Autofocus is a control loop, and a control loop the author cannot see is one they cannot debug. The Scene view should show what it is currently locking onto, where it is driving the convergence plane, and when it has given up.
DisplayXRGizmoHelpersalready draws the convergence plane for both rigs (DisplayXRCamera.cs:270-292,DisplayXRDisplay.cs:287-292) — the autofocus visualisation should ride on that rather than introduce a parallel one.Relationship to the comfort-bounds gizmo (#315)
Autofocus is what moves content into the comfort budget; the comfort-bounds gizmo is what shows the budget. They're separable — either is useful alone — but they read best together, and both want the same disparity model.