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

OpenSCAD is a surface modeler that pretends to be a solid modeler.    The
question is really how aggressively you want it to pretend.

If stitching together volumes from surface patches is desired, then I'm not
sure it should be done with something called 'polyhedron.'

STL is also surface - rather than space - modeling.  And, although the STL
format has its merits, I don't think "it makes sense in STL" is a good
argument for (or against) having a particular behavior in the modeling
software.

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

I'm fascinated that it breaks differently based on the position of the object
in space. Also glad it outputs anything at all, even when I am making a 2d
face with a 3d command.

Parkinbot wrote

Parkinbot when I do use polyhedron to make a closed 3D object (not just
faces) it does work for 3d printing.

BUT looks like i can't do differences or intersections. (hull still works)

//this just makes the cube - difference or intersection is ignored
difference(){
polyhedron
(points=[p0,p1,p2,p3,p4,p5,p6,p7],faces=[f0,f1,f2,f3,f4,f5,f6,f7,f8,f9,f10,f11]);
translate([5,5,5])cube(10);}

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

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

peetersm wrote

Hmm, your code produces a watertight object. The Boolean operation passes
CGAL (F6) without any problems. Therefore an STL-export will be
3D-printable.
You might have been mislead by F12 (combined) view, which does not show the
result of Boolean operations as you might expect it. I use F12 only to check
for polyhedron correctness. So: use F5 for preview, F12 for orientation
checks and F6 (plus a dummy Boolean operation) for watertight check and STL
correctness of a polyhedron.

@NateTG
I agree that polyhedron() and polygon() stand out from all other primitives
offered by OpenSCAD. This is because they are meant for user-defined stuff -
and thus they indeed provide functionality that allow more experienced users
to squeeze out a lot more from OpenSCAD not covered by the core concepts. In
my eyes they provide about 50% of the power of OpenSCAD, while the other 50%
are Boolean operations. I wouldn't need more to do my work.

In this forum regularly appear posts that demand a closure of these
primitives as they admittedly open a can of worms and bust the CSG paradigm,
which by the way also all the other 2D-primivites do. The argument is always
that a less experienced user might stumble over this or that and that some
posts could have been avoided, if OpenSCAD had a somehow more watertight
implementation.

Clearly, one could imagine implementations of these primitives that
immediately throw errors in case a non-simple polygon or some non-watertight
or wrongly oriented polyhedron is constructed. While this would severly
break existing code it would also prevent output essential for "learning by
doing" when working with these concepts. I am convinced that such a closure
wouldn't help less experienced users, but rather lead to an even steeper
learning curve. On the other side, it would block more experienced users to
do their stuff.
OpenSCAD is not only used to produce STLs for print. A lot of people,
including me, use it to do fancy animations and other "exotic" stuff, like
visualizing Math. Why should this creative "extra" functionality be blocked?

I am always a friend of warnings, because they give valuable hints. Of
course they have to be taken serious, which is not always the case -
especially by less experienced users, who often don't know which
implications a certain warning has. To face this, a beginners/experienced
user mode switch could be introduced. But wouldn't such a switch trigger
posts from people, who don't know about its existence?

I think this forum is enough means to give help and communicate the ways and
tricks for sailing around the different cliffs of OpenSCAD. Procrusting its
scope, or even boarding it up, won't serve any needs.

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

On 2/20/2018 3:53 AM, Parkinbot wrote:

By all means, have primitives that let you build exotic structures.

But "polyhedron" is an English word with a meaning and shouldn't be
abused for structures that are not polyhedra.

On 21. feb. 2018 18:55, Jordan Brown wrote:

Exactly my point.

Carsten Arnholm