Wednesday, November 9. 2011
AMF - The 3D Printing Format to Replace STL?

The PDF of 3D Printing?
The committee's goal was to create a standard additive manufacturing file format that would be more compact than STL and would include additional features such as colors, units and materials; sort of a Portable Document Format (pdf) for additive manufacturing. In this way, as much information as possible describing an object could be included in the 3D CAD design phase before being exported in a standard format for the fabrication phase. Additive manufacturing OEMs (or others) would then develop software to read this format and use whatever information would be applicable for their particular hardware.
In June, 2011 the first revision of this new format, dubbed AMF (Additive Manufacturing Format or Additive Manufacturing File) was approved. AMF format was designed to:
- be non-proprietary
- backwards compatible with STL
- able to handle complex objects and microstructures within objects
- support 'constellations' of objects (e.g. a full build tray)
- be forward compatible to allow future incorporation of new features
AMF Format is XML-Based
To allow for ease of use and forward compatibility, the AMF format is text-based XML. XML is highly compressible and easy to read, write and process. An AMF file describes first the object (currently with the <mesh> tag) and then the materials and other properties relating to it's manufacture. Significantly, AMF provides no information as to how to fabricate an object. For example, although additive fabrication requires 'slicing' files before generating machine paths, the inclusion of slice information was rejected as too machine-specific. Just like the 2D pdf format, the idea of the AMF format is to provide as much information as possible about and object and let each printer fabricate to the best of its abilities.
AMF Uses Triangular Meshes to Describe Surfaces
An AMF <mesh> is made up of <vertices> and volumes <volume>. Like .PLY files, all vertices <vertex> are defined (later to be referenced according to write order) and then for each <volume>, triangles (<triangle>) are defined as a set of three numbered numbered vertices. This is a bit more efficient than STL files since vertices are only defined once. An excerpt of our original 10 centimeter diameter sphere, translated to AMF format using an open source AMF editor:
00000001 <?xml version="1.0" encoding="ISO-8859-1"?>00000002 <amf>
00000003 <object id="1">
00000004 <metadata type="name">sp</metadata>
00000005 <mesh>
00000006 <vertices>
00000007 <vertex>
00000008 <coordinates>
00000009 <x>-3.06161e-015</x>
00000010 <y>0</y>
00000011 <z>-49.9999</z>
00000012 </coordinates>
00000013 </vertex>
00000014 <vertex>
00000015 <coordinates>
00000016 <x>-0.0493787</x>
00000017 <y>-1.40144</y>
00000018 <z>-49.9802</z>
00000019 </coordinates>
00000020 </vertex>
...
00173292 </vertices>
00173293 <volume>
00173294 <metadata type="name">Default</metadata>
00173295 <triangle>
00173296 <v1>24642</v1>
00173297 <v2>24640</v2>
00173298 <v3>24417</v3>
00173299 </triangle>
00173300 <triangle>
00173301 <v1>24640</v1>
00173302 <v2>24638</v2>
00173303 <v3>24415</v3>
00173304 </triangle>
...
00420820 <triangle>
00420821 <v1>24640</v1>
00420822 <v2>24642</v2>
00420823 <v3>24754</v3>
00420824 </triangle>
00420825 </volume>
00420826 </mesh>
00420827 </object>
00420828 </amf>
With additional tags and definitions, an AMF file might actually have more lines than an equivalent STL file, but it will likely be smaller and more easily parsed. For example, although the AMF file above has 20% more lines than the equivalent STL file it is 27% smaller in size, even as human readable text.
AMF Meshes Not Limited to Straightedged, Planar Triangles
Like STLs an AMF <mesh> can simply be composed of straight edged, planar triangles. But an AMF mesh doesn't have to stop there. AMF triangles can more accurately describe a 3 dimensional surface by being curved edge and/or non-planar. By adding a unit normal tag (<normal>) to vertices, non-planar triangles can be described. And by adding an an <edge> tag specifying the tangent direction vector at the end of an edge, curved edge triangles can be described.
Finally, and perhaps most interestingly, an AMF mesh requires a certain depth of recursion when it is read. It is expected that a reading program will subdivide each triangle into a specified number of planar subtriangles to be used for viewing or CAM algorithms. For example, a four-fold recursion would result in each triangle being subdivided into 256 subtriangles. The encoding software would assume a four-fold recursion and would then determine the minimum number of triangles required to specify the target geometry to a chosen tolerance or precision. This results in a SIGNIFICANTLY fewer number of required triangles to define an object (although read/process times are increased slightly). For example, a 10 cm sphere defined to a precision of 10 microns requires less than 400 non-planar triangles to define. A similar STL file requires 20-50 thousand triangles. In our ealier post we were only able to reduce the number of STL triangles by reducing the precision to 1mm. Looked at another way, an STL file with a similar number of defined triangle facets is 2-3 orders of magnitude lower resolution than an AMF file describing the same surface but with non-planar, curved edge triangles.
STL Format(Binary) |
AMF Format(Curved Triangles) |
|
PRECISION |
10 micron |
10 micron |
NO. OF MESH TRIANGLES
|
49,500 |
320 |
FILE SIZE
|
2400k |
10k |
Alternatives to <mesh> Possible in Future
In choosing how to describe the surface of an object several options were considered: the STL-like triangular mesh described above; using 'voxels' to define a 3D bitmap; or functional representations where the function evaluates to zero at the object surface. Ultimately, to ensure a quicker transition and simple backward compatibility, the triangular mesh (<mesh>) was settled upon although this choice was not unanimous (e.g. see here). However, it is anticipated that 3D bitmap (<voxel>) and functional (<frep>) representations will be incorporated into the standard in the future.
AMF Can Describe Materials, Compositions, Colors, Textures and More
In addition to <mesh> definition AMF goes beyond standard STL files in being able to define available materials (<material>). Materials are defined with particular properties, given an ID and subsequently associated with AMF volumes by ID. Compositions (<composite>) colors (<color>) textures (<texture> etc. can be specified for various materials. Microstructures, colored or textured objects can now be defined in CAD programs and then have that information available in a standard AMF file. 3D printers would then use whatever information the need to match their capabilities. Can't create compositions or colors? That information would simply be ignored.
AMF Can Describe Arrangements of Different Objects
AMF also allows for the creation of groups of objects in constellations (<constellation>. Instances (<instance>) of defined objects (<object>) are grouped under the <constellation> tag and specify the displacement and rotation of each instance of an object. In this way, entire build envelopes can be specified.
AMF Can Include Metadata
Finally, AMF allows for the incorporation of metadata (<metadata>) at whatever level is feasible. A number of 'types' have been reserved including Name, Author, Company, Description, Volume, Tolerance, etc. and they can be placed under everything from the top-level <amf> tag all the way down to the <vertex> tag.
The Future of AMF
The AMF format is an exciting development in an area that has seen little in the last 20 years. It will now be possible to more accurately define objects using a simpler more efficient file structure.
Unfortunately, though a first revision has been approved there is little use for it at this time; CAD programs are incapable of exporting in AMF format and 3D printer OEM programs do not allow for AMF import. The ASTM F42.04 committee predicted that "Big CAD" will first allow for export of basic geometry to AMF files and 3D printer OEMs will allow for imports of AMF files with information that supports their unique hardware capabilities such as color or material specifications. The committee hopes that in parallel smaller or new CAD companies will introduce programs to actually create objects with different microstructures, colors, grade materials etc. which the AMF format - an a number of actual printers - already support. Finally Big CAD would/should follow.
Will it happen? More than likely. The committee has done a good job of creating a robust, extensible format that addresses both the increased 3D CAD and 3D printing capabilities which now exist. All that are needed are conversion and creation tools. To that end, Hod Lipson and Johnathan Hiller have developed an STL-AMF converter/viewer, a second generation STL-AMF converter/viewer (although we found it a bit buggy) and are working on open source C++ libraries for basic AMF functionality including read/write/view etc.
In the meantime, for most of us, we must simply sit tight and wait for new or existing software to incorporate the AMF format. For those with programming skills this might represent an opportunity. With open source C++ libraries, it may be possible for independent programmers to begin developing the solutions which the industry needs but which, it is expected, Big CAD and OEMs will be hesitant to implement.
3D Additive Fabrication, Inc. (3dAddFab) is a start up company located in Colorado, USA. 3dAddFab provides high quality 3D printing that is easy to price and order, at a lower cost than existing fabricators.
Strict Standards: Non-static method serendipity_plugin_api::hook_event() should not be called statically in /srv/www/3daddfab.com/public_html/blog/include/functions_comments.inc.php on line 293 Strict Standards: Non-static method serendipity_plugin_api::get_event_plugins() should not be called statically in /srv/www/3daddfab.com/public_html/blog/include/plugin_api.inc.php on line 1041 Strict Standards: Only variables should be assigned by reference in /srv/www/3daddfab.com/public_html/blog/include/functions_smarty.inc.php on line 73
Frontpage - Top level Strict Standards: Non-static method serendipity_plugin_api::hook_event() should not be called statically in /srv/www/3daddfab.com/public_html/blog/include/functions_smarty.inc.php on line 553 Strict Standards: Non-static method serendipity_plugin_api::get_event_plugins() should not be called statically in /srv/www/3daddfab.com/public_html/blog/include/plugin_api.inc.php on line 1041
Strict Standards: Only variables should be assigned by reference in /srv/www/3daddfab.com/public_html/blog/include/functions_smarty.inc.php on line 73