[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.
@clothbot - that is a very nice solution. looking fwd to it...
--
View this message in context: http://forum.openscad.org/semi-on-topic-print-speed-optimized-sinus-support-material-integration-interface-possible-tp16383p16424.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
@clothbot strategy may be nicely implemented without any extension to the
last OpenSCAD version.
​
​
part_height = 50;
module up_hull(h){
minkowski(){
children();
cylinder(r1=0,r2=h/100,h=h);
}
}
module support_mask(ph){
render(convexity=10)
difference() {
linear_extrude(height=ph)
projection(cut=false)
children();
up_hull(ph)
children();
}
}
render(convexity = 4) part();
translate([150,0,0]) projection(cut=false) part();
translate([300,0,0]) linear_extrude(height=part_height)
projection(cut=false) part();
translate([450,0,0]) up_hull(part_height) part();
translate([600,0,0]) support_mask(part_height) part();
2016-03-11 20:23 GMT-03:00 Neon22 mschafer@wireframe.biz:
@clothbot - that is a very nice solution. looking fwd to it...
--
View this message in context:
http://forum.openscad.org/semi-on-topic-print-speed-optimized-sinus-support-material-integration-interface-possible-tp16383p16424.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
Ronaldo nice indeed,
but how would you implement a continuous sinus form?
any cut through a pre-made sinus filed block will produce many
discontinuities which will slowdown the printing process a lot.
there is no way i can think of of joining these together again in scad,
many slow prints where my support was way slower than slic3rs, and
inability to query existing geometry were what made me turn to javascript.
it was not an easy decision.
actually i can see this this approach as a perfect complement to a an
external sinus tool.
i will just have to export the step#2 as svg,fill it with sinus with the
external tool (or half-circle which might turn out to be even faster)
then extrude the result and cut it like your last form
Peter
On 12.03.2016 04:01, Ronaldo Persiano wrote:
@clothbot strategy may be nicely implemented without any extension to
the last OpenSCAD version.
​
​
part_height = 50;
module up_hull(h){
minkowski(){
children();
cylinder(r1=0,r2=h/100,h=h);
}
}
module support_mask(ph){
render(convexity=10)
difference() {
linear_extrude(height=ph)
projection(cut=false)
children();
up_hull(ph)
children();
}
}
render(convexity = 4) part();
translate([150,0,0]) projection(cut=false) part();
translate([300,0,0]) linear_extrude(height=part_height)
projection(cut=false) part();
translate([450,0,0]) up_hull(part_height) part();
translate([600,0,0]) support_mask(part_height) part();
2016-03-11 20:23 GMT-03:00 Neon22 <mschafer@wireframe.biz
mailto:mschafer@wireframe.biz>:
@clothbot - that is a very nice solution. looking fwd to it...
--
View this message in context:
http://forum.openscad.org/semi-on-topic-print-speed-optimized-sinus-support-material-integration-interface-possible-tp16383p16424.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
_______________________________________________
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
Why not just fork your favourite open source slicer and modify the
support material generation in that?
i was thinking about this but i see to many cons:
i consider forks harmful, i think if a project disintegrates into many
forks, there is a good chance it will cease to exits all together soon.
i would be stuck with the version of slicer which i have forked,
redoing the same changes for every new version and creating even more
forks is not a trivial task. that means the changes will be obsolete
quickly.
it is much more effort to study the complex inner working of the slicer
to be able to implement stuff inside , compile it , test the whole
thing. it is a much bigger project than creating a small script.
one could consider forking and extending openscad itself with the "call
out to javascript" functionality as well. at least this might limit the
desire for even more forks. and it appears to me be an easier
project(though i do not know really), but i do not want to create
another f#rking f#rk of openscad anyway!
i think getting along with other people and creating stuff together is
a much harder project, than just doing it for yourself and forking, but
in the end it should be better for everybody.(in theory at least)
Peter
On 11.03.2016 19:47, nop head wrote:
On 11 March 2016 at 18:21, Parkinbot <rudolf@parkinbot.com
mailto: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
1. parse an STL export of your model
2. determine all surface parts that need support (using criteria like:
triangle inclination > min_support_angle)
3. close this surface against xy plane (z=0) into an object that
describes
the full volume (=hull) of your support and write it out as STL.
This is more or less straight forward. Then continue with OpenSCAD
3. import this STL and use intersection() to cut the support from
a generic
block of sine infill structure
4. combine your support with your model.
This is also straight forward.
Peter wrote
i.e. just as you write creating a hull of the model and
subtracting it
from the support structures will help,
if the Model is not convex it will not quite work, but one can
"subdivide" the model using a small cube "rastering" the Space
containing your model, creating smaller Hulls in the
intersection with
this cube and then unioning them together and subtracting the whole
thing from the support structure.
--
View this message in context:
http://forum.openscad.org/semi-on-topic-print-speed-optimized-sinus-support-material-integration-interface-possible-tp16383p16417.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
_______________________________________________
OpenSCAD mailing list
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
ok i see now, yes.
these mechanisms ,whether you put them into openscad code, slicer or
JavaScript tool, are very nice to have.
but one could live without them at all in a great deal of cases, just
union the model with a support material block of the height you choose.
if you consider the angle to be steep enough , just do not do it.
the whole point of the tool was to produce the continuous form inside
the support material block which fits the outline of the model, so that
you do not get many separate half waves at the outline. these
discontinuities turned out very slow to print because of filament
retractions, deccelerations and "idle" head moves.
Peter
On 11.03.2016 19:21, Parkinbot 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
The following code will create a box filled with cosine support. CGAL
rendering is almost instantaneous.
Is it what you were asking for?
supportblock();
module supportblock(rows = 10, cols = 10, box = [100, 100, 10], thickness
= .1)
{
amplitude = box[1]/rows/2;
wavelength = box[0]/cols PI;
linear_extrude(height = box[2])
for(i = [0:rows-1])
Ty(iamplitude*2)
polygon(points = sine(cols, amplitude, wavelength, i%2, thickness));
}
function sine(periods, amplitude, wavelength, mode, thickness = .01) =
let(amp = amplitude-thickness/1.9)
concat(
[for(i=[0:10:360periods]) [i/wavelength, ampcos(i+mode180)]],
[for(i=[360periods:-1:0]) [i/wavelength,
ampcos(i+mode180)+thickness]]);
Rudolf
--
View this message in context: http://forum.openscad.org/semi-on-topic-print-speed-optimized-sinus-support-material-integration-interface-possible-tp16383p16438.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
i think i have problems explaining what this javascript tool is actually
about.
the starting point was a code in scad very similar to yours creating a
sine filled block.
but the tool does not create a rectangular box filled with sinus.
cutting out a footprint of almost any model out of such block will
produce many discontinuities at the areas where the sinus wave is cut by
the outline of footprint of the model. it will create many standalone
"islands" of fractures of a sinewave. this will slow down the print.
what the javascript tool realy does, and i think it is impossible in
openscad without querieng the geometry, it tries to create a continous
sine or half-scircle wave in the footprint of the model, so that you do
not have to cut out the footprint out of a sine block, and printer can
(ideally) print the whole layer of support without deccelerating or idly
moving its head
Peter
On 12.03.2016 14:45, Parkinbot wrote:
The following code will create a box filled with cosine support. CGAL
rendering is almost instantaneous.
Is it what you were asking for?
supportblock();
module supportblock(rows = 10, cols = 10, box = [100, 100, 10], thickness
= .1)
{
amplitude = box[1]/rows/2;
wavelength = box[0]/cols PI;
linear_extrude(height = box[2])
for(i = [0:rows-1])
Ty(iamplitude*2)
polygon(points = sine(cols, amplitude, wavelength, i%2, thickness));
}
function sine(periods, amplitude, wavelength, mode, thickness = .01) =
let(amp = amplitude-thickness/1.9)
concat(
[for(i=[0:10:360periods]) [i/wavelength, ampcos(i+mode180)]],
[for(i=[360periods:-1:0]) [i/wavelength,
ampcos(i+mode180)+thickness]]);
Rudolf
--
View this message in context: http://forum.openscad.org/semi-on-topic-print-speed-optimized-sinus-support-material-integration-interface-possible-tp16383p16438.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
My slicer does a nice path on that. If linewidth is not to thin jump don't
occur often. Of course, there are jumps at the boundaries. Jump minimization
is another task done by the slicer.
So, if path planning and GCODE optimization is your concern, OpenScad will
not help you. Better follow nophead's proposal and fork out your own slic3r
branch to solve your problems there. https://github.com/alexrj/Slic3r
Rudolf
--
View this message in context: http://forum.openscad.org/semi-on-topic-print-speed-optimized-sinus-support-material-integration-interface-possible-tp16383p16443.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
I understand your point and agree that there is no way to do it entirely in
OpenSCAD without geometry query tools. However, it would not be difficult
to write a javascript code to process an OpenSCAD stl file of the
linear_extrude() of the part projection. This code would generate a text
file like this:
model=[
[[275,50,0], [275,100,0], [285,50,0]],
[[315,-50,0], [325,-50,0], [325,-100,0]],
[[315,50,0], [325,100,0], [325,50,0]],
[[315,50,0], [275,100,0], [325,100,0]],
[[285,-50,0], [285,50,0], [315,-50,0]],
[[315,-50,0], [285,50,0], [315,50,0]],
[[285,50,0], [275,100,0], [315,50,0]],
[[275,-100,0], [285,-50,0], [315,-50,0]],
[[275,-100,0], [275,-50,0], [285,-50,0]],
[[325,-100,0], [275,-100,0], [315,-50,0]]];
which could be inserted in a OpenSCAD code for further processing.
That approach doesn't avoid an external processing but the javascript code
could be valuable to any application demanding geometric queries. And you
may write then your support generation methods in OpenSCAD. :)
As a complement, would be nice also to have an OpenSCAD library to answer
geometric queries about models generated this way.
2016-03-12 11:15 GMT-03:00 pproj@posteo.de pproj@posteo.de:
i think i have problems explaining what this javascript tool is actually
about.
the starting point was a code in scad very similar to yours creating a
sine filled block.
but the tool does not create a rectangular box filled with sinus.
cutting out a footprint of almost any model out of such block will
produce many discontinuities at the areas where the sinus wave is cut by
the outline of footprint of the model. it will create many standalone
"islands" of fractures of a sinewave. this will slow down the print.
what the javascript tool realy does, and i think it is impossible in
openscad without querieng the geometry, it tries to create a continous
sine or half-scircle wave in the footprint of the model, so that you do
not have to cut out the footprint out of a sine block, and printer can
(ideally) print the whole layer of support without deccelerating or idly
moving its head
Peter
On 12.03.2016 14:45, Parkinbot wrote:
The following code will create a box filled with cosine support. CGAL
rendering is almost instantaneous.
Is it what you were asking for?
supportblock();
module supportblock(rows = 10, cols = 10, box = [100, 100, 10],
thickness
= .1)
{
amplitude = box[1]/rows/2;
wavelength = box[0]/cols PI;
linear_extrude(height = box[2])
for(i = [0:rows-1])
Ty(iamplitude*2)
polygon(points = sine(cols, amplitude, wavelength, i%2, thickness));
}
function sine(periods, amplitude, wavelength, mode, thickness = .01) =
let(amp = amplitude-thickness/1.9)
concat(
[for(i=[0:10:360periods]) [i/wavelength, ampcos(i+mode180)]],
[for(i=[360periods:-1:0]) [i/wavelength,
ampcos(i+mode180)+thickness]]);
Rudolf
--
View this message in context:
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
On 03/12/2016 04:34 PM, Ronaldo Persiano wrote:
As a complement, would be nice also to have an OpenSCAD library
to answer geometric queries about models generated this way.
I agree, and this will hopefully come, but it's a fair amount of
work.
Although for the specific solution of producing better support
structures for 3d printing it would be greatly beneficial if that
would be implemented in one of the open source slicers. This would
then easily available for all people using the open source tool
chain for 3d printing.
In addition the slicer has some additional information that will
make support better fit the actual machine configuration.
Also in my view there is absolutely nothing wrong with forking a
project with the intention of contributing changes back.
The only bad kind of forking is to create a parallel project
if the main project is still alive and responsive to feedback.
ciao,
Torsten.
well what should i say? i am glad your slicer is working out well for
you, so you will probably have no need for similar tools and all the
export and import steps the process requires,
it was definitely not the case on my models with slic3r, that was the
very reason i interrupted the work on the part and took time to
implement the support.
first in .scad and redoing it in javascript for the reasons we have been
talking about. and it is actually working reasonably well for me (and i
am not going to say perfect no, but it is an obvios improvement in
support quality vs printing time in my case).
there are many reasons i am not going to f#rk (with) slicers source i
just have been discussing in the same thread with nop-head. there were
many reasons to go the .js path, and it seems to work, and i hope others
who experience similar problems with slicers support, can use it as
well, that is why i put it on github, and in the process of this
discussion may be we will come up with a way of making openscad more
extensible and open for tools. thats it.
Peter
On 12.03.2016 16:21, Parkinbot wrote:
My slicer does a nice path on that. If linewidth is not to thin jump don't
occur often. Of course, there are jumps at the boundaries. Jump minimization
is another task done by the slicer.
So, if path planning and GCODE optimization is your concern, OpenScad will
not help you. Better follow nophead's proposal and fork out your own slic3r
branch to solve your problems there. https://github.com/alexrj/Slic3r
Rudolf
--
View this message in context: http://forum.openscad.org/semi-on-topic-print-speed-optimized-sinus-support-material-integration-interface-possible-tp16383p16443.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
Ronaldo i am not 100% sure i understand you right, but i think this i
exactly what the current tool we are discussing is doing, it just skips
the extrusion step and processes the2D .svg of the projection directly.
then it writes out the support path data as an openscad vector text
file supportPathData.scad which one can then extrude to any height needed.
comprende?
Peter
On 12.03.2016 16:34, Ronaldo Persiano wrote:
I understand your point and agree that there is no way to do it
entirely in OpenSCAD without geometry query tools. However, it would
not be difficult to write a javascript code to process an OpenSCAD stl
file of the linear_extrude() of the part projection. This code would
generate a text file like this:
model=[
[[275,50,0], [275,100,0], [285,50,0]],
[[315,-50,0], [325,-50,0], [325,-100,0]],
[[315,50,0], [325,100,0], [325,50,0]],
[[315,50,0], [275,100,0], [325,100,0]],
[[285,-50,0], [285,50,0], [315,-50,0]],
[[315,-50,0], [285,50,0], [315,50,0]],
[[285,50,0], [275,100,0], [315,50,0]],
[[275,-100,0], [285,-50,0], [315,-50,0]],
[[275,-100,0], [275,-50,0], [285,-50,0]],
[[325,-100,0], [275,-100,0], [315,-50,0]]];
which could be inserted in a OpenSCAD code for further processing.
That approach doesn't avoid an external processing but the javascript
code could be valuable to any application demanding geometric queries.
And you may write then your support generation methods in OpenSCAD. :)
As a complement, would be nice also to have an OpenSCAD library to
answer geometric queries about models generated this way.
2016-03-12 11:15 GMT-03:00 pproj@posteo.de mailto:pproj@posteo.de
<pproj@posteo.de mailto:pproj@posteo.de>:
i think i have problems explaining what this javascript tool is
actually
about.
the starting point was a code in scad very similar to yours creating a
sine filled block.
but the tool does _not_ create a rectangular box filled with sinus.
cutting out a footprint of almost any model out of such block will
produce many discontinuities at the areas where the sinus wave is
cut by
the outline of footprint of the model. it will create many standalone
"islands" of fractures of a sinewave. this will slow down the print.
what the javascript tool realy does, and i think it is impossible in
openscad without querieng the geometry, it tries to create a
_continous_
sine or half-scircle wave in the footprint of the model, so that
you do
not have to cut out the footprint out of a sine block, and printer can
(ideally) print the whole layer of support without deccelerating
or idly
moving its head
Peter
On 12.03.2016 14:45, Parkinbot wrote:
The following code will create a box filled with cosine support.
CGAL
rendering is almost instantaneous.
Is it what you were asking for?
supportblock();
module supportblock(rows = 10, cols = 10, box = [100, 100, 10],
thickness
= .1)
{
amplitude = box[1]/rows/2;
wavelength = box[0]/cols PI;
linear_extrude(height = box[2])
for(i = [0:rows-1])
Ty(iamplitude*2)
polygon(points = sine(cols, amplitude, wavelength, i%2,
thickness));
}
function sine(periods, amplitude, wavelength, mode, thickness =
.01) =
let(amp = amplitude-thickness/1.9)
concat(
[for(i=[0:10:360periods]) [i/wavelength, ampcos(i+mode180)]],
[for(i=[360periods:-1:0]) [i/wavelength,
ampcos(i+mode180)+thickness]]);
Rudolf
--
View this message in context:
http://forum.openscad.org/semi-on-topic-print-speed-optimized-sinus-support-material-integration-interface-possible-tp16383p16438.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
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
In my simple mind OpenScad is as simple tool for describing geometry, not
querying it. Slicers take geometry and produce tool paths. If you don't
like the tool path modify the slicer. Don't advocate making OpenScad more
more complicated. Make the slicer more sophisticated.
Support material doesn't need to be sinusoidal, but it could benefit from
rounded corners (as could all tool paths) because above a certain radius
the x and y accelerations are capable of turning the corner without slowing
down at all.
I must admit I do make support structures myself in Openscad but I export
them separately and slice them separately and combine the gcode with the
appropriate z offset. See
http://hydraraptor.blogspot.co.uk/2012/08/peel-able-support.html. Support
needs a solid interface layer less than a layer height below the object, so
you can't export it in the same file as the object and expect the slicer to
make it peelable.
One day I will write my own slicer to do this automatically.
On 12 March 2016 at 16:00, pproj@posteo.de pproj@posteo.de wrote:
Ronaldo i am not 100% sure i understand you right, but i think this i
exactly what the current tool we are discussing is doing, it just skips the
extrusion step and processes the2D .svg of the projection directly. then
it writes out the support path data as an openscad vector text file
supportPathData.scad which one can then extrude to any height needed.
comprende?
Peter
On 12.03.2016 16:34, Ronaldo Persiano wrote:
I understand your point and agree that there is no way to do it entirely
in OpenSCAD without geometry query tools. However, it would not be
difficult to write a javascript code to process an OpenSCAD stl file of the
linear_extrude() of the part projection. This code would generate a text
file like this:
model=[
[[275,50,0], [275,100,0], [285,50,0]],
[[315,-50,0], [325,-50,0], [325,-100,0]],
[[315,50,0], [325,100,0], [325,50,0]],
[[315,50,0], [275,100,0], [325,100,0]],
[[285,-50,0], [285,50,0], [315,-50,0]],
[[315,-50,0], [285,50,0], [315,50,0]],
[[285,50,0], [275,100,0], [315,50,0]],
[[275,-100,0], [285,-50,0], [315,-50,0]],
[[275,-100,0], [275,-50,0], [285,-50,0]],
[[325,-100,0], [275,-100,0], [315,-50,0]]];
which could be inserted in a OpenSCAD code for further processing.
That approach doesn't avoid an external processing but the javascript code
could be valuable to any application demanding geometric queries. And you
may write then your support generation methods in OpenSCAD. :)
As a complement, would be nice also to have an OpenSCAD library to answer
geometric queries about models generated this way.
2016-03-12 11:15 GMT-03:00 pproj@posteo.depproj@posteo.de <
pproj@posteo.de>:
i think i have problems explaining what this javascript tool is actually
about.
the starting point was a code in scad very similar to yours creating a
sine filled block.
but the tool does not create a rectangular box filled with sinus.
cutting out a footprint of almost any model out of such block will
produce many discontinuities at the areas where the sinus wave is cut by
the outline of footprint of the model. it will create many standalone
"islands" of fractures of a sinewave. this will slow down the print.
what the javascript tool realy does, and i think it is impossible in
openscad without querieng the geometry, it tries to create a continous
sine or half-scircle wave in the footprint of the model, so that you do
not have to cut out the footprint out of a sine block, and printer can
(ideally) print the whole layer of support without deccelerating or idly
moving its head
Peter
On 12.03.2016 14:45, Parkinbot wrote:
The following code will create a box filled with cosine support. CGAL
rendering is almost instantaneous.
Is it what you were asking for?
supportblock();
module supportblock(rows = 10, cols = 10, box = [100, 100, 10],
thickness
= .1)
{
amplitude = box[1]/rows/2;
wavelength = box[0]/cols PI;
linear_extrude(height = box[2])
for(i = [0:rows-1])
Ty(iamplitude*2)
polygon(points = sine(cols, amplitude, wavelength, i%2,
thickness));
}
function sine(periods, amplitude, wavelength, mode, thickness = .01) =
let(amp = amplitude-thickness/1.9)
concat(
[for(i=[0:10:360periods]) [i/wavelength, ampcos(i+mode180)]],
[for(i=[360periods:-1:0]) [i/wavelength,
ampcos(i+mode180)+thickness]]);
Rudolf
--
View this message in context:
http://forum.openscad.org/semi-on-topic-print-speed-optimized-sinus-support-material-integration-interface-possible-tp16383p16438.html
http://forum.openscad.org/semi-on-topic-print-speed-optimized-sinus-support-material-integration-interface-possible-tp16383p16438.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
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
@nophead That blog post is quite interesting, thanks.
This makes it clear why you need a special feature in the slicer to do user
defined peelable support. The support object would have to be imported as a
separate STL. Or, if we implement multiple colours/materials using a single
AMF file, as discussed in other threads, then the support object could be
included in the AMF file as a separate labeled object.
On 12 March 2016 at 20:06, nop head nop.head@gmail.com wrote:
In my simple mind OpenScad is as simple tool for describing geometry, not
querying it. Slicers take geometry and produce tool paths. If you don't
like the tool path modify the slicer. Don't advocate making OpenScad more
more complicated. Make the slicer more sophisticated.
Support material doesn't need to be sinusoidal, but it could benefit from
rounded corners (as could all tool paths) because above a certain radius
the x and y accelerations are capable of turning the corner without slowing
down at all.
I must admit I do make support structures myself in Openscad but I export
them separately and slice them separately and combine the gcode with the
appropriate z offset. See
http://hydraraptor.blogspot.co.uk/2012/08/peel-able-support.html. Support
needs a solid interface layer less than a layer height below the object, so
you can't export it in the same file as the object and expect the slicer to
make it peelable.
One day I will write my own slicer to do this automatically.
On 12 March 2016 at 16:00, pproj@posteo.de pproj@posteo.de wrote:
Ronaldo i am not 100% sure i understand you right, but i think this i
exactly what the current tool we are discussing is doing, it just skips the
extrusion step and processes the2D .svg of the projection directly. then
it writes out the support path data as an openscad vector text file
supportPathData.scad which one can then extrude to any height needed.
comprende?
Peter
On 12.03.2016 16:34, Ronaldo Persiano wrote:
I understand your point and agree that there is no way to do it entirely
in OpenSCAD without geometry query tools. However, it would not be
difficult to write a javascript code to process an OpenSCAD stl file of the
linear_extrude() of the part projection. This code would generate a text
file like this:
model=[
[[275,50,0], [275,100,0], [285,50,0]],
[[315,-50,0], [325,-50,0], [325,-100,0]],
[[315,50,0], [325,100,0], [325,50,0]],
[[315,50,0], [275,100,0], [325,100,0]],
[[285,-50,0], [285,50,0], [315,-50,0]],
[[315,-50,0], [285,50,0], [315,50,0]],
[[285,50,0], [275,100,0], [315,50,0]],
[[275,-100,0], [285,-50,0], [315,-50,0]],
[[275,-100,0], [275,-50,0], [285,-50,0]],
[[325,-100,0], [275,-100,0], [315,-50,0]]];
which could be inserted in a OpenSCAD code for further processing.
That approach doesn't avoid an external processing but the javascript
code could be valuable to any application demanding geometric queries. And
you may write then your support generation methods in OpenSCAD. :)
As a complement, would be nice also to have an OpenSCAD library to answer
geometric queries about models generated this way.
2016-03-12 11:15 GMT-03:00 pproj@posteo.depproj@posteo.de <
pproj@posteo.de>:
i think i have problems explaining what this javascript tool is actually
about.
the starting point was a code in scad very similar to yours creating a
sine filled block.
but the tool does not create a rectangular box filled with sinus.
cutting out a footprint of almost any model out of such block will
produce many discontinuities at the areas where the sinus wave is cut by
the outline of footprint of the model. it will create many standalone
"islands" of fractures of a sinewave. this will slow down the print.
what the javascript tool realy does, and i think it is impossible in
openscad without querieng the geometry, it tries to create a continous
sine or half-scircle wave in the footprint of the model, so that you do
not have to cut out the footprint out of a sine block, and printer can
(ideally) print the whole layer of support without deccelerating or idly
moving its head
Peter
On 12.03.2016 14:45, Parkinbot wrote:
The following code will create a box filled with cosine support. CGAL
rendering is almost instantaneous.
Is it what you were asking for?
supportblock();
module supportblock(rows = 10, cols = 10, box = [100, 100, 10],
thickness
= .1)
{
amplitude = box[1]/rows/2;
wavelength = box[0]/cols PI;
linear_extrude(height = box[2])
for(i = [0:rows-1])
Ty(iamplitude*2)
polygon(points = sine(cols, amplitude, wavelength, i%2,
thickness));
}
function sine(periods, amplitude, wavelength, mode, thickness = .01) =
let(amp = amplitude-thickness/1.9)
concat(
[for(i=[0:10:360periods]) [i/wavelength, ampcos(i+mode180)]],
[for(i=[360periods:-1:0]) [i/wavelength,
ampcos(i+mode180)+thickness]]);
Rudolf
--
View this message in context:
http://forum.openscad.org/semi-on-topic-print-speed-optimized-sinus-support-material-integration-interface-possible-tp16383p16438.html
http://forum.openscad.org/semi-on-topic-print-speed-optimized-sinus-support-material-integration-interface-possible-tp16383p16438.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
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
nophead wrote
In my simple mind OpenScad is as simple tool for describing geometry, not
querying it.
Beyond paradigm discussion and the fact that no function can operate over
geometry by now: By design of OpenSCAD there is also a severe technical
restriction to query geometry. CSG (F5) representation is rendered only
implicitly by OpenGL. Explict geometry (which may be queried) is only known
after CGAL rendering (F6).
But as already has been discussed in other threads there is no reason to NOT
offer a query on STL imports - at least from an implementation point of view
- which I hope will be coming with the next major release.
Rudolf
--
View this message in context: http://forum.openscad.org/semi-on-topic-print-speed-optimized-sinus-support-material-integration-interface-possible-tp16383p16458.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Yes getting info from imported geometry is useful and has no impact on the
declarative nature. It effectively becomes part of the description, another
form of source code. Similarly getting info from a polygon or polyhedron as
the mesh is available during preview.
On 13 March 2016 at 12:49, Parkinbot rudolf@parkinbot.com wrote:
nophead wrote
In my simple mind OpenScad is as simple tool for describing geometry, not
querying it.
Beyond paradigm discussion and the fact that no function can operate over
geometry by now: By design of OpenSCAD there is also a severe technical
restriction to query geometry. CSG (F5) representation is rendered only
implicitly by OpenGL. Explict geometry (which may be queried) is only known
after CGAL rendering (F6).
But as already has been discussed in other threads there is no reason to
NOT
offer a query on STL imports - at least from an implementation point of
view
- which I hope will be coming with the next major release.
Rudolf
--
View this message in context:
http://forum.openscad.org/semi-on-topic-print-speed-optimized-sinus-support-material-integration-interface-possible-tp16383p16458.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