discuss@lists.openscad.org

OpenSCAD general discussion Mailing-list

View all threads

rendering for paper assembly manual...

P
pierrepoulpe
Mon, Jan 16, 2017 3:28 PM

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

@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.
P
Parkinbot
Mon, Jan 16, 2017 3:48 PM

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.

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.
WA
William Adams
Mon, Jan 16, 2017 4:13 PM

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

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
RP
Ronaldo Persiano
Mon, Jan 16, 2017 4:49 PM

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

@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.
P
Parkinbot
Mon, Jan 16, 2017 5:56 PM

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.

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 > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org -- 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.
R
Ronaldo
Mon, Jan 16, 2017 7:01 PM

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.

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.
P
Parkinbot
Tue, Jan 17, 2017 2:06 AM

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.

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.
NH
nop head
Tue, Jan 17, 2017 9:35 AM

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

>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 >
P
Parkinbot
Tue, Jan 17, 2017 11:26 AM

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.

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.
R
Ronaldo
Tue, Jan 17, 2017 12:21 PM

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

@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]; &lt;/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.