Oh, since this came up, for people who like code CAD and want to try something more powerful than OpenSCAD:
https://github.com/yuechen-li-dev/Aetheris/
Not an OpenCascade wrapper, it's based off my own experimental BREP geometry kernel. So, fillets/chamfers work, booleans works fairly robustly, surfacing, sheet metal, etc all works decently, it exports STEP AP242 by default.
Haven't had time to get the AIs to write a more up to date documentation and polish the language server. Not the easiest thing to use right now, so, using it through Codex/Claude Code or CLI is probably the easiest way to get started.
Still working on the webUI currently, in case someone want to DIY the UI. Note that the WASM compilation path is still unoptimized and way slower than the RyuJIT C# compilation though.
Not even two years ago writing your own BREP kernel was considered to be out of reach for even the most determined dedicated hardcore engineering teams that weren't extremely well funded. Now, it seems tractable and may finally get us out of the dependence on proprietary kernels that has plagued this industry for decades.
Yeah, I know. I started this project earlier this year because of my own frustration with the software ecosystem and that the major CAD vendors is charging thousands of dollar to add STEP 242 support and because of proprietary lock-in and locking everything behind cloud, and was trying to see if I can accomplish this with AI.
I'm not going to pretend this is easy: I actually quit multiple times for this project because I ran into the same walls that everyone else ran to: arbitrary 3D boolean operations is HARD,(Surprisingly, I actually didn't have that much trouble with fillets/chamfers because I kept them pretty bounded) and the approach I've finally taken to solve it is pretty insane. Essentially, the final architecture is more like "LLVM for 3D objects" compiler stack than it is traditional BREP kernel. Would love to talk about the technical deep dives if people want to hear it.
Also, feel free to write UI wrappers around it, because I'm pretty bad at UI design myself.
Given modern capabilities how hard would it be to make a really high quality stl to STEP converter that works well on CAD models that have been converted to STL?
It doesn’t need to be perfect on edge cases just translate back “reasonable” models.
Should be something that is fairly easy to eval etc.
Near impossible to do it robustly without AI, since a mesh is a blob of triangles and vertices, it doesn't really know if something is a "face" or an "edge", and mesh STL -> BREP STEP is akin to decompilation from binary than it is a simple translation. So, the most robust approach is to get a human/LLM to reconstruct the STEP file from the STL/OBJ/glTF file with a BREP kernel.
I wish there was an easier way, but I've spent weeks during the course of the project working on and failing to solve a similar problem (SDF to BREP) and concluded finally that there just isn't an easier way to do this fully automated without AI.
You can ask your LLM to try it with one of the OCCT wrappers or with my thing, I think Aetheris is slightly better because we added more STEP diagnostic tools like ray query depth detection and SVG sectional view during the course of development.
https://yepher.com/tools/mesh-slicer
STEP is a weird standard and one of the reasons it's weird is because it allows you to store tessellated mesh in the file with no BREP. Wrapping an STL mesh inside a STEP container is trivial, but reconstructing a BREP from the mesh is daunting.
Here're are some SIGGRAPH 2026 papers attempting BREP recovery, if you are interested. None of their automated approaches seem to work reliably, and they can only recover generic NURBS instead of analytical geometries like circles/cones/torii, etc.
https://github.com/AutodeskAILab/DualBrep https://github.com/yilinliu77/Brepler https://rilpraa0110.github.io/Img2CADSeq/
Yeah - this is BREP-recovery using RANSAC shapes, not tesselated-mesh-in-STEP.
What is wrong with OpenCascade? Why not use that?