Boundary Representation Geometry in OpenUSD — Problem Statement

[asluk]

Description of Proposal

Summary

Frame the problem of representing mathematically exact geometry in OpenUSD. Industrial workflows in manufacturing, AECO, robotics, and simulation depend on boundary representations (Breps) and other exact geometry; OpenUSD today offers only approximating types (meshes, subdivision surfaces) and a small set of analytic primitives. This proposal makes the case for native Brep support without committing to a schema, separating the problem from the solution so the design discussion can converge on requirements first.

The AOUSD Geometry Working Group's companion UsdSolid schema proposal is opened against this proposal's branch as a stacked PR.

Problem statement

OpenUSD has no mechanism for representing mathematically exact geometry. Meshes approximate. Subdivision surfaces approximate. NURBS patches come closest but lack topological connectivity, robust trimming support, and double-precision control vertices. Analytic primitives are exact but limited to a fixed catalog of canonical shapes.

The dominant interchange representation for exact geometry in industry is the boundary representation (Brep): a solid described by its bounding surfaces, edges, and vertices with explicit topological relationships. As OpenUSD expands into manufacturing, AECO, robotics, and simulation, the absence of Brep support is becoming a structural gap rather than a missing feature.

Two distinct kinds of geometry are conflated in current discussions: (1) display geometry -- meshes and subdivision surfaces, approximate, derived; and (2) exact geometry -- Breps, parametric surfaces, analytic shapes with trimming, mathematically exact, authoritative. These are complementary, not competing. Separating these concerns is the core design goal of this proposal.

Glossary

The full Brep glossary lives in Appendix A of the proposal. Highlights for orientation:

• Brep (boundary representation) -- A solid described by its bounding surfaces, edges, and vertices with explicit topological relationships.
• Exact geometry -- A mathematical surface or solid representation whose accuracy is not bounded by tessellation density.
• Display geometry -- Meshes, subdivision surfaces, and other approximating types derived from exact geometry (or authored directly).
• Manifold / non-manifold -- Topological classifications of Brep entities; non-manifold support is needed for simulation and other industrial use cases.

Reference Links

• Identifier Separation of Concerns (PR #105) -- The "problem compiler" methodology this proposal applies. The two proposals are substantively independent.
• Profiles Proposal (PR #89) -- A relevant mechanism for declaring which capabilities a USD implementation supports.
• Gaussian Splats schema (OpenUSD PR #3716) -- A precedent for shipping schema, Hydra adapter, and conversion tools together; cited as a model for staging implementation.
• AOUSD Geometry Working Group -- The group preparing the companion schema proposal.

Details

This proposal applies the "problem compiler" methodology used in the Identifiers proposal: a domain-agnostic problem statement, separation of concerns, and consensus on requirements before any schema is introduced.

Use cases are drawn from the AOUSD Geometry Working Group's cross-industry survey (CAD and BIM Use Cases, v0.2, December 2024, Thorsten Hertel and Alex Fuchs). Two hero use cases lead:

1. Measurement and clash detection in facility planning -- factories, warehouses, construction sites, hospital wings. Equipment suppliers publish tessellated meshes; the planner has no access to the original CAD models. Meshes make measurement unreliable (cylinders have no center axis, holes have no canonical diameter) and clash detection ambiguous when measured distance is near the tessellation tolerance.
2. Consumer-controlled data quality -- the exporter currently chooses a tessellation density once for all downstream consumers. With a Brep in the stage, a visualization artist, a structural engineer, and a machining planner each derive a fit-for-purpose representation without modifying the source.

Additional use cases cover AECO (reference model exchange, clash detection, code compliance, BIM interoperability), Manufacturing and Product Engineering (PMI, tolerances, machining toolpaths, inspection, wireframe authoring including for IP protection), and Robotics and Simulation (collision, path planning, FEA/CFD with exact geometry).

The proposal also covers Existing mechanisms in USD (Mesh and subdivision surfaces, NURBS curves and patches, analytic primitives, UsdVol's opaque-data precedent) and documents why current workarounds (embedding STEP as opaque payloads, encoding Breps in customData, parallel external pipelines) forfeit composition, layering, and sparse overrides for the most important geometry in the scene.

A Design considerations section captures seven principles (separation of concerns, double precision, prim-count discipline, additive-not-disruptive, grounded in proven theory, ship early-iterate), open questions, and a Likely direction paragraph that points readers to the companion schema proposal.

Risks

From the proposal's Risks subsection:

• Scope creep. Exact geometry covers a wide territory — Brep topology and a broad catalog of curve, surface, and volume types (analytic primitives, NURBS, blends, offsets, volumes, and more, per standards such as PRC ISO 14739-1:2014). The companion schema proposal targets the full catalog but presents detailed schema designs incrementally, beginning with NURBS curves and surfaces in the current revision and adding the remaining types in subsequent revisions.
• Kernel dependency. Tessellation, Booleans, and measurement require geometry kernels (Parasolid, ACIS, Open Cascade). The schema should not mandate a specific kernel, but the ecosystem needs at least one open-source tessellation path.
• Evaluation cost. Brep data is more compact than high-resolution meshes but more expensive to evaluate. The schema should let applications choose between the Brep and a cached mesh.
• Adoption chicken-and-egg. Reference implementations (exporters, a tessellator, Hydra adapters) and early-adopter engagement are essential.
• Core-team alignment. Brep support introduces requirements from domains Pixar has not historically served. Close collaboration between the WG and Pixar's team is needed.

Alternate solutions

The proposal's Existing mechanisms in USD section evaluates the current options:

• Polygonal meshes, subdivision surfaces, NURBS patches, analytic primitives -- the status quo. All approximate or are otherwise insufficient for industrial use cases; the gap this proposal documents.
• STEP / PRC / Parasolid as opaque file references -- preserves exactness but forfeits USD composition, layering, overrides, and per-element property assignment. Discussed in Why this matters now alongside other workarounds (customData encoding, parallel external pipelines).
• UsdVol-style opaque data -- precedent considered; rejected for the same composition reasons.

Out of Scope

• Schema design -- the technical design is the companion AOUSD UsdSolid Schema proposal, stacked on this one. This document is meant to establish requirements against which any proposed schema can be evaluated.
• Implementation in OpenUSD -- staged separately; the Gaussian Splats PR (#3716) is cited as a model.
• Brep-to-Mesh relationship -- identified as an open question (USD relationships, naming conventions, or a companion API schema are candidate approaches; deferred).
• Assembly representation, constraint systems, PMI -- identified as open questions and downstream proposals.
• Manifold-vs-non-manifold scoping -- identified as an open question; the WG draft supports both.
• Tessellation responsibility -- USD-level plugin vs. application-level kernel tessellation; identified as an open question.

Link to Rendered Proposal

Supporting Materials

None at this time.

Contributing

• I agree to and accept the Supplemental Terms.