# The OpenSCAD Plugin That Never Calls OpenSCAD

Flexible for OpenSCAD renders and evaluates CSG models entirely in the browser engine, without ever calling the real OpenSCAD binary.


A CSG model is a recipe, not a shape. You do not draw the union of a cube and a cylinder, you write down “union of this cube and this cylinder” and something else has to work out what solid that actually describes. That something is a boolean-operator tree sitting over a small set of primitives - cubes, cylinders, spheres - and the entire discipline of constructive solid geometry is really just different answers to one question: how do you evaluate that tree into an actual mesh you can look at.
OpenSCAD answers it by calling into CGAL, the Computational Geometry Algorithms Library, which does exact algebraic boolean operations - genuinely correct results, at the cost of being slow enough that anyone who has modeled anything nontrivial in OpenSCAD has sat through a render.
So when I built Flexible for OpenSCAD, the obvious plan was to shell out to the real OpenSCAD binary for the preview and just make the round trip faster. I did not do that. The live preview never touches an OpenSCAD executable at all.
Evaluating the tree without CGAL There is a second, older way to do boolean operations on meshes, and it is the one most three.js CSG libraries use: binary space partitioning. A BSP tree recursively splits a mesh’s polygons against dividing planes, sorting pieces into front and back of each cut, until every polygon sits cleanly on one side of every plane it has been tested against. Once two meshes are represented that way, union, difference and intersection become tree operations - clip one tree against the other, invert where you need to subtract, reassemble the surviving polygons. It is not exact the way CGAL is exact. It is numeric, working in floating point with a small epsilon for “close enough to coplanar,” and it runs entirely in JavaScript, in the same WebGL context that is already rendering the model.
That is what Flexible for OpenSCAD’s live preview actually is. It parses your .scad file, evaluates the primitive and boolean tree directly, renders it with three.js, and does the CSG itself with a built-in engine based on Evan Wallace’s csg.js, adapted for ES modules and three.js’s buffer geometry. STL export runs through the same engine. No OpenSCAD executable required for either. If you have OpenSCAD installed, the plugin will still use it for the harder export formats - 3MF, AMF, DXF, SVG, PNG - and as a fallback renderer for files the built-in evaluator cannot handle, but for the everyday loop of edit, save, look at the model, it never leaves the IDE.
Running the tree evaluator in-process instead of shelling out is also what makes the rest of the preview possible. The animation timeline drives OpenSCAD’s $t variable and re-evaluates the model on every frame. The measurement and cross-section tools need to query the mesh interactively as you drag. None of that works if every frame means spawning an external process and waiting for it to write a file to disk before you can read it back.
Where the shortcut shows The first time I got the union operator working, two overlapping cubes produced a shape with a stray triangle floating a fraction of a millimeter off the surface. Exactly the coplanar case the textbooks warn about, and exactly as satisfying to finally squash as it sounds.
I am not going to pretend a few hundred lines of BSP splitting is CGAL. It is not, and the places where that gap shows up are predictable once you know how BSP trees fail. Coplanar or near-coplanar faces are the classic case - two polygons sitting close enough to the same plane that the epsilon check cannot confidently sort them, which can leave a sliver of leftover geometry or a crack where two “solid” pieces should meet exactly. Very large or deeply nested boolean trees are the other one: every cut recursively re-splits polygons, so a model with a few thousand primitives chained through nested differences gets slow and can shed precision the CGAL kernel would not.
None of that makes the built-in evaluator wrong for what it is for. Most of what people actually model - brackets, enclosures, mounts, the kind of parametric part you iterate on twenty times before it is right - stays comfortably inside where BSP splitting holds up, and you get to see it update the instant you save instead of waiting on a render queue. It stops being enough exactly where OpenSCAD’s own choice of CGAL starts paying for itself: geometry precise enough, or large enough, that floating-point splitting is the wrong tool. That is what the OpenSCAD fallback is still there for.