discuss@lists.openscad.org

OpenSCAD general discussion Mailing-list

View all threads

Re: [OpenSCAD] sumUp() to Replace Difference() (in most cases)

P
pproj
Fri, Oct 7, 2016 1:57 PM

Hello Nophead
you are right with the children. i had experienced problems which i have
attributed to sporadic issues with the nightly openscad i was using.
trying to solve these i have changed children() back to what it was
before: children([0:$children-1]).

but the cause of the problem was probably elsewhere completely, and it
surely can be changed back.
i did not think of the trick with the FOR instead of Union you use. do
you think it is faster? i had assumed that union of a union was a NOP
and would not have any effect. not sure if i was right though.
you code is much shorter anyway.

as for the tree optimization idea, this is very welcome to me, i had a
similar but very rough idea the branching is increased significantly by
the sumUps() and the If's inside thepredicates, but it was very rough,
you propose a solution.

i think somebody would have to touch the openscad code to accelerate
that, that is the probable problem.

by the way do you wish the rights to make the changes you wish(like the
"For" optimisation or whatever) on github of the project?
i am happy to give them to you. it is better to keep everything  in one
place instead of forking imho.
Peter

On 07.10.2016 10:14, nop head wrote:

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/ [1], otherwise cc0
<https://creativecommons.org/share-your-work/public-domain/cc0/ [2]

or

CC-BY etc <https://creativecommons.org/licenses/ [3]> )


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/ [4] time is running out!

View this message in context:

[5]
Sent from the OpenSCAD mailing list archive at Nabble.com.


OpenSCAD mailing list
Discuss@lists.openscad.org

[6]

Hello Nophead you are right with the children. i had experienced problems which i have attributed to sporadic issues with the nightly openscad i was using. trying to solve these i have changed children() back to what it was before: children([0:$children-1]). but the cause of the problem was probably elsewhere completely, and it surely can be changed back. i did not think of the trick with the FOR instead of Union you use. do you think it is faster? i had assumed that union of a union was a NOP and would not have any effect. not sure if i was right though. you code is much shorter anyway. as for the tree optimization idea, this is very welcome to me, i had a similar but very rough idea the branching is increased significantly by the sumUps() and the If's inside thepredicates, but it was very rough, you propose a solution. i think somebody would have to touch the openscad code to accelerate that, that is the probable problem. by the way do you wish the rights to make the changes you wish(like the "For" optimisation or whatever) on github of the project? i am happy to give them to you. it is better to keep everything in one place instead of forking imho. Peter On 07.10.2016 10:14, nop head wrote: > 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/ [1], otherwise cc0 >> <https://creativecommons.org/share-your-work/public-domain/cc0/ [2] >>> or >> CC-BY etc <https://creativecommons.org/licenses/ [3]> ) >> >> ----- >> 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/ [4] time is running out! >> -- >> View this message in context: >> > http://forum.openscad.org/sumUp-to-Replace-Difference-in-most-cases-tp18580p18589.html >> [5] >> 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 >> [6] > > > > Links: > ------ > [1] http://www.wtfpl.net/ > [2] https://creativecommons.org/share-your-work/public-domain/cc0/ > [3] https://creativecommons.org/licenses/ > [4] http://www.ourfairdeal.org/ > [5] > http://forum.openscad.org/sumUp-to-Replace-Difference-in-most-cases-tp18580p18589.html > [6] > 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