[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:
>>> 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
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
> 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
> 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?
More information about the Discuss