AMF or AML: A format or a language?

300 views
Skip to first unread message

Hod Lipson

unread,
May 15, 2013, 1:16:53 PM5/15/13
to st...@googlegroups.com

In a recent conference on digital manufacturing at MIT, we held a breakout session on AMF. While various people asked to add this and that feature to the standard, Christopher Fry (MIT) came to me at the end and said “you are falling into the trap of many standard developers before you”.

 

Intrigued, I followed up with Fry after the session ended, to inquire which trap that was.

 

Fry mentioned that many standards start by thinking that they are going to be a static “format”, but end up as a full blown “Language”. Because they don’t anticipate this endgame, they get there through a series of patches and extensions.

 

The most notorious example is HTML. It was initially thought of as a file format to describe the layout of a document: Formatting of text and images. Very soon, however, various things were added to make the page respond dynamically. Now, we have a nightmarish patchwork of html extensions, javascript code, and incompatible browsers.

 

Postscript (inside PDF) was another standard that was meant to describe documents, but evolved into a full blown language.

 

Similarly, AMF is meant to describe a static object, but in the future, is may evolve into a dynamic language.

 

I thought about this and I can see how this will happen:

 

1.      First, AMF is already a kind of language because it can describe color and material distribution using spatial functions. For example, a checkerboard composite material fill is described by a mathematical function. This makes it very powerful and compact, but you can see how it may soon be necessary to add hierarchical functions, vector functions, etc.

 

2.      Second, it is likely that in the future users will want to describe certain object properties that will depend on the printer. Just like a HTML page needs to render differently on an ipad versus an iphone, a small feature in an object might need to adjust its thickness depending on the smallest feature size of the printer. And so on.

 

3.      Third, there may be parametric objects, for example an object that scales non-uniformly so that it can be printed correctly at a range of scales.

 

And there are many more example.

 

So the bottom line:

 

1.      I move that we rename AMF to AML  (Additive Manufacturing Language)

2.      We keep the language metaphor in mind  

 

--hod

 

 

Hod Lipson

Associate Prof. of Mechanical & Aerospace Engineering and Computing & Information Science

Cornell University, 242 Upson Hall, Ithaca NY 14853, USA

Office: (607) 255 1686 Lab: (607) 254 8940 Fax: (607) 255 1222

Email: Hod.L...@cornell.edu

Web: http://www.mae.cornell.edu/lipson

Administrative Assistant:  Craig Ryan  cd...@cornell.edu

Calendar: http://www.mae.cornell.edu/lipson/calendar.htm

 

Markus Hitter

unread,
May 15, 2013, 5:50:12 PM5/15/13
to st...@googlegroups.com

Am 15.05.2013 um 19:16 schrieb Hod Lipson:

> Fry mentioned that many standards start by thinking that they are
> going to be a static "format", but end up as a full blown
> "Language". Because they don't anticipate this endgame, they get
> there through a series of patches and extensions.
>
> The most notorious example is HTML.

Interesting point. I think the lesson learned from STL and early HTML
is, simplicity is successful.

There are also examples of formats/languages which tried to do
everything right from the beginning. Hard to find, though, as such
attempts usually fail. Predicting the future isn't possible, but
trying to do so ends up in bloat.

The mess we have now with HTML isn't, IMHO, due to the fact it
evolved at all, it's because hackers were much faster than
standardizers and also, because having a browser with certain
capabilities was a business advantage on its own is a toughly fighted
market for some time.

These days the mess settles and standardisation catches up. Likely,
because there are not two, but many browsers and developers care much
more about standard compliance accordingly. It's pointless to
introduce a new feature if only 10% of the users can actually see it.
I hope for a similar development in the 3D printing area, we already
have dozens of printers and modelling applications.

I see possible solutions for AMF:

1. Keep dynamic stuff strictly separate, allow not more than object
identifiers. Just like HTML did with JavaScript. This implies there's
always a non-dynamic fallback, so simple software can do useful
things, too.

It also means the dynamics engine is likely kept seperate from the
static rendering engine, so there's sort of an intermediate static
object - compare to the rendered HTML page at a specific point in
time - and different developments of those two engines can be mixed
with reasonable efforts.

2. Do well on static objects now, start over when dynamic object
printing - whatever that will mean - appears. Just like AMF is a
start over of STL.

In both cases there's always the possibility to have helping external
applications to modify the geometry depending on situation, so
dynamics is possible even without having it embedded in the file
format. Looks like a better solution to me for the time between
invention of a feature and its standardisation than trying to predict
inventions before they actually happened.


my $0.02
Markus Hitter


P.S. don't forget the security risks involved with any kind of
dynamic language. See virus' embedded in PDF.

- - - - - - - - - - - - - - - - - - -
Dipl. Ing. (FH) Markus Hitter
http://www.jump-ing.de/





Jacob Barhak

unread,
May 15, 2013, 6:14:22 PM5/15/13
to st...@googlegroups.com, st...@googlegroups.com
Hi Hod,

If you go open and go towards a language then you should learn from how other open languages evolved. I suggest you start with python. 

As for postscript/PDF and HTML. You are actually describing success stories that build a foundation that was adopted by many. And HTML evolved through time. If you wish AMF/AML to succeed widely you need to accept evolution rather that enforce rigidity. Moving towards openness is a good move. 

By the way, if you are going towards a language you should start from scratch, freeze AMF as it is and select only the good features from AMF and start AML only with those. 

For example, no language I know compresses its files. So you may want to loose the zip compression as part of the standard and just suggest it to users as good practice. 

Also if you are going towards a language, I assume you use a scripting language. You should consult with compiler experts - there are technologies today that are relevant even for scripting languages you may want to be aware of. 

I hope it makes sense. 

       Jacob



Sent from my iPhone
--
You received this message because you are subscribed to the Google Groups "STL 2.0" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stl2+uns...@googlegroups.com.
To post to this group, send email to st...@googlegroups.com.
Visit this group at http://groups.google.com/group/stl2?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Charles Overy

unread,
May 15, 2013, 7:36:38 PM5/15/13
to st...@googlegroups.com
>Hard to find, though
how about:  
VRML

Different renderers will show completely different scenes.  The optional inclusion of primitives really messes things up.  etc.  I have no knowledge of how that was developed but it looks like the group tried to keep too many people happy.  
 
Charles 



On Wed, May 15, 2013 at 3:50 PM, Markus Hitter <m...@jump-ing.de> wrote:
Hard to find, though



Alejandro Sklar

unread,
May 16, 2013, 2:28:50 AM5/16/13
to st...@googlegroups.com, st...@googlegroups.com
Hod,

I'm not a computer scientist, I'm an engineer looking to make 3d printing useable for the masses and i understand the undertaking is daunting.  

This will happen in steps, and I'm not sure what is the best way to fuel progress while laying a solid and reusable foundation. But I am ready to experiment, and am excited to use what the community can offer. Personally, I think moving towards a dynamic language for 3d printing will open many "doors", and I think we should be open to development of a language for printing that encompasses end use and incorporates the printing process. This is where I thought AMF was headed and where the true potential over traditional CAD/CAM and STL exists. I would love to experiment with AML and its uses, similar to creating an API for printing. This could bridge the gap between users and technical developers, and I think would be a great step forward towards adoption of the technology on a broader scale.

If anyone would like to test out experimental methods to standardize the printing process, please contact me. My team at Carnegie Mellon is currently developing a simple method for masking editing of 3d models within current CAD framework, to allow non technical users to create customized printable pieces. 

I think together we can put an end to the age old question of "what will people print?" By providing a system that yields a better answer than "whatever you want to print". 

Sent from my iPhone

Jesse McGatha

unread,
May 16, 2013, 3:22:39 AM5/16/13
to st...@googlegroups.com
You came to the exact opposite conclusion I expected. The problem, as I see it, is one of unclear goals.

If the goal is a format intended to transmit a static model to a device that makes a static object, i.e. to replace STL for printing, I would have expected the appropriate response would be to strip dynamic content from the format.

If the goal is a format intended to be an interchange format for interactive or fluid 3D models, then a language makes sense... But then the format becomes a very poor choice to transmit a specific intent to a 3D printer. This works directly counter to the goal of advancing the state of the art (STL) in actual printing scenarios.

Frankly, I believe following the route of building an inseparable language as an intrinsic and inextricable part of the AMF format will inevitably doom its relevance for printing devices.

Just want to offer a countervailing view. There are ways to split the difference, but extraordinary care will have to be employed to keep the static representation and interactive representation separate.

-Jesse McGatha

Turlif

unread,
May 17, 2013, 10:04:48 PM5/17/13
to st...@googlegroups.com
AM languages or more generally geometric design and manufacturing languages (and I do not mean CG/3D languages - see VRML/OpenGL/etc.) are a more or less a fairly compact set although they have a long history.

Most of these languages are just scratching the surface of what is possible and more robust representations and languages are clearly needed as we head more and more toward the programming and exact manipulation of physical structure and material.  The real story of AM is not distributed or even customized manufacturing but the scale at which we can now control materials/matter and, with the new found control, the ability to manufacture a new class of human made objects that can take on all kinds of different properties and behaviors from even a limited set of materials (akin to the way that nature builds).  New and exact languages are required that can truly describe real objects, their properties and relations in multi-scale (not the current representations we use for planning and visualization).

This is my field of interest and Uformia has been developing such languages and supporting frameworks on the basis of our academic group's ongoing and long standing research (in fact we often refer to our language development as a kind of a Volume PostScript), so I see something like AML as a clear need and natural outcome of AM technologies growth.  However, I would like to pose a practical "out of the gate" problem with moving AMF to AML.  XML or really any markup/meta syntax is a bad choice for building a useful shape modeling language.  There is a reason WebGL is succeeding where VRML/X3D did not.  Even cutting edge web development is near pure JS now.  Of course there are a lot of other issues to consider as well, too many to list here, but I would suggest as a starting point to consider an alternative to XML for a modeling language.  The other broad point I would make is start small and grow organically (but well organized) - i.e. create a language that is flexible enough to let the problems dictate the solutions via the language itself.

Mvh & best regards,

Turlif Vilbrandt - CTO, Uformia

.www.uformia.com
+46 090 205 76 71 (Norway/Sweden)  |  +1 425 296 1719 (US)

This message may contain information which is privileged, confidential and/or proprietary. If you are not the intended recipient, please do not disclose or use the information within this email or its attachments. If you have received this email in error, please delete it immediately.

Yoav Bressler

unread,
Jun 29, 2013, 7:42:54 AM6/29/13
to st...@googlegroups.com
בתאריך יום רביעי, 15 במאי 2013 20:16:53 UTC+3, מאת Hod Lipson:
Once a language is Turing Complete, there is no way of knowing when a file will ever stop rendering, or what it may do to your computer. Take care.

Joris

unread,
Jul 12, 2013, 10:07:46 AM7/12/13
to st...@googlegroups.com
Just an idea (I'd don't want to cause any headaches) but wouldn't it be valuable to encapsulate all of the necessary information that an object has and needs into it? So the shape, toolpath instructions, complete production process, materials but also functionality and behavior? I understand that this rather fanciful and would be akin to having a file encapsulate CSS, C, Javascript, XML and more. I would also stipulate that it is important to have a stable working AMF before forking it and starting something like this.

You could save a design for a robot. Define all the materials and show where what material needs to go, define all the process steps and the toolpaths. Then the printer(s) would print plastic on the arms, battery material where the battery needs to go, conductive material where the electrical connections are, softer material where the buttons are etc. This encapsulated information could also tell you what equipment or material would be needed for the part to be made including all relevant machine settings. And the printability of it would be assured on certain systems once it was test made skipping the need for slicing, settings and file checking. If another person than prints the object using a different machine the correct toolpath and instructions and settings for that machine would be added also. Once it has been made sucessfully another person could then change the color of the robot, easily add another arm, scale it etc. by just using the file and the relatively easy XML-type syntax. You could then even check to see if under these new parameters the new robot would work within the confines of the previous production process or check what processes could be used.

You could even include the AI or other instructions for the part/machine in the file format. You could then add revision histories showing how the file was adapted and by whom while having a development tree that would let you see how it was changed and let you roll back certain developments.

If you do it in this way you have one central registry of all the relevant data for the part in one place. AMF would then be more akin to the DNA of the object and make the object's design, functionality, behavior and production methods all (possibly parametrically) adaptable while containing all of this information in one place.

So this may seem fanciful but going forward we're going to need a DNA for machines and things right? We could call it sDNA for Stuff DNA.

Kind regards,

Joris

Jacob Barhak

unread,
Jul 14, 2013, 8:29:21 PM7/14/13
to st...@googlegroups.com
Hi Yoav,

You have a good theoretical point here. However, there is a simple practical solution here.
You can check if time exceeded a certain threshold and notify the user that this happened.

Perhaps its a good idea to think about practical language solutions that fits additive manufacturing.

I am sure the group here can resolve such issues.

Jacob

Sent from my iPhone

> --
> You received this message because you are subscribed to the Google Groups "STL 2.0" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to stl2+uns...@googlegroups.com.
> To post to this group, send email to st...@googlegroups.com.
> Visit this group at http://groups.google.com/group/stl2.

Charles Overy

unread,
Jul 16, 2013, 12:01:15 PM7/16/13
to st...@googlegroups.com
> important to have a stable working AMF
Joris, well said.
And I would like to add, well adopted.

It continues to amaze me that there are a large number of AF veterans who are unaware of the AMF effort.  I am sure most of the vast number of newcomers are also.

While an AMF language is a good end goal, it seems to me that there are tremendous advantages to implementing a clean, easy to code, AF format that merely replaces STL with an unambiguous and concise description of the intended geometry.   

As reference, this post comes as I embark yet again on debugging VRML worflows for colour printing and  wishing for just the simple things like  a consistent use of UNITS OF MEASURE....  -  A major AF software vendor writes their vrml units as "MM*10,000" .  Aghhhhh. 

Charles 


Alejandro Sklar

unread,
Aug 26, 2013, 4:20:11 AM8/26/13
to st...@googlegroups.com
Would have thought there would be more buzz on this chat about Microsoft's integration of 3D printing into Windows 8.1: http://www.3ders.org/articles/20130823-microsoft-explained-3d-printing-support-in-windows.html

It says they've been developing their own 3MF format, also xml based, for a little while now. Was this foreseen, and how do you think things will play out between 3MF and AMF? 


Jesse McGatha

unread,
Aug 26, 2013, 6:00:34 AM8/26/13
to st...@googlegroups.com
As a person behind 3MF, I can comment a bit on this. AMF was certainly reviewed as we were trying to decide the file format for the 3D print spool file format for Windows. There are a few needs here that AMF doesn't quite address:

1) Streaming scenarios, where the file can be processed serially by a driver, even when being transmitted over a network (think branch offices or print servers).

2) Packaging flexibility. Current spec does not allow for OPC-based container, a min bar for the Windows spooler.

3) Versioning. Current spec has inadequate forward and backward versioning capabilities. This ties into XML namespace discussions.

4) Extensibility & Metadata. Current spec has no extensibility and limited metadata capabilities. Consequently, it cannot support embedding print pipeline job metadata, for example.

5) Model description objectivity. AMF is not positioned as a format that exactly describes the object to be created independent of algorithms, formulas, and other programmatic instructions that define how to derive or construct the model instead of what the model actually is. Recent discussions have been pushing even more heavily in this direction. Practically speaking, this means dozens of independent implementations that all result in identical output with perfect programmatic behavior and mathematic accuracy... A tall order. Also note that programmatic capabilities become a vector for malicious attacks.

6) Focus on additive only. When adding a 3D output capability to Windows, it needs to also support subtractive as well, e.g. CNC mills or laser cutters. The latter requires a slice format, which AMF also lacks.

7) Markup compactness. There are a number of issues around markup compactess, notably inline textures and verbose element hierarchies.

8) Security issues. In addition to the afore-mentioned programmatic attack vectors, AMF is susceptible to known DTD security exploits, since DTDs are not prohibited.

Note, the above list is also not comprehensive. These issues do not necessarily mean that AMF is bad or wrong; it is simply focused on a different problem. This is likely reflected in the low interest all of these issues have garnered as I brought them up to this group. I would like to see some of these issues resolved over time. Indeed, other concerns not mentioned above were alleviated by the spec feedback that has already been incorporated. The most important current gap, in my mind, is the lack of a defined XML namespace for AMF. This, plus some careful metadata selection, could allow AMF data to be transformed and printed on Windows by even an AMF-unaware device, yet allow an AMF-aware device full access to transform the data back into AMF.

Regardless, AMF looks to be on a path to be a powerful on-disk format, while 3MF was designed with the needs of a print pipeline foremost.

-Jesse

Alejandro Sklar

unread,
Aug 26, 2013, 6:50:55 AM8/26/13
to st...@googlegroups.com
You bring up the slicing for CNC, but this also applies to 3DP. Microsoft's video shows that users will be able to specify fill and other basic print settings through Windows. Is Microsoft using 3D system's slicing engine to generate the printhead toolpath? Will application designers be able to get around Microsoft's built-in slicing engine and generate their own toolpaths before initiating a print with the Windows spooler? The spooler would then just be used to send the specified machine's bitcode serially to the supported printer. I bring it up because there are definitely some printing functionality developers might want to be able to specify, and it would be great to be able to communicate this information to the Windows spooler.


--
You received this message because you are subscribed to the Google Groups "STL 2.0" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stl2+uns...@googlegroups.com.
To post to this group, send email to st...@googlegroups.com.
Visit this group at http://groups.google.com/group/stl2.
For more options, visit https://groups.google.com/groups/opt_out.

Jonathan Hiller

unread,
Aug 26, 2013, 11:59:20 AM8/26/13
to st...@googlegroups.com
I think discussion has been limited because of the limited available concrete information on 3df so far.

Based on the blog posts/videos/Jesse's information above I agree with Jesse. 3mf seems to fills a primarily different niche than AMF: it describes how to build an object for specific (microsoft supported) 3d printers/cnc machines.  If I understand correctly then, 3df files are not suitable to be distributed unless perhaps among users of the same printer model/version. In contrast, the over-arching goal of AMF is to be a general interchange format.

The main implication I see for AMF is that users on a compatible version of Windows, using supported software, and printing only on a supported local 3d printer would never generate AMF, and in fact will have all intermediate file formats abstracted away from them. That's a good thing. But everyone else will still need a general interchange format.

Jesse, please chime in if I made any incorrect assumptions. Concrete info appreciated.

  ~Jon

ps. I will point out that "discussion towards" making amf more programmatic and that being in the spec are two different things. So far the only programmatic nature of AMF that has been approved is equations. These are unambiguous and (to the best of my limited knowledge) easy to sandbox from being a security threat. Jesse summarizes several valid issues that would, of course, need to be adequately addressed before any greater programming ability is included in the AMF spec.

pss. XML namespace is important. Has there been any progress on this? Please start a separate thread if so.


Jacob Barhak

unread,
Aug 26, 2013, 3:41:28 PM8/26/13
to st...@googlegroups.com
Hi Jesse,

Does the 3MF format has any parallelism in mind? 

In other words does it support multiples processors/machines? Or does it ignore such matters leaving decisions to other levels and only deals with a single machine model - like in a regular 2D printer?

I was happy to see that some elements in 3MF were previously discussed in this group.

        Jacob

Sent from my iPhone

Daid

unread,
Aug 27, 2013, 3:34:36 AM8/27/13
to st...@googlegroups.com
As for 4), that's the main issue I have with AMF as storage&sharing format. I already build in basic AMF support into Cura (loading and saving, with multi materials, but no curved triangles) but while I currently follow the standard we already decided to include none-standard meta-data if we need this. Not having a provision for this assures that everyone will do this in a different way. Instead of the intended idea that there would be no custom meta data. There is a need for this, ignoring it won't take the need away.

Sorry, but for 6), having a same format for lasercutting and 3D models is a bit beyond stupidity. These are two very different machines and is like adding an ice machine to your coffee maker. A lasercutter does not do 3D, it does 2D. And generating a milling path from a AMF file can surely be done, but usually milling toolpaths are quite complex and I think some extra meta data would be useful here. But I do not know a lot about 3D milling. 2D or 2.5D milling follows a lot of the same rules as lasercutting. With making 1 format you are basicly putting 2 different formats in 1 file, adding unneeded complexity and error scenarios.

Jesse McGatha

unread,
Aug 27, 2013, 3:59:17 AM8/27/13
to st...@googlegroups.com
Slicing will take place in the driver. As such, the hardware manufacturer is free to use their own slicing technology in the driver package. The settings the user selected are included in the 3d spool file and the driver must apply these settings to alter its slicing behavior.
 
We feel that drivers are responsible for transforming the 3MF spool file into their device's specific PDL (e.g. gcode). Apps should describe *what* they want to make, the driver decides *how* to make it. This is, in our experience the best possible partnership between apps and devices. The devices that are the best at this will win out in the market versus other devices. That said, if a hardware vendor has its own software and wants to communicate some specific PDL from its app to its device, or if a hardware vendor wants to receive PDL from apps, these apps may communicate that PDL to the device *in addition* to the standard model data. This is to account for the fact that print administrators may re-direct spool files from one queue to another in the future for load-balancing or to remove a queue from service.
 
-Jesse

Jesse McGatha

unread,
Aug 27, 2013, 4:05:37 AM8/27/13
to st...@googlegroups.com
The 3MF format describes a model, but not in a PDL specific to the device. Basically, we had to have a single format that apps could communicate to the Windows spooler. That spool file could not be specific to any one device until the spooler de-spooled the job to a particular device. At this point the driver has the opportunity to transform the 3MF data into whatever PDL it desires. Note this is exactly the same way 2D printing has worked on Windows since 2006. The same infrastructure has been leveraged, from the spooler, to print queues, to driver architecture, to plug and play.
 
While 3MF was designed as a spool file format, it is fundamentally a file, as dictated by the architecture of the Windows spooler. As such, it theoretically could stand alone as an on-disk file format, but that was not the principal use case.
 
-Jesse

Jesse McGatha

unread,
Aug 27, 2013, 4:13:02 AM8/27/13
to st...@googlegroups.com
It is not baked into the format, but certain optimizations can pre-process data to make it suitable for parallelism, e.g. in slicing in a driver. The architecture follows the Windows 2D architecture, so parallelism would be introduced in the driver as in 2D.
 
-Jesse

Jesse McGatha

unread,
Aug 27, 2013, 4:18:19 AM8/27/13
to st...@googlegroups.com
Slices have been discussed in this group as a valuable feature for AMF. In 3MF these have been included, leveraging the existing SVG-like syntax for 2D geometries defined in the XPS format, which incidentally has been used for some time to drive laser cutters. I would suggest it would be beneficial for AMF to adopt this same format (described in the OpenXPS spec, with one addition for segment color definition) for its slices feature.
 
-Jesse
Reply all
Reply to author
Forward
0 new messages