solid123d

This package has moved into scad123d

solid123d is now the geometry engine inside scad123d rather than a separate distribution. 0.9.1 was its last release with code in it; this one only carries this notice. It is not going anywhere — it stays installable, and anything pinned to it keeps working — but new work happens in the merged package.

pip install scad123d

gives you both import scad123d and import solid123d, with the same API this package had. scad123d converts OpenSCAD models to STEP; solid123d is the geometry engine underneath it — OpenSCAD's semantics on build123d — usable on its own if you're writing SolidPython rather than converting .scad files.

They were split because solid123d has no OpenSCAD dependency and that boundary is worth keeping. It still is, and it still holds — it is enforced by imports now rather than by two repositories, which stopped being worth the release-ordering cost of changing both at once.

A bridge that runs SolidPython (OpenSCAD-style) code on the build123d BRep kernel. Change one import and existing code produces native build123d shapes instead of OpenSCAD source.

# before
from solid import translate, cube, scad_render_to_file

# after
from solid123d import translate, cube, scad_render_to_file

c = translate([10, 0, 0])(cube(10, center=True))
scad_render_to_file(c, filename="c.scad")  # writes c.step (real BRep geometry)

Every object returned is a plain build123d Shape, so bridged code mixes freely with native build123d — the intended migration path:

from build123d import fillet
from solid123d import cube

part = cube(20, center=True)
part = fillet(part.edges(), radius=2)  # native build123d from here on

Supported

• Primitives: cube, sphere, cylinder (incl. r1/r2 cones, d/d1/d2), square, circle, polygon (incl. paths holes), text

• Font resolution: text(font=...) matches fonts by family name the way fontconfig/OpenSCAD does (incl. "Family:style=Style" syntax), by scanning system font directories with fontTools and handing build123d the resolved file path. This fixes fonts with nonstandard subfamilies (e.g. "Academy Engraved LET", whose subfamily "Plain" makes OCCT's own lookup fall back to Arial).

• Transforms (callable style, translate(v)(obj, ...)): translate, rotate (vector, scalar, and axis-angle forms with OpenSCAD ordering), scale, mirror, resize, color, offset

• Booleans: union(), difference(), intersection() — plus native operators a + b, a - b, a & b

• minkowski() with a ball — minkowski()(A, sphere(r)) / minkowski()(A, circle(r)), by far the most common use of minkowski() (rounding a shape), is computed exactly as offset(A, r) — including a ball tessellated as an explicit polyhedron(), the way BOSL2 builds its rounding kernels. Exact BRep geometry, not an approximation.

• hull(), for every case with a closed-form answer — all computed as exact BRep geometry: equal-radius spheres in any arrangement (including the collinear capsule/slot idiom), equal-radius parallel cylinders sharing a span (the "rounded box from corner posts" idiom), exactly two spheres of any radii (two spherical caps sewn to their external tangent cone; overlap and containment handled), exactly two 2D circles (the keyhole/slot idiom), and any collection of purely flat-faced children (cubes, polyhedron()s, extruded polygons — the hull is exactly the convex hull of their vertices). See Known differences for what still raises.

• polyhedron(points, faces) — explicit point/face solids, with OpenSCAD's tolerance for either winding direction.

• color() that survives into STEP export — colors live on bodies, never on groups. Every operation keeps one invariant: the result is a set of non-overlapping bodies, each with at most one resolved color. Precedence for contested material: an assigned color beats uncolored material, and between two assigned colors the later operand wins — so a red sphere stays whole under a later uncolored cube, while a later blue cube would take the shared material. union() partitions overlapping colored children accordingly, difference() cuts each colored body on its own and keeps its color (cutter colors are ignored), intersection() gives shared material the later operand's color when it has one, and color() fills whatever is still uncolored without repainting explicit inner colors. scale()/mirror() carry colors and structure through. hull() and minkowski() create new material, so they warn and drop the children's colors; an enclosing color() still applies. Every part is labeled with the color name you wrote (color("SteelBlue") → steelblue, numeric colors get the CSS name or hex). export_step(shape, path) writes one colored STEP product per body under your own grouping; export_step(..., group_by_color=True) buckets the bodies under one group per color instead (plus uncolored), which is what slicers read. Uncolored models are entirely unaffected.

• a * b intersection is not overloaded; use a & b or intersection()(a, b).

• hull() raises NotImplementedError outside the closed-form cases above — notably three or more spheres of unequal radii (their hull needs planes tangent to three spheres at once, a genuinely harder object) and mixtures of curved children. Model those explicitly (loft/sweep), or import through scad123d, which renders unsupported hulls as meshes via OpenSCAD.

• minkowski() raises NotImplementedError except for the ball cases above; general Minkowski sums have no BRep equivalent. Use offset() or fillet/chamfer on the build123d object instead.

• linear_extrude(twist=...) raises NotImplementedError.

• $fn/segments arguments are accepted and ignored — BRep curves are exact.

• scad_render() (source string) raises NotImplementedError.

• OpenSCAD modifiers (#, %, !) and import()/surface()/projection() are not implemented.

Development

just test    # or: uv run pytest