<div dir="ltr">Regardless of file format limitations, non manifold objects cannot exist in reality, so I think it should be an error to make one and users should be educated.<div><br></div><div>Two cubes cannot share a zero width edge. They either overlap by at least one atom or are separate. It is no coincidence that STL can represents all physically realisable objects.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 11 Nov 2019 at 04:17, Doug Moen <<a href="mailto:doug@moens.org">doug@moens.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u><div><div>On Sun, Nov 10, 2019, at 2:47 AM, Jordan Brown wrote:<br></div><blockquote type="cite" id="gmail-m_-2312581535418641244qt"><div>If I had to pick a single set of things that I'd like to see
    improvement on, it would be the handling of what are currently
    considered "errors" in the model - non-2-manifolds[*], ...  Those are all easy traps for the novice to
    fall into and not immediately obvious.<br></div><div> <br></div><div>There's no intuitive reason why this model is a problem:<br></div><div> <br></div><blockquote><pre>cube(1);
translate([1,1,0]) cube(1);<br></pre></blockquote></blockquote><div><br></div><div>The specific problem being referenced here is that if you have two polyhedra that don't intersect (with a non-zero intersection volume), but they touch at a vertex or touch at an edge, then you can't represent that in an STL file, because the polygon mesh is not 2-manifold.<br></div><div><br></div><div>This restriction is a problem for users, because it means that shapes are not closed under union. You can take two valid shapes (cubes in the above example), union them together, and the result is not considered valid.<br></div><div><br></div><div>This limitation really only exists because of the STL file format.<br></div><div><br></div><div>The limitation doesn't exist in CGAL, which is the library used by OpenSCAD to compute unions, intersections and differences. CGAL provides a Nef Polyhedron data structure which is closed under the union operation, and which can represent the union of two cubes shown above.<br></div><div><br></div><div>This limitation doesn't exist in the 3MF file format, which explicitly supports these kinds of models.<br></div><div><br></div><div>This statement might be surprising or controversial. The way it works is: 3MF uses a different mesh representation than STL. In 3MF, there is an array of points, each point has a numeric ID. Then there is a separate array of triangles: each triangle is represented by 3 point IDs, which are indexes into the point array. In a "non-manifold Nef Polyhedron" (like the 2 cubes in the example), there are 2 or more disjoint volumes that touch at one or more vertices. These "shared vertices" must be duplicated in the 3MF points array, so that each disjoint volume refers to the same shared vertices using distinct point IDs. Only then do you have a valid 3MF representation. The 3MF standard discusses this in section 4.1.3: "The producer SHOULD NOT include duplicate vertices unless coalescing duplicates would create non-manifold edges."<br></div><div><br></div><div>As far as I can tell, CGAL provides the necessary APIs that could be used to export a non-manifold Nef Polyhedron to a 3MF file, without creating an invalid 3MF file. But the current 3MF export code isn't written that way, and doesn't support this case. So the problem is fixable, it's not PhD thesis level of difficulty.<br></div><div><br></div><div><br></div><blockquote type="cite" id="gmail-m_-2312581535418641244qt"><p>Beyond that, I'd like to see better integration between CAD
      programs like OpenSCAD and slicers.  I'd like you to be able to
      change a design in OpenSCAD and "refresh" the slicer so that the
      old model is replaced by the new.  Some aspects of that are easy: 
      retaining translation, rotation, and scaling; maybe retaining
      print settings.  Some are harder, like arranging that the model is
      on the print bed even when its lowest point moved up or down. 
      Some are probably nearly impossible, like retaining support
      designs.  Probably this is mostly on the slicer, but maybe not.<br></p><p>Along the same lines of integration with slicers, it would be
      nice to be able to incorporate slicer controls into the model
      definition, so that you don't have to have both the .scad file and
      a separate file that sets up the slicer.  Perhaps, for instance,
      there could be annotations that you could add in OpenSCAD that the
      slicer would read.  Start with rotation, translation, and scaling,
      so that you can be looking at the object in its "use" orientation
      in OpenSCAD, but it would automatically adjust to its "print"
      orientation in the slicer.  Continue with, e.g., slice thickness. 
      This would address some of the "refresh" functionality desired
      above.  People with mills instead of 3D printers might be
      interested in similar functionality to allow cut descriptions to
      be embedded in the model design.<br></p></blockquote><div><br></div><div>The 3MF file format can hold slicer settings. I haven't researched this, but something of what you ask for might be possible with 3MF.<br></div><div><br></div></div>_______________________________________________<br>
OpenSCAD mailing list<br>
<a href="mailto:Discuss@lists.openscad.org" target="_blank">Discuss@lists.openscad.org</a><br>
<a href="http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org" rel="noreferrer" target="_blank">http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org</a><br>
</blockquote></div>