All writing
7 min read

Running a C++ Geometry Kernel in the Browser with WebAssembly

WebAssemblyC++Three.jsCAD

Building a cloud CAD engine raises an awkward question: CAD math is heavy, precise, C++ territory — but the product has to run in a browser tab with no local engineering software installed. For the Cloud 3D CAD Engine at Applied Engineering Solutions, the answer was to compile a C++ geometry kernel to WebAssembly and let JavaScript handle only what it is good at.

The split: kernel vs. interaction

The architecture draws a hard line:

  • The C++ kernel (compiled to WebAssembly) owns geometry: boolean operations, tessellation, and the exact math that has to be correct and fast.
  • The Three.js layer owns interaction and rendering: cameras, selection, gizmos, and pushing triangles to the GPU.

Keeping these separated means the expensive, accuracy-critical work runs at near-native speed in WASM, while the UI stays responsive in regular JavaScript.

Why WebAssembly and not "just rewrite it in JS"

Two reasons. First, performance: geometry kernels do enormous amounts of floating-point work, and WASM runs it far closer to native than JS can. Second, trust: a mature C++ kernel already encodes years of correct CAD behavior. Recompiling it is far safer than reimplementing that math from scratch and hoping the edge cases match.

The real challenge: the boundary

The hard part of WASM is rarely the compute — it is the boundary between WASM and JS. Crossing it constantly, or copying large buffers back and forth, will erase every performance gain you came for. What worked:

  • Move data in bulk, not per call. Hand the kernel a whole operation and get a whole result back, instead of chatting across the boundary thousands of times.
  • Share typed-array memory for the big geometry buffers so the GPU-bound Three.js side can read tessellation output without re-copying it.
  • Stream feedback for long operations so the user sees progress instead of a frozen tab.

Handling large assemblies

Large CAD files are not just "more triangles" — they break naive rendering. The Three.js layer had to be heavily optimized for big assemblies, and large files and generated assets lived in a scalable object-storage backend rather than being shipped to the client all at once.

The takeaway

WebAssembly let us deliver desktop-class CAD workflows over the web, but the engineering effort was less about the compile step and more about respecting the WASM/JS boundary and designing data flow around it. Get that wrong and WASM is slow; get it right and the browser stops being a limitation.