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:

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:

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:

On 03/10/2016 04:46 PM, pproj@posteo.de wrote:

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.

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:

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:

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:

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: