Manifold is so fast now, can you just live without using Preview?
Preview has a few bonusses compared to "render".
1a) colors: Surfaces that have been created by subtractign something
have a different color. This helps me find my way around my model.
1b) Colors: I can assign different colors to different objects
to make sure that I know which is which.
I use auto-preview so that to get an updated view I just hit "save"
in my (external) editor and I get a new preview.
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.
Guys, the Z-fighting on the quarter of the faces is in my example to
show "what effect I'm talking about".
The problem is that I'm seeing that on ALL faces. And sometimes to
such an extent that I think: Hey: I shouldnt' be able to see that
because it should be behind that solid bar. And then when you turn it
a bit you get the shimmering of z-fighting and you realize the surface
there was supposed to be solid all along. (and isn't supposed to be
see-through).
That said... I installed the old driver directly from NVIDIA, not
through ubuntu. This works again as expected. Apparently this GPU is
12 or 14 years old. Nobody seems interested in fixing bugs with that
old hardware. It was bought (4! years ago!) with the expectation that
it would be plenty for the little openscad work that I do. And so far
I think it is fine.
Still... I think I know where the bug is. With other cards and drivers
not having this issue, Nouveau must be mis-handling the z-depth buffer
on this cpu in some way. (e.g. thinking that dropping the lowest bit
will often not matter on a significant enough number of pixels to be
noticable. Until you explicitly expect the +1 in depth to always be
"behind" the +0 copy of an object. )
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 6/12/2026 10:47 PM, Revar Desmera via Discuss wrote:
My experiments suggest Manifold is generally faster than Preview. I don’t know if this is always the case though. Just usually the case.
Test case? My favorite high-intensity test case is the Menger Sponge,
Examples/Old/example024.scad. For me, setting n=4 and previewing is
basically instantaneous; rendering is ~3s. Moving the camera around is
then significantly slower for preview than for a rendered result, but I
assume that we are talking here about the initial run. With n=5,
preview is about 2s and render is about ... well, a lot longer; I got
impatient.
Do remember to flush caches.
But maybe different test cases have different performance profiles.
Did you try to check the "Force Goldfeather" option that can be found somewhere in the Advanced Preferences?
Apart from that, an update to OpenCSG 1.8.2 could help. That version contains a fix for an alike issue, that was confirmed on a similar configuration.
Florian
Gesendet: Samstag, 13. Juni 2026 um 16:52
Von: "Rogier Wolff via Discuss" <discuss@lists.openscad.org>
An: "OpenSCAD general discussion Mailing-list" <discuss@lists.openscad.org>
CC: "Rogier Wolff" <R.E.Wolff@BitWizard.nl>
Betreff: [OpenSCAD] Re: Z-buffer fighting in normal preview on Nouveau.
Guys, the Z-fighting on the quarter of the faces is in my example to
show "what effect I'm talking about".
The problem is that I'm seeing that on ALL faces. And sometimes to
such an extent that I think: Hey: I shouldnt' be able to see that
because it should be behind that solid bar. And then when you turn it
a bit you get the shimmering of z-fighting and you realize the surface
there was supposed to be solid all along. (and isn't supposed to be
see-through).
That said... I installed the old driver directly from NVIDIA, not
through ubuntu. This works again as expected. Apparently this GPU is
12 or 14 years old. Nobody seems interested in fixing bugs with that
old hardware. It was bought (4! years ago!) with the expectation that
it would be plenty for the little openscad work that I do. And so far
I think it is fine.
Still... I think I know where the bug is. With other cards and drivers
not having this issue, Nouveau must be mis-handling the z-depth buffer
on this cpu in some way. (e.g. thinking that dropping the lowest bit
will often not matter on a significant enough number of pixels to be
noticable. Until you explicitly expect the +1 in depth to always be
"behind" the +0 copy of an object. )
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.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
Thanks Florian- I have been chasing z-fighting in a particular project of mine for a while, and nothing worked- enabling goldfeather has fixed it.
On 16/6/26 05:27, Florian Kirsch via Discuss wrote:
Did you try to check the "Force Goldfeather" option that can be found somewhere in the Advanced Preferences?
Apart from that, an update to OpenCSG 1.8.2 could help. That version contains a fix for an alike issue, that was confirmed on a similar configuration.
Florian
OpenSCAD mailing list
To unsubscribe send an email todiscuss-leave@lists.openscad.org
A baby can be defined as an ego with a noise at one end and a smell at the other.
Your job as parents is to teach them to control all three.
My job as a grandad is to tell you how you are doing it all wrong!