📈 GH Trending Explorer 🎲 Surprise me

← all repos

tangency-labs / solidcore

git clone https://github.com/tangency-labs/solidcore.git

A Rust port of NVIDIA's SMLib B-rep kernel (CAD subset): safe, deterministic, wasm-compatible

+4
stars, 24h · #3,304
+~28
stars, 7 days · #4,058
+134
stars, 30 days · #3,795
148
★ total · +26% this week
62
forks · 129 open issues

Star history (as recorded here)

2026-10-20 · 130 ★ 2026-10-22 · 148 ★
LanguageRust
LicenseApache-2.0
Created2026-10-12 (10d ago)
Last pushtoday
Watchers4
OwnerOrganization

Links

README excerpt
# solidcore
**📊 Live progress: tangency-labs.github.io/solidcore**: every unit's port status and difftest results, the upstream-issues log, and the surface/surface intersection corpus scores, regenerated on every merge.
solidcore is a Rust port of NVIDIA's SMLib: a boundary-representation (B-rep) solid
modeling kernel in safe Rust (SMLib is from USD BRep, Apache-2.0).
Solids are exact: shells, faces, loops, edges and vertices bound to analytic and NURBS
curves and surfaces. solidcore's first consumer is **SolidCraft**.
## Scope
In scope: the `SMLib` kernel and the `SM_API` operation layer of upstream — NURBS
math, curve and surface geometry, B-rep topology, intersections, booleans, fillets and
chamfers, offset/shell, sweeps and skins, primitives, healing/stitching, mass
properties and queries.
Out of scope: upstream's OCCT translators, USD/Hydra integration and Python bindings.
See ATTRIBUTION.md.
Goals: no `unsafe` in the kernel, no panics on bad input, deterministic results, no
global state, builds for `wasm32-unknown-unknown`, and numerical agreement with the
C++ to `1e-9` relative with identical topology, verified unit by unit.
## Status
About a third ported and verified against the C++: the math, NURBS and curve layers,
with surfaces and topology under way. **Checklist: `plan/PROGRESS.md`**
(updated automatically). Notes and handoff: `plan/STATUS.md`.
The same data, browsable, is on the progress site built by
`site/build.py` (`python3 site/build.py` -> `bin/site/`).
Nothing is usable end to end yet (no primitives, booleans or fillets).
## Layout
| Path | Contents |
|-------------------------|--------------------------------------------------------------|
| `crates/solidcore` | The kernel library |
| `crates/solidcore-ffi` | `extern "C"` bindings to the upstream C++ (feature `cpp`) |
| `crates/difftest` | Runs Rust and C++ side by side on the same inputs |
| `harness/cpp` | Builds the upstream C++ reference into `bin/cpp`; FFI shims |
| `plan/` | Unit list, port order, status, findings |
| `site/` | Generator for the GitHub Pages progress site |
| `upstream/` | Local clone of usd-brep at `c9c5979` (gitignored) |
| `bin/` | All build output (gitignored) |
## Building
Requires the stable toolchain (pinned by `rust-toolchain.toml`, which also installs
`rustfmt`, `clippy` and the `wasm32-unknown-unknown` target). Cargo output goes to
`bin/` (see `.cargo/config.toml`).
 [code] 
Optional: `export RUSTC_WRAPPER=sccache` to share compilation caches.
### WebAssembly stack size
On `wasm32-unknown-unknown` the Rust stack lives in linear memory **without a guard
page**, so an overflow corrupts memory instead of aborting. solidcore bounds
input-driven recursion, but kernel algorithms (subdivision, intersection, filleting)
still recurse legitimately. Link wasm consumers with a larger stack than the ~1 MB
default, e.g. in the consumer's `.cargo/config.toml`:
 [code] 
## Difftest (Rust vs C++)
On Linux x86_64 with glibc 2.39 or newer and GCC 13 or newer (Ubu