brepkit

Solid modeling kernel for Rust and WebAssembly.

Architecture · Performance · Getting Started · Known Limitations · Stability · Contributing

One exact-geometry engine, from Rust and from JavaScript. Cut a solid, measure it, export it.

use brepkit_operations::primitives::{make_box, make_cylinder};
use brepkit_operations::boolean::{boolean, BooleanOp};
use brepkit_operations::measure::solid_volume;
use brepkit_io::step::write_step;
use brepkit_topology::Topology;

let mut topo = Topology::new();

// Primitives are anchored at the origin, so this cylinder rounds off the
// block's corner. Use `transform_solid` to place it somewhere else.
let block = make_box(&mut topo, 30.0, 20.0, 10.0)?;
let cutter = make_cylinder(&mut topo, 5.0, 15.0)?;
let notched = boolean(&mut topo, BooleanOp::Cut, block, cutter)?;

// Measure and export
let vol = solid_volume(&topo, notched, 0.1)?;
let step = write_step(&topo, &[notched])?;

import { BrepKernel } from 'brepkit-wasm';

const kernel = new BrepKernel();

// Primitives are anchored at the origin, so this cylinder rounds off the
// block's corner. Use `transformSolid` to place it somewhere else.
const block = kernel.makeBox(30, 20, 10);
const cutter = kernel.makeCylinder(5, 15);
const notched = kernel.cut(block, cutter);

// Measure and export
const vol = kernel.volume(notched, 0.1);
const step = kernel.exportStep(notched); // Uint8Array

Why a CAD kernel?

brepkit is a B-Rep solid modeling kernel written from scratch in Rust. It targets WebAssembly, so the same kernel runs in the browser and on the desktop. unsafe is denied by lint, as are unwrap and panic. Every public operation returns a Result.

It grew out of building gridfinitylayouttool.com, where the options for parametric CAD in the browser were proprietary or compiled from large C++ codebases.

The geometry is exact. Booleans run on analytic and NURBS surfaces and keep those surfaces through the operation, so a cylinder stays a cylinder instead of becoming a bag of triangles. That keeps face counts low and round-trips lossless.

Status

brepkit is in active development. Core modeling is solid. Each feature below is marked stable, beta, planned, or experimental, and Known Limitations covers the gaps.

The table below rates features. For API stability per crate, and what the shared 2.x version does and does not promise, see STABILITY.md.

Known Limitations

A few areas are still maturing. Worth knowing before you build on them:

• Boolean fallback. Most booleans run on an exact path that preserves analytic and NURBS surfaces. Hard configurations fall back to a mesh-based boolean: coincident-face contact, coaxial analytic surfaces, razor-thin geometry, or very high face counts. The fallback returns a usable, non-degenerate solid, but it tessellates the curved faces and is not guaranteed watertight.
• Torus booleans. Box-with-torus and coaxial-torus cases work and give correct volumes. General torus-to-torus and torus-with-other-surface intersections have known gaps and may fall back to meshing.
• Non-planar profiles. Loft, sweep, and pipe accept profiles with non-planar surfaces, and close non-planar section boundaries with bilinear caps for four-sided rings (boundaries with more than four edges, or holes on a non-planar section, are not yet supported). Revolve accepts non-planar profile surfaces; a full revolution takes any boundary, but a partial revolution still requires a planar boundary for its caps. The smooth, scaled/guided, and multi-section sweep variants accept non-planar profiles too; only the miter-corner variant still requires planar profiles (its bisector-plane joint faces would otherwise be non-planar).
• IGES is experimental. Export writes planar and NURBS surfaces but skips analytic surfaces and approximates circular and elliptical edges as polylines. Import reconstructs planar placeholder faces only. Use STEP for B-Rep exchange.
• Inertia tensor. Volume, area, bounding box, and center of mass are computed for any solid. A full inertia tensor exists only as closed-form formulas for analytic primitives and is not exposed through the modeling or WASM API.
• Beta subsystems. Feature recognition, assemblies, evolution tracking, and defeaturing work but are still maturing. Defeaturing handles planar faces only.

Scope

brepkit deliberately does not:

• Bundle a viewport into the kernel. The core emits exact geometry and tessellated meshes; camera, lighting, and shading belong to the caller (Three.js and the like). The optional brepkit-render crate provides offscreen wgpu rendering with a face-id buffer, for tests and headless verification, and is not required by any core operation.
• Plan toolpaths or slice. Export STEP, STL, or 3MF and pass the output to a CAM tool or slicer.
• Model with meshes. The kernel operates on exact B-Rep geometry. Subdivision surfaces, polygon meshes, and voxels are out of scope.
• Provide a GUI. brepkit is a library. Building a UI around it, like gridfinitylayouttool.com, is the application's job.
• Simulate physics. Measurement (volume, area, center of mass) is included. Stress analysis, collision detection, and dynamics are not.

Architecture

Layered Cargo workspace. Each crate depends only on the same or lower layers, and CI enforces the boundaries.

Performance

Median times from brepkit-bench, the public repro harness (5 iterations, Node.js, Linux x86_64). WASM is single-threaded. Native benchmarks use criterion. Reproduce the WASM columns yourself:

git clone https://github.com/andymai/brepkit-bench && cd brepkit-bench
npm ci && npm run bench

Every row is output-verified before timing, enforced by the harness itself: it refuses to time a row whose result is wrong. Fuse, chamfer, and box volumes must match exactly; cut, fillet, and multi-boolean volumes are checked against closed-form or cross-kernel values (measured fillet agreement: 0.004%); the intersect result must match the closed-form spherical-octant volume (also pinned by a regression test); exported STEP must re-import to the correct volume. The sphere mesh densities are comparable at equal tolerance (9,800 triangles vs 10,176).

Booleans preserve analytic surfaces, so face counts stay low across chained operations. A nine-step compound boolean settles at 72 faces while a mesh-based approach would reach roughly 7,000. The same holds for blends: a straight edge filleted between two planar faces keeps an exact cylindrical wall rather than a NURBS approximation of one.

The OCCT comparison uses occt-wasm, an OpenCASCADE build compiled to WebAssembly. Both kernels run single-threaded in Node.js through the same brepjs adapter layer, so adapter overhead is identical on both sides. Boolean and exportSTEP rows are timed as batches of ten operations. Speedups are computed from unrounded medians. WASM figures measured 2026-08-07 via brepkit-bench on the released npm packages, exact-pinned in its lockfile: brepkit-wasm 3.0.0, occt-wasm 3.8.3, brepjs 18.120.0. Native figures: cargo bench -p brepkit-operations --bench cad_operations, except the mesh-sphere row, which is measured at the same parameters as the WASM row (tessellate_solid_with_tolerance, deflection 0.01, angular 0.1 rad) via crates/operations/examples/perf_probe.rs — the criterion suite's sphere case meshes per-face and is not comparable.

Data Exchange

STEP preserves exact geometry on round-trip. Analytic surfaces (plane, cylinder, cone, sphere, torus) are written as native STEP surface entities rather than tessellated, and they read back to the same surface types. NURBS surfaces are preserved too, as are line, circle, ellipse, and NURBS edges.

Mesh formats export tessellated triangles. glTF is binary .glb, with no materials or scene graph. IGES is experimental, as described in Known Limitations.

* PLY import is available in the Rust crate but is not yet exposed in the WASM API.

Getting Started

The Rust crates require Rust 1.88 or newer. The WASM package has no toolchain requirement.

As a WASM package

npm install brepkit-wasm

import { BrepKernel } from 'brepkit-wasm';

const kernel = new BrepKernel();
const solid = kernel.makeBox(10, 20, 30);

For a higher-level TypeScript API, see brepjs.

As a Rust dependency

Requires Rust 1.88 or newer.

cargo add brepkit-topology brepkit-operations
cargo add brepkit-io       # optional: STEP, STL, 3MF, OBJ, PLY, glTF

brepkit-operations is the entry point for modeling. It pulls in the geometry, topology, and algorithm crates it needs, so most projects want it plus brepkit-topology, which owns the Topology arena that every operation takes. Add brepkit-io for import and export.

Every crate publishes at the same version from the same commit, so a single minor line works across all of them. To depend on something more specific, the Architecture table lists what each crate does, and STABILITY.md says which are meant to be depended on directly.

Building from source

Requires Rust 1.88 or newer.

cargo build --workspace
cargo test --workspace
cargo clippy --all-targets -- -D warnings
cargo fmt --all

# WASM (with I/O)
cargo build -p brepkit-wasm --target wasm32-unknown-unknown --release

# WASM (smaller, no I/O)
cargo build -p brepkit-wasm --target wasm32-unknown-unknown --release --no-default-features

# API docs
cargo doc --workspace --no-deps --open

Roadmap

Broad directions, no dates.

• Boolean robustness. Harden torus and mixed-surface booleans, and shrink the set of inputs that fall back to meshing.
• Sweep generalization. Extend non-planar profile support to the miter-corner sweep, to section boundaries with more than four edges, and to partial revolutions with non-planar boundaries.
• Parallel tessellation in WASM. Native builds already parallelize per-face meshing. Bring it to the WASM target via threads.
• Assembly metadata. Colors, layers, materials, and PMI for richer data exchange.
• Lossless IGES. Real B-Rep import and analytic-surface export.
• Documentation. API reference, tutorials, and architectural guides.

Projects Using brepkit

• brepjs, CAD modeling for JavaScript.
• Gridfinity Layout Tool, a web-based Gridfinity storage layout generator.

Open a PR to add your project.

License

brepkit is dual-licensed:

• AGPL-3.0-only: free for open-source use. You may use, modify, and redistribute brepkit, provided applications and network services built on it also make their source available under the AGPL.
• Commercial license: for embedding brepkit in proprietary products, sold by Collective Context, LLC. Contact hi@andymai.com.

Versions through 2.129.x were published under MIT OR Apache-2.0 and remain available under those terms. Versions 3.0.0 and later are AGPL-3.0-only with a commercial option.

Contributions require a signed CLA; see CONTRIBUTING.