# USD BRep for NURBS solid modeling in C++ and Python

> USD BRep is NVIDIA Omniverse's Apache-2.0 library for NURBS-based boundary-representation solid modeling. It offers C++ libraries, Python bindings, tests, examples, and USD asset healing, but its build requirements and platform constraints require careful evaluation.

**NVIDIA-Omniverse/usd-brep** — USD BRep is a standalone C++ and Python library for NURBS-based boundary representation (BRep) solid modeling

- Repository: https://github.com/NVIDIA-Omniverse/usd-brep
- Website: https://nvidia-omniverse.github.io/usd-brep/
- Stars: 1,744 · Forks: 257
- Language: C++
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/nvidia-omniverse-usd-brep

## USD BRep's solid-modeling scope and intended users

USD BRep addresses a specific geometry-engineering problem: representing solid models through NURBS-based boundary representation, or BRep. A BRep describes a solid through its boundary surfaces and the relationships between those surfaces. That makes the library relevant to engineers working with precise geometric assets, USD scene data, CAD-like conversions, and sample models involving USD, STEP, IGES, or JT fixtures. It is a standalone Omniverse repository rather than a general-purpose command-line CAD application.

The project serves two programming audiences. Its C++ libraries provide the native implementation, while the Python layer exposes bindings for scripts, examples, tests, and a graphical interface. The repository includes examples grouped by API layer under `Examples/PyAPI/`, `Examples/SMLib/`, and `Examples/SM_API/`. This separation helps engineers identify whether an example exercises the Python interface, the solid-modeling library, or another API surface.

USD BRep should not be confused with a mesh-only viewer or converter. Its stated center is NURBS boundary-representation solid modeling, and its asset-healing function deals specifically with `BrepArray` definitions in composed USD layers. Teams looking for a complete CAD application, a general mesh repair package, or a cross-platform package that can be installed from a standard language registry should look elsewhere.

## Repository architecture, build tools, and dependency flow

The repository is organized as a C++ source project with Python packaging, native tests, developer tools, fixtures, and layer-specific examples. The root contains `source/`, `tests/`, `TestFiles/`, `TestFilesSmb/`, `tools/`, and `Examples/`. Build definitions include `premake5.lua`, `premake5-libraries.lua`, `premake5-public.lua`, and `repo.toml`. This layout indicates that the build is driven by Omniverse repository tooling and Premake rather than by a conventional standalone package-manager installation.

On Linux and other supported build-time environments, Packman automatically obtains OpenUSD, Python 3.12, pybind11, Premake, and the `repo_*` tools. Linux also requires the system `build-essential` package. Git and Git LFS are required because the repository tracks large binary fixtures, including USD assets and STEP, IGES, and JT models. A fresh build needs a prebuild step because it stages the `omniSolid` schema plugin resources under `_build/schema/omniSolid/resources`; the README states that `repo build` alone does not create those runtime resources.

Windows has a narrower route. The C++ build requires Visual Studio 2019 or 2022 with the Desktop development with C++ workload, the MSVC v142 build tools, and a Windows SDK. Built binaries dynamically link the Microsoft Visual C++ runtime. On macOS, the documented path is Apple Silicon with `macos-universal`, and the project notes special handling for Python, OpenUSD, Premake, and local dependencies. These are source-build constraints, not simple binary installation promises.

## Building USD BRep and running the first Python GUI

On Linux, install `build-essential`, then run the prebuild script before creating a fresh build. The prebuild step is not optional according to the README because it prepares schema resources needed by USD tools at runtime. After `./repo.sh build`, the same checkout can run the repository test suite.

```bash
sudo apt-get install build-essential
./prebuild.sh
./repo.sh build
./repo.sh test
```

The expected result is a staged build under `_build` plus a successful repository test invocation. The README does not provide sample build output or expected timing. If `_build` has been deleted, run the prebuild script again before rebuilding.

The Python GUI is the clearest first end-to-end use described by the README. The command uses the locked `gui` dependency group, so it resolves the versions pinned in `pyproject.toml`, including PySide6, VTK, PyVista, and NumPy. The kernel defaults to debug binaries and writes `Dump()` output to the terminal.

```bash
uv run --locked --group gui python tools/scripts/smlib_gui.py
```

For release binaries, pass `--release` as documented. The GUI is a development interface rather than proof that every C++ feature is available through Python. The repository's example index provides additional runnable compositions, and `tools/smlib_gui/README.md` contains the documented smoke-test and troubleshooting commands.

## Healing BrepArray definitions in USD files

The repository includes a Python API for repairing USD scene files containing `BrepArray` definitions. The documented operation takes an input file and writes a healed output file:

```python
import usd_brep

usd_brep.usd.heal_file("input.usdc", "input_healed.usdc")
```

According to the README, the function heals `BrepArray` definitions in layers used by the current USD composition. The resulting scene retains layers, references, native instancing, transforms, and materials. This makes the operation narrower than a general USD scene optimizer. It targets definitions involved in BRep assets while preserving specified scene structure.

Composition boundaries also matter. External layers used only by unselected variants remain referenced, but their BRep definitions are not healed. Material subset opinions outside the BRep's defining prim specification are rejected rather than silently discarded. That behavior is significant for asset pipelines because it makes the scope of modification explicit and avoids claiming that unrelated variant content was processed. The README does not document recovery behavior, file backups, atomic replacement, or automatic rollback, so those properties should not be inferred from the function signature.

## Testing, formatting, examples, and development constraints

The repository exposes dedicated commands for building, testing, and formatting. On Linux, `./repo.sh test` runs the general repository tests, while `./tests.sh linux-x86_64` runs the documented platform-specific test entry point. On macOS, the corresponding platform target is `macos-universal`. Formatting uses `./repo.sh format`, which is the documented repository-wide formatting command.

```bash
./repo.sh test
./tests.sh linux-x86_64
./repo.sh format
```

The macOS instructions separate a Python-only default path from an optional Tier 1 path that stages local OpenUSD 3.12. The default path lists the kernel, C++ tests, `_smlib_tests`, and `_smlib_dev`, with imports requiring Tier 1 `_omni_solid`. The optional setup changes that dependency arrangement by using `SMLIB_USD_ROOT` and `setup-macos-local-deps.sh`. This is an important operational distinction: a successful Python-oriented build should not automatically be treated as proof that all USD integration paths are available.

The repository is not currently accepting contributions. That reduces its appeal for engineers who expect to submit patches or influence the roadmap through pull requests. Issue and security reporting remain documented, but the contribution policy is a practical adoption constraint separate from the code license. The presence of examples and tests helps inspection, although the README does not define coverage thresholds or compatibility guarantees.

## USD BRep maintenance, licensing, and platform boundaries

The repository is not archived. Its last push was on 2026-10-09, and its latest listed release is `v1.0.0`, identified as Omniverse USD BRep v1.0.0 and dated 2026-10-09. These repository records establish recent project activity, but they do not by themselves establish compatibility with every local toolchain or consumer workload. Upgrade planning must account for the source build, Packman dependency staging, platform toolchain, and fixture requirements rather than treating the library as a small self-contained binary package.

The main library is licensed under Apache License, Version 2.0. The repository also states that `repo.sh`, `repo.bat`, and `tools/repoman/repoman_bootstrapper.py` are MIT licensed instead. Third-party notices and bundled components are recorded in `THIRD_PARTY_NOTICES.md`. This distinction matters when distributing a build: the project identifies different licenses for repository tooling and the main library, so an adoption review should preserve those files and inspect the third-party notices. This is a licensing inventory, not legal advice.

A real alternative is to use a CAD kernel or BRep library through an existing CAD application or an established Python binding stack. That approach may be preferable when the requirement is hosted CAD functionality, a mature exchange workflow, or a platform-neutral installation. USD BRep instead prioritizes Omniverse repository workflows, USD composition, native C++ access, Python bindings, and the specific `BrepArray` healing path. The choice is between project-specific USD integration and broader application-level CAD tooling, not between two interchangeable geometry libraries.

## Conclusion

USD BRep fits engineers who need NURBS boundary-representation solids and can satisfy its Packman, compiler, SDK, and Python 3.12 requirements. It is a poor fit for a lightweight, portable CAD dependency or a contributor-oriented project, since contributions are not currently accepted. Verify your platform toolchain, dependency availability, intended API layer, and the project's Apache-2.0 and third-party licensing obligations before adoption.

## FAQ

### How do I build USD BRep on Linux?

Install `build-essential`, run `./prebuild.sh`, then run `./repo.sh build`. The prebuild step stages the `omniSolid` schema plugin resources required by USD tools at runtime. The README does not document a separate system package installation for the library.

### Can I run the USD BRep Python GUI?

Yes, the README documents `uv run --locked --group gui python tools/scripts/smlib_gui.py` for debug binaries. Add `--release` to use release binaries. The command resolves the GUI dependency group defined in `pyproject.toml`.

### What does `usd_brep.usd.heal_file` change?

It heals `BrepArray` definitions in layers used by the current USD composition and writes the healed geometry to an output file. The README says layers, references, native instancing, transforms, and materials are preserved, while unselected variant layers remain referenced but are not healed.

## Sources

- [License: Apache-2.0](https://github.com/NVIDIA-Omniverse/usd-brep/blob/main/LICENSE)
- [NVIDIA-Omniverse/usd-brep on GitHub](https://github.com/NVIDIA-Omniverse/usd-brep)
- [Project website](https://nvidia-omniverse.github.io/usd-brep/)
- [README](https://github.com/NVIDIA-Omniverse/usd-brep/blob/main/README.md)
- [Releases](https://github.com/NVIDIA-Omniverse/usd-brep/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nvidia-omniverse-usd-brep