Stereoscopic XR Rendering: Preserve Per-View Poses, Projections and Image Layers

この記事はまだ日本語では提供されていません。原文を表示しています。

article · en · 知識の基準日 2026-10-11 · 変更日 2026-10-11, リビジョン 1 · unreviewed

Render consistent stereo views using runtime view data and validate multiview optimizations without losing eye-specific geometry or effects.

Obtain a pose and projection for every view

Stereoscopic rendering requires views from distinct eye positions. Copying a single camera image into both eyes does not produce the correct geometric disparity. OpenXR returns view information for a requested display time, and applications must use the view count belonging to the selected configuration. The returned data can change between calls. [1]

Each view contains a pose and field-of-view angles for the projection's sides. [2] Build matrices consistently from those values and the selected reference space. Do not replace them with a hardcoded eye separation or assume the projection must be symmetric.

Multiview lets one recorded command sequence serve multiple views. A view index selects the appropriate per-view behavior; Vulkan exposes this through ViewIndex. The implementation determines how to execute the views efficiently. [3]

Keep pose, projection, render-target layer and view-dependent shader inputs connected to the same index. Geometry and material data may be shared, but a world-space point generally projects to different pixels in each eye. A reflection vector, billboard orientation or screen-space lookup that accidentally uses the other eye can remain visibly wrong despite correct basic geometry.

Worked example: count the actual image workload

Suppose an illustrative stereo configuration renders 2 views, each with an image extent of 1440 by 1600 pixels. The combined image area is 2 * 1440 * 1600 = 4608000 pixels. One view alone contains 2304000 pixels.

Recording the scene once through multiview does not turn the combined output into a single-view image area. This calculation excludes overdraw, multisampling and any resolution variation; it is not a measured shading cost. Use it to check whether a performance estimate mistakenly counted only one eye. Conversely, do not assume every geometry or CPU cost doubles: sharing opportunities depend on the rendering path and implementation.

Validate the two images before optimizing

Begin with a room containing near and far markers and an object crossing the center of view. Display each eye image separately and verify labels, layer routing, projection and depth. Then inspect the stereo result while translating and rotating the tracked view. Use view data for the intended display time and check its validity. [1]

Test culling at both eyes' outer edges. A shared visibility decision must include geometry visible to either eye, or use independent decisions. Validate particles, text, reflections and post effects with the same care as opaque meshes. Give temporal resources a consistent per-view identity so image histories cannot be exchanged accidentally.

Evaluate the complete stereo path

Check asymmetric fields of view, changes of reference space and the view configurations the application actually supports. A mono desktop preview cannot establish stereo correctness. Measure submission, geometry, image processing and final view handling together. Multiview is a tool for reducing duplicate work, while the visual contract remains a correctly projected and consistently timed image for every required view.

Sources

[1] xrLocateViews — Khronos Group, OpenXR specification.
[2] XrView — Khronos Group, OpenXR specification.
[3] VK_KHR_multiview — Khronos Group, Vulkan specification.

範囲と根拠

Source-based synthesis; original illustrative examples; no experiment or benchmark claimed.

知識の基準日：2026-10-11。状態：unreviewed（レビュー記録なし） — 編集するとレビュー状態はリセットされます。本文は未検証の参考情報として扱い、出典を確認してください。

出典

帰属とライセンス

オリジナルの投稿： CC BY 4.0. リンク先の出典はそれぞれの権利を保持します。