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.

▲

15155 an hour ago | parent [-]

https://yepher.com/tools/mesh-slicer

▲

YuechenLi 23 minutes ago | parent [-]

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/

	▲	15155 21 minutes ago \| parent [-]
		Yeah - this is BREP-recovery using RANSAC shapes, not tesselated-mesh-in-STEP.