[semi-on-topic] print speed optimized sinus support material. integration interface possible??

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

[semi-on-topic] print speed optimized sinus support material. integration interface possible??

Peter
Hello Everyone
i am sorry if i am not off-topic with this,hope it is ok

i have thrown together a javascript tool to semi-automatically create
continuous sinusoidal support for my openscad models .i tried but failed
to implement it using  scad language only.

  its aim is to minimize sharp corners and empty head moves(with filament
retractions) in the  inbuilt support of my openscad model.

in case you want to have a look,  i have put together some instructions
and put the tool on the github:
https://github.com/solidboredom/sinus-support/


After putting quite some effort into an .scad version of it, i could not
figure a possibility to make it _continous_ around the parts outline
using openscad only, so i have aborted my efforts and created this  
javascript tool.

external tool makes  the whole process more complicated, you have to
export SVG  and import twice.
so how could i simplify the process? is the only  way to implement
something like this directly in the source-code of openscad source?

reason i have made it:
i  was unhappy with slic3r generated support for long time.
it works very good on simple parts, but It fails quite a lot on my
complex models, and it fills all gaps in any height. i only wanted to
support the part from below.
the simple inbuilt support i have created before using n openscad  only,
always been slowing down my print because of discontinuities and sharp
corners.

so is this  possible to streamline the exchange between openscad and
javascript? (i actually do not think so)  is it time for an open
interface for openscad?

Peter


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

Re: [semi-on-topic] print speed optimized sinus support material. integration interface possible??

doug.moen
Pretty cool project.

With respect to your comments about an "open interface", I feel this is the kind of project that ought to be possible in OpenSCAD. You are taking one geometric object and transforming it into another, and that's exactly the sort of thing that OpenSCAD ought to be good at, especially if the application is 3D printing.

I don't know exactly what your roadblock was, but for support generation, I think the missing feature is a full set of capabilities for querying the geometry of an object. Creating a "plugin interface" to OpenSCAD is a big can of worms, and in some ways it's easier to just fix the deficiencies in the language. (Both approaches, plugins and geometric queries, are controversial within the dev team, but my vote is to make the language more powerful.)

As for Slic3r having poor support generation, this was being discussed in another forum that I participate in, and a number of people recommend using Simplify3D instead.

Note that Simplify3D is proprietary and costs money, but for some users, that's not a problem. On the other hand, if OpenSCAD made it easier for people to experiment with new support algorithms, then that could allow progress to be made within the open source community without the requirement to hack the internals of Slic3r or Cura.

On 9 March 2016 at 19:12, pproj <[hidden email]> wrote:
Hello Everyone
i am sorry if i am not off-topic with this,hope it is ok

i have thrown together a javascript tool to semi-automatically create continuous sinusoidal support for my openscad models .i tried but failed to implement it using  scad language only.

 its aim is to minimize sharp corners and empty head moves(with filament retractions) in the  inbuilt support of my openscad model.

in case you want to have a look,  i have put together some instructions and put the tool on the github:
https://github.com/solidboredom/sinus-support/


After putting quite some effort into an .scad version of it, i could not figure a possibility to make it _continous_ around the parts outline using openscad only, so i have aborted my efforts and created this  javascript tool.

external tool makes  the whole process more complicated, you have to export SVG  and import twice.
so how could i simplify the process? is the only  way to implement something like this directly in the source-code of openscad source?

reason i have made it:
i  was unhappy with slic3r generated support for long time.
it works very good on simple parts, but It fails quite a lot on my complex models, and it fills all gaps in any height. i only wanted to support the part from below.
the simple inbuilt support i have created before using n openscad  only, always been slowing down my print because of discontinuities and sharp corners.

so is this  possible to streamline the exchange between openscad and javascript? (i actually do not think so)  is it time for an open interface for openscad?

Peter


_______________________________________________
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: [semi-on-topic] print speed optimized sinus support material. integration interface possible??

Peter
Thanks Doug!

 anyways by now i started to think  openscad really lacks extensibility, through plugins (like i.e. in inkscape) there would be more efficient possibilities for the problems at hand,perhaps there would alse be less openscad-variants, and more improvements.

the reason to switch to Javascript for me was indeed  the inability to query existing geometry,

If the question at hand was, wether to make openscad geomeries querieable or to build the plugin interface, my answer would be a definitive "both"!
but i just like you i consider the queriability more important.


if one  needs a result quickly and can't wait untill openscad evolves to more extensibility,  going the Javascript route like i did is perhaps not the worst solution,
if anybody has a use for my script as base for his own processing i will be very happy. and would be even more so if it will me made availiable for others to use

and thanks for the hint on Simplify3D, but it looks like i will not need it anymore :)
Peter

On 10.03.2016 03:19, doug moen wrote:
Pretty cool project.

With respect to your comments about an "open interface", I feel this is the kind of project that ought to be possible in OpenSCAD. You are taking one geometric object and transforming it into another, and that's exactly the sort of thing that OpenSCAD ought to be good at, especially if the application is 3D printing.

I don't know exactly what your roadblock was, but for support generation, I think the missing feature is a full set of capabilities for querying the geometry of an object. Creating a "plugin interface" to OpenSCAD is a big can of worms, and in some ways it's easier to just fix the deficiencies in the language. (Both approaches, plugins and geometric queries, are controversial within the dev team, but my vote is to make the language more powerful.)

As for Slic3r having poor support generation, this was being discussed in another forum that I participate in, and a number of people recommend using Simplify3D instead.

Note that Simplify3D is proprietary and costs money, but for some users, that's not a problem. On the other hand, if OpenSCAD made it easier for people to experiment with new support algorithms, then that could allow progress to be made within the open source community without the requirement to hack the internals of Slic3r or Cura.

On 9 March 2016 at 19:12, pproj <[hidden email]> wrote:
Hello Everyone
i am sorry if i am not off-topic with this,hope it is ok

i have thrown together a javascript tool to semi-automatically create continuous sinusoidal support for my openscad models .i tried but failed to implement it using  scad language only.

 its aim is to minimize sharp corners and empty head moves(with filament retractions) in the  inbuilt support of my openscad model.

in case you want to have a look,  i have put together some instructions and put the tool on the github:
https://github.com/solidboredom/sinus-support/


After putting quite some effort into an .scad version of it, i could not figure a possibility to make it _continous_ around the parts outline using openscad only, so i have aborted my efforts and created this  javascript tool.

external tool makes  the whole process more complicated, you have to export SVG  and import twice.
so how could i simplify the process? is the only  way to implement something like this directly in the source-code of openscad source?

reason i have made it:
i  was unhappy with slic3r generated support for long time.
it works very good on simple parts, but It fails quite a lot on my complex models, and it fills all gaps in any height. i only wanted to support the part from below.
the simple inbuilt support i have created before using n openscad  only, always been slowing down my print because of discontinuities and sharp corners.

so is this  possible to streamline the exchange between openscad and javascript? (i actually do not think so)  is it time for an open interface for openscad?

Peter


_______________________________________________
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: [semi-on-topic] print speed optimized sinus support material. integration interface possible??

nophead
How do you print your support structures? Do you slice them separately and apply a Z offset?

On 10 March 2016 at 15:46, [hidden email] <[hidden email]> wrote:
Thanks Doug!

 anyways by now i started to think  openscad really lacks extensibility, through plugins (like i.e. in inkscape) there would be more efficient possibilities for the problems at hand,perhaps there would alse be less openscad-variants, and more improvements.

the reason to switch to Javascript for me was indeed  the inability to query existing geometry,

If the question at hand was, wether to make openscad geomeries querieable or to build the plugin interface, my answer would be a definitive "both"!
but i just like you i consider the queriability more important.


if one  needs a result quickly and can't wait untill openscad evolves to more extensibility,  going the Javascript route like i did is perhaps not the worst solution,
if anybody has a use for my script as base for his own processing i will be very happy. and would be even more so if it will me made availiable for others to use

and thanks for the hint on Simplify3D, but it looks like i will not need it anymore :)
Peter

On 10.03.2016 03:19, doug moen wrote:
Pretty cool project.

With respect to your comments about an "open interface", I feel this is the kind of project that ought to be possible in OpenSCAD. You are taking one geometric object and transforming it into another, and that's exactly the sort of thing that OpenSCAD ought to be good at, especially if the application is 3D printing.

I don't know exactly what your roadblock was, but for support generation, I think the missing feature is a full set of capabilities for querying the geometry of an object. Creating a "plugin interface" to OpenSCAD is a big can of worms, and in some ways it's easier to just fix the deficiencies in the language. (Both approaches, plugins and geometric queries, are controversial within the dev team, but my vote is to make the language more powerful.)

As for Slic3r having poor support generation, this was being discussed in another forum that I participate in, and a number of people recommend using Simplify3D instead.

Note that Simplify3D is proprietary and costs money, but for some users, that's not a problem. On the other hand, if OpenSCAD made it easier for people to experiment with new support algorithms, then that could allow progress to be made within the open source community without the requirement to hack the internals of Slic3r or Cura.

On 9 March 2016 at 19:12, pproj <[hidden email]> wrote:
Hello Everyone
i am sorry if i am not off-topic with this,hope it is ok

i have thrown together a javascript tool to semi-automatically create continuous sinusoidal support for my openscad models .i tried but failed to implement it using  scad language only.

 its aim is to minimize sharp corners and empty head moves(with filament retractions) in the  inbuilt support of my openscad model.

in case you want to have a look,  i have put together some instructions and put the tool on the github:
https://github.com/solidboredom/sinus-support/


After putting quite some effort into an .scad version of it, i could not figure a possibility to make it _continous_ around the parts outline using openscad only, so i have aborted my efforts and created this  javascript tool.

external tool makes  the whole process more complicated, you have to export SVG  and import twice.
so how could i simplify the process? is the only  way to implement something like this directly in the source-code of openscad source?

reason i have made it:
i  was unhappy with slic3r generated support for long time.
it works very good on simple parts, but It fails quite a lot on my complex models, and it fills all gaps in any height. i only wanted to support the part from below.
the simple inbuilt support i have created before using n openscad  only, always been slowing down my print because of discontinuities and sharp corners.

so is this  possible to streamline the exchange between openscad and javascript? (i actually do not think so)  is it time for an open interface for openscad?

Peter


_______________________________________________
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
tp3
Reply | Threaded
Open this post in threaded view
|

Re: [semi-on-topic] print speed optimized sinus support material. integration interface possible??

tp3
In reply to this post by Peter
On 03/10/2016 04:46 PM, [hidden email] wrote:
> anyways by now i started to think  openscad really lacks extensibility,
> through plugins (like i.e. in inkscape) there would be more efficient
> possibilities for the problems at hand, perhaps there would also be less
> openscad-variants, and more improvements.
>
In general I do like the idea of plugins, but I'm not sure how manageable
that would be currently. Creating and maintaining a stable plugin API is
not an easy topic and that would probably mean even less improvements in
other areas.

The geometry query part is certainly one of the biggest issues, but that's
not solvable by just adding plugins, it needs the internal changes to
support that without completely breaking good things like the quick preview.
That's one of the big things the OpenSCAD2 discussion is supposed to give
and I hope we can slowly move into that direction so there's not a huge
leap in the end when trying to get the full list of new features.

As for the variants, and side projects, I'm not so sure. There will always
be a number of use cases where the descriptive nature of OpenSCAD is not
going to cover everything and some additional frontend in a general
programming language is appropriate (like for reading data from a database).

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: [semi-on-topic] print speed optimized sinus support material. integration interface possible??

Parkinbot
In reply to this post by Peter
Hm, nice approach, but somehow very ambitious.

Support structures are usually more than an stl. They interact with your print as well as with your material. It is a good idea to have it calculated by your slicer. Maybe you try another slicer like Kisslicer before you put a lot of work into that.  

This is some of the features you'll want to have:
- support should easily break off. So it is better loosely connected with the object (a slicer uses jerk control for this)
- support is only needed up to a certain angle and has a heightmap. Don't see that in your current approach
- support can have a substructure ...

If you really want to go into that, I suggest to use some imperative programming language and
- parse the STL of your print object
- analyse the triangles to determine the surface to be supported
- do your own sine magic on that surface, which is not trivial to calculate as intersections are involved

OpenScad can help you with the sine magic
- close your surface into an object (or a bunch of objects depending on your design) exactly hulling your support structure and export it as STL.
- now you can import that STL into OpenScad and do your sine magic there in a generic fashion, intersect it and so on.

Rudolf


Reply | Threaded
Open this post in threaded view
|

Re: [semi-on-topic] print speed optimized sinus support material. integration interface possible??

Peter
In reply to this post by nophead
i just include the support structure back into the .scad code of my model (or import the stl of the model  into the support sructure .scad code) they get "Unioned" to a new model with inbuilt suport, which i can export as stl and slice.
it is not a "proper" support in terms of own gcode settings (speed, extrusion thickness, etc..) but i do not care as long as i get better results than with the native one. so i  just slice it as if it was a part of the models Material rather than trying to acheive it through slic3rs own support structues.
Peter

On 10.03.2016 19:32, nop head wrote:
How do you print your support structures? Do you slice them separately and apply a Z offset?

On 10 March 2016 at 15:46, [hidden email] <[hidden email]> wrote:
Thanks Doug!

 anyways by now i started to think  openscad really lacks extensibility, through plugins (like i.e. in inkscape) there would be more efficient possibilities for the problems at hand,perhaps there would alse be less openscad-variants, and more improvements.

the reason to switch to Javascript for me was indeed  the inability to query existing geometry,

If the question at hand was, wether to make openscad geomeries querieable or to build the plugin interface, my answer would be a definitive "both"!
but i just like you i consider the queriability more important.


if one  needs a result quickly and can't wait untill openscad evolves to more extensibility,  going the Javascript route like i did is perhaps not the worst solution,
if anybody has a use for my script as base for his own processing i will be very happy. and would be even more so if it will me made availiable for others to use

and thanks for the hint on Simplify3D, but it looks like i will not need it anymore :)
Peter

On 10.03.2016 03:19, doug moen wrote:
Pretty cool project.

With respect to your comments about an "open interface", I feel this is the kind of project that ought to be possible in OpenSCAD. You are taking one geometric object and transforming it into another, and that's exactly the sort of thing that OpenSCAD ought to be good at, especially if the application is 3D printing.

I don't know exactly what your roadblock was, but for support generation, I think the missing feature is a full set of capabilities for querying the geometry of an object. Creating a "plugin interface" to OpenSCAD is a big can of worms, and in some ways it's easier to just fix the deficiencies in the language. (Both approaches, plugins and geometric queries, are controversial within the dev team, but my vote is to make the language more powerful.)

As for Slic3r having poor support generation, this was being discussed in another forum that I participate in, and a number of people recommend using Simplify3D instead.

Note that Simplify3D is proprietary and costs money, but for some users, that's not a problem. On the other hand, if OpenSCAD made it easier for people to experiment with new support algorithms, then that could allow progress to be made within the open source community without the requirement to hack the internals of Slic3r or Cura.

On 9 March 2016 at 19:12, pproj <[hidden email]> wrote:
Hello Everyone
i am sorry if i am not off-topic with this,hope it is ok

i have thrown together a javascript tool to semi-automatically create continuous sinusoidal support for my openscad models .i tried but failed to implement it using  scad language only.

 its aim is to minimize sharp corners and empty head moves(with filament retractions) in the  inbuilt support of my openscad model.

in case you want to have a look,  i have put together some instructions and put the tool on the github:
https://github.com/solidboredom/sinus-support/


After putting quite some effort into an .scad version of it, i could not figure a possibility to make it _continous_ around the parts outline using openscad only, so i have aborted my efforts and created this  javascript tool.

external tool makes  the whole process more complicated, you have to export SVG  and import twice.
so how could i simplify the process? is the only  way to implement something like this directly in the source-code of openscad source?

reason i have made it:
i  was unhappy with slic3r generated support for long time.
it works very good on simple parts, but It fails quite a lot on my complex models, and it fills all gaps in any height. i only wanted to support the part from below.
the simple inbuilt support i have created before using n openscad  only, always been slowing down my print because of discontinuities and sharp corners.

so is this  possible to streamline the exchange between openscad and javascript? (i actually do not think so)  is it time for an open interface for openscad?

Peter


_______________________________________________
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


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

Re: [semi-on-topic] print speed optimized sinus support material. integration interface possible??

Peter
In reply to this post by Parkinbot
Rudolf yes i agree you have a point here.

and of course it would be difficult to program all the functionality a
native support can give you in javascript,
but in my experiments, when slicing the thin  structures in the .stl  it
turned out,  slic3r produces
gcode which seems close enough to what is needed to replace its native
support structures. ( for the parts i have tried  so far at least).
as to the proper alignment of the support material, the art itself and
interface layers, again i agree, that would be quite a big task to
program it all in the js, but i think it is not really eededin in very
may cases.

i do nor mind if i have no thinned out support interface layers, if the
support is thin enough to easy break it off.
i do not mind if the support fills a bit of my model to a certain
heigh,t like in the picture,i have attached, for the  same reason.
creating fine gridded interface layers on top of the coarser  support
(with longer sinus periods and bigger amplitudes at the bottom) might be
needed in some cases, but should be doable in openscad as well, if one
really needs it.
so of course this not an ideal approach, but i think it might be just
practical enough to quickly get  quickly printing  support done quickly.
from what i grasp, it is actually not that difficult to do much of what
you have mentioned in  opencad either.
i.e. just as you write creating a hull of the model and subtracting it
from the support structures will help,
if the Model is not convex it will not quite work, but one can
"subdivide" the model using a small cube  "rastering" the Space
containing your model, creating smaller Hulls in the intersection with
this cube and then unioning them together and subtracting the whole
thing from the support structure.

creating the thinned  "support Structure interface" area where your
support meets the model does not seem that difficult in openscad either,
since one can scale the support a bit higher into the model intersect it
with the model itself, erode the intersection with minkowsi to make it
thinner and move it back just under under the model.
i actually have experimented quite a bit with smoothing and eroding of
the model with hull and minkowski or moving  "rastering" cubes  and it
works, but it is incredibly slow on a complex model.

but like i have said before  i think in quite many cases we might not
need to do any of it, but the support will still be very useful.
 Peter
On 11.03.2016 01:28, Parkinbot wrote:

> Hm, nice approach, but somehow very ambitious.
>
> Support structures are usually more than an stl. They interact with your
> print as well as with your material. It is a good idea to have it calculated
> by your slicer. Maybe you try another slicer like Kisslicer before you put a
> lot of work into that.  
>
> This is some of the features you'll want to have:
> - support should easily break off. So it is better loosely connected with
> the object (a slicer uses jerk control for this)
> - support is only needed up to a certain angle and has a heightmap. Don't
> see that in your current approach
> - support can have a substructure ...
>
> If you really want to go into that, I suggest to use some imperative
> programming language and
> - parse the STL of your print object
> - analyse the triangles to determine the surface to be supported
> - do your own sine magic on that surface, which is not trivial to calculate
> as intersections are involved
>
> OpenScad can help you with the sine magic
> - close your surface into an object (or a bunch of objects depending on your
> design) exactly hulling your support structure and export it as STL.
> - now you can import that STL into OpenScad and do your sine magic there in
> a generic fashion, intersect it and so on.
>
> Rudolf
>
>
>
>
>
>
> --
> View this message in context: http://forum.openscad.org/semi-on-topic-print-speed-optimized-sinus-support-material-integration-interface-possible-tp16383p16402.html
> Sent from the OpenSCAD mailing list archive at Nabble.com.
>
> _______________________________________________
> 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

ModWithSupport.png (88K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

plugins and the 3d-Dir.scad command; was: Re: [semi-on-topic] print speed optimized sinus support material. integration interface possible??

Peter
In reply to this post by tp3
Torsten  I was just thinking aloud.  of course i cannot be sure what
impact these features(shape queering and plugins) would have had on the
project development.
i beleive you have a much clearer perpective on the project as a whole
anyway.

as for keepig the fast rendering functionality, it makes sense to me,
but perhaps it could be an acceptable compromise for more complex models.
i have to gcal-render big deal of the  models i have created to make
them display properly or be able to turn them in the view without
waiting for tens of seconds.
i like complex models and i like to use .children() in my libraries,
that is probably why.  but that is what .children() was made for right?
i think i also see a compromise solution to pugins: if we could scripts
the export to different formats, which are already available from the
menu, from the scad code itself
and then could run an external tool and then import the results back,
that woud be almost as good as plugins.

yes this could affect the declarativity of the scad code.
so perhaps creating a separate special  module in  code like the classic
"main() function" accepting only imperative code as well as
render() calls could solve it.
i can also see a restriction to have only one main() in all included
.scad files and libraries so the utility libraries do not use it and do
not break the modularity and "nestability" of the library code which
than have to stay declarative only.
i expect people to ask now, why not use shell instead?
here are my considerations:
-calling out from scad would be much more convenient and put most of
simple "one line" dependencies into one scad file. it is also than
possible to pass information as command line parameters to the "plugin"
command.
-it is overall much closer to plug-ins. there is a reason other programs
have plugin systems besides being started from a shell as well, so why
do they need it then?
-it is much easier to share a scad file  than an archive full of shell
scripts and scad files, with scripts having to take care where they have
been started from, where are the other files they need, etc.
-it is much simpler to put everything into a single file and perhaps add
one external program or use a system program. HEY HOW ABOUT a 3D ls or
dir command with spheric files flying around your cubic folders and
sub-folder wiggling next to them? just run the 3d-dir.scad...:) it just
one  hypothetical example of integration possibilities and uses that
will open...
Peter
 On 10.03.2016 22:01, Torsten Paul wrote:

> On 03/10/2016 04:46 PM, [hidden email] wrote:
>> anyways by now i started to think  openscad really lacks extensibility,
>> through plugins (like i.e. in inkscape) there would be more efficient
>> possibilities for the problems at hand, perhaps there would also be less
>> openscad-variants, and more improvements.
>>
> In general I do like the idea of plugins, but I'm not sure how manageable
> that would be currently. Creating and maintaining a stable plugin API is
> not an easy topic and that would probably mean even less improvements in
> other areas.
>
> The geometry query part is certainly one of the biggest issues, but that's
> not solvable by just adding plugins, it needs the internal changes to
> support that without completely breaking good things like the quick preview.
> That's one of the big things the OpenSCAD2 discussion is supposed to give
> and I hope we can slowly move into that direction so there's not a huge
> leap in the end when trying to get the full list of new features.
>
> As for the variants, and side projects, I'm not so sure. There will always
> be a number of use cases where the descriptive nature of OpenSCAD is not
> going to cover everything and some additional frontend in a general
> programming language is appropriate (like for reading data from a database).
>
> ciao,
>   Torsten.
>
>
> _______________________________________________
> 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: [semi-on-topic] print speed optimized sinus support material. integration interface possible??

jon_bondy
In reply to this post by Peter
I often do the same thing when automatic support structures are ineffective.  I use posts or sheets that are roughly 0.3 mm in diameter or thickness.  If I generate them in a separate module, then I can disable them quickly if necessary.

Jon

On 3/11/2016 10:15 AM, [hidden email] wrote:
i just include the support structure back into the .scad code of my model (or import the stl of the model  into the support sructure .scad code) they get "Unioned" to a new model with inbuilt suport, which i can export as stl and slice.
it is not a "proper" support in terms of own gcode settings (speed, extrusion thickness, etc..) but i do not care as long as i get better results than with the native one. so i  just slice it as if it was a part of the models Material rather than trying to acheive it through slic3rs own support structues.
Peter



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

Re: plugins and the 3d-Dir.scad command; was: Re: [semi-on-topic] print speed optimized sinus support material. integration interface possible??

doug.moen
In reply to this post by Peter
That's an interesting idea. It can be done in a declarative way.

external_transform("warp $in >$out", in="stl", out="stl") cube(10);

The external_transform module takes a shape as an argument, and returns a second shape, which is constructed by executing a shell command. The input shape is written to a file, the shell command is run, then the output file is read to obtain the resulting shape.

I see two problems.

The big problem is security:
   external_transform("rm -rf $HOME");
It allows people to write malicious OpenSCAD scripts. This would be a problem for Thingiverse and other companies that allow people to upload OpenSCAD scripts and execute them on their servers. Hackers could distribute trojan-horse OpenSCAD scripts to attack people's personal computers.

A smaller problem is that we'd have to execute the shell script during preview, which would slow down preview. This could be mitigated by caching.

On 11 March 2016 at 10:19, [hidden email] <[hidden email]> wrote:
Torsten  I was just thinking aloud.  of course i cannot be sure what
impact these features(shape queering and plugins) would have had on the
project development.
i beleive you have a much clearer perpective on the project as a whole
anyway.

as for keepig the fast rendering functionality, it makes sense to me,
but perhaps it could be an acceptable compromise for more complex models.
i have to gcal-render big deal of the  models i have created to make
them display properly or be able to turn them in the view without
waiting for tens of seconds.
i like complex models and i like to use .children() in my libraries,
that is probably why.  but that is what .children() was made for right?
i think i also see a compromise solution to pugins: if we could scripts
the export to different formats, which are already available from the
menu, from the scad code itself
and then could run an external tool and then import the results back,
that woud be almost as good as plugins.

yes this could affect the declarativity of the scad code.
so perhaps creating a separate special  module in  code like the classic
"main() function" accepting only imperative code as well as
render() calls could solve it.
i can also see a restriction to have only one main() in all included
.scad files and libraries so the utility libraries do not use it and do
not break the modularity and "nestability" of the library code which
than have to stay declarative only.
i expect people to ask now, why not use shell instead?
here are my considerations:
-calling out from scad would be much more convenient and put most of
simple "one line" dependencies into one scad file. it is also than
possible to pass information as command line parameters to the "plugin"
command.
-it is overall much closer to plug-ins. there is a reason other programs
have plugin systems besides being started from a shell as well, so why
do they need it then?
-it is much easier to share a scad file  than an archive full of shell
scripts and scad files, with scripts having to take care where they have
been started from, where are the other files they need, etc.
-it is much simpler to put everything into a single file and perhaps add
one external program or use a system program. HEY HOW ABOUT a 3D ls or
dir command with spheric files flying around your cubic folders and
sub-folder wiggling next to them? just run the 3d-dir.scad...:) it just
one  hypothetical example of integration possibilities and uses that
will open...
Peter
 On 10.03.2016 22:01, Torsten Paul wrote:
> On 03/10/2016 04:46 PM, [hidden email] wrote:
>> anyways by now i started to think  openscad really lacks extensibility,
>> through plugins (like i.e. in inkscape) there would be more efficient
>> possibilities for the problems at hand, perhaps there would also be less
>> openscad-variants, and more improvements.
>>
> In general I do like the idea of plugins, but I'm not sure how manageable
> that would be currently. Creating and maintaining a stable plugin API is
> not an easy topic and that would probably mean even less improvements in
> other areas.
>
> The geometry query part is certainly one of the biggest issues, but that's
> not solvable by just adding plugins, it needs the internal changes to
> support that without completely breaking good things like the quick preview.
> That's one of the big things the OpenSCAD2 discussion is supposed to give
> and I hope we can slowly move into that direction so there's not a huge
> leap in the end when trying to get the full list of new features.
>
> As for the variants, and side projects, I'm not so sure. There will always
> be a number of use cases where the descriptive nature of OpenSCAD is not
> going to cover everything and some additional frontend in a general
> programming language is appropriate (like for reading data from a database).
>
> ciao,
>   Torsten.
>
>
> _______________________________________________
> 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: plugins and the 3d-Dir.scad command; was: Re: [semi-on-topic] print speed optimized sinus support material. integration interface possible??

doug.moen
A third problem is that the syntax of shell commands is different between Windows, Mac, Linux. We'd want a syntax that is platform independent.

The security issues could be mitigated by requiring that external "plugin" executables are installed in an OpenSCAD plugin directory.

On 11 March 2016 at 11:06, doug moen <[hidden email]> wrote:
That's an interesting idea. It can be done in a declarative way.

external_transform("warp $in >$out", in="stl", out="stl") cube(10);

The external_transform module takes a shape as an argument, and returns a second shape, which is constructed by executing a shell command. The input shape is written to a file, the shell command is run, then the output file is read to obtain the resulting shape.

I see two problems.

The big problem is security:
   external_transform("rm -rf $HOME");
It allows people to write malicious OpenSCAD scripts. This would be a problem for Thingiverse and other companies that allow people to upload OpenSCAD scripts and execute them on their servers. Hackers could distribute trojan-horse OpenSCAD scripts to attack people's personal computers.

A smaller problem is that we'd have to execute the shell script during preview, which would slow down preview. This could be mitigated by caching.

On 11 March 2016 at 10:19, [hidden email] <[hidden email]> wrote:
Torsten  I was just thinking aloud.  of course i cannot be sure what
impact these features(shape queering and plugins) would have had on the
project development.
i beleive you have a much clearer perpective on the project as a whole
anyway.

as for keepig the fast rendering functionality, it makes sense to me,
but perhaps it could be an acceptable compromise for more complex models.
i have to gcal-render big deal of the  models i have created to make
them display properly or be able to turn them in the view without
waiting for tens of seconds.
i like complex models and i like to use .children() in my libraries,
that is probably why.  but that is what .children() was made for right?
i think i also see a compromise solution to pugins: if we could scripts
the export to different formats, which are already available from the
menu, from the scad code itself
and then could run an external tool and then import the results back,
that woud be almost as good as plugins.

yes this could affect the declarativity of the scad code.
so perhaps creating a separate special  module in  code like the classic
"main() function" accepting only imperative code as well as
render() calls could solve it.
i can also see a restriction to have only one main() in all included
.scad files and libraries so the utility libraries do not use it and do
not break the modularity and "nestability" of the library code which
than have to stay declarative only.
i expect people to ask now, why not use shell instead?
here are my considerations:
-calling out from scad would be much more convenient and put most of
simple "one line" dependencies into one scad file. it is also than
possible to pass information as command line parameters to the "plugin"
command.
-it is overall much closer to plug-ins. there is a reason other programs
have plugin systems besides being started from a shell as well, so why
do they need it then?
-it is much easier to share a scad file  than an archive full of shell
scripts and scad files, with scripts having to take care where they have
been started from, where are the other files they need, etc.
-it is much simpler to put everything into a single file and perhaps add
one external program or use a system program. HEY HOW ABOUT a 3D ls or
dir command with spheric files flying around your cubic folders and
sub-folder wiggling next to them? just run the 3d-dir.scad...:) it just
one  hypothetical example of integration possibilities and uses that
will open...
Peter
 On 10.03.2016 22:01, Torsten Paul wrote:
> On 03/10/2016 04:46 PM, [hidden email] wrote:
>> anyways by now i started to think  openscad really lacks extensibility,
>> through plugins (like i.e. in inkscape) there would be more efficient
>> possibilities for the problems at hand, perhaps there would also be less
>> openscad-variants, and more improvements.
>>
> In general I do like the idea of plugins, but I'm not sure how manageable
> that would be currently. Creating and maintaining a stable plugin API is
> not an easy topic and that would probably mean even less improvements in
> other areas.
>
> The geometry query part is certainly one of the biggest issues, but that's
> not solvable by just adding plugins, it needs the internal changes to
> support that without completely breaking good things like the quick preview.
> That's one of the big things the OpenSCAD2 discussion is supposed to give
> and I hope we can slowly move into that direction so there's not a huge
> leap in the end when trying to get the full list of new features.
>
> As for the variants, and side projects, I'm not so sure. There will always
> be a number of use cases where the descriptive nature of OpenSCAD is not
> going to cover everything and some additional frontend in a general
> programming language is appropriate (like for reading data from a database).
>
> ciao,
>   Torsten.
>
>
> _______________________________________________
> 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: plugins and the 3d-Dir.scad command; was: Re: [semi-on-topic] print speed optimized sinus support material. integration interface possible??

Alan Cox
In reply to this post by doug.moen
On Fri, 11 Mar 2016 11:06:21 -0500
doug moen <[hidden email]> wrote:

> That's an interesting idea. It can be done in a declarative way.
>
> external_transform("warp $in >$out", in="stl", out="stl") cube(10);
>
> The external_transform module takes a shape as an argument, and returns a
> second shape, which is constructed by executing a shell command. The input
> shape is written to a file, the shell command is run, then the output file
> is read to obtain the resulting shape.
>
> I see two problems.
>
> The big problem is security:
>    external_transform("rm -rf $HOME");
> It allows people to write malicious OpenSCAD scripts. This would be a
> problem for Thingiverse and other companies that allow people to upload
> OpenSCAD scripts and execute them on their servers. Hackers could
> distribute trojan-horse OpenSCAD scripts to attack people's personal
> computers.
>
> A smaller problem is that we'd have to execute the shell script during
> preview, which would slow down preview. This could be mitigated by caching.

Another big problem you then have is that you then have to deal with
plugins that only run on one platform or have different versions at which
point all the portability and consistency goes up in smoke.

There are other tools for programmatically generating objects and then
using OpenSCAD to render them. It seems unfortunate that people are still
trying to "fix" openscad rather than just treat it as a tool that does
one job well.

Alan

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

Re: plugins and the 3d-Dir.scad command; was: Re: [semi-on-topic] print speed optimized sinus support material. integration interface possible??

Peter
In reply to this post by doug.moen
Doug, areally  good idea for declarative syntax,indeed.
concerning the security, it will open a new can of worms, but considering the possibiliies i think it is not the reason not to do it, because it can be made optional.
i imagine three different mechanisms which are  very easy to implement:
-disallow the command for the high security environments. (by the way how many websites interpret .scad? from what i know thingyverse only shows the .stl so it is a non issue for the security of the site itself) only run shell commands ifopenscadisrun with "unsecure" switch

-openscad could display big warning screens with commands before executing  the script with the commnds and default toommiting the commands unless the user makesan exceeption.

-all commands could be limited to running scripts javascript virtual machine, which already has all the needed sandboxing and file io security mechanisms built in it, because they always do.
(this wil mitigate the differences between unix and windows as well, but this could be done by bundling unixshell with openscad package anyway.)

it is not trivial but not all that difficult..
Peter
On 11.03.2016 17:37, doug moen wrote:
A third problem is that the syntax of shell commands is different between Windows, Mac, Linux. We'd want a syntax that is platform independent.

The security issues could be mitigated by requiring that external "plugin" executables are installed in an OpenSCAD plugin directory.

On 11 March 2016 at 11:06, doug moen <[hidden email]> wrote:
That's an interesting idea. It can be done in a declarative way.

external_transform("warp $in >$out", in="stl", out="stl") cube(10);

The external_transform module takes a shape as an argument, and returns a second shape, which is constructed by executing a shell command. The input shape is written to a file, the shell command is run, then the output file is read to obtain the resulting shape.

I see two problems.

The big problem is security:
   external_transform("rm -rf $HOME");
It allows people to write malicious OpenSCAD scripts. This would be a problem for Thingiverse and other companies that allow people to upload OpenSCAD scripts and execute them on their servers. Hackers could distribute trojan-horse OpenSCAD scripts to attack people's personal computers.

A smaller problem is that we'd have to execute the shell script during preview, which would slow down preview. This could be mitigated by caching.

On 11 March 2016 at 10:19, [hidden email] <[hidden email]> wrote:
Torsten  I was just thinking aloud.  of course i cannot be sure what
impact these features(shape queering and plugins) would have had on the
project development.
i beleive you have a much clearer perpective on the project as a whole
anyway.

as for keepig the fast rendering functionality, it makes sense to me,
but perhaps it could be an acceptable compromise for more complex models.
i have to gcal-render big deal of the  models i have created to make
them display properly or be able to turn them in the view without
waiting for tens of seconds.
i like complex models and i like to use .children() in my libraries,
that is probably why.  but that is what .children() was made for right?
i think i also see a compromise solution to pugins: if we could scripts
the export to different formats, which are already available from the
menu, from the scad code itself
and then could run an external tool and then import the results back,
that woud be almost as good as plugins.

yes this could affect the declarativity of the scad code.
so perhaps creating a separate special  module in  code like the classic
"main() function" accepting only imperative code as well as
render() calls could solve it.
i can also see a restriction to have only one main() in all included
.scad files and libraries so the utility libraries do not use it and do
not break the modularity and "nestability" of the library code which
than have to stay declarative only.
i expect people to ask now, why not use shell instead?
here are my considerations:
-calling out from scad would be much more convenient and put most of
simple "one line" dependencies into one scad file. it is also than
possible to pass information as command line parameters to the "plugin"
command.
-it is overall much closer to plug-ins. there is a reason other programs
have plugin systems besides being started from a shell as well, so why
do they need it then?
-it is much easier to share a scad file  than an archive full of shell
scripts and scad files, with scripts having to take care where they have
been started from, where are the other files they need, etc.
-it is much simpler to put everything into a single file and perhaps add
one external program or use a system program. HEY HOW ABOUT a 3D ls or
dir command with spheric files flying around your cubic folders and
sub-folder wiggling next to them? just run the 3d-dir.scad...:) it just
one  hypothetical example of integration possibilities and uses that
will open...
Peter
 On 10.03.2016 22:01, Torsten Paul wrote:
> On 03/10/2016 04:46 PM, [hidden email] wrote:
>> anyways by now i started to think  openscad really lacks extensibility,
>> through plugins (like i.e. in inkscape) there would be more efficient
>> possibilities for the problems at hand, perhaps there would also be less
>> openscad-variants, and more improvements.
>>
> In general I do like the idea of plugins, but I'm not sure how manageable
> that would be currently. Creating and maintaining a stable plugin API is
> not an easy topic and that would probably mean even less improvements in
> other areas.
>
> The geometry query part is certainly one of the biggest issues, but that's
> not solvable by just adding plugins, it needs the internal changes to
> support that without completely breaking good things like the quick preview.
> That's one of the big things the OpenSCAD2 discussion is supposed to give
> and I hope we can slowly move into that direction so there's not a huge
> leap in the end when trying to get the full list of new features.
>
> As for the variants, and side projects, I'm not so sure. There will always
> be a number of use cases where the descriptive nature of OpenSCAD is not
> going to cover everything and some additional frontend in a general
> programming language is appropriate (like for reading data from a database).
>
> ciao,
>   Torsten.
>
>
> _______________________________________________
> 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: plugins and the 3d-Dir.scad command; was: Re: [semi-on-topic] print speed optimized sinus support material. integration interface possible??

Peter
In reply to this post by doug.moen
Doug, a really good idea for declarative syntax,indeed.

concerning the security, it will open a new can of worms, but considering the possibilities, i think it is not the reason not to do it.
i imagine three different mechanisms which are  very easy to implement:

-it  could be turned off by default and only activated by the user.

-all commands could be limited to running scripts in a javascript virtual machine, which already has all the needed sandboxing and file io security mechanisms built into it, because they always do.
(this will mitigate the differences between unix and windows as well, but this could be done by bundling unixshell with openscad package anyway.)

-disallow the command for the high security environments. (by the way how many websites interpret .scad? from what i know thingyverse only shows the .stl so it is a non-issue for the security of the site itself)
-only run shell commands if openscad isrun with "unsecure" switch

-openscad could display big warning screens with commands before executing  the script with the commnds and default toommiting the commands unless the user makesan exceeption.



it is not trivial but not all that difficult..
Peter
On 11.03.2016 17:37, doug moen wrote:
A third problem is that the syntax of shell commands is different between Windows, Mac, Linux. We'd want a syntax that is platform independent.

The security issues could be mitigated by requiring that external "plugin" executables are installed in an OpenSCAD plugin directory.

On 11 March 2016 at 11:06, doug moen <[hidden email]> wrote:
That's an interesting idea. It can be done in a declarative way.

external_transform("warp $in >$out", in="stl", out="stl") cube(10);

The external_transform module takes a shape as an argument, and returns a second shape, which is constructed by executing a shell command. The input shape is written to a file, the shell command is run, then the output file is read to obtain the resulting shape.

I see two problems.

The big problem is security:
   external_transform("rm -rf $HOME");
It allows people to write malicious OpenSCAD scripts. This would be a problem for Thingiverse and other companies that allow people to upload OpenSCAD scripts and execute them on their servers. Hackers could distribute trojan-horse OpenSCAD scripts to attack people's personal computers.

A smaller problem is that we'd have to execute the shell script during preview, which would slow down preview. This could be mitigated by caching.

On 11 March 2016 at 10:19, [hidden email] <[hidden email]> wrote:
Torsten  I was just thinking aloud.  of course i cannot be sure what
impact these features(shape queering and plugins) would have had on the
project development.
i beleive you have a much clearer perpective on the project as a whole
anyway.

as for keepig the fast rendering functionality, it makes sense to me,
but perhaps it could be an acceptable compromise for more complex models.
i have to gcal-render big deal of the  models i have created to make
them display properly or be able to turn them in the view without
waiting for tens of seconds.
i like complex models and i like to use .children() in my libraries,
that is probably why.  but that is what .children() was made for right?
i think i also see a compromise solution to pugins: if we could scripts
the export to different formats, which are already available from the
menu, from the scad code itself
and then could run an external tool and then import the results back,
that woud be almost as good as plugins.

yes this could affect the declarativity of the scad code.
so perhaps creating a separate special  module in  code like the classic
"main() function" accepting only imperative code as well as
render() calls could solve it.
i can also see a restriction to have only one main() in all included
.scad files and libraries so the utility libraries do not use it and do
not break the modularity and "nestability" of the library code which
than have to stay declarative only.
i expect people to ask now, why not use shell instead?
here are my considerations:
-calling out from scad would be much more convenient and put most of
simple "one line" dependencies into one scad file. it is also than
possible to pass information as command line parameters to the "plugin"
command.
-it is overall much closer to plug-ins. there is a reason other programs
have plugin systems besides being started from a shell as well, so why
do they need it then?
-it is much easier to share a scad file  than an archive full of shell
scripts and scad files, with scripts having to take care where they have
been started from, where are the other files they need, etc.
-it is much simpler to put everything into a single file and perhaps add
one external program or use a system program. HEY HOW ABOUT a 3D ls or
dir command with spheric files flying around your cubic folders and
sub-folder wiggling next to them? just run the 3d-dir.scad...:) it just
one  hypothetical example of integration possibilities and uses that
will open...
Peter
 On 10.03.2016 22:01, Torsten Paul wrote:
> On 03/10/2016 04:46 PM, [hidden email] wrote:
>> anyways by now i started to think  openscad really lacks extensibility,
>> through plugins (like i.e. in inkscape) there would be more efficient
>> possibilities for the problems at hand, perhaps there would also be less
>> openscad-variants, and more improvements.
>>
> In general I do like the idea of plugins, but I'm not sure how manageable
> that would be currently. Creating and maintaining a stable plugin API is
> not an easy topic and that would probably mean even less improvements in
> other areas.
>
> The geometry query part is certainly one of the biggest issues, but that's
> not solvable by just adding plugins, it needs the internal changes to
> support that without completely breaking good things like the quick preview.
> That's one of the big things the OpenSCAD2 discussion is supposed to give
> and I hope we can slowly move into that direction so there's not a huge
> leap in the end when trying to get the full list of new features.
>
> As for the variants, and side projects, I'm not so sure. There will always
> be a number of use cases where the descriptive nature of OpenSCAD is not
> going to cover everything and some additional frontend in a general
> programming language is appropriate (like for reading data from a database).
>
> ciao,
>   Torsten.
>
>
> _______________________________________________
> 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: plugins and the 3d-Dir.scad command; was: Re: [semi-on-topic] print speed optimized sinus support material. integration interface possible??

Peter
In reply to this post by Alan Cox
hello Alan
this would be resolved by the javascript sandbox i mentioned in my
previos post.
what exactyl do you mean by
"there are other tools for programmatically generating objects and then
using OpenSCAD to render them. "?
Peter
 On 11.03.2016 18:30, Alan Cox wrote:

> On Fri, 11 Mar 2016 11:06:21 -0500
> doug moen <[hidden email]> wrote:
>
>> That's an interesting idea. It can be done in a declarative way.
>>
>> external_transform("warp $in >$out", in="stl", out="stl") cube(10);
>>
>> The external_transform module takes a shape as an argument, and returns a
>> second shape, which is constructed by executing a shell command. The input
>> shape is written to a file, the shell command is run, then the output file
>> is read to obtain the resulting shape.
>>
>> I see two problems.
>>
>> The big problem is security:
>>    external_transform("rm -rf $HOME");
>> It allows people to write malicious OpenSCAD scripts. This would be a
>> problem for Thingiverse and other companies that allow people to upload
>> OpenSCAD scripts and execute them on their servers. Hackers could
>> distribute trojan-horse OpenSCAD scripts to attack people's personal
>> computers.
>>
>> A smaller problem is that we'd have to execute the shell script during
>> preview, which would slow down preview. This could be mitigated by caching.
> Another big problem you then have is that you then have to deal with
> plugins that only run on one platform or have different versions at which
> point all the portability and consistency goes up in smoke.
>
> There are other tools for programmatically generating objects and then
> using OpenSCAD to render them. It seems unfortunate that people are still
> trying to "fix" openscad rather than just treat it as a tool that does
> one job well.
>
> Alan
>
> _______________________________________________
> 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: [semi-on-topic] print speed optimized sinus support material. integration interface possible??

Parkinbot
In reply to this post by Peter
Peter,

from your answer I can guess you didn't fully unterstand, what I meant. I did NOT mean to use a hull operation in OpenSCAD.
I meant to use JavaScript to
1. parse an STL export of your model
2. determine all surface parts that need support (using criteria like: triangle inclination > min_support_angle)
3. close this surface against xy plane (z=0) into an object that describes the full volume (=hull) of your support and write it out as STL.

This is more or less straight forward. Then continue with OpenSCAD
3. import this STL and use intersection() to cut the support from a generic block of sine infill structure
4. combine your support with your model.

This is also straight forward.

Peter wrote
i.e. just as you write creating a hull of the model and subtracting it
from the support structures will help,
if the Model is not convex it will not quite work, but one can
"subdivide" the model using a small cube  "rastering" the Space
containing your model, creating smaller Hulls in the intersection with
this cube and then unioning them together and subtracting the whole
thing from the support structure.
Reply | Threaded
Open this post in threaded view
|

Re: plugins and the 3d-Dir.scad command; was: Re: [semi-on-topic] print speed optimized sinus support material. integration interface possible??

Alan Cox
In reply to this post by Peter
On Fri, 11 Mar 2016 18:48:51 +0100
"[hidden email]" <[hidden email]> wrote:

> hello Alan
> this would be resolved by the javascript sandbox i mentioned in my
> previos post.
> what exactyl do you mean by
> "there are other tools for programmatically generating objects and then
> using OpenSCAD to render them. "?

OpenSCAD is a tool that turns one set of input into another. If you need
to do more complex stuff you can already wrap it in other tools and call
it as needed.

Alan

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

Re: [semi-on-topic] print speed optimized sinus support material. integration interface possible??

nophead
In reply to this post by Parkinbot
Why not just fork your favourite open source slicer and modify the support material generation in that?

On 11 March 2016 at 18:21, Parkinbot <[hidden email]> wrote:
Peter,

from your answer I can guess you didn't fully unterstand, what I meant. I
did NOT mean to use a hull operation in OpenSCAD.
I meant to use JavaScript to
1. parse an STL export of your model
2. determine all surface parts that need support (using criteria like:
triangle inclination > min_support_angle)
3. close this surface against xy plane (z=0) into an object that describes
the full volume (=hull) of your support and write it out as STL.

This is more or less straight forward. Then continue with OpenSCAD
3. import this STL and use intersection() to cut the support from a generic
block of sine infill structure
4. combine your support with your model.

This is also straight forward.


Peter wrote
> i.e. just as you write creating a hull of the model and subtracting it
> from the support structures will help,
> if the Model is not convex it will not quite work, but one can
> "subdivide" the model using a small cube  "rastering" the Space
> containing your model, creating smaller Hulls in the intersection with
> this cube and then unioning them together and subtracting the whole
> thing from the support structure.





--
View this message in context: http://forum.openscad.org/semi-on-topic-print-speed-optimized-sinus-support-material-integration-interface-possible-tp16383p16417.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
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: [semi-on-topic] print speed optimized sinus support material. integration interface possible??

clothbot
In reply to this post by jon_bondy
If/when there is a convex_decomposition() function implemented (see https://github.com/openscad/openscad/issues/1562), here's one approach you could take to create support 'mask' geometry which could then be intersection()'d with your support pattern:

https://github.com/clothbot/ClothBotCreations/blob/master/examples/concave_support.scad

https://github.com/clothbot/ClothBotCreations/blob/master/examples/concave_support_faked.png

- the projection(cut=false) gets the 'shadow' for each concave part.

- linear_extrude the shadow by a layer thickness and hull() it with the original concave part to 'fill' the support volume.

- difference off minkowski() all of the original concave parts with a 'small enough' spacer shape so the slicer doesn't try to join the support to the original part.

Once you have that 'concave_support' output, do an intersection() with your support pattern for the final geometry.

Andrew.
12