discuss@lists.openscad.org

OpenSCAD general discussion Mailing-list

View all threads

New 3MF file format

AP
Andrew Plumb
Sat, May 2, 2015 2:16 PM

Thanks for summarizing what I’ve been mulling over in my head.

I’m going to comment+close the Issue with something to this effect.

Andrew.

On May 1, 2015, at 11:29 PM, MichaelAtOz oz.at.michael@gmail.com wrote:

My 2c worth is that we will need something to support multiple
materials/colours real soon, colour printing is already a reality on
Shapeways etc, and with things like the Diamond head, let alone multi-head
printers now, will have demand for multi-stuff now.

Given AMF export is implemented in OpenSCAD and in slicers, should the focus
be on implementing multi-stuff-ability in OpenSCAD using AMF, rather than
expanding to other formats and still not be able to make multi-stuff?


Unless specifically shown otherwise above, my contribution is in the Public Domain; To the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. This work is published globally via the internet. :) Inclusion of works of previous authors is not included in the above.

The TPP is no simple “trade agreement.”  Fight it! http://www.ourfairdeal.org/

View this message in context: http://forum.openscad.org/New-3MF-file-format-tp12525p12543.html
Sent from the OpenSCAD mailing list archive at Nabble.com.


OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

Thanks for summarizing what I’ve been mulling over in my head. I’m going to comment+close the Issue with something to this effect. Andrew. > On May 1, 2015, at 11:29 PM, MichaelAtOz <oz.at.michael@gmail.com> wrote: > > My 2c worth is that we will need something to support multiple > materials/colours real soon, colour printing is already a reality on > Shapeways etc, and with things like the Diamond head, let alone multi-head > printers now, will have demand for multi-stuff now. > > Given AMF export is implemented in OpenSCAD and in slicers, should the focus > be on implementing multi-stuff-ability in OpenSCAD using AMF, rather than > expanding to other formats and still not be able to make multi-stuff? > > > > ----- > Unless specifically shown otherwise above, my contribution is in the Public Domain; To the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. This work is published globally via the internet. :) Inclusion of works of previous authors is not included in the above. > > The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ > -- > View this message in context: http://forum.openscad.org/New-3MF-file-format-tp12525p12543.html > Sent from the OpenSCAD mailing list archive at Nabble.com. > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
TP
Torsten Paul
Sat, May 2, 2015 5:29 PM

On 05/02/2015 05:29 AM, MichaelAtOz wrote:

Given AMF export is implemented in OpenSCAD and in slicers, should the focus
be on implementing multi-stuff-ability in OpenSCAD using AMF, rather than
expanding to other formats and still not be able to make multi-stuff?

Right, I agree the functionality would be much more useful than just
another import/export format. But then I think the effort spent on a
simple exporter would be not too big, I guess the biggest thing is to
find a nice cross platform solution to read/write the ZIP file (which
would come in useful for AMF handling too).

Still, I guess the best strategy for now is to sit back, fetch some
popcorn and watch what happens :-).

ciao,
Torsten.

On 05/02/2015 05:29 AM, MichaelAtOz wrote: > Given AMF export is implemented in OpenSCAD and in slicers, should the focus > be on implementing multi-stuff-ability in OpenSCAD using AMF, rather than > expanding to other formats and still not be able to make multi-stuff? > Right, I agree the functionality would be much more useful than just another import/export format. But then I think the effort spent on a simple exporter would be not too big, I guess the biggest thing is to find a nice cross platform solution to read/write the ZIP file (which would come in useful for AMF handling too). Still, I guess the best strategy for now is to sit back, fetch some popcorn and watch what happens :-). ciao, Torsten.
F
frankv
Wed, May 27, 2015 7:02 AM

A skim through http://bit.ly/1KqwpFU suggests that the "royalty-free patent
license" requires a "conformant application" to be produced, and I have no
doubt that "conformant" will require DRM, so that a 3MF derivative without
DRM would be subject to lawsuits and monetization.

--
View this message in context: http://forum.openscad.org/New-3MF-file-format-tp12525p12755.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

A skim through http://bit.ly/1KqwpFU suggests that the "royalty-free patent license" requires a "conformant application" to be produced, and I have no doubt that "conformant" will require DRM, so that a 3MF derivative without DRM would be subject to lawsuits and monetization. -- View this message in context: http://forum.openscad.org/New-3MF-file-format-tp12525p12755.html Sent from the OpenSCAD mailing list archive at Nabble.com.
BC
Bob Cousins
Wed, May 27, 2015 9:28 AM

The DRM relevant features of the spec are all optional, the only required
part is the 3D model. So I think a conformant implementation need not
process any DRM.

I understand there is great suspicion of Microsoft, but in my reading 3MF
is a genuinely open spec, there are no strings attached. It actually makes
clear it is royalty free, unlike AMF. It also can be freely downloaded,
unlike AMF which costs $49 and you have to agree to inspection of your
premises and computer systems by a third party to ensure you are complying
with the copyright (i.e. not made ANY copies), otherwise the agreement is
cancelled and you must destroy all copies.

Personally I find it a lot easier to implement 3MF than AMF.

On 27 May 2015 at 08:02, frankv drifter.frank@gmail.com wrote:

A skim through http://bit.ly/1KqwpFU suggests that the "royalty-free
patent
license" requires a "conformant application" to be produced, and I have no
doubt that "conformant" will require DRM, so that a 3MF derivative without
DRM would be subject to lawsuits and monetization.

--
View this message in context:
http://forum.openscad.org/New-3MF-file-format-tp12525p12755.html
Sent from the OpenSCAD mailing list archive at Nabble.com.


OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

The DRM relevant features of the spec are all optional, the only required part is the 3D model. So I think a conformant implementation need not process any DRM. I understand there is great suspicion of Microsoft, but in my reading 3MF is a genuinely open spec, there are no strings attached. It actually makes clear it is royalty free, unlike AMF. It also can be freely downloaded, unlike AMF which costs $49 and you have to agree to inspection of your premises and computer systems by a third party to ensure you are complying with the copyright (i.e. not made ANY copies), otherwise the agreement is cancelled and you must destroy all copies. Personally I find it a lot easier to implement 3MF than AMF. On 27 May 2015 at 08:02, frankv <drifter.frank@gmail.com> wrote: > A skim through http://bit.ly/1KqwpFU suggests that the "royalty-free > patent > license" requires a "conformant application" to be produced, and I have no > doubt that "conformant" will require DRM, so that a 3MF derivative without > DRM would be subject to lawsuits and monetization. > > > > -- > View this message in context: > http://forum.openscad.org/New-3MF-file-format-tp12525p12755.html > Sent from the OpenSCAD mailing list archive at Nabble.com. > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >
DM
doug moen
Wed, May 27, 2015 11:34 AM

The only version of the AMF spec that I've studied is the 0.47 draft from
this URL:

http://creativemachines.cornell.edu/sites/default/files/AMF_V0.47.pdf

If there are substantive differences in the $49 version, I have no way of
finding about them. The legal risks involved in obtaining the actual
standard sound too high. If I create a context diff comparing 0.47 with
1.0, I'm breaking the law. On the other hand, most of the other people
implementing AMF are probably also basing their implementation on V0.47, so
whatever text happens to be in the pay version of the AMF standard probably
doesn't matter all that much.

I agree that Microsoft has done a better job, in making their standard
freely available and explicitly royalty free.

On 27 May 2015 at 05:28, Bob Cousins bobcousins42@googlemail.com wrote:

The DRM relevant features of the spec are all optional, the only required
part is the 3D model. So I think a conformant implementation need not
process any DRM.

I understand there is great suspicion of Microsoft, but in my reading 3MF
is a genuinely open spec, there are no strings attached. It actually makes
clear it is royalty free, unlike AMF. It also can be freely downloaded,
unlike AMF which costs $49 and you have to agree to inspection of your
premises and computer systems by a third party to ensure you are complying
with the copyright (i.e. not made ANY copies), otherwise the agreement is
cancelled and you must destroy all copies.

Personally I find it a lot easier to implement 3MF than AMF.

On 27 May 2015 at 08:02, frankv drifter.frank@gmail.com wrote:

A skim through http://bit.ly/1KqwpFU suggests that the "royalty-free
patent
license" requires a "conformant application" to be produced, and I have no
doubt that "conformant" will require DRM, so that a 3MF derivative without
DRM would be subject to lawsuits and monetization.

--
View this message in context:
http://forum.openscad.org/New-3MF-file-format-tp12525p12755.html
Sent from the OpenSCAD mailing list archive at Nabble.com.


OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

The only version of the AMF spec that I've studied is the 0.47 draft from this URL: http://creativemachines.cornell.edu/sites/default/files/AMF_V0.47.pdf If there are substantive differences in the $49 version, I have no way of finding about them. The legal risks involved in obtaining the actual standard sound too high. If I create a context diff comparing 0.47 with 1.0, I'm breaking the law. On the other hand, most of the other people implementing AMF are probably also basing their implementation on V0.47, so whatever text happens to be in the pay version of the AMF standard probably doesn't matter all that much. I agree that Microsoft has done a better job, in making their standard freely available and explicitly royalty free. On 27 May 2015 at 05:28, Bob Cousins <bobcousins42@googlemail.com> wrote: > The DRM relevant features of the spec are all optional, the only required > part is the 3D model. So I think a conformant implementation need not > process any DRM. > > I understand there is great suspicion of Microsoft, but in my reading 3MF > is a genuinely open spec, there are no strings attached. It actually makes > clear it is royalty free, unlike AMF. It also can be freely downloaded, > unlike AMF which costs $49 and you have to agree to inspection of your > premises and computer systems by a third party to ensure you are complying > with the copyright (i.e. not made ANY copies), otherwise the agreement is > cancelled and you must destroy all copies. > > Personally I find it a lot easier to implement 3MF than AMF. > > On 27 May 2015 at 08:02, frankv <drifter.frank@gmail.com> wrote: > >> A skim through http://bit.ly/1KqwpFU suggests that the "royalty-free >> patent >> license" requires a "conformant application" to be produced, and I have no >> doubt that "conformant" will require DRM, so that a 3MF derivative without >> DRM would be subject to lawsuits and monetization. >> >> >> >> -- >> View this message in context: >> http://forum.openscad.org/New-3MF-file-format-tp12525p12755.html >> Sent from the OpenSCAD mailing list archive at Nabble.com. >> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> > > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > >
TP
Torsten Paul
Wed, May 27, 2015 12:16 PM

Von: "doug moen" doug@moens.org

On the other hand, most of the other people implementing AMF are probably
also basing their implementation on V0.47, so whatever text happens to be
in the pay version of the AMF standard probably doesn't matter all that much.

Actually there are some details that are fairly important for interoperability
across different programs. In general the file structure is pretty well
explained in Wikipedia and most information (especially the XML schema is
freely available).
Also Hod Lipson, technical contact and ASTM F42 Task group chair is pretty
helpful and also answers specific questions in the google group. Unfortunately
he failed to convince others to make the specification freely available.
This is likey an ASTM/ISO issue and not related to the actual specification,
but still it's hugely annoying.

From what I know, both cura and slic3r implementations are not based on the

released spec version. Last time I looked, the netfabb implementation did
not follow the specification regarding the actual file storage when using
ZIPed format.

On 27 May 2015 at 05:28, Bob Cousins <bobcousins42@googlemail.com[bobcousins42@googlemail.com]> wrote:
 > Personally I find it a lot easier to implement 3MF than AMF.

I can't see much difference there and AMF is pretty trivial when ignoring
the curved triangles (where I'm still not convinced that's extremely useful,
especially due to the fixed 5 level recursion, but I might be wrong here
as I did not dig into the details).

And basic AMF support is already implemented, the export is included in
the release version. The restrictions are mainly coming from limitations
present in current OpenSCAD and are not related to AMF.

ciao,
Torsten.

Von: "doug moen" <doug@moens.org> > On the other hand, most of the other people implementing AMF are probably > also basing their implementation on V0.47, so whatever text happens to be > in the pay version of the AMF standard probably doesn't matter all that much. > Actually there are some details that are fairly important for interoperability across different programs. In general the file structure is pretty well explained in Wikipedia and most information (especially the XML schema is freely available). Also Hod Lipson, technical contact and ASTM F42 Task group chair is pretty helpful and also answers specific questions in the google group. Unfortunately he failed to convince others to make the specification freely available. This is likey an ASTM/ISO issue and not related to the actual specification, but still it's hugely annoying. >From what I know, both cura and slic3r implementations are not based on the released spec version. Last time I looked, the netfabb implementation did not follow the specification regarding the actual file storage when using ZIPed format. > On 27 May 2015 at 05:28, Bob Cousins <bobcousins42@googlemail.com[bobcousins42@googlemail.com]> wrote: > > Personally I find it a lot easier to implement 3MF than AMF. > > I can't see much difference there and AMF is pretty trivial when ignoring the curved triangles (where I'm still not convinced that's extremely useful, especially due to the fixed 5 level recursion, but I might be wrong here as I did not dig into the details). And basic AMF support is already implemented, the export is included in the release version. The restrictions are mainly coming from limitations present in current OpenSCAD and are not related to AMF. ciao, Torsten.
TP
Torsten Paul
Thu, Jul 23, 2015 5:26 PM

Digging out this thread as there is some good and some bad news :-)

The github project https://github.com/3MFConsortium/lib3mf looks promising
as it's providing the library with a 2-clause BSD license and it does
support compiling with GCC.

(Interesting note... the code is copyright by Netfabb / Microsoft)

That's the good news.

The bad news is, that the GCC part is missing some essential parts,
mainly the Reader and Writer classes. So currently it's basically just
the data model which would be usable (as far as I can tell after digging
a bit yesterday).

Still, that's a good start and hopefully the missing parts will
appear eventually.

ciao,
Torsten.

Digging out this thread as there is some good and some bad news :-) The github project https://github.com/3MFConsortium/lib3mf looks promising as it's providing the library with a 2-clause BSD license and it does support compiling with GCC. (Interesting note... the code is copyright by Netfabb / Microsoft) That's the good news. The bad news is, that the GCC part is missing some essential parts, mainly the Reader and Writer classes. So currently it's basically just the data model which would be usable (as far as I can tell after digging a bit yesterday). Still, that's a good start and hopefully the missing parts will appear eventually. ciao, Torsten.
JL
Joseph Lenox
Thu, Jul 23, 2015 5:38 PM

Well, an XML reader/writer is cake to drop in if you wanted to; I suspect
the non-gcc part made liberal use of Windows-only stuff.

--Joseph Lenox

On Thu, Jul 23, 2015 at 12:26 PM, Torsten Paul Torsten.Paul@gmx.de wrote:

Digging out this thread as there is some good and some bad news :-)

The github project https://github.com/3MFConsortium/lib3mf looks promising
as it's providing the library with a 2-clause BSD license and it does
support compiling with GCC.

(Interesting note... the code is copyright by Netfabb / Microsoft)

That's the good news.

The bad news is, that the GCC part is missing some essential parts,
mainly the Reader and Writer classes. So currently it's basically just
the data model which would be usable (as far as I can tell after digging
a bit yesterday).

Still, that's a good start and hopefully the missing parts will
appear eventually.

ciao,
Torsten.


OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

Well, an XML reader/writer is cake to drop in if you wanted to; I suspect the non-gcc part made liberal use of Windows-only stuff. --Joseph Lenox On Thu, Jul 23, 2015 at 12:26 PM, Torsten Paul <Torsten.Paul@gmx.de> wrote: > Digging out this thread as there is some good and some bad news :-) > > The github project https://github.com/3MFConsortium/lib3mf looks promising > as it's providing the library with a 2-clause BSD license and it does > support compiling with GCC. > > (Interesting note... the code is copyright by Netfabb / Microsoft) > > That's the good news. > > The bad news is, that the GCC part is missing some essential parts, > mainly the Reader and Writer classes. So currently it's basically just > the data model which would be usable (as far as I can tell after digging > a bit yesterday). > > Still, that's a good start and hopefully the missing parts will > appear eventually. > > ciao, > Torsten. > > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >
TP
Torsten Paul
Thu, Jul 23, 2015 5:50 PM

On 07/23/2015 07:38 PM, Joseph Lenox wrote:

Well, an XML reader/writer is cake to drop in if you wanted to; I suspect
the non-gcc part made liberal use of Windows-only stuff.

Sort-of, yes. It uses the OPC stuff which 3MF is based on, so it gets
most of the XML / ZIP / Packaging infrastructure for free.
(https://msdn.microsoft.com/en-us/library/windows/desktop/dd371025%28v=vs.85%29.aspx)

They did model the C++ interface after COM but according to the docs
it's only "A COM-like DLL Interface" which would work without the COM
magic.

ciao,
Torsten.

On 07/23/2015 07:38 PM, Joseph Lenox wrote: > Well, an XML reader/writer is cake to drop in if you wanted to; I suspect > the non-gcc part made liberal use of Windows-only stuff. > Sort-of, yes. It uses the OPC stuff which 3MF is based on, so it gets most of the XML / ZIP / Packaging infrastructure for free. (https://msdn.microsoft.com/en-us/library/windows/desktop/dd371025%28v=vs.85%29.aspx) They did model the C++ interface after COM but according to the docs it's only "A COM-like DLL Interface" which would work without the COM magic. ciao, Torsten.
TP
Torsten Paul
Mon, Feb 1, 2016 11:52 PM

And another update regarding 3MF support...

The official library now has support for GCC compilation and it
actually does read and write 3MF files :-).

So basic support is possible (mainly limited by what OpenSCAD
can handle / produce right now). There seem to be some issues
with some of the example files, I guess it will be interesting
to see if there's any feedback for the bug report.
( https://github.com/3MFConsortium/lib3mf/issues/7 )

Interesting note: Ultimaker joined the 3MF Consortium last
December.

https://ultimaker.com/press/22-ultimaker-announces-joining-3mf-consortium-as-founding-member

ciao,
Torsten.

And another update regarding 3MF support... The official library now has support for GCC compilation and it actually does read and write 3MF files :-). So basic support is possible (mainly limited by what OpenSCAD can handle / produce right now). There seem to be some issues with some of the example files, I guess it will be interesting to see if there's any feedback for the bug report. ( https://github.com/3MFConsortium/lib3mf/issues/7 ) Interesting note: Ultimaker joined the 3MF Consortium last December. https://ultimaker.com/press/22-ultimaker-announces-joining-3mf-consortium-as-founding-member ciao, Torsten.