@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:

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:

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:

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:

The following code will create a box filled with cosine support. CGAL
rendering is almost instantaneous.
Is it what you were asking for?

http://forum.openscad.org/file/n16438/sinecomb.png

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:

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:

On 03/12/2016 04:34 PM, Ronaldo Persiano wrote:

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.