All I want for Christmas (another feature request)

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

All I want for Christmas (another feature request)

Mike Aubury
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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: All I want for Christmas (another feature request)

RevarBat
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 <[hidden email]> 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
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: All I want for Christmas (another feature request)

JordanBrown
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


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
tp3
Reply | Threaded
Open this post in threaded view
|

Re: All I want for Christmas (another feature request)

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


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
Reply | Threaded
Open this post in threaded view
|

Re: All I want for Christmas (another feature request)

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


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
tp3
Reply | Threaded
Open this post in threaded view
|

Re: All I want for Christmas (another feature request)

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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
Reply | Threaded
Open this post in threaded view
|

Re: All I want for Christmas (another feature request)

JordanBrown
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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: All I want for Christmas (another feature request)

acwest
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, <[hidden email]> 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: All I want for Christmas (another feature request)

doug.moen
In reply to this post by JordanBrown
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


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: All I want for Christmas (another feature request)

Mike Aubury
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, <[hidden email]> 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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: All I want for Christmas (another feature request)

doug.moen
In reply to this post by doug.moen
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

_______________________________________________
OpenSCAD mailing list


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: All I want for Christmas (another feature request)

rickan
This post was updated on .
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 consumer 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/

_______________________________________________
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: All I want for Christmas (another feature request)

rickan
This post was updated on .
I did a

cat paddleBase.stl paddleBase.scad > /tmp/junk.stl

and opened /tmp/junk.stl in Cura-3.6.0.AppImage 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/

_______________________________________________
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: All I want for Christmas (another feature request)

JordanBrown
In reply to this post by doug.moen
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.)


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: All I want for Christmas (another feature request)

Tim Hawkins
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 <[hidden email]> 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:

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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: All I want for Christmas (another feature request)

Parkinbot
In reply to this post by Mike Aubury
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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: All I want for Christmas (another feature request)

Tim Hawkins
or use a generic multilanguage  package manager 

On Fri, Oct 23, 2020 at 8:08 PM Parkinbot <[hidden email]> 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: All I want for Christmas (another feature request)

nophead
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 <[hidden email]> wrote:
or use a generic multilanguage  package manager 

On Fri, Oct 23, 2020 at 8:08 PM Parkinbot <[hidden email]> 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: All I want for Christmas (another feature request)

RevarBat
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 <[hidden email]> 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 <[hidden email]> wrote:
or use a generic multilanguage  package manager 

On Fri, Oct 23, 2020 at 8:08 PM Parkinbot <[hidden email]> 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
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: All I want for Christmas (another feature request)

cacb
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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org