We’ve all been there. You find that cool cat model on Thingiverse — we won’t judge. You download the STL, all ready to watch the magic of having it materialize on your print bed. But the slicer complains it isn’t manifold or watertight or something like that. What a let down. Part of this is due to shortcomings in the STL file format. There’s a newer format available, 3MF, and Josef Prusa and Jakub Kočí would like you to start using it.
STL — short for stereolithography — is a simple format that just holds a bunch of triangles. If you need any information about the part — like colors or materials. Worse still, as in our hypothetical example, there are no definition about how the triangles relate so you can create “bad” STL files. Even properly formed files can be tough to work with. You might scale for inches and the file is set for millimeters, for example.
Turns out 3MF is actually a ZIP archive and it can contain lots of information. The file can contain one or more models, colors, slicing data, copyrights, images, and lots more. The ZIP file is often shorter, too because of the compression. The big deal, though, is that the file format won’t allow nonmanifold models and removes ambiguity so that everything nicely prints. If your slicer stores data into the file — as the Prusa one does — other people using the same software can grab your settings, too.
The format isn’t really that new — it appeared around 2015 — but it hasn’t seen widespread adoption yet. Prusa encourages you to upload models in 3MF even if you also add an STL copy for people who haven’t made the switch yet.
So will you start using 3MF? Or are you already? The file format is open, they say. So if your favorite tool doesn’t like 3MF, you could always add support for it yourself.
Another format, another day.
“There are now 15 competing standards”
Maybe the next one will cover everybody’s use cases…
It’s not all bad. Still to early to tell if it’s DVD or Betamax, but I’m always glad to see new developments that are well intentioned and full of possibilities. We can’t keep using punch cards forever for fear of format chaos.
Nevertheless applications use standardized files formats only, for a reason.
Except that this one is backed by many large parties. Like solidworks, autodesk and microsoft.
Also, Cura uses it as file format to store projects in. So there is more support out there already, it’s not a new standard, it’s around for a while already.
Prusa continues to lead the consumer 3d market — This is really overdue. Thank you Josef
Lead? You mean lag behind and finally get on board the 3mf wagon. Cura has already had this feature for years.
Sli3r has had thiss feature for years too!
ZIP format is lazy. If you are going to make a new format, why not at least use the latest compression with an old container format? .tar.xz would have been a much better choice.
Calm down Satan, can see ppl out there with 8 bit printer controllers watching their kids go from kindergarten to college while they wait for fancy smancy formats to decompress.
Well.. actually it’s the slicer which is doing the decompression of the 3mf file. Nobody is sending zipped gcode to their printer!
Unless you have an ultimaker 3 ;) those accept gcode.gz just fine ;)
tar.xz would be a bad choice for this use case as it does not allow access to individual files. If you want just the file at the end of the archive, you have to decompress everything.
Recent versions of the ZIP file format support LZMA compression.
LZMA compression in a ZIP container isn’t good choice either. LZMA is really slow to compress, so it’s not a good idea to use it every time you hit Ctrl-S.
It’s the decompress that’s gonna be the real make-or-break, especially with standalone 3D printers.
It’ll have to be both cpu and memory light while fast, compression is a second thought as WIP’s could most likely be saved “raw” and uncompressed.
3d printers handle GCode, not STL or 3MF. It’s the slicer, configured with the parameters of your printer, that has to decompress the 3MF file. The slicer is (almost) always on your computer, not on the printer.
@Gravis, AMF also uses zip and I can’t recall it’s name but I think there is a third 3d model format that does too. That makes it kind of a standard don’t you think?
.zip is what epub(badly, the spec depends on more than just filenames and expects stuff in a certain order) and iirc odt use. It’s a standard. It works everywhere.
Tar.xz might be popular enough to work these days besides the fact that it’s a little annoyed to click through two layers of container instead of having compression and archiving in one.
.wad files too, for various video games! And .docx / .xlsx files for MS Office.
It would be just .xz. The .tar part is for combining multiple files (and folders) into one file, which is of no use if there’s always only one file.
That said, making the compression algorithm part of the file format isn’t a good idea in general. Compression and decompression should stay part of file handling. For printing a file, one has to decompress it anyways, so this uncompressed thing is what should get standardized.
It’s not just based on zip. It’s based on the open document format. So it builds on other standards instead of re-inventing the wheel.
just upload step files, drives me nuts getting a STL
Yeah, I can’t stand STL files. To make any changes to an STL is a nightmare. I don’t know of any slicers that accept STEP files, which I’m assuming is the reason why STL is the norm for sharing 3D printed models, but if you can’t manage to convert a STEP to an STL I’m not sure you should have a printer.
this times literally infinity plus 15.
Why doesn’t everyone just upload the CAD project files too? Unless you specifically want to prevent people from making changes, why not?
Having only CAD files would be an issue though, you guys all seem to like SolidWorks and I don’t have a Windows machine or a desire to pay for a copy of it.
Another format, another day.
“There are now 15 competing standards”
Applies to CAD as well, with the commercial versions also deliberately making newer versions incompatible with the old ones (looking at you, Solidworks) unless you specifically export your file as said version.
No, because not everyone models in solids or NURBS. For example, all the models seen in the Prusa video included in this article were made in programs that generate polygons, not surfaces and solids. At no point was there a STEP file to be had.
STEP supports polygon geometries (tessellated surfaces) as well as it supports b-spline surfaces. Support for them in CAD software is pretty wide, in my experience. Problem is getting the folks at Rhino and the like to step up and support standards-based solutions.
But Rhino does import and export STEP, along with a huge amount of other file types.
Yes please!
I make a habit of always uploading STL, STEP, and original CAD files for each project.
I find it a bit strange how we often model in solids, nurbs, etc then tesselate to polygons then make the gcode.
Surely we can skip the tesselation step and go straight from curves to gcode for better results without huge STL files?
Please, someone smarter than me, please please write a STEP import plugin for cura!
Same here. It’s like someone sending you screenshots of their Word document and wanting you to edit it. #triggered
(Mind you, I mostly use OpenSCAD, so I can create STL’s at whatever resolution I want or use FreeCAD to convert my designs to STEP format.)
So if it’s a zip file doesn’t it just contain some sort of mesh file anyway? Isn’t it just more ways for a file to get loaded up with crap?
a compressed file can contain anything………. zip, rar, etc… it doesnt say much about the file format if all you say is that it is compressed like zip files…
I have to admit with a bit of shame, my very first venture into 3d printing and model making was with microsofts “3d builder” (free as in beer, but win10 only)
3mf is its default file format. I was always disappointed in the results of converting it to STL and losing most all of the texture and all the color info. Even now with better tools 3mf is my “master” storage format and any subset format needed is generated out of that.
Amf its already supported in open source apps, but I didn’t saw one yet that let me export to 3mf.
That sounds like a good idea – he does mention it’s not perfect but it’s a step in the right direction- I’ll be giving it a go
The problem with this is that printers are so different and slicer settings are printer specific. I would be much more interested in a brep type format like step that could contain useful information such as specifications on a surface finish. This way the information could be consumed by slicers generically.
Well not all settings are printer specfic. But the boundary is vague. Printable-without support could be model specific. But sls printers will print everything without supports… so printer specific after all. Not a trivial problem to solve.
Being able to save color/material information is nice, but really seems a bit early to be worried about that kind of thing. Unless of course you’re a company trying to sell a multi-material printer upgrade (hint, hint). The vast majority of desktop 3D printers are single extruder, and I don’t see any sign of that changing in the near future.
Same goes for the ability to save support material and printer settings. It makes sense for Prusa in the context of their model sharing site, but assuming you’re sharing models for a larger audience, I can’t imagine a situation where you’d want to include that kind of info.
As I understand it, the only unit STL understands is the millimeter. So when modeling with trueSpace I can work in millimeters, centimeters, or meters. Doesn’t matter, it all comes out the same size on the print bed. I just use the scale that most convenient for the size of object I’m making. So if I’m doing something tiny I can set the object scale to meters and the workspace scale so the small object is large enough to see without having to zoom way in.
What STL needed added a long time ago was support in the file for noting what unit it’s in. Let the slicers convert to MM for the printers.
There is no unit specified in STL files. Most slicers assume the units are mm, and allow you to scale in case the file was actually in another size.
Thanks I’ve long wondered what the STL de facto scale is. I knew it was not actually specified anywhere in the file (gross oversight imo) but figured most tools had some assumption, but it was hard to google what that was :)
I’ve never encountered an STL file that uses inches… it may not technically be against any standards, but it’d be bad practice IMO because it’s not what anybody in their right mind would expect.
I’ve actually run into a few hiding in the darkest reaches of Thingiverse, but it’s been awhile. Usually it meant the creator had used Sketchup.
When I started making Cura, the amount of models on thingiverse was managable. About 3% where in inches back then. Which is why I decided, it’s always mm, and if you encounter something else, you need to scale. No import wizards, no extra in-between screens for that 3%.
But STL itself does not define the unit as mm. It also does not define which direction is “up”, and that varies between applications as well.
If I’m not mistaken, stl does see mm or inches at all. It sees units. 1 unit could mean 1 millimeter, 1 meter, 1 inch or 1 yard. The slicer just assumes that it’s 1 millimeter.
When I was reading up on file formats I read that 3mf and amf were the two “modern” formats and that even though stl is still way more common, with it’s lack of color and material information it is dated. I only have a single nozzle, single color printer but I see no reason to assume that will always be the case and not standardize on a better format today.
I also read that to implement amf you have to either use a beta standard document that was released for free or pay for the privilege of reading the actual standard. 3mf I read was free, totally open.
Then I searched to see if OpenSCAD supported 3mf. I found a forum post where the authors were debating whether to add 3mf export or not and they decided not to because it wasn’t open enough. And they do support amf!
I am confused. Does anyone out there understand what that was about?
There were some concerns early on about Microsoft being Microsoft, but as of the latest version of OpenSCAD (2019.05), both 3MF and AMF are supported.
People have way more concerns than they need to about Microsoft. Compared to other companies they’re starting to look pretty darn good. I still wouldn’t use Windows, but even that’s better now with linux support.
That’s only the case *now*. Microsoft has a very poor track record, and it’s only fair to expect people to be cautious for at least a few years after they claimed to change their spots.
Not when you are familiar with their full history and modus operandi towards open standards.
I haven’t tried the Linux subsystem in several months. Maybe I should try it again. So far I see it as kind of a negative thing actually.
I have used Cygwin for quite a while. It’s package management is quite rough but it does work. When I tried the subsystem it was able to run fewer of my Linux applications than Cygwin. Worse, it is only available for Windows Professional edition. I’d say those two things make it inferior to Cygwin.
And yet the subsystem gets all the attention, not Cygwin. Nobody else I know still uses Cygwin, everyone is excited about Linux on Windows. Maybe I am imagining it but it seems like updates are fewer and farther between in Cygwin. Is that a symptom of developers leaving to use the subsystem instead?
Embrace, extend, extinguish. It fits.
Is that for import, export or both?
OpenSCAD on my computer does not list 3mf in it’s export options and it is 2019.05. It’s built from the Gentoo ebuild. Maybe I need to build it myself to get that? I’ll look into it a bit later.
I do have AMF. I wonder, does that mean somebody paid for the spec? If so then are there parts of OpenSCAD that aren’t supposed to be open sourced?
I never understood the “but Microsoft was involved” argument. If the spec was released under an open source compatible license then even if Microsoft decided to re-release with proprietary extensions we can just fork it right? I don’t see the problem.
The day Blender can natively export to 3mf is the day I start using it when making new projects for distribution…
Still just a mesh. Please stop using triangle meshes once and for all! Use B-rep or F-rep instead.
Unfortunately ZIP does not impose a chatacter encoding scheme for the filenames it contains.
E.g. I have serious issues with “download folder as zip” via WebGUI off OneDrives, then unpack it on non-MS-systems: there’s allways some garbled filenames when I18N chars are involved.
It’s hard to blame MS even they don’t disclose the encoding used when OneDrive makes up the ZipArchive as Zip does not define any :-(
yes this is a great step in the right direction, I plan on switching immediately since all the tools I use support 3mf
stl is totally fine. its a case of garbage in garbage out.
I think I understand where prusa wants to go. STL is fine when you are dealing with a single colour / single material objects. It gets messier with multiple colours / materials. We are using it in ways it was not designed for, at some point a switch will be required.
I tried to add 3mf import to the ColorPod full color 3d printing software. I found the 3mf specs too complicated. Next i tried to find an open source 3mf to obj converter. None of the ones I tried handles colors well. The only way I can handle 3mf is by importing it in builder and exporting it as obj.
If you need any information about the part — like colors or materials.
Is not a complete sentence. Not even close.
I might use it.. Its fine as long as they maintain some kind of backward compatibility. There are a lot of slicers out there, and a lot of software for tweaking meshes as well as different cad programs used for modifying those. STL isn’t ideal, but it is old enough and standard enough that almost every piece of software supports it. So whatever problem I DO have can be solved using the best tool for that job.
They do have a good slicer going, that is certainly true. So they may end up being able to drag other software suites along and make a new default standard. That would be great. In the meantime there is enough legacy stuff out there already that it needs to be a transition not just an attempt at an abrupt switch.
Not so much a new format, but a package containing an existing format (.stl) plus metadata to bodge up some of STL’s shortcomings. Not a bad hack, but the absolute minimum possible improvement to STL rather than a new format designed for 3D printing.
Google killed the zip. Choose another format that wont get blocked by most webmail srvers…
Since the 3mf files can (and in prusa’s case they do) contain print settings there are security issues to worry about. It’s quite easy to hide harmful settings in the included slicer profile, as some 3d printing youtube channels already explained. It’s no difficult to set your z-home to -5mm and damage your printbed, or set nozzle temp to 300+ and extrusion ratio to 10 after 100th layer, turning your hotend in melting plastic blob in the best case.