Spatial 3D Display App: Technical Explainer

A spatial 3D display app is not the display itself. It is the application-layer software that prepares source content for a glasses-free 3D display pipeline and hands that content to the display hardware in a form it can render. Understanding this distinction is what separates a generic 3D viewer from a deployable spatial review tool.

1. Concept frame: what counts as a spatial 3D display app

In the 3DV architecture, the spatial 3D display system is a stack:

An optical layer — lenticular or parallax barrier — that splits light into directionally separated views.
A display panel that renders multiple interleaved views per frame.
An eye-tracking subsystem that locates the viewer in space.
A display-side FPGA that performs dynamic view mapping and stereo composition.
An application layer — the spatial 3D display app — that produces the right input signal for that stack.

The app is the boundary where a 3D model, a medical volume, or a microscope stream becomes a stereo signal. It decides what counts as a “left eye” view and a “right eye” view, at what resolution, with what depth budget, and at what frame cadence.

2. Application-layer responsibilities in a glasses-free 3D pipeline

The app is responsible for five things the display cannot do for it:

Scene representation. Hold the 3D model, DICOM volume, CT slice stack, CAD assembly, or microscope image stream in a form the renderer can traverse.
Camera pair construction. Generate two virtual cameras with a controlled interaxial distance and convergence angle appropriate to the content. CAD parts need tight convergence; medical volumes often need wider separation.
Frame composition. Deliver the pair to the display in a recognized format — most commonly side-by-side (SBS), with optional half-resolution per eye depending on pipeline.
Timing and cadence. Hold a stable frame rate. Eye tracking expects predictable frame boundaries to recompute view mapping.
2D / 3D mode signaling. Tell the display pipeline whether the next frame is stereo or a flat fallback, so the FPGA can bypass view mapping for 2D content.

If any of these break, the viewer perceives crosstalk, judder, or loss of depth — not because the display is broken, but because the app signal is inconsistent.

3. Stereo source formats and the app’s role in preparing them

A spatial 3D display app does not invent depth. It receives a source that already carries stereo information or a 3D scene that can be rendered as stereo. The app’s job is format normalization.

Common source formats the app must handle:

Side-by-side (SBS) — left and right eye packed horizontally. The most common interchange format.
Over-under (OU) — vertical packing, used by some legacy stereo cameras and rendering pipelines.
Native stereo render — the app itself renders two cameras from a 3D scene, which is the cleanest input for CAD and medical visualization.
Multi-view or light-field capture — higher-end sources where the app must still choose which two views to forward.

For content that arrives as flat 2D — a screenshot, a slide deck, a conventional video — the app has no stereo information to forward. It must signal the display to fall back to 2D mode rather than synthesize depth that does not exist.

4. Eye tracking, view mapping, and the display-side FPGA handoff

3DV’s spatial displays use structured-light eye tracking and a display-side FPGA to remap views as the viewer moves. The app does not perform view mapping. It performs stereo delivery; the FPGA performs directional delivery.

The handoff contract is roughly:

App outputs a correctly composed stereo frame at the panel’s native resolution.
Display-side processor reads the eye position reported by the tracker.
FPGA remaps subpixels to the viewer’s current location using a calibrated lookup.
The optical layer — lenticular or parallax barrier — separates the resulting directional pattern into left and right views.

What this means for app developers: the app should not attempt to compensate for viewer position. Compensation is the display’s job, and double-compensation produces visible artifacts. The app’s discipline is to keep the stereo geometry stable across frames.

5. Workflow implications: CAD, medical, industrial, and microscope review

The value of a spatial 3D display app shows up in workflows where a flat monitor loses information:

CAD and design review. Native stereo render from a 3D scene lets multiple reviewers see assembly depth without head-locked parallax tricks.
Medical visualization. DICOM volume rendering with stereo camera pair gives anatomy education and surgical review a depth cue that 2D slicing cannot.
Industrial inspection and NDT. CT and X-ray volumes benefit from stereo rendering for defect localization in dense assemblies.
Spatial Microscope workflows. Stereo-aware capture or post-processing pipelines feed the same app contract as full 3D scenes, but with calibrated camera geometry.

In all four cases, the architectural shift is the same: the app is the bridge between a 3D-aware source and a glasses-free 3D display that expects a stereo signal. Without that bridge, the workflow collapses to a 2D monitor with no depth.

6. Limits and failure modes of the app layer

Three classes of failure are common when the app is treated as a generic 3D viewer:

Stereo geometry drift. Interaxial distance or convergence angle changes frame-to-frame, producing visible depth instability.
Format mismatch. The app outputs top-bottom or full SBS but the display expects half SBS, or vice versa. The display renders both eyes into one eye, producing a flat image.
Mode switching artifacts. The app toggles between 2D and 3D without signaling the FPGA, causing the display to apply view mapping to frames that are not stereo. Result: visible ghosting during UI overlays.

Current 3DV Spatial Display models are positioned as non-touch. An app that assumes touch input for navigation, annotation, or measurement will mis-target the workflow. Touch-aware UI belongs in adjacent product lines, not the current Spatial Display app contract.

7. Implementation notes for teams building or integrating an app

For teams planning a spatial 3D display app integration:

Treat stereo output as a first-class signal type, not a post-processing filter.
Lock the stereo camera pair at scene load and avoid runtime recalculation unless the scene explicitly demands it.
Respect the panel’s native timing. Buffering or variable refresh logic must not break the eye-tracker’s per-frame contract.
Use the 2D / 3D signaling path for menus, overlays, and any non-stereo UI elements.
Pre-validate source content against the display’s content compatibility expectations before committing to a deployment.

A spatial 3D display app is, in effect, a discipline as much as a piece of software. It enforces the contract that lets a glasses-free 3D display do what a flat monitor cannot: deliver depth, without glasses, in a workflow a professional reviewer can actually use.