zero thickness membranes in Preview as a result of difference()
When I difference two objects that have a common length on one dimension, I
see a thin membrane in Preview rather than a hole:
http://forum.openscad.org/file/t2199/membrane.png Here's sample
code:$fn=40;dist=3;difference(){ cube([5,5,dist],center=true);
cylinder(r=2,h=dist,center=true);}I know that this membrane goes away when
the model is rendered but I'm producing complex objects where the rendering
process can take several minutes. I'm also using the customizer so the
membrane is redisplayed each time a parameter is changed.I have worked
around this behavior by liberally peppering my code with references to a
global fudge factor:fudge=0.005.I add this factor to any object that will be
used to difference another object. Often, I have to add a translate() call
just to move the resultant object down by fudge/2 to ensure that the hole is
uncovered on both sides of the first object.Since I'm 3D printing the final
model, this fudge factor is in the noise but it makes a mess of my code.
How have you all solved this problem? Remember, requiring a render step
isn't a solution.Thanks,Ken
--
Sent from: http://forum.openscad.org/
Hi,
Your approach is the conventional one. But we usually call the variable
epsilon :)
This is actually pretty common in 3D printing and other fields. You'll find
the same approach occasionally used in vector graphics, for example.
Floating point precision errors cause headaches all around.
I know you say rendering is not an option, but you might check out the
render() primitive, which allows you to force rendering for particular
parts of your model. Depending on the geometry you're working with, you may
be able to render the outermost parts so you can see the interior details,
without rendering the whole thing.
Best of luck!
On Wed, Apr 22, 2020, 5:25 PM khackbarth ken@volksswitch.org wrote:
When I difference two objects that have a common length on one dimension,
I see a thin membrane in Preview rather than a hole: Here's sample code:
$fn=40; dist=3; difference(){ cube([5,5,dist],center=true);
cylinder(r=2,h=dist,center=true); } I know that this membrane goes away
when the model is rendered but I'm producing complex objects where the
rendering process can take several minutes. I'm also using the customizer
so the membrane is redisplayed each time a parameter is changed. I have
worked around this behavior by liberally peppering my code with references
to a global fudge factor: fudge=0.005. I add this factor to any object that
will be used to difference another object. Often, I have to add a
translate() call just to move the resultant object down by fudge/2 to
ensure that the hole is uncovered on both sides of the first object. Since
I'm 3D printing the final model, this fudge factor is in the noise but it
makes a mess of my code. How have you all solved this problem? Remember,
requiring a render step isn't a solution. Thanks, Ken
Sent from the OpenSCAD mailing list archive http://forum.openscad.org/
at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
I simple always subtract something that is bigger. It's like drilling a
hole, you always use a drill longer than the hole. I often default to
subtracting a cylinder 100 long.
On Thu, 23 Apr 2020 at 00:25, khackbarth ken@volksswitch.org wrote:
When I difference two objects that have a common length on one dimension,
I see a thin membrane in Preview rather than a hole: Here's sample code:
$fn=40; dist=3; difference(){ cube([5,5,dist],center=true);
cylinder(r=2,h=dist,center=true); } I know that this membrane goes away
when the model is rendered but I'm producing complex objects where the
rendering process can take several minutes. I'm also using the customizer
so the membrane is redisplayed each time a parameter is changed. I have
worked around this behavior by liberally peppering my code with references
to a global fudge factor: fudge=0.005. I add this factor to any object that
will be used to difference another object. Often, I have to add a
translate() call just to move the resultant object down by fudge/2 to
ensure that the hole is uncovered on both sides of the first object. Since
I'm 3D printing the final model, this fudge factor is in the noise but it
makes a mess of my code. How have you all solved this problem? Remember,
requiring a render step isn't a solution. Thanks, Ken
Sent from the OpenSCAD mailing list archive http://forum.openscad.org/
at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
It's called z-fighting, see the link here
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/FAQ#What_are_those_strange_flickering_artifacts_in_the_preview?
.
Your fudged is the correct way too handle it.
It is also good to use the fudge, as sometimes these co-incident faces can
cause non-manifoldness or other problems.
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.
--
Sent from: http://forum.openscad.org/
I will say that I, too, balked when I was first asked to do this, but once
one becomes used to it & plans for it at the outset, one finds idiomatic
ways to incorporate it and it doesn't feel like such a hack.
On Wed, Apr 22, 2020, 5:34 PM Max Bond max.o.bond@gmail.com wrote:
Hi,
Your approach is the conventional one. But we usually call the variable
epsilon :)
This is actually pretty common in 3D printing and other fields. You'll
find the same approach occasionally used in vector graphics, for example.
Floating point precision errors cause headaches all around.
I know you say rendering is not an option, but you might check out the
render() primitive, which allows you to force rendering for particular
parts of your model. Depending on the geometry you're working with, you may
be able to render the outermost parts so you can see the interior details,
without rendering the whole thing.
Best of luck!
On Wed, Apr 22, 2020, 5:25 PM khackbarth ken@volksswitch.org wrote:
When I difference two objects that have a common length on one dimension,
I see a thin membrane in Preview rather than a hole: Here's sample code:
$fn=40; dist=3; difference(){ cube([5,5,dist],center=true);
cylinder(r=2,h=dist,center=true); } I know that this membrane goes away
when the model is rendered but I'm producing complex objects where the
rendering process can take several minutes. I'm also using the customizer
so the membrane is redisplayed each time a parameter is changed. I have
worked around this behavior by liberally peppering my code with references
to a global fudge factor: fudge=0.005. I add this factor to any object that
will be used to difference another object. Often, I have to add a
translate() call just to move the resultant object down by fudge/2 to
ensure that the hole is uncovered on both sides of the first object. Since
I'm 3D printing the final model, this fudge factor is in the noise but it
makes a mess of my code. How have you all solved this problem? Remember,
requiring a render step isn't a solution. Thanks, Ken
Sent from the OpenSCAD mailing list archive http://forum.openscad.org/
at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
BTW your original post has that large paragraph without line breaks, I
presume it was not formatted that way originally, what method did you use to
post it.
I don't normally see "Sent from the OpenSCAD mailing list archive at
Nabble.com"
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.
--
Sent from: http://forum.openscad.org/
BTW your original post has that large paragraph without line breaks, I
presume it was not formatted that way originally, what method did you use to
post it.
I don't normally see "Sent from the OpenSCAD mailing list archive at
Nabble.com"
MichaelAtOz
Forum Admin
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.
--
Sent from: http://forum.openscad.org/
On 4/22/2020 4:25 PM, khackbarth wrote:
Since I'm 3D printing the final model, this fudge factor is in the
noise but it makes a mess of my code.
The fudge factor should be applied only to the "negative" objects, the
second-and-later children of the difference().
Since it only applies to the negative objects, it never appears in the
final result.
I call it itsy (as it itsy bitsy). Any small number where the precise value
isn't of importance.
Max Bond wrote
Your approach is the conventional one. But we usually call the variable
epsilon :)
--
Sent from: http://forum.openscad.org/
This is a general principle of computing : “any program such depends on (a
== b) is broken”
Manufacturing has a similar concept : tolerance.
I disagree with the claim that only “difference” needs a tolerance. It’s
also necessary when doing a “union” of two objects with a shared boundary.
--
Sent from: http://forum.openscad.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
--
-Kenneth Sloan