P
pproj@posteo.de
Thu, Oct 6, 2016 7:55 PM
hello after few years of work on my quite complex cad project, which i
created using openscad .(my love to openscad was hampered by quite few a
limittions for a compex project- but i am still working with it)
anyway,
i have decided it is time to share with others some of the things i have
discovered and developed in the years of use.
i will start with the sumUp(). which is an advanced replacement for the
difference() keyword and allows for holes inside modules, and reduced
nesting producing simpler code among other things.
i have put it it under:
https://github.com/solidboredom/sumUp
but to show you why i have been using it so much: it can produce this
example. the code below and the lib is all you need
:
include<sumup.scad>
sumUp()
{
add()
cube([20,20,7],center=true);
lidWithNailsAndWasher();
}
//== modules below ==
module lidWithNailsAndWasher()
{
add()//washer
translate([0,0,8])
cube([20,20,1],center=true);
addAfterRemoving()//top cover without holes
translate([0,0,11])
color("green")
cube([17,17,2],center=true);
for(x=[-1,1],y=[-1,1])
translate([x7,y7,2])
{
remove()
cylinder(h=25,d=4.5,center=true);
#addAfterRemoving()
cylinder(h=10,d2=3,d1=1);
}
}
i have been quite happy with thhe library (actually its predecessor) so
i hope you will find it useful too.
i have been using it so much i would like to have its approach somehow
integrated in openscad itself.
this perhaps could resolve its main drawback: speed on complex models:
openscad creates a lot groups and getting much slower on complex models
than with the difference().
i would also like to share another library: essentially a human(not
linear algebra robot) oriented syntax rewrite library for basic openscad
operations i use a lot, but still need to make it ready for publishing
and documented first.
so whats your take folks?
Peter
hello after few years of work on my quite complex cad project, which i
created using openscad .(my love to openscad was hampered by quite few a
limittions for a compex project- but i am still working with it)
anyway,
i have decided it is time to share with others some of the things i have
discovered and developed in the years of use.
i will start with the sumUp(). which is an advanced replacement for the
difference() keyword and allows for holes inside modules, and reduced
nesting producing simpler code among other things.
i have put it it under:
https://github.com/solidboredom/sumUp
but to show you why i have been using it so much: it can produce this
example. the code below and the lib is all you need
:
include<sumup.scad>
sumUp()
{
add()
cube([20,20,7],center=true);
lidWithNailsAndWasher();
}
//== modules below ==
module lidWithNailsAndWasher()
{
add()//washer
translate([0,0,8])
cube([20,20,1],center=true);
addAfterRemoving()//top cover without holes
translate([0,0,11])
color("green")
cube([17,17,2],center=true);
for(x=[-1,1],y=[-1,1])
translate([x*7,y*7,2])
{
remove()
cylinder(h=25,d=4.5,center=true);
#addAfterRemoving()
cylinder(h=10,d2=3,d1=1);
}
}
i have been quite happy with thhe library (actually its predecessor) so
i hope you will find it useful too.
i have been using it so much i would like to have its approach somehow
integrated in openscad itself.
this perhaps could resolve its main drawback: speed on complex models:
openscad creates a lot groups and getting much slower on complex models
than with the difference().
i would also like to share another library: essentially a human(not
linear algebra robot) oriented syntax rewrite library for basic openscad
operations i use a lot, but still need to make it ready for publishing
and documented first.
so whats your take folks?
Peter
RP
Ronaldo Persiano
Thu, Oct 6, 2016 9:45 PM
Interesting approach. I don't have any reason to question your statement
that sumUp() could favor modelling complex projects. I have no experience
on that and have to give it a try. But I don't understand why you say it is
faster. Ultimately, sumUp will perform the same boolean operations. I
compared the CSG tree your code generated with the CSG tree generated for a
code I wrote to produce the same model using directly the boolean
operations. The CSG tree of sumUp is a lot bigger than the later. The
preview time of sumUp was a bit bigger.
2016-10-06 16:55 GMT-03:00 pproj@posteo.de pproj@posteo.de:
hello after few years of work on my quite complex cad project, which i
created using openscad .(my love to openscad was hampered by quite few a
limittions for a compex project- but i am still working with it)
anyway,
i have decided it is time to share with others some of the things i have
discovered and developed in the years of use.
i will start with the sumUp(). which is an advanced replacement for the
difference() keyword and allows for holes inside modules, and reduced
nesting producing simpler code among other things.
i have put it it under:
https://github.com/solidboredom/sumUp
but to show you why i have been using it so much: it can produce this
example. the code below and the lib is all you need
:
include<sumup.scad>
sumUp()
{
add()
cube([20,20,7],center=true);
lidWithNailsAndWasher();
}
//== modules below ==
module lidWithNailsAndWasher()
{
add() //washer
translate([0,0,8])
cube([20,20,1],center=true);
addAfterRemoving() //top cover without holes
translate([0,0,11])
color("green")
cube([17,17,2],center=true);for(x=[-1,1],y=[-1,1])
translate([x7,y7,2])
{
remove()
cylinder(h=25,d=4.5,center=true);
#addAfterRemoving()
cylinder(h=10,d2=3,d1=1);
}
}
i have been quite happy with thhe library (actually its predecessor) so i
hope you will find it useful too.
i have been using it so much i would like to have its approach somehow
integrated in openscad itself.
this perhaps could resolve its main drawback: speed on complex models:
openscad creates a lot groups and getting much slower on complex models
than with the difference().
i would also like to share another library: essentially a human(not linear
algebra robot) oriented syntax rewrite library for basic openscad
operations i use a lot, but still need to make it ready for publishing and
documented first.
so whats your take folks?
Peter
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Interesting approach. I don't have any reason to question your statement
that sumUp() could favor modelling complex projects. I have no experience
on that and have to give it a try. But I don't understand why you say it is
faster. Ultimately, sumUp will perform the same boolean operations. I
compared the CSG tree your code generated with the CSG tree generated for a
code I wrote to produce the same model using directly the boolean
operations. The CSG tree of sumUp is a lot bigger than the later. The
preview time of sumUp was a bit bigger.
2016-10-06 16:55 GMT-03:00 pproj@posteo.de <pproj@posteo.de>:
> hello after few years of work on my quite complex cad project, which i
> created using openscad .(my love to openscad was hampered by quite few a
> limittions for a compex project- but i am still working with it)
> anyway,
> i have decided it is time to share with others some of the things i have
> discovered and developed in the years of use.
>
> i will start with the sumUp(). which is an advanced replacement for the
> difference() keyword and allows for holes inside modules, and reduced
> nesting producing simpler code among other things.
> i have put it it under:
> https://github.com/solidboredom/sumUp
> but to show you why i have been using it so much: it can produce this
> example. the code below and the lib is all you need
> :
>
> include<sumup.scad>
>
> sumUp()
> {
> add()
> cube([20,20,7],center=true);
> lidWithNailsAndWasher();
> }
> //== modules below ==
> module lidWithNailsAndWasher()
> {
> add() //washer
> translate([0,0,8])
> cube([20,20,1],center=true);
> addAfterRemoving() //top cover without holes
> translate([0,0,11])
> color("green")
> cube([17,17,2],center=true);for(x=[-1,1],y=[-1,1])
> translate([x*7,y*7,2])
> {
> remove()
> cylinder(h=25,d=4.5,center=true);
> #addAfterRemoving()
> cylinder(h=10,d2=3,d1=1);
> }
> }
>
>
> i have been quite happy with thhe library (actually its predecessor) so i
> hope you will find it useful too.
> i have been using it so much i would like to have its approach somehow
> integrated in openscad itself.
> this perhaps could resolve its main drawback: speed on complex models:
> openscad creates a lot groups and getting much slower on complex models
> than with the difference().
>
> i would also like to share another library: essentially a human(not linear
> algebra robot) oriented syntax rewrite library for basic openscad
> operations i use a lot, but still need to make it ready for publishing and
> documented first.
> so whats your take folks?
> Peter
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>
P
pproj
Thu, Oct 6, 2016 10:13 PM
hmm.. there must be a misunderstanding.
i have stated that sumUp() is slower than difference() in complex
projects (thats its main drawback) and asked if it can be hardcoded to
make it faster...
i think we are of the same opinion on that. i believe the cleanliness of
code, reduction of nesting and thus redundancy by far outweigh the very
unpleasant fact that i have to wait for several minutes for a complex
model to render, and this would have been times faster with the messier
difference()-using code
On 06.10.2016 23:45, Ronaldo Persiano wrote:
Interesting approach. I don't have any reason to question your
statement that sumUp() could favor modelling complex projects. I have
no experience on that and have to give it a try. But I don't
understand why you say it is faster. Ultimately, sumUp will perform
the same boolean operations. I compared the CSG tree your code
generated with the CSG tree generated for a code I wrote to produce
the same model using directly the boolean operations. The CSG tree of
sumUp is a lot bigger than the later. The preview time of sumUp was a
bit bigger.
2016-10-06 16:55 GMT-03:00 pproj@posteo.de pproj@posteo.de:
hello after few years of work on my quite complex cad project,
which i created using openscad .(my love to openscad was hampered by
quite few a limittions for a compex project- but i am still working
with it)
anyway,
i have decided it is time to share with others some of the things i
have discovered and developed in the years of use.
i will start with the sumUp(). which is an advanced replacement for
the difference() keyword and allows for holes inside modules, and
reduced nesting producing simpler code among other things.
i have put it it under:
https://github.com/solidboredom/sumUp [1]
but to show you why i have been using it so much: it can produce
this example. the code below and the lib is all you need
:
include<sumup.scad>
sumUp()
{
add()
cube([20,20,7],center=true);
lidWithNailsAndWasher();
}
//== modules below ==
module lidWithNailsAndWasher()
{
add() //washer
translate([0,0,8])
cube([20,20,1],center=true);
addAfterRemoving() //top cover without holes
translate([0,0,11])
color("green")
cube([17,17,2],center=true);
for(x=[-1,1],y=[-1,1])
translate([x7,y7,2])
{
remove()
cylinder(h=25,d=4.5,center=true);
#addAfterRemoving()
cylinder(h=10,d2=3,d1=1);
}
}
i have been quite happy with thhe library (actually its
predecessor) so i hope you will find it useful too.
i have been using it so much i would like to have its approach
somehow integrated in openscad itself.
this perhaps could resolve its main drawback: speed on complex
models: openscad creates a lot groups and getting much slower on
complex models than with the difference().
i would also like to share another library: essentially a human(not
linear algebra robot) oriented syntax rewrite library for basic
openscad operations i use a lot, but still need to make it ready for
publishing and documented first.
so whats your take folks?
Peter
OpenSCAD mailing list
Discuss@lists.openscad.org
hmm.. there must be a misunderstanding.
i have stated that sumUp() is slower than difference() in complex
projects (thats its main drawback) and asked if it can be hardcoded to
make it faster...
i think we are of the same opinion on that. i believe the cleanliness of
code, reduction of nesting and thus redundancy by far outweigh the very
unpleasant fact that i have to wait for several minutes for a complex
model to render, and this would have been times faster with the messier
difference()-using code
On 06.10.2016 23:45, Ronaldo Persiano wrote:
> Interesting approach. I don't have any reason to question your
> statement that sumUp() could favor modelling complex projects. I have
> no experience on that and have to give it a try. But I don't
> understand why you say it is faster. Ultimately, sumUp will perform
> the same boolean operations. I compared the CSG tree your code
> generated with the CSG tree generated for a code I wrote to produce
> the same model using directly the boolean operations. The CSG tree of
> sumUp is a lot bigger than the later. The preview time of sumUp was a
> bit bigger.
>
> 2016-10-06 16:55 GMT-03:00 pproj@posteo.de <pproj@posteo.de>:
>
>> hello after few years of work on my quite complex cad project,
>> which i created using openscad .(my love to openscad was hampered by
>> quite few a limittions for a compex project- but i am still working
>> with it)
>> anyway,
>> i have decided it is time to share with others some of the things i
>> have discovered and developed in the years of use.
>>
>> i will start with the sumUp(). which is an advanced replacement for
>> the difference() keyword and allows for holes inside modules, and
>> reduced nesting producing simpler code among other things.
>> i have put it it under:
>> https://github.com/solidboredom/sumUp [1]
>> but to show you why i have been using it so much: it can produce
>> this example. the code below and the lib is all you need
>> :
>>
>> include<sumup.scad>
>>
>> sumUp()
>> {
>> add()
>> cube([20,20,7],center=true);
>> lidWithNailsAndWasher();
>> }
>>
>> //== modules below ==
>> module lidWithNailsAndWasher()
>> {
>> add() //washer
>> translate([0,0,8])
>> cube([20,20,1],center=true);
>> addAfterRemoving() //top cover without holes
>> translate([0,0,11])
>> color("green")
>> cube([17,17,2],center=true);
>> for(x=[-1,1],y=[-1,1])
>> translate([x*7,y*7,2])
>> {
>> remove()
>> cylinder(h=25,d=4.5,center=true);
>> #addAfterRemoving()
>> cylinder(h=10,d2=3,d1=1);
>> }
>> }
>>
>> i have been quite happy with thhe library (actually its
>> predecessor) so i hope you will find it useful too.
>> i have been using it so much i would like to have its approach
>> somehow integrated in openscad itself.
>> this perhaps could resolve its main drawback: speed on complex
>> models: openscad creates a lot groups and getting much slower on
>> complex models than with the difference().
>>
>> i would also like to share another library: essentially a human(not
>> linear algebra robot) oriented syntax rewrite library for basic
>> openscad operations i use a lot, but still need to make it ready for
>> publishing and documented first.
>> so whats your take folks?
>> Peter
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> Discuss@lists.openscad.org
>>
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>> [2]
>
>
>
> Links:
> ------
> [1] https://github.com/solidboredom/sumUp
> [2]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
RP
Ronaldo Persiano
Thu, Oct 6, 2016 10:34 PM
I am sorry. You are right. I misunderstood your statement.
From one point of view, it is interesting that it is possible to add() and
remove() parts in any order inside sumUp(). But this may also make codes
harder to understand. I cannot judge it without trying it anyway.
Although I have not fully grasped the technique you developed I guess it
may be helpful in other contexts.
2016-10-06 19:13 GMT-03:00 pproj pproj@posteo.de:
hmm.. there must be a misunderstanding.
i have stated that sumUp() is slower than difference() in complex
projects (thats its main drawback) and asked if it can be hardcoded to make
it faster...
i think we are of the same opinion on that. i believe the cleanliness of
code, reduction of nesting and thus redundancy by far outweigh the very
unpleasant fact that i have to wait for several minutes for a complex model
to render, and this would have been times faster with the messier
difference()-using code
I am sorry. You are right. I misunderstood your statement.
>From one point of view, it is interesting that it is possible to add() and
remove() parts in any order inside sumUp(). But this may also make codes
harder to understand. I cannot judge it without trying it anyway.
Although I have not fully grasped the technique you developed I guess it
may be helpful in other contexts.
2016-10-06 19:13 GMT-03:00 pproj <pproj@posteo.de>:
> hmm.. there must be a misunderstanding.
> i have stated that sumUp() is slower than difference() in complex
> projects (thats its main drawback) and asked if it can be hardcoded to make
> it faster...
> i think we are of the same opinion on that. i believe the cleanliness of
> code, reduction of nesting and thus redundancy by far outweigh the very
> unpleasant fact that i have to wait for several minutes for a complex model
> to render, and this would have been times faster with the messier
> difference()-using code
>
>
>
DB
don bright
Fri, Oct 7, 2016 12:34 AM
That is very cool, seems a little bit like using "negative objects" and
"positive objects".
--
don bright
hmbright@fastmail.com
On Thu, Oct 6, 2016, at 02:55 PM, pproj@posteo.de wrote:
hello after few years of work on my quite complex cad project, which
i created using openscad .(my love to openscad was hampered by quite
few a limittions for a compex project- but i am still working with it)
anyway,
i have decided it is time to share with others some of the things i
have discovered and developed in the years of use.
i will start with the sumUp(). which is an advanced replacement for
the difference() keyword and allows for holes inside modules, and
reduced nesting producing simpler code among other things.
i have put it it under:
https://github.com/solidboredom/sumUp
but to show you why i have been using it so much: it can produce this
example. the code below and the lib is all you need
:
include<sumup.scad> sumUp() { add() cube([20,20,7],center=true);
lidWithNailsAndWasher(); }
//== modules below == module lidWithNailsAndWasher() { add()
//washer translate([,,8]) cube([20,20,1],center=true);
addAfterRemoving() //top cover without holes translate([,,11])
color("green") cube([17,17,2],center=true); for(x=[-1,1],y=[-1,1])
translate([x7,y7,2]) { remove() cylinder(h=25,d=4.5,center=true);
#addAfterRemoving() cylinder(h=10,d2=3,d1=1); } }
i have been quite happy with thhe library (actually its predecessor)
so i hope you will find it useful too.
i have been using it so much i would like to have its approach
somehow integrated in openscad itself.
this perhaps could resolve its main drawback: speed on complex
models: openscad creates a lot groups and getting much slower on
complex models than with the difference().
i would also like to share another library: essentially a human(not
linear algebra robot) oriented syntax rewrite library for basic
openscad operations i use a lot, but still need to make it ready for
publishing and documented first.
so whats your take folks?
Peter
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
That is very cool, seems a little bit like using "negative objects" and
"positive objects".
--
don bright
hmbright@fastmail.com
On Thu, Oct 6, 2016, at 02:55 PM, pproj@posteo.de wrote:
> hello after few years of work on my quite complex cad project, which
> i created using openscad .(my love to openscad was hampered by quite
> few a limittions for a compex project- but i am still working with it)
> anyway,
> i have decided it is time to share with others some of the things i
> have discovered and developed in the years of use.
>
> i will start with the sumUp(). which is an advanced replacement for
> the difference() keyword and allows for holes inside modules, and
> reduced nesting producing simpler code among other things.
> i have put it it under:
> https://github.com/solidboredom/sumUp
> but to show you why i have been using it so much: it can produce this
> example. the code below and the lib is all you need
> :
>
> include<sumup.scad> sumUp() { add() cube([20,20,7],center=true);
> lidWithNailsAndWasher(); }
> //== modules below == module lidWithNailsAndWasher() { add()
> //washer translate([,,8]) cube([20,20,1],center=true);
> addAfterRemoving() //top cover without holes translate([,,11])
> color("green") cube([17,17,2],center=true); for(x=[-1,1],y=[-1,1])
> translate([x*7,y*7,2]) { remove() cylinder(h=25,d=4.5,center=true);
> #addAfterRemoving() cylinder(h=10,d2=3,d1=1); } }
>
> i have been quite happy with thhe library (actually its predecessor)
> so i hope you will find it useful too.
> i have been using it so much i would like to have its approach
> somehow integrated in openscad itself.
> this perhaps could resolve its main drawback: speed on complex
> models: openscad creates a lot groups and getting much slower on
> complex models than with the difference().
>
> i would also like to share another library: essentially a human(not
> linear algebra robot) oriented syntax rewrite library for basic
> openscad operations i use a lot, but still need to make it ready for
> publishing and documented first.
> so whats your take folks?
> Peter
>
>
> _________________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
M
MichaelAtOz
Fri, Oct 7, 2016 12:57 AM
Peter, interesting approach, will be a useful technique elsewhere too. Thanks
for sharing.
You should add a licence to github, difficult to use a library if you don't
know the copyright implications.
(I recently found http://www.wtfpl.net/, otherwise cc0
<https://creativecommons.org/share-your-work/public-domain/cc0/ > or
CC-BY etc https://creativecommons.org/licenses/ )
Admin - PM me if you need anything, or if I've done something stupid...
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
View this message in context: http://forum.openscad.org/sumUp-to-Replace-Difference-in-most-cases-tp18580p18589.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Peter, interesting approach, will be a useful technique elsewhere too. Thanks
for sharing.
You should add a licence to github, difficult to use a library if you don't
know the copyright implications.
(I recently found http://www.wtfpl.net/, otherwise cc0
<https://creativecommons.org/share-your-work/public-domain/cc0/ > or
CC-BY etc <https://creativecommons.org/licenses/> )
-----
Admin - PM me if you need anything, or if I've done something stupid...
Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
--
View this message in context: http://forum.openscad.org/sumUp-to-Replace-Difference-in-most-cases-tp18580p18589.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
NH
nop head
Fri, Oct 7, 2016 8:14 AM
Interesting approach. Here is a more concise version noting that
children([0:$children-1]) is the same as children() and children already
come unioned:
module sumUp(showRemovedOnly=false)
{
$summingUp=true;
if(!showRemovedOnly)
{
difference()
{
for($beforeRemoving=true)
children();
for($removing = true)
children();
}
children();
}
if(showRemovedOnly)
for($removing = true)
children();
}
I think the reason it is slower is that all the negative objects get
unioned and passed as a single argument to difference whereas with the
normally coded version difference can have lots of subtrahends that don't
get pre unioned. I would think that for the same reason for loops will be
slower than repetitions when used in a subtrahend.
Perhaps there could be a simple tree optimisation after compilation and
before rendering that looks for redundant groups and unions under
difference nodes and where it is the subtrahend remove them and hoist the
children upwards.
On 7 October 2016 at 01:57, MichaelAtOz oz.at.michael@gmail.com wrote:
Peter, interesting approach, will be a useful technique elsewhere too.
Thanks
for sharing.
You should add a licence to github, difficult to use a library if you don't
know the copyright implications.
(I recently found http://www.wtfpl.net/, otherwise cc0
<https://creativecommons.org/share-your-work/public-domain/cc0/ > or
CC-BY etc https://creativecommons.org/licenses/ )
Admin - PM me if you need anything, or if I've done something stupid...
Unless specifically shown otherwise above, my contribution is in the
Public Domain; to the extent possible under law, I have waived all
copyright and related or neighbouring rights to this work. Obviously
inclusion of works of previous authors is not included in the above.
The TPP is no simple “trade agreement.” Fight it!
http://www.ourfairdeal.org/ time is running out!
View this message in context: http://forum.openscad.org/
sumUp-to-Replace-Difference-in-most-cases-tp18580p18589.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
Interesting approach. Here is a more concise version noting that
children([0:$children-1]) is the same as children() and children already
come unioned:
module sumUp(showRemovedOnly=false)
{
$summingUp=true;
if(!showRemovedOnly)
{
difference()
{
for($beforeRemoving=true)
children();
for($removing = true)
children();
}
children();
}
if(showRemovedOnly)
for($removing = true)
children();
}
I think the reason it is slower is that all the negative objects get
unioned and passed as a single argument to difference whereas with the
normally coded version difference can have lots of subtrahends that don't
get pre unioned. I would think that for the same reason for loops will be
slower than repetitions when used in a subtrahend.
Perhaps there could be a simple tree optimisation after compilation and
before rendering that looks for redundant groups and unions under
difference nodes and where it is the subtrahend remove them and hoist the
children upwards.
On 7 October 2016 at 01:57, MichaelAtOz <oz.at.michael@gmail.com> wrote:
> Peter, interesting approach, will be a useful technique elsewhere too.
> Thanks
> for sharing.
>
> You should add a licence to github, difficult to use a library if you don't
> know the copyright implications.
> (I recently found http://www.wtfpl.net/, otherwise cc0
> <https://creativecommons.org/share-your-work/public-domain/cc0/ > or
> CC-BY etc <https://creativecommons.org/licenses/> )
>
>
>
> -----
> Admin - PM me if you need anything, or if I've done something stupid...
>
> Unless specifically shown otherwise above, my contribution is in the
> Public Domain; to the extent possible under law, I have waived all
> copyright and related or neighbouring rights to this work. Obviously
> inclusion of works of previous authors is not included in the above.
>
> The TPP is no simple “trade agreement.” Fight it!
> http://www.ourfairdeal.org/ time is running out!
> --
> View this message in context: http://forum.openscad.org/
> sumUp-to-Replace-Difference-in-most-cases-tp18580p18589.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
>
RP
Ronaldo Persiano
Fri, Oct 7, 2016 1:34 PM
Surprising recoding, nophead. The for() statement is used as a let() !
2016-10-07 5:14 GMT-03:00 nop head nop.head@gmail.com:
I think the reason it is slower is that all the negative objects get
unioned and passed as a single argument to difference whereas with the
normally coded version difference can have lots of subtrahends that don't
get pre unioned. I would think that for the same reason for loops will be
slower than repetitions when used in a subtrahend.
Doesn't it depend on the geometrical complexity of each term? If the
positive object is complex and the subtrahends are simple, it should be
faster to do the subtrahend union before.
Surprising recoding, nophead. The for() statement is used as a let() !
2016-10-07 5:14 GMT-03:00 nop head <nop.head@gmail.com>:
> I think the reason it is slower is that all the negative objects get
> unioned and passed as a single argument to difference whereas with the
> normally coded version difference can have lots of subtrahends that don't
> get pre unioned. I would think that for the same reason for loops will be
> slower than repetitions when used in a subtrahend.
>
Doesn't it depend on the geometrical complexity of each term? If the
positive object is complex and the subtrahends are simple, it should be
faster to do the subtrahend union before.
