Functional OpenSCAD, working with vertex data

classic Classic list List threaded Threaded
58 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Functional OpenSCAD, working with vertex data

Parkinbot
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.z-r_]) sphere(r_);
      translate([r_, sz.y-r_, r_]) sphere(r_);
      translate([r_, sz.y-r_, sz.z-r_]) sphere(r_);
      translate([sz.x-r_, r_, r_]) sphere(r_);
      translate([sz.x-r_, r_, sz.z-r_]) sphere(r_);
      translate([sz.x-r_, sz.y-r_, r_]) sphere(r_);
      translate([sz.x-r_, sz.y-r_, sz.z-r_]) sphere(r_);
    }
  else
    cube(size);
}

in contrast the following call of hull will take minutes.

  hull()  
  for(x=[r_,size.x-r_], y=[r_,size.y-r_], z=[r_,size.z-r_])
    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
Reply | Threaded
Open this post in threaded view
|

Re: Functional OpenSCAD, working with vertex data

jon_bondy
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.z-r_]) sphere(r_);
>        translate([r_, sz.y-r_, r_]) sphere(r_);
>        translate([r_, sz.y-r_, sz.z-r_]) sphere(r_);
>        translate([sz.x-r_, r_, r_]) sphere(r_);
>        translate([sz.x-r_, r_, sz.z-r_]) sphere(r_);
>        translate([sz.x-r_, sz.y-r_, r_]) sphere(r_);
>        translate([sz.x-r_, sz.y-r_, sz.z-r_]) sphere(r_);
>      }
>    else
>      cube(size);
> }
>
> in contrast the following call of hull will take minutes.
>
>    hull()
>    for(x=[r_,size.x-r_], y=[r_,size.y-r_], z=[r_,size.z-r_])
>      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
Reply | Threaded
Open this post in threaded view
|

Re: Functional OpenSCAD, working with vertex data

Parkinbot
as I wrote, it avoids CGAL.



--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Functional OpenSCAD, working with vertex data

JordanBrown
In reply to this post by Parkinbot
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.z-r_]) sphere(r_); 
      translate([r_, sz.y-r_, r_]) sphere(r_); 
      translate([r_, sz.y-r_, sz.z-r_]) sphere(r_); 
      translate([sz.x-r_, r_, r_]) sphere(r_); 
      translate([sz.x-r_, r_, sz.z-r_]) sphere(r_); 
      translate([sz.x-r_, sz.y-r_, r_]) sphere(r_); 
      translate([sz.x-r_, sz.y-r_, sz.z-r_]) sphere(r_); 
    }
  else 
    cube(size); 
}

in contrast the following call of hull will take minutes. 

  hull()  
  for(x=[r_,size.x-r_], y=[r_,size.y-r_], z=[r_,size.z-r_])
    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
Reply | Threaded
Open this post in threaded view
|

Re: Functional OpenSCAD, working with vertex data

Parkinbot
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
Reply | Threaded
Open this post in threaded view
|

Re: Functional OpenSCAD, working with vertex data

jon_bondy
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
Reply | Threaded
Open this post in threaded view
|

Re: Functional OpenSCAD, working with vertex data

thehans
In reply to this post by Parkinbot
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 more-or-less 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.z-r_]) sphere(r_);
>       translate([r_, sz.y-r_, r_]) sphere(r_);
>       translate([r_, sz.y-r_, sz.z-r_]) sphere(r_);
>       translate([sz.x-r_, r_, r_]) sphere(r_);
>       translate([sz.x-r_, r_, sz.z-r_]) sphere(r_);
>       translate([sz.x-r_, sz.y-r_, r_]) sphere(r_);
>       translate([sz.x-r_, sz.y-r_, sz.z-r_]) sphere(r_);
>     }
>   else
>     cube(size);
> }
>
> in contrast the following call of hull will take minutes.
>
>   hull()
>   for(x=[r_,size.x-r_], y=[r_,size.y-r_], z=[r_,size.z-r_])
>     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
Reply | Threaded
Open this post in threaded view
|

Re: Functional OpenSCAD, working with vertex data

JordanBrown
In reply to this post by Parkinbot
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
Reply | Threaded
Open this post in threaded view
|

Re: Functional OpenSCAD, working with vertex data

thehans
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
Reply | Threaded
Open this post in threaded view
|

Re: Functional OpenSCAD, working with vertex data

Parkinbot
In reply to this post by thehans
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([r1-r1_, r1_]) circle(r1_);
        translate([r2-r2_, h-r2_]) circle(r2_);  
       polygon([[0,0], [r1-r1_, r1_], [r2-r2_, h-r2_], [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
Reply | Threaded
Open this post in threaded view
|

Re: Functional OpenSCAD, working with vertex data

Parkinbot
In reply to this post by thehans
 
thehans wrote
> 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?

This issue has also been discussed many times, in the context of
multithreading and also in the context with a lazy_union() operator.




--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Functional OpenSCAD, working with vertex data

Parkinbot
In reply to this post by Parkinbot
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
Reply | Threaded
Open this post in threaded view
|

Re: Functional OpenSCAD, working with vertex data

cacb
In reply to this post by JordanBrown
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
Reply | Threaded
Open this post in threaded view
|

Re: Functional OpenSCAD, working with vertex data

jon_bondy
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
Reply | Threaded
Open this post in threaded view
|

Re: Functional OpenSCAD, working with vertex data

thehans
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/350

On 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
Reply | Threaded
Open this post in threaded view
|

Re: Functional OpenSCAD, working with vertex data

atnbueno
In reply to this post by cacb
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, i5-4570S @ 2.90GHz and 32 GB of RAM


size=30;
radius=1;
$fn=60;
// 16s if $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);
}
}

// 26s if $fn=60
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)

2018-01-30 20:05 GMT+01:00 Carsten Arnholm <[hidden email]>:
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



--
Saludos,
Antonio



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Functional OpenSCAD, working with vertex data

cacb
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
Reply | Threaded
Open this post in threaded view
|

Re: Functional OpenSCAD, working with vertex data

thehans
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
Reply | Threaded
Open this post in threaded view
|

Re: Functional OpenSCAD, working with vertex data

NateTG
> Its basically just easier for CGAL to handle a bunch of smaller unions
than one big one.

If that's true, then can OpenSCAD get a performance improvement with divide
and conquer?





--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Functional OpenSCAD, working with vertex data

NateTG
In reply to this post by thehans
As an attempt to attack the problem of booleans, I wrote an octree voxelizer
- that would make the boolean operations trivial, but it seems too slow to
be viable.

octree.scad <http://forum.openscad.org/file/t2140/octree.scad>  



--
Sent from: http://forum.openscad.org/

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