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.
No one seems to offer collaborative 3D printing modes on dual extrusion devices. We explain why this is the case.