Polyhedron is meant to define a self-contained solid object, I don't
think behavior is well defined if you are using it to define
individual triangles one-by-one.
Also the winding order of each triangle matters, if the order of
vertices for a triangle not in the correct order, the face will be
inside-out.

On Sat, Feb 17, 2018 at 11:12 AM, peetersm peetersmarkg@gmail.com wrote:

On 17. feb. 2018 18:12, peetersm wrote:

Your code illustrate 2 important issues

1. a polyhedron cannot contain a single face and be valid, it must have
   at least 4 faces to define a closed volume.

Looking at your code, it will necessarily fail. This is because you
define several polyhedra with only one face in each. Clearly these are
not closed volumes. To define a single polyhedron equivalent to a cube,
you must first list 8 points (one for each corner) and then list 6
rectangular (or 12 triangular) faces, all in the same polyhedron,
referring to the point indices using the rules described below.

So, your cubeTri() module should define one polyhedron, not 12.

2. The face normals of any polyhedron must be properly oriented.

The face normal of any polyhedron face defines where the solid material
is relative to the face (inside or outside). The solid material is on
the opposite side of where the face normal is pointing. When one or more
of the face normals points inwards, the polyhedron is not describing a
closed volume.

The orientation of a face normal is defined from the winding order of
the face vertices (=points): In OpenSCAD you must list the face vertices
in clockwise order (as seen from outside) for the face normal to be
properly pointing outwards. This must be true for all the faces in a
polyhedron, or else the polyhedron does not really define a closed
volume, and will fail.

For simple shapes like cubes it is much easier to simply use the cube()
command, as it is much less work and rules 1) and 2) will be taken care
of automatically. If you use polyhedron() you have to apply rules 1) and
2) yourself.

Carsten Arnholm

Thanks everyone for the quick replies. I have the following observations.

about the NORMAL or WINDING ORDER:

1. I don't agree that this is causing the "bad faces" since I can eliminate
   generation of "bad faces" by simply rotating the object which does not
   change the winding order.
2. I did correct the winding order on all the faces and the results were
   identical.
3. Incorrect winding order may cause other issues, but that is not related
   to this "bad face" issue.

about the "A SINGLE FACE DOES NOT A POLYHEDRON MAKE":

1. I rewrote the code so that I am not making faces but a closed surface
   and it works.
2. I was using polyhedron in a way that causes inconsistent results when
   rendering. :-(

Of course I was not trying to make cubes but some complicated shapes from
formulas. This cube idea was just a debugging exercise to try to understand
why it's behavior is not consistent.

---updated code that works--
//test polyhedron - don't make faces

cubeTriAll();//it works

p0=[0,0,0];//bottom origin 7:30 0'clock
p1=[0,10,0];//bottom 10:30 0'clock
p2=[10,10,0];//bottom 1:30 0'clock
p3=[10,0,0];//bottom 4:30 0'clock
p4=[0,0,10];//top origin 7:30 0'clock
p5=[0,10,10];//top 10:30 0'clock
p6=[10,10,10];//top 1:30 0'clock
p7=[10,0,10];//top 4:30 0'clock

f0=[0,2,1];//bottom1
f1=[0,3,2];//bottom2
f2=[0,1,5];//left1
f3=[0,5,4];//left2
f4=[1,6,5];//away1
f5=[1,2,6];//away2
f6=[2,3,7];//right1
f7=[2,7,6];//right2
f8=[0,4,7];//front1
f9=[0,7,3];//front2
f10=[4,5,6];//top1
f11=[4,6,7];//top2

module cubeTriAll(){
polyhedron
(points=[p0,p1,p2,p3,p4,p5,p6,p7],faces=[f0,f1,f2,f3,f4,f5,f6,f7,f8,f9,f10,f11]);
}

On Sat, Feb 17, 2018 at 1:36 PM, Carsten Arnholm arnholm@arnholm.org
wrote:

peetersm wrote

In a sense, I agree with you.  IMO OpenSCAD should have just had an error or
produced an empty STL from those polyhedron calls.  "Winding order" really
only makes sense as an issue if you've got a connected surface with more
than one face.

--
Sent from: http://forum.openscad.org/

On 2018-02-18 02:46, NateTG wrote:

A polyhedron with less than 4 faces is not a closed surface, and
therefore cannot describe a closed volume. Since the face winding order
is relative to a viewpoint outside of the closed volume, it follows that
the winding order is undefined for a polyhedron with less than 4 faces.
The error that should have been flagged in this case is that the
polyhedron calls had less than 4 faces, it is always an error.

Carsten Arnholm

cacb wrote

Carsten, again, I disagree with you. We had this discussion before.
Non-manifold polyhedra make sense, even for STL export. OpenSCAD
could/should give a warning at export, because a non-manifold polyhedron
might not be 3D-printable - which in turn depends on the slicer or the post
processing tool.
I can image to export a bunch of somehow arranged faces as STL and use a
postprocessor to fab something out of this structure - e.g. to feed a laser
cutter. Would that be an error?

Peter, you can test your polyhedron for 3D-printability by writing

polyhedron(verts, faces);
cube();

CGAL will give you an error if the polyhedron is non-manifold. It is as
simple as this.

--
Sent from: http://forum.openscad.org/

On 2018-02-18 11:08, Parkinbot wrote:

Fair enough, we disagree. OpenSCAD is a solid modeller based around the
Constructive Solid Geometry modelling technique. For that you need
solids.

My comment relates to the often seen situation described by the original
poster in this thread.

It is not solid modelling. A solid modeller should warn when used in a
way inconsistent with its stated objective. In 99% of the cases what you
describe is an unintended mistake.

Carsten Arnholm