A team must decide whether a shared workspace should consume the whole immersive session or live inside a runtime-positioned bounded volume beside other applications. If that choice remains implicit, the first prototype can encode the wrong ownership model into rendering, input, persistence, and exit behavior.
Khronos lists XR_EXT_spatial_container, XR_EXT_spatial_container_self_rendering, and XR_EXT_spatial_image_tracking among the new ratified multi-vendor extensions in the OpenXR SDK 1.1.63 release. Ratification creates a shared contract, while each runtime still decides support and system behavior.
Test OpenXR 1.1.63 spatial containers as three decisions
The base spatial-container extension covers bounded spatial content whose placement is coordinated by the system. The self-rendering companion covers a branch where the application supplies rendering under that container contract.
Spatial image tracking is a different capability. It turns a known image into tracked spatial evidence; it should not be hidden inside the container abstraction merely because both affect where content appears.
Constraint to consequence
- Runtime owns placement: avoid assuming a fixed world origin or permanent full-screen control.
- Capability is optional: preserve an ordinary immersive or nonspatial fallback.
- Several apps may coexist: bound input, audio, visibility, and persistence to the container lifecycle.
- Tracking can be lost: expose acquisition and recovery rather than freezing the last pose.
Query support before constructing the scene
Enumerate the required extensions and treat each result as a capability, not a product tier. A runtime may expose the base container without self-rendering or image tracking.
Choose the fallback before allocation. The app can remain fully immersive, use a conventional panel, disable the spatial feature, or offer a different tracked anchor, but it should not fail halfway through scene creation.
Make the container lifecycle visible
Record creation, readiness, placement changes, visibility, focus, interaction, exit, and destruction. Give every container a product-level owner so a suspended activity cannot leave audio, input, or resources alive.
The OpenXR 1.1.63 specification is the contract for structures and result codes. Generated headers prove compilation; a runtime trace proves that the implemented lifecycle matches the target system.
Respect system placement and coexistence
Do not snap a runtime-positioned container back to an application-defined world origin. Observe the pose supplied by the system and design content to tolerate movement, resizing, occlusion, and neighbouring application space.
Test what happens when focus moves elsewhere. Pause expensive work, quiet audio, release exclusive input, and preserve only the state needed for a correct return.
Use self-rendering as an explicit branch
Keep shared application state above the renderer so the same task can survive a self-rendered container, another presentation path, or a fallback. Do not fork business state by rendering mode.
Measure frame timing, resolution, visibility, and resource lifetime inside the branch. A container that looks correct in isolation can still overrun the budget when another application remains active.
Test image tracking as acquisition and loss
Record acquisition time, pose stability, tracking loss, reacquisition, and destruction while the target moves through ordinary distance, angle, occlusion, and light changes. Never let the last known pose masquerade as current tracking.
Keep the image target’s physical dimensions, printed contrast, and revision in the fixture record. A tracking regression is difficult to reproduce when the target itself changes between runs.
Update the loader and validation lane together
The matching OpenXR documentation release travels with the registry change. The SDK release includes loader cleanup, list_json improvements, an Android loader artifact, and Android debug API layers for API dump, core validation, and best-practices validation.
Do not ship debug validation layers as production dependencies. Preserve their reports with the build identity, runtime version, device firmware, and exact extension list.
Build a six-step acceptance walk
Start with support enumeration, create the bounded container, accept runtime placement, interact inside it, move focus to another app, and destroy the container. Repeat after suspend and resume.
Add an image target only after the container path is stable. Then cover target absent, partially occluded, reacquired, replaced, and removed while the container changes focus.
Keep terminology tied to the user-visible mode
OpenXR is the technology contract inside this topic; the Neyrotex section remains Virtual Reality. Describe whether the user enters an immersive scene, a bounded spatial workspace, or a tracked-object task instead of using one umbrella term for all three.
Release only when the fallback returns the user to a usable mode and cleanup leaves no stale object, sound, focus, or tracking handle behind.
Write the tracked-image contract before adding content
A tracked image needs an identifier, physical size, revision, allowed environment, acquisition timeout, confidence behavior, loss state, and cleanup owner. The article uses the phrase tracked image deliberately: it describes runtime evidence, not a permanent anchor.
Pair the trace with a recording of the target and room so a pose jump can be separated from a changed print, glare, occlusion, or calibration fixture. Keep raw camera data only when the product and privacy policy require it.
Keep a release evidence record
Save the source versions, selected capability, test fixture, expected result, observed result, failure path, owner, and review date together. Recheck the decision when the platform contract, dependency, device class, model snapshot, or business consequence changes; a green launch artifact is evidence for one bounded state, not a permanent guarantee.
Continue with the Virtual Reality hub, then use our first related guide and second related guide to connect this decision to the surrounding platform work. The next-action guide carries the resulting evidence into the following release decision.
