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

nop head nop.head at gmail.com
Thu Nov 14 02:47:11 EST 2019

> Just to be clear, the 2-manifold property doesn't say anything about
whether a mesh is self intersecting or not.

Sorry I thought self intersection is not manifold because it creates zero
thickness sections. If it is then all I have said is correct if you change
non-manifold to non-manifold and not self intersecting.

>This problem is fixable for 3MF export. All we need to do is preserve the
"topology information" (the vertex table) when we convert CGAL data to 3MF

It isn't only during STL export that this goes wrong. A lot of OpenSCAD
operations use a PolySet representation, which is a polygon soup of
doubles. Whenever it converts from CGAL rationals to PolySet doubles is can
cause self intersections and degenerate triangles. Any of these will give a
CGAL exception if they get converted back to NefPolyhedra to do another CSG
operation. This is the source of endless CGAL exceptions that people
report. To avoid them the geometry has be manifold and free of
self-intersections even after its vertices are snapped to a grid and or
truncated. So you have to avoid close vertices as well.

So in a lot of cases there is no "topology information" to preserve.
Whenever you do F6 and don't get the "simple:" report then the final result
is a PolySet, but even if the final result is a CGAL NefPolyhedron PolySets
might have been use for intermediate results.

So I don't think the problem is fixable for 3MF export without changing
PolySet to contain topology and also fix all the places that truncate or
snap to grid to fix the topology, which is hard. If one only needs to
design manifold geometry without self intersections then PolySets don't
need to store topology but the truncation problem sill needs to be fixed.

On Thu, 14 Nov 2019 at 03:41, Jordan Brown <openscad at jordan.maileater.net>

> 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 add them...
> but I shouldn't have had to add them.
> 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 OpenSCAD and the slicers.
> 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.
> _______________________________________________
> OpenSCAD mailing list
> Discuss at lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20191114/31f63851/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pfacbkllencjpkok.png
Type: image/png
Size: 20066 bytes
Desc: not available
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20191114/31f63851/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ijlacojjhnanjecj.png
Type: image/png
Size: 492355 bytes
Desc: not available
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20191114/31f63851/attachment-0001.png>

More information about the Discuss mailing list