ASTM AMF subcommittee ballot successful

[Hod Lipson]

Hello all,

I am pleased to report that the ASTM subcommittee ballot on AMF has
just completed with 100% affirmative votes: 27 Positive, 6
abstentions, and 0 negatives. There was one unofficial negative vote
(from a new member that joined after the balloting had started). This
participation represents 61% voting rate. The current draft is
available here: http://ccsl.mae.cornell.edu/amf

Based on ASTM rules, the ballot continues automatically to be voted by
the entire F42 committee. However, I have asked ASTM to hold off on
the balloting to give us time to reflect on the negative vote and
other comments received. Here is a summary of the public comments
(quoted verbatim or summarized in one sentence):

Comment 1: "It is my concern that while AMF is a vast improvement
over STL, the passing of this draft will halt any movement toward the
use of a STEP file. The AMF is still an approximation"

Comment 2: "Please correct error regarding lack of mention of
coloring of triangles in section 8."

Comment 3:: [Suggested more compact representation of coordinates]

Comment 4:: [concerned about curved triangles and would like to see
more evidence of their performance]

Comment 5:: [various concerns, including reliability of curved
triangles, lack of option for custom extensions]

Comment 6:: [requested option for non volumetric geometry: shells
and lines]

Negative 1: [Suggests further exploration of alternative
representations such as voxel representations and layer based
representations]

I would encourage those who made the comments above to elaborate if
necessary, and for others to comment as well. If you would like to
speak to me directly, you can reach me any time at +1 (607) 592 4383
(cell) or by email at hod.l...@cornell.edu

Thanks
--hod

[Mario Domingo Monzón Verona]

Congratulations Hod, AMF is an important step for Additive
manufacturing and all the people working in this field. Good job!

Regards

Mario

Hod Lipson <hod.l...@cornell.edu> escribió:

> --
> You received this message because you are subscribed to the Google
> Groups "STL 2.0" group.
> To post to this group, send email to st...@googlegroups.com.
> To unsubscribe from this group, send email to
> stl2+uns...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/stl2?hl=en.
>
>

[jiquan]

Hi Hod,

Thanks for your great contribution to this field. Hope to see more features added in your future revisions.

Three cheers! 

yours,

Jiquan Y., and Fadel G.M.  

[Turlif]

Hi Hod,

On comment 5 - lack of option for custom extensions - I will simply
post the comments from the balloting here for more open discussion:

"black box" functionality extensions should be officially supported by
some mechanism other than "unofficial" extensions of the XML standard
- e.g. Externproto in VRML or the component/profile system of 3XD.
This will both allow for play/innovation and create a "living/active"
standard leading to rapid improvements.

BR, .t

[Jenny Buck]

There is a vein of conversation building on the edge of this group, based on
concerns from end-product-design issues, that appears to be pointing to the
need for layer as an option in addition to mesh/triangle. There will be
more on this soon. My larger concerns about the risk of stifling
innovation particularly in AM output would be reduced, though, if there were
a way to keep this standard living/ active/ iterative. I know product
design, not software, but I'm very interested if I'm correctly interpreting
what you're proposing below.
Best to all,
j

Hi Hod,

BR, .t

--

[Hod Lipson]

I think that a layer-based representation is a bad idea because it is process-dependent. For inkjet processes you would need a layer for every 16 microns; for FDM you would need a different spacing. Whatever spacing you choose, a machine could come out that would have a different spacing or even non-uniform spacing. And interpolating between layers is a computational nightmare.

Furthermore, layers are an inefficient way to describe an object because they do not take advantage of regular geometry. If you wanted to print a 1-inch cube in 16 microns layers, you would need 1500 layers. They are also orientation dependent.

Also, how do you represent graded materials and colors in a layer representation?

It is critical that AMF is process independent, like STL was. I think that there is merit to other representations like Voxel and Function Representation (which should be included in future revisions of AMF), but not Layers.

--hod

[Jenny Buck]

I'm sharing Scott's response on the further layer conversations here.
Gonzalo, Patrick & Scott, I do want you to get this so you know what I did &
didn't nail in my consolidation & interpretation, but please speak up
immediately you want to be pulled from this ongoing circulation so we do not
flood your inbox:

Hi -
I don't know about layers - when I send a file, it's just a solid chunk. My
main schtick is that the triangles kill the design. That the tech has to
move in the direction of slicing directly from an IGES, STEP or eventually a
solid file (from Pro/e or Solidworks). Once that happens, we'll be able to
get much closer to consumer-quality, which will be where the real
breakthroughs are.
Scott

[Hod Lipson]

But XML naturally supports extensions. You can just start using some new element (e.g. <FRep>) and when you are ready you can propose it as a standard. Parsers that dont recognize it will just ignore it. Why would you need a black box?

--hod

-----Original Message-----
From: st...@googlegroups.com [mailto:st...@googlegroups.com] On Behalf Of Turlif
Sent: Thursday, March 17, 2011 12:10 AM
To: STL 2.0
Subject: Re: ASTM AMF subcommittee ballot successful

Hi Hod,

BR, .t

--

[Gonzalo Martinez]

Hi Hod,

We are in agreement about the slicing might not be right approach as each machine out there has a different requirement for the spacing between each slice. Furthermore future machines might have different requirements as well.

Gonzalo

Gonzalo Martinez
Director, Strategic Research
Office of the CTO 

Autodesk, Inc.
1 Market Street, Suite 500
San Francisco, CA 94105

Direct 415 547-2031
Mobile 415 341-7588

-----Original Message-----
From: Hod Lipson [mailto:hod.l...@cornell.edu]
Sent: Thursday, March 17, 2011 2:55 PM
To: st...@googlegroups.com

Cc: tur...@uformiaworld.com; Kulk...@3DSystems.Com; Gonzalo Martinez; dun...@3dsystems.com; summ...@pacbell.net
Subject: Layers are process dependent

[Jenny Buck]

I need more info, but yes I'm leaning the same direction. As noted, my
consolidation & interpretation of potential options over the past 24 hours
had its issues as a non-software person. We still have a serious problem at
the design output side, though, that we aren’t addressing with this standard
yet. I still feel it's crucial we generate a solid aim as to how we're
tackling that, & that we're a lot surer than we are today that it will
actually work.

[Kulkarni, Rajeev]

All,

In my view, layer based representation is not the most ideal form to represent a 3D model. While the STL format itself is very limiting, a layer based format is further restrictive.

The fundamental difference is as follows:

STL and/or even a native CAD format defines the surface of the object. This could be the a geometric definition, surface property definition, color definition, etc. etc. In all these formats, the external surface is being defined.

A layer based format predominantly defines the "internals" of the object and not the external surface. The external surface is approximately based on the contour profiles and hence it is a 2.5D format at best. 3D Systems already has a SLC format that has been made public a long time ago and used widely in the medical and jewelry industry. It works for them as they native data originates from MRI, CT Scan data and hence adopting the SLC for RP purpose is quite natural. This format does not work well for other mainstream applications due to lack of surface definitions.

Additionally, as data is manipulated, the level of approximations required when managing a surface based format are quite less that those required to make a layer based format work. With these manipulations, the final object being fabricated is moving further and further away from the original definition of the object.

Hence, in my view, an enriched STL format (or a simple surface format) is the right approach.

Rajeev Kulkarni
VP of Global R&D
3D Systems

[Duane Storti]

If you do not mind another voice joining the conversation, and I would
like to offer the comment that describing the "internals" should become
more and more relevant as we move forward, not only in terms of
integration of volumetric imaging (IBM's estimate indicates that we have
already reached the point where 30% of all digitally stored data is
comprised of medical imaging) but also in terms of fabricating with
inhomogeneous or spatially-controlled materials.

As an example, let me briefly describe a recent project aimed at
producing brain phantoms (models for scanner calibration) that needed to
be fabricated with radioactive source material selectively deposited
throughout the interior in a manner that would match up with
measurements of patients at various stages of Alzheimer's. A standard 3D
printer suffices to do this job, but not using the standard software and
STL files. What is required is the ability to print a stack of images,
and my colleague managed to create a hack that made this possible. Other
than using radioactive ink (which we probably do not want everyone
doing), this seems like the sort of thing we should be looking to
support without the necessity of hacking the system.

Finally, let me address the general issue of a layered object
description. The layers in the description need not be tied directly to
the fabrication layers, so supporting a layered description should not
impose any limitation on fabrication approaches as long as there are
tools available for determining the properties needed for slicing,
support generation, or whatever other functions are required. Also, if
you think in terms of implicit or function-based models, a layered
description (e.g. a model based on an image stack) need not be limited
to representing 2.5D. Appropriate use of simple interpolants enables
full 3D modeling, and the fabricated part need be no further from the
original model than in the traditional approach using external surface
models and/or STL files. In fact, we have seen cases where the
fabricated part quality is actually enhanced by avoiding unnecessary
triangulation.

Duane Storti
Mechanical Engineering
University of Washington-Seattle
Co-Director Solheim Rapid Manufacturing lab

On 3/22/2011 1:28 PM, Kulkarni, Rajeev wrote:
> All,
>
> In my view, layer based representation is not the most ideal form to represent a 3D model. While the STL format itself is very limiting, a layer based format is further restrictive.
>
> The fundamental difference is as follows:
>
> STL and/or even a native CAD format defines the surface of the object. This could be the a geometric definition, surface property definition, color definition, etc. etc. In all these formats, the external surface is being defined.
>
> A layer based format predominantly defines the "internals" of the object and not the external surface. The external surface is approximately based on the contour profiles and hence it is a 2.5D format at best. 3D Systems already has a SLC format that has been made public a long time ago and used widely in the medical and jewelry industry. It works for them as they native data originates from MRI, CT Scan data and hence adopting the SLC for RP purpose is quite natural. This format does not work well for other mainstream applications due to lack of surface definitions.
>
> Additionally, as data is manipulated, the level of approximations required when managing a surface based format are quite less that those required to make a layer based format work. With these manipulations, the final object being fabricated is moving further and further away from the original definition of the object.
>
> Hence, in my view, an enriched STL format (or a simple surface format) is the right approach.
>
> Rajeev Kulkarni
> VP of Global R&D
> 3D Systems
>
>
>
>
> -----Original Message-----
> From: Jenny Buck [mailto:jebu...@yahoo.com]
> Sent: Thursday, March 17, 2011 9:09 PM
> To: st...@googlegroups.com; 'Hod Lipson'
> Cc: tur...@uformiaworld.com; Kulkarni, Rajeev; Dunne, Patrick; summ...@pacbell.net
> Subject: RE: Layers are process dependent
>

> I need more info, but yes I'm leaning the same direction. As noted, my consolidation& interpretation of potential options over the past 24 hours had its issues as a non-software person. We still have a serious problem at the design output side, though, that we aren't addressing with this standard yet. I still feel it's crucial we generate a solid aim as to how we're tackling that,& that we're a lot surer than we are today that it will actually work.

[jcunningham]

I'm not sure that layers are any more process dependent than pixels
are in raster image formats, though voxels are obviously the more
appropriate analog to pixels. In the 2D world, there are separate
file formats for raster and vector images, and maybe that would be a
better path to follow here too. There are container formats that can
hold both raster and vector images, but usually not both
representations for a single image.

-jeff