9 ms·

3MF file format and why it’s great (2019)

82 points by danboarder 5y ago

random59 5y ago
Americans are insane hypocrites now. The very same Americans who scream that straws should be illegal, protests are great, the police should be abolished, the border must be opened, and schools are wonderful then turn around and say that masks must be mandatory, protests must be outlawed, guns must be banned, the border must be closed, and schools must be shut. The very same Americans who swear that they love freedom then turn around and insist that websites must be outlawed, solar panels should be banned, free trade should be ended, and pot must be illegal. WTF?
Const-me 5y ago
I wouldn't call 3MF great. The format is text based. This means if you have 1GB model, you gonna have to print 1GB of float numbers when saving the model, and parse 1GB of float numbers when loading. Text formats are good when human readable, but no sane person gonna read 1GB of data. Not even 100MB. Both numbers are reasonable now for very high-poly models. They should have designed a true binary format, instead of zipped XML. Speaking of the STL format, it can be either binary or text depending on the header. When they have measured size, pretty sure they have used text variant of STL, otherwise they'd get similar sizes. Also, the format is rather complex. One of the reasons why STL is so popular, only needs couple pages of code to support, almost regardless on the programming language. For optimal compatibility, one needs the official C++ only lib3mf library to read/write 3MF files.
- deugtniet 5y ago
  I think 3MF has some real practical benefits as outlined in the article. It may take a lot of file space, but that can be solved in a new version, specified in the header files, in the same way it was done with STL. As with any format, the tooling needs to develop, and then C++ is not a bad idea to write a library in I think. I guess there's space for both file formats tbh. If you are sure your STL is correct, and are sure about the dimensioning, go for it. If you want to be a little safer, go for 3MF, with the drawback of a little larger filesize.
  - Const-me 5y ago
    > that can be solved in a new version Yeah, if in a next version they will move vertex/index buffer data from XML into binary files in the same ZIP (3MF are ZIP files), will be better already. Printing and parsing numbers is surprisingly expensive when you have a gigabyte of them. > C++ is not a bad idea to write a library C++ is fine by itself. Still, should the format be simpler, the official library would be optional, as people would be able to implement support in any language without FFI. It’s hard to do in practice, which leaves the official library as the only practical option, IMO. At least that’s what I did when a client asked me to support that format.
- numpad0 5y ago
  I don't get why a new polygon data format is needed at all. Sculpted models are always on polygons, and that's good, but almost as much bulk of 3D models are CAD models "rasterized" into triangle polygons and that's just pain. Aside from patents and/or rights reasons, why can't we just pass around CAD data to feed CNC machines?
  - Const-me 5y ago
    Some parts of the 3MF are actually good. I like the spec documents winding order of the meshes. The format includes units, and these optional 4x4 transformation matrices — both are useful. As for need of the new formats, for one, modern CAD formats are insanely complex. These IGES/STEP/BREP files require many megabytes of very complicated code to deal with, such as this library https://github.com/tpaviot/oce https://github.com/tpaviot/oce These formats may even contain proprietary extensions. Also, they need non-trivial processing power to handle. Many people wouldn’t want a Core i7 with gigabytes of RAM in their 3D printers, inflates hardware cost and software complexity. Besides, we now have high-resolution 3D scanners, and CAE software which algorithmically optimizes models by running numerical simulations. They both output triangle meshes instead of CAD files. Scanners often output point clouds one can convert into triangles, but hard to convert into CAD formats. I just don’t like the 3MF implementation too much. XML is fine for kilobytes of data, but not many megabytes. If I would be designing that format, I would probably made it binary. Maybe EBML https://en.wikipedia.org/wiki/Extensible_Binary_Meta_Language https://en.wikipedia.org/wiki/Extensible_Binary_Meta_Languag... would work for that; it does fine for MKV videos, which is also a huge pile of structured data with non-trivial performance constraints for producers and especially parsers. Another minor thing, it was not the best idea to make name start with a digit. Most programming languages forbid identifiers like that for their classes / functions / namespaces / modules.
  - mch82 5y ago
    There are a few goals for 3MF. One is to have a common format that is portable across tools made by the big companies participating in the consortium. Another is support for specifying material in addition to shape. STL can represent a part, but can’t distinguish it as a specific metal or plastic. STL also can’t specify color. Those properties can be used in engineering software to simplify analysis and visualization. 3MF also supports multiple parts, which is useful in a multi-material build. For example, when a dentist 3D prints a mouth model they might use white for the teeth, red for the jaws, and a removable support material. With STL each of those sub-models would be a separate file, meaning the 3D printer operator would need to properly position them and choose appropriate materials at build time.
- formerly_proven 5y ago
  https://en.wikipedia.org/wiki/3D_Manufacturing_Format#Sample_file https://en.wikipedia.org/wiki/3D_Manufacturing_Format#Sample... It's not the dumbest engineering data format I've seen (seen many, this is at least one you can parse). But ffs, just use HDF5 people.
  - Const-me 5y ago
    > It's not the dumbest engineering data format I've seen It’s not, but should the models be binary, the format would be much better. > just use HDF5 Last time I checked (a few years ago), HDF5 was only possible to handle with the official C++ library. That library didn’t even support multithreading, when I tried to write 2 HDF5 files from 2 concurrent thread, the program crashed with broken data structures in some global variables deep inside the HDF5 library. My computer has 16 hardware threads, the servers I’m targeting often have more of them, and I’d like to actually use that hardware. Single-threaded libraries aren’t OK in my books; not in 2021.
    - formerly_proven 5y ago
      HDF5 supports parallel I/O with MPI, which works fine for HPC applications, but I can see how this might be a reason against HDF5.
    - deleted 5y ago
      [deleted]
    - ggrrhh_ta 5y ago
      It's a pity, also, some other limitations (for example with strings in HDF5 files, etc.). The format itself is to me, the closest to "the ultimate format", however, yes, library/tools support is a bit disappointing and it is sad. I came here to say that 3MF can be serialized into HDF5 - keeping the advantages of both, the textual description (which is much much more futureproof when one looks 10/15/20 years in the future) while having a one-to-one fast access counterpart.
      - Const-me 5y ago
- ggrrhh_ta 5y ago
  I know that it is counterintuitive, but storing doubles in binary format can take (for many use cases) much more space than storing the text. Each double, uncompressed is 8 bytes, 3.2e-3 is only 6 bytes, a 1 digit integer is 1 byte, a 5 digit integer is 3 bytes less than the double to store it... Also, when humans enter data in some specific units they want to see the same number back (and not a rounded -in binary- version of it, although very good algorithms exist to that end). Text compression of number data is extremely efficient. Having cross-platform binary formats is complex and binary formats go stale much sooner. Having humans peek at the file in text mode and debut or use simple command line tools with copied and pasted data is also useful for exploration purposes. The best of both worlds is to have a text representation coupled with one-to-one binary encoding; but as I pointed out, many times, the binary format actually takes, unintuitively, more space...
  - Const-me 5y ago
    > much more space than storing the text In other cases it’s the opposite. Convert a model from millimeters to inches, and that 1.0/25.4 multiplier gonna cause decimal representation to be much longer than 8 digits. Mechanical engineers are doing things like that pretty often. > when humans enter data in some specific units I don’t think it’s a reasonable expectation for a human to type 100 MB, or 1GB of numbers. People do work with triangle meshes that large. These models were made by specialized hardware or software tools, not by entering numbers. It’s the same story with images: they have too many megapixels now, and people aren’t entering millions of RGB numbers. Instead, people using scanners, digital cameras, and Photoshop to deal with these volumes of data. > Text compression of number data is extremely efficient The most expensive part is not compression, it’s printing and parsing. That code is very hard to vectorize or parallelize. When software reads or writes large continuous buffer of binary data like std::vector in C++, the throughput is often limited by physical disk. On many modern computers that’s at least 100 MBytes/sec, often much faster. I think it’s borderline impossible to print or parse float numbers that fast. Especially given that in 3MF, there’s some XML producer/parser down the stack who needs to escape/unescape these strings.
    - willis936 5y ago
- threatripper 5y ago
  Reading those numbers is only a minor part compared to processing the data in the slicer. While you are right, that a better format could be imagined I would call it a minor or even non-issue. After compressing the file sizes should not be so much different as the raw data suggests. > Text formats are good when human readable, but no sane person gonna read 1GB of data. People are regularly editing the resulting G-Code file which is even bigger in size. They use old fashioned text editors for this which works because it's not binary but simple text with readable numbers. Then those huge files are processed with little 8-Bit computers which have barely enough processing power to move the motors.
  - ddingus 5y ago
    All true! Some common edits are: Change in process parameters mid program, speed / feed rate tweaks to optimize production jobs, tool number change to run job on different machine / tool setup. Big G-code files are my favorite text editor test.
- ddingus 5y ago
  Personally, I much prefer text for manufacturing data. File size isn't a big deal for the intended use cases and that file contains setup information anyone can read and make use of. That's actually worth the format tradeoffs right there. G-code generated from these files often contains that info, and some additional info specific to the job created. Same benefits of plain text. Often, I get these files and that information being available, easy to read without having to have specific software is a huge win. Humans do read these files :D
beachy 5y ago
I'd like to know the backstory of the .amf format mentioned in the post.
- bchanudet 5y ago
  AMF is an ISO standard, which means the full specification can only be bought from the ISO store itself. I'm not sure about the ambiguity mentioned in the blogpost, as ISO standards are usually rather thorough. I suppose it's because most of software implementing AMF did so without the full specification at hand and assumed some things. For me STL/AMF and 3MF are complimentary. When I design a piece in FreeCAD and want to export it, AMF or STL is good enough as FreeCAD doesn't know anything about the printer I'll be using or the settings I want. But once in PrusaSlicer it makes sense to use 3MF to keep everything tight, for example if I need to move an already configured file from home to the office.
  - stavros 5y ago
    > STL is good enough as FreeCAD doesn't know anything about the printer I'll be using or the settings I want This is exactly how I feel about all this. Logically, 3MF is superior to STL, but emotionally the STL feels like it is about "the model" whereas 3MF feels like it is about "the print settings, with an STL model happening to be in there too".
Causality1 5y ago
The grammarian in me has to cringe at chopping an initialism in half. It should really be 3DMF.
- boondaburrah 5y ago
  Maybe, but 3DMF is a 90s QuickTime/QuickDraw3d file format from Apple. Since this is /also/ a model format, you wouldn't want that.
greatgib 5y ago
Designing a new xml zip based file format is like going back to 1990...
- eesmith 5y ago
  .... 1999. At least, that's when I remember learning about XML. Wikipedia adds that XML 1.0 didn't come out until 1998 and started in 1996.
- kome 5y ago
  there was no xml in the 90s.
- demeyer1 5y ago
  Well said. In some respects (not all), on our teams that manage geometric indexing, we've been comparing this to Office document formats a long time back.
junon 5y ago
A new text based 3D format in XML... in 2021? > Microsoft Oh that makes more sense.
- formerly_proven 5y ago
  These files are pretty much an OOXML file, same structure and even has a [Content_Types].xml
- baq 5y ago
  strictly better than yaml.
- OJFord 5y ago
  > in 2021 This post is (should be) `(2019)`, and 3MF first released in 2015 according to Wikipedia.
  - junon 5y ago
    Thanks. 2019 and 2015 aren't much better though. There's been a bit push for gltf but it's quite complex; I don't see it being adopted. XML isn't the answer either, though.
- kome 5y ago
  > A new text based 3D format in XML... in 2021? Well, thank god they are using a standard, interoperable, widely understood and supported text-based format like XML. Any other solution would have been terrible, especially if yaml or json were involved.
  - numlock86 5y ago
    Why would JSON have been terrible? Because it's lacking namespaces and all those "quirky" things most XML implementations (and users) get wrong?
    - AussieWog93 5y ago
      You took the bait, mate.
wronex 5y ago
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) https://en.m.wikipedia.org/wiki/STL_(file_format)
- wronex 5y ago
  https://xkcd.com/927/ https://xkcd.com/927/
- phoronixrly 5y ago
  > 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 5y ago
    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?
hulitu 5y ago
> 3MF file format and why it’s great (2019) >3MF, also called 3D Manufacturing Format is an open-source project developed by the 3MF consortium founded by Microsoft. Everything Microsoft does is great. I wonder if i have to delete some registry keys to use it just like for my dvd drive /s
demeyer1 5y ago
We have a few million unique users, which is small within the broader context of 3D creators and consumers - so small N, but I'll share a couple observations at that volume. Adoption STLs remain the most popular, today, on our platform. 3MF has been growing, but only in the past quarter did our users tell us in meaningful volumes that we need to support it - which we did, happily. The push to 3MF seems to be gaining momentum. Expected benefits vs current state (again, small N and biases in my data) 1. Color/texture is a benefit, though creators include it to varying degrees based on their use case and the intended consumption. We support printers, general 3D designers/sculptors, and mechanical engineers - so our audience is broader than primarily/solely 3D printing. As such, adoption varies considerably depending on the user and use case. 2. Often, the model has more metadata (though rarely includes color, photorealistic renders, etc) and a smaller storage footprint. Benefits creators, consumer and platforms. Though again, adoption lags on the more advanced capabilities inherent to the format. 3. Support for assembly like models is a huge benefit! However, the average 3D printing oriented creator still prefers collections of STLs. In user interviews, I often hear the rationale for this is that there are (perceived) tooling and general workflow changes that seem time consuming - so the usual.. change/learning takes time. Timing Creators will drive adoption, as if often the case. We are seeing this increase every month on our platform (thangs.com), but the relative share of uploads still skews towards STL and other formats. Platforms will need to adapt and take advantage of the format benefits to help consumers see the value. Over the mid term, I am really excited about 3MF. The fact that there is a spirited discussion on HN about it, if nothing else, strikes me as a great sign!
- ddingus 5y ago
  >Support for assembly like models is a huge benefit! However, the average 3D printing oriented creator still prefers collections of STLs. In user interviews, I often hear the rationale for this is that there are (perceived) tooling and general workflow changes that seem time consuming - so the usual.. change/learning takes time. Yes! STL actually does this, and I've employed it for years, but often find software isn't expecting / designed for it, and or others are not aware and use the bundle of files workflow and it's easiest to just go with that flow. Model metadata is exciting to me, and it's for reasons similar to those found in other manufacturing contexts. JT is a great example, and in the 90's VRML actually got used for model + metadata representation by SDRC / FORD to communicate tolerances and other data along with the geometry. Things are very slow to change. Decades for some of this stuff. We were capable of real paperless in the 90's, and still... Not there, but more there than not these days.

82 points by danboarder 5y ago

Americans are insane hypocrites now. The very same Americans who scream that straws should be illegal, protests are great, the police should be abolished, the border must be opened, and schools are wonderful then turn around and say that masks must be mandatory, protests must be outlawed, guns must be banned, the border must be closed, and schools must be shut. The very same Americans who swear that they love freedom then turn around and insist that websites must be outlawed, solar panels should be banned, free trade should be ended, and pot must be illegal. WTF?

Const-me 5y ago

I wouldn't call 3MF great. The format is text based. This means if you have 1GB model, you gonna have to print 1GB of float numbers when saving the model, and parse 1GB of float numbers when loading. Text formats are good when human readable, but no sane person gonna read 1GB of data. Not even 100MB. Both numbers are reasonable now for very high-poly models. They should have designed a true binary format, instead of zipped XML. Speaking of the STL format, it can be either binary or text depending on the header. When they have measured size, pretty sure they have used text variant of STL, otherwise they'd get similar sizes. Also, the format is rather complex. One of the reasons why STL is so popular, only needs couple pages of code to support, almost regardless on the programming language. For optimal compatibility, one needs the official C++ only lib3mf library to read/write 3MF files.

deugtniet 5y ago
I think 3MF has some real practical benefits as outlined in the article. It may take a lot of file space, but that can be solved in a new version, specified in the header files, in the same way it was done with STL. As with any format, the tooling needs to develop, and then C++ is not a bad idea to write a library in I think. I guess there's space for both file formats tbh. If you are sure your STL is correct, and are sure about the dimensioning, go for it. If you want to be a little safer, go for 3MF, with the drawback of a little larger filesize.
- Const-me 5y ago
  > that can be solved in a new version Yeah, if in a next version they will move vertex/index buffer data from XML into binary files in the same ZIP (3MF are ZIP files), will be better already. Printing and parsing numbers is surprisingly expensive when you have a gigabyte of them. > C++ is not a bad idea to write a library C++ is fine by itself. Still, should the format be simpler, the official library would be optional, as people would be able to implement support in any language without FFI. It’s hard to do in practice, which leaves the official library as the only practical option, IMO. At least that’s what I did when a client asked me to support that format.
numpad0 5y ago
I don't get why a new polygon data format is needed at all. Sculpted models are always on polygons, and that's good, but almost as much bulk of 3D models are CAD models "rasterized" into triangle polygons and that's just pain. Aside from patents and/or rights reasons, why can't we just pass around CAD data to feed CNC machines?
- Const-me 5y ago
  Some parts of the 3MF are actually good. I like the spec documents winding order of the meshes. The format includes units, and these optional 4x4 transformation matrices — both are useful. As for need of the new formats, for one, modern CAD formats are insanely complex. These IGES/STEP/BREP files require many megabytes of very complicated code to deal with, such as this library https://github.com/tpaviot/oce https://github.com/tpaviot/oce These formats may even contain proprietary extensions. Also, they need non-trivial processing power to handle. Many people wouldn’t want a Core i7 with gigabytes of RAM in their 3D printers, inflates hardware cost and software complexity. Besides, we now have high-resolution 3D scanners, and CAE software which algorithmically optimizes models by running numerical simulations. They both output triangle meshes instead of CAD files. Scanners often output point clouds one can convert into triangles, but hard to convert into CAD formats. I just don’t like the 3MF implementation too much. XML is fine for kilobytes of data, but not many megabytes. If I would be designing that format, I would probably made it binary. Maybe EBML https://en.wikipedia.org/wiki/Extensible_Binary_Meta_Language https://en.wikipedia.org/wiki/Extensible_Binary_Meta_Languag... would work for that; it does fine for MKV videos, which is also a huge pile of structured data with non-trivial performance constraints for producers and especially parsers. Another minor thing, it was not the best idea to make name start with a digit. Most programming languages forbid identifiers like that for their classes / functions / namespaces / modules.
- mch82 5y ago
  There are a few goals for 3MF. One is to have a common format that is portable across tools made by the big companies participating in the consortium. Another is support for specifying material in addition to shape. STL can represent a part, but can’t distinguish it as a specific metal or plastic. STL also can’t specify color. Those properties can be used in engineering software to simplify analysis and visualization. 3MF also supports multiple parts, which is useful in a multi-material build. For example, when a dentist 3D prints a mouth model they might use white for the teeth, red for the jaws, and a removable support material. With STL each of those sub-models would be a separate file, meaning the 3D printer operator would need to properly position them and choose appropriate materials at build time.
formerly_proven 5y ago
https://en.wikipedia.org/wiki/3D_Manufacturing_Format#Sample_file https://en.wikipedia.org/wiki/3D_Manufacturing_Format#Sample... It's not the dumbest engineering data format I've seen (seen many, this is at least one you can parse). But ffs, just use HDF5 people.
- Const-me 5y ago
  > It's not the dumbest engineering data format I've seen It’s not, but should the models be binary, the format would be much better. > just use HDF5 Last time I checked (a few years ago), HDF5 was only possible to handle with the official C++ library. That library didn’t even support multithreading, when I tried to write 2 HDF5 files from 2 concurrent thread, the program crashed with broken data structures in some global variables deep inside the HDF5 library. My computer has 16 hardware threads, the servers I’m targeting often have more of them, and I’d like to actually use that hardware. Single-threaded libraries aren’t OK in my books; not in 2021.
  - formerly_proven 5y ago
    HDF5 supports parallel I/O with MPI, which works fine for HPC applications, but I can see how this might be a reason against HDF5.
  - deleted 5y ago
    [deleted]
  - ggrrhh_ta 5y ago
    It's a pity, also, some other limitations (for example with strings in HDF5 files, etc.). The format itself is to me, the closest to "the ultimate format", however, yes, library/tools support is a bit disappointing and it is sad. I came here to say that 3MF can be serialized into HDF5 - keeping the advantages of both, the textual description (which is much much more futureproof when one looks 10/15/20 years in the future) while having a one-to-one fast access counterpart.
    - Const-me 5y ago
ggrrhh_ta 5y ago
I know that it is counterintuitive, but storing doubles in binary format can take (for many use cases) much more space than storing the text. Each double, uncompressed is 8 bytes, 3.2e-3 is only 6 bytes, a 1 digit integer is 1 byte, a 5 digit integer is 3 bytes less than the double to store it... Also, when humans enter data in some specific units they want to see the same number back (and not a rounded -in binary- version of it, although very good algorithms exist to that end). Text compression of number data is extremely efficient. Having cross-platform binary formats is complex and binary formats go stale much sooner. Having humans peek at the file in text mode and debut or use simple command line tools with copied and pasted data is also useful for exploration purposes. The best of both worlds is to have a text representation coupled with one-to-one binary encoding; but as I pointed out, many times, the binary format actually takes, unintuitively, more space...
- Const-me 5y ago
  > much more space than storing the text In other cases it’s the opposite. Convert a model from millimeters to inches, and that 1.0/25.4 multiplier gonna cause decimal representation to be much longer than 8 digits. Mechanical engineers are doing things like that pretty often. > when humans enter data in some specific units I don’t think it’s a reasonable expectation for a human to type 100 MB, or 1GB of numbers. People do work with triangle meshes that large. These models were made by specialized hardware or software tools, not by entering numbers. It’s the same story with images: they have too many megapixels now, and people aren’t entering millions of RGB numbers. Instead, people using scanners, digital cameras, and Photoshop to deal with these volumes of data. > Text compression of number data is extremely efficient The most expensive part is not compression, it’s printing and parsing. That code is very hard to vectorize or parallelize. When software reads or writes large continuous buffer of binary data like std::vector in C++, the throughput is often limited by physical disk. On many modern computers that’s at least 100 MBytes/sec, often much faster. I think it’s borderline impossible to print or parse float numbers that fast. Especially given that in 3MF, there’s some XML producer/parser down the stack who needs to escape/unescape these strings.
  - willis936 5y ago
threatripper 5y ago
Reading those numbers is only a minor part compared to processing the data in the slicer. While you are right, that a better format could be imagined I would call it a minor or even non-issue. After compressing the file sizes should not be so much different as the raw data suggests. > Text formats are good when human readable, but no sane person gonna read 1GB of data. People are regularly editing the resulting G-Code file which is even bigger in size. They use old fashioned text editors for this which works because it's not binary but simple text with readable numbers. Then those huge files are processed with little 8-Bit computers which have barely enough processing power to move the motors.
- ddingus 5y ago
  All true! Some common edits are: Change in process parameters mid program, speed / feed rate tweaks to optimize production jobs, tool number change to run job on different machine / tool setup. Big G-code files are my favorite text editor test.
ddingus 5y ago
Personally, I much prefer text for manufacturing data. File size isn't a big deal for the intended use cases and that file contains setup information anyone can read and make use of. That's actually worth the format tradeoffs right there. G-code generated from these files often contains that info, and some additional info specific to the job created. Same benefits of plain text. Often, I get these files and that information being available, easy to read without having to have specific software is a huge win. Humans do read these files :D

beachy 5y ago

I'd like to know the backstory of the .amf format mentioned in the post.

bchanudet 5y ago
AMF is an ISO standard, which means the full specification can only be bought from the ISO store itself. I'm not sure about the ambiguity mentioned in the blogpost, as ISO standards are usually rather thorough. I suppose it's because most of software implementing AMF did so without the full specification at hand and assumed some things. For me STL/AMF and 3MF are complimentary. When I design a piece in FreeCAD and want to export it, AMF or STL is good enough as FreeCAD doesn't know anything about the printer I'll be using or the settings I want. But once in PrusaSlicer it makes sense to use 3MF to keep everything tight, for example if I need to move an already configured file from home to the office.
- stavros 5y ago
  > STL is good enough as FreeCAD doesn't know anything about the printer I'll be using or the settings I want This is exactly how I feel about all this. Logically, 3MF is superior to STL, but emotionally the STL feels like it is about "the model" whereas 3MF feels like it is about "the print settings, with an STL model happening to be in there too".

Causality1 5y ago

The grammarian in me has to cringe at chopping an initialism in half. It should really be 3DMF.

boondaburrah 5y ago
Maybe, but 3DMF is a 90s QuickTime/QuickDraw3d file format from Apple. Since this is /also/ a model format, you wouldn't want that.

greatgib 5y ago

Designing a new xml zip based file format is like going back to 1990...

eesmith 5y ago
.... 1999. At least, that's when I remember learning about XML. Wikipedia adds that XML 1.0 didn't come out until 1998 and started in 1996.
kome 5y ago
there was no xml in the 90s.
demeyer1 5y ago
Well said. In some respects (not all), on our teams that manage geometric indexing, we've been comparing this to Office document formats a long time back.

junon 5y ago

A new text based 3D format in XML... in 2021? > Microsoft Oh that makes more sense.

formerly_proven 5y ago
These files are pretty much an OOXML file, same structure and even has a [Content_Types].xml
baq 5y ago
strictly better than yaml.
OJFord 5y ago
> in 2021 This post is (should be) `(2019)`, and 3MF first released in 2015 according to Wikipedia.
- junon 5y ago
  Thanks. 2019 and 2015 aren't much better though. There's been a bit push for gltf but it's quite complex; I don't see it being adopted. XML isn't the answer either, though.
kome 5y ago
> A new text based 3D format in XML... in 2021? Well, thank god they are using a standard, interoperable, widely understood and supported text-based format like XML. Any other solution would have been terrible, especially if yaml or json were involved.
- numlock86 5y ago
  Why would JSON have been terrible? Because it's lacking namespaces and all those "quirky" things most XML implementations (and users) get wrong?
  - AussieWog93 5y ago
    You took the bait, mate.

wronex 5y ago

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) https://en.m.wikipedia.org/wiki/STL_(file_format)

wronex 5y ago
https://xkcd.com/927/ https://xkcd.com/927/
phoronixrly 5y ago
> 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 5y ago
  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?

hulitu 5y ago

> 3MF file format and why it’s great (2019) >3MF, also called 3D Manufacturing Format is an open-source project developed by the 3MF consortium founded by Microsoft. Everything Microsoft does is great. I wonder if i have to delete some registry keys to use it just like for my dvd drive /s

demeyer1 5y ago

We have a few million unique users, which is small within the broader context of 3D creators and consumers - so small N, but I'll share a couple observations at that volume. Adoption STLs remain the most popular, today, on our platform. 3MF has been growing, but only in the past quarter did our users tell us in meaningful volumes that we need to support it - which we did, happily. The push to 3MF seems to be gaining momentum. Expected benefits vs current state (again, small N and biases in my data) 1. Color/texture is a benefit, though creators include it to varying degrees based on their use case and the intended consumption. We support printers, general 3D designers/sculptors, and mechanical engineers - so our audience is broader than primarily/solely 3D printing. As such, adoption varies considerably depending on the user and use case. 2. Often, the model has more metadata (though rarely includes color, photorealistic renders, etc) and a smaller storage footprint. Benefits creators, consumer and platforms. Though again, adoption lags on the more advanced capabilities inherent to the format. 3. Support for assembly like models is a huge benefit! However, the average 3D printing oriented creator still prefers collections of STLs. In user interviews, I often hear the rationale for this is that there are (perceived) tooling and general workflow changes that seem time consuming - so the usual.. change/learning takes time. Timing Creators will drive adoption, as if often the case. We are seeing this increase every month on our platform (thangs.com), but the relative share of uploads still skews towards STL and other formats. Platforms will need to adapt and take advantage of the format benefits to help consumers see the value. Over the mid term, I am really excited about 3MF. The fact that there is a spirited discussion on HN about it, if nothing else, strikes me as a great sign!

ddingus 5y ago
>Support for assembly like models is a huge benefit! However, the average 3D printing oriented creator still prefers collections of STLs. In user interviews, I often hear the rationale for this is that there are (perceived) tooling and general workflow changes that seem time consuming - so the usual.. change/learning takes time. Yes! STL actually does this, and I've employed it for years, but often find software isn't expecting / designed for it, and or others are not aware and use the bundle of files workflow and it's easiest to just go with that flow. Model metadata is exciting to me, and it's for reasons similar to those found in other manufacturing contexts. JT is a great example, and in the 90's VRML actually got used for model + metadata representation by SDRC / FORD to communicate tolerances and other data along with the geometry. Things are very slow to change. Decades for some of this stuff. We were capable of real paperless in the 90's, and still... Not there, but more there than not these days.