Concept frame: what spatial 3D display software actually controls

In a glasses-free 3D review workflow, the display panel is only one half of the system. The other half is the software pipeline that prepares and delivers the stereo signal. On a 3DV Spatial Display, the panel uses eye-tracked autostereoscopic architecture with a microlens or lenticular optical layer, structured-light eye tracking, and display-side FPGA processing. None of that depth delivery works unless the upstream software can hand the panel correctly formatted left-eye and right-eye views.

So when buyers ask about “spatial 3D display software,” the honest scope is wider than a single application:

• Source-side applications that can output stereo or 3D-ready views, such as CAD viewers, DICOM stacks, CT and NDT viewers, Unity and Unreal scenes, and WebGL viewers.
• Output and packaging formats that carry stereo intent, primarily side-by-side (SBS) and similar interleaved layouts, with proper half-resolution or full-resolution per eye depending on the encoder.
• Runtime viewers and players that can route those streams to the display, including utilities such as the 3DV Spatial Player and the Spatial Display Simulator.
• Source-side pipelines that still need preparation, including ordinary 2D video, flat images, and applications that only output a single 2D view.

Software, in this context, is not a product the buyer installs and forgets. It is a compatibility decision that has to be made per content source.

Architecture notes: where software sits between source content and glasses-free delivery

The Spatial Display hardware assumes a known input contract: a stereo-ready stream plus viewer eye position. The software stack has to satisfy that contract. In practice, four layers matter.

1. Source authoring or capture. CAD packages, medical viewers, 3D engines, and stereo cameras produce raw geometry or imagery. The question at this layer is whether the tool exposes a stereo camera, an SBS export, or a WebGL/Unity/Unreal target that can be addressed in stereo.
2. Encoding and packaging. Stereo or 3D-ready content is rendered into a layout the display can interpret, most commonly SBS, with left and right views laid out at known pixel offsets. Stereo separation, alignment, and color budget are decided here.
3. Playback or delivery. A runtime player, web viewer, or engine instance feeds the encoded stream to the panel. On Spatial Display, this is also where dynamic stereo view mapping reacts to eye tracking.
4. Display-side processing. The display FPGA handles mapping, crosstalk compensation, and 2D / 3D mode switching on Pro models. Software upstream cannot fix what this layer rejects.

The practical implication is that a working spatial 3D workflow is a chain, and the software choice at any link can break the chain. Reviewers should evaluate each link against the display’s input contract rather than asking whether “the software” is supported.

Content readiness categories: best-fit, prep-required, and unsupported paths

Mapping source content into three buckets helps teams assign software effort realistically. These buckets are consistent with the Spatial Display content compatibility framework.

Best-fit content

• SBS stereo video with correct per-eye resolution.
• CAD and 3D model viewers with explicit stereo output or camera pairs.
• Medical and industrial 3D exports, including DICOM stacks, CT volumes, and segmentation overlays rendered with stereo cameras.
• Custom 3D applications built in Unity, Unreal, or WebGL that target the Spatial Display pipeline.

Prep-required content

• Ordinary 2D video that needs to be reauthored as SBS or upconverted with depth estimation.
• Flat images and screenshots that lack any stereo signal.
• Software that only outputs a single 2D view, which has to be paired with a second view or replaced with a stereo-capable viewer.

Unsupported paths

• Headset-bound VR pipelines that cannot be redirected to a monitor-class glasses-free panel.
• Streams that are encrypted, DRM-locked, or otherwise blocked from re-encoding.
• Source content whose licensing model forbids stereo reformatting.

Teams that classify assets into these buckets before deployment save a great deal of rework. The Spatial Display Compatibility Checker is the fastest way to score a source against this matrix.

Workflow implications: a reference pipeline from source asset to on-screen depth

The following reference workflow assumes a professional review team that wants predictable depth on every meeting, not a one-off demo.

1. Intake and classify the asset. Decide whether the asset is best-fit, prep-required, or unsupported using the readiness categories above.
2. Choose a stereo path. For authored 3D, prefer a native stereo camera or SBS export from the source tool. For 2D material, plan depth synthesis or stereo reauthoring before reaching the display.
3. Validate on a simulator first. Use the Spatial Display Simulator or the 3DV Spatial Player to confirm that the encoded stream resolves into clean left and right views before connecting a physical display.
4. Connect and seat the viewer. Once on a Spatial Display, structured-light eye tracking picks up the viewer, and dynamic stereo view mapping follows their position. The viewer should sit within the documented head box for the chosen model.
5. Switch modes intentionally on Pro models. Pro displays support 2D and 3D switching. Use 3D for depth-critical moments and 2D for dense reading tasks where stereo separation would interfere.
6. Capture and version the pipeline. Record the source tool, export settings, encoder layout, and player version. Stereo workflows are sensitive to small changes, and a versioned pipeline makes troubleshooting tractable.

For teams that need help choosing a model for this pipeline, the Display Selector and the Spatial Display product page provide the relevant model fit and architecture context.

Limits and failure modes: where software choices break stereo delivery

Spatial 3D display software has honest limits that reviewers should plan around.

• Single-viewer assumptions. Spatial Display delivers depth for one tracked viewer. Multi-viewer audiences see a degraded or 2D-ish image. Software that assumes a shared flat view will look wrong even when every other setting is correct.
• Crosstalk and stereo budget. Left and right views are not perfectly isolated. High-contrast text and very thin geometry stress the crosstalk budget. Software that renders extreme contrast or very fine linework amplifies the problem.
• 2D-only tools. Applications that cannot output a second view, or whose licensing forbids re-encoding, will not reach the panel as stereo regardless of player capability.
• Resolution mismatches. SBS that halves per-eye resolution below the panel’s usable budget produces soft depth. Encoding settings should be checked per asset.
• Display side matters. Current Spatial Display positioning is non-touch. Software that assumes a touch surface will leave inputs unmapped.

These failure modes are usually diagnosable by stepping back through the pipeline. The compatibility framework in the prior section is the fastest triage path.

Implementation notes: pre-deployment checks and support routes

Before any Spatial Display goes live, three checks reduce surprises:

1. Source audit. List every content type the team intends to review. Score each against the readiness categories and flag any “prep-required” asset that lacks a stereo plan.
2. Pipeline pilot. Run one representative asset end to end on the simulator, then on the actual display, and confirm both visual quality and the per-eye resolution budget.
3. Support routing. Direct compatibility questions into a structured support path rather than ad hoc email. The Ask Before Ordering route handles pre-purchase alignment, while compatibility questions on live installations belong with engineering support.

Spatial 3D display software is ultimately an architectural decision, not a checkbox. Teams that treat it as a layered compatibility problem and route each layer against the display’s input contract get predictable depth; teams that treat it as a single “supported app” question spend more time reworking pipelines.