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 10/22/2020 3:44 AM, Revar Desmera 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.

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:

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.

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:

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.

Yes, I thought of mentioning 3MF.  I assume that it can handle all of
that, since Cura saves its workspaces as 3MFs.

I'll have to look into that.

On 22.10.20 19:09, Jordan Brown 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 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:

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.

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".

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:

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:

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:

There are 3MF files on thingiverse.

On Thu, Oct 22, 2020, at 3:44 PM, Doug Moen wrote:

On 10/22/2020 1:15 PM, Doug Moen wrote:

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:

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

--
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:

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:

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 2020-10-24 02:20, Revar Desmera wrote:

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