Comment by YuechenLi | Hacker News Reader

Comment by YuechenLi | Hacker News Reader

Parent Full thread

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.

Great resources thank you!

You can find NURBs fitting in decades old textbooks (such as "The NURBs book"), but you have to be aware that this is an approximation problem as the only exact fitting is the one where the output is the input.

Also prone to robustness and quality issues. You're better off outputing a BREP directly.

Reply on news.ycombinator.com