I am using the Windows Binary version on my Windows NT machine(s). Upon startup, I always get the warning message "No support for OpenGL 2.0 found! ...". But I am still using openSCAD and it seems to work OK, although it is slow for my most complex renderings. I found that my graphics hardware is "Intel 829456 Express Chipset Family". Looking at the Intel drivers, I find that the latest one only adds OpenGL 1.5 capability. So it looks like I am out of luck as far as upgrading to OpenGL 2.0. Have I no other options, other than finding or buying a different machine? Are there other advantages to using OpenGL 2.0, other than speed? I don't see much on this issue in the manual. On an unrealated issue, I tried the "multmatrix" transformation and it doesn't appear to be working. Is there an example of the use of this transformation? Why a 4x4 matrix and not 3x3? Thanks in advance for any help anyone can give!! George 
Hello,
On Thu, Jan 14, 2010 at 11:12:25PM +0000, [hidden email] wrote: > [...] So it looks like I am out of luck as far > as upgrading to OpenGL 2.0. Have I no other options, other than > finding or buying a different machine? > Are there other advantages to using OpenGL 2.0, other than speed? I > don't see much on this issue in the manual. unfortunately the manual does not cover the user interface atm.. when you have OpenGL 2.0 there is the "OpenCSG" [1] view mode where you can view your model instantanously without building it using CGAL. without OpenGL 2.0 there is only the "Thrown together" mode in which the CSG operations (difference, intersection) are not performed but instead all bodies are fully drawn. With OpenGL 2.0 it becomes much easier to make complex designs because the test cycles are much shorter. > On an unrealated issue, I tried the "multmatrix" transformation and it > doesn't appear to be working. Is there an example of the use of this > transformation? Why a 4x4 matrix and not 3x3? > Thanks in advance for any help anyone can give!! as to why it is a 4x4 instead of a 3x3 matrix I'd like to refer you to any better OpenGL introduction. maybe you got the syntax for multmatrix() wrong. The following example translates the child objects along the vector [10, 20, 30]: multmatrix([ [1, 0, 0, 10], [0, 1, 0, 20], [0, 0, 1, 30], [0, 0, 0, 1]]) However: usually one does not need to use multmatrix() directly but use a combination of the other transform statements translate(), scale() and rotate() instead. yours,  clifford  If Python is executable pseudocode, then perl is executable line noise. 
In reply to this post by gibell
Thanks for the quick response, Clifford! > > On an unrelated issue, I tried the "multmatrix" transformation > > and it doesn't appear to be working. Is there an example of the > > use of this transformation? Why a 4x4 matrix and not 3x3? > > Thanks in advance for any help anyone can give!! > > > maybe you got the syntax for multmatrix() wrong. The following example > translates the child objects along the vector [10, 20, 30]: > > multmatrix([ > [1, 0, 0, 10], > [0, 1, 0, 20], > [0, 0, 1, 30], > [0, 0, 0, 1]]) The online manual says the syntax is ... multmatrix(v = [ ... ]) {} but this fails for me. Does your example compile, or is supposed to be multmatrix(m = [ ... ]) {} > However: usually one does not need to use multmatrix() directly > but use a combination of the other transform statements translate(), > scale() and rotate() instead. Agreed. I wanted to do a rotation about an arbitrary axis, but this can be accomplished using translate, rotate, and translate. Regarding polyhedrons. Must all the faces be triangles? I made a polyhedron where all the faces have 4 sides, and I entered it as "Triangles=[[0,1,2,3],[0,4,3,2], ...]]" which works fine (so far). But if I create a polyhedron where some faces have 3 sides and some 4, it tends to crash. It would be nice if there was a check for this if they are all supposed to be triangles, or all the same number of sides. Thanks! George 
Administrator

On Jan 15, 2010, at 18:15 , [hidden email] wrote:
> The online manual says the syntax is ... > multmatrix(v = [ ... ]) {} > but this fails for me. Does your example compile, or is supposed to > be > multmatrix(m = [ ... ]) {} > The online manual was wrong; the correct syntax is with the 'm' argument. I've updated the manual with an example. > Regarding polyhedrons. Must all the faces be triangles? No, they can be any number of vertices, also mixed. See example011.scad for an example. If you get a crash, please submit an example model and we'll look into it. ~/= Marius  We are Elektropeople for a better living. 
In reply to this post by gibell
> Marius Kintel wrote: > On Jan 15, 2010, at 18:15 , [hidden email] wrote: > > > The online manual says the syntax is ... > > multmatrix(v = [ ... ]) {} > > but this fails for me. Does your example compile, or is supposed to > > be multmatrix(m = [ ... ]) {} > > > The online manual was wrong; the correct syntax is with the 'm' > argument. I've updated the manual with an example. Thanks! > > 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=[]". 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 counterclockwise. > If you get a crash, please submit an example model and we'll look into Will do. Thanks for your response! George 
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+(ba)); 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.55112e17 $ gcc O1 demo.c $ ./a.out 1.11022e16 (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 counterclockwise. 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!! 
On Sat, Jan 16, 2010 at 11:00:42PM +0100, Clifford Wolf wrote:
> > > > 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. How about adding "polygons" or "faces" as an alias so that people can learn to know what they're doing? Given that your example011.scad has one triangle with four corners... Ralf  Dr. Ralf Schlatterbeck Tel: +43/2243/2646516 Open Source Consulting Fax: +43/2243/2646523 Reichergasse 131 www: http://www.runtux.com A3411 Weidling email: [hidden email] osAlliance member email: [hidden email] 
Free forum by Nabble  Edit this page 