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!!
Locked
