All I want for Christmas (another feature request)
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.
Don't think it needs to include any libraries or anything - just the main
code file.
Binary STLs have an 80 character leading comment, and can theoretically store two characters per face in the attribute field. Storing and reading the source code from that would be quite awkward.
ASCII STLs can only store a one line comment as the solid name.
It’s really not practical to store sources in STL files.
-Revar
On Oct 22, 2020, at 12:53 AM, Mike Aubury mike@aubit.com 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.
Don't think it needs to include any libraries or anything - just the main code file.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 10/22/2020 3:44 AM, Revar Desmera wrote:
Binary STLs have an 80 character leading comment, and can theoretically store two characters per face in the attribute field. Storing and reading the source code from that would be quite awkward.
ASCII STLs can only store a one line comment as the solid name.
If we could get one or more of the slicers to play, we could extend the
format. It'd have to be optional, but it's not like the format is the law.
What I'd be interested in is encoding some of the slicing parameters
into the STL, so that I can have both the CAD design and at least some
of the CAM embedded in my OpenSCAD program, instead of having to specify
them separately.
e.g.:
infill-percent: 30
layer-height: 0.2
On 22.10.20 18:35, Jordan Brown wrote:
If we could get one or more of the slicers to play,
we could extend the format. It'd have to be optional,
but it's not like the format is the law.
Not law, but still pretty much impossible. Optional does
not help here as any file trying to use the extension
will break in all existing applications. The much better
option is to use a format which allows properties and/or
extensions. I'm pretty sure 3MF can handle those. AMF
could do that too, but I'd rate that as dead already, not
really worth starting with it.
What I'd be interested in is encoding some of the
slicing parameters into the STL, so that I can have both
the CAD design and at least some of the CAM embedded in
my OpenSCAD program, instead of having to specify them
separately.
Slic3r supports that for at least AMF, not sure about
other formats. I'm not sure about the 3MF support.
ciao,
Torsten.
On 10/22/2020 9:52 AM, Torsten Paul wrote:
On 22.10.20 18:35, Jordan Brown wrote:
If we could get one or more of the slicers to play,
we could extend the format. It'd have to be optional,
but it's not like the format is the law.
Not law, but still pretty much impossible. Optional does
not help here as any file trying to use the extension
will break in all existing applications.
Hmm?
Note that I did say "If we could get one or more of the slicers to play".
If OpenSCAD has a mechanism to emit this extended STL, and (say) Cura
can consume it, how does that break OpenSCAD's ability to supply a
standard STL to Slic3r? How does Cura's ability to consume the extended
STL break its ability to consume a standard STL from Blender?
Sure, an extended STL won't work with a non-extension-capable consumer.
So if you're going to be using a non-extension-capable consumer... don't
create extended STLs.
The much better option is to use a format which allows properties
and/or extensions. I'm pretty sure 3MF can handle those. AMF could do
that too, but I'd rate that as dead already, not really worth starting
with it.
Yes, I thought of mentioning 3MF. I assume that it can handle all of
that, since Cura saves its workspaces as 3MFs.
What I'd be interested in is encoding some of the
slicing parameters into the STL, so that I can have both
the CAD design and at least some of the CAM embedded in
my OpenSCAD program, instead of having to specify them
separately.
Slic3r supports that for at least AMF, not sure about
other formats. I'm not sure about the 3MF support.
I'll have to look into that.
On 22.10.20 19:09, Jordan Brown wrote:
If OpenSCAD has a mechanism to emit this extended STL,
and (say) Cura can consume it, how does that break
OpenSCAD's ability to supply a standard STL to Slic3r?
How does Cura's ability to consume the extended STL
break its ability to consume a standard STL from Blender?
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 to
even call the menu entry?
"Export as STL (for Cura only, do not upload to Thingiverse)"
AMF died because it never really was used by anyone (and
maybe due to the not so clever fact the spec is hiding
behind a paywall). It was not really a bad format, well,
at least when ignoring the curved triangles support ;-)
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.
ciao,
Torsten.
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.
Stl is also a file format with wider uses than just 3d printing, so it is
likely much tougher to get such a change accepted
On Thu, 22 Oct 2020, 15:14 Jordan Brown, openscad@jordan.maileater.net
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
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 was under the impression that anything after a ';' was just treated as a
comment by most tools ?
On Thu, 22 Oct 2020, 20:44 Doug Moen, doug@moens.org 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
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org