Additive Manufacturing File Format
|Internet media type||
|Initial release||May 2, 2011|
Additive Manufacturing File Format (AMF) is an open standard for describing objects for additive manufacturing processes such as 3D printing. The official ISO/ASTM 52915:2013standard is an XML-based format designed to allow any computer-aided design software to describe the shape and composition of any 3D object to be fabricated on any 3D printer. Unlike its predecessor STL format, AMF has native support for color, materials, lattices, and constellations.
- 1 Structure
- 2 Design considerations
- 3 History
- 4 See also
- 5 Notes
- 6 External links
An AMF can represent one object, or multiple objects arranged in a constellation. Each object is described as a set of non-overlapping volumes. Each volume is described by a triangular mesh that references a set of points (vertices). These vertices can be shared among volumes. An AMF file can also specify the material and the color of each volume, as well as the color of each triangle in the mesh. The AMF file is compressed using the zip compression format, but the ".amf" file extension is retained. A minimal AMF reader implementation must be able to decompress an AMF file and import at least geometry information (ignoring curvature).
Basic file structure
The AMF file begins with the XML declaration line specifying the XML version and encoding. The remainder of the file is enclosed between an opening <amf> element and a closing </amf> element. The unit system can also be specified (millimeter, inch, feet, meter or micrometer). In absence of a units specification, millimeters are assumed.
Within the AMF brackets, there are five top level elements. Only a single object element is required for a fully functional AMF file.
- <object> The object element defines a volume or volumes of material, each of which are associated with a material ID for printing. At least one object element must be present in the file. Additional objects are optional.
- <material> The optional material element defines one or more materials for printing with an associated material ID. If no material element is included, a single default material is assumed.
- <texture> The optional texture element defines one or more images or textures for color or texture mapping, each with an associated texture ID.
- <constellation> The optional constellation element hierarchically combines objects and other constellations into a relative pattern for printing.
- <metadata> The optional metadata element specifies additional information about the object(s) and elements contained in the file.
The format maintains the triangle-mesh geometry representation used in the STL format in order to take advantage of existing optimized slicing algorithm and code infrastructure. The top level <object> element specifies a unique id. The <object> element can also optionally specify a material. The entire mesh geometetry is contained in a single mesh element. The mesh is defined using one <vertices> element and one or more <volume> elements. The required <vertices> element lists all vertices that are used in this object. Each vertex is implicitly assigned a number in the order in which it was declared, starting at zero. The required child element <coordinates> gives the position of the point in 3D space using the <x>, <y> and <z> elements. After the vertex information, at least one <volume> element must be included. Each volume encapsulates a closed volume of the object, Multiple volumes can be specified in a single object. Volumes may share vertices at interfaces but may not have any overlapping volume. Within each volume, the child element <triangle> is used to define triangles that tessellate the surface of the volume. Each <triangle> element will list three vertices from the set of indices of the previously defined vertices. The indices of the three vertices of the triangles are specified using the <v1>, <v2> and <v3> elements. The order of the vertices must be according to the right-hand rule, such that vertices are listed in counter-clockwise order as viewed from the outside. Each triangle is implicitly assigned a number in the order in which it was declared, starting at zero.
Colors are introduced using the <color> element by specifying the red, green, blue and alpha (transparency) channels in the sRGB color space as numbers in the range of 0 to 1. The <color> element can be inserted at the material, object, volume, vertex, or triangle levels, and takes priority in reverse order (triangle color is highest priority). The transparency channel specifies to what degree the color from the lower level is blended in. By default, all values are set to zero.
A color can also be specified by referring to a formula that can use a variety of coordinate-dependent functions.
Texture maps allow assigning color or material to a surface or a volume, borrowing from the idea of Texture mapping in graphics. The <texture> element is first used to associate a texture-id with particular texture data. The data can be represented as either a 2D or a 3D array, depending on whether the color or material need to be mapped to a surface or a volume. The data is represented as a string of bytes in Base64 encoding, one byte per pixel specifying the grayscale level in the 0-255 range.
Once the texture-id is assigned, the texture data can be referenced in a color formula, such as in the example below.
Usually, however, the coordinated will not be used directly as shown above, but transformed first to bring them from object coordinates to texture coordinates. For example tex(1,f1(x,y,z),f2(x,y,z),f3(x,y,z)) where f1(), f2(), f3() are some functions, typically linear.
Materials are introduced using the <material> element. Each material is assigned a unique id. Geometric volumes are associated with materials by specifying a material-id within the <volume> element.
Mixed, graded, lattice, and random materials
New materials can be defined as compositions of other materials. The element <composite> is used to specify the proportions of the composition, as a constant or as a formula dependent of the x, y, and z coordinates. A constant mixing proportion will lead to a homogenous material. A coordinate-dependent composition can lead to a graded material. More complex coordinate-dependent proportions can lead to nonlinear material gradients as well as periodic and non-periodic substructure. The proportion formula can also refer to a texture map using the tex(textureid,x,y,z) function. Reference to material-id "0" (void) can be used to specify porous structures. Reference to the rand(x,y,z) function can be used to specify pseudo-random materials. The rand(x,y,z) function returns a random number between 0 and 1 that is persistent for that coordinate.
Multiple objects can be arranged together using the <constellation> element. A constellation can specify the position and orientation of objects to increase packing efficiency and to describe large arrays of identical objects. The <instance> element specifies the displacement and rotation an existing object needs to undergo to arrive into its position in the constellation. The displacement and rotation are always defined relatively to the original position and orientation in which the object was defined. A constellation can refer to another constellation as long as cyclic references are avoided.
If multiple top-level constellations are specified, or if multplie objects without constellations are specified, each of them will be imported with no relative position data. The importing program can then freely determine the relative positioning.
The <metadata> element can optionally be used to specify additional information about the objects, geometries and materials being defined. For example, this information can specify a name, textual description, authorship, copyright information and special instructions. The <metadata> element can be included at the top level to specify attributes of the entire file, or within objects, volumes and materials to specify attributes local to that entity.
Optional curved triangles
In order to improve geometric fidelity, the format allows curving the triangle patches. By default, all triangles are assumed to be flat and all triangle edges are assumed to be straight lines connecting their two vertices. However, curved triangles and curved edges can optionally be specified in order to reduce the number of mesh elements required to describe a curved surface. The curvature information has been shown to reduce the error of a spherical surface by a factor of 1000 as compared to a surface described by the same number of planar triangles. Curvature should not create a deviation of from the plane of the flat triangle that exceeds 50% of the largest dimension of the triangle.
To specify curvature, a vertex can optionally contain a child element <normal> to specify desired surface normal at the location of the vertex. The normal should be unit length and pointing outwards. If this normal is specified, all triangle edges meeting at that vertex are curved so that they are perpendicular to that normal and in the plane defined by the normal and the original straight edge. When the curvature of a surface at a vertex is undefined (for example at a cusp, corner or edge), an <edge> element can be used to specify the curvature of a single non-linear edge joining two vertices. The curvature is specified using the tangent direction vectors at the beginning and end of that edge. The <edge> element will take precedence in case of a conflict with the curvature implied by a <normal> element.
When curvature is specified, the triangle is decomposed recursively into four sub-triangles. The recursion must be executed five levels deep, so that the original curved triangle is ultimately replaced by 1024 flat triangles. These 1024 triangles are generated "on the fly" and stored temporarily only while layers intersecting that triangle are being processed for manufacturing.
In both the <color> and <composite> elements, coordinate-dependent formulas can be used instead of constants. These formulas can use various standard algebraic and mathematical operators and expressions.
An AMF can be stored either as plain text or as compressed text. If compressed, the compression is in ZIP archive format. A compressed AMF file is typically about half the size of an equivalent compressed binary STL file. The compression can be done manually using compression software such as WinZip, 7-Zip, or automatically by the exporting software during write. Both the compressed and uncompressed files have the AMF extension and it is the responsibility of the parsing program to determine whether or not the file is compressed, and if so to perform decompression during import.
When the ASTM Design subcommittee began developing the AMF specifications, a survey of stakeholders revealed that the key priority for the new standard was the requirement for a non-proprietary format. Units and buildability issues were a concern lingering from problems with the STL format. Other key requirements were the ability to specify geometry with high fidelity and small file sizes, multiple materials, color, and microstructures. In order to be successful across the field of additive manufacturing, this file format was designed to address the following concerns
- Technology independence: The file format must describe an object in a general way such that any machine can build it to the best of its ability. It is resolution and layer-thickness independent, and does not contain information specific to any one manufacturing process or technique. This does not negate the inclusion of properties that only certain advanced machines support (for example, color, multiple materials, etc.), but these are defined in such a way as to avoid exclusivity.
- Simplicity: The file format must be easy to implement and understand. The format should be readable and editable in a simple text viewer, in order to encourage understanding and adoption. No identical information should be stored in multiple places.
- Scalability: The file format should scale well with increase in part complexity and size, and with the improving resolution and accuracy of manufacturing equipment. This includes being able to handle large arrays of identical objects, complex repeated internal features (e.g. meshes), smooth curved surfaces with fine printing resolution, and multiple components arranged in an optimal packing for printing.
- Performance: The file format must enable reasonable duration (interactive time) for read and write operations and reasonable file sizes for a typical large object.
- Backwards compatibility: Any existing STL file should be convertible directly into a valid AMF file without any loss of information and without requiring any additional information. AMF files are also easily convertible back to STL for use on legacy systems, although advanced features will be lost.
- Future compatibility: In order to remain useful in a rapidly changing industry, this file format must be easily extensible while remaining compatible with earlier versions and technologies. This allows new features to be added as advances in technology warrant, while still working flawlessly for simple homogenous geometries on the oldest hardware.
Since the mid-1980s, the STL file format has been the de facto industry standard for transferring information between design programs and additive manufacturing equipment. The STL format only contained information about a surface mesh, and had no provisions for representing color, texture, material, substructure, and other properties of the fabricated target object. As additive manufacturing technology evolved from producing primarily single-material, homogenous shapes to producing multi-material geometries in full color with functionally graded materials and microstructures, there was a growing need for a standard interchange file format that could support these features. A second factor that ushered the development of the standard was the improving resolution of additive manufacturing technologies. As the fidelity of printing processes approached micron scale resolution, the number of triangles required to describe smooth curved surfaces resulted in unacceptably large file sizes.
During the 1990s and 2000s, a number of proprietary file formats have been in use by various companies to support specific features of their manufacturing equipment, but the lack of an industry-wide agreement prevented widespread adoption of any single format. In January 2009, a new ASTM Committee F42 on Additive Manufacturing Technologies was established, and a design subcommittee was formed to develop a new standard. A survey was conducted in late 2009 leading to over a year of deliberations on the new standard. The resulting first revision of the AMF standard became official on May 2, 2011
During the July 2013 meetings of ASTM’s F42 and ISO’s TC261 in Nottingham (UK), the Joint Plan for Additive Manufacturing Standards Development was approved. Since then, the AMF standard is managed jointly by ISO and ASTM.
- AMF Wiki: A repository of AMF resources, sample files, and source code