translate([0,5,5])    rotate(90,[0,1,0])  rotate(45,[0,0,1]) 

translate([5,0,5])    rotate(90,[1,0,0])  rotate(45,[0,0,1]) 

Thanks, guys, that was a very interesting and useful series of comments. First, let me explain that what I am after is 3D printing in steel and aluminium, which requires to push the limits of model accuracy from the 0.03mm useful for plastic printing to 0.003mm as is common with subtractive machining processes or even 0.00003mm if I need a mirror surface. The technology <http://ibmresearchnews.blogspot.co.nz/2013/05/how-to-move-atom.html> is even available to push to single atom accuracy in 3D printing (0.0000002mm). As part of this effort I currently investigate what OpenSCAD really does vs what the manual claims it does. I will let you know when the work is complete. At the moment, I take it from your contributions that OpenSCAD does surfaces, not volumes. In a genuine CSG package like BRLCAD, which I investigated quite some time ago, solids would be defined by, using OpenSCAD language syntax sphere(1)=={pow(r,2)=pow(x,2)+pow(y,2)+pow(z,2)} or cube(1)=={pow(r,infinity)=pow(x,infinity)+pow(y,infinity)+pow(z,infinity)} In OpenSCAD, my current understanding is that a cube is defined by six simultaneous equations, one for each face: cube(1)=={x>=0; y>=0; z>=0; x<=1; y<=1; z<=1;} A consequence of this definition (I think in C++ syntax it would be called a constructor) is the bug listed here <http://https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/STL_Import_and_Export> . To fix it would require a change of definition for the cube as used in this code: // taken from: // https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/STL_Import_and_Export // purpose: to show that rendering problems can be avoided by appropriate programming Chamfer=0.000002; //lowest permissible value that does not produce a warning when rendering: Chamfer=0.000002 MyCube(); translate([10,10,0]) MyCube(); translate([-10,-10,-10]) cube([30,30,5]); module MyCube() difference() { cube([10,10,10], center=true); translate([5,5,0]) rotate(45,[0,0,1]) cube([Chamfer,Chamfer,12], center=true); translate([5,-5,0]) rotate(45,[0,0,1]) cube([Chamfer,Chamfer,12], center=true); translate([-5,5,0]) rotate(45,[0,0,1]) cube([Chamfer,Chamfer,12], center=true); translate([-5,-5,0]) rotate(45,[0,0,1]) cube([Chamfer,Chamfer,12], center=true); translate([0,5,5]) rotate(90,[0,1,0]) rotate(45,[0,0,1]) cube([Chamfer,Chamfer,12], center=true); translate([0,5,-5]) rotate(90,[0,1,0]) rotate(45,[0,0,1]) cube([Chamfer,Chamfer,12], center=true); translate([0,-5,5]) rotate(90,[0,1,0]) rotate(45,[0,0,1]) cube([Chamfer,Chamfer,12], center=true); translate([0,-5,-5]) rotate(90,[0,1,0]) rotate(45,[0,0,1]) cube([Chamfer,Chamfer,12], center=true); translate([5,0,5]) rotate(90,[1,0,0]) rotate(45,[0,0,1]) cube([Chamfer,Chamfer,12], center=true); translate([5,0,-5]) rotate(90,[1,0,0]) rotate(45,[0,0,1]) cube([Chamfer,Chamfer,12], center=true); translate([-5,0,5]) rotate(90,[1,0,0]) rotate(45,[0,0,1]) cube([Chamfer,Chamfer,12], center=true); translate([-5,0,-5]) rotate(90,[1,0,0]) rotate(45,[0,0,1]) cube([Chamfer,Chamfer,12], center=true); } Because I am a scientific jerk, someone who rates actual behaviour of a piece of software above what a programmer thinks <http://ask.slashdot.org/story/15/06/18/1634205/ask-slashdot-whats-the-harm-in-a-default-setting-for-div-by-zero> , I do dare to step on the toes of those who need it. But I am also willing to learn from those who point out where facts are in conflict with what I say or write. And with that, explicit thanks to doug.moen. His idea for OpenSCAD2 having just one primitive solid (he calls it orthogonality <http://https://github.com/doug-moen/openscad2/blob/master/rfc/Composable_Building_Blocks.md> ) means that surface() becomes the source and origin of all shapes. That means, as a designer, I have full control over both the shape and its surface. I can add to the shape using union(0), or access the vectors defining the shape and add to them. The latter would mean a dramatic improvement in rendering speed. -- View this message in context: http://forum.openscad.org/CSG-file-syntax-tp14115p14127.html Sent from the OpenSCAD mailing list archive at Nabble.com.

Von: wolf <wv99999@gmail.com> > The technology <http://ibmresearchnews.blogspot.co.nz/2013/05/how-to-move-atom.html> is > even available to push to single atom accuracy in 3D printing (0.0000002mm). > I suspect that might be pushing the current limitations a bit, but it will be interesting to see the details. > As part of this effort I currently investigate what OpenSCAD really does vs > what the manual claims it does. I will let you know when the work is > complete. > I'm not sure what that means? I'd suggest to share the discussion earlier to clarify details. > At the moment, I take it from your contributions that OpenSCAD does > surfaces, not volumes. > For CSG calculation, OpenSCAD currently uses libCGAL with Nef Polyhedra as data structure, for details, you can check their documentation. http://doc.cgal.org/latest/Manual/packages.html#PkgNef3Summary "3D Nef polyhedra, are a boundary representation for cell-complexes bounded by halfspaces that supports Boolean operations and topological operations in full generality including unbounded cells, mixed dimensional cells (e.g., isolated vertices and antennas). Nef polyhedra distinguish between open and closed sets and can represent non-manifold geometry." > Because I am a scientific jerk, someone who rates actual behaviour of a > piece of software above what a programmer thinks, I do dare to step on > the toes of those who need it. But I am also willing to learn from those > who point out where facts are in conflict with what I say or write. > I'd like to ask you to engage in discussion but not in a way that "step(s) on the toes of those who need it". This might be considered ok with some groups of people and/or when meeting in person, but having a diverse community with people from around the world also means the perception of what's said can be quite different. Also not all people (me for example) are native english speakers, which adds to the risk of misunderstandings. I know from my own experience how written messages can get out of hand even with people one knows for years. In one really bad case we could clear the misunderstandings quite easily by meeting in real life and talking about it, but we don't always have this option. > That means, as a designer, I have full control over both the shape > and its surface. I can add to the shape using union(0), or access > the vectors defining the shape and add to them. The latter would > mean a dramatic improvement in rendering speed. > Yes, that's one of the big limitations currently. Access to the mesh from the script would open up a number of new and powerful ways to write models. ciao, Torsten.