Hi,

On Sat, Jan 16, 2010 at 08:36:54PM +0000,

[hidden email] wrote:

> > > Regarding polyhedrons. Must all the faces be triangles?

> >

> > No, they can be any number of vertices, also mixed.

> > See example011.scad for an example.

>

> OK. At some point, if it is not too hard to change, I suggest the syntax

> "Faces=[]" would be much less confusing than "Triangles=[]".

I named it "triangles" for a reason: besides the fact that you may specify

more than 3 vertices I hardly recommend not to do so unless you really know

what you are doing. all point on a face must lay in the same plane. i.e.

there must be an a, b, c and d so

a*x + b*y + c*z + d = 0

is true for all vertices. for 3 vertices this requirement is always met.

for more than 4 vertices it is up to the user to ensure that all three

points are _exactly_ in one plane.

There are some easy cases. E.g. when one ordinate has the same value for

all points. The general case however is hard. The ordinates are stored as

double precision floating point numbers. So most decimal numbers actually

have another value than the one you write in the scad script.

E.g. consider the following C program:

#include <stdio.h>

int main() {

double a = 0.3, b = 0.6, c = 0.9;

double x = c-(b+(b-a));

printf("%g\n", x);

return 0;

}

it adds the difference of 'b' and 'a' to b and calculates the difference of

that value to 'c'. the difference of 'b' and 'a' is 0.3. 0.3 plus 0.6 is

0.9. the same value as 'c' so the program should output 0, right?

well - it does not. this values can't be correctly represented as binary

floating point numbers and so the program outputs a very small number

different from 0. It even depends on what compiler options you are using to

build this program:

$ gcc -O0 demo.c

$ ./a.out

5.55112e-17

$ gcc -O1 demo.c

$ ./a.out

1.11022e-16

(this is because double precission floats have a 53 significant binary

digits and the 80x87 floating point instruction set is using floating point

registers with 80 significant binary digits. the result is different

depending on what register allocation strategy the compiler is using)

So e.g. f(x) with f(1)=0.3, f(2)=0.6, f(3)=0.9 is not a linear function

when calculated with floating point numbers!

because of that you should only pass faces with more than three vertices to

the polygon statement if you eighter are looking at one of the simple cases

(such as one ordinate beeing identical for all vertices) or all numbers can

be represented as n / 2^m, which is e.g. obiously true for integer numbers.

so, if you really know what you are doing: feel free to pass faces of

arbitraty numbers of vertices to the polygon statement. if you are not sure

you should stick to the safe strategy and tesselate your polygon into

triangles.

> Incidentally, are the normals all supposed to be oriented in the same way?

> I notice the faces are different colors if the order of the vertices is

> clockwise versus counter-clockwise.

there is a right and a wrong oriantation for the faces. (I forgot which

one is which.. ;-)

all polygons should be yellow (or green for subtracted volumes) in the the

"thrown together" view mode. triangles with the wrong orientation are drawn

in a noticeable different color in the "thrown together" mode and are

invisible in the OpenCSG mode (when you are running OpenSCAD on a system

with full OpenGL 2.0 support).

yours,

- clifford

--

Qrpelcgvat ebg13 ivbyngrf gur QZPN! Cercner gb or fhrq!!