On 2016-02-04 06:54, Triffid Hunter wrote:

No, it does not.

An example of non-manifold topology is where a topological edge is
shared by more than 2 faces.
http://docs.mcneel.com/rhino/5/help/en-us/popup_moreinformation/non-manifold_edges.htm

It is not ambiguous, and in many cases a desired feature. This kind of
non-manifold topology is much used in ship design when designing FEM
models with shell elements. Often, non-manifold topology is perfectly
acceptable and is not ambiguous in any way. CAD systems like e.g. ACIS (
https://en.wikipedia.org/wiki/ACIS ) have no issues representing
non-manifold topology.

In the special case of 3d solid topological models, a non-manifold face
is a face internal to the body, it has material on both sides and does
not describe the external surface of the solid body. That does not mean
it is topologically ambiguous. Such faces may be and are used for
subdivision, for example to guide 3d solid meshing (solid FEM models).
Whether such non-manifold topological entities are  desirable or not
depends on the application area, but it is not topologically ambiguous.

It is only when the topological description is non-existent things like
this become a problem.

Carsten Arnholm

OpenScad doesn't handle non-manifold topology. It can only do boolean ops
on manifold solids. Therefore writing them to STL and reimporting them does
not prevent you doing boolean ops. If it is manifold then it will re-import
correctly. If it isn't then you could never do boolean ops on it anyway.

When I attempt to make a polygon with an infinitely thin crack it just gets
ignored. The only reason you can ever get a non-manifold object in OpenScad
is because it doesn't validate polyhedron and import data, plus a bug I
think it has when it snaps vertices to a grid without preserving topology.
I think this shows it doesn't hold any more topological information
internally that could be lost writing to STL. Objects are represented by
their boundary mesh and it has to be manifold. Since physical objects in
the real world are manifold that isn't a limitation for a solid modeller.

This is no doubt not the same with ACIS, but that isn't what we are
discussing on this list.

Since I have never claimed STL files can represent non-manifold geometry I
think it is you that is presenting a straw man argument.

On 4 February 2016 at 07:13, arnholm@arnholm.org wrote:

"a non-manifold face is a face internal to the body, it has material on
both sides and does not describe the external surface of the solid body."

The ability to partition a solid into a collection of disjoint subvolumes
with shared faces is also useful in OpenSCAD; it's not just a ship
design/ACIS thing.

One obvious example is 3D printing of multi-material/multi-colour objects.
There have been a number of discussions about how to support this in
OpenSCAD. Internally, the volumes for each colour/material need to be kept
separate and labeled. To export such a model, you either need to export
multiple STL files (one per material/colour), or you need to export an AMF
file with distinct volume elements for each colour/material. In no case
should any of the individual volumes that we track internally or export
contain non-manifold faces.

This situation can arise in feature request #1562, which requests a
convex_decomposition() operator. The result of this operator is a group of
solids which share faces between them. Each group element is a convex
polyhedron, which is manifold. This feature isn't useful unless we get rid
of the implicit union that would otherwise occur when passing the results
of convex_decomposition() to another module: see issue #350. But, issue
#350 also eliminates the top level implicit union that occurs before
exporting an STL file. If we get rid of top level implicit union, and the
top level element in a script is a call to convex_decomposition() on
non-convex input, then we can't meaningfully export to STL. There is a
manifoldness check prior to STL export which should report this problem
(issue #1215). Exporting the same object to AMF can be supported, because
we can put each convex polyhedron into a separate volume.

In summary, OpenSCAD should support models that contain disjoint subvolumes
with shared faces. There are features we need to add and bugs/design flaws
we need to fix before this support is complete.

On 4 February 2016 at 02:13, arnholm@arnholm.org wrote:

On 4 February 2016 at 15:17, doug moen doug@moens.org wrote:

Where does that come from?

There are lots of non-manifold problems a face can have, not just internal
faces. There are holes, singularities and self intersection.

A more accurate statement is "a face internal to the body makes it
non-manifold".

Yes and you can do that already if you export them into separate STL files.

True. The top level union is required when exporting to STL if the objects
touch, or overlap.

But how is that meaningful? An object broken into arbitrary convex lumps
doesn't seem useful as an end result to me. More useful is simply tagging a
branch of the tree to be a particular material and then it can be an
arbitrary shape not just convex.

Disjoint subvolumes is another straw man argument. Your cracked plate
example is not a disjoint subvolume. Nobody said we could put disjoint
subvolumes in an STL file. We can and do put them in separate STL files
though.

doug moen brings another important aspect to this discussion: " the top
level implicit union that occurs before exporting an STL file". STL is
intended to represent one object only presumably a 2-manifold and this is a
serious limitation of STL format. I agree that, excluding numerical
approximation issues, STL allows the recovering of the missing topological
information if and only if the geometrical embedding of it is a manifold.
As I showed before by examples, we can represent several non-disjoint
manifolds in STL as far as they do not have common vertices. But that is
very restrictive.

I would like to represent not only one body in OSCAD. I would like to
represent a set of distinct (not necessarily disjoint) objects. One simple
application of that, besides the ones Arholm brought, is an animation of,
say, a ball bouncing in a billiard table. If I define a fixed table and a
ball on it, as their union is not a 2-manifold, I may have problems. Two
gears may have contact. In the real world, objects have contact.

Best than just eliminating the top level implicit union would be to have
another operator: the set (or aggregate) operator. The set operator would
collect a set of bodies preserving each one as a separated entity. If you
union the set, then they become one (possibly manifold) body only but
before that the set may not represent a manifold. Its bodies may not even
be disjoint. May be, I don't know, there is no non-manifold objects in the
world but the world itself is not a manifold.

If we go in that way, STL should be abandoned.

2016-02-04 13:17 GMT-02:00 doug moen doug@moens.org:

nop head:

That comes from Carsten, I was replying to his message. See the quoted
message below the body of my post.

There are lots of non-manifold problems a face can have, not just internal

Okay. To be clear, in my message I was only addressing the specific case of
disjoint solids sharing a face. I wasn't making any general claims about
non-manifold models. Breaking the problem of non-manifold models down into
different cases makes it easier to think about how OpenSCAD should deal
with each case.

Obviously. But there are things we can do to make this more convenient, as
touched on in my message, and as currently being discussed in other forum
threads and github issues. My point is that this is something people need
to do, and OpenSCAD could support it better.

It wouldn't be useful for 3D printing, but people use OpenSCAD in a variety
of ways. Here's one use case: multiple users want better support for
exporting an intermediate result to a file, then loading that file back
into OpenSCAD for further processing. (Can't find the issue# right now.) We
should support this capability in the general case, not just those cases
where the intermediate result happens to be representable by a single STL
file.

In summary, OpenSCAD should support models that contain disjoint subvolumes

Why are you accusing me of making a straw man argument? This is my first
substantive post to this thread. I said nothing about cracked plates.
Nowhere in my post did I claim that we should put disjoint subvolumes in an
STL file. Although people commonly do put disjoint subvolumes into a single
STL file -- if the individual volumes are not touching or overlapping,
there doesn't seem to be a problem for 3D printing.

Sorry Doug, for some reason I thought you were Carsten.

On 4 February 2016 at 16:39, doug moen doug@moens.org wrote:

On 04. feb. 2016 16:17, doug moen wrote:

Indeed, this is very true, I was just referring to my experience. Your
example below is even better.

Yes, once you mention it is certainly the obvious example, very good
point! This illustrates that a non-manifold face internal to the body is
not just not ambiguous, it is essential in some cases. If used properly
non-manifold  topology actually solves known and already stated problems.

A non-manifold face has material on both sides and your example adds to
that by saying the two materials need not be the same. Then the
non-manifold face has direct physical significance also in 3d printing.

"Models that contain disjoint subvolumes with shared faces" is another
way of saying explicit topology and that the topology sometimes needs to
be non-manifold. I agree.

Obviously you can't do that with export to STL. As you say, AMF (or
another format with similar features) would be able to represent meshes
generated from such models and it looks like a good way to support
multi-material printing.

Great post.

Carsten Arnholm

nop head said: "Sorry Doug, for some reason I thought you were Carsten."

Yes, but I was agreeing with Carsten's post. Just that one post, where he
was arguing for the utility of models containing disjoint subvolumes with
shared faces. I agreed that OpenSCAD should support this situation. As I
recall, Carsten previously argued that this kind of model can't be
represented by a (single) STL file, but that you could use AMF. I said the
same thing, although I restricted my argument to the special case of
disjoint subvolumes sharing faces.

Maybe you should also apologize to Carsten? I don't like the animosity you
two have been showing each other in this thread. We need to keep the forum
civil.

On 4 February 2016 at 11:43, nop head nop.head@gmail.com wrote:

Well as far as I have been concerned I have been putting forward rational
and civil arguments to disprove Cartsten's assertion that you can't save
OpenScad geometry in an STL file, reimport and do boolean ops on it. I
tried to show his two examples had flaws in them and produced counter
examples. He accused me of having a straw man argument. I have no idea why.

Then we move onto saying you can't save non-manifold objects in an STL.
That is a classic straw man argument. Nobody said you can store a
non-manifold object in an STL file and OpenScad can't currently process
non-manifold objects.

On 4 February 2016 at 17:05, doug moen doug@moens.org wrote: