CascadeStudio VS oce

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:

Have a look at https://github.com/tpaviot/oce/ Not sure if there is a go wrapper for it. There is a python library wrapping opencascade already.

Some parts of the 3MF are actually good. I like the spec documents winding order of the meshes. The format includes units, and these optional 4x4 transformation matrices — both are useful.

As for need of the new formats, for one, modern CAD formats are insanely complex. These IGES/STEP/BREP files require many megabytes of very complicated code to deal with, such as this library https://github.com/tpaviot/oce These formats may even contain proprietary extensions. Also, they need non-trivial processing power to handle. Many people wouldn’t want a Core i7 with gigabytes of RAM in their 3D printers, inflates hardware cost and software complexity.

Besides, we now have high-resolution 3D scanners, and CAE software which algorithmically optimizes models by running numerical simulations. They both output triangle meshes instead of CAD files. Scanners often output point clouds one can convert into triangles, but hard to convert into CAD formats.

I just don’t like the 3MF implementation too much. XML is fine for kilobytes of data, but not many megabytes. If I would be designing that format, I would probably made it binary. Maybe EBML https://en.wikipedia.org/wiki/Extensible_Binary_Meta_Languag... would work for that; it does fine for MKV videos, which is also a huge pile of structured data with non-trivial performance constraints for producers and especially parsers.

Another minor thing, it was not the best idea to make name start with a digit. Most programming languages forbid identifiers like that for their classes / functions / namespaces / modules.

Cadquery uses opencascade under the hood. I think your best bet is to open an issue and ask: https://github.com/tpaviot/oce