build123d VS CascadeStudio

I haven't tried Zoo (really, unique naming isn't THAT hard...), and afict I can't see the code so I prob never will, but I got perfect results with build123d recently. Admittedly it's python to cad, not AI text to cad, but it was a joy to use after getting over the initial learning curve. The users and devs hang out on the slack chan and are very helpful.

https://github.com/gumyr/build123d

Yes, absolutely.

It was where GIMP still is now, for artists.

It's definitely been idiosyncratic (if not solipsistic). And it still [0] has a core flaw that is being mitigated.

OpenSCAD is actually very limited in ways that don't become obvious until you get into a bRep CAD system at least. But it's how I also got into CAD.

If you like it, you might find Build123D [1] interesting: this is a Python (and very pythonic) environment built around the same kernel as FreeCAD.

I wanted to know there was at least something I'd be able to use for my own ideas, and the fact that OpenSCAD exists is definitely a blessing.

But I got from OpenSCAD to FreeCAD and I am very glad of it; it's an amazingly capable bit of software once you get past the pain (in the same way Blender is, I gather).

GIMP is not an amazingly capable bit of software for designers. It's broken and hobbled.

[0] the topological naming problem: being corrected in the core distribution at the moment as they head to 1.0

[1] https://github.com/gumyr/build123d

https://github.com/gumyr/build123d :

> Build123d is a python-based, parametric, boundary representation (BREP) modeling framework for 2D and 3D CAD. It's built on the Open Cascade geometric kernel and allows for the creation of complex models using a simple and intuitive python syntax. Build123d can be used to create models for 3D printing, CNC machining, laser cutting, and other manufacturing processes. Models can be exported to a wide variety of popular CAD tools such as FreeCAD and SolidWorks.

> Build123d could be considered as an evolution of CadQuery where the somewhat restrictive Fluent API (method chaining) is replaced with stateful context managers* - e.g. with blocks - thus enabling the full python toolbox: for loops, references to objects, object sorting and filtering, etc.*

"Build123d: A Python CAD programming library" (2023) https://news.ycombinator.com/item?id=37576296

BREP: Boundary representation: https://en.wikipedia.org/wiki/Boundary_representation

Manim, Blender, PhysX, o3de, [FEM, CFD, [thermal, fluidic,] engineering]: https://github.com/ManimCommunity/manim/issues/3362

NURBS: Non-Uniform Rational B-Splines: https://en.wikipedia.org/wiki/Non-uniform_rational_B-spline

NURBS for COMPAS: https://github.com/gramaziokohler/compas_nurbs :

> This package is inspired by the NURBS-Python package, however uses a NumPy-based backend for better performance.

> Curve, and Surface are non-uniform non-rational B-Spline geometries (NUBS), RationalCurve, and RationalSurface are non-uniform rational B-Spline Geometries (NURBS). They all built upon the class BSpline. Coordinates have to be in 3D space (x, y, z)

test_curve.py, test_surface.py

https://github.com/compas-dev

compas_rhino, compas_blender

Blender docs > Modeling Surfaces; NURBs implementation, limits, challenges:

https://github.com/gumyr/build123d/blob/dev/examples/heat_ex...

github

OCCT is definitely difficult.

I am almost as far as you can get from an expert but:

For example the TNP issue derives from OCCT (or something in the stack close to it, I am not exactly sure) not really handling face naming at all.

So if you want to avoid topological naming issues (which is a hard problem in CAD), you apparently have to do some work to track before and after and reconstruct your face naming.

https://wiki.freecad.org/Topological_naming_problem

https://forum.freecad.org/viewtopic.php?t=27278

Then there are various fairly entrenched issues to do with filleting and chamfering. Basically, both these operations will fail (in FreeCAD at least, but it's OCCT at "fault") if a chamfer or fillet would completely consume an existing edge. (It also sometimes creates impossible objects when filleting, or used to).

Booleans can be slow.

And more generally, it seems if you track the FreeCAD project that OCCT can be inscrutable when things fail; error messages aren't the greatest etc.

The flip side of OpenCascade is that it seems to be highly portable and has for example been compiled to JS with Emscripten for this astonishing thing:

https://zalo.github.io/CascadeStudio/

It's a monumental open source project, for sure, and it's definitely not nothing that we have an open source CAD kernel; these are projects that perhaps have to extend beyond the working life of an individual developer if they are to be stable. And there are loads of projects built around it.

If you haven't seen it you may want to check out https://github.com/zalo/CascadeStudio

From what I see, it is exposing the OpenCascade base commands directly, versus your completely new DSL, but you might be interested in a way to implement your DSL on top of such an interface such as this which takes out a lot of the extra work of having a rendering interface, exports, etc, maybe.

It's nowhere near ready for primetime, but you should take a look at CascadeStudio (https://github.com/zalo/CascadeStudio)

FreeCAD is GUI-based though, not code-first like Fornjot. A better comparison would be CadQuery (https://cadquery.readthedocs.io/en/latest/intro.html) or Cascade Studio (https://zalo.github.io/CascadeStudio/), both of which are code-first and based on the same CAD kernel as FreeCAD.

It is an actual example from CascadeStudio, but I haven't looked into it enough to know how what actually happens under the hood, but I assume the following: