Pathio Users

STEP support in addition to STL

A limitation and frequently a source of deviations in final products is that we always have to go via mesh description of the model to be printed. (And apparently these are also a source of problems in themselves as they can be non-manifold). STEP is a common format for exchanging CAD 3d models which correctly models curves not just triangles. (Think of STL as the equivalent of 2d bitmaps and STEP the equivalent of 2d vector drawings)

Using STEP as an input to the slicing engine can give the following benefits:
Curved surfaces are accurate without potentially creating a huge (high resolution) mesh

Having the slicer know of curves and not just line segments allow the use of controlled arc motion (g2/g3) allowing printers to optimize the accuracy printing curves (generating g2/g3 codes needs to be an option of course as not all printers support these, but having a slicer that can generate them is a motivation for printer makers to support them)

The result is more accurate print results without depending on mesh generation and more compact and potentially better printing gcode (Line segments approximating a curve can suffer from artifacts from accelleration and decellerations between each segment)


I really like the idea, but, if Pathio’s approach assumes a triangle based mesh as a starting point, then the benefits mentioned above might be very hard to realize.

1 Like

The potential of using proper STEP files over stl’s can’t be overlooked. Using stl’s at all is, in my opinion, one of 3D printing biggest blunders, and is holding back the industry as a whole. With true geometry/arcs, correct acceleration/jerk settings, and other novel motion profiles, can be implemented. Imagine faster prints with significantly less ringing, for example.
That would be the last killer feature Pathio needs to make it the undisputed keep king of slicers, especially for high-level enthusiasts and professionals.


I think that STEP file slicing would put Pathio heads and shoulders above the rest,
and would be a step into the future of 3D printing.
most all printer boards support G02/G03 motion.


@sverreb I like this idea a lot. As a former machinist, and always CAD enthusiast, i truly wish that interpolation was properly supported for true arcs. Meshes of sufficient density to describe an arc, to the best of the printer’s capability, require FAR more commands (read as: processing cycles) than an arc command, in any scenario. Since almost all modern variants of 3d printer firmware started life as a GRBL fork or similar cnc firmware, arc commands have likely been supported since day 1. This may have been removed and then returned at points, such as with Marlin.

This is a LOT of work to implement, i suspect. Converting a slicing algorithm from reading meshes, to reading formulaic input, is probably like starting from scratch all over. But i suspect, a halfway point could be reached, where an STEP/IGES input module converts to a (quad) mesh, internally, for slicing purpose. This could add some sort of metadata that describes horizontal mesh edges (thus the quad mesh), specifically with respect to the source being a polyline, spline, or arc. This way the slicer can be prompted to use either a resolution threshold to convert to a true arc command, or not. Perhaps if consecutive mesh edges are defined as arc/spline, and are longer than the threshold (lets say 0.1mm), then an arc command is to be used. This could be tweened from row to row of quad mesh edges.

Another option is to skip the import, and just add arc recognition with a similar resolution threshold. reverse engineering software suites already implement this, for scanning objects, and redefining mesh sections as true CAD objects, such as cylinders, spheroids, etc.

Something else to consider, many CNC toolpath generation software programs do internally convert CAD objects to meshes, for ease of voxel population. Voxels are the way to go for slicers, and i am calling it right now, that the first slicer to properly implement voxel volumes is going to be king of the hill.


Looks like the currently implemented Asset importer does already support STP files:

And the team is already working on importing some “engineering-type file formats” acoording to @james.c here: Support for OBJ Files?


Will there be support for iges as well?
I can convert to step easy enough, but it would save me this extra process.

1 Like

@oscar I don’t see IGES in the asset importer’s supported file format documentation, so I doubt you’ll see it anytime soon.

1 Like

@Ubermeisters you don’t get if you don’t ask. :joy:


What about the 3mf format? What is even the best format anyway?
Take care not to develop an all-purpose solution.

1 Like

3mf is mainly used for color assignment of sub-objects. The source file format within 3MF is still a mesh, and as such, is not really part of this discussion.

1 Like