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