[wronex]

STL works everywhere. Is trivial to parse. And can contain both colors and units [0].

Is there anything stopping us from having multiple solids per file? If not, I don't see the reason for another format.

The mentioned benefit of having slicing settings in the file will not work. Slicing settings are not portable between machines. And not portable between different kinds of filament.

Can someone post the XKCD about additional standards? :)

[0]: https://en.m.wikipedia.org/wiki/STL_(file_format)

[phoronixrly]

> Is there anything stopping us from having multiple solids per file? If not, I don't see the reason for another format.

I think TFA offered a pretty compelling argumentation why you should consider using 3mf for 3D printing and I think you glossed over it:

> 3MF provides a clear definition of manifoldness — it’s impossible to create a 3MF file with non-manifold edges, and there is no ambiguity for models with self-intersections.

Even this is enough of a reason for me to prefer using a 3mf if available instead of having to fix holes in a godawful mesh editor. "STL works everywhere" is true only if you consider incidentally non-manifold STLs as an issue with the software that produced them and not the format itself.

I would like to add another technical detail that I don't think is included in the article -- 3MF uses curved triangular tessellations to encode geometry. This means more accurate representations of geometries and smaller file sizes even with high detail.

[wronex]

I would consider that an issue with the software. Non-manifold models, or self-intersecting models, are not suitable for 3D printing. This is an issue with the model rather than the file format.

If 3MF somehow makes self-intersection, and non-manifoldness, impossible cannot we run STL files though the same algorithm to end up with a "fixed" mesh?

What happens if you try to save a non-manifold model as 3MF? Will it magically fix the issue or will it fail to generate the file?

[smaudet]

...yeah I have to agree... xml is a bit trash, STL works and I don't see how the file format itself can preclude invalid structures, and as others have pointed out the whole text versus binary means a massive slowdown and inefficiency...

The algorithms and the vector compressions could likely be salveaged, but the whole positioning as a 'replacement' to STL seems like red herring marketing, with lock-in to whatever stdlibs they are providing.

It would have been better as a standard binary format, there are a number of choices...

[wronex]

https://xkcd.com/927/