AMF export (and import)
I have done a couple of tests of AMF export from OpenSCAD, and find that
it appears to work ok.
A minor issue is that OpenSCAD AMF files are written with an extra blank
line after every line with data and some of the tags are located in odd
places. However, this still works with most XML parsers as it does with
mine. It could be made to appear more finished though, by removing the
blank lines.
When testing the AMF files in netfabb basic, the ones I checked seem to
be ok.
An interesting thing is that in an unreleased test version of
AngelScript CSG, one can do export and import of AMF. Here is an import
example:
solid@ thing = polyhedron(filepath:"nut_and_bolt.amf");
This will import the first object in the AMF file. Alternatively, if
there are more objects, for example a nut (id 0) and a bolt (id 1):
solid@ nut = polyhedron(filepath:"nut_and_bolt.amf",id:0);
solid@ bolt = polyhedron(filepath:"nut_and_bolt.amf",id:1);
I was able to import OpenSCAD AMFs this way. I think it would be nice to
have similar capabilities in OpenSCAD, for example to import the nut:
import(file="nut_and_bolt.amf", id=1);
Importing AMF is easier and safer than STL, since it contains ready made
polyhedrons with no need to compare coordinates.
Carsten Arnholm
On 04/04/2016 11:36 PM, Carsten Arnholm wrote:
I was able to import OpenSCAD AMFs this way. I think it would be nice to have
similar capabilities in OpenSCAD.
The pull request for that is a bit stuck behind the SVG import as both
use the same library setup. I guess we have to untangle that or finally
decide how to go on with the SVG import.
Importing the objects separately is a good point, not sure how to
do that in a nice way yet. DXF has something similar with layers.
ciao,
Torsten.
Hi Carsten. I've been thinking about AMF import, over here:
https://github.com/openscad/openscad/issues/1608
My plan is to import all of the objects in an AMF file, preserving the
object ids as "part names". An AMF object can contain multiple volumes,
labelled with different materials and colors, and those will be kept
distinct as well.
import("nut_and_bolt.amf")
You can select an individual part by name using
select_part("1") import("nut_and_bolt.amf")
I haven't documented select_part() yet, but it enables a number of
interesting programming idioms.
This also works for multiple layers in a DXF file.
Doug.
On 4 April 2016 at 17:36, Carsten Arnholm arnholm@arnholm.org wrote:
I have done a couple of tests of AMF export from OpenSCAD, and find that
it appears to work ok.
A minor issue is that OpenSCAD AMF files are written with an extra blank
line after every line with data and some of the tags are located in odd
places. However, this still works with most XML parsers as it does with
mine. It could be made to appear more finished though, by removing the
blank lines.
When testing the AMF files in netfabb basic, the ones I checked seem to be
ok.
An interesting thing is that in an unreleased test version of AngelScript
CSG, one can do export and import of AMF. Here is an import example:
solid@ thing = polyhedron(filepath:"nut_and_bolt.amf");
This will import the first object in the AMF file. Alternatively, if there
are more objects, for example a nut (id 0) and a bolt (id 1):
solid@ nut = polyhedron(filepath:"nut_and_bolt.amf",id:0);
solid@ bolt = polyhedron(filepath:"nut_and_bolt.amf",id:1);
I was able to import OpenSCAD AMFs this way. I think it would be nice to
have similar capabilities in OpenSCAD, for example to import the nut:
import(file="nut_and_bolt.amf", id=1);
Importing AMF is easier and safer than STL, since it contains ready made
polyhedrons with no need to compare coordinates.
Carsten Arnholm
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Hi Doug,
Thanks for the reference, interesting (long) discussions. Good to see
that AMF is "on the table". You are right that the issue of different
materials (I see color as mostly a property of material) will come up
this way. The select_part("1") import("nut_and_bolt.amf"); syntax looks
like it is doing much the same as in my AngelScript implementation, so
that looks quite nice.
A useful thing would be if one could make a multi part model, export it
as AMF and successfully "round trip" it between OpenSCAD and for example
AngelScript CSG. Practical interoperability between applications is
important, and better AMF support would help in this regard.
@Torsten: I saw your comment earlier. I don't know SVG in much detail,
but from what I have seen it appears that SVG and AMF are rather
different animals and I would suggest treating them separately, and pick
the lowest hanging fruit first (AMF).
Carsten Arnholm
On 2016-04-05 01:58, doug moen wrote:
Hi Carsten. I've been thinking about AMF import, over here:
https://github.com/openscad/openscad/issues/1608 [2]
My plan is to import all of the objects in an AMF file, preserving the
object ids as "part names". An AMF object can contain multiple
volumes, labelled with different materials and colors, and those will
be kept distinct as well.
import("nut_and_bolt.amf")
You can select an individual part by name using
select_part("1") import("nut_and_bolt.amf")
I haven't documented select_part() yet, but it enables a number of
interesting programming idioms.
This also works for multiple layers in a DXF file.
Doug.
On 04/05/2016 10:51 AM, arnholm@arnholm.org wrote:
@Torsten: I saw your comment earlier. I don't know SVG in
much detail, but from what I have seen it appears that SVG
and AMF are rather different animals and I would suggest
treating them separately, and pick the lowest hanging fruit
first (AMF).
Yeah, it's basically all the build system stuff they share,
otherwise there's not much relation.
Although there's another option for import/export and that's
3MF. It can collect a number of plus points over AMF, mainly
open and freely accessible specification and now also a
working library that is usable on multiple platforms. The
interaction regarding changes/bugfixes was not brilliant,
but my simple build system patch got in and the libzip issue
on Linux about reading files generated on Windows is now also
closed.
ciao,
Torsten.