All I want for Christmas (another feature request)
There are 3MF files on thingiverse.
On Thu, Oct 22, 2020, at 3:44 PM, Doug Moen wrote:
Any extension to STL that isn't backwards compatible isn't STL and needs a new name and a different file extension. AMF began life as STL2. As has been mentioned, AMF is dead and 3MF is the new "extended STL". As Torsten says, it's not worthwhile to create a new extended STL format when 3MF has all the required features and all the momentum.
On Thu, Oct 22, 2020, at 3:14 PM, Jordan Brown wrote:
On 10/22/2020 10:31 AM, Torsten Paul wrote:
I'm not saying it's impossible to make it work. I'm saying it's not realistic for this to happen. Who designs that? Who convinces multiple projects to support that?
How realistic? Don't know. Were somebody to be active in the Cura community, how amenable would they be to such integration? I don't know - I'm not involved there. It might be little more than some programming and a pull request, or it might be impossible.
If there's value - if using OpenSCAD with Cura becomes appreciably easier - then maybe other slicer communities would be interested too. And if using OpenSCAD with slicers is easier, maybe other CAD systems would be interested.
Moving workflows to use 3MF seems a much better way to get new features. Ultimaker is part of the the 3MF Consortium so I assume they'll continue supporting the format.
Seems plausible, though the process would be very similar to the process for STL - you still have to get people to consume the extension. It might be harder, because there's a formal consortium that one might want to approve the extension. (But a natively-extensible format means that at least your extended files are compatible with consumers that don't support the extension.)
And note that Thingiverse doesn't support 3MF, so in that sense it's no better than "extended STL".
How to even call the menu entry?
"Export as STL (for Cura only, do not upload to Thingiverse)"
I'd probably spin it as a switch that enables "Extended STL". (Or insert a clever name here.) Even with the switch, it should only emit something if the program says to. Having the program say to emit something without the switch on might yield a message.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
I haven't yet found anything that looks like an official STL file
specification, but what I have found says that both ASCII and binary forms
have a definite end.
So what if you put your extension stuff after the end? Seems like the
easiest thing to do and if some soooper strict STL comsumer complains of the
junk after the end of the STL data, a tool to remove it would be very
simple.
--
Sent from: http://forum.openscad.org/
I did a
cat paddleBase.stl paddleBase.scad > /tmp/junk.stl
and opened /tmp/junk.stl in Cura-3.6.0.AppImage which which displayed the
STL file properly and made no complaint.
The input STL file is ascii.
Slic3r-1.3.0-x86_64.AppImage, however, barfed on it. Shame.
--
Sent from: http://forum.openscad.org/
On 10/22/2020 1:15 PM, Doug Moen wrote:
There are 3MF files on thingiverse.
I was just looking at what file types its upload tool says they
support: STL, OBJ, THING, SCAD, JPG, TXT, PDF, amf, dae, 3ds, x3d,
blend, ply, dxf, ai, svg, cdr, ps, eps, epsi, sch, brd, png, gif, doc, docx.
Anyhow, from an OpenSCAD perspective there are two major aspects to the
problem:
1) What's the OpenSCAD language construct that adds metadata to the
resulting file? Perhaps something as simple as property(name, value)
where name is a string and value is an arbitrary data value. Note that
"name" could have internal structure - it could be something like
"category/propname". Or maybe name could be an arbitrary data value
too, to allow expressing a hierarchy index as an array of strings.
2) What do the OpenSCAD export mechanisms do with the collected
metadata? That would depend on the particular exporter. Some might
include it, some might ignore it. There might also be a specialty
exporter that just dumps the metadata as some text form.
Probably you want to attach the metadata to the current object - e.g.,
to specify material. Maybe there should be a way to attach metadata to
a primitive. I don't know how a property assigned to a particular
object survives the operations done on that object so as to remain
attached (in some sense) to that object in the resulting render.
Perhaps this would be left for the second generation of the feature.
Cura uses 3MF for its primary save format, but it looks like it dumps
everything and its brother into those files - one simple file has 571K
(uncompressed) of Cura-specific metadata. It's in a mix of JSON, XML,
and INI formats. It's not at all clear whether Cura would cope with a
3MF with a tiny subset of that data. (And that's Cura-specific, so
unlikely to be consumed by anything else.)
Prusa is heavily into 3MF,.
https://blog.prusaprinters.org/3mf-file-format-and-why-its-great_30986/
Thier v2.x slic3r fork fully suports it.
On Fri, Oct 23, 2020, 07:26 Jordan Brown openscad@jordan.maileater.net
wrote:
On 10/22/2020 1:15 PM, Doug Moen wrote:
There are 3MF files on thingiverse.
I was just looking at what file types its upload tool says they support:
STL, OBJ, THING, SCAD, JPG, TXT, PDF, amf, dae, 3ds, x3d, blend, ply, dxf,
ai, svg, cdr, ps, eps, epsi, sch, brd, png, gif, doc, docx.
Anyhow, from an OpenSCAD perspective there are two major aspects to the
problem:
- What's the OpenSCAD language construct that adds metadata to the
resulting file? Perhaps something as simple as property(name, value)
where name is a string and value is an arbitrary data value. Note that
"name" could have internal structure - it could be something like
"category/propname". Or maybe name could be an arbitrary data value too,
to allow expressing a hierarchy index as an array of strings. - What do the OpenSCAD export mechanisms do with the collected
metadata? That would depend on the particular exporter. Some might
include it, some might ignore it. There might also be a specialty exporter
that just dumps the metadata as some text form.
Probably you want to attach the metadata to the current object - e.g., to
specify material. Maybe there should be a way to attach metadata to a
primitive. I don't know how a property assigned to a particular object
survives the operations done on that object so as to remain attached (in
some sense) to that object in the resulting render. Perhaps this would be
left for the second generation of the feature.
Cura uses 3MF for its primary save format, but it looks like it dumps
everything and its brother into those files - one simple file has 571K
(uncompressed) of Cura-specific metadata. It's in a mix of JSON, XML, and
INI formats. It's not at all clear whether Cura would cope with a 3MF with
a tiny subset of that data. (And that's Cura-specific, so unlikely to be
consumed by anything else.)
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
besides the fact, that STL format is poorly defined, there is a bunch of
reasons, why this is not desireable:
- license reasons: SCADs and STL can have different licences
- versioning: you'd need some information about the OpenSCAD version (and
all the parameters) that created the STL. This will be a nightmare. - libraries: most programmers use a stack of libraries. The name resolution
depends on the system and platform being used - ...
It is much easier to zip such projects.
Mike Aubury wrote
AFAIK - it's possible to embed comments in the generated STL.
I'd really like to have a flag that when set (or in preferences) - embeds
the OpenSCAD code that was used to generate the STL as a comment.
--
Sent from: http://forum.openscad.org/
or use a generic multilanguage package manager
On Fri, Oct 23, 2020 at 8:08 PM Parkinbot rudolf@digitaldocument.de wrote:
besides the fact, that STL format is poorly defined, there is a bunch of
reasons, why this is not desireable:
- license reasons: SCADs and STL can have different licences
- versioning: you'd need some information about the OpenSCAD version (and
all the parameters) that created the STL. This will be a nightmare. - libraries: most programmers use a stack of libraries. The name resolution
depends on the system and platform being used - ...
It is much easier to zip such projects.
Mike Aubury wrote
AFAIK - it's possible to embed comments in the generated STL.
I'd really like to have a flag that when set (or in preferences) - embeds
the OpenSCAD code that was used to generate the STL as a comment.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
IIRC there is a fault in the STL spec which means you can't tell for sure
if the file is binary or ascii because the marker for ascii can occur by
chance in the binary version. So because of this readers look at the length
in the header versus the file size to tell for sure. That will perhaps
break if you start adding extra data.
On Fri, 23 Oct 2020 at 13:14, Tim Hawkins tim.thawkins@gmail.com wrote:
or use a generic multilanguage package manager
On Fri, Oct 23, 2020 at 8:08 PM Parkinbot rudolf@digitaldocument.de
wrote:
besides the fact, that STL format is poorly defined, there is a bunch of
reasons, why this is not desireable:
- license reasons: SCADs and STL can have different licences
- versioning: you'd need some information about the OpenSCAD version (and
all the parameters) that created the STL. This will be a nightmare. - libraries: most programmers use a stack of libraries. The name
resolution
depends on the system and platform being used - ...
It is much easier to zip such projects.
Mike Aubury wrote
AFAIK - it's possible to embed comments in the generated STL.
I'd really like to have a flag that when set (or in preferences) -
embeds
the OpenSCAD code that was used to generate the STL as a comment.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
That ambiguity only really occurs if the binary file starts with the word “solid” in the 80 character comment header. Technically ambiguous, but practically unlikely.
- Revar
On Oct 23, 2020, at 5:26 AM, nop head nop.head@gmail.com wrote:
IIRC there is a fault in the STL spec which means you can't tell for sure if the file is binary or ascii because the marker for ascii can occur by chance in the binary version. So because of this readers look at the length in the header versus the file size to tell for sure. That will perhaps break if you start adding extra data.
On Fri, 23 Oct 2020 at 13:14, Tim Hawkins tim.thawkins@gmail.com wrote:
or use a generic multilanguage package manager
On Fri, Oct 23, 2020 at 8:08 PM Parkinbot rudolf@digitaldocument.de wrote:
besides the fact, that STL format is poorly defined, there is a bunch of
reasons, why this is not desireable:
- license reasons: SCADs and STL can have different licences
- versioning: you'd need some information about the OpenSCAD version (and
all the parameters) that created the STL. This will be a nightmare. - libraries: most programmers use a stack of libraries. The name resolution
depends on the system and platform being used - ...
It is much easier to zip such projects.
Mike Aubury wrote
AFAIK - it's possible to embed comments in the generated STL.
I'd really like to have a flag that when set (or in preferences) - embeds
the OpenSCAD code that was used to generate the STL as a comment.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 2020-10-24 02:20, Revar Desmera wrote:
That ambiguity only really occurs if the binary file starts with the
word “solid” in the 80 character comment header. Technically
ambiguous, but practically unlikely.
It is not practically unlikely, it is certain to happen and affect you
as it has affected me already several times. There are 'lots' of binary
STL files around starting with the word "solid" (by that I mean you are
sooner or later bound to hit a few of those if you download files from
many sources like I did when I wrote my STL reader code).
If you are interested in a practical solution to that particular
practical problem you can find it in my 'spaceio' library
https://github.com/arnholm/spacelibs/tree/master/spaceio
The main take-away is that STL is a well established and basically a
very poor design that doesn't even contain the same information in its
ascii vs. binary variants. You can live with it or use something else,
but trying to 'fix' or 'improve' it as suggested is only making things
worse. It is what it is.
Trying to embed OpenSCAD code into STL is not a workable idea. Even if
you could (you cannot), how are you going to declare that the non-STL
info is actually OpenSCAD code? Remember also that there are numerous
softwares that generate STL (AngelCAD for example), and not all of them
have source codes to embed, but something else. So you would have to
have some way of saying what kind of information you are embedding. But
this is not going to happen, so nevermind.
The best you can do is probably provide a package in a zip file (or some
other well established container format) containing the STL and the
source code and whatever other information you find relevant. Or as
suggested use one of the other mesh formats (STL isn't really one of
those, but...).
Carsten Arnholm