@William ....
beautiful... do you know the process to get to this result?
--
View this message in context: http://forum.openscad.org/rendering-for-paper-assembly-manual-tp20108p20119.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Ronaldo,
I was trying to sketch a function allowing you transform some STL into an
outline drawing. For this you want to do away with the "inner" triangulation
and this needs some filter approach.
http://forum.openscad.org/file/n20120/stl.png
My question to the dev team was, if it has just capacity reasons, why such
an "easy to implement" and "no side effect" function is not provided, or if
there are political reasons.
--
View this message in context: http://forum.openscad.org/rendering-for-paper-assembly-manual-tp20108p20120.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
On Mon, Jan 16, 2017 at 10:28 AM, pierrepoulpe contact@pierrebeck.fr
wrote:
@William ....
beautiful... do you know the process to get to this result?
Thank you! I'm flattered --- it's just a matter of editing the SVG for
interactivity --- I documented it pretty thoroughly on the Shapeoko forums,
Inkscape mailing list, and Github change logs I'd thought:
http://www.shapeoko.com/forum/viewtopic.php?f=10&t=2930&start=10#p22311
Hope this helps!
William
@Parkinbot
The trouble is the language sintax limitations. There is no way to define
something like
bb=boundingbox(sphere(20));
or
bb=boundingbox() cylinder(10,20);
Functions does not accept objects as parameters and modules doesn't return
any value. So a major language change is needed.
Ronaldo I am with you and you are right for the modules, but I am opting for
stl imports. It wouldn't be very difficult to implement
myStl = import("myDesign.stl");
with myStl denoting a list of triags respectively a list of list of
vertices. With this it is a one-liner to implement your own boundingbox:
function boundingbox(points) = let (x = [for (p = points) p[0]], y = [for
(p = points) p[1]], x = [for (p = points) p[2]]) [[min(x), min(y),
min(z)], [max(x), max(y), max(z)]];
Ronaldo wrote
@Parkinbot
The trouble is the language sintax limitations. There is no way to define
something like
bb=boundingbox(sphere(20));
or
bb=boundingbox() cylinder(10,20);
Functions does not accept objects as parameters and modules doesn't
return
any value. So a major language change is needed.
OpenSCAD mailing list
Discuss@.openscad
--
View this message in context: http://forum.openscad.org/rendering-for-paper-assembly-manual-tp20108p20123.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Parkinbot wrote
Ronaldo I am with you and you are right for the modules, but I am opting
for stl imports. It wouldn't be very difficult to implement
myStl = import("myDesign.stl");
I see your point now. An import stl function would not conflict with the
language syntax. And it would be a great value indeed.
I have consulted the Github/OpenSCAD forum and there is an issue on that
opened on Apr, 2015 https://github.com/openscad/openscad/issues/1324 .
The proposed syntax is not the same though:
my2Dobj=read("my2dmodel.dxf");
my3Dobj=read("my3dmodel.stl");
There was not much discussion about it and it seems to be forgotten.
Disappointing.
A second issue on the same idea, opened (and closed) on Feb, 2016, has
proposed your syntax which seems better to me.
--
View this message in context: http://forum.openscad.org/rendering-for-paper-assembly-manual-tp20108p20124.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Ronaldo,
I would like to give an example concerning the rendering of large number
unions, and present a technique I use for calculating lazy unions to speed
up this process. The implementation has some similarities with your sweep
interface - it stuffs everything into a single polyhedron call.
The Problem: We all know it can take hours to F6-render something like this:
http://forum.openscad.org/file/n20126/lazy.png
$fn = 30;
X = 800;
Y = 800;
for(x=[0:21:X], y=[0:21:Y])
translate([x, y])
cylinder(r=10,h=10, center = true);
cube([10, 10, 30], center = true); // final boolean operation
My machine takes about 33 min to F6-render this array. F5 is almost
instantly.
Now, let's look at the stony way. We sweep each of the cylinders and bypass
CGAL for the array union using some OpenSCAD function code that stuffs all
into a large polyhedron. With this approach F5 now takes some 12s, and F6
only 11s. This is a gain of factor 200 for F6 - just for being lazy.
As the cube intersects the first cylinder, we can't bypass CGAL and F6 takes
about 2 min.
In a large design I can visually analyze the situation using via F5 and find
out easily, which object groups need boolean operations and which can be
bypassed. After F6-rendering them one by one and generating STLs they could
be reimported for lazy unioning. Of course a lazy union primitive would do a
much better job, but I doubt, we will ever get one, because it is prone to
generate faulty output.
Here the code for the lazy union:
lazy_union.scad http://forum.openscad.org/file/n20126/lazy_union.scad
--
View this message in context: http://forum.openscad.org/rendering-for-paper-assembly-manual-tp20108p20126.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Of course a lazy union primitive would do a much better job, but I doubt,
we will ever get one, because it is prone to generate faulty output.
Why is it error prone?
If union determined two objects don't overlap it could bypass CGAL's union
and just merge the facet data. That would speed up cases like this.
Determining when objects overlap if their bounding boxes overlap could get
tricky but you could always default to CGAL in those cases.
I am surprised CGAL doesn't do this itself already. Seems like a low
hanging optimisation.
On 17 January 2017 at 02:06, Parkinbot rudolf@parkinbot.com wrote:
Ronaldo,
I would like to give an example concerning the rendering of large number
unions, and present a technique I use for calculating lazy unions to speed
up this process. The implementation has some similarities with your sweep
interface - it stuffs everything into a single polyhedron call.
The Problem: We all know it can take hours to F6-render something like
this:
http://forum.openscad.org/file/n20126/lazy.png
$fn = 30;
X = 800;
Y = 800;
for(x=[0:21:X], y=[0:21:Y])
translate([x, y])
cylinder(r=10,h=10, center = true);
cube([10, 10, 30], center = true); // final boolean operation
My machine takes about 33 min to F6-render this array. F5 is almost
instantly.
Now, let's look at the stony way. We sweep each of the cylinders and bypass
CGAL for the array union using some OpenSCAD function code that stuffs all
into a large polyhedron. With this approach F5 now takes some 12s, and F6
only 11s. This is a gain of factor 200 for F6 - just for being lazy.
As the cube intersects the first cylinder, we can't bypass CGAL and F6
takes
about 2 min.
In a large design I can visually analyze the situation using via F5 and
find
out easily, which object groups need boolean operations and which can be
bypassed. After F6-rendering them one by one and generating STLs they could
be reimported for lazy unioning. Of course a lazy union primitive would do
a
much better job, but I doubt, we will ever get one, because it is prone to
generate faulty output.
Here the code for the lazy union:
lazy_union.scad http://forum.openscad.org/file/n20126/lazy_union.scad
--
View this message in context: http://forum.openscad.org/
rendering-for-paper-assembly-manual-tp20108p20126.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
nophead wrote
Why is it error prone?
You are right, a lazy_union() could be implemented to do a boundingbox test
and offer the option to completely omit all tests, for kamikaze fighters
like me.
I have reported the huge potential
http://forum.openscad.org/No-bounding-box-test-for-union-before-entering-CGAL-tp17538.html
to speed up unions dramatically by conducting at least boundingbox tests to
bypass CGAL operation some time ago, with not much reaction, as it seems.
Indeed, I used this example to demonstrate part of the enormous potential of
an STL-import function, which would have much less impact on OpenSCAD code
compared to an optimization of Boolean operations of this scope. And even
getting an explicit /lazy-union()/ operation, which is much easier to
implement, will not do away with the "get hands on the point representation"
problem. An /import()/ function would and also open a broad range of paths
to tackle other problems, like lazy unions or distortion and morph
operations.
Beyond time, since the whole workflow is defined for linux being on Windows
it doesn't seem viable to me to branch out an own version and just implement
it.
--
View this message in context: http://forum.openscad.org/rendering-for-paper-assembly-manual-tp20108p20133.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
@Parkinbot.
I think I need a new computer: the render of your code with the cube took
almost 7min! But that is really fast for a model with 91260 vertices and
94302 facets.
I understand your point of what you call a lazy union. I have tried before
to produce one polyhedron with thousand spheres with such surprising
results. The way you have conceived your multiple sweep is similar to the
way I have been stitching my surface-bounded models. However, I usually does
not use this union inside polyhedron.
What it is weird to me (besides many other things, for sure) is that CGAL
accepts uncritically any polyhedron even with self-interceptions without a
warning. Only when we do a boolean operation it complains. Try this:
X = 100;
Y = 100;
// generate object array
dat2union = [for(x=[0:17:X], y=[0:17:Y]) sweep_(TF(x, y, Cyl()))];
Now the cylinders overlap but you will be able to render it without any
warning. And generate an STL file. Corrupted, of course.
Finally, I am surprised that you have embraced the new C-like for and got a
neat non-recursive version of what I call an accumulated sum function:
function acc_sum(l) =
[for(i=0, sum=0; i<len(l); sum=sum+l[i], i=i+1) sum];
</quote>
--
View this message in context: http://forum.openscad.org/rendering-for-paper-assembly-manual-tp20108p20134.html
Sent from the OpenSCAD mailing list archive at Nabble.com.