[OpenSCAD] User Poll: What do you want to see from OpenSCAD development?

arnholm at arnholm.org arnholm at arnholm.org
Mon Nov 11 11:02:58 EST 2019

On 2019-11-11 05:15, Doug Moen wrote:
> On Sun, Nov 10, 2019, at 2:47 AM, Jordan Brown wrote:
>>> cube(1);
>>> translate([1,1,0]) cube(1);
> 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.

Actually, this is not correct. STL as such has no issues representing 
such a thing. STL has no shared vertices or edges at all, every vertex 
is duplicated for each triangle, and there are no explicit edges. The 
problem is not representing such a thing in STL, the problem is 
interpreting it consistently by OpenSCAD or any other program reading 

An STL file is a "polygon soup", it is simply a set of totally 
disconnected triangles with zero shared topology. Such topology must be 
guessed at by the program reading it, by comparing coordinates. This is 
totally different from most other formats such as OBJ, OFF, AMF or 3MF 
where the topology is explicitly represented.

For this reason, STL is particularly unsuitable for sharing models 
between CAD applications. A slicer program is more forgiving so that 
works better with STL.

> 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.
> This limitation really only exists because of the STL file format.

No, this is not true. STL has no issues representing this case or any 
other case, it does not care about non-manifoldness. It is not STL that 
complains in this case, this issue is totally unrelated to STL.

The warning that the model is not 2-manifold can be considered false 
alarm in some cases, whether it is a problem or not depends on the 
intended use of the model. There is nothing wrong topologically with two 
cubes sharing an edge in this way, it just happens to not be 2-manifold.

Manifoldness in this context means "how many times an edge is shared 
between adjacent faces". An edge is the topological connection between 2 
vertices. For a clean, closed volume every edge is used twice, hence it 
is 2-manifold. In this case there are 2 volumes sharing an edge, so that 
edge becomes 4-manifold as it is referenced by 4 faces.

But manifoldness is totally irrelevant in the STL file format, you can 
write this file to STL without any issue. You can also write a single 
triangle to an STL without any issue, there is no volume in that case. 
The problem with STL is not that it is limited or restrictive, the 
problem with STL is that there are no rules at all, so interpretation of 
it becomes a problem.

> This limitation doesn't exist in the 3MF file format, which explicitly
> supports these kinds of models.

Any of STL, OBJ, OFF, AMF will of course support such a model. It is not 
a question of file format.

> This statement might be surprising or controversial. The way it works
> is: 3MF uses a different mesh representation than STL.

As does OBJ, OFF and AMF. All of them use the kind of topology you 
describe below.

> 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."

Not duplicating the vertices is what is causing the edge to be 
4-manifold. If 3MF require all edges to be 2-manifold, it is 3MF that is 
extra restrictive.

> 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 that seems to violate the rule you just referred to?

Carsten Arnholm

More information about the Discuss mailing list