CSG file syntax
I know the syntax of scad files is documented. My question is "Is there any
documentation of the CSG file syntax"?
Thanks
--
View this message in context: http://forum.openscad.org/CSG-file-syntax-tp14115.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
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.
If I can believe Wikipedia
https://en.wikipedia.org/wiki/Constructive_solid_geometry ,
OpenSCAD is mostly Constructive Solid Geometry (CSG). But OpenSCAD als uses
boundary representation
https://en.wikipedia.org/wiki/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] ]);
http://forum.openscad.org/file/n14117/OpenCube.jpg
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.
--
View this message in context: http://forum.openscad.org/CSG-file-syntax-tp14115p14117.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
That's not b-rep, it's implemented internally as a mesh.
--
View this message in context: http://forum.openscad.org/CSG-file-syntax-tp14115p14119.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
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.
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 wv99999@gmail.com 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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
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.
How I wish that scientists were not arrogant jerks.
I'm done with this project, you can write your own fucking code.
--
View this message in context: http://forum.openscad.org/CSG-file-syntax-tp14115p14123.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
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);
}
}
--
View this message in context: http://forum.openscad.org/CSG-file-syntax-tp14115p14124.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
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 johnmdanskin@gmail.com 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
Discuss@lists.openscad.org javascript:;
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org