We need a developer story for eye-tracked lenticular displays (Acer SpatialLabs, Samsung Odyssey 3D). The stereo-viewer competitive analysis found no desktop photo viewer driving these natively — the niche is open.
What we already know (2026-10-03 research):
- Both displays sit on the shared LeiaSR "Simulated Reality" platform (Immersity SDK, public). effcol/SR-Loom (MIT) is a working reference implementation: the recipe is to feed the weaver a full side-by-side texture and it produces the lenticular, eye-tracked output (
CreateDX11Weaver, SR::EyeTracker::create()).
- Acer SpatialLabs Pro additionally ships a certified OpenXR runtime, so a pyopenxr-based presentation path needs zero vendor-specific integration — and the same code path covers VR HMDs.
- The lazy path already exists: Rendepth (free/open viewer) outputs SBS fullscreen and lets the vendor hub (Reality Hub / SpatialLabs Go) do the weaving. Shallow but shippable; the deep integration is still unclaimed.
- A 3D Slicer → SR Loom bridge exists for medical scans, so the scientific-visualization use case is real, not hypothetical.
- Hardware-gated for now: the Acer panel is ~$2000 and out of stock; no SR display on hand. Software/research spike only until hardware happens.
Principles: our pass-per-eye architecture already generalizes to pass-per-view (N views); the weaver is just the multiplexer in that picture — eye separation stays ours.
This issue does not need to solve it today. It needs: (1) a read-through of the SR-Loom source for the exact weaver/eye-tracker API surface, (2) a spike deciding between the LeiaSR-native path and the OpenXR path for first integration, (3) a note on what "weave from our per-eye framebuffers" concretely requires.
We need a developer story for eye-tracked lenticular displays (Acer SpatialLabs, Samsung Odyssey 3D). The stereo-viewer competitive analysis found no desktop photo viewer driving these natively — the niche is open.
What we already know (2026-10-03 research):
CreateDX11Weaver,SR::EyeTracker::create()).Principles: our pass-per-eye architecture already generalizes to pass-per-view (N views); the weaver is just the multiplexer in that picture — eye separation stays ours.
This issue does not need to solve it today. It needs: (1) a read-through of the SR-Loom source for the exact weaver/eye-tracker API surface, (2) a spike deciding between the LeiaSR-native path and the OpenXR path for first integration, (3) a note on what "weave from our per-eye framebuffers" concretely requires.