[OpenSCAD] Discuss manifoldness, co-incident faces edges etc
nop head
nop.head at gmail.com
Thu Nov 14 06:56:41 EST 2019
Also polygon soups can describe self intersecting geometry in general. What
they can't do is handle meshes with shared edges. These are like
singularities where the shape goes from 3 dimensions to 2. As long as each
edge of a facet has a unique partner running in the opposite direction you
can stitch them all together in an unambiguous way. However I don't think
CGAL allows self intersections even without shared edges.
On Thu, 14 Nov 2019 at 07:47, nop head <nop.head at gmail.com> wrote:
> > 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
> data.
>
> 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>
> wrote:
>
>> 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/27efc44a/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/27efc44a/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/27efc44a/attachment-0001.png>
More information about the Discuss
mailing list