
123

thehans wrote
> Here is a quick implementation of the rounded cube concept which I
> made as a module, since this version *does* still require one hull
> operation.
> https://gist.github.com/thehans/2c96601af4e5c8c2d232e50252dd37b1let me annote that hull() itself is not the problem. To avoid a time
consuming CGAL round trip, don't use (implicit) unions inside a hull(). If
you implement rounded_cube() more explicitely, rendering is fast (seconds).
$fa = 0.1;
$fs = 0.1;
rounded_cube_([4, 20, 5], r=1, center=[1,1,1]);
module rounded_cube_(size, r=0, center=false)
{
sz = size[0]==undef?[size, size, size]:size;
ce = center[0]==undef?[center, center, center]:center;
r_ = min(abs(r), abs(size.x/2), abs(size.y/2), abs(size.z/2)); // correct
r
translate([ce.x?sz.x/2:0,ce.y?sz.y/2:0, ce.z?sz.z/2:0])
if(r)
hull()
{
translate([r_, r_, r_]) sphere(r_);
translate([r_, r_, sz.zr_]) sphere(r_);
translate([r_, sz.yr_, r_]) sphere(r_);
translate([r_, sz.yr_, sz.zr_]) sphere(r_);
translate([sz.xr_, r_, r_]) sphere(r_);
translate([sz.xr_, r_, sz.zr_]) sphere(r_);
translate([sz.xr_, sz.yr_, r_]) sphere(r_);
translate([sz.xr_, sz.yr_, sz.zr_]) sphere(r_);
}
else
cube(size);
}
in contrast the following call of hull will take minutes.
hull()
for(x=[r_,size.xr_], y=[r_,size.yr_], z=[r_,size.zr_])
translate([x,y,z]) sphere(r_);
However, rounded_cube_ is currently a typical libary module. I wouldn't add
it to the core language unless cylinder(), linear_extrude() and maybe hull()
also get a r parameter.

Sent from: http://forum.openscad.org/_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


Sorry to be clueless, but why is it faster to enumerate the explicit
locations of the spheres vs having them in a loop?
Jon
On 1/30/2018 10:42 AM, Parkinbot wrote:
> thehans wrote
>> Here is a quick implementation of the rounded cube concept which I
>> made as a module, since this version *does* still require one hull
>> operation.
>> https://gist.github.com/thehans/2c96601af4e5c8c2d232e50252dd37b1> let me annote that hull() itself is not the problem. To avoid a time
> consuming CGAL round trip, don't use (implicit) unions inside a hull(). If
> you implement rounded_cube() more explicitely, rendering is fast (seconds).
>
> $fa = 0.1;
> $fs = 0.1;
> rounded_cube_([4, 20, 5], r=1, center=[1,1,1]);
>
> module rounded_cube_(size, r=0, center=false)
> {
> sz = size[0]==undef?[size, size, size]:size;
> ce = center[0]==undef?[center, center, center]:center;
> r_ = min(abs(r), abs(size.x/2), abs(size.y/2), abs(size.z/2)); // correct
> r
> translate([ce.x?sz.x/2:0,ce.y?sz.y/2:0, ce.z?sz.z/2:0])
> if(r)
> hull()
> {
> translate([r_, r_, r_]) sphere(r_);
> translate([r_, r_, sz.zr_]) sphere(r_);
> translate([r_, sz.yr_, r_]) sphere(r_);
> translate([r_, sz.yr_, sz.zr_]) sphere(r_);
> translate([sz.xr_, r_, r_]) sphere(r_);
> translate([sz.xr_, r_, sz.zr_]) sphere(r_);
> translate([sz.xr_, sz.yr_, r_]) sphere(r_);
> translate([sz.xr_, sz.yr_, sz.zr_]) sphere(r_);
> }
> else
> cube(size);
> }
>
> in contrast the following call of hull will take minutes.
>
> hull()
> for(x=[r_,size.xr_], y=[r_,size.yr_], z=[r_,size.zr_])
> translate([x,y,z]) sphere(r_);
>
> However, rounded_cube_ is currently a typical libary module. I wouldn't add
> it to the core language unless cylinder(), linear_extrude() and maybe hull()
> also get a r parameter.
>
>
>
>
>
> 
> Sent from: http://forum.openscad.org/>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org>
>

Sent from my desktop computer.
I do not receive emails while away from my desk,
nor do I receive texts on my main phone number
(which is a land line).
If you know that I am on the road, please text me.
If you know that I am home, please email me.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


On 1/30/2018 7:42 AM, Parkinbot wrote:
let me annote that
hull() itself is not the problem. To avoid a time consuming CGAL
round trip, don't use (implicit) unions inside a hull(). If you
implement rounded_cube() more explicitely, rendering is fast
(seconds).
So you're saying it's better if the objects are simple and direct
children of the hull, rather than being a union (through whatever
mechanism) of those same objects?
$fa = 0.1;
$fs = 0.1;
rounded_cube_([4, 20, 5], r=1, center=[1,1,1]);
module rounded_cube_(size, r=0, center=false)
{
sz = size[0]==undef?[size, size, size]:size;
ce = center[0]==undef?[center, center, center]:center;
r_ = min(abs(r), abs(size.x/2), abs(size.y/2), abs(size.z/2)); // correct
r
translate([ce.x?sz.x/2:0,ce.y?sz.y/2:0, ce.z?sz.z/2:0])
if(r)
hull()
{
translate([r_, r_, r_]) sphere(r_);
translate([r_, r_, sz.zr_]) sphere(r_);
translate([r_, sz.yr_, r_]) sphere(r_);
translate([r_, sz.yr_, sz.zr_]) sphere(r_);
translate([sz.xr_, r_, r_]) sphere(r_);
translate([sz.xr_, r_, sz.zr_]) sphere(r_);
translate([sz.xr_, sz.yr_, r_]) sphere(r_);
translate([sz.xr_, sz.yr_, sz.zr_]) sphere(r_);
}
else
cube(size);
}
in contrast the following call of hull will take minutes.
hull()
for(x=[r_,size.xr_], y=[r_,size.yr_], z=[r_,size.zr_])
translate([x,y,z]) sphere(r_);
However, rounded_cube_ is currently a typical libary module. I wouldn't add
it to the core language unless cylinder(), linear_extrude() and maybe hull()
also get a r parameter.

Sent from: http://forum.openscad.org/
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


JordanBrown wrote
> So you're saying it's better if the objects are simple and direct
> children of the hull, rather than being a union (through whatever
> mechanism) of those same objects?
Exactly. Have a look at the CSG structures. Results of a for loop are
represented as group node and processed as (implicit) union. And this needs
to be done by CGAL.

Sent from: http://forum.openscad.org/_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


Thank you Parkinbot!
This is an excellent example of how a user new to OpenSCAD could spin
their wheels "needlessly". I know nothing about the internals of
OpenSCAD. I imagine that most C programmers do not wish to have to
understand the details of the parser or the code generator. I hope that
we can eventually have a tool where two seemingly identical structures
take roughly the same time to calculate. I imagine there are good (and
subtle) reasons why this objective is difficult to achieve
Jon
On 1/30/2018 11:41 AM, Parkinbot wrote:
> JordanBrown wrote
>> So you're saying it's better if the objects are simple and direct
>> children of the hull, rather than being a union (through whatever
>> mechanism) of those same objects?
> Exactly. Have a look at the CSG structures. Results of a for loop are
> represented as group node and processed as (implicit) union. And this needs
> to be done by CGAL.
>
>
>
>
> 
> Sent from: http://forum.openscad.org/>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org>
>

Sent from my desktop computer.
I do not receive emails while away from my desk,
nor do I receive texts on my main phone number
(which is a land line).
If you know that I am on the road, please text me.
If you know that I am home, please email me.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


Oh, wow. I guess I had always assumed that hull was a CGAL operation.
You say this belongs in a library, but is there a single library that
has a properly implemented rounded cube? Everyone's implementation is
different and 99.9% of them are slow and/or poduce ugly geometry.
This is why It should be standardized from the source.
I guess what I'm saying is at the very least MCAD should get updated
with an efficient module like you wrote here, because I think its
currently using what is moreorless the same implementation as that
example006.scad I mentioned.
Also I should just say that my attention was originally drawn to
example006.scad a while ago when I was looking at improving OpenSCAD's
Travis build times, particularly in the execution time of individual
tests. And example006.scad was one of the longest running tests.
Hans
On Tue, Jan 30, 2018 at 9:42 AM, Parkinbot < [hidden email]> wrote:
> thehans wrote
>> Here is a quick implementation of the rounded cube concept which I
>> made as a module, since this version *does* still require one hull
>> operation.
>> https://gist.github.com/thehans/2c96601af4e5c8c2d232e50252dd37b1>
> let me annote that hull() itself is not the problem. To avoid a time
> consuming CGAL round trip, don't use (implicit) unions inside a hull(). If
> you implement rounded_cube() more explicitely, rendering is fast (seconds).
>
> $fa = 0.1;
> $fs = 0.1;
> rounded_cube_([4, 20, 5], r=1, center=[1,1,1]);
>
> module rounded_cube_(size, r=0, center=false)
> {
> sz = size[0]==undef?[size, size, size]:size;
> ce = center[0]==undef?[center, center, center]:center;
> r_ = min(abs(r), abs(size.x/2), abs(size.y/2), abs(size.z/2)); // correct
> r
> translate([ce.x?sz.x/2:0,ce.y?sz.y/2:0, ce.z?sz.z/2:0])
> if(r)
> hull()
> {
> translate([r_, r_, r_]) sphere(r_);
> translate([r_, r_, sz.zr_]) sphere(r_);
> translate([r_, sz.yr_, r_]) sphere(r_);
> translate([r_, sz.yr_, sz.zr_]) sphere(r_);
> translate([sz.xr_, r_, r_]) sphere(r_);
> translate([sz.xr_, r_, sz.zr_]) sphere(r_);
> translate([sz.xr_, sz.yr_, r_]) sphere(r_);
> translate([sz.xr_, sz.yr_, sz.zr_]) sphere(r_);
> }
> else
> cube(size);
> }
>
> in contrast the following call of hull will take minutes.
>
> hull()
> for(x=[r_,size.xr_], y=[r_,size.yr_], z=[r_,size.zr_])
> translate([x,y,z]) sphere(r_);
>
> However, rounded_cube_ is currently a typical libary module. I wouldn't add
> it to the core language unless cylinder(), linear_extrude() and maybe hull()
> also get a r parameter.
>
>
>
>
>
> 
> Sent from: http://forum.openscad.org/>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


On 1/30/2018 8:41 AM, Parkinbot wrote:
JordanBrown wrote
So you're saying it's better if the objects are simple and direct
children of the hull, rather than being a union (through whatever
mechanism) of those same objects?
Exactly. Have a look at the CSG structures. Results of a for loop are
represented as group node and processed as (implicit) union. And this needs
to be done by CGAL.
Not knowing how hull( ) works, I wouldn't have expected there to be
a difference.
Good information, thanks.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


I wonder if we could alleviate most of the slowdown of implicit union
by having group nodes do a simple bounding box check before passing to
CGAL, if no bounding boxes overlap then just skip it?
On Tue, Jan 30, 2018 at 10:49 AM, Jordan Brown
< [hidden email]> wrote:
> On 1/30/2018 8:41 AM, Parkinbot wrote:
>
> JordanBrown wrote
>
> So you're saying it's better if the objects are simple and direct
> children of the hull, rather than being a union (through whatever
> mechanism) of those same objects?
>
> Exactly. Have a look at the CSG structures. Results of a for loop are
> represented as group node and processed as (implicit) union. And this needs
> to be done by CGAL.
>
>
> Not knowing how hull( ) works, I wouldn't have expected there to be a
> difference.
>
> Good information, thanks.
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org>
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


thehans wrote
> You say this belongs in a library, but is there a single library that
> has a properly implemented rounded cube? Everyone's implementation is
> different and 99.9% of them are slow and/or poduce ugly geometry.
> This is why It should be standardized from the source.
Well I prefer libraries, which I write on my own, because they let me define
my own parameters and defaults and I can refer to the implementation. I
never understood why cube(), cylinder() and linear_extrude() are not
centered by default. And to be honest, I still don't know which prototypes
and defaults they exactly have. OK, this could be fixed by a proper
documentation ...
We have discussed it before several times that OpenSCAD is missing a
(standard) library concept. Have a look at the libraries folder shipped with
OpenSCAD and you will discover pretty old stuff that hasn't been maintained
for years.
See my implementation of a rounded_cylinder() and how it deals with
conflicts between diameters and radii. It is pretty fast, but I have no way
to figure out, whether it is semantically equivalent with cylinder,
therefore I can't call cylinder() with all its parameters in case r_ is 0.
$fa=.2;
$fs=.2;
CyR(r1=1, r2=6, h=7, r_=1.4, center = false);
//CyR(h=12, r_=1, r1=6, d2=1);
module CyR(r = 10, h=10, r_=1, d = undef, r1=undef, r2=undef, d1 = undef, d2
= undef, center=false)
{
r1 = r1==undef?d1==undef?d==undef?r:d/2:d1/2:r1;
r2 = r2==undef?d2==undef?d==undef?r:d/2:d2/2:r2;
r1_=min(abs(h/4), abs(r1), abs(r_));
r2_=min(abs(h/4), abs(r2), abs(r_));
echo(r1, r2, r1_, r2_);
h=abs(h);
translate([0,0,(center?h/2:0)])
rotate_extrude()
intersection()
{
hull()
{
translate([r1r1_, r1_]) circle(r1_);
translate([r2r2_, hr2_]) circle(r2_);
polygon([[0,0], [r1r1_, r1_], [r2r2_, hr2_], [0,h]] );
}
square([max(r1,r2), h]);
}
}

Sent from: http://forum.openscad.org/_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


Parkinbot wrote
>
> See my implementation of a rounded_cylinder() and how it deals with
> conflicts between diameters and radii. It is pretty fast, but I have no
> way
> to figure out, whether it is semantically equivalent with cylinder,
> therefore I can't call cylinder() with all its parameters in case r_ is 0.
Sorry, here is my latest implementation:
$fa=.2;
$fs=.2;
module CyR(r = 10, h=10, r_=1, d = undef, r1=undef, r2=undef, d1 = undef, d2
= undef, center=false)
{
r1 = r1==undef?d1==undef?d==undef?r:d/2:d1/2:r1;
r2 = r2==undef?d2==undef?d==undef?r:d/2:d2/2:r2;
r_=min(abs(h/4), abs(r1), abs(r2), abs(r_));
h=abs(h);
translate([0,0,center?h/2:0])
rotate_extrude()
intersection()
{
offset(r_)offset(r_) polygon([[2*r_,0], [r1, 0], [r2, h], [0,h],
[2*r_,h]] );
square(max(r1,r2), h);
}
}

Sent from: http://forum.openscad.org/_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


On 30. jan. 2018 17:49, Jordan Brown wrote:
> Not knowing how hull( ) works, I wouldn't have expected there to be a
> difference.
>
> Good information, thanks.
The problem is not hull(), but implicit union. Hull only needs the
points in the input mesh(es). Applying [implicit] union() before
applying hull() to the result is like unknowingly driving with the hand
brake engaged. You perform a potentially costly computation (union())
only to immediately throw away the result.
One idea would be to provide an option to switch off implicit union, and
such issues will go away.
Carsten Arnholm
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


I would welcome a switch that turned off implicit union, if the result
was better performance. I understand that I would need to alter my
source code, and that I might need to modify library source code.
Jon
On 1/30/2018 2:05 PM, Carsten Arnholm wrote:
> On 30. jan. 2018 17:49, Jordan Brown wrote:
>> Not knowing how hull( ) works, I wouldn't have expected there to be a
>> difference.
>>
>> Good information, thanks.
>
> The problem is not hull(), but implicit union. Hull only needs the
> points in the input mesh(es). Applying [implicit] union() before
> applying hull() to the result is like unknowingly driving with the
> hand brake engaged. You perform a potentially costly computation
> (union()) only to immediately throw away the result.
>
> One idea would be to provide an option to switch off implicit union,
> and such issues will go away.
>
> Carsten Arnholm
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org>
>

Sent from my desktop computer.
I do not receive emails while away from my desk,
nor do I receive texts on my main phone number
(which is a land line).
If you know that I am on the road, please text me.
If you know that I am home, please email me.
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


By the way, here is a relevant issue that looks like had a lot of work
done towards it but never completely finalized.
Lazy union (aka. no implicit union):
https://github.com/openscad/openscad/issues/350On Tue, Jan 30, 2018 at 1:25 PM, jon < [hidden email]> wrote:
> I would welcome a switch that turned off implicit union, if the result was
> better performance. I understand that I would need to alter my source code,
> and that I might need to modify library source code.
>
> Jon
>
>
>
> On 1/30/2018 2:05 PM, Carsten Arnholm wrote:
>>
>> On 30. jan. 2018 17:49, Jordan Brown wrote:
>>>
>>> Not knowing how hull( ) works, I wouldn't have expected there to be a
>>> difference.
>>>
>>> Good information, thanks.
>>
>>
>> The problem is not hull(), but implicit union. Hull only needs the points
>> in the input mesh(es). Applying [implicit] union() before applying hull() to
>> the result is like unknowingly driving with the hand brake engaged. You
>> perform a potentially costly computation (union()) only to immediately throw
>> away the result.
>>
>> One idea would be to provide an option to switch off implicit union, and
>> such issues will go away.
>>
>> Carsten Arnholm
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> [hidden email]
>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org>>
>>
>
> 
> Sent from my desktop computer.
> I do not receive emails while away from my desk,
> nor do I receive texts on my main phone number
> (which is a land line).
> If you know that I am on the road, please text me.
> If you know that I am home, please email me.
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


Any insight in why the first
hull() (the one with explicit
union()) is faster (16s*) than the second one (26s)?
(*) These times are with version 2018.01.06, Windows 10 x64, i54570S @ 2.90GHz and 32 GB of RAM
size=30; radius=1; $fn=60; hull() { union() translate([size/2, size/2]) { translate([0, 0, size/2]) sphere(radius); translate([0, 0, size/2]) sphere(radius); cylinder(radius, h=size, center=true); } rotate(90) union() translate([size/2, size/2]) { translate([0, 0, size/2]) sphere(radius); translate([0, 0, size/2]) sphere(radius); cylinder(radius, h=size, center=true); } rotate(180) union() translate([size/2, size/2]) { translate([0, 0, size/2]) sphere(radius); translate([0, 0, size/2]) sphere(radius); cylinder(radius, h=size, center=true); } rotate(270) union() translate([size/2, size/2]) { translate([0, 0, size/2]) sphere(radius); translate([0, 0, size/2]) sphere(radius); cylinder(radius, h=size, center=true); } }
hull() { translate([size/2, size/2]) { translate([0, 0, size/2]) sphere(radius); translate([0, 0, size/2]) sphere(radius); cylinder(radius, h=size, center=true); } rotate(90) translate([size/2, size/2]) { translate([0, 0, size/2]) sphere(radius); translate([0, 0, size/2]) sphere(radius); cylinder(radius, h=size, center=true); } rotate(180) translate([size/2, size/2]) { translate([0, 0, size/2]) sphere(radius); translate([0, 0, size/2]) sphere(radius); cylinder(radius, h=size, center=true); } rotate(270) translate([size/2, size/2]) { translate([0, 0, size/2]) sphere(radius); translate([0, 0, size/2]) sphere(radius); cylinder(radius, h=size, center=true); } }
(I know there are faster methods to do that, but they are a couple of samples from an speed test I did some time ago and illustrate well my doubt)
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


On 30. jan. 2018 20:35, Antonio Bueno wrote:
> Any insight in why the first hull() (the one with explicit union()) is
> faster (16s*) than the second one (26s)?
Implicit or explicit union takes time. You are doing both in this case.
Why not simplify. Shorter, easier code. And faster.
size=30;
radius=1;
$fn=60;
hull() {
translate([size/2, size/2, size/2]) sphere(radius);
translate([+size/2, size/2, size/2]) sphere(radius);
translate([+size/2, +size/2, size/2]) sphere(radius);
translate([size/2, +size/2, size/2]) sphere(radius);
translate([size/2, size/2, +size/2]) sphere(radius);
translate([+size/2, size/2, +size/2]) sphere(radius);
translate([+size/2, +size/2, +size/2]) sphere(radius);
translate([size/2, +size/2, +size/2]) sphere(radius);
}
Carsten Arnholm
_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


Its basically just easier for CGAL to handle a bunch of smaller unions
than one big one.
On Tue, Jan 30, 2018 at 2:07 PM, Carsten Arnholm < [hidden email]> wrote:
> On 30. jan. 2018 20:35, Antonio Bueno wrote:
>>
>> Any insight in why the first hull() (the one with explicit union()) is
>> faster (16s*) than the second one (26s)?
>
>
> Implicit or explicit union takes time. You are doing both in this case.
>
> Why not simplify. Shorter, easier code. And faster.
>
> size=30;
> radius=1;
> $fn=60;
> hull() {
> translate([size/2, size/2, size/2]) sphere(radius);
> translate([+size/2, size/2, size/2]) sphere(radius);
> translate([+size/2, +size/2, size/2]) sphere(radius);
> translate([size/2, +size/2, size/2]) sphere(radius);
>
> translate([size/2, size/2, +size/2]) sphere(radius);
> translate([+size/2, size/2, +size/2]) sphere(radius);
> translate([+size/2, +size/2, +size/2]) sphere(radius);
> translate([size/2, +size/2, +size/2]) sphere(radius);
>
> }
>
> Carsten Arnholm
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

123
