Yes, you generally need to nest the difference() levels to control where
the cuts happen vs. don't happen.
Generally, when I am cutting holes, I will way-oversize the cutting
structure. Because of the nesting, I don't have to worry about anything
"above" the cuts (both literally and logically).
Also, the "#" operator (makes the object created on a line of source text
visible regardless of what it is doing in the final render) can greatly aid
in troubleshooting cuts.
On Fri, Oct 7, 2022 at 12:00 PM Bogdan Caramalac via Discuss <
discuss@lists.openscad.org> wrote:
---------- Forwarded message ----------
From: fxeconomist@yahoo.com
To: discuss@lists.openscad.org
Cc:
Bcc:
Date: Fri, 7 Oct 2022 17:00:15 +0000
Subject: [OpenSCAD] Re: something upsets me about difference()
I can cut more on the outer hole side, but if I have only N units to cut
inside, does it actually cut N ?
And what happens if on the outside is actually another object ? It’s not
within the difference() declaration, it won’t cut from it, right ?
---------- Forwarded message ----------
From: Bogdan Caramalac via Discuss discuss@lists.openscad.org
To: discuss@lists.openscad.org
Cc: fxeconomist@yahoo.com
Bcc:
Date: Fri, 7 Oct 2022 17:00:15 +0000
Subject: [OpenSCAD] Re: something upsets me about difference()
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Hmm, I don’t even know about the # operator.
When I debug cuts, I temporarilly move the cylinders before the difference() so they appear solid so I see where the cut will be.
The nested nature of many designs is certainly there. However, decades of coding has resulted in habits leading to small easily understood pieces of code. I rarely nest difference()s because it just harder to understand. I tend to keep my modules to around 20 or so lines of code but there are exception of course. The nesting all takes place by modules calling modules.
Of course you can use +1 instead of tiny. A byproduct of using tiny is that it’s a signal in the code that this is an overlap situation. I can’t think of any other reason I use it. And I use 1/128 since someone pointed out in this forum about the floating point issue. It’s simply more aesthetically pleasing knowing that there is a little less floating point mess going on under the covers. And periodically a question shows up here about why a construction is failing and the answer is that two points should be equal but aren’t because of floating point issues.
-Bob
Tucson AZ
On Oct 7, 2022, at 10:14, FF Systems <joeh@rollanet.org mailto:joeh@rollanet.org> wrote:
Yes, you generally need to nest the difference() levels to control where the cuts happen vs. don't happen.
Generally, when I am cutting holes, I will way-oversize the cutting structure. Because of the nesting, I don't have to worry about anything "above" the cuts (both literally and logically).
Also, the "#" operator (makes the object created on a line of source text visible regardless of what it is doing in the final render) can greatly aid in troubleshooting cuts.
On Fri, Oct 7, 2022 at 12:00 PM Bogdan Caramalac via Discuss <discuss@lists.openscad.org mailto:discuss@lists.openscad.org> wrote:
---------- Forwarded message ----------
From: fxeconomist@yahoo.com mailto:fxeconomist@yahoo.com
To: discuss@lists.openscad.org mailto:discuss@lists.openscad.org
Cc:
Bcc:
Date: Fri, 7 Oct 2022 17:00:15 +0000
Subject: [OpenSCAD] Re: something upsets me about difference()
I can cut more on the outer hole side, but if I have only N units to cut inside, does it actually cut N ?
And what happens if on the outside is actually another object ? It’s not within the difference() declaration, it won’t cut from it, right ?
---------- Forwarded message ----------
From: Bogdan Caramalac via Discuss <discuss@lists.openscad.org mailto:discuss@lists.openscad.org>
To: discuss@lists.openscad.org mailto:discuss@lists.openscad.org
Cc: fxeconomist@yahoo.com mailto:fxeconomist@yahoo.com
Bcc:
Date: Fri, 7 Oct 2022 17:00:15 +0000
Subject: [OpenSCAD] Re: something upsets me about difference()
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org mailto:discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org mailto:discuss-leave@lists.openscad.org
-Bob
Tucson AZ