RW
Rogier Wolff
Fri, Jun 12, 2026 12:34 PM
Ubuntu hard-dropped support for my graphics driver (NVIDIA). So as
we're now 4 years further, I was hoping the open source version
would've matured to the level to be usable.
I remember trying it 4 years ago, finding it unusable for some reason
and then switching to "nvidia" without any further problems....
Well now trying nouveau again... openscad shows the classic
Z-fighting that we all recognize when objects coincide.
e.g.
difference () {
cube (40);
cube (20);
}
but now for all planes. In the "z-fight.png" screenshot I've turned
the above so you can see a fully non-transparent (minus about 100
pixels) side, a fully shimmered side, and a half-open side.
At this orientation. I don't get the shimmering on the sides that
normally don't shimmer.
On this object, the "no shimmering expected" faces don't do it that
often. Only on very rare orientations. WIth my real model that I'm
working on, it is about about 50% of the faces that get hit on every
possible orientation.
See z-fight2.png for where the whole bottom surface is partly
transparent.
With some back-and-forth with an AI, it seems that openscad is drawing
both the front and back faces of objects, with the back face making
the pixels transparent when they get drawn.
But they shouldn't be drawn because they need to be "deeper". This
Z-buffer offset is calculated at the corners of the triangles,
interpolated while the GPU iterates along the scanlines, and sometimes
the offset is not enough to cause the back-side to be "deeper" than
the front side.
Is this Z-offset trick fully driver-side so I should complain to the
nouveau guys, or is this a: "an offset of 1 guarantees it will be
deeper(*)" that is somehow a constant inside the openscad 3D code?
Roger.
(*) That's wrong as soon as interpolation starts happening.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Verl. Spiegelmakerstraat 37 2645 LZ Delfgauw, The Netherlands.
** KVK: 27239233 **
f equals m times a. When your f is steady, and your m is going down
your a** is going up. -- Chris Hadfield about flying up the space shuttle.
** 'a' for accelleration.
Ubuntu hard-dropped support for my graphics driver (NVIDIA). So as
we're now 4 years further, I was hoping the open source version
would've matured to the level to be usable.
I remember trying it 4 years ago, finding it unusable for some reason
and then switching to "nvidia" without any further problems....
Well now trying nouveau again... openscad shows the classic
Z-fighting that we all recognize when objects coincide.
e.g.
difference () {
cube (40);
cube (20);
}
but now for all planes. In the "z-fight.png" screenshot I've turned
the above so you can see a fully non-transparent (minus about 100
pixels) side, a fully shimmered side, and a half-open side.
At this orientation. I don't get the shimmering on the sides that
normally don't shimmer.
On this object, the "no shimmering expected" faces don't do it that
often. Only on very rare orientations. WIth my real model that I'm
working on, it is about about 50% of the faces that get hit on every
possible orientation.
See z-fight2.png for where the whole bottom surface is partly
transparent.
With some back-and-forth with an AI, it seems that openscad is drawing
both the front and back faces of objects, with the back face making
the pixels transparent when they get drawn.
But they shouldn't be drawn because they need to be "deeper". This
Z-buffer offset is calculated at the corners of the triangles,
interpolated while the GPU iterates along the scanlines, and sometimes
the offset is not enough to cause the back-side to be "deeper" than
the front side.
Is this Z-offset trick fully driver-side so I should complain to the
nouveau guys, or is this a: "an offset of 1 guarantees it will be
deeper(*)" that is somehow a constant inside the openscad 3D code?
Roger.
(*) That's wrong as soon as interpolation starts happening.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Verl. Spiegelmakerstraat 37 2645 LZ Delfgauw, The Netherlands.
** KVK: 27239233 **
f equals m times a. When your f is steady, and your m is going down
your a** is going up. -- Chris Hadfield about flying up the space shuttle.
** 'a' for accelleration.
L
larry
Fri, Jun 12, 2026 5:28 PM
On Fri, 2026-06-12 at 14:34 +0200, Rogier Wolff via Discuss wrote:
Ubuntu hard-dropped support for my graphics driver (NVIDIA). So as
we're now 4 years further, I was hoping the open source version
would've matured to the level to be usable.
I remember trying it 4 years ago, finding it unusable for some reason
and then switching to "nvidia" without any further problems....
Well now trying nouveau again... openscad shows the classic
Z-fighting that we all recognize when objects coincide.
e.g.
difference () {
cube (40);
cube (20);
}
Tried it on my machine, and all looks as expected, z-fighting on 1/4 of
three faces.
I'm running Ubuntu 22.04.5 LTS MATE.
My graphics card:
Advanced Micro Devices, Inc. [AMD/ATI] Cezanne (rev c9)
No idea if that helps you, but only a few pixens were inconvenienced.
but now for all planes. In the "z-fight.png" screenshot I've turned
the above so you can see a fully non-transparent (minus about 100
pixels) side, a fully shimmered side, and a half-open side.
At this orientation. I don't get the shimmering on the sides that
normally don't shimmer.
On this object, the "no shimmering expected" faces don't do it that
often. Only on very rare orientations. WIth my real model that I'm
working on, it is about about 50% of the faces that get hit on every
possible orientation.
See z-fight2.png for where the whole bottom surface is partly
transparent.
With some back-and-forth with an AI, it seems that openscad is
drawing
both the front and back faces of objects, with the back face making
the pixels transparent when they get drawn.
But they shouldn't be drawn because they need to be "deeper". This
Z-buffer offset is calculated at the corners of the triangles,
interpolated while the GPU iterates along the scanlines, and
sometimes
the offset is not enough to cause the back-side to be "deeper" than
the front side.
Is this Z-offset trick fully driver-side so I should complain to the
nouveau guys, or is this a: "an offset of 1 guarantees it will be
deeper(*)" that is somehow a constant inside the openscad 3D code?
Roger.
(*) That's wrong as soon as interpolation starts happening.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
On Fri, 2026-06-12 at 14:34 +0200, Rogier Wolff via Discuss wrote:
>
> Ubuntu hard-dropped support for my graphics driver (NVIDIA). So as
> we're now 4 years further, I was hoping the open source version
> would've matured to the level to be usable.
>
> I remember trying it 4 years ago, finding it unusable for some reason
> and then switching to "nvidia" without any further problems....
>
> Well now trying nouveau again... openscad shows the classic
> Z-fighting that we all recognize when objects coincide.
>
> e.g.
>
> difference () {
> cube (40);
> cube (20);
> }
Tried it on my machine, and all looks as expected, z-fighting on 1/4 of
three faces.
I'm running Ubuntu 22.04.5 LTS MATE.
My graphics card:
Advanced Micro Devices, Inc. [AMD/ATI] Cezanne (rev c9)
No idea if that helps you, but only a few pixens were inconvenienced.
> but now for all planes. In the "z-fight.png" screenshot I've turned
> the above so you can see a fully non-transparent (minus about 100
> pixels) side, a fully shimmered side, and a half-open side.
>
> At this orientation. I don't get the shimmering on the sides that
> normally don't shimmer.
>
> On this object, the "no shimmering expected" faces don't do it that
> often. Only on very rare orientations. WIth my real model that I'm
> working on, it is about about 50% of the faces that get hit on every
> possible orientation.
>
> See z-fight2.png for where the whole bottom surface is partly
> transparent.
>
> With some back-and-forth with an AI, it seems that openscad is
> drawing
> both the front and back faces of objects, with the back face making
> the pixels transparent when they get drawn.
>
> But they shouldn't be drawn because they need to be "deeper". This
> Z-buffer offset is calculated at the corners of the triangles,
> interpolated while the GPU iterates along the scanlines, and
> sometimes
> the offset is not enough to cause the back-side to be "deeper" than
> the front side.
>
> Is this Z-offset trick fully driver-side so I should complain to the
> nouveau guys, or is this a: "an offset of 1 guarantees it will be
> deeper(*)" that is somehow a constant inside the openscad 3D code?
>
> Roger.
>
> (*) That's wrong as soon as interpolation starts happening.
>
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
JB
Jordan Brown
Fri, Jun 12, 2026 5:44 PM
That second picture, where the entire bottom of the cube is messed up,
doesn't seem like it can be tied to the difference. I'm not deeply
familiar with the previewer, but I don't think that a difference
generates any triangles that are "outside" the negative volume, and so I
don't think it can cause Z-fighting problems for the other 3/4 of that
face.
Random diagnostic thought: perhaps we should have a way to dump the
list of triangles (and other parameters) that we're handing to OpenGL,
and a separate program that consumes that list and feeds it to OpenGL.
That would allow for exercising these cases with more repeatability and
precision, and giving OpenGL providers simple(r) test cases to look at.
That second picture, where the entire bottom of the cube is messed up,
doesn't seem like it can be tied to the difference. I'm not deeply
familiar with the previewer, but I don't think that a difference
generates any triangles that are "outside" the negative volume, and so I
don't think it *can* cause Z-fighting problems for the other 3/4 of that
face.
Random diagnostic thought: perhaps we should have a way to dump the
list of triangles (and other parameters) that we're handing to OpenGL,
and a separate program that consumes that list and feeds it to OpenGL.
That would allow for exercising these cases with more repeatability and
precision, and giving OpenGL providers simple(r) test cases to look at.
CC
Cory Cross
Fri, Jun 12, 2026 5:56 PM
Manifold is so fast now, can you just live without using Preview?
On June 12, 2026 5:34:52 AM PDT, Rogier Wolff via Discuss discuss@lists.openscad.org wrote:
Ubuntu hard-dropped support for my graphics driver (NVIDIA). So as
we're now 4 years further, I was hoping the open source version
would've matured to the level to be usable.
I remember trying it 4 years ago, finding it unusable for some reason
and then switching to "nvidia" without any further problems....
Well now trying nouveau again... openscad shows the classic
Z-fighting that we all recognize when objects coincide.
e.g.
difference () {
cube (40);
cube (20);
}
but now for all planes. In the "z-fight.png" screenshot I've turned
the above so you can see a fully non-transparent (minus about 100
pixels) side, a fully shimmered side, and a half-open side.
At this orientation. I don't get the shimmering on the sides that
normally don't shimmer.
On this object, the "no shimmering expected" faces don't do it that
often. Only on very rare orientations. WIth my real model that I'm
working on, it is about about 50% of the faces that get hit on every
possible orientation.
See z-fight2.png for where the whole bottom surface is partly
transparent.
With some back-and-forth with an AI, it seems that openscad is drawing
both the front and back faces of objects, with the back face making
the pixels transparent when they get drawn.
But they shouldn't be drawn because they need to be "deeper". This
Z-buffer offset is calculated at the corners of the triangles,
interpolated while the GPU iterates along the scanlines, and sometimes
the offset is not enough to cause the back-side to be "deeper" than
the front side.
Is this Z-offset trick fully driver-side so I should complain to the
nouveau guys, or is this a: "an offset of 1 guarantees it will be
deeper(*)" that is somehow a constant inside the openscad 3D code?
Roger.
(*) That's wrong as soon as interpolation starts happening.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Verl. Spiegelmakerstraat 37 2645 LZ Delfgauw, The Netherlands.
** KVK: 27239233 **
f equals m times a. When your f is steady, and your m is going down
your a** is going up. -- Chris Hadfield about flying up the space shuttle.
** 'a' for accelleration.
Manifold is so fast now, can you just live without using Preview?
On June 12, 2026 5:34:52 AM PDT, Rogier Wolff via Discuss <discuss@lists.openscad.org> wrote:
>
>Ubuntu hard-dropped support for my graphics driver (NVIDIA). So as
>we're now 4 years further, I was hoping the open source version
>would've matured to the level to be usable.
>
>I remember trying it 4 years ago, finding it unusable for some reason
>and then switching to "nvidia" without any further problems....
>
>Well now trying nouveau again... openscad shows the classic
>Z-fighting that we all recognize when objects coincide.
>
>e.g.
>
> difference () {
> cube (40);
> cube (20);
> }
>
>but now for all planes. In the "z-fight.png" screenshot I've turned
>the above so you can see a fully non-transparent (minus about 100
>pixels) side, a fully shimmered side, and a half-open side.
>
>At this orientation. I don't get the shimmering on the sides that
>normally don't shimmer.
>
>On this object, the "no shimmering expected" faces don't do it that
>often. Only on very rare orientations. WIth my real model that I'm
>working on, it is about about 50% of the faces that get hit on every
>possible orientation.
>
>See z-fight2.png for where the whole bottom surface is partly
>transparent.
>
>With some back-and-forth with an AI, it seems that openscad is drawing
>both the front and back faces of objects, with the back face making
>the pixels transparent when they get drawn.
>
>But they shouldn't be drawn because they need to be "deeper". This
>Z-buffer offset is calculated at the corners of the triangles,
>interpolated while the GPU iterates along the scanlines, and sometimes
>the offset is not enough to cause the back-side to be "deeper" than
>the front side.
>
>Is this Z-offset trick fully driver-side so I should complain to the
>nouveau guys, or is this a: "an offset of 1 guarantees it will be
>deeper(*)" that is somehow a constant inside the openscad 3D code?
>
> Roger.
>
>(*) That's wrong as soon as interpolation starts happening.
>
>
>--
>** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
>** Verl. Spiegelmakerstraat 37 2645 LZ Delfgauw, The Netherlands.
>** KVK: 27239233 **
>f equals m times a. When your f is steady, and your m is going down
>your a** is going up. -- Chris Hadfield about flying up the space shuttle.
>** 'a' for accelleration.
TP
Torsten Paul
Fri, Jun 12, 2026 6:27 PM
On 12.06.26 14:34, Rogier Wolff via Discuss wrote:
Well now trying nouveau again... openscad shows the classic
Z-fighting that we all recognize when objects coincide.
08-Feb-2026: OpenCSG 1.8.2 release with rendering fixes for Linux
The new release fixes a z-fighting bug in the SCS algorithm, that was
known for a long time, under Linux with Nouveau graphics driver.
ciao,
Torsten.
On 12.06.26 14:34, Rogier Wolff via Discuss wrote:
> Well now trying nouveau again... openscad shows the classic
> Z-fighting that we all recognize when objects coincide.
It might be that:
https://opencsg.org/news.html
> 08-Feb-2026: OpenCSG 1.8.2 release with rendering fixes for Linux
with Nouveau driver
> The new release fixes a z-fighting bug in the SCS algorithm, that was
known for a long time, under Linux with Nouveau graphics driver.
ciao,
Torsten.
GB
Glenn Butcher
Fri, Jun 12, 2026 6:48 PM
Almost, still need it to temporarily prepend # to subtractors in
difference() operations, so I can see them to scooch them around.
On 6/12/2026 11:56 AM, Cory Cross via Discuss wrote:
Manifold is so fast now, can you just live without using Preview?
On June 12, 2026 5:34:52 AM PDT, Rogier Wolff via Discuss
discuss@lists.openscad.org wrote:
Ubuntu hard-dropped support for my graphics driver (NVIDIA). So as
we're now 4 years further, I was hoping the open source version
would've matured to the level to be usable. I remember trying it 4
years ago, finding it unusable for some reason and then switching
to "nvidia" without any further problems.... Well now trying
nouveau again... openscad shows the classic Z-fighting that we all
recognize when objects coincide. e.g. difference () { cube (40);
cube (20); } but now for all planes. In the "z-fight.png"
screenshot I've turned the above so you can see a fully
non-transparent (minus about 100 pixels) side, a fully shimmered
side, and a half-open side. At this orientation. I don't get the
shimmering on the sides that normally don't shimmer. On this
object, the "no shimmering expected" faces don't do it that often.
Only on very rare orientations. WIth my real model that I'm
working on, it is about about 50% of the faces that get hit on
every possible orientation. See z-fight2.png for where the whole
bottom surface is partly transparent. With some back-and-forth
with an AI, it seems that openscad is drawing both the front and
back faces of objects, with the back face making the pixels
transparent when they get drawn. But they shouldn't be drawn
because they need to be "deeper". This Z-buffer offset is
calculated at the corners of the triangles, interpolated while the
GPU iterates along the scanlines, and sometimes the offset is not
enough to cause the back-side to be "deeper" than the front side.
Is this Z-offset trick fully driver-side so I should complain to
the nouveau guys, or is this a: "an offset of 1 guarantees it will
be deeper(*)" that is somehow a constant inside the openscad 3D
code? Roger. (*) That's wrong as soon as interpolation starts
happening.
OpenSCAD mailing list
To unsubscribe send an email todiscuss-leave@lists.openscad.org
Almost, still need it to temporarily prepend # to subtractors in
difference() operations, so I can see them to scooch them around.
On 6/12/2026 11:56 AM, Cory Cross via Discuss wrote:
> Manifold is so fast now, can you just live without using Preview?
>
>
> On June 12, 2026 5:34:52 AM PDT, Rogier Wolff via Discuss
> <discuss@lists.openscad.org> wrote:
>
> Ubuntu hard-dropped support for my graphics driver (NVIDIA). So as
> we're now 4 years further, I was hoping the open source version
> would've matured to the level to be usable. I remember trying it 4
> years ago, finding it unusable for some reason and then switching
> to "nvidia" without any further problems.... Well now trying
> nouveau again... openscad shows the classic Z-fighting that we all
> recognize when objects coincide. e.g. difference () { cube (40);
> cube (20); } but now for all planes. In the "z-fight.png"
> screenshot I've turned the above so you can see a fully
> non-transparent (minus about 100 pixels) side, a fully shimmered
> side, and a half-open side. At this orientation. I don't get the
> shimmering on the sides that normally don't shimmer. On this
> object, the "no shimmering expected" faces don't do it that often.
> Only on very rare orientations. WIth my real model that I'm
> working on, it is about about 50% of the faces that get hit on
> every possible orientation. See z-fight2.png for where the whole
> bottom surface is partly transparent. With some back-and-forth
> with an AI, it seems that openscad is drawing both the front and
> back faces of objects, with the back face making the pixels
> transparent when they get drawn. But they shouldn't be drawn
> because they need to be "deeper". This Z-buffer offset is
> calculated at the corners of the triangles, interpolated while the
> GPU iterates along the scanlines, and sometimes the offset is not
> enough to cause the back-side to be "deeper" than the front side.
> Is this Z-offset trick fully driver-side so I should complain to
> the nouveau guys, or is this a: "an offset of 1 guarantees it will
> be deeper(*)" that is somehow a constant inside the openscad 3D
> code? Roger. (*) That's wrong as soon as interpolation starts
> happening.
>
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email todiscuss-leave@lists.openscad.org
L
larry
Fri, Jun 12, 2026 8:03 PM
On Fri, 2026-06-12 at 12:48 -0600, Glenn Butcher via Discuss wrote:
Almost, still need it to temporarily prepend # to subtractors in
difference() operations, so I can see them to scooch them around.
On 6/12/2026 11:56 AM, Cory Cross via Discuss wrote:
As do I, but for more than difference() operations.
When I am modifying an existing STL, I use # and z-fighting to find the
exact measurements of holes, heights of surfaces where render->measure
is impractical, etc.
I also use % to line up connecting structures when working on something
that needs to fit together.
Manifold is so fast now, can you just live without using Preview?
On June 12, 2026 5:34:52 AM PDT, Rogier Wolff via Discuss
discuss@lists.openscad.org wrote:
Ubuntu hard-dropped support for my graphics driver (NVIDIA). So
as we're now 4 years further, I was hoping the open source
version would've matured to the level to be usable. I remember
trying it 4 years ago, finding it unusable for some reason and
then switching to "nvidia" without any further problems.... Well
now trying nouveau again... openscad shows the classic Z-fighting
that we all recognize when objects coincide. e.g. difference () {
cube (40); cube (20); } but now for all planes. In the "z-
fight.png" screenshot I've turned the above so you can see a
fully non-transparent (minus about 100 pixels) side, a fully
shimmered side, and a half-open side. At this orientation. I
don't get the shimmering on the sides that normally don't
shimmer. On this object, the "no shimmering expected" faces don't
do it that often. Only on very rare orientations. WIth my real
model that I'm working on, it is about about 50% of the faces
that get hit on every possible orientation. See z-fight2.png for
where the whole bottom surface is partly transparent. With some
back-and-forth with an AI, it seems that openscad is drawing both
the front and back faces of objects, with the back face making
the pixels transparent when they get drawn. But they shouldn't be
drawn because they need to be "deeper". This Z-buffer offset is
calculated at the corners of the triangles, interpolated while
the GPU iterates along the scanlines, and sometimes the offset is
not enough to cause the back-side to be "deeper" than the front
side. Is this Z-offset trick fully driver-side so I should
complain to the nouveau guys, or is this a: "an offset of 1
guarantees it will be deeper()" that is somehow a constant
inside the openscad 3D code? Roger. () That's wrong as soon as
interpolation starts happening.
On Fri, 2026-06-12 at 12:48 -0600, Glenn Butcher via Discuss wrote:
> Almost, still need it to temporarily prepend # to subtractors in
> difference() operations, so I can see them to scooch them around.
> On 6/12/2026 11:56 AM, Cory Cross via Discuss wrote:
As do I, but for more than difference() operations.
When I am modifying an existing STL, I use # and z-fighting to find the
exact measurements of holes, heights of surfaces where render->measure
is impractical, etc.
I also use % to line up connecting structures when working on something
that needs to fit together.
> > Manifold is so fast now, can you just live without using Preview?
> >
> >
> > On June 12, 2026 5:34:52 AM PDT, Rogier Wolff via Discuss
> > <discuss@lists.openscad.org> wrote:
> >
> > > Ubuntu hard-dropped support for my graphics driver (NVIDIA). So
> > > as we're now 4 years further, I was hoping the open source
> > > version would've matured to the level to be usable. I remember
> > > trying it 4 years ago, finding it unusable for some reason and
> > > then switching to "nvidia" without any further problems.... Well
> > > now trying nouveau again... openscad shows the classic Z-fighting
> > > that we all recognize when objects coincide. e.g. difference () {
> > > cube (40); cube (20); } but now for all planes. In the "z-
> > > fight.png" screenshot I've turned the above so you can see a
> > > fully non-transparent (minus about 100 pixels) side, a fully
> > > shimmered side, and a half-open side. At this orientation. I
> > > don't get the shimmering on the sides that normally don't
> > > shimmer. On this object, the "no shimmering expected" faces don't
> > > do it that often. Only on very rare orientations. WIth my real
> > > model that I'm working on, it is about about 50% of the faces
> > > that get hit on every possible orientation. See z-fight2.png for
> > > where the whole bottom surface is partly transparent. With some
> > > back-and-forth with an AI, it seems that openscad is drawing both
> > > the front and back faces of objects, with the back face making
> > > the pixels transparent when they get drawn. But they shouldn't be
> > > drawn because they need to be "deeper". This Z-buffer offset is
> > > calculated at the corners of the triangles, interpolated while
> > > the GPU iterates along the scanlines, and sometimes the offset is
> > > not enough to cause the back-side to be "deeper" than the front
> > > side. Is this Z-offset trick fully driver-side so I should
> > > complain to the nouveau guys, or is this a: "an offset of 1
> > > guarantees it will be deeper(*)" that is somehow a constant
> > > inside the openscad 3D code? Roger. (*) That's wrong as soon as
> > > interpolation starts happening.
> > >
> >
> >
> > _______________________________________________
> > 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
RD
Revar Desmera
Sat, Jun 13, 2026 5:47 AM
My experiments suggest Manifold is generally faster than Preview. I don’t know if this is always the case though. Just usually the case.
-Revar
On Jun 12, 2026, at 1:03 PM, larry via Discuss discuss@lists.openscad.org wrote:
On Fri, 2026-06-12 at 12:48 -0600, Glenn Butcher via Discuss wrote:
Almost, still need it to temporarily prepend # to subtractors in
difference() operations, so I can see them to scooch them around.
On 6/12/2026 11:56 AM, Cory Cross via Discuss wrote:
As do I, but for more than difference() operations.
When I am modifying an existing STL, I use # and z-fighting to find the
exact measurements of holes, heights of surfaces where render->measure
is impractical, etc.
I also use % to line up connecting structures when working on something
that needs to fit together.
Manifold is so fast now, can you just live without using Preview?
On June 12, 2026 5:34:52 AM PDT, Rogier Wolff via Discuss
discuss@lists.openscad.org wrote:
Ubuntu hard-dropped support for my graphics driver (NVIDIA). So
as we're now 4 years further, I was hoping the open source
version would've matured to the level to be usable. I remember
trying it 4 years ago, finding it unusable for some reason and
then switching to "nvidia" without any further problems.... Well
now trying nouveau again... openscad shows the classic Z-fighting
that we all recognize when objects coincide. e.g. difference () {
cube (40); cube (20); } but now for all planes. In the "z-
fight.png" screenshot I've turned the above so you can see a
fully non-transparent (minus about 100 pixels) side, a fully
shimmered side, and a half-open side. At this orientation. I
don't get the shimmering on the sides that normally don't
shimmer. On this object, the "no shimmering expected" faces don't
do it that often. Only on very rare orientations. WIth my real
model that I'm working on, it is about about 50% of the faces
that get hit on every possible orientation. See z-fight2.png for
where the whole bottom surface is partly transparent. With some
back-and-forth with an AI, it seems that openscad is drawing both
the front and back faces of objects, with the back face making
the pixels transparent when they get drawn. But they shouldn't be
drawn because they need to be "deeper". This Z-buffer offset is
calculated at the corners of the triangles, interpolated while
the GPU iterates along the scanlines, and sometimes the offset is
not enough to cause the back-side to be "deeper" than the front
side. Is this Z-offset trick fully driver-side so I should
complain to the nouveau guys, or is this a: "an offset of 1
guarantees it will be deeper()" that is somehow a constant
inside the openscad 3D code? Roger. () That's wrong as soon as
interpolation starts happening.
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 to discuss-leave@lists.openscad.org
My experiments suggest Manifold is generally faster than Preview. I don’t know if this is always the case though. Just usually the case.
-Revar
> On Jun 12, 2026, at 1:03 PM, larry via Discuss <discuss@lists.openscad.org> wrote:
>
> On Fri, 2026-06-12 at 12:48 -0600, Glenn Butcher via Discuss wrote:
>> Almost, still need it to temporarily prepend # to subtractors in
>> difference() operations, so I can see them to scooch them around.
>> On 6/12/2026 11:56 AM, Cory Cross via Discuss wrote:
>
> As do I, but for more than difference() operations.
> When I am modifying an existing STL, I use # and z-fighting to find the
> exact measurements of holes, heights of surfaces where render->measure
> is impractical, etc.
>
> I also use % to line up connecting structures when working on something
> that needs to fit together.
>
>>> Manifold is so fast now, can you just live without using Preview?
>>>
>>>
>>> On June 12, 2026 5:34:52 AM PDT, Rogier Wolff via Discuss
>>> <discuss@lists.openscad.org> wrote:
>>>
>>>> Ubuntu hard-dropped support for my graphics driver (NVIDIA). So
>>>> as we're now 4 years further, I was hoping the open source
>>>> version would've matured to the level to be usable. I remember
>>>> trying it 4 years ago, finding it unusable for some reason and
>>>> then switching to "nvidia" without any further problems.... Well
>>>> now trying nouveau again... openscad shows the classic Z-fighting
>>>> that we all recognize when objects coincide. e.g. difference () {
>>>> cube (40); cube (20); } but now for all planes. In the "z-
>>>> fight.png" screenshot I've turned the above so you can see a
>>>> fully non-transparent (minus about 100 pixels) side, a fully
>>>> shimmered side, and a half-open side. At this orientation. I
>>>> don't get the shimmering on the sides that normally don't
>>>> shimmer. On this object, the "no shimmering expected" faces don't
>>>> do it that often. Only on very rare orientations. WIth my real
>>>> model that I'm working on, it is about about 50% of the faces
>>>> that get hit on every possible orientation. See z-fight2.png for
>>>> where the whole bottom surface is partly transparent. With some
>>>> back-and-forth with an AI, it seems that openscad is drawing both
>>>> the front and back faces of objects, with the back face making
>>>> the pixels transparent when they get drawn. But they shouldn't be
>>>> drawn because they need to be "deeper". This Z-buffer offset is
>>>> calculated at the corners of the triangles, interpolated while
>>>> the GPU iterates along the scanlines, and sometimes the offset is
>>>> not enough to cause the back-side to be "deeper" than the front
>>>> side. Is this Z-offset trick fully driver-side so I should
>>>> complain to the nouveau guys, or is this a: "an offset of 1
>>>> guarantees it will be deeper(*)" that is somehow a constant
>>>> inside the openscad 3D code? Roger. (*) That's wrong as soon as
>>>> interpolation starts happening.
>>>>
>>>
>>>
>>> _______________________________________________
>>> 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 to discuss-leave@lists.openscad.org
RW
Raymond West
Sat, Jun 13, 2026 9:56 AM
With changing the view angle, I can momentarily get the z fighting
over the whole base of the large cube, I can't get it on the whole large
sides, but provided it is shown somewhere, that is a good thing. z
fighting is important, since. it shows the ambiguity in the design. The
f6 render 'papers over that ambiguity', f5 does not.
On 12/06/2026 13:34, Rogier Wolff via Discuss wrote:
Ubuntu hard-dropped support for my graphics driver (NVIDIA). So as
we're now 4 years further, I was hoping the open source version
would've matured to the level to be usable.
I remember trying it 4 years ago, finding it unusable for some reason
and then switching to "nvidia" without any further problems....
Well now trying nouveau again... openscad shows the classic
Z-fighting that we all recognize when objects coincide.
e.g.
difference () {
cube (40);
cube (20);
}
but now for all planes. In the "z-fight.png" screenshot I've turned
the above so you can see a fully non-transparent (minus about 100
pixels) side, a fully shimmered side, and a half-open side.
At this orientation. I don't get the shimmering on the sides that
normally don't shimmer.
On this object, the "no shimmering expected" faces don't do it that
often. Only on very rare orientations. WIth my real model that I'm
working on, it is about about 50% of the faces that get hit on every
possible orientation.
See z-fight2.png for where the whole bottom surface is partly
transparent.
With some back-and-forth with an AI, it seems that openscad is drawing
both the front and back faces of objects, with the back face making
the pixels transparent when they get drawn.
But they shouldn't be drawn because they need to be "deeper". This
Z-buffer offset is calculated at the corners of the triangles,
interpolated while the GPU iterates along the scanlines, and sometimes
the offset is not enough to cause the back-side to be "deeper" than
the front side.
Is this Z-offset trick fully driver-side so I should complain to the
nouveau guys, or is this a: "an offset of 1 guarantees it will be
deeper(*)" that is somehow a constant inside the openscad 3D code?
Roger.
(*) That's wrong as soon as interpolation starts happening.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
With changing the view angle, I can momentarily get the z fighting
over the whole base of the large cube, I can't get it on the whole large
sides, but provided it is shown somewhere, that is a good thing. z
fighting is important, since. it shows the ambiguity in the design. The
f6 render 'papers over that ambiguity', f5 does not.
On 12/06/2026 13:34, Rogier Wolff via Discuss wrote:
> Ubuntu hard-dropped support for my graphics driver (NVIDIA). So as
> we're now 4 years further, I was hoping the open source version
> would've matured to the level to be usable.
>
> I remember trying it 4 years ago, finding it unusable for some reason
> and then switching to "nvidia" without any further problems....
>
> Well now trying nouveau again... openscad shows the classic
> Z-fighting that we all recognize when objects coincide.
>
> e.g.
>
> difference () {
> cube (40);
> cube (20);
> }
>
> but now for all planes. In the "z-fight.png" screenshot I've turned
> the above so you can see a fully non-transparent (minus about 100
> pixels) side, a fully shimmered side, and a half-open side.
>
> At this orientation. I don't get the shimmering on the sides that
> normally don't shimmer.
>
> On this object, the "no shimmering expected" faces don't do it that
> often. Only on very rare orientations. WIth my real model that I'm
> working on, it is about about 50% of the faces that get hit on every
> possible orientation.
>
> See z-fight2.png for where the whole bottom surface is partly
> transparent.
>
> With some back-and-forth with an AI, it seems that openscad is drawing
> both the front and back faces of objects, with the back face making
> the pixels transparent when they get drawn.
>
> But they shouldn't be drawn because they need to be "deeper". This
> Z-buffer offset is calculated at the corners of the triangles,
> interpolated while the GPU iterates along the scanlines, and sometimes
> the offset is not enough to cause the back-side to be "deeper" than
> the front side.
>
> Is this Z-offset trick fully driver-side so I should complain to the
> nouveau guys, or is this a: "an offset of 1 guarantees it will be
> deeper(*)" that is somehow a constant inside the openscad 3D code?
>
> Roger.
>
> (*) That's wrong as soon as interpolation starts happening.
>
>
>
> _______________________________________________
> OpenSCAD mailing list
> To unsubscribe send an email to discuss-leave@lists.openscad.org
RW
Rogier Wolff
Sat, Jun 13, 2026 2:15 PM
On Fri, Jun 12, 2026 at 11:28:19AM -0600, larry via Discuss wrote:
On Fri, 2026-06-12 at 14:34 +0200, Rogier Wolff via Discuss wrote:
Ubuntu hard-dropped support for my graphics driver (NVIDIA). So as
we're now 4 years further, I was hoping the open source version
would've matured to the level to be usable.
I remember trying it 4 years ago, finding it unusable for some reason
and then switching to "nvidia" without any further problems....
Well now trying nouveau again... openscad shows the classic
Z-fighting that we all recognize when objects coincide.
e.g.
difference () {
cube (40);
cube (20);
}
Tried it on my machine, and all looks as expected, z-fighting on 1/4 of
three faces.
I'm running Ubuntu 22.04.5 LTS MATE.
My graphics card:
Advanced Micro Devices, Inc. [AMD/ATI] Cezanne (rev c9)
I'm an idiot, thinking it was only "nouveau" that mattered (that
what the thing that changed and made the difference).
Mine is:
01:00.0 VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT 730] (rev a1)
Turns out my other workstation has:
01:00.0 VGA compatible controller: NVIDIA Corporation GF119 [GeForce GT 610] (rev a1)
and has been running openscad on Nouveau fine for years.
It's the GT730 that nouveau is not happy with.
Roger.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Verl. Spiegelmakerstraat 37 2645 LZ Delfgauw, The Netherlands.
** KVK: 27239233 **
f equals m times a. When your f is steady, and your m is going down
your a** is going up. -- Chris Hadfield about flying up the space shuttle.
** 'a' for accelleration.
On Fri, Jun 12, 2026 at 11:28:19AM -0600, larry via Discuss wrote:
> On Fri, 2026-06-12 at 14:34 +0200, Rogier Wolff via Discuss wrote:
> >
> > Ubuntu hard-dropped support for my graphics driver (NVIDIA). So as
> > we're now 4 years further, I was hoping the open source version
> > would've matured to the level to be usable.
> >
> > I remember trying it 4 years ago, finding it unusable for some reason
> > and then switching to "nvidia" without any further problems....
> >
> > Well now trying nouveau again... openscad shows the classic
> > Z-fighting that we all recognize when objects coincide.
> >
> > e.g.
> >
> > difference () {
> > cube (40);
> > cube (20);
> > }
>
> Tried it on my machine, and all looks as expected, z-fighting on 1/4 of
> three faces.
> I'm running Ubuntu 22.04.5 LTS MATE.
> My graphics card:
> Advanced Micro Devices, Inc. [AMD/ATI] Cezanne (rev c9)
I'm an idiot, thinking it was only "nouveau" that mattered (that
what the thing that changed and made the difference).
Mine is:
01:00.0 VGA compatible controller: NVIDIA Corporation GK208B [GeForce GT 730] (rev a1)
Turns out my other workstation has:
01:00.0 VGA compatible controller: NVIDIA Corporation GF119 [GeForce GT 610] (rev a1)
and has been running openscad on Nouveau fine for years.
It's the GT730 that nouveau is not happy with.
Roger.
--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
** Verl. Spiegelmakerstraat 37 2645 LZ Delfgauw, The Netherlands.
** KVK: 27239233 **
f equals m times a. When your f is steady, and your m is going down
your a** is going up. -- Chris Hadfield about flying up the space shuttle.
** 'a' for accelleration.
