Do you mean this example?

polyhedron
(points = [
[0, -10, 60], [0, 10, 60], [0, 10, 0], [0, -10, 0], [60, -10,
60], [60, 10, 60],
[10, -10, 50], [10, 10, 50], [10, 10, 30], [10, -10, 30], [30,
-10, 50], [30, 10, 50]
],
faces = [
[0,3,2],  [0,2,1],  [4,0,5],  [5,0,1],  [5,2,4],  [4,2,3],
[6,8,9],  [6,7,8],  [6,10,11],[6,11,7], [10,8,11],
[10,9,8], [3,0,9],  [9,0,6],  [10,6, 0],[0,4,10],
[3,9,10], [3,10,4], [1,7,11], [1,11,5], [1,8,7],
[2,8,1],  [8,2,11], [5,11,2]
]
);

It works for me.

On 9 December 2016 at 17:48, Ronaldo rcmpersiano@gmail.com wrote:

I say bug in both :)

I believe this should theoretically work, but it evidently doesn’t, and we don’t have any test cases for it.
Note: The polygons don’t have holes, they are simply self-intersecting in a “seam”, making them appear as if they have holes. The result should be possible to tessellate into a clean triangle mesh, but somehow, something goes wrong.

It’s possible that this has worked in some development snapshot, but due to not being tested stopped working again.

A github issue is warranted if someone wants to start one.

-Marius

The error only happens if you have a spurious cube in the scad as Ronaldo's
screenshot shows.  That's not in the wiki example.

On Fri, Dec 9, 2016 at 12:51 PM, Ronaldo Persiano rcmpersiano@gmail.com
wrote:

What you call spurious cube is a test whether the model supports boolean
operations.

But there is something very odd here. If we drop the cube, render it and
generate a stl file, we will find that the file is fine, can be imported
and boolean operated!

2016-12-09 16:57 GMT-02:00 Hans L thehans@gmail.com:

This is "normal" behaviour for OpenSCAD. What we have here are bad/illegal
arguments to polyhedron. They are bad because the resulting polyhedron
causes problems in CGAL. OpenSCAD does not report bad arguments to
polyhedron, so you don't find out if the program is correct unless you
attempt to perform a boolean operation on the polyhedron. You can
successfully preview a bad polyhedron, or export it to STL, as long as you
don't attempt a boolean operation on it.

So the example code in the wiki is bad/illegal code.

My personal opinion is that this indicates a problem with OpenSCAD. There
should be a clear specification for what constitutes a legal set of
arguments to polyhedron. If the arguments are legal, then the resulting
polyhedron should work correctly in all contexts, including boolean
operations. If the arguments are illegal, then an error should be reported
by the polyhedron primitive.

The interesting question for me becomes: what are the rules for determining
if the arguments to polyhedron are correct? It's necessary to decide this
in order to fix the bug.

On 10 December 2016 at 08:34, Ronaldo Persiano rcmpersiano@gmail.com
wrote:

I would not expect more than the following as correct arguments for
polyhedron: the arguments should define a 2-manifold without border and
each facet should be a planar simple polygon. But I think it is important
to preview illegal polyhedron: it is an invaluable tool in debugging
models. That is my daily use in the development of surfaces.

2016-12-10 11:59 GMT-02:00 doug moen doug@moens.org:

The problem with that is it is impossible to represent perfectly planar
polygons with floating point unless they are triangles or parallel to an
axis or perhaps some other special cases. How much error do you allow? Is
there a way to snap float coordinates to a plane represented by rationals
that CGAL can eat?

On 10 December 2016 at 14:30, Ronaldo Persiano rcmpersiano@gmail.com
wrote:

Right now this is only implicitly specified through test cases. Having an explicit spec would be nice, just time consuming to create and maintain. This is why the manual is a wiki :)

Some notes:

o As meshes have multiple paths in and out of OpenSCAD, as well as CGAL, we try to have similar requirements for these processes.
o Polygons can be slightly non-planar. CGAL isn’t happy about this, so we’re required to offer triangulation.
o Polygons coming from CGAL can have holes/islands, and have quite complex topology after snap-rounding, so we need our triangulator to be robust in terms of holes and self-intersections.
o Polygons in OpenSCAD polyhedrons can be slightly non-planar, and since we need to be robust in the previous point, we could offer similar robustness for polyhedrons.
o Import from external files: We should try to match robustness with common upstream or downstream software.
o Local/global manifoldness is hard to support well across file formats and internal libraries.

Exactly. We’re somehow not passing this polygon to CGAL in a way that CGAL understands. It could be that CGAL interprets this polygon as having an infinitely thin crack and tries to preserve this, while the polyhedron manual indicates that it’s simply a seam. After triangulating to STL, this polygon becomes non-ambiguous and will work as expected. Some disambiguation is needed here.

-Marius