Proposal: DisplayXR for CLO Virtual Fashion (garment design in a dedicated 3D window via the DisplayXR Browser, Leia SR tested)

[joehillthunder]

Summary

A thin CLO plug-in shows the garment being designed in CLO (CLO Virtual Fashion) in
glasses-free 3D, in its own window beside CLO, following CLO's 3D-window camera. CLO's
public API (SDK 2026.1) can export the scene and read the 3D window's camera, but has no
draw hook into that window. So the integration uses the dedicated 3D window class from
the architecture direction
(#2331 (comment)),
not the app's own viewport: a windowed DisplayXR Browser app window running an inline-3D
page. It needs no native code and no runtime changes, and it was checked seated on the tested
display (Leia SR, 34.4 × 21.5 cm, 300 % scale) in CLO 2026.1.336.

Code: private repo joehillthunder/displayxr-clo (Apache-2.0), access on request.

What it does

• CLO side (Python plug-in, dock panel "DisplayXR 3D", Plugins menu):
  • Update 3D exports the garment (and, optionally, the avatar) as GLB.
  • Sync camera reads CLO's 3D-window camera. There's no "get camera" call, so it saves
    the view as a Custom View and reads that back.
  • Send to Omniverse (USD) exports in Kit's layout (Y up, centimetres).
  • All CLO and DisplayXR internals the plug-in relies on are in one coupling module,
    each marked "not a contract".
• The export is made display-ready. CLO 2026.1 writes the avatar as skinned meshes in the
  bind pose, some parented under joints, and in millimetres (its SDK says metres). The
  plug-in rewrites only the GLB's JSON: it drops the skins, moves those meshes to the scene
  root and scales the scene to metres. Garment pieces come out as real draped geometry
  (Modular Library shorts: five pieces, 9–14 cm deep each), not a flat cloth with a normal
  map, so the folds read in stereo.
• The 3D window is a page opened from disk in the DisplayXR Browser, in its own profile,
  with no server and nothing on the network. It polls a live folder (state.json, then the
  newest scene-<n>.glb). A first version served the page from a 127.0.0.1 server in
  CLO's embedded Python. That doesn't work: the embedded interpreter only runs while a
  menu or button callback runs, so the server accepted connections and never answered.
• Windowed, beside CLO, never covering CLO's UI. Full panel is F11 or a button, and F11
  again returns to the window. The status line says "3D active" while the display weaves
  the page.
• CLO's camera is the source of truth: "Follow CLO camera" turns the 3D to CLO's view on
  each sync. A drag turns the garment all the way round, and the wheel zooms.

Depth and comfort (measured)

• Display values (panel size, nominal viewer) come from display info. The comfort budget
  (0.14 % of panel width in front of the glass, 0.42 % behind) is a named constant until
  Display info: publish the comfort budget (front/behind disparity limits), e.g. layout.comfort {front_frac, behind_frac} #2388 publishes it.
• 100 % puts the nearest and farthest visible points on the budget:
  • The glass sits a quarter of the way into the garment, because the budget behind is three
    times the budget in front. That doubles the usable depth compared with a glass through
    the middle.
  • The page refits the stereo strength from the current bounds ten times a second.
    Parallax is linear in strength, so the readout holds at the budget at any zoom or angle.
• Panel readout (shorts on the CLO avatar, front view): 0.14 % front / 0.41 % behind at
  100 %, 0.18 / 0.51 % at 125 %, 0.21 / 0.59 % at 150 %.
• Seated on the tested display, the user's path to a setting:
  • True geometry (strength capped at 1, 0.05 %): "needs more depth".
  • 125 % and 150 %: crosstalk at the edges.
  • 100 %: "looks good", so it ships as the default.
  • Before the refit, a wheel zoom took the image past the budget ("image melts"). Fixed.
• Woven pages need an opaque clear colour. The display rig's per-eye cameras clear to
  transparent black. Woven, those pixels showed stale content (a bright ring, earlier
  "Loading…" text) instead of the page. The page now clears every camera to an opaque
  mid-grey. Mid-grey rather than black, because light skin or fabric on black makes
  crosstalk more visible.

What a shared host library would need

For apps like CLO (scripting and export, but no draw hook), a page plus a plug-in is enough
today. Five things would make it a supported path instead of a workaround:

1. The comfort budget in display info (Display info: publish the comfort budget (front/behind disparity limits), e.g. layout.comfort {front_frac, behind_frac} #2388), so the page reads it instead of a constant.
2. A supported way to open a local viewer page in the DisplayXR Browser, windowed, with
   access to one live folder. Today the plug-in starts chrome.exe --app=file:///… --allow-file-access-from-files in a dedicated profile. A launch option or manifest that
   grants one folder would remove the flag and the per-app profile.
3. An inline-3D option for an opaque clear colour, or an opaque default on the display
   rig's eye cameras. Every embedding page otherwise has to patch the cameras.
4. A "fit to budget" helper in inline-3D that keeps the nearest and farthest points on
   the budget while the user zooms and turns: glass placement and continuous strength
   refit, as above. Every object viewer needs it, and the current per-pose fit doesn't
   follow the wheel zoom.
5. A pass-through orbitStyle in addSplat (turntable). Object viewers need a full
   turn, and the default is a 15° tilt that springs back. The page sets it on the viewer
   directly today.

Open items

• Edges are still slightly perforated on the panel. The eye buffers render at two-thirds
  of the panel's resolution at 300 % scale. Full resolution (renderScale 1.5) dropped to
  15 fps with the GPU shared with two other 3D apps. Next: try about 1.25×, and measure on
  an idle GPU.
• Camera convention for non-front views. CLO's Custom View cameraMatrix translation
  looks like a world-to-camera matrix (front view: t = (0, −934, −9167) mm). The front view
  is right either way. Side and top views need a check in CLO before the plug-in can follow
  them reliably.
• No continuous follow. CLO's Python API has no timer or change event, so the 3D updates
  on Update 3D and Sync camera only.
• Not yet checked:
  • The Send to Omniverse USD, in USD Composer.
  • A run beside another 3D app.
  • CLO-SET's web garment viewer in the DisplayXR Browser (needs an account).
• macOS: CLO ships on macOS, but there's no Leia SR runtime there.

🤖 Generated with Claude Code

[joehillthunder]

Hosting-readiness check: pass (2026-10-27)

Installed runtime v2.55.0 with the Leia SR plug-in; no dev settings.

• The 3D window opens with the plug-in's own launch command and shows "3D active".
• Depth −/+/Reset works:

Setting	Front	Behind
75 %	0.11 %	0.30 %
100 % (default)	0.14 %	0.41 %
125 %	0.18 %	0.51 %

• Exit: clean.
• Seated rating at the shipped 100 %: "looks good".
• Fixed during the check: from a file:// page, fetch() fails to read a 26 MB export, so the page now loads the GLB with XHR.

Not tested: CLO's side and top camera views; the USD export opened in USD Composer.

🤖 Generated with Claude Code