sumUp() to Replace Difference() (in most cases)

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

sumUp() to Replace Difference() (in most cases)

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

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

Re: sumUp() to Replace Difference() (in most cases)

Ronaldo
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 [hidden email] <[hidden email]>:
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
[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: sumUp() to Replace Difference() (in most cases)

Peter
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 [hidden email] <[hidden email]>:
>
>> 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
>> [hidden email]
>>
> 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
> [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: sumUp() to Replace Difference() (in most cases)

Ronaldo
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 <[hidden email]>:
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




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

Re: sumUp() to Replace Difference() (in most cases)

donbright
In reply to this post by Peter
That is very cool, seems a little bit like using "negative objects" and "positive objects".

--
  don bright


On Thu, Oct 6, 2016, at 02:55 PM, [hidden email] 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:
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


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

Re: sumUp() to Replace Difference() (in most cases)

MichaelAtOz
Administrator
In reply to this post by Peter
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 or CC-BY etc)
Admin - email* me if you need anything,
or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.

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

Re: sumUp() to Replace Difference() (in most cases)

nophead
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 <[hidden email]> 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
[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: sumUp() to Replace Difference() (in most cases)

Ronaldo
Surprising recoding, nophead. The for() statement is used as a let() !

2016-10-07 5:14 GMT-03:00 nop head <[hidden email]>:
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.

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

Re: sumUp() to Replace Difference() (in most cases)

Peter
In reply to this post by Peter


Everyone: i think this a very important point of the lib (it should be
be placed somewhere in the docs): you can now group things by their
semantic meaning and not by weather you are going to add or remove them.

On 07.10.2016 00:34, Ronaldo Persiano wrote:
> 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.

Hello Ronaldo
i actually think that is the very thing which makes the sumUp()
attractive - the code shorter and easier, because you can now group
things by their semantic meaning and not by weather you are going to add
or remove them.

say you want to make holes and add screws at some area of your model.
with difference() you would have to translate and rotate each of them
with reference to some third "zero-coordinate":
first for the subtracted part(holes) and then duplicating the same
translation and rotation for the screws.
it is impossible to say to openscad to "simply put screws just where you
have made holes" because the screws are positive and holes are made
inside the difference()
that is code redundancy something everybody is trying to avoid for good
reasons
with sumup() you could just group stuff by their meaning and do
translate(..)
  rotate()
{
remove() holes();
addAfterRemoving()bolts();
}
you could even move added part() in relation to the subtracted part not
some third "zero-coordinates", which is practically impossible with
difference() you have to hide your transformation by putting them into
transforming modules, and a lot of them! sometimes you have to manually
calculate the reverse transformation if you want to do something
relative to the part which is subtracted. quite terrible stuff.
but with sumUp () it is easy
translate(..)
  rotate()
{
  remove() holes();
  translate([0,0,2]) //move the bolts 2 mm out of the hole
  addAfterRemoving()bolts();
}
the same goes for "FOR" which can multiply holes and bolts in one step.
beside this now you can now put all this inside of a module, and even
add stuff which you want to be added before your remove()(and thus -
subtracted from) by using add()

>
> 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 <[hidden email]>:
>
>> 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
>
>
> _______________________________________________
> 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: sumUp() to Replace Difference() (in most cases)

Peter
In reply to this post by Peter


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 <[hidden email]>
> 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
>> [hidden email]
>>
> 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
> [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: sumUp() to Replace Difference() (in most cases)

Peter
In reply to this post by Peter


Hello Don
thanks for the good words, in fact i was thinking of naming the
predicates positive() and negative().
but this could not accomodate for the addBeforeRemoving() predicate
which is very useful in real world cases.
say when you construct holes and put screws in them.
my take was  that calling it add() and remove() is less mathematical and
should be a little bit more intuitively understood by just looking at
the code.
  at least this is what your module is doing: it "adds" stuff to your
main model, then it "removes" some and than it can add new stuff (think
screws in the holes) in one iteration. putting both things in the same
iterationv(no nesting of sumUp needed) simplifies the code for the
real-world-tasks for me a lot
Peter
On 07.10.2016 02:34, don bright wrote:

> That is very cool, seems a little bit like using "negative objects"
> and "positive objects".
>
> --
>
>  don bright
>
>  [hidden email]
>
> On Thu, Oct 6, 2016, at 02:55 PM, [hidden email] 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 [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
>>
>> [hidden email]
>>
>>
> 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
> [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: sumUp() to Replace Difference() (in most cases)

Peter
In reply to this post by Peter

hello Michael
  i am glad it had received positive attention form quite a few people,
so the work on documenting and publishing it was not wasted.
i have added the cc0.
licenses are not something i normally spend my time with- do you think
it is ok and useful now?
there are actually also some non obvious issues with predicates, once
you have to start nesting sumUps it can kind of invert the predicates if
you make a sumUp() of sumUp() (the same happens when you make difference
of a difference), this could be intended or not.
usually i need way less nesting with sumUp() anyway.
and there is a workaroundish solution for this too: the showRemovedOnly
parameter in sumUp which can be set to true in the call of the inner
sumUp:
like this:  sumUp() sumUp(showRemovedOnly=true)moduleX();
Peter



On 07.10.2016 02:57, MichaelAtOz 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
> [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: sumUp() to Replace Difference() (in most cases)

Peter
In reply to this post by Peter
Sorry of course i mean addAfterRemoving() as opposed to Add() and not
the non-existent "addBeforeRemoving()" which is now called just add()
that is definitely a weak spot in the predicate naming.

On 07.10.2016 15:58, pproj wrote:

> Hello Don
> thanks for the good words, in fact i was thinking of naming the
> predicates positive() and negative().
> but this could not accomodate for the addBeforeRemoving() predicate
> which is very useful in real world cases.
> say when you construct holes and put screws in them.
> my take was  that calling it add() and remove() is less mathematical
> and should be a little bit more intuitively understood by just looking
> at the code.
>  at least this is what your module is doing: it "adds" stuff to your
> main model, then it "removes" some and than it can add new stuff
> (think screws in the holes) in one iteration. putting both things in
> the same iterationv(no nesting of sumUp needed) simplifies the code
> for the real-world-tasks for me a lot
> Peter
> On 07.10.2016 02:34, don bright wrote:
>> That is very cool, seems a little bit like using "negative objects"
>> and "positive objects".
>>
>> --
>>
>>  don bright
>>
>>  [hidden email]
>>
>> On Thu, Oct 6, 2016, at 02:55 PM, [hidden email] 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 [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
>>>
>>> [hidden email]
>>>
>>>
>> 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
>> [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

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

Re: sumUp() to Replace Difference() (in most cases)

nophead
>Surprising recoding, nophead. The for() statement is used as a let() !

It is a bodge because let() isn't accepted at that position, assign is deprecated in favour of assignment in braces but braces don't work if they are not the child of something like for or if.

>it is impossible to say to openscad to "simply put screws just where you have made holes ...

I make the screw hole positions relative to the part's origin into a module that translates a child. Then I can use that with a poly_cylinder child to drill the holes in both the part and mating parts and with a screw / washer / nut combo child to place the fasteners just after I place the part.

I haven't felt the need to encapsulate objects and their holes into the same module. I simply have my_object(), my_object_hole_positions() and usually my_object_assembly(), which is the object plus its fasteners. The hole positions might be used to drill clearance holes in the part and tappable holes or nut traps in a mating part, etc, so I find it more useful than having the object bore its own holes.

>i did not think of the trick with the FOR instead of Union you use. do you think it is faster?

No just more succinct source code.

> i had assumed that union of a union was a NOP and would not have any effect.

It is a NOP because children() already unions the kids so there is nothing to union. However I think we really want the kids to be hoisted into the difference without being unioned first.

> i had a similar but very rough idea the branching is increased significantly by the sumUps

I don't think the branching adds any significant time. It has to be extra CSG ops to slow things down noticeably.

>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?

No thanks. The normal protocol is fork and submit a pull request but for such a short piece of code it doesn't seem worth the hassle.


On 7 October 2016 at 15:16, pproj <[hidden email]> wrote:
Sorry of course i mean addAfterRemoving() as opposed to Add() and not the non-existent "addBeforeRemoving()" which is now called just add()
that is definitely a weak spot in the predicate naming.


On 07.10.2016 15:58, pproj wrote:
Hello Don
thanks for the good words, in fact i was thinking of naming the
predicates positive() and negative().
but this could not accomodate for the addBeforeRemoving() predicate
which is very useful in real world cases.
say when you construct holes and put screws in them.
my take was  that calling it add() and remove() is less mathematical
and should be a little bit more intuitively understood by just looking
at the code.
 at least this is what your module is doing: it "adds" stuff to your
main model, then it "removes" some and than it can add new stuff
(think screws in the holes) in one iteration. putting both things in
the same iterationv(no nesting of sumUp needed) simplifies the code
for the real-world-tasks for me a lot
Peter
On 07.10.2016 02:34, don bright wrote:
That is very cool, seems a little bit like using "negative objects"
and "positive objects".

--

 don bright

 [hidden email]

On Thu, Oct 6, 2016, at 02:55 PM, [hidden email] 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 [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

[hidden email]


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
[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

_______________________________________________
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: sumUp() to Replace Difference() (in most cases)

Ronaldo
2016-10-07 12:19 GMT-03:00 nop head <[hidden email]>:
>Surprising recoding, nophead. The for() statement is used as a let() !

It is a bodge because let() isn't accepted at that position, assign is deprecated in favour of assignment in braces but braces don't work if they are not the child of something like for or if.

It is a strange construction because for() is not used over a list but a simple element. Regular modules and functions accept variables not declared in their definition as argument (like $fn in cylinder()). Although children() seems to be syntactically a module, it doesn't accept the construction children($beforeRemoving=true) or even children([0:$children-1],$beforeRemoving=true) what would simplify the code a bit more.

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