CSG file syntax

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

CSG file syntax

KeithSloan52
I know the syntax of scad files is documented. My question is "Is there any documentation of the CSG file syntax"?

Thanks
tp3
Reply | Threaded
Open this post in threaded view
|

Re: CSG file syntax

tp3
On 10/12/2015 10:31 PM, KeithSloan52 wrote:
> I know the syntax of scad files is documented. My question is "Is there any
> documentation of the CSG file syntax"?
>
I don't think there's something like an official documentation. It's
essentially scad without any modules, variables and such.

ciao,
  Torsten.




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
Reply | Threaded
Open this post in threaded view
|

Re: CSG file syntax

wolf
If I can believe Wikipedia,
OpenSCAD is mostly Constructive Solid Geometry (CSG). But OpenSCAD als uses boundary representation (b-rep)as the following bit of code of a simple cube in b-rep shows

polyhedron(
  points=[ [0,0,0],[0,0,1],
          [0,1,0],[0,1,1],
          [1,0,0],[1,0,1],
          [1,1,0],[1,1,1]],
  faces=[ [0,1,3,2],[4,5,7,6],
         // [2,3,7,6],[0,4,5,1],   // faces left out deliberately
          [1,5,7,3],[0,4,6,2] ]);



In more complex scripts, b-rep has proven to be a lot faster when rendered, since non-existent faces need not be considered by the renderer. But creating complex shapes using CSG is faster. And if you want to decorate surfaces of CSG shapes, you are really asking for trouble, since OpenSCAD does not support access to the surfaces, edges or vertices of its shape primitives.
Reply | Threaded
Open this post in threaded view
|

Re: CSG file syntax

bobc
That's not b-rep, it's implemented internally as a mesh.
Reply | Threaded
Open this post in threaded view
|

Re: CSG file syntax

wolf
As far as I can see, the given polyhedron has no volume and thus is a 2-manifold, a surface for non-mathematicians. As far as I am aware, solids have by definition a volume and thus are 3-manifolds (or higher). If you delete all but one face in the example given, you obtain

polyhedron(
  points=[ [0,0,0],[0,0,1],
          [0,1,0],[0,1,1],],
  faces=[ [0,1,3,2] ]);

Rendering (F6) produces this output:

Rendering Polygon Mesh using CGAL...
Geometries in cache: 2
Geometry cache size in bytes: 496
CGAL Polyhedrons in cache: 0
CGAL cache size in bytes: 0
Total rendering time: 0 hours, 0 minutes, 0 seconds
   Top level object is a 3D object:
   Facets:          1

If the rendered object had a volume (i.e. were a very thin cube), it would need to have at least 6 facets, more if all facets are triangles. Since only one facet is reported, the claim that the top level object is a 3D object is false.

Surfaces can also be rendered as meshes. Claiming that an entity is 3D because it has been rendered as a mesh is nonsense. And if you are willing to drop the requirement that meshes must have faces, even a line can be a mesh: it may have vertices and edges! I am not willing to drop the requirement that solids have volumes and thus are at least 3-manifolds.

How I'd wish that programmers do have at least basic scientific training. Then they would understand that a single example to the contrary invalidates even the most acclaimed theory and turns it into rubbish. If you can show that in my example of a cube, with all faces shown, there is indeed an edge going from point [0,0,0] to point [1,1,1], i.e. through the centre of the cube, you have invalidated my claims. If you cannot, all you can claim is that a 2D mesh has been drawn inside a 3-manifold, which is an entirely acceptable way of doing it - for a b-rep.

Let's see it.
Reply | Threaded
Open this post in threaded view
|

Re: CSG file syntax

doug.moen
I really don't understand what this discussion is about. Also, I don't agree with the Wikipedia articles that were cited.

In my experience, every CSG system that I've looked at uses some universal representation for a solid object, and provides CSG operations that map solids onto solids. The solid representations I've seen are:
  • boundary rep, eg a polygonal mesh like OpenSCAD. This is the most common.
  • Implicit function representation.
  • Voxels.
The Wikipedia articles on CSG and brep appear to draw a false dichotomy between CSG systems and brep systems. The article on CSG seems to focus on a hypothetical type of CSG system in which solids are represented as trees, where the non-leaf nodes are CSG operations, and the leaf nodes are "primitive solids", whatever that means. These primitive solids logically *must* have some representation, but Wikipedia appears to rule out brep as that representation, even though that's the most popular choice in actual real existing CSG systems. In other words, if a CSG system uses brep, then Wikipedia claims that it isn't a CSG system, which is wrong.

bobc claims that OpenSCAD is not a brep system, because we use meshes. That makes no sense. The mesh is used to Represent the Boundary of a 3D object.

wolf points out that there is a bug in the polygon primitive. It doesn't check the mesh and report an error if the mesh is not manifold, or if the mesh is inside out. So that's a bug in OpenSCAD, but wolf is using this bug to make some categorical claim about OpenSCAD that I can't decipher.

On 14 October 2015 at 05:17, wolf <[hidden email]> wrote:
As far as I can see, the given polyhedron has no volume and thus is a
2-manifold, a surface for non-mathematicians. As far as I am aware, solids
have by definition a volume and thus are 3-manifolds (or higher). If you
delete all but one face in the example given, you obtain

polyhedron(
  points=[ [0,0,0],[0,0,1],
          [0,1,0],[0,1,1],],
  faces=[ [0,1,3,2] ]);

Rendering (F6) produces this output:

Rendering Polygon Mesh using CGAL...
Geometries in cache: 2
Geometry cache size in bytes: 496
CGAL Polyhedrons in cache: 0
CGAL cache size in bytes: 0
Total rendering time: 0 hours, 0 minutes, 0 seconds
   Top level object is a 3D object:
   Facets:          1

If the rendered object had a volume (i.e. were a very thin cube), it would
need to have at least 6 facets, more if all facets are triangles. Since only
one facet is reported, the claim that the top level object is a 3D object is
false.

Surfaces can also be rendered as meshes. Claiming that an entity is 3D
because it has been rendered as a mesh is nonsense. And if you are willing
to drop the requirement that meshes must have faces, even a line can be a
mesh: it may have vertices and edges! I am not willing to drop the
requirement that solids have volumes and thus are at least 3-manifolds.

How I'd wish that programmers do have at least basic scientific training.
Then they would understand that a single example to the contrary invalidates
even the most acclaimed theory and turns it into rubbish. If you can show
that in my example of a cube, with all faces shown, there is indeed an edge
going from point [0,0,0] to point [1,1,1], i.e. through the centre of the
cube, you have invalidated my claims. If you cannot, all you can claim is
that a 2D mesh has been drawn inside a 3-manifold, which is an entirely
acceptable way of doing it - for a b-rep.

Let's see it.




--
View this message in context: http://forum.openscad.org/CSG-file-syntax-tp14115p14120.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: CSG file syntax

johnmdanskin
The wikipedia entry on CSG is making a statement about CSG operations vs BREP operations. With CSG operations, if you start with solids, you end up with solids (floating point implementations willing). With BREP it's super easy to generate self-intersecting polyhedra which aren't solids.

CSG can be performed on any solids, including the output of BREP modelers:

Wikipedia entry on Constructive Solid Geometry:
   "CSG can also be performed on polygonal meshes, "
   "Some software packages allow CSG on curved objects while other packages do not."
   "When creating geometry based upon boundary representations, additional topological data is required, or consistency checks must be performed to assure that the given boundary description specifies a valid solid object"

CSG operations and Brep operations can be provided by the same modelers. They've got different properties. I've been doing some free-form Brep manipulations in OpenScad and keeping the polygons consistent and non-degenerate is an incredible pain. On the other hand, I can make some nifty smooth objects by applying lots of sin and cosine waves to my object. Until my surface self-intersects or my polygons become degenerate and I have to play with it until it's better.

If you think of Brep and CSG as sets of operations on solids, maybe the discussion would be less charged? CSG is like + and *. Hard to get in trouble with, but limited. Brep is like /. Also useful, but dividing by zero is always a possibility.

?
Reply | Threaded
Open this post in threaded view
|

Re: CSG file syntax

bobc
In reply to this post by wolf
How I wish that scientists were not arrogant jerks.

I'm done with this project, you can write your own fucking code.
Reply | Threaded
Open this post in threaded view
|

Re: CSG file syntax

L Boyd
In reply to this post by johnmdanskin
Getting back to the original question, regardless of what wikipedia may say, OpenSCAD puts enough information in its .csg to completely recreate your model. Try loading one and displaying it.

It includes both 2D and 3D primitives.  Rotate and Translate show up as multmatrix. Variables are absent because the input has been fully compiled to have constant values.

As far as I can tell, anything from an OpenSCAD  .csg can be included in a .scad file.

A simple example:

a = 10;
translate([5,4]){
circle(a);
square(a+2);}

generates:

group() {
        multmatrix([[1, 0, 0, 5], [0, 1, 0, 4], [0, 0, 1, 0], [0, 0, 0, 1]]) {
                circle($fn = 0, $fa = 12, $fs = 2, r = 10);
                square(size = [12, 12], center = false);
        }
}
Larry
Reply | Threaded
Open this post in threaded view
|

Re: CSG file syntax

doug.moen
In reply to this post by johnmdanskin
Thanks for the explanation, that makes sense to me.

I've looked at a few solid modeling languages with a rich set of operations on "non manifold objects", but don't have experience with such systems. I never thought of OpenSCAD as belonging to this category, as I didn't think there was anything useful you could do with a non-manifold polyhedron. I could be mistaken about that.

Doug Moen

On Wednesday, 14 October 2015, johnmdanskin <[hidden email]> wrote:
The wikipedia entry on CSG is making a statement about CSG operations vs BREP
operations. With CSG operations, if you start with solids, you end up with
solids (floating point implementations willing). With BREP it's super easy
to generate self-intersecting polyhedra which aren't solids.

CSG can be performed on any solids, including the output of BREP modelers:

Wikipedia entry on Constructive Solid Geometry:
   "CSG can also be performed on polygonal meshes, "
   "Some software packages allow CSG on curved objects while other packages
do not."
   "When creating geometry based upon boundary representations, additional
topological data is required, or consistency checks must be performed to
assure that the given boundary description specifies a valid solid object"

CSG operations and Brep operations can be provided by the same modelers.
They've got different properties. I've been doing some free-form Brep
manipulations in OpenScad and keeping the polygons consistent and
non-degenerate is an incredible pain. On the other hand, I can make some
nifty smooth objects by applying lots of sin and cosine waves to my object.
Until my surface self-intersects or my polygons become degenerate and I have
to play with it until it's better.

If you think of Brep and CSG as sets of operations on solids, maybe the
discussion would be less charged? CSG is like + and *. Hard to get in
trouble with, but limited. Brep is like /. Also useful, but dividing by zero
is always a possibility.

?




--
View this message in context: http://forum.openscad.org/CSG-file-syntax-tp14115p14122.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
OpenSCAD mailing list
<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;Discuss@lists.openscad.org&#39;)">Discuss@...
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: CSG file syntax

wolf
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 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. 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, 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) 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.
tp3
Reply | Threaded
Open this post in threaded view
|

Re: CSG file syntax

tp3
Von: wolf <[hidden email]>
> 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.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten