Proposal: DisplayXR for Twinmotion (architectural visualization, Leia SR tested)

[joehillthunder]

Twinmotion (tested: 2026.2 Preview, Unreal Engine 5.7.4, Windows 11, D3D12) shows glasses-free 3D on DisplayXR through its own OpenXR mode. It's a closed Unreal build with no plug-ins and no scripting, so everything sits outside the app:

• a launcher that selects DisplayXR per process (XR_RUNTIME_JSON);
• a thin adapter that turns display info into a camera rig;
• a coupling list of every internal it relies on.

Leia SR is the tested display. Status text reads "3D active".

Code: joehillthunder/displayxr-twinmotion @ 96710db (private, Apache-2.0 + NOTICE).

Target class: dedicated 3D window, whole client

In 3D mode (F10), Twinmotion hides its own UI and mirrors one eye over its whole client, so the 3D view is the whole client and there's no viewport rect to track. It can't draw a woven texture into its own viewport. Today's test scaffolding is the overlay embed (#2332) over the client. The target is the shared host library's dedicated 3D window: over the app's whole client, or full screen on a 3D monitor with the UI on a 2D one.

What the shared host library needs to provide for this class

• A per-process seed for external legacy OpenXR apps, with no app code: a camera rig computed from display info before xrCreateSession, plus the 3D window's size so the rig follows resizes.
• Window placement for a whole-client app: own the 3D window over the host's client, or move it to a 3D monitor, with dock/undock and F11.
• A live depth channel any helper can drive: strength relative to the seeded rig, plus focus distance.
• Input mapping for apps that expect motion controllers:
  • the mouse pointer as the controller (Twinmotion binds microsoft/motion_controller, and the mouse hand drives its teleport pointer);
  • a gamepad → Touch / motion-controller map.

Display values

Panel size and nominal viewer come from display info (displayxr-cli status --json, screens[].layout). The named gap is the comfort budget, which isn't in display info, so 0.14 % front / 0.42 % behind are constants (#2388).

Depth method: true-geometry rig

• vFOV = the 3D view's angular height from the nominal viewer.
• The screen plane is at g scene metres (convergenceDiopters = 1/g).
• ipdFactor = K·w·g/(ipd·z) puts infinity exactly at the behind budget K.
• Parallax then follows p(z) = K·(1 − g/z). Architecture scenes are tens of metres deep, so nothing can exceed the behind budget, and only content nearer than 0.75·g crosses the front budget.
• Profiles: interior g = 2 m, exterior g = 8 m, plus a live Focus slider (0.3–10 m).

Measured

Projection atlas, block matching, viewer seated, g = 2 m, K = 0.42 %:

Measurement	Measured	Predicted
Floor ~10 m away	0.31 %	0.34 %
Far floor	0.37 %	→ 0.42 %
Slider strength 2×	1.8×	2×

Unreal renders the off-axis true-geometry frustum correctly. On a hybrid-GPU PC, the session runs through the D3D12 → D3D11 reroute. Twinmotion delivers ~29 fps, and the weave's saturation back-off engages.

Omniverse

Twinmotion 2026.2 exports no 3D scene format; glTF/FBX export are on Epic's public roadmap. Two ways to share content, neither tested yet:

• send the same source model to both apps (Datasmith → Twinmotion, USD → Kit);
• go Twinmotion → Unreal Engine → USD.

Runtime findings

• The post-compose atlas trigger never fires on the D3D12 → D3D11 hub reroute; the projection trigger works: Atlas capture: the post-compose trigger never fires on the D3D12 → D3D11 hub reroute (projection trigger works) #2387.
• Comfort budget in display info: Display info: publish the comfort budget (front/behind disparity limits), e.g. layout.comfort {front_frac, behind_frac} #2388.
• A data point for the reroute gates is in D3D12 hybrid reroute default flip — gates #2375.

Pending

• Running beside another weaving app (the Kit viewer).
• Gamepad input: Touch emulation is pending signing, and no physical pad has been tried.
• The exterior profile measurement.
• macOS: no display plug-in there, and Twinmotion's macOS VR is unverified.
• Linux: n/a, because Twinmotion doesn't ship there.

🤖 Generated with Claude Code

[joehillthunder]

Update: confirmed on the released runtime. Twinmotion 2026.2 Preview (UE 5.7.4) runs in glasses-free 3D on the released runtime (installed v2.53.1, unmodified). The user started it with F10 and confirmed the look on the tested display ("looks good"), using the true-geometry rig from display info (screen plane 2 m into the scene, behind-glass budget 0.42 %). On the released runtime, the 3D takes the whole panel. The in-window 3D view and the live depth control still need the dev drafts (#2332 / #2350) until the shared host library lands.

Finding: a legacy app must use a runtime client whose version matches the running service. With a mismatched client (dev v2.53.0-24 against service v2.53.1), Twinmotion's F10 silently does nothing: there are no OpenXR lines in the app log and no error on screen. The launcher now takes -Runtime installed|dev, so the right client can be picked. A clear error, or a log line from the loader, would save integrators time here.

Still open:

• the Atlas capture: the post-compose trigger never fires on the D3D12 → D3D11 hub reroute (projection trigger works) #2387 retest on v2.54.0+ (trigger name without .exe, grep #2342 hub capture);
• the hub-placement check against DXR_HUB=0 for D3D12 hybrid reroute default flip — gates #2375.

Expected gaps against the integration checklist:

• the dedicated 3D window;
• a live depth control inside Twinmotion;
• the gamepad (untested; the Touch-emulation layer is refused by the trust gate);
• USD export (Twinmotion has none).

Code: joehillthunder/displayxr-twinmotion @ 2ae3392 (private).

🤖 Generated with Claude Code