why does this script preview so differently from the render?
universe = 100;
module conditional_zflip_z(condition, z=0) {
if (condition)
scale([1,1,-1]) translate([0,0,-z]) children();
else children();
}
module conditional_offset(condition, delta) {
if (condition)
offset(delta=delta) children();
else children();
}
// generates an extrusion from z=0 and cropped at z=rise.
// extrusion tapers inward with positive run and outward with negative run
module roofrr(rise=1, run=1, s=universe) {
assert(run != 0, "run can not be zero.")
assert(rise != 0, "rise can not be zero.")
assert(s != 0, "s can not be zero.")
conditional_zflip_z(run<0, z=rise)
difference() {
scale([1,1,rise/abs(run)]) roof() conditional_offset(run<0,
delta=-run) children();
translate([0,0,rise>0 ? rise+s0.5 : rise-s0.5]) cube([s,s,s],
center=true);
}
}
module mytext() scale([2,2]) text("S", font="Liberation Sans:style=Bold
Italic");
module position(x,y) translate([20x,20y,0]) children();
position(0,0) roofrr(rise=1.0, run=0.6) mytext();
position(0,-1) roofrr(rise=-1.0, run=0.6) mytext();
position(1,0) roofrr(rise=1.0, run=-0.6) mytext();
position(1,-1) roofrr(rise=-1.0, run=-0.6) mytext();
The render:
[image: 037b7cb7-67de-492b-aef1-d313fb28fc73.png]
The preview:
[image: roofrr preview.png]
Looking at the preview from a variety of angles gives an impression of
something like the cube being subtracted is z fighting with its target.
Can someone explain how the preview is generated and why this happens?
The convexity argument is too low somewhere. Looks like giving
roof(convexity=10) fixes it.
On Fri, Sep 18, 2026 at 4:44 PM Todd Allen via Discuss <
discuss@lists.openscad.org> wrote:
universe = 100;
module conditional_zflip_z(condition, z=0) {
if (condition)
scale([1,1,-1]) translate([0,0,-z]) children();
else children();
}
module conditional_offset(condition, delta) {
if (condition)
offset(delta=delta) children();
else children();
}
// generates an extrusion from z=0 and cropped at z=rise.
// extrusion tapers inward with positive run and outward with negative run
module roofrr(rise=1, run=1, s=universe) {
assert(run != 0, "run can not be zero.")
assert(rise != 0, "rise can not be zero.")
assert(s != 0, "s can not be zero.")
conditional_zflip_z(run<0, z=rise)
difference() {
scale([1,1,rise/abs(run)]) roof() conditional_offset(run<0,
delta=-run) children();
translate([0,0,rise>0 ? rise+s0.5 : rise-s0.5])
cube([s,s,s], center=true);
}
}
module mytext() scale([2,2]) text("S", font="Liberation Sans:style=Bold
Italic");
module position(x,y) translate([20x,20y,0]) children();
position(0,0) roofrr(rise=1.0, run=0.6) mytext();
position(0,-1) roofrr(rise=-1.0, run=0.6) mytext();
position(1,0) roofrr(rise=1.0, run=-0.6) mytext();
position(1,-1) roofrr(rise=-1.0, run=-0.6) mytext();
The render:
[image: 037b7cb7-67de-492b-aef1-d313fb28fc73.png]
The preview:
[image: roofrr preview.png]
Looking at the preview from a variety of angles gives an impression of
something like the cube being subtracted is z fighting with its target.
Can someone explain how the preview is generated and why this happens?
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Thanks! It's been a long time since I have had a convexity issue and did
not think of it as something that might affect preview but not render. I
guess that is because preview does raytracing?
On Fri, Sep 18, 2026, 4:21 PM Adrian Mariano via Discuss <
discuss@lists.openscad.org> wrote:
The convexity argument is too low somewhere. Looks like giving
roof(convexity=10) fixes it.
On Fri, Sep 18, 2026 at 4:44 PM Todd Allen via Discuss <
discuss@lists.openscad.org> wrote:
universe = 100;
module conditional_zflip_z(condition, z=0) {
if (condition)
scale([1,1,-1]) translate([0,0,-z]) children();
else children();
}
module conditional_offset(condition, delta) {
if (condition)
offset(delta=delta) children();
else children();
}
// generates an extrusion from z=0 and cropped at z=rise.
// extrusion tapers inward with positive run and outward with negative run
module roofrr(rise=1, run=1, s=universe) {
assert(run != 0, "run can not be zero.")
assert(rise != 0, "rise can not be zero.")
assert(s != 0, "s can not be zero.")
conditional_zflip_z(run<0, z=rise)
difference() {
scale([1,1,rise/abs(run)]) roof() conditional_offset(run<0,
delta=-run) children();
translate([0,0,rise>0 ? rise+s0.5 : rise-s0.5])
cube([s,s,s], center=true);
}
}
module mytext() scale([2,2]) text("S", font="Liberation Sans:style=Bold
Italic");
module position(x,y) translate([20x,20y,0]) children();
position(0,0) roofrr(rise=1.0, run=0.6) mytext();
position(0,-1) roofrr(rise=-1.0, run=0.6) mytext();
position(1,0) roofrr(rise=1.0, run=-0.6) mytext();
position(1,-1) roofrr(rise=-1.0, run=-0.6) mytext();
The render:
[image: 037b7cb7-67de-492b-aef1-d313fb28fc73.png]
The preview:
[image: roofrr preview.png]
Looking at the preview from a variety of angles gives an impression of
something like the cube being subtracted is z fighting with its target.
Can someone explain how the preview is generated and why this happens?
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Thinking about it a bit more I've likely had plenty of convexity issues
that were less extreme and easily ignored. I'll probably find more now.
On Fri, Sep 18, 2026, 5:51 PM Todd Allen speedebikes@gmail.com wrote:
Thanks! It's been a long time since I have had a convexity issue and did
not think of it as something that might affect preview but not render. I
guess that is because preview does raytracing?
On Fri, Sep 18, 2026, 4:21 PM Adrian Mariano via Discuss <
discuss@lists.openscad.org> wrote:
The convexity argument is too low somewhere. Looks like giving
roof(convexity=10) fixes it.
On Fri, Sep 18, 2026 at 4:44 PM Todd Allen via Discuss <
discuss@lists.openscad.org> wrote:
universe = 100;
module conditional_zflip_z(condition, z=0) {
if (condition)
scale([1,1,-1]) translate([0,0,-z]) children();
else children();
}
module conditional_offset(condition, delta) {
if (condition)
offset(delta=delta) children();
else children();
}
// generates an extrusion from z=0 and cropped at z=rise.
// extrusion tapers inward with positive run and outward with negative
run
module roofrr(rise=1, run=1, s=universe) {
assert(run != 0, "run can not be zero.")
assert(rise != 0, "rise can not be zero.")
assert(s != 0, "s can not be zero.")
conditional_zflip_z(run<0, z=rise)
difference() {
scale([1,1,rise/abs(run)]) roof() conditional_offset(run<0,
delta=-run) children();
translate([0,0,rise>0 ? rise+s0.5 : rise-s0.5])
cube([s,s,s], center=true);
}
}
module mytext() scale([2,2]) text("S", font="Liberation Sans:style=Bold
Italic");
module position(x,y) translate([20x,20y,0]) children();
position(0,0) roofrr(rise=1.0, run=0.6) mytext();
position(0,-1) roofrr(rise=-1.0, run=0.6) mytext();
position(1,0) roofrr(rise=1.0, run=-0.6) mytext();
position(1,-1) roofrr(rise=-1.0, run=-0.6) mytext();
The render:
[image: 037b7cb7-67de-492b-aef1-d313fb28fc73.png]
The preview:
[image: roofrr preview.png]
Looking at the preview from a variety of angles gives an impression of
something like the cube being subtracted is z fighting with its target.
Can someone explain how the preview is generated and why this happens?
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
I've never understood why the default for Convexity is 1. Make it 100,
and many of these bug reports would vanish.
Jon
On 9/18/2026 7:05 PM, Todd Allen via Discuss wrote:
Thinking about it a bit more I've likely had plenty of convexity
issues that were less extreme and easily ignored. I'll probably find
more now.
On Fri, Sep 18, 2026, 5:51 PM Todd Allen speedebikes@gmail.com wrote:
Thanks! It's been a long time since I have had a convexity issue
and did not think of it as something that might affect preview but
not render. I guess that is because preview does raytracing?
--
This email has been checked for viruses by AVG antivirus software.
www.avg.com
Is there processing overhead with a higher default?
On Fri, Sep 18, 2026 at 6:18 PM Jon Bondy via Discuss <
discuss@lists.openscad.org> wrote:
I've never understood why the default for Convexity is 1. Make it 100,
and many of these bug reports would vanish.
Jon
On 9/18/2026 7:05 PM, Todd Allen via Discuss wrote:
Thinking about it a bit more I've likely had plenty of convexity issues
that were less extreme and easily ignored. I'll probably find more now.
On Fri, Sep 18, 2026, 5:51 PM Todd Allen speedebikes@gmail.com wrote:
Thanks! It's been a long time since I have had a convexity issue and did
not think of it as something that might affect preview but not render. I
guess that is because preview does raytracing?
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient
Virus-free.www.avg.com
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient
<#m_-3346072149058589412_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Yes, convexity=10 is fine on my system, but convexity=100 leads to jerky,
slow scrolling with large models. I'm using on board graphics---no
graphics card---so my graphics is weak.
On Fri, Sep 18, 2026 at 7:20 PM Father Horton via Discuss <
discuss@lists.openscad.org> wrote:
Is there processing overhead with a higher default?
On Fri, Sep 18, 2026 at 6:18 PM Jon Bondy via Discuss <
discuss@lists.openscad.org> wrote:
I've never understood why the default for Convexity is 1. Make it 100,
and many of these bug reports would vanish.
Jon
On 9/18/2026 7:05 PM, Todd Allen via Discuss wrote:
Thinking about it a bit more I've likely had plenty of convexity issues
that were less extreme and easily ignored. I'll probably find more now.
On Fri, Sep 18, 2026, 5:51 PM Todd Allen speedebikes@gmail.com wrote:
Thanks! It's been a long time since I have had a convexity issue and
did not think of it as something that might affect preview but not render.
I guess that is because preview does raytracing?
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient
Virus-free.www.avg.com
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient
<#m_3165102810642234509_m_-3346072149058589412_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Fine! 10 would be a huge improvement over 1! I withdraw my
shoot-from-the-hip request for 100.
:)
On 9/18/2026 7:26 PM, Adrian Mariano via Discuss wrote:
Yes, convexity=10 is fine on my system, but convexity=100 leads to
jerky, slow scrolling with large models. I'm using on board
graphics---no graphics card---so my graphics is weak.
On Fri, Sep 18, 2026 at 7:20 PM Father Horton via Discuss
discuss@lists.openscad.org wrote:
Is there processing overhead with a higher default?
On Fri, Sep 18, 2026 at 6:18 PM Jon Bondy via Discuss
<discuss@lists.openscad.org> wrote:
I've never understood why the default for Convexity is 1.
Make it 100, and many of these bug reports would vanish.
Jon
On 9/18/2026 7:05 PM, Todd Allen via Discuss wrote:
Thinking about it a bit more I've likely had plenty of
convexity issues that were less extreme and easily ignored.
I'll probably find more now.
On Fri, Sep 18, 2026, 5:51 PM Todd Allen
<speedebikes@gmail.com> wrote:
Thanks! It's been a long time since I have had a
convexity issue and did not think of it as something that
might affect preview but not render. I guess that is
because preview does raytracing?
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.avg.com_email-2Dsignature-3Futm-5Fmedium-3Demail-26utm-5Fsource-3Dlink-26utm-5Fcampaign-3Dsig-2Demail-26utm-5Fcontent-3Demailclient&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AsrE-c7ZR7B2Kyr3qgfvvppkCEBVsNmwEMndcrRSuOI&m=WeWxkJ55Ah0_uFV1RmfelMhehM99FY7K09xyGJkHBMwJSxL1eIdEW8zECWks5QtT&s=XZI6FGhfuWrRlVtZ_eMwyFY15TjBffz_o6UyWyCKqvc&e=>
Virus-free.www.avg.com
<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.avg.com_email-2Dsignature-3Futm-5Fmedium-3Demail-26utm-5Fsource-3Dlink-26utm-5Fcampaign-3Dsig-2Demail-26utm-5Fcontent-3Demailclient&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=AsrE-c7ZR7B2Kyr3qgfvvppkCEBVsNmwEMndcrRSuOI&m=WeWxkJ55Ah0_uFV1RmfelMhehM99FY7K09xyGJkHBMwJSxL1eIdEW8zECWks5QtT&s=XZI6FGhfuWrRlVtZ_eMwyFY15TjBffz_o6UyWyCKqvc&e=>
<#m_3165102810642234509_m_-3346072149058589412_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
_______________________________________________
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
OpenSCAD mailing list
To unsubscribe send an email todiscuss-leave@lists.openscad.org
--
This email has been checked for viruses by AVG antivirus software.
www.avg.com
Convexity has a performance hit, higher & it needs to do more work, basically a direct multiplication,
but preview is quick, so n*quick can usually be OK for low values of n.
Increasing the default has been raised a number of times, but no ideal number comes up.
It's been a long time since I have had a convexity issue and did not think of it as something that might affect preview but not render. I guess that is because preview does raytracing?
Technically not Raytracing, something like it.
It builds a depth buffer(Z buffer) stack of all the faces of things, then determines which bits are visible from the camera,
"First, only the front face of intersected and the back
face of subtracted primitives are potentially visible.
Second, each other primitive P affects the visibility of a
pixel in a potentially visible polygon by the number of
polygons of P in front of the pixel (called the parity,
which, for convex primitives, is always in-between zero
and two): If P is subtracted and the parity is one, the
pixel is not visible, and if P is intersected and the parity
is zero or two, the pixel is also not visible."
OpenCSG: A https://www.opencsg.org/data/csg_freenix2005_paper.pdf Library for Image-Based CSG Rendering (2005)
It's more complicated, read the linked paper, Figure 2. helps.
Also this one https://dl.acm.org/doi/pdf/10.1145/285305.285308 1998 (unfortunately a better quality version is not freely available).
From: Jon Bondy via Discuss [mailto:discuss@lists.openscad.org]
Sent: Saturday, September 19, 2026 9:18 AM
To: OpenSCAD general discussion Mailing-list
Cc: Todd Allen; Jon Bondy
Subject: [OpenSCAD] Re: why does this script preview so differently from the render?
I've never understood why the default for Convexity is 1. Make it 100, and many of these bug reports would vanish.
Jon
On 9/18/2026 7:05 PM, Todd Allen via Discuss wrote:
Thinking about it a bit more I've likely had plenty of convexity issues that were less extreme and easily ignored. I'll probably find more now.
On Fri, Sep 18, 2026, 5:51 PM Todd Allen speedebikes@gmail.com wrote:
Thanks! It's been a long time since I have had a convexity issue and did not think of it as something that might affect preview but not render. I guess that is because preview does raytracing?
Virus-free. http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient www.avg.com
On 9/18/2026 5:16 PM, Michael Marx (spin) via Discuss wrote:
Increasing the default has been raised a number of times, but no ideal
number comes up.
My favorite concept is to add a variable $convexity, which supplies the
default convexity for all consumers in its scope. It would be as if
every built-in module that accepts a "convexity" argument was declared
with the parameter "convexity=$convexity". $convexity could default to
1, or it could default to some larger number; the key fact is that the
program could readily override that default. Having $convexity default
to 1 would be 99.9% compatible (excluding only existing programs that
use $convexity for their own purposes), and a program that wants to make
its life simple could set it to 10 at the top level. Having $convexity
default to 10 would make life easier in most cases, but would be
slightly incompatible; a program that wants to return to 99.9%
compatibility could explicitly set it to 1 at the top level.