Does it look purple in the F12 view?  If so it is inside out. I.e. a
cavity, instead of a solid.

On 18 February 2016 at 17:15, L Boyd lboyd@frontiernet.net wrote:

On 18. feb. 2016 18:15, L Boyd wrote:

In most systems I have encountered, counterclockwise is the logical
definition. I used that in Angelscript CSG which ends up in OpenSCAD as
polyhedrons, and I observed no issues when I did that.

The recent thread about STL referred to a format description where it is
explicitly stated in text and with a figure that the correct vertex
order is counterclockwise (CCW) when looking at the face from outside
looking inwards http://www.fabbers.com/tech/STL_Format

Unless OpenSCAD reverses all faces in polyhedrons when writing to STL, I
guess the polyhedron face vertex order definition you are referring to
is simply wrong.

If you check with the example under the definition text, this guess
appears to be confirmed. The pyramid polyhedron example lists all the
face vertices in CCW order when observing from outside looking in,
exactly opposite the text definition.

https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Primitive_Solids#polyhedron

So I think the definition in the text should be corrected from CW to CCW.

Carsten Arnholm

I agree it seems weird for OpenSCAD to use the left hand rule for
polyhedron(), since both STL and CGAL use the opposite convention, but the
documentation appears to be correct. I tried creating a right-hand rule
polyhedron() a while back (counter-clockwise vertices as viewed from
outside), but the faces are purple in thrown-together mode, and you get
CGAL assertions if you try to do CSG operations on the polyhedron.

If you want to check my work and see if I'm mistaken, here it is:

points = [
[ 1,  1,  1],
[ 1,  1, -1],
[ 1, -1,  1],
[ 1, -1, -1],
[-1,  1,  1],
[-1,  1, -1],
[-1, -1,  1],
[-1, -1, -1],
];
faces = [
[ 4 , 5, 1, 0],
[ 2 , 6, 4, 0],
[ 1 , 3, 2, 0],
[ 6 , 2, 3, 7],
[ 5 , 4, 6, 7],
[ 3 , 1, 5, 7],
];
// vertexes are in the wrong order:
rfaces = [
[0,1,4,5],
[0,4,6,2],
[0,2,3,1],
[7,3,2,6],
[7,6,4,5],
[7,5,1,3],
];

polyhedron(points,rfaces);
cube(2); // CGAL error if rfaces used

On 18 February 2016 at 13:16, Carsten Arnholm arnholm@arnholm.org wrote:

Actually you have the first rface as a self intersecting polygon, which
CGAL hates. Fixing to [0,1,5,4], seems to make it happy and the result is a
pair of unioned cubes and is manifold. Very odd.

On 18 February 2016 at 18:49, doug moen doug@moens.org wrote:

On 18. feb. 2016 19:49, doug moen wrote:

I misread the polyhedron example and came to the wrong conclusion when I
said "The pyramid polyhedron example lists all the face vertices in CCW
order when observing from outside looking in, exactly opposite the text
definition. ". After double checking I can see now I was wrong, the
vertices are listed in CW order in the example, consistent with the text
requirement.

Still it is counterintuitive and inconsistent with STL and CGAL as you say.

The comment for rfaces is correct, it is in the wrong order. But the
real problem is that first face is neither CW nor CCW, there are two
diagonals crossing each other, so it should fail.

Try this instead:

points = [
[ 1,  1,  1],
[ 1,  1, -1],
[ 1, -1,  1],
[ 1, -1, -1],
[-1,  1,  1],
[-1,  1, -1],
[-1, -1,  1],
[-1, -1, -1],
];
cw_faces = [
[ 4 , 5, 1, 0],
[ 2 , 6, 4, 0],
[ 1 , 3, 2, 0],
[ 6 , 2, 3, 7],
[ 5 , 4, 6, 7],
[ 3 , 1, 5, 7],
];

ccw_faces = [
[ 0 , 1, 5, 4],
[ 2 , 0, 4, 6],
[ 1 , 0, 2, 3],
[ 6 , 7, 3, 2],
[ 5 , 7, 6, 4],
[ 3 , 7, 5, 1],
];

union() {
polyhedron(points,ccw_faces);
cube(2);
}

The union works fine with ccw_faces as well as cw_faces. I am guessing
that someone is flipping the vertex order silently somewhere when
cw_faces are given. However, a mix of cw and ccw faces will not work.

I really don't know how the "thrown together" thing is implemented, but
to me it looks like it is trying to enforce what I would call the wrong
rule. If you ignore it and use CCW consistent with STL and CGAL it looks
to me booleans work fine.

Carsten Arnholm

On 19. feb. 2016 15:09, L Boyd wrote:

Apparently, that means OpenSCAD is flipping the sense of the faces
without any check. It would make more sense not to do that.

Carsten Arnholm

And Cura accepts either - which (IMNSHO) is not correct.  I think it should at least generate a warning.

There are competing conventions - the only reason to pick one over the other is consistency.

The next interesting test might be to create a difference of two cubes (each cube built as is done here and scaled differently).  What does OpenSCAD do with the faces defining the hole?  Of course, now there are 4 conditions to check:

a) big cube  CW, smaller hole  CW
b) big cube  CW, smaller hole  CCW
c) big cube CCW, smaller hole CW
d) big cube CCW, smaller hole CCW

and what we want to know is: direction of the facets on the outer surface and on the interior hole, for each of the above.
—
Kenneth Sloan
KennethRSloan@gmail.com mailto:KennethRSloan@gmail.com
Vision is the art of seeing what is invisible to others.

Doesn't it just mean that polyhedron uses the opposite convention to STL,
so they should always get flipped going from one the other.

On 19 February 2016 at 18:15, Carsten Arnholm arnholm@arnholm.org wrote: