Solid Models in USD

[asluk]

Description of Proposal

Summary

Introduce UsdSolid, a boundary representation (Brep) schema for OpenUSD built on the Radial Edge Data Model. The schema supports manifold and non-manifold solids, sheet bodies, and wireframes, with explicit topological relationships and a packed UsdSolidBrepArray design that limits prim count for large assemblies.

This is the technical companion to the Boundary Representation Geometry in OpenUSD — Problem Statement proposal (PR #108); please review that proposal first for use cases and motivation. Both proposals are opened against main, so this PR's diff includes the P1 problem-statement file as well as the P2 schema files until P1 merges; reviewers may wish to focus on proposals/UsdSolid/ here.

This proposal is from the AOUSD Geometry Working Group.

Problem statement

OpenUSD has no native representation for mathematically exact solid geometry. The companion problem statement develops the use cases and design considerations in depth. In brief, manufacturing, AECO, robotics, simulation, and digital-twin workflows require exact Brep geometry that mesh and subdivision-surface types cannot express. This proposal provides a candidate schema.

Glossary

The full Brep glossary lives in the companion problem statement's Appendix A; this proposal's Glossary section adds only the schema-specific terms:

• BrepArray -- A UsdSolidBrepArray prim that holds one or more Breps in a packed, flat representation. Each Brep's topology, geometry, and metadata are concatenated into shared arrays and delineated by per-Brep counts and offsets.
• Wire edge -- A wireEdge is a topologically standalone edge that is not part of any face loop. Wire edges carry the same curve geometry as loop-bounding edges but exist independently as one-dimensional features within a shell.
• Radial Edge Data Model -- A non-manifold-capable topological data model (Weiler, 1986) that supports manifold solids, non-manifold solids, sheet bodies, and wireframes through a unified "use" abstraction (edgeuse, faceuse).

Reference Links

• Companion problem-statement proposal -- PR Boundary Representation Geometry in OpenUSD — Problem Statement #108
• Weiler, K. (1986). The Radial Edge Structure: a Topological Representation for Non-Manifold Geometric Boundary Modeling -- The topological model the schema is built on.
• PRC specification (ISO 14739-1:2014) -- Reference for the geometry-type catalog the schema targets.
• Gaussian Splats schema (OpenUSD PR #3716) -- A precedent for a preliminary geometry schema (prelimUsdRender...) entering OpenUSD and later promoting.
• USD Profiles proposal (PR #89) -- A relevant mechanism for declaring which capabilities a USD implementation supports.

Details

The proposal is organized as Introduction → Glossary → Design → Schema → Examples → References.

Design introduces the Brep data model in three layers — shape, topology and "use", and Brep — and then walks through USD-implementation choices including UsdSolidBrepArray, instancing, geometry typing, modeling Breps on a UsdStage, and trimming curves. Subsections on Flexible design possibilities and Other implementations considered document the design space the proposal explored before converging on the Radial Edge model and a packed BrepAPI on a typed prim. Assemblies, tolerance, validation, risks, and open questions follow.

Schema is a complete prelimUsdSolid schema definition (prelimUsdSolid prefix and skipCodeGeneration = true, following the OpenUSD convention for WIP schemas; both will be stripped on acceptance, matching the path Gaussian splats took).

Examples narrate five .usda cases covering cube, non-manifold cubes, cube with internal void, BrepArray with multiple Breps, and per-face materials.

Design choices worth highlighting for reviewers:

• Radial Edge over winged-edge / half-edge -- chosen for explicit non-manifold support, which industrial assemblies require. The topology models in PRC, STEP, and Parasolid map into the Radial Edge model.
• Packed BrepArray -- a UsdSolidBrepArray typed prim with a multiple-apply UsdSolidBrepAPI keeps prim counts tractable for large assemblies. The trade-offs against one-prim-per-Brep and one-prim-per-geometry-object alternatives are documented in the Design section.
• Double-precision geometry -- proposed for NURBS control vertices, weights, and knots (and analytic surface parameters), addressing a known limitation of existing UsdGeomNurbsCurves / UsdGeomNurbsPatch for CAD interchange.
• PRC geometry-type catalog as target -- the proposal lists the full set of analytic curves, surfaces, and volumes (Helix, Revolution, Extrusion, Torus, etc.) that the schema is structured to accommodate. NURBS land first; the analytic types are an extension path, not a v1 deliverable.

Risks

From the proposal's Risks subsection:

• Validation complexity. Full geometric validation (self-intersection, tangency, tolerance enforcement) requires a geometry kernel and is outside the scope of OpenUSD. Topological validation is in scope; geometric validity depends on third-party libraries.
• Geometry kernel dependencies for rendering. Tessellation of Breps for rendering requires a kernel. OpenUSD does not ship one; adoption depends on the ecosystem (open source or commercial kernels) consuming UsdSolid data.
• Performance at scale. Large assemblies (thousands of Breps, tens of thousands of faces) drove the packed UsdSolidBrepArray design, but composition, layering, and instancing performance remain to be characterized with production datasets.
• Ecosystem readiness. DCCs, viewers, and engines will need to add Brep support before the schema delivers end-user value.
• Data quality dependence on exporters. Authoring happens outside OpenUSD; quality tracks exporter quality. The WG is considering reference datasets and a conformance suite.

Alternate solutions

The proposal's Other implementations considered subsection documents the alternatives evaluated:

• One UsdPrim per geometry object -- rejected on prim-count grounds at industrial-assembly scale.
• One UsdPrim per Brep -- rejected for the same reason; assemblies routinely contain thousands of Breps.
• Breps as an Applied API on existing prim types -- considered; the typed-prim approach with a multiple-apply API was preferred for stronger schema semantics on the container.
• Breps as a black box (opaque file reference) -- rejected because it forfeits USD's composition, layering, and per-element property assignment. The companion problem statement develops the full rebuttal.

Out of Scope

• Detailed schemas for analytic geometry types -- the catalog is identified (Helix, Revolution, Extrusion, Torus, etc.) and the schema is structured to accommodate them, but their detailed designs are deferred to a follow-up revision.
• Brep <-> Mesh correlation -- identified as an open question. A candidate approach (gprim back-references via an applied API) is sketched in Open Questions; full design is deferred until the core schema is in use.
• CAD assemblies as a schema -- whether assemblies warrant a dedicated schema or a best-practices guide built on instancing and constraints is unresolved; covered in Open Questions.
• Constraint systems for assembly simulation -- mates, joints, kinematic constraints; identified as open. May belong here, in a separate schema, or in an OpenUSD-wide proposal.
• Migration tooling from STEP, PRC, Parasolid -- detailed mappings and exporter implementations are downstream work.
• Implementation in OpenUSD -- staged separately, modeled on the Gaussian splats path (prelimUsdRenderGaussian → UsdRenderGaussian after community use).

Link to Rendered Proposal

Supporting Materials

The proposal includes six diagrams (proposals/UsdSolid/images/) illustrating the Radial Edge data model, BrepArray structure, and face-material binding. Five narrated .usda examples accompany the schema.

Contributing

• I agree to and accept the Supplemental Terms.

[dgovil]

Hi Aaron,
I am just relaying some internal feedback:

Can we reconsider deferring the correlation between the BRep and the tessellated mesh? These are the two main concerns:

Vendor divergence risk: If we ship without a standardized correlation mechanism, individual CAD vendors might develop their own conventions to bridge the two representations. Once these conventions become widely adopted and assets rely on them, standardizing later becomes a migration issue rather than a design challenge. The cost of getting this right upfront is significantly lower than the cost of reconciling multiple vendor-specific schemes later.

Tessellated mesh may not always be present: CAD vendors might choose not to ship a tessellated mesh at all if the correlation path is unclear. If the contract for going BRep - mesh isn’t clearly defined, the safest choice for a new vendor is to ship BRep only and let consumers tessellate. This is arguably a worse outcome than having a dual representation, and it’s the default we’ll end up with if we defer.

[asluk]

Hi Aaron, I am just relaying some internal feedback:

Can we reconsider deferring the correlation between the BRep and the tessellated mesh? These are the two main concerns:

Vendor divergence risk: If we ship without a standardized correlation mechanism, individual CAD vendors might develop their own conventions to bridge the two representations. Once these conventions become widely adopted and assets rely on them, standardizing later becomes a migration issue rather than a design challenge. The cost of getting this right upfront is significantly lower than the cost of reconciling multiple vendor-specific schemes later.

Tessellated mesh may not always be present: CAD vendors might choose not to ship a tessellated mesh at all if the correlation path is unclear. If the contract for going BRep - mesh isn't clearly defined, the safest choice for a new vendor is to ship BRep only and let consumers tessellate. This is arguably a worse outcome than having a dual representation, and it's the default we'll end up with if we defer.

Hi @dgovil — thanks for surfacing this. Responding for whoever raised it:

Correlation isn't deferred — it's a separate concern from the Brep schema. The companion problem statement's Coexistence with meshes principle already says Brep and Mesh "should be relatable… but neither should require the other," and the mechanism is "separable from the core Brep schema." This proposal's Open Questions section has a "Brep↔Mesh correlation" entry sketching a candidate from Steve Ghee: an applied schema on the derived gprim that back-references the source Brep — the active follow-on path.

Two reasons it sits there:

• Broader than Brep↔Mesh. Source/derived pairs aren't unique to CAD — subdivision cages and limit surfaces, sim results and viz meshes, LoD chains. A mechanism designed only for UsdSolid would need rework when the next pair appears. It belongs in its own proposal, seeded by prior discussions.
• USD composition supports the separation. The correlation mechanism sits outside UsdSolid's domain entirely; the core Brep schema stays self-contained.

On the two specific concerns:

Vendor divergence. The Ghee sketch signals direction. Vendor-prefixed proposals exploring variations are welcome — AOUSD's vendor → multi-vendor → core pattern (cf. PR #105) converges rather than fragments. Symmetric risk: continuing to block the Brep schema leaves vendor-specific Brep encodings hardening in customData and opaque payloads — a divergence we're already paying for.

Brep without companion mesh. The problem statement frames this as a desired direction, not a worse outcome — see "'Derive on demand' is replacing pre-tessellation" and Hero Use Case 2 (consumer-controlled data quality). The schema doesn't preclude shipping both; the question is whether the correlation contract must land in v1, and we don't think so. Real data on real stages is how the community converges on the right mechanism.

Best,
@asluk and @umhoefer

[martinpwnv]

Could I suggest moving the schema.usda out of the main doc where it is a bit hard to find (currently in a collapsible section) and have it be a standalone file in the repo that lives alongside the document?

[asluk]

Good call, Martin — done. The schema now lives as a standalone schema.usda alongside the document, and the README links to it instead of burying it in a collapsible section. The content is byte-identical to the previously inlined block (no edits beyond the move). Pushed as 811f03c.

[asluk]

Re: schema.usda extraction — tradeoff + a future idea

Moving the schema into a sibling schema.usda is the approach we've landed on for now. It has real tradeoffs worth noting for the record:

Wins

• Single canonical, machine-readable copy (good for tooling/codegen)
• No drift between an inlined block and the real schema
• Easy to find, lives alongside the doc

Cost

• Schema no longer visible in place in the proposal
• Relative ./schema.usda link works on GitHub's web view, but breaks in portable/offline renderings — a PDF or static export (e.g. Pandoc) can't follow it, so "read the proposal on the go" hits a dead reference

Future work for consideration

• If "canonical file + reference from prose" becomes a common pattern, a small proposal build step could transclude the file into the rendered doc (marker comments + CI staleness check) — one source of truth and self-contained artifacts (GitHub / PDF / offline)

Flagging only; not proposing we act on it here.