On 12/6/2024 4:31 AM, L Michael Fraser wrote:

There is indeed a well-known generic problem:  the previewer gets into
trouble in a couple of scenarios where you have two objects that share
the same face and conflict on how that face should be shown.  This is
called "Z-fighting".  It most commonly occurs when you difference away
an object with a face that is in the same place as the face of the
object it's being removed from.  There's an FAQ entry at
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/FAQ#What_are_those_strange_flickering_artifacts_in_the_preview?

In your model, before my changes, this manifests along the front
(smallest Y) edge, where the negative larger tick marks exactly line up
with the front of the ruler.

This exact behavior is well-known.  The workaround is to ensure that the
negative object extends at least a little outside the thing it is being
subtracted from.  Tiny values work, but I usually use 1 because it's
easy to type and it's very rare that I would be adding a constant 1 or
translating by a constant 1.  Some people prefer to use a variable named
"epsilon" or "eps".

Thus my first change was to move that square one unit in the -Y
direction and make it one unit longer so that the other end is in the
same place.

        xcopies(mk4,l=len-4, sp=[0,-6,0]) fwd(1) square([3,1+3]) ;

That got rid of the Z-fighting at the front:

With some work, it's possible to come up with cases where this
workaround breaks the model, but generally it's safe.  For it to be a
problem, you'd have to have some more "positive" volume that's separated
from what you're trying to remove, but closer than the "epsilon".  In
the unlikely event that that's a problem, make the epsilon smaller. 
(Example on request.)

From certain angles, you'll see another well-known preview artifact.
Ref
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/FAQ#Why_are_some_parts_(e.g._holes)_of_the_model_not_rendered_correctly?

This one is a "convexity" artifact.  For some reason that I have never
bothered to understand, the previewer wants to know how many times a
line can cross into and out of the model.  For many operations it can
figure this out on its own, but when you linear-extrude a concave shape,
or when you build your own polyhedron, or a few other cases, it has no
idea and you need to tell it.  The theoretical number for this model is
somewhere around 64, I think, drawing a line parallel to the X axis
through the small tick marks.  However, I can't find an angle where I
can see it there.  Even along the thick tick marks, the theoretical
number is around 16, but it's hard to get an angle where it's more than
about 5.  This is purely a preview artifact; the workaround is to
recognize the symptom, recognize constructs that cause it, and set
"convexity=" some number, in the linear_extrude in this case.  I usually
use 10, because that's almost always enough.  Making it larger has a
very slight performance cost when viewing the model, but it's hard to
get cases where the cost is visible.

But none of those usually cause rendering problems; they are all preview
issues.  Theoretically Z-fighting could be tied to objects that are not
quite aligned, that yield extremely thin shapes or gaps, but that's
very unusual.  (I think the issue below may be the first time I've seen it.)

Now we're out of the known stuff, and into something weird.  There is a
very odd artifact; some of the large tick marks still have something odd
going on at their back ends...

This looks Escher-esque; the two cutouts at the left appear to have
solid behind them with the top at the same level as the yellow parts,
but then when you follow that to the right it's back down at the cutout
level.

TL;DR:  looks like a bug in the 2D subsystem.  Work around it by
extending the square further into +Y.

Turning around to a different angle makes it a little clearer:

There seems to be a microscopically thin wall between the tick-mark
cutouts and the large cutout.

Extending the square a bit more +Y makes the problem go away.

Putting a ! in front of the union() to get just the 2D object, and
zooming way, way in, shows a very small dividing line.  I can only see
it at some angles, and only in perspective mode.

But it shows up clearly in a render of the 2D object:

The render shows that it is there on most, but not all, of the tick marks:

The previewer shows it on fewer, but that could just be because it was
hard to see even on the ones it did show.

This sure seems like a bug in the 2D subsystem.  I would have guessed
that it was a floating point accuracy problem, but I'm able to reproduce
it using only integers so that's unlikely.  I dumped the CSG tree for
this figure, chopped out all of the noise, turned the multmatrix calls
back into translate() calls, and simplified as much as I could.

This is the simplest variant I have come up with that demonstrates the
problem.  It demonstrates it only on one square.

square([50, 3]);
translate([0, -3])
square(3);
translate([6, -3])
square(3);
translate([12, -6])
square(3);
translate([19, -6])
square(3);
translate([25, -6])
square(3);
translate([31,-6])
square(3);
translate([38,-6])
square(3);
translate([44, -3])  // Note this one is -3
square(3);
translate([50, -6])
square(3);
translate([57,-6])
square(3);
translate([63,-6])
square(3);
translate([69,-6])
square(3);
translate([76, -6])
square(3);
translate([82,-6])
square(3);
translate([88,-6])
square(3);
translate([95,-6])
square(3);

Removing any of the squares makes the problem go away.  Moving any of
the three "attached" squares away from the top makes it go away.  Moving
the "loose" squares around does not seem to affect the problem.

I've filed issue #5478 https://github.com/openscad/openscad/issues/5478.

Net:  two well-known artifacts, one really weird and
difficult-to-trigger bug.

Nice find and explanation.  I wonder if OpenSCAD could detect z-fighting or
a possible concavity issue, and post a warning with a link to the relevant
docs.

On Fri, Dec 6, 2024 at 7:09 PM Jordan Brown via Discuss <
discuss@lists.openscad.org> wrote:

On 12/6/2024 6:15 PM, John David wrote:

That would be good, but I don't know how possible it would be.

At preview time, strange as it may seem, OpenSCAD has no idea where all
the faces are and how they relate to one another.  It just mixes in a
magic potion and throws them at the graphics card, and the graphics card
figures out what's in front, including subtraction and intersection.

A render might be able to detect coincident faces.  I don't know how
hard that would be.

I suspect that calculating convexity is very hard even on render,
because you have to consider all possible paths through the object.

I think we should set the default convexity to 10 or so, because that
addresses almost all cases at very little cost, or provide a global way
to set it, but so far that idea has been shot down in favor of nebulous
automatic calculation schemes.  I think this is a case of better being
the enemy of good enough.

On 07/12/2024 00:08, Jordan Brown via Discuss wrote:

If  you want to see if a point is inside or outside of an object, then
you can draw a straight line in any direction, and if it crosses a
boundary an odd number of times, then the point is inside the object.
There are about eight special cases, where it runs along a boundary, or
hits a point of inflexion, etc. I would guess it is something to do with
that.

On 12/7/2024 3:35 AM, Raymond West via Discuss wrote:

I'm pretty sure that the previewer doesn't do any ray tracing.  For
unions, I think I understand how it works:  it throws triangles at the
graphics subsystem, and for each pixel the graphics subsystem records
the color and Z-depth (that is, how far into the screen).  When you
throw a second triangle in the same place, it either overwrites the
earlier pixel if the new one is closer, or ignores it if the new one is
further away.

Difference does something more magical, but I believe it's still the
same basic mechanism:  throw triangles at the graphics subsystem, and
decide on a pixel-by-pixel basis whether to display or ignore them.

But I'm pretty sure that the previewer doesn't know nor care whether a
particular point is inside the object.  It, per se, doesn't even know
what's in front of what.