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 |
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 |
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 |
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 |
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 |
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 |
In reply to this post by Parkinbot
On 1/30/2018 8:41 AM, Parkinbot wrote:
JordanBrown wroteSo 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 |
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 |
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 |
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 |
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 |
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/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 |
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); } } 2018-01-30 20:05 GMT+01:00 Carsten Arnholm <[hidden email]>: On 30. jan. 2018 17:49, Jordan Brown wrote: Saludos,
Antonio _______________________________________________ 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 |
> 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 |
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 |
Free forum by Nabble | Edit this page |