How SBS (Side-by-Side) Produces a Glasses-Free 3D Image

What SBS is, in one paragraph

SBS (side-by-side) is the simplest possible 3D input format: a single rectangular frame in which the left-eye view occupies the left half and the right-eye view occupies the right half. On a 4K panel that means a 3840 x 2160 image with two 1920 x 2160 views packed side by side. The format itself has no interleaving, no metadata, no time-multiplexing, and no per-view z-depth. It is literally two pictures drawn next to each other.

That simplicity is exactly why SBS has become the universal input format for glasses-free 3D displays. It is also why it is misunderstood — the format is small; the stereoscopic pipeline that has to follow it is not.

Why every glasses-free 3D display accepts SBS

Three properties make SBS the lingua franca of glasses-free 3D.

1. It is just a video frame. Every operating system, media player, game engine, and rendering pipeline already knows how to output a 2D video frame at 3840 x 2160. SBS requires no new host infrastructure.
2. It is transport-neutral. SBS travels over HDMI, DisplayPort, and USB-C as a standard 2D video stream. The display, the cable, the GPU, and the OS all treat it as a flat picture. No 3D-specific signaling is required.
3. It is content-neutral. Game engines, 3D modeling tools, medical imaging viewers, scientific visualization packages, and pre-rendered 3D video all know how to render two camera views into the left and right halves of an SBS frame.

Every major glasses-free 3D vendor supports SBS for this reason: it is the only 3D format that requires nothing from the host beyond “render an image at this resolution.”

What SBS is at the pixel level

An SBS frame is a wider-than-tall picture. The two views are not duplicates — they are the same scene rendered or photographed from two horizontally offset camera positions, separated by roughly the average inter-pupillary distance of a human viewer (about 63 mm). When the brain receives those two views — one per eye — it fuses them into a single 3D percept. This is the same binocular disparity trick that has driven stereoscopic 3D since the 19th century.

Two SBS variants appear in the wild:

• Full-resolution SBS. Each eye gets the full vertical resolution of the frame. On a 4K panel, each eye sees a 1920 x 2160 view. This is what glasses-free 3D displays expect.
• Half-resolution SBS. Each eye is also squeezed horizontally to 960 x 1080 on a 4K frame, then placed into a 1920 x 1080 half. This is more common in VR video pipelines where the source is already at lower per-eye resolution, and it is not what glasses-free 3D displays want.

From SBS frame to 3D image — what has to happen

SBS is a storage format, not a display format. A lenticular lens on the front of the panel does not know what SBS is. It knows how to take a sub-pixel pattern on the panel and refract it into a set of angular windows, one window per viewing direction. The work between the SBS frame and that sub-pixel pattern is the real stereoscopic pipeline.

To turn an SBS frame into a usable 3D image, the display has to:

1. Unpack the SBS frame into two separate left-eye and right-eye images.
2. Estimate where the viewer is, in particular the positions of the left eye and right eye relative to the panel.
3. Compute, for each pixel in the panel, which viewer’s eye it should be routed to. This is the stereoscopic pixel routing step, and it depends on the eye positions and on the lens geometry.
4. Rearrange the panel’s sub-pixels so that the left-eye pixels are aimed at the left-eye angular window of the lens, and the right-eye pixels at the right-eye window.
5. Refetch, recompute, and re-route at panel-refresh cadence so the 3D image follows the viewer in real time.
6. Repeat all of the above for every frame, at low latency, without dropping frames.

Step 3 is the non-obvious one. The mapping from eye position to sub-pixel address is not a fixed table — it changes every frame. Step 4 is also non-obvious: the lens is a static grating, but the sub-pixel pattern underneath it has to be dynamically arranged so that the combination of pattern plus grating produces a stable left/right image at the viewer’s eyes.

Where the stereoscopic pipeline runs

The SBS frame arrives at the display as a flat 2D picture. Everything from step 1 to step 6 above has to happen somewhere. There are two realistic places it can run:

• On the host computer, using the host CPU, GPU, camera pipeline, and OS drivers.
• Inside the display, on an integrated real-time processor (typically an FPGA or a dedicated ASIC) sitting between the panel’s input and the panel itself.

Software-driven lenticular displays (Sony ELF-SR2, Samsung Odyssey 3D G90XF, Acer SpatialLabs View Pro 27, Lenovo ThinkVision 27 3D) put the stereoscopic pipeline on the host. The display itself is essentially a 4K panel with a bonded lenticular lens and a camera. The host does the unpacking, the eye tracking, the pixel routing, and the sub-pixel rearrangement, and then ships the rearranged image to the panel over a non-standard “3D-mode” video signal.

3DV Spatial Displays put the stereoscopic pipeline on an integrated FPGA inside the display. The host’s job stops at “render the SBS frame.” Everything after that happens on the FPGA, in the panel’s clock domain, with no round-trip through the host.

What goes wrong when the host does the pipeline

Eye-tracking latency

The eye tracker has to know where the viewer’s eyes are at the moment the panel is being refreshed, not the moment the host camera captured the frame. In a software-driven lenticular display, the camera image goes through USB into the host, into a vendor service, through a pose-estimation pipeline, and back out through the GPU’s rendering path. The total round-trip latency is typically tens of milliseconds. By the time the new sub-pixel pattern arrives at the panel, the viewer has already moved. The 3D image lags the head.

Stereoscopic alignment drift

Crosstalk is determined by how precisely the sub-pixel pattern is aligned to the lens’s expected layout. If the host GPU is under load, if a background process interrupts the stereoscopic renderer, or if the panel’s vertical refresh drifts relative to the host’s render submission, the alignment drifts and crosstalk rises.

OS and GPU lock-in

Because the host has to run the eye tracker, the stereoscopic renderer, and the sub-pixel rearranger, it has to do so through real-time APIs that are stable on a specific operating system and a specific GPU vendor stack. In practice this means DirectX on Windows with a certified NVIDIA GPU. There is no equivalent real-time path on macOS, and no equivalent on Linux.

Host power and heat

Running a 60 Hz stereoscopic renderer, a real-time eye tracker, and a sub-pixel rearranger is a real GPU and CPU load. The host workstation has to be specified for it. The display side of the power budget is dominated by the host, not by the panel.

What changes when the FPGA does the pipeline

In a 3DV display, the host’s only job is to render an SBS frame at 3840 x 2160 and ship it over HDMI, DisplayPort, or USB-C. The integrated FPGA inside the display then:

• unpacks the SBS frame into left-eye and right-eye buffers,
• runs the on-device structured-light eye tracker at 180 Hz (sample period about 5.6 ms),
• computes the stereoscopic pixel routing in hardware, in the panel’s clock domain,
• drives the panel with the rearranged sub-pixel pattern,
• repeats all of the above at panel-refresh cadence with no round-trip through the host.

At the user level, the visible difference is concrete:

1. The 3D image is stable when the viewer moves.
2. The sweet spot is wider.
3. The OS stops mattering — see why most glasses-free 3D displays cannot work on a Mac.
4. The host GPU requirement drops — see why a glasses-free 3D display doesn’t need a high-end GPU.
5. The display’s power budget is predictable at no more than 48 W.

SBS as a contract between the host and the display

The cleanest way to think about SBS in the 3DV architecture is as a contract. The host agrees to deliver an SBS frame at the panel’s native resolution, with the left-eye view on the left and the right-eye view on the right. The display agrees to do everything that has to happen after that — eye tracking, stereoscopic routing, sub-pixel rearrangement, real-time refresh — on its own hardware, with no further host involvement.

This contract is what lets a 3DV display run on a MacBook, a Linux workstation, an embedded ARM board, or any other device that can output a flat 3840 x 2160 video stream. The OS does not need to know that 3D is happening. The GPU does not need a special driver. The application does not need a vendor plugin.

How a content author produces SBS

Producing an SBS source for a 3DV display is a standard stereoscopic rendering task. The host application renders the same scene twice, from two horizontally offset camera positions, and writes the left-eye render into the left 1920 x 2160 half of the output frame and the right-eye render into the right half. The horizontal offset between the two virtual cameras is typically set to the average inter-pupillary distance (63 mm) and can be tuned for comfort.

For pre-recorded content, the same procedure is done offline: render the scene twice from the offset cameras, encode the two views as the left and right halves of a video frame, and ship the resulting SBS video to the display. There is no per-display authoring step.

What SBS does not solve

SBS is a clean input format, but it is not a complete 3D pipeline. It does not, by itself, do any of the following:

• Track the viewer. Eye tracking is its own pipeline, with its own hardware and its own latency budget.
• Route pixels through the lens. The sub-pixel rearrangement that maps an SBS frame onto a lenticular lens’s expected pattern is its own computation.
• Handle head movement. A static SBS frame viewed through a static lenticular lens only produces 3D for a fixed viewer position.
• Reduce crosstalk. Crosstalk is determined by the precision of the sub-pixel alignment, which is a property of the routing pipeline, not of the SBS frame.
• Decide which OS the user has to run. The OS question is decided by where the routing pipeline runs, not by the format of the input frame.

Common questions

Is SBS the same as HDMI 3D?
No. HDMI 3D is a signaling mode that carries frame-packing metadata. SBS is just a video frame layout. A 3DV display reads SBS as a normal 2D frame.

Does every glasses-free 3D display accept SBS?
Yes — including software-driven products like Sony ELF-SR2 and Samsung Odyssey 3D. They differ in what they do with the SBS frame after receiving it.

What about half-resolution SBS?
Some VR pipelines produce half-resolution SBS to save bandwidth. A glasses-free 3D display expects full-resolution SBS at its native panel resolution. Half-resolution SBS will look soft and is not recommended.

Can I author SBS in Blender, Maya, or Unity?
Yes. All three can render two virtual cameras with horizontal offset and combine the output into a single SBS frame. The procedure is standard for any stereoscopic 3D pipeline.

Where to read next

• How spatial monitors work — the broader pipeline that SBS feeds into.
• Lenticular lens vs. integrated FPGA — what happens to the SBS pipeline depending on where it runs.
• Vergence–accommodation conflict — how the pipeline’s tightness affects long-session comfort.
• What is spatial display — the category overview.