C++ Solid Porting

This is the first step toward moving the BREP kernel off the JavaScript side and into the custom manifold wasm build.

Current foundation

  • manifold-plus/BrepSolidCore is now compiled into the custom wasm module.
  • It owns:

    • - authoring vertex and triangle buffers - face-name to face-ID mapping - reverse face-ID to face-name mapping - face metadata and edge metadata as JSON blobs

  • It can now ingest/export full Solid authoring snapshots and run bakeTransform

    • over the vertex buffer on the C++ side.

  • It now also runs weldVerticesByEpsilon and pushFace on the C++ side.
  • src/BREP/CppSolidCore.js provides the JS bridge layer used by tests and future API adaptation work.
  • Migrated methods now require the custom local manifold build; they do not silently

fall back to the old JS implementation.

Why this boundary

The current Solid implementation mixes several concerns:

  • authoring-state ownership
  • face-ID reservation and face-tag preservation
  • metadata storage and renaming
  • heavy geometry cleanup and transform work
  • manifold construction and boolean reconstruction
  • visualization-only extraction

The first thing to move is the authoring-state owner, because every later expensive operation depends on that state staying canonical in one place.

Next phases

  1. Move JS authoring helpers into BrepSolidCore

- _key - _getPointIndex - _getOrCreateID - addTriangle - metadata set/get

  1. Continue moving bulk authoring transforms into BrepSolidCore

- bakeTransform is now running in C++ via the bridge - pushFace is now running in C++ via the bridge - weld-by-epsilon is now running in C++ via the bridge - next targets: mirror and cleanup/remesh passes

  1. Move mesh/manifold rebuild work into BrepSolidCore

- winding correction - weld / epsilon handling - _manifoldize - boolean result reconstruction

  1. Move expensive geometry transforms and cleanup

- mirrorAcrossPlane - remesh / degenerate cleanup / internal-triangle removal

  1. Keep visualization in JS

- THREE.Group - scene objects - material assignment - conversion of kernel state into renderable meshes/edges

Practical rule

Anything that mutates or scans triangle/vertex buffers at scale should migrate into C++. Anything that exists only to build scene objects for three.js should stay on the JS side.