AMF or AML: A format or a language?
Hod Lipson
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
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.
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
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
Alejandro Sklar
Sent from my iPhone
Jesse McGatha
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
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)
Yoav Bressler
Joris
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
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.
Charles Overy
Alejandro Sklar
Jesse McGatha
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
--
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
Jacob Barhak
Sent from my iPhone
