Proposal: KitBash3D kits in DisplayXR hosts (content source: Cargo USD → host 3D views at true size, inside the comfort budget)

[joehillthunder]

KitBash3D's Cargo 3.0 is USD-native and imports kits into Blender, Maya, Houdini and Unreal. Cargo itself is a 2D browser, so compatibility means the content reaches each DisplayXR host's own 3D view correctly: true size, materials intact, depth inside the comfort budget. It's a content source, like generated 3D (#2391) and measured materials (#2419).

Code: displayxr-kitbash, private repo @ 75216c7 (Apache-2.0 + NOTICE), access on request. Standard-library Python plus usd-core; 14 tests, synthetic fixtures only. No KitBash3D assets, textures or renders are included: kits are licensed to the user.

What it does

• check reports the traps a plain reference hits:
  • Z-up cm;
  • bindings outside the defaultPrim;
  • MaterialX-only shading;
  • visible collision meshes;
  • absolute or missing textures.
• convert writes one self-contained file in Omniverse Kit's layout:
  • the asset flattened into the defaultPrim, with relationships re-pointed;
  • a UsdPreviewSurface beside the MaterialX;
  • collision hidden in every host (guide + invisible);
  • instancing kept.
• fit frames a kit for prop, street and aerial views inside the comfort budget, using the same true-geometry rig maths as the Slicer (Proposal: DisplayXR for 3D Slicer (medical visualization, Leia SR tested) #2352), ParaView (Proposal: DisplayXR for ParaView (scientific visualization, Leia SR tested) #2360) and Maya (Proposal: DisplayXR for Autodesk Maya (in-viewport Viewport 2.0 plug-in, Leia SR tested) #2390) integrations. Panel size, pixels and viewing distance come from display info (displayxr-cli status --json). Only the budget is a constant (Display info: publish the comfort budget (front/behind disparity limits), e.g. layout.comfort {front_frac, behind_frac} #2388).

Measured

• Hosts: headless Blender 5.2.2, mayapy 2027 and USD Composer (Kit 110.4, RTX) load the converted file at true size, with textured materials, collision hidden and instancing kept. Kit renders the MaterialX surface.
• Depth fit in Kit's 3D view: at first it failed. Kit's "frame selection" put the glass at the bounding-box centre, so the far side measured +0.47 % against the 0.42 % behind budget. With the Omniverse adapter's depth-aware framing (back off only as far as the depth needs, and slide the glass toward the near end), it measured +0.10 to +0.26 %, with nothing in front.
• Predicted (rig maths, 1920×1200 view on the tested display), with no camera push-back in any case:

Content	Prop (20° down)	Street (eye 1.7 m)	Aerial (55° down)
20×60×20 m tower	behind 0.14 %	behind 0.39 %	behind 0.30 %
55×60×30 m layout	behind 0.12 %	behind 0.28 %	behind 0.24 %
400×120×400 m block	behind 0.18 %	behind 0.36 %	behind 0.16 %

Every case sits exactly at the front budget, because the solver puts the nearest content there. The glass is tens to hundreds of metres out, so hosts must set clip planes from the fitted depth range rather than a DCC default far clip.

What a shared host library would need

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 fit reads it instead of a constant.
2. A per-host "frame this USD prim in 3D" call, so content libraries don't re-implement each host's camera, and so the host's own "frame selection" doesn't overshoot the budget.
3. Clip planes derived from the fitted depth range for very large scenes.

Pending

• A real Cargo download: up axis, units and binding layout are still assumed from the worst case.
• Houdini and Unreal routes.
• Atlas measurements in each host on the panel.

🤖 Generated with Claude Code