# [OpenSCAD] Discuss manifoldness, co-incident faces edges etc

Wed Nov 13 22:40:10 EST 2019

```On 11/13/2019 9:39 AM, Max Bond wrote:
> I think it would be helpful to enumerate the use cases for which
> nonmanifold geometry is desired/required, so we can look at that list
> and ask; is this what OpenSCAD is for? What do these things have in
> common? Would they all be served well by 3MF etc?

OK, I know I just said I'd shut up, but this is a specific question to
which I have a specific (example) answer.  This is not concocted; it's
real.  The intent is to produce something visually similar to a shingled
roof.  It basically makes a checkerboard where all of the black squares
are slightly raised.  (Because the shingle thickness is down around the
vertical resolution of the printer, trying to represent the actual slant
of the shingles wouldn't work.)

inch = 1;
foot = 12*inch;
layer=0.3;
epsilon=0.1;

module roof(w,l,t,shinglew,shinglel, shinglet) {
cube([w,l,t]);
translate([0,0,t]) {
for (iy=[0:1:floor(l/shinglel)-1]) {
for (ix=[iy%2:2:floor(w/shinglew)-1]) {
translate([ix*shinglew, iy*shinglel, 0]) cube([shinglew-epsilon, shinglel-epsilon, shinglet]);
}
}
}
}

roof(w=8*foot, l=4*foot, t=0.6*inch, shinglew=6*inch, shinglel=4*inch, shinglet=layer);

The rendering ends up with optical illusions that make the shape unclear
from most directions, but this one is pretty good:

Here's what it looks like in plastic (pardon the poor focus):

Why is this a problem?

Note that I couldn't use the obvious solution; I had to inject
"-epsilon" so that the raised rectangles wouldn't touch at the corners.
I don't remember whether I remembered to do that when I constructed it,
or if I had to run into an OpenSCAD non-manifold-ness complaint and then

And (OK, repeating myself a bit) I don't care in the slightest what the
slicer does with those intersections, whether it considers the
rectangles to have separate perimeters or not.  The corners should be
awfully close to one another, and whether that means slightly separated,
or slightly overlapping, or precisely touching is not important.

(Half of the time I say that the slicer should color *between* the
lines, which means that "square" convex corners will always be round and
the corners will not touch, and half the time I say that no matter how
thin the object is, it should still be represented in the plastic, even
if that means coloring outside the lines, and so a zero-thickness
intersection gets a single minimal extrusion across it.  Either answer
would be reasonable and understandable.)

Now, note:  I'm talking about the input 3D solids and the output
plastic.  I'm *not* talking about the mesh in the middle; that's an
implementation detail that I shouldn't have to care about.  I accept
that a "polygon soup" representation might be ambiguous.  (I'm not sure
I've seen one yet, but I'm willing to accept it on faith.)  It might
well be that solving this problem would require fundamental changes to

I had another real-project case that ran into the same problem, but it
was more complex.  Basically, it was equivalent to having an inset
square with a raised circle in it, where (to the accuracy of my
measurements) the diameter of the circle was equal to the length of the
edge of the square.  I had to fudge them a bit to get them to be different.

-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pfacbkllencjpkok.png
Type: image/png
Size: 20066 bytes
Desc: not available