Feature request: STEP export

[PetteriAimonen]

If I understand correctly, the internal data model has true curves, but currently supported output formats only include triangulated data.

Especially for CNC use, a true STEP export with curves would be great!

BTW. Congrats for very promising state of this software already in this early state.

[hrgdavor]

feature requests already :)

[drwho495]

I think this could be done with the current geometric system, but not in the same way as in other geometry libraries; the thing is that it is not really boundary representation (unless I misunderstand some of the code I've read). Each edge is a group of meshes compounded together, so to the user it looks like precise geometry, but in reality it still uses good old meshes (this doesn't really matter because libraries like OpenCASCADE and ParaSolid that have "real" brep have tolerances). If you want STEP export, everything needs to be described as a NURBS surface or edge, which means that a "curved" edge in the program will need to be converted to a real "precise" edge.

If you are willing to import OpenCASCADE in brep.io, then this issue is rather trivial. First you loop through each face in a model, and you check to see if the edges in the face are linear. If they are, then you port those edges to OpenCASCADE and recreate the face. If an edge isn't linear, then it is made up of a set of points, which you can use to create a spline/arc. You would do that for each curved edge until you have a recreated wire to recreate the face.

Doing this without OpenCASCADE would NOT be trivial. The format is very complicated (not even OpenCASCADE or ParaSolid can export it and import it properly sometimes), so you would need to make a NURBS implementation in brep.io that can create splines and faces, AND you would need to properly export those NURBS to a usable STEP file. The last part is very hard; not even SolveSpace (an open-source program with its own custom NURBS kernel) could do it properly for 16 years. They still can't import STEP files either.

[hrgdavor]

Also ask yourself, do you really need curves ?
If modeling is allowed to be done in a lower poly count, and export in a more detailed mesh, could be usable (you have to have tollerance of some king IRL )

[drwho495]

Also ask yourself, do you really need curves ?
If modeling is allowed to be done in a lower poly count, and export in a more detailed mesh, could be usable (you have to have tollerance of some king IRL )

Curves are totally necessary for cnc machining, but it should be easy to implement with open cascade

[mmiscool]

It looks like step AP242 Edition 2 supports the following entity types:
triangulated_face_set
polygonal_face_set
tessellated_shape_representation

So it might be possible to generate a usable step file with the data as is without the full NURBS representation.

It would be interesting to try and figure out how to try and approximate the NURBS surfaces from the meshes as they are now. Unfortunately NURBS intersections are considerably more difficult than the mesh intersections especially when trying to maintain manifolds at the edges between faces as the intersection has to be calculated in the UV space of both faces and guarantee identical points are produced when these NURBS curves are tessellated back to the 3D world out of the UV space of the faces.

I have been trying to avoid using OpenCASCADE in this project but there is no reason it would not be possible to make use of it in the future. I really want to iron out the classes and methods using the current approach and possibly in the future build an alternative drop in implementation that uses OpenCASCADE but wrapped with the same API used for this purely mesh based kernel and exposed in the BREP class. https://github.com/mmiscool/BREP/blob/master/src/BREP/BREP.js

[drwho495]

It looks like step AP242 Edition 2 supports the following entity types: triangulated_face_set polygonal_face_set tessellated_shape_representation

So it might be possible to generate a usable step file with the data as is without the full NURBS representation.

It would be interesting to try and figure out how to try and approximate the NURBS surfaces from the meshes as they are now. Unfortunately NURBS intersections are considerably more difficult than the mesh intersections especially when trying to maintain manifolds at the edges between faces as the intersection has to be calculated in the UV space of both faces and guarantee identical points are produced when these NURBS curves are tessellated back to the 3D world out of the UV space of the faces.

I have been trying to avoid using OpenCASCADE in this project but there is no reason it would not be possible to make use of it in the future. I really want to iron out the classes and methods using the current approach and possibly in the future build an alternative drop in implementation that uses OpenCASCADE but wrapped with the same API used for this purely mesh based kernel and exposed in the BREP class. https://github.com/mmiscool/BREP/blob/master/src/BREP/BREP.js

I think PythonOpenScad uses the entity types you described (it does have STEP export with manifold, so that's why I assume that this is the case), but it is not supported well by slicers like OrcaSlicer or Cura, so it wouldn't be very usable. The manifold issue will be tricky, and some clever tricks will probably need to be used to anchor the start and ends of edges in place so the faces are setup properly.

OpenCASCADE would only need to be used for exporting (and importing, which should be easier to implement since you can mesh an edge and just create a brep.io edge from the resulting mesh group). Using the current kernel would be better for speed, reliability, STL importing, and TopoNaming (OpenCASCADE can do TopoNaming, of course; it's just not nearly as easy as what Manifold offers from what I have seen with that API. I haven't used OCAF in my FreeCAD Toponaming development, so maybe that is better).

[mmiscool]

I just searched the PythonOpenScad repo to see if I could find the step related code you mentioned. Did not find anything searching the repo for "step".
https://github.com/search?q=repo%3Aowebeeone%2Fpythonopenscad%20step&type=code

If you could find a link for the thing you were talking about there it would be helpful.

[drwho495]

I just searched the PythonOpenScad repo to see if I could find the step related code you mentioned. Did not find anything searching the repo for "step". https://github.com/search?q=repo%3Aowebeeone%2Fpythonopenscad%20step&type=code

If you could find a link for the thing you were talking about there it would be helpful.

Here is the button, and here is an exported example.

(remove the .txt extension to use)

csg.step.txt

FreeCAD and OrcaSlicer cannot import that step file.
I was able to get the AutoDesk online viewer to work (the shape it imported was not manifold though)

[PetteriAimonen]

Yeah, true NURBS STEP is what I meant. STL to triangulated STEP conversion itself is easy to do with other tools.

It is possible to re-interpret curves from triangulated STL, but there aren't any open source software that does it well. And it always causes some inaccuracy in e.g. hole sizes.

[drwho495]

Yeah, true NURBS STEP is what I meant. STL to triangulated STEP conversion itself is easy to do with other tools.

It is possible to re-interpret curves from triangulated STL, but there aren't any open source software that does it well. And it always causes some inaccuracy in e.g. hole sizes.

Luckily we have more access to the proper dimensions than what you would have with an STL file so we can probably fix that in multiple circumstances.

[X-Ryl669]

If you are willing to import OpenCASCADE in brep.io, then this issue is rather trivial

I don't think it's true. It's clearly not trivial to convert meshes to curves and OpenCASCADE make it even harder.
Sure, if you need to convert a cube, you're golden, but as soon as you have fillets, tangent constraints and so on, you're out of luck.

In fact, it basic idea of using NURBS for any 3D manifold shape does not work (it's not stable mathematically) so you're always end up with tricks to overcome the mathematical limits. That's why you have so many "bugs" in OpenCASCADE when you're doing fillet or NURBS/NURBS intersections.

I've made a tool that's doing almost exactly what you're proposing, that is, deduce curve edges and faces from meshes so I've been thinking a lot about how to perform these "sampled 3d mesh to mathematical surface" conversions.

Technically, I wonder if it wouldn't be easier to convert first the 3D mesh to a SDF (signed distance field) and then sample the field to find out a curve that has the right characteristics (like tangency/normals and so on). This would avoid many mathematical issues and precision errors, giving an very good approximation of the intended object, instead of try to solve impossible constraint from heuristics.

[hrgdavor]

I wonder who actualy needs the curves so badly, that mesh with a specific tolerance is not enough. I can imagine making procedural shapes, that can produse both a mesh and coresponding curves that could be then be used by either a mesh tool, SETEP, or hybrid like brep.io ... but after you start doing stuff to it in either tool, it becomes increasingly difficult to maintain compatibility.

[PetteriAimonen]

@hrgdavor For example, if you try to mill a round hole on a CNC, the facetet approximation results in error in the diameter. True, it gets smaller the more faces you add, but it's far from ideal. STEP is also easier to use in CAM software and can be edited in other programs.

But yeah, if curves is not something the brep's internal data supports, then STEP export is not worth doing. I'm still unclear on how it works internally, as in the GUI it appears to have real curves.

[X-Ryl669]

@hrgdavor For example, if you try to mill a round hole on a CNC, the facetet approximation results in error in the diameter.

I don't think so, unless your mesh tesselation is too high. You need to tesselate the mesh at the tolerance level of your machine. Think about it, no cartesian machine can move following a curve, it has to be approximated at some level. When you have a curve / arc in your GCode, it's the GCode reader/processor that make segment out of it (and it does it right because it knows the tolerance of your machine like the actual minimal length of a physical step, so it can choose the tesselation level).

If the input is a mesh, then you need to generate the mesh with the same tesselation level, it won't be distinguishable. However, that implies that you know this physical step size and set in the CAD software, which people don't usually do, it easier to keep the Arc in the GCode and let the processor handle it.

[mmiscool]

@X-Ryl669
I took a peak at your thing
https://blog.cyril.by/user/pages/03.software/15.parametizer/index.html

and found it very interesting. Do you have the code up on github some where? It looks like it is doing a good job of face extraction and converting geometry made of line segments in to proper curves.