At Last: The End of STL Is In Sight

There have been a few developments recently that have brought me to the view that STL file format will slide away quietly.

STL has always been a highly problematic format, but at the same time has been used almost ubiquitously in 3D printing. Now there seems to be a crack in that standard that ultimately should kill STL forever.

What is STL? It’s a 3D model format that uses the “mesh” principle. To represent a 3D object, a mesh of triangles is defined overlaying the surface of the object. STL is like a “skin” made entirely of triangles. The file format is simply groups of numbers representing the three-dimensional location in space of each of the triangle’s three corners. An example:

 facet normal -0.189553067088 0.977301478386 0.0946121066809

    outer loop

      vertex -9.78547859192 -9.21082210541 0.277236670256

      vertex -9.4548368454 -9.27194213867 0.335449486971

      vertex -9.40421581268 -8.9552898407 0.375922739506

    endloop

  endfacet

  facet normal -0.16579669714 0.977534234524 0.130147337914

    outer loop

      vertex -9.40421581268 -8.9552898407 0.375922739506

      vertex -9.80759620667 -8.79104614258 0.329373627901

      vertex -9.78547859192 -9.21082210541 0.277236670256

    endloop

  endfacet

And so on, for sometimes hundreds of thousands of triangles.

You’d think this is an OK approach, but it is most definitely not. There are numerous possible problems that can happen with this format design, including:

• “Holes” where a triangle is missing

• Stray triangles not attached to the rest of the “skin”

• Reversed triangles where the inside is outside

• Ambigious results when triangles appear inside an enclosed shape

And more.

All of these are entirely possible and seen daily. These format problems are why we often need to “repair” our 3D models before submitting them for 3D printing.

And that submission is usually to a slicing program, which decomposes the 3D skin represented by the STL into slices, each of which becomes a toolpath for the printer to follow.

This makes sense, as STL was originally designed for this purpose way back when the first 3D printers were devised. But as we reported recently, some companies are skipping over STL, like Velo3D has done, and hinted at in an exploratory video.

Their system — and in our understanding several other 3D printer manufacturers’ — uses the base CAD model to generate machine toolpaths, and not using an intermediate format such as STL.

I believe this approach will become the standard. Why? Because the CAD model can include all kinds of information that could be very useful to a slicing program. For example, a CAD model could include information about expected mechanical stresses and their direction. A slicing program could sense that data and adjust its slicing approach to provide an optimum toolpath that accounts for those stresses.

An STL approach cannot do this because all information beyond the exterior skin is lost when the CAD file is exported to STL format.

Why do we want to lose important information?

Why wouldn’t we try to keep it and make good use of it?

My thinking is that future 3D print slicing systems will work with CAD files directly as a standard approach. They will quickly develop extremely powerful algorithms for producing highly optimal parts that could never even be attempted with standard STL-based slicers.

As a result, we could see a migration of users toward CAD-powered slicing systems. This would force the slicer market to quickly tip over to the CAD approach. Thus, STL will die, and I will be happy.

I think we will first see examples of the CAD-slicing approach in well-funded large 3D printer manufacturing companies, where they seek an edge on the competition. This will eventually cause other manufacturers to come along with similar strategies soon after.

It also has implications on generic slicing systems such as Simplify3D, the new Pathio and open source slicers such as Cura or Slic3r, all of which are currently driven by STL. They may have to switch to a CAD approach.

It turns out that Simplify3D is in the midst of a massive rewrite of their product to be released as Version 5 sometime this year. Could they be engineering a CAD-input option? If so, that would be very strategic for them.

It’s likely that Cura could eventually switch modes as it is the heart of Ultimaker’s strategy. If Ultimaker wishes to continue to provide optimal prints for their clients, they will eventually have to make Cura deal with CAD data. And since many third parties use Cura as their slicer, they may be able to ride along for that benefit.

The one that I worry about is Slic3r, which doesn’t have a big name, or a motivated and well-funded backer. It’s an open source project, and some companies, like Prusa Research, make extended versions of it. It’s possible Prusa Research may provide the resources to make such a switch, but that may happen later than the others.

This sounds like a lot of turmoil, and I suspect it will be. But as they say, “no pain, no gain”. If slicers truly did accept CAD input, we could see a revolution in the quality of 3D prints going forward.

And the death of STL.