Re: [OpenSCAD] sumUp() to Replace Difference() (in most cases)
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
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 [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
[2]
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
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 [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
[2]
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 pproj@posteo.de 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
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 [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
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
2016-10-07 12:19 GMT-03:00 nop head nop.head@gmail.com:
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.