[semi-on-topic] print speed optimized sinus support material. integration interface possible??
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
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 pproj@posteo.de 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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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 <pproj@posteo.de
mailto:pproj@posteo.de> 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
Discuss@lists.openscad.org <mailto:Discuss@lists.openscad.org>
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
How do you print your support structures? Do you slice them separately and
apply a Z offset?
On 10 March 2016 at 15:46, pproj@posteo.de pproj@posteo.de 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 pproj@posteo.de 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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing listDiscuss@lists.openscad.orghttp://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 03/10/2016 04:46 PM, pproj@posteo.de 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.
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.
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, pproj@posteo.de <pproj@posteo.de
mailto:pproj@posteo.de> 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 <pproj@posteo.de
<mailto:pproj@posteo.de>> 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
Discuss@lists.openscad.org <mailto:Discuss@lists.openscad.org>
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
Discuss@lists.openscad.org <mailto:Discuss@lists.openscad.org>
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
Discuss@lists.openscad.org <mailto:Discuss@lists.openscad.org>
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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, pproj@posteo.de 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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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, pproj@posteo.de 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
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, pproj@posteo.de pproj@posteo.de 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, pproj@posteo.de 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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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 doug@moens.org 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, pproj@posteo.de pproj@posteo.de 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, pproj@posteo.de 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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On Fri, 11 Mar 2016 11:06:21 -0500
doug moen doug@moens.org 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
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 <doug@moens.org
mailto:doug@moens.org> 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, pproj@posteo.de
<mailto:pproj@posteo.de> <pproj@posteo.de
<mailto:pproj@posteo.de>> 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, pproj@posteo.de
<mailto:pproj@posteo.de> 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).
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
Discuss@lists.openscad.org <mailto:Discuss@lists.openscad.org>
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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 <doug@moens.org
mailto:doug@moens.org> 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, pproj@posteo.de
<mailto:pproj@posteo.de> <pproj@posteo.de
<mailto:pproj@posteo.de>> 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, pproj@posteo.de
<mailto:pproj@posteo.de> 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).
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
Discuss@lists.openscad.org <mailto:Discuss@lists.openscad.org>
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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 doug@moens.org 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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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
- parse an STL export of your model
- determine all surface parts that need support (using criteria like:
triangle inclination > min_support_angle) - 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.
On Fri, 11 Mar 2016 18:48:51 +0100
"pproj@posteo.de" pproj@posteo.de 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
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 rudolf@parkinbot.com 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
- parse an STL export of your model
- determine all surface parts that need support (using criteria like:
triangle inclination > min_support_angle) - 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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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.
--
View this message in context: http://forum.openscad.org/semi-on-topic-print-speed-optimized-sinus-support-material-integration-interface-possible-tp16383p16420.html
Sent from the OpenSCAD mailing list archive at Nabble.com.