On Wed, Nov 13, 2019, at 3:34 AM, nop head wrote:

I'm not asking for OpenSCAD to support non-manifold shapes, I'm asking for OpenSCAD to more fully support the 3MF file format. The practical use is the ability to download an arbitrary 3MF file from the internet, transform it in some way, export back to 3MF, and then print the results. As long as the 3MF file contains a valid mesh, as defined by the 3MF standard, I expect this to work.

No, this is a straw man argument. I'm asking for better 3MF support. If I send a valid 3MF file to a slicer, then I expect it to print the model without any problem. The 3MF standard provides unambiguous instructions on how to slice a valid 3MF mesh.

This is why you should embrace the 3MF standard. It contains rules defining what is and is not a valid mesh. There is open source code for rapidly validating a 3MF mesh. Given a valid mesh, there are rules that define exactly how the mesh should be sliced. This means that model files can be portable between slicers. This also means that we can test a slicer or 3D modelling tool for conformance to the 3MF standard, and report a bug if it misinterprets a valid model. Unambiguous rules, validation, and model portability are a big selling point of 3MF.

OpenSCAD to more fully support the 3MF file format.

Isn't that a self contradictory statement? If 3MF supports non-manifold
shapes then OpenSCAD will need to support them in order to read them.
OpenSCAD only supports manifolds for the exact same reason STL files only
support them. Its mesh representation is a polygon soup.

On Wed, 13 Nov 2019 at 11:40, Doug Moen doug@moens.org wrote:

STL certainly supports non-manifold shapes, it has pretty much no validity
checking at all... The problem is they don't tend to be very meaningful 😊

On Wed, 13 Nov 2019, 07:23 nop head, nop.head@gmail.com wrote:

Well you could say it supports them write only. It only works as a
non-lossy representation when the contents are manifold. The reason it has
lasted so long as a format for 3D printing is that is all that is needed.
It's a shame the standard didn't contain that rule.

On Wed, 13 Nov 2019 at 12:41, A. Craig West acraigwest@gmail.com 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?

I think one of OpenSCAD's strengths is that it has chosen a narrow
objective & focused on fulfilling that need well. It doesn't propose to be
a Fusion or FreeCAD replacement; it's a parametric, CSG design tool, with
some GUI sugar to assist in that.

I don't totally understand what it is people want this for, but I think
it's important to ask; is this the mission of OpenSCAD? Or is this
something for another project?

Best,
Max

On Wed, Nov 13, 2019, 7:00 AM nop head nop.head@gmail.com wrote:

On Wed, Nov 13, 2019 at 2:50 AM A. Craig West acraigwest@gmail.com wrote:

I suspect you underestimate the age of people on this list, but either
way Pull Requests are welcome if you have any concrete solutions to
the problems involved.

nop head nop.head@gmail.com wrote:

It is not. I see contradiction in your arguments favoring STL file format
against 3MF when this last format is able to enforce the 2-manifold
condition. It is insane to me that a CAD program has to discard all
topological information present in its internal structures to write a STL
file to be consumed by other programs that will have to guess the topology
from an unstructured pool of triangles in order to do their job. If
something is representable by a 3MF file but not admissible by the reader
it can just reject the file as OpenSCAD does with malformed (meaning non
2-manifold) STL files. Reading and writing a well structured file format
should be not only easier but safer.

The reason it has lasted so long as a format for 3D printing is that is all

It has lasted so long because it was the first (1987) and unique file
format available at the beginning of rapid prototyping and not by its
merits. Other formats, like  3MF (2015), AMF (2011), are much more recent.
It is a shame that STL is still in use.

There is no guesswork needed to read an STL if the geometry it contains is
manifold. 3MF and AMF presumably can represent non-manifold geometry
unambiguously but I don't see that as an advantage for 3D printing. They
have other advantages, like being able to handle multiple materials.
Nothing compelling enough for me to scrap my 3D tool chain because
multiple STL files can be used to represent multiple materials. I still
slice everything with Skeinforge!

If STL files had a rule to say the geometry they contained has to be
manifold and writers and readers enforced it there would not be a problem.

OpenSCAD doesn't reject bad STLs. It just feeds the soup to CGAL and CGAL
barfs if it is not manifold and produces and incomprehensible exception.
OpenSCAD might as well catch all CGAL exceptions and say the geometry has
become non-manifold. It would be a more meaningful error message.

On Wed, 13 Nov 2019 at 19:51, Ronaldo Persiano rcmpersiano@gmail.com
wrote:

On 13.11.2019 21:05, nop head wrote:

I am sorry but this is nonsensical. See below.

How many times must it be explained that STL is a polygon soup without
any topological information whatsoever, and hence any topology
(manifoldness relates to topology only) on the reader side must be
guessed? It has been stated many times already. It is a fact.

And in this process, someone takes a guess at what the topology is
supposed to be.

Carsten Arnholm

If the STL is manifold than you can find each edge is shared by exactly two
triangles so you can reconstruct the mesh without any change in topology.
There is no explicit topology but it is preserved. Once read into OpenSCAD
all explicit topology is lost anyway because it uses a polygon soup itself.
Polygon soups are fine for representing a mesh until you have self
intersections or edges shared by more than two facets.

On Wed, 13 Nov 2019 at 20:34, Carsten Arnholm arnholm@arnholm.org wrote: