NVIDIA has published USD BRep, an open-source library for creating and editing boundary-representation solids and storing them in OpenUSD. The release gives developers C++ and Python APIs for solid modeling, plus OpenUSD import and export; its practical significance is a new route for keeping exact BRep geometry in 3D pipelines rather than relying only on polygon meshes.
The project is built around SMLib, NVIDIA’s NURBS-based geometry kernel. The repository documents solid-modeling operations including booleans, fillets, sweeps and offsets, alongside geometry healing and validation. The kernel can represent BRep faces and edges with NURBS or analytic geometry. In OpenUSD, the project’s BrepArray schema stores the BRep’s topology and geometry, while separate tools can tessellate solids into meshes for applications that need them.
Geometry exchange is the stronger near-term story
USD BRep is more than a kernel API: the repository includes OpenUSD converters, a validator, a healer, a Hydra plugin for viewing BReps in usdview, and converters between Open CASCADE and USD BReps. That combination gives pipeline developers a way to test geometry exchange and downstream handling without making every stage of a visualization workflow operate on tessellated output.
I would use USD BRep for geometry exchange and automation, not as a replacement for feature-history CAD. Transferring BRep geometry alone carries a feature-history loss risk. The repository describes BrepArray as storing topology and geometry; it does not establish that a source model’s multi-step feature tree or editable design intent travels with that representation. If a conversion carries only that BRep data, downstream users may receive the shape without the original construction history. When editable design intent must survive, I would require a native parametric workflow rather than treat BRep exchange as a substitute. The documented direct BRep operations may still support scripted modeling and downstream pipelines, but they do not by themselves demonstrate a full parametric authoring workflow. Claims that the release makes AI-generated models manufacturable should therefore be treated as a possibility for developers to investigate, not as a demonstrated outcome.
There are reported examples of the pipeline approach. SMLib already powers ClassCAD, according to AWV Informatik, which said it had worked with the SMLib team for over 20 years. Separately, Scott Rafferty of engineering and design consultancy AFRY described integrating USD BRep with a Blender workflow: his openWire tool writes exact NURBS BRep data to OpenUSD as a BrepArray, which can then be opened in usdview with NVIDIA’s Hydra plugin. This is a reported example, not evidence that every Blender or OpenUSD workflow supports the same exchange path. The example illustrates how exact geometry can be passed into a visualization pipeline while keeping the mesh as a separate representation, but it does not show that parametric feature history is preserved.
There is a practical adoption boundary, too. NVIDIA’s repository says its PyPI package supports CPython 3.12 on Linux (x86_64 and aarch64) and Windows; teams on other configurations should check the build requirements rather than assume a ready-made package. The project is licensed under Apache 2.0 and provides runnable Python and C++ examples. Those facts make prototyping accessible, but production use still calls for validation against the organization’s own geometry and exchange requirements.
Early release, with a focused follow-up
The initial public release appeared as version 1.0.0. NVIDIA’s subsequent 1.0.1 release added USD BRep geometry validation and healing APIs for BrepArray data and improved tessellation performance, according to the project’s release notes. Those additions reinforce the project’s pipeline focus: checking and repairing geometry in USD scenes, as well as modeling solids in memory.
My practical acceptance test would record the source model’s topology and surface-tolerance measures, then compare them after conversion and again after healing. I would reject the pipeline if either comparison exceeds the team’s agreed limits: healing that changes topology can break downstream face references, while surface changes beyond the part’s manufacturing tolerances can make the geometry unsuitable for production. The team should set those limits for its own parts and downstream use.
For CAD teams, I would ask directly: Does a representative part move through the target OpenUSD workflow with the required topology and surface data intact? The team should also check whether validation, healing and downstream conversion behave as needed. Keep a native parametric workflow wherever feature history and editable design intent must remain available; assess USD BRep separately for geometry exchange and downstream use.
Sources
- Omniverse USD BRep v1.0.0 release — NVIDIA-Omniverse on GitHub
- USD BRep repository and README — NVIDIA-Omniverse on GitHub
- USD BRep releases and changelog — NVIDIA-Omniverse on GitHub
- USD BRep Python API documentation — NVIDIA Omniverse
