The kernel

smlibpy is a Python layer over SMLib, a NURBS boundary-representation solid modeling kernel with a long industrial history. NVIDIA released it, together with a C-style API and Python bindings, as open source under the Apache License 2.0 in the usd-brep repository.

How it fits together

smlibpy (Python)         shapes, selections, sketches, features, STEP/glTF/STL, viewer
  └─ smlibpy._core       one compiled extension module
       ├─ ext            smlibpy's own C++: exact geometry and topology access, transforms,
       │                 sweeps with all options, precise integration, body splitting
       ├─ SmPyLib        NVIDIA's pybind11 bindings of SM_API (without the USD parts)
       ├─ SM_API         NVIDIA's C-style API over the kernel
       └─ SMLib          the kernel: geometry, topology, Booleans, fillets, sweeps, healing

The kernel sources come in as a git submodule (third_party/usd-brep) and are compiled with CMake into a single, self-contained Python extension. Nothing of the kernel is modified; where smlibpy needs more than the published bindings offer, its own C++ module (src/cpp/ext.cpp) calls the kernel directly.

Accuracy

• Geometry is exact: planes, cylinders, cones, spheres and tori are analytic; free-form geometry is NURBS. Booleans and fillets work on the exact surfaces.
• Areas, volumes and centers are integrated over the exact geometry to a relative accuracy of 1e-7 by default. The kernel API limits face areas to 1e-4; smlibpy calls the kernel's integration directly to get past that limit.
• STEP export writes the kernel's exact curves and surfaces. The test suite reads the files back with OpenCASCADE and checks validity and volume.
• STEP import rebuilds every face on its exact surface and keeps the file's topology, so faces share edges instead of being stitched by tolerance.

Robustness work in smlibpy

Some kernel behaviour is wrapped so that it is predictable:

Kernel behaviour	What smlibpy does
Plane cuts keep the other half than documented and leave the body open	split intersects with a half space instead
2D Booleans reject some overlaps (two circles, for one)	falls back to 3D Booleans of thin slabs
Fillets larger than the geometry allows can come back as a "valid" solid	checks the radius against neighbouring edges and the volume change
Sweeps anchor the profile at the start point of its first curve	centers the profile on the path and orients it
A full 360 degree non-manifold revolve returns an empty body	revolves each loop and subtracts the holes
Faces on cylinders, cones, spheres and tori need a seam edge, but NX and others write them without one	adds the seam along the surface when importing STEP
The seam has to lie where the surface's angle parameter starts	turns the surface frame to the seam edge of the file
The extended offset mode depends on memory layout and sometimes builds a face the kernel cannot integrate or mesh	shell uses the plain mode first, checks every result and falls back to the extended mode
Arcs from the API are plain B-splines	arcs are trimmed kernel circles, so they keep radius and center

Known kernel limitations

From usd-brep's own list of known issues, the ones that can matter here:

• heal may report success without repairing everything; check is_valid() afterwards.
• Healing of imported periodic faces (tori, spheres) can go wrong.
• Rounds where three fillets meet at a corner of mixed convexity can fail; round the edges in a different order or with different radii.
• shell cannot remove a face that is bordered by fillets; shell first, then round the rim.
• offset can take a few attempts on complex parts, each as long as the operation itself.

Building the kernel

The build compiles about 250 C++ files and takes a minute or two. It is single threaded inside the kernel unless oneTBB is available (-DSMLIBPY_USE_TBB=ON, used for parallel tessellation and Boolean preprocessing).