Ronaldo said: "Best than just eliminating the top level implicit union would be to have another operator: the set (or aggregate) operator. The set operator would collect a set of bodies preserving each one as a separated entity. If you union the set, then they become one (possibly manifold) body only but before that the set may not represent a manifold. Its bodies may not even be disjoint." We already have a "set (or aggregate)" operator. It is called "group". The explicit syntax is 'group() { shape1; shape2; ... }'. You can see this operator if you display the CSG tree. Nobody types it explicitly, because groups are generated implicitly for every module call (the 'children()' of a module call is represented by a group, and the output is always a group). There is a design flaw in how groups currently work. In short, too many groups are being implicitly generated. If the tail argument to a module call is a single (non-compound) statement, like a for loop or a module call, then the results returned by that statement (which may be a group) are wrapped in another group with a single element. This prevents you from feeding multiple outputs from one module call into another module as its children(). This is why intersection_for() exists. There is a plan to fix this problem, but it is called "lazy union", because the same feature also eliminates the implicit top level union. https://github.com/openscad/openscad/issues/350 OpenSCAD2 fixes the problem by adopting so-called "lazy union" semantics for module calls, and also by reinterpreting the "{ ... }" syntax as the group constructor. In OpenSCAD2, groups are always constructed explicitly using {...} syntax, except for at the top level, where all top level objects are implicitly collected into a group. Even in OpenSCAD2, there is a requirement that each element of a group be either another group, or a manifold shape. The CGAL union operator requires that its arguments be manifold; that's where the restriction comes from. Doug Moen. On 4 February 2016 at 11:13, Ronaldo Persiano <rcmpersiano@gmail.com> wrote: > doug moen brings another important aspect to this discussion: " the top > level implicit union that occurs before exporting an STL file". STL is > intended to represent one object only presumably a 2-manifold and this is > a serious limitation of STL format. I agree that, excluding numerical > approximation issues, STL allows the recovering of the missing topological > information if and only if the geometrical embedding of it is a manifold. > As I showed before by examples, we can represent several non-disjoint > manifolds in STL as far as they do not have common vertices. But that is > very restrictive. > > I would like to represent not only one body in OSCAD. I would like to > represent a set of distinct (not necessarily disjoint) objects. One simple > application of that, besides the ones Arholm brought, is an animation of, > say, a ball bouncing in a billiard table. If I define a fixed table and a > ball on it, as their union is not a 2-manifold, I may have problems. Two > gears may have contact. In the real world, objects have contact. > > Best than just eliminating the top level implicit union would be to have > another operator: the set (or aggregate) operator. The set operator would > collect a set of bodies preserving each one as a separated entity. If you > union the set, then they become one (possibly manifold) body only but > before that the set may not represent a manifold. Its bodies may not even > be disjoint. May be, I don't know, there is no non-manifold objects in the > world but the world itself is not a manifold. > > If we go in that way, STL should be abandoned. > > 2016-02-04 13:17 GMT-02:00 doug moen <doug@moens.org>: > >> "a non-manifold face is a face internal to the body, it has material on >> both sides and does not describe the external surface of the solid body." >> >> The ability to partition a solid into a collection of disjoint subvolumes >> with shared faces is also useful in OpenSCAD; it's not just a ship >> design/ACIS thing. >> >> One obvious example is 3D printing of multi-material/multi-colour >> objects. There have been a number of discussions about how to support this >> in OpenSCAD. Internally, the volumes for each colour/material need to be >> kept separate and labeled. To export such a model, you either need to >> export multiple STL files (one per material/colour), or you need to export >> an AMF file with distinct volume elements for each colour/material. In no >> case should any of the individual volumes that we track internally or >> export contain non-manifold faces. >> >> This situation can arise in feature request #1562, which requests a >> convex_decomposition() operator. The result of this operator is a group of >> solids which share faces between them. Each group element is a convex >> polyhedron, which is manifold. This feature isn't useful unless we get rid >> of the implicit union that would otherwise occur when passing the results >> of convex_decomposition() to another module: see issue #350. But, issue >> #350 also eliminates the top level implicit union that occurs before >> exporting an STL file. If we get rid of top level implicit union, and the >> top level element in a script is a call to convex_decomposition() on >> non-convex input, then we can't meaningfully export to STL. There is a >> manifoldness check prior to STL export which *should* report this problem >> (issue #1215). Exporting the same object to AMF can be supported, because >> we can put each convex polyhedron into a separate volume. >> >> In summary, OpenSCAD should support models that contain disjoint >> subvolumes with shared faces. There are features we need to add and >> bugs/design flaws we need to fix before this support is complete. >> >> On 4 February 2016 at 02:13, <arnholm@arnholm.org> wrote: >> >>> On 2016-02-04 06:54, Triffid Hunter wrote: >>> >>>> non-manifold means that the topology is somehow ambiguous. >>>> >>> >>> No, it does not. >>> >>> An example of non-manifold topology is where a topological edge is >>> shared by more than 2 faces. >>> >>> http://docs.mcneel.com/rhino/5/help/en-us/popup_moreinformation/non-manifold_edges.htm >>> >>> It is not ambiguous, and in many cases a desired feature. This kind of >>> non-manifold topology is much used in ship design when designing FEM models >>> with shell elements. Often, non-manifold topology is perfectly acceptable >>> and is not ambiguous in any way. CAD systems like e.g. ACIS ( >>> https://en.wikipedia.org/wiki/ACIS ) have no issues representing >>> non-manifold topology. >>> >>> In the special case of 3d solid topological models, a non-manifold face >>> is a face internal to the body, it has material on both sides and does not >>> describe the external surface of the solid body. That does not mean it is >>> topologically ambiguous. Such faces may be and are used for subdivision, >>> for example to guide 3d solid meshing (solid FEM models). Whether such >>> non-manifold topological entities are desirable or not depends on the >>> application area, but it is not topologically ambiguous. >>> >>> It is only when the topological description is non-existent things like >>> this become a problem. >>> >>> >>> Carsten Arnholm >>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> Discuss@lists.openscad.org >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> >>> >>> >> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> >> > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > >

I have used group() explicitly to make a bunch of children into a first child. On 4 February 2016 at 18:04, doug moen <doug@moens.org> wrote: > Ronaldo said: "Best than just eliminating the top level implicit union > would be to have another operator: the set (or aggregate) operator. The set > operator would collect a set of bodies preserving each one as a separated > entity. If you union the set, then they become one (possibly manifold) body > only but before that the set may not represent a manifold. Its bodies may > not even be disjoint." > > We already have a "set (or aggregate)" operator. It is called "group". The > explicit syntax is 'group() { shape1; shape2; ... }'. You can see this > operator if you display the CSG tree. Nobody types it explicitly, because > groups are generated implicitly for every module call (the 'children()' of > a module call is represented by a group, and the output is always a group). > > There is a design flaw in how groups currently work. In short, too many > groups are being implicitly generated. If the tail argument to a module > call is a single (non-compound) statement, like a for loop or a module > call, then the results returned by that statement (which may be a group) > are wrapped in another group with a single element. This prevents you from > feeding multiple outputs from one module call into another module as its > children(). This is why intersection_for() exists. > > There is a plan to fix this problem, but it is called "lazy union", > because the same feature also eliminates the implicit top level union. > https://github.com/openscad/openscad/issues/350 > > OpenSCAD2 fixes the problem by adopting so-called "lazy union" semantics > for module calls, and also by reinterpreting the "{ ... }" syntax as the > group constructor. In OpenSCAD2, groups are always constructed explicitly > using {...} syntax, except for at the top level, where all top level > objects are implicitly collected into a group. > > Even in OpenSCAD2, there is a requirement that each element of a group be > either another group, or a manifold shape. The CGAL union operator requires > that its arguments be manifold; that's where the restriction comes from. > > Doug Moen. > > On 4 February 2016 at 11:13, Ronaldo Persiano <rcmpersiano@gmail.com> > wrote: > >> doug moen brings another important aspect to this discussion: " the top >> level implicit union that occurs before exporting an STL file". STL is >> intended to represent one object only presumably a 2-manifold and this >> is a serious limitation of STL format. I agree that, excluding numerical >> approximation issues, STL allows the recovering of the missing topological >> information if and only if the geometrical embedding of it is a manifold. >> As I showed before by examples, we can represent several non-disjoint >> manifolds in STL as far as they do not have common vertices. But that is >> very restrictive. >> >> I would like to represent not only one body in OSCAD. I would like to >> represent a set of distinct (not necessarily disjoint) objects. One simple >> application of that, besides the ones Arholm brought, is an animation of, >> say, a ball bouncing in a billiard table. If I define a fixed table and a >> ball on it, as their union is not a 2-manifold, I may have problems. Two >> gears may have contact. In the real world, objects have contact. >> >> Best than just eliminating the top level implicit union would be to have >> another operator: the set (or aggregate) operator. The set operator would >> collect a set of bodies preserving each one as a separated entity. If you >> union the set, then they become one (possibly manifold) body only but >> before that the set may not represent a manifold. Its bodies may not even >> be disjoint. May be, I don't know, there is no non-manifold objects in the >> world but the world itself is not a manifold. >> >> If we go in that way, STL should be abandoned. >> >> 2016-02-04 13:17 GMT-02:00 doug moen <doug@moens.org>: >> >>> "a non-manifold face is a face internal to the body, it has material on >>> both sides and does not describe the external surface of the solid body." >>> >>> The ability to partition a solid into a collection of disjoint >>> subvolumes with shared faces is also useful in OpenSCAD; it's not just a >>> ship design/ACIS thing. >>> >>> One obvious example is 3D printing of multi-material/multi-colour >>> objects. There have been a number of discussions about how to support this >>> in OpenSCAD. Internally, the volumes for each colour/material need to be >>> kept separate and labeled. To export such a model, you either need to >>> export multiple STL files (one per material/colour), or you need to export >>> an AMF file with distinct volume elements for each colour/material. In no >>> case should any of the individual volumes that we track internally or >>> export contain non-manifold faces. >>> >>> This situation can arise in feature request #1562, which requests a >>> convex_decomposition() operator. The result of this operator is a group of >>> solids which share faces between them. Each group element is a convex >>> polyhedron, which is manifold. This feature isn't useful unless we get rid >>> of the implicit union that would otherwise occur when passing the results >>> of convex_decomposition() to another module: see issue #350. But, issue >>> #350 also eliminates the top level implicit union that occurs before >>> exporting an STL file. If we get rid of top level implicit union, and the >>> top level element in a script is a call to convex_decomposition() on >>> non-convex input, then we can't meaningfully export to STL. There is a >>> manifoldness check prior to STL export which *should* report this problem >>> (issue #1215). Exporting the same object to AMF can be supported, because >>> we can put each convex polyhedron into a separate volume. >>> >>> In summary, OpenSCAD should support models that contain disjoint >>> subvolumes with shared faces. There are features we need to add and >>> bugs/design flaws we need to fix before this support is complete. >>> >>> On 4 February 2016 at 02:13, <arnholm@arnholm.org> wrote: >>> >>>> On 2016-02-04 06:54, Triffid Hunter wrote: >>>> >>>>> non-manifold means that the topology is somehow ambiguous. >>>>> >>>> >>>> No, it does not. >>>> >>>> An example of non-manifold topology is where a topological edge is >>>> shared by more than 2 faces. >>>> >>>> http://docs.mcneel.com/rhino/5/help/en-us/popup_moreinformation/non-manifold_edges.htm >>>> >>>> It is not ambiguous, and in many cases a desired feature. This kind of >>>> non-manifold topology is much used in ship design when designing FEM models >>>> with shell elements. Often, non-manifold topology is perfectly acceptable >>>> and is not ambiguous in any way. CAD systems like e.g. ACIS ( >>>> https://en.wikipedia.org/wiki/ACIS ) have no issues representing >>>> non-manifold topology. >>>> >>>> In the special case of 3d solid topological models, a non-manifold face >>>> is a face internal to the body, it has material on both sides and does not >>>> describe the external surface of the solid body. That does not mean it is >>>> topologically ambiguous. Such faces may be and are used for subdivision, >>>> for example to guide 3d solid meshing (solid FEM models). Whether such >>>> non-manifold topological entities are desirable or not depends on the >>>> application area, but it is not topologically ambiguous. >>>> >>>> It is only when the topological description is non-existent things like >>>> this become a problem. >>>> >>>> >>>> Carsten Arnholm >>>> >>>> _______________________________________________ >>>> OpenSCAD mailing list >>>> Discuss@lists.openscad.org >>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>> >>>> >>>> >>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> Discuss@lists.openscad.org >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> >>> >> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> >> > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > >

Okay, cool. That probably means we should document the group() operator. And you had to do that because {...} standing alone (not as a module argument) doesn't create a group. This is unfortunately another incompatibility with OpenSCAD2. Doug. On Thursday, 4 February 2016, nop head <nop.head@gmail.com> wrote: > I have used group() explicitly to make a bunch of children into a first > child. > > On 4 February 2016 at 18:04, doug moen <doug@moens.org > <javascript:_e(%7B%7D,'cvml','doug@moens.org');>> wrote: > >> Ronaldo said: "Best than just eliminating the top level implicit union >> would be to have another operator: the set (or aggregate) operator. The set >> operator would collect a set of bodies preserving each one as a separated >> entity. If you union the set, then they become one (possibly manifold) body >> only but before that the set may not represent a manifold. Its bodies may >> not even be disjoint." >> >> We already have a "set (or aggregate)" operator. It is called "group". >> The explicit syntax is 'group() { shape1; shape2; ... }'. You can see this >> operator if you display the CSG tree. Nobody types it explicitly, because >> groups are generated implicitly for every module call (the 'children()' of >> a module call is represented by a group, and the output is always a group). >> >> There is a design flaw in how groups currently work. In short, too many >> groups are being implicitly generated. If the tail argument to a module >> call is a single (non-compound) statement, like a for loop or a module >> call, then the results returned by that statement (which may be a group) >> are wrapped in another group with a single element. This prevents you from >> feeding multiple outputs from one module call into another module as its >> children(). This is why intersection_for() exists. >> >> There is a plan to fix this problem, but it is called "lazy union", >> because the same feature also eliminates the implicit top level union. >> https://github.com/openscad/openscad/issues/350 >> >> OpenSCAD2 fixes the problem by adopting so-called "lazy union" semantics >> for module calls, and also by reinterpreting the "{ ... }" syntax as the >> group constructor. In OpenSCAD2, groups are always constructed explicitly >> using {...} syntax, except for at the top level, where all top level >> objects are implicitly collected into a group. >> >> Even in OpenSCAD2, there is a requirement that each element of a group be >> either another group, or a manifold shape. The CGAL union operator requires >> that its arguments be manifold; that's where the restriction comes from. >> >> Doug Moen. >> >> On 4 February 2016 at 11:13, Ronaldo Persiano <rcmpersiano@gmail.com >> <javascript:_e(%7B%7D,'cvml','rcmpersiano@gmail.com');>> wrote: >> >>> doug moen brings another important aspect to this discussion: " the top >>> level implicit union that occurs before exporting an STL file". STL is >>> intended to represent one object only presumably a 2-manifold and this >>> is a serious limitation of STL format. I agree that, excluding >>> numerical approximation issues, STL allows the recovering of the missing >>> topological information if and only if the geometrical embedding of it is a >>> manifold. As I showed before by examples, we can represent several >>> non-disjoint manifolds in STL as far as they do not have common vertices. >>> But that is very restrictive. >>> >>> I would like to represent not only one body in OSCAD. I would like to >>> represent a set of distinct (not necessarily disjoint) objects. One simple >>> application of that, besides the ones Arholm brought, is an animation of, >>> say, a ball bouncing in a billiard table. If I define a fixed table and a >>> ball on it, as their union is not a 2-manifold, I may have problems. Two >>> gears may have contact. In the real world, objects have contact. >>> >>> Best than just eliminating the top level implicit union would be to >>> have another operator: the set (or aggregate) operator. The set operator >>> would collect a set of bodies preserving each one as a separated entity. If >>> you union the set, then they become one (possibly manifold) body only but >>> before that the set may not represent a manifold. Its bodies may not even >>> be disjoint. May be, I don't know, there is no non-manifold objects in the >>> world but the world itself is not a manifold. >>> >>> If we go in that way, STL should be abandoned. >>> >>> 2016-02-04 13:17 GMT-02:00 doug moen <doug@moens.org >>> <javascript:_e(%7B%7D,'cvml','doug@moens.org');>>: >>> >>>> "a non-manifold face is a face internal to the body, it has material >>>> on both sides and does not describe the external surface of the solid body." >>>> >>>> The ability to partition a solid into a collection of disjoint >>>> subvolumes with shared faces is also useful in OpenSCAD; it's not just a >>>> ship design/ACIS thing. >>>> >>>> One obvious example is 3D printing of multi-material/multi-colour >>>> objects. There have been a number of discussions about how to support this >>>> in OpenSCAD. Internally, the volumes for each colour/material need to be >>>> kept separate and labeled. To export such a model, you either need to >>>> export multiple STL files (one per material/colour), or you need to export >>>> an AMF file with distinct volume elements for each colour/material. In no >>>> case should any of the individual volumes that we track internally or >>>> export contain non-manifold faces. >>>> >>>> This situation can arise in feature request #1562, which requests a >>>> convex_decomposition() operator. The result of this operator is a group of >>>> solids which share faces between them. Each group element is a convex >>>> polyhedron, which is manifold. This feature isn't useful unless we get rid >>>> of the implicit union that would otherwise occur when passing the results >>>> of convex_decomposition() to another module: see issue #350. But, issue >>>> #350 also eliminates the top level implicit union that occurs before >>>> exporting an STL file. If we get rid of top level implicit union, and the >>>> top level element in a script is a call to convex_decomposition() on >>>> non-convex input, then we can't meaningfully export to STL. There is a >>>> manifoldness check prior to STL export which *should* report this problem >>>> (issue #1215). Exporting the same object to AMF can be supported, because >>>> we can put each convex polyhedron into a separate volume. >>>> >>>> In summary, OpenSCAD should support models that contain disjoint >>>> subvolumes with shared faces. There are features we need to add and >>>> bugs/design flaws we need to fix before this support is complete. >>>> >>>> On 4 February 2016 at 02:13, <arnholm@arnholm.org >>>> <javascript:_e(%7B%7D,'cvml','arnholm@arnholm.org');>> wrote: >>>> >>>>> On 2016-02-04 06:54, Triffid Hunter wrote: >>>>> >>>>>> non-manifold means that the topology is somehow ambiguous. >>>>>> >>>>> >>>>> No, it does not. >>>>> >>>>> An example of non-manifold topology is where a topological edge is >>>>> shared by more than 2 faces. >>>>> >>>>> http://docs.mcneel.com/rhino/5/help/en-us/popup_moreinformation/non-manifold_edges.htm >>>>> >>>>> It is not ambiguous, and in many cases a desired feature. This kind of >>>>> non-manifold topology is much used in ship design when designing FEM models >>>>> with shell elements. Often, non-manifold topology is perfectly acceptable >>>>> and is not ambiguous in any way. CAD systems like e.g. ACIS ( >>>>> https://en.wikipedia.org/wiki/ACIS ) have no issues representing >>>>> non-manifold topology. >>>>> >>>>> In the special case of 3d solid topological models, a non-manifold >>>>> face is a face internal to the body, it has material on both sides and does >>>>> not describe the external surface of the solid body. That does not mean it >>>>> is topologically ambiguous. Such faces may be and are used for subdivision, >>>>> for example to guide 3d solid meshing (solid FEM models). Whether such >>>>> non-manifold topological entities are desirable or not depends on the >>>>> application area, but it is not topologically ambiguous. >>>>> >>>>> It is only when the topological description is non-existent things >>>>> like this become a problem. >>>>> >>>>> >>>>> Carsten Arnholm >>>>> >>>>> _______________________________________________ >>>>> OpenSCAD mailing list >>>>> Discuss@lists.openscad.org >>>>> <javascript:_e(%7B%7D,'cvml','Discuss@lists.openscad.org');> >>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> OpenSCAD mailing list >>>> Discuss@lists.openscad.org >>>> <javascript:_e(%7B%7D,'cvml','Discuss@lists.openscad.org');> >>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>> >>>> >>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> Discuss@lists.openscad.org >>> <javascript:_e(%7B%7D,'cvml','Discuss@lists.openscad.org');> >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> >>> >> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> <javascript:_e(%7B%7D,'cvml','Discuss@lists.openscad.org');> >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> >> >

Yes but if {...} made a group, how would you pass multiple children as separate children? On 4 February 2016 at 18:49, doug moen <doug@moens.org> wrote: > Okay, cool. That probably means we should document the group() operator. > > And you had to do that because {...} standing alone (not as a module > argument) doesn't create a group. This is unfortunately another > incompatibility with OpenSCAD2. > > Doug. > > > On Thursday, 4 February 2016, nop head <nop.head@gmail.com> wrote: > >> I have used group() explicitly to make a bunch of children into a first >> child. >> >> On 4 February 2016 at 18:04, doug moen <doug@moens.org> wrote: >> >>> Ronaldo said: "Best than just eliminating the top level implicit union >>> would be to have another operator: the set (or aggregate) operator. The set >>> operator would collect a set of bodies preserving each one as a separated >>> entity. If you union the set, then they become one (possibly manifold) body >>> only but before that the set may not represent a manifold. Its bodies may >>> not even be disjoint." >>> >>> We already have a "set (or aggregate)" operator. It is called "group". >>> The explicit syntax is 'group() { shape1; shape2; ... }'. You can see this >>> operator if you display the CSG tree. Nobody types it explicitly, because >>> groups are generated implicitly for every module call (the 'children()' of >>> a module call is represented by a group, and the output is always a group). >>> >>> There is a design flaw in how groups currently work. In short, too many >>> groups are being implicitly generated. If the tail argument to a module >>> call is a single (non-compound) statement, like a for loop or a module >>> call, then the results returned by that statement (which may be a group) >>> are wrapped in another group with a single element. This prevents you from >>> feeding multiple outputs from one module call into another module as its >>> children(). This is why intersection_for() exists. >>> >>> There is a plan to fix this problem, but it is called "lazy union", >>> because the same feature also eliminates the implicit top level union. >>> https://github.com/openscad/openscad/issues/350 >>> >>> OpenSCAD2 fixes the problem by adopting so-called "lazy union" semantics >>> for module calls, and also by reinterpreting the "{ ... }" syntax as the >>> group constructor. In OpenSCAD2, groups are always constructed explicitly >>> using {...} syntax, except for at the top level, where all top level >>> objects are implicitly collected into a group. >>> >>> Even in OpenSCAD2, there is a requirement that each element of a group >>> be either another group, or a manifold shape. The CGAL union operator >>> requires that its arguments be manifold; that's where the restriction comes >>> from. >>> >>> Doug Moen. >>> >>> On 4 February 2016 at 11:13, Ronaldo Persiano <rcmpersiano@gmail.com> >>> wrote: >>> >>>> doug moen brings another important aspect to this discussion: " the >>>> top level implicit union that occurs before exporting an STL file". STL is >>>> intended to represent one object only presumably a 2-manifold and this >>>> is a serious limitation of STL format. I agree that, excluding >>>> numerical approximation issues, STL allows the recovering of the missing >>>> topological information if and only if the geometrical embedding of it is a >>>> manifold. As I showed before by examples, we can represent several >>>> non-disjoint manifolds in STL as far as they do not have common vertices. >>>> But that is very restrictive. >>>> >>>> I would like to represent not only one body in OSCAD. I would like to >>>> represent a set of distinct (not necessarily disjoint) objects. One simple >>>> application of that, besides the ones Arholm brought, is an animation of, >>>> say, a ball bouncing in a billiard table. If I define a fixed table and a >>>> ball on it, as their union is not a 2-manifold, I may have problems. Two >>>> gears may have contact. In the real world, objects have contact. >>>> >>>> Best than just eliminating the top level implicit union would be to >>>> have another operator: the set (or aggregate) operator. The set operator >>>> would collect a set of bodies preserving each one as a separated entity. If >>>> you union the set, then they become one (possibly manifold) body only but >>>> before that the set may not represent a manifold. Its bodies may not even >>>> be disjoint. May be, I don't know, there is no non-manifold objects in the >>>> world but the world itself is not a manifold. >>>> >>>> If we go in that way, STL should be abandoned. >>>> >>>> 2016-02-04 13:17 GMT-02:00 doug moen <doug@moens.org>: >>>> >>>>> "a non-manifold face is a face internal to the body, it has material >>>>> on both sides and does not describe the external surface of the solid body." >>>>> >>>>> The ability to partition a solid into a collection of disjoint >>>>> subvolumes with shared faces is also useful in OpenSCAD; it's not just a >>>>> ship design/ACIS thing. >>>>> >>>>> One obvious example is 3D printing of multi-material/multi-colour >>>>> objects. There have been a number of discussions about how to support this >>>>> in OpenSCAD. Internally, the volumes for each colour/material need to be >>>>> kept separate and labeled. To export such a model, you either need to >>>>> export multiple STL files (one per material/colour), or you need to export >>>>> an AMF file with distinct volume elements for each colour/material. In no >>>>> case should any of the individual volumes that we track internally or >>>>> export contain non-manifold faces. >>>>> >>>>> This situation can arise in feature request #1562, which requests a >>>>> convex_decomposition() operator. The result of this operator is a group of >>>>> solids which share faces between them. Each group element is a convex >>>>> polyhedron, which is manifold. This feature isn't useful unless we get rid >>>>> of the implicit union that would otherwise occur when passing the results >>>>> of convex_decomposition() to another module: see issue #350. But, issue >>>>> #350 also eliminates the top level implicit union that occurs before >>>>> exporting an STL file. If we get rid of top level implicit union, and the >>>>> top level element in a script is a call to convex_decomposition() on >>>>> non-convex input, then we can't meaningfully export to STL. There is a >>>>> manifoldness check prior to STL export which *should* report this problem >>>>> (issue #1215). Exporting the same object to AMF can be supported, because >>>>> we can put each convex polyhedron into a separate volume. >>>>> >>>>> In summary, OpenSCAD should support models that contain disjoint >>>>> subvolumes with shared faces. There are features we need to add and >>>>> bugs/design flaws we need to fix before this support is complete. >>>>> >>>>> On 4 February 2016 at 02:13, <arnholm@arnholm.org> wrote: >>>>> >>>>>> On 2016-02-04 06:54, Triffid Hunter wrote: >>>>>> >>>>>>> non-manifold means that the topology is somehow ambiguous. >>>>>>> >>>>>> >>>>>> No, it does not. >>>>>> >>>>>> An example of non-manifold topology is where a topological edge is >>>>>> shared by more than 2 faces. >>>>>> >>>>>> http://docs.mcneel.com/rhino/5/help/en-us/popup_moreinformation/non-manifold_edges.htm >>>>>> >>>>>> It is not ambiguous, and in many cases a desired feature. This kind >>>>>> of non-manifold topology is much used in ship design when designing FEM >>>>>> models with shell elements. Often, non-manifold topology is perfectly >>>>>> acceptable and is not ambiguous in any way. CAD systems like e.g. ACIS ( >>>>>> https://en.wikipedia.org/wiki/ACIS ) have no issues representing >>>>>> non-manifold topology. >>>>>> >>>>>> In the special case of 3d solid topological models, a non-manifold >>>>>> face is a face internal to the body, it has material on both sides and does >>>>>> not describe the external surface of the solid body. That does not mean it >>>>>> is topologically ambiguous. Such faces may be and are used for subdivision, >>>>>> for example to guide 3d solid meshing (solid FEM models). Whether such >>>>>> non-manifold topological entities are desirable or not depends on the >>>>>> application area, but it is not topologically ambiguous. >>>>>> >>>>>> It is only when the topological description is non-existent things >>>>>> like this become a problem. >>>>>> >>>>>> >>>>>> Carsten Arnholm >>>>>> >>>>>> _______________________________________________ >>>>>> OpenSCAD mailing list >>>>>> Discuss@lists.openscad.org >>>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>>> >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> OpenSCAD mailing list >>>>> Discuss@lists.openscad.org >>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> OpenSCAD mailing list >>>> Discuss@lists.openscad.org >>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>> >>>> >>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> Discuss@lists.openscad.org >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> >>> >> > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > >

Or do you mean that children are module arguments? On 4 February 2016 at 19:00, nop head <nop.head@gmail.com> wrote: > Yes but if {...} made a group, how would you pass multiple children as > separate children? > > On 4 February 2016 at 18:49, doug moen <doug@moens.org> wrote: > >> Okay, cool. That probably means we should document the group() operator. >> >> And you had to do that because {...} standing alone (not as a module >> argument) doesn't create a group. This is unfortunately another >> incompatibility with OpenSCAD2. >> >> Doug. >> >> >> On Thursday, 4 February 2016, nop head <nop.head@gmail.com> wrote: >> >>> I have used group() explicitly to make a bunch of children into a first >>> child. >>> >>> On 4 February 2016 at 18:04, doug moen <doug@moens.org> wrote: >>> >>>> Ronaldo said: "Best than just eliminating the top level implicit union >>>> would be to have another operator: the set (or aggregate) operator. The set >>>> operator would collect a set of bodies preserving each one as a separated >>>> entity. If you union the set, then they become one (possibly manifold) body >>>> only but before that the set may not represent a manifold. Its bodies may >>>> not even be disjoint." >>>> >>>> We already have a "set (or aggregate)" operator. It is called "group". >>>> The explicit syntax is 'group() { shape1; shape2; ... }'. You can see this >>>> operator if you display the CSG tree. Nobody types it explicitly, because >>>> groups are generated implicitly for every module call (the 'children()' of >>>> a module call is represented by a group, and the output is always a group). >>>> >>>> There is a design flaw in how groups currently work. In short, too many >>>> groups are being implicitly generated. If the tail argument to a module >>>> call is a single (non-compound) statement, like a for loop or a module >>>> call, then the results returned by that statement (which may be a group) >>>> are wrapped in another group with a single element. This prevents you from >>>> feeding multiple outputs from one module call into another module as its >>>> children(). This is why intersection_for() exists. >>>> >>>> There is a plan to fix this problem, but it is called "lazy union", >>>> because the same feature also eliminates the implicit top level union. >>>> https://github.com/openscad/openscad/issues/350 >>>> >>>> OpenSCAD2 fixes the problem by adopting so-called "lazy union" >>>> semantics for module calls, and also by reinterpreting the "{ ... }" syntax >>>> as the group constructor. In OpenSCAD2, groups are always constructed >>>> explicitly using {...} syntax, except for at the top level, where all top >>>> level objects are implicitly collected into a group. >>>> >>>> Even in OpenSCAD2, there is a requirement that each element of a group >>>> be either another group, or a manifold shape. The CGAL union operator >>>> requires that its arguments be manifold; that's where the restriction comes >>>> from. >>>> >>>> Doug Moen. >>>> >>>> On 4 February 2016 at 11:13, Ronaldo Persiano <rcmpersiano@gmail.com> >>>> wrote: >>>> >>>>> doug moen brings another important aspect to this discussion: " the >>>>> top level implicit union that occurs before exporting an STL file". STL is >>>>> intended to represent one object only presumably a 2-manifold and this >>>>> is a serious limitation of STL format. I agree that, excluding >>>>> numerical approximation issues, STL allows the recovering of the missing >>>>> topological information if and only if the geometrical embedding of it is a >>>>> manifold. As I showed before by examples, we can represent several >>>>> non-disjoint manifolds in STL as far as they do not have common vertices. >>>>> But that is very restrictive. >>>>> >>>>> I would like to represent not only one body in OSCAD. I would like to >>>>> represent a set of distinct (not necessarily disjoint) objects. One simple >>>>> application of that, besides the ones Arholm brought, is an animation of, >>>>> say, a ball bouncing in a billiard table. If I define a fixed table and a >>>>> ball on it, as their union is not a 2-manifold, I may have problems. Two >>>>> gears may have contact. In the real world, objects have contact. >>>>> >>>>> Best than just eliminating the top level implicit union would be to >>>>> have another operator: the set (or aggregate) operator. The set operator >>>>> would collect a set of bodies preserving each one as a separated entity. If >>>>> you union the set, then they become one (possibly manifold) body only but >>>>> before that the set may not represent a manifold. Its bodies may not even >>>>> be disjoint. May be, I don't know, there is no non-manifold objects in the >>>>> world but the world itself is not a manifold. >>>>> >>>>> If we go in that way, STL should be abandoned. >>>>> >>>>> 2016-02-04 13:17 GMT-02:00 doug moen <doug@moens.org>: >>>>> >>>>>> "a non-manifold face is a face internal to the body, it has material >>>>>> on both sides and does not describe the external surface of the solid body." >>>>>> >>>>>> The ability to partition a solid into a collection of disjoint >>>>>> subvolumes with shared faces is also useful in OpenSCAD; it's not just a >>>>>> ship design/ACIS thing. >>>>>> >>>>>> One obvious example is 3D printing of multi-material/multi-colour >>>>>> objects. There have been a number of discussions about how to support this >>>>>> in OpenSCAD. Internally, the volumes for each colour/material need to be >>>>>> kept separate and labeled. To export such a model, you either need to >>>>>> export multiple STL files (one per material/colour), or you need to export >>>>>> an AMF file with distinct volume elements for each colour/material. In no >>>>>> case should any of the individual volumes that we track internally or >>>>>> export contain non-manifold faces. >>>>>> >>>>>> This situation can arise in feature request #1562, which requests a >>>>>> convex_decomposition() operator. The result of this operator is a group of >>>>>> solids which share faces between them. Each group element is a convex >>>>>> polyhedron, which is manifold. This feature isn't useful unless we get rid >>>>>> of the implicit union that would otherwise occur when passing the results >>>>>> of convex_decomposition() to another module: see issue #350. But, issue >>>>>> #350 also eliminates the top level implicit union that occurs before >>>>>> exporting an STL file. If we get rid of top level implicit union, and the >>>>>> top level element in a script is a call to convex_decomposition() on >>>>>> non-convex input, then we can't meaningfully export to STL. There is a >>>>>> manifoldness check prior to STL export which *should* report this problem >>>>>> (issue #1215). Exporting the same object to AMF can be supported, because >>>>>> we can put each convex polyhedron into a separate volume. >>>>>> >>>>>> In summary, OpenSCAD should support models that contain disjoint >>>>>> subvolumes with shared faces. There are features we need to add and >>>>>> bugs/design flaws we need to fix before this support is complete. >>>>>> >>>>>> On 4 February 2016 at 02:13, <arnholm@arnholm.org> wrote: >>>>>> >>>>>>> On 2016-02-04 06:54, Triffid Hunter wrote: >>>>>>> >>>>>>>> non-manifold means that the topology is somehow ambiguous. >>>>>>>> >>>>>>> >>>>>>> No, it does not. >>>>>>> >>>>>>> An example of non-manifold topology is where a topological edge is >>>>>>> shared by more than 2 faces. >>>>>>> >>>>>>> http://docs.mcneel.com/rhino/5/help/en-us/popup_moreinformation/non-manifold_edges.htm >>>>>>> >>>>>>> It is not ambiguous, and in many cases a desired feature. This kind >>>>>>> of non-manifold topology is much used in ship design when designing FEM >>>>>>> models with shell elements. Often, non-manifold topology is perfectly >>>>>>> acceptable and is not ambiguous in any way. CAD systems like e.g. ACIS ( >>>>>>> https://en.wikipedia.org/wiki/ACIS ) have no issues representing >>>>>>> non-manifold topology. >>>>>>> >>>>>>> In the special case of 3d solid topological models, a non-manifold >>>>>>> face is a face internal to the body, it has material on both sides and does >>>>>>> not describe the external surface of the solid body. That does not mean it >>>>>>> is topologically ambiguous. Such faces may be and are used for subdivision, >>>>>>> for example to guide 3d solid meshing (solid FEM models). Whether such >>>>>>> non-manifold topological entities are desirable or not depends on the >>>>>>> application area, but it is not topologically ambiguous. >>>>>>> >>>>>>> It is only when the topological description is non-existent things >>>>>>> like this become a problem. >>>>>>> >>>>>>> >>>>>>> Carsten Arnholm >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OpenSCAD mailing list >>>>>>> Discuss@lists.openscad.org >>>>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OpenSCAD mailing list >>>>>> Discuss@lists.openscad.org >>>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> OpenSCAD mailing list >>>>> Discuss@lists.openscad.org >>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> OpenSCAD mailing list >>>> Discuss@lists.openscad.org >>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>> >>>> >>> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> >> >

Consider this code: module m() { cube(10,center=true); sphere(6,center=true); }; m() returns a group containing two children, a cube and a sphere. The use of '{...}' is necessary here to construct a group containing more than one child. Now consider this: module m2() { { cube(10,center=true); sphere(6,center=true); } cylinder(r=1,h=20,center=true); } I would like m2() to return a group with 2 children; the first child is a group of a cube and sphere, the second child is the cylinder. What actually happens is that the inner {....} brackets are ignored, and a group of 3 shapes is returned. This, I think, is the situation where the group(){...} syntax must be used explicitly. If {...} worked the way I think it should work, then you wouldn't need to call group() explicitly. We wouldn't need group() at all, and we could just use {...} in the CSG tree. In a related matter, I also think that variables defined within {...} should be local to the {...} in all cases, but that doesn't happen either, in the same case where {...} fails to form a group. Doug. On 4 February 2016 at 14:00, nop head <nop.head@gmail.com> wrote: > Yes but if {...} made a group, how would you pass multiple children as > separate children? > > On 4 February 2016 at 18:49, doug moen <doug@moens.org> wrote: > >> Okay, cool. That probably means we should document the group() operator. >> >> And you had to do that because {...} standing alone (not as a module >> argument) doesn't create a group. This is unfortunately another >> incompatibility with OpenSCAD2. >> >> Doug. >> >> >> On Thursday, 4 February 2016, nop head <nop.head@gmail.com> wrote: >> >>> I have used group() explicitly to make a bunch of children into a first >>> child. >>> >>> On 4 February 2016 at 18:04, doug moen <doug@moens.org> wrote: >>> >>>> Ronaldo said: "Best than just eliminating the top level implicit union >>>> would be to have another operator: the set (or aggregate) operator. The set >>>> operator would collect a set of bodies preserving each one as a separated >>>> entity. If you union the set, then they become one (possibly manifold) body >>>> only but before that the set may not represent a manifold. Its bodies may >>>> not even be disjoint." >>>> >>>> We already have a "set (or aggregate)" operator. It is called "group". >>>> The explicit syntax is 'group() { shape1; shape2; ... }'. You can see this >>>> operator if you display the CSG tree. Nobody types it explicitly, because >>>> groups are generated implicitly for every module call (the 'children()' of >>>> a module call is represented by a group, and the output is always a group). >>>> >>>> There is a design flaw in how groups currently work. In short, too many >>>> groups are being implicitly generated. If the tail argument to a module >>>> call is a single (non-compound) statement, like a for loop or a module >>>> call, then the results returned by that statement (which may be a group) >>>> are wrapped in another group with a single element. This prevents you from >>>> feeding multiple outputs from one module call into another module as its >>>> children(). This is why intersection_for() exists. >>>> >>>> There is a plan to fix this problem, but it is called "lazy union", >>>> because the same feature also eliminates the implicit top level union. >>>> https://github.com/openscad/openscad/issues/350 >>>> >>>> OpenSCAD2 fixes the problem by adopting so-called "lazy union" >>>> semantics for module calls, and also by reinterpreting the "{ ... }" syntax >>>> as the group constructor. In OpenSCAD2, groups are always constructed >>>> explicitly using {...} syntax, except for at the top level, where all top >>>> level objects are implicitly collected into a group. >>>> >>>> Even in OpenSCAD2, there is a requirement that each element of a group >>>> be either another group, or a manifold shape. The CGAL union operator >>>> requires that its arguments be manifold; that's where the restriction comes >>>> from. >>>> >>>> Doug Moen. >>>> >>>> On 4 February 2016 at 11:13, Ronaldo Persiano <rcmpersiano@gmail.com> >>>> wrote: >>>> >>>>> doug moen brings another important aspect to this discussion: " the >>>>> top level implicit union that occurs before exporting an STL file". STL is >>>>> intended to represent one object only presumably a 2-manifold and this >>>>> is a serious limitation of STL format. I agree that, excluding >>>>> numerical approximation issues, STL allows the recovering of the missing >>>>> topological information if and only if the geometrical embedding of it is a >>>>> manifold. As I showed before by examples, we can represent several >>>>> non-disjoint manifolds in STL as far as they do not have common vertices. >>>>> But that is very restrictive. >>>>> >>>>> I would like to represent not only one body in OSCAD. I would like to >>>>> represent a set of distinct (not necessarily disjoint) objects. One simple >>>>> application of that, besides the ones Arholm brought, is an animation of, >>>>> say, a ball bouncing in a billiard table. If I define a fixed table and a >>>>> ball on it, as their union is not a 2-manifold, I may have problems. Two >>>>> gears may have contact. In the real world, objects have contact. >>>>> >>>>> Best than just eliminating the top level implicit union would be to >>>>> have another operator: the set (or aggregate) operator. The set operator >>>>> would collect a set of bodies preserving each one as a separated entity. If >>>>> you union the set, then they become one (possibly manifold) body only but >>>>> before that the set may not represent a manifold. Its bodies may not even >>>>> be disjoint. May be, I don't know, there is no non-manifold objects in the >>>>> world but the world itself is not a manifold. >>>>> >>>>> If we go in that way, STL should be abandoned. >>>>> >>>>> 2016-02-04 13:17 GMT-02:00 doug moen <doug@moens.org>: >>>>> >>>>>> "a non-manifold face is a face internal to the body, it has material >>>>>> on both sides and does not describe the external surface of the solid body." >>>>>> >>>>>> The ability to partition a solid into a collection of disjoint >>>>>> subvolumes with shared faces is also useful in OpenSCAD; it's not just a >>>>>> ship design/ACIS thing. >>>>>> >>>>>> One obvious example is 3D printing of multi-material/multi-colour >>>>>> objects. There have been a number of discussions about how to support this >>>>>> in OpenSCAD. Internally, the volumes for each colour/material need to be >>>>>> kept separate and labeled. To export such a model, you either need to >>>>>> export multiple STL files (one per material/colour), or you need to export >>>>>> an AMF file with distinct volume elements for each colour/material. In no >>>>>> case should any of the individual volumes that we track internally or >>>>>> export contain non-manifold faces. >>>>>> >>>>>> This situation can arise in feature request #1562, which requests a >>>>>> convex_decomposition() operator. The result of this operator is a group of >>>>>> solids which share faces between them. Each group element is a convex >>>>>> polyhedron, which is manifold. This feature isn't useful unless we get rid >>>>>> of the implicit union that would otherwise occur when passing the results >>>>>> of convex_decomposition() to another module: see issue #350. But, issue >>>>>> #350 also eliminates the top level implicit union that occurs before >>>>>> exporting an STL file. If we get rid of top level implicit union, and the >>>>>> top level element in a script is a call to convex_decomposition() on >>>>>> non-convex input, then we can't meaningfully export to STL. There is a >>>>>> manifoldness check prior to STL export which *should* report this problem >>>>>> (issue #1215). Exporting the same object to AMF can be supported, because >>>>>> we can put each convex polyhedron into a separate volume. >>>>>> >>>>>> In summary, OpenSCAD should support models that contain disjoint >>>>>> subvolumes with shared faces. There are features we need to add and >>>>>> bugs/design flaws we need to fix before this support is complete. >>>>>> >>>>>> On 4 February 2016 at 02:13, <arnholm@arnholm.org> wrote: >>>>>> >>>>>>> On 2016-02-04 06:54, Triffid Hunter wrote: >>>>>>> >>>>>>>> non-manifold means that the topology is somehow ambiguous. >>>>>>>> >>>>>>> >>>>>>> No, it does not. >>>>>>> >>>>>>> An example of non-manifold topology is where a topological edge is >>>>>>> shared by more than 2 faces. >>>>>>> >>>>>>> http://docs.mcneel.com/rhino/5/help/en-us/popup_moreinformation/non-manifold_edges.htm >>>>>>> >>>>>>> It is not ambiguous, and in many cases a desired feature. This kind >>>>>>> of non-manifold topology is much used in ship design when designing FEM >>>>>>> models with shell elements. Often, non-manifold topology is perfectly >>>>>>> acceptable and is not ambiguous in any way. CAD systems like e.g. ACIS ( >>>>>>> https://en.wikipedia.org/wiki/ACIS ) have no issues representing >>>>>>> non-manifold topology. >>>>>>> >>>>>>> In the special case of 3d solid topological models, a non-manifold >>>>>>> face is a face internal to the body, it has material on both sides and does >>>>>>> not describe the external surface of the solid body. That does not mean it >>>>>>> is topologically ambiguous. Such faces may be and are used for subdivision, >>>>>>> for example to guide 3d solid meshing (solid FEM models). Whether such >>>>>>> non-manifold topological entities are desirable or not depends on the >>>>>>> application area, but it is not topologically ambiguous. >>>>>>> >>>>>>> It is only when the topological description is non-existent things >>>>>>> like this become a problem. >>>>>>> >>>>>>> >>>>>>> Carsten Arnholm >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OpenSCAD mailing list >>>>>>> Discuss@lists.openscad.org >>>>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OpenSCAD mailing list >>>>>> Discuss@lists.openscad.org >>>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> OpenSCAD mailing list >>>>> Discuss@lists.openscad.org >>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> OpenSCAD mailing list >>>> Discuss@lists.openscad.org >>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>> >>>> >>> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> >> > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > >

Well, this open a new world I have never been aware of. But I don't understand what a group is. In a few tests I have just built, two overlapping cubes in a group is previewed as two cubes (I see 24 edges) and rendered as their union (with 12 edges). After all, what is a group? 2016-02-04 18:21 GMT-02:00 doug moen <doug@moens.org>: > Consider this code: > > module m() > { > cube(10,center=true); > sphere(6,center=true); > }; > > m() returns a group containing two children, a cube and a sphere. The use > of '{...}' is necessary here to construct a group containing more than one > child. > > Now consider this: > > module m2() > { > { > cube(10,center=true); > sphere(6,center=true); > } > cylinder(r=1,h=20,center=true); > } > > I would like m2() to return a group with 2 children; the first child is a > group of a cube and sphere, the second child is the cylinder. > > What actually happens is that the inner {....} brackets are ignored, and a > group of 3 shapes is returned. > > This, I think, is the situation where the group(){...} syntax must be used > explicitly. If {...} worked the way I think it should work, then you > wouldn't need to call group() explicitly. We wouldn't need group() at all, > and we could just use {...} in the CSG tree. > > In a related matter, I also think that variables defined within {...} > should be local to the {...} in all cases, but that doesn't happen either, > in the same case where {...} fails to form a group. > > Doug. > > On 4 February 2016 at 14:00, nop head <nop.head@gmail.com> wrote: > >> Yes but if {...} made a group, how would you pass multiple children as >> separate children? >> >> On 4 February 2016 at 18:49, doug moen <doug@moens.org> wrote: >> >>> Okay, cool. That probably means we should document the group() operator. >>> >>> And you had to do that because {...} standing alone (not as a module >>> argument) doesn't create a group. This is unfortunately another >>> incompatibility with OpenSCAD2. >>> >>> Doug. >>> >>> >>> On Thursday, 4 February 2016, nop head <nop.head@gmail.com> wrote: >>> >>>> I have used group() explicitly to make a bunch of children into a first >>>> child. >>>> >>>> On 4 February 2016 at 18:04, doug moen <doug@moens.org> wrote: >>>> >>>>> Ronaldo said: "Best than just eliminating the top level implicit >>>>> union would be to have another operator: the set (or aggregate) operator. >>>>> The set operator would collect a set of bodies preserving each one as a >>>>> separated entity. If you union the set, then they become one (possibly >>>>> manifold) body only but before that the set may not represent a manifold. >>>>> Its bodies may not even be disjoint." >>>>> >>>>> We already have a "set (or aggregate)" operator. It is called "group". >>>>> The explicit syntax is 'group() { shape1; shape2; ... }'. You can see this >>>>> operator if you display the CSG tree. Nobody types it explicitly, because >>>>> groups are generated implicitly for every module call (the 'children()' of >>>>> a module call is represented by a group, and the output is always a group). >>>>> >>>>> There is a design flaw in how groups currently work. In short, too >>>>> many groups are being implicitly generated. If the tail argument to a >>>>> module call is a single (non-compound) statement, like a for loop or a >>>>> module call, then the results returned by that statement (which may be a >>>>> group) are wrapped in another group with a single element. This prevents >>>>> you from feeding multiple outputs from one module call into another module >>>>> as its children(). This is why intersection_for() exists. >>>>> >>>>> There is a plan to fix this problem, but it is called "lazy union", >>>>> because the same feature also eliminates the implicit top level union. >>>>> https://github.com/openscad/openscad/issues/350 >>>>> >>>>> OpenSCAD2 fixes the problem by adopting so-called "lazy union" >>>>> semantics for module calls, and also by reinterpreting the "{ ... }" syntax >>>>> as the group constructor. In OpenSCAD2, groups are always constructed >>>>> explicitly using {...} syntax, except for at the top level, where all top >>>>> level objects are implicitly collected into a group. >>>>> >>>>> Even in OpenSCAD2, there is a requirement that each element of a group >>>>> be either another group, or a manifold shape. The CGAL union operator >>>>> requires that its arguments be manifold; that's where the restriction comes >>>>> from. >>>>> >>>>> Doug Moen. >>>>> >>>>> On 4 February 2016 at 11:13, Ronaldo Persiano <rcmpersiano@gmail.com> >>>>> wrote: >>>>> >>>>>> doug moen brings another important aspect to this discussion: " the >>>>>> top level implicit union that occurs before exporting an STL file". STL is >>>>>> intended to represent one object only presumably a 2-manifold and this >>>>>> is a serious limitation of STL format. I agree that, excluding >>>>>> numerical approximation issues, STL allows the recovering of the missing >>>>>> topological information if and only if the geometrical embedding of it is a >>>>>> manifold. As I showed before by examples, we can represent several >>>>>> non-disjoint manifolds in STL as far as they do not have common vertices. >>>>>> But that is very restrictive. >>>>>> >>>>>> I would like to represent not only one body in OSCAD. I would like to >>>>>> represent a set of distinct (not necessarily disjoint) objects. One simple >>>>>> application of that, besides the ones Arholm brought, is an animation of, >>>>>> say, a ball bouncing in a billiard table. If I define a fixed table and a >>>>>> ball on it, as their union is not a 2-manifold, I may have problems. Two >>>>>> gears may have contact. In the real world, objects have contact. >>>>>> >>>>>> Best than just eliminating the top level implicit union would be to >>>>>> have another operator: the set (or aggregate) operator. The set operator >>>>>> would collect a set of bodies preserving each one as a separated entity. If >>>>>> you union the set, then they become one (possibly manifold) body only but >>>>>> before that the set may not represent a manifold. Its bodies may not even >>>>>> be disjoint. May be, I don't know, there is no non-manifold objects in the >>>>>> world but the world itself is not a manifold. >>>>>> >>>>>> If we go in that way, STL should be abandoned. >>>>>> >>>>>> 2016-02-04 13:17 GMT-02:00 doug moen <doug@moens.org>: >>>>>> >>>>>>> "a non-manifold face is a face internal to the body, it has >>>>>>> material on both sides and does not describe the external surface of the >>>>>>> solid body." >>>>>>> >>>>>>> The ability to partition a solid into a collection of disjoint >>>>>>> subvolumes with shared faces is also useful in OpenSCAD; it's not just a >>>>>>> ship design/ACIS thing. >>>>>>> >>>>>>> One obvious example is 3D printing of multi-material/multi-colour >>>>>>> objects. There have been a number of discussions about how to support this >>>>>>> in OpenSCAD. Internally, the volumes for each colour/material need to be >>>>>>> kept separate and labeled. To export such a model, you either need to >>>>>>> export multiple STL files (one per material/colour), or you need to export >>>>>>> an AMF file with distinct volume elements for each colour/material. In no >>>>>>> case should any of the individual volumes that we track internally or >>>>>>> export contain non-manifold faces. >>>>>>> >>>>>>> This situation can arise in feature request #1562, which requests a >>>>>>> convex_decomposition() operator. The result of this operator is a group of >>>>>>> solids which share faces between them. Each group element is a convex >>>>>>> polyhedron, which is manifold. This feature isn't useful unless we get rid >>>>>>> of the implicit union that would otherwise occur when passing the results >>>>>>> of convex_decomposition() to another module: see issue #350. But, issue >>>>>>> #350 also eliminates the top level implicit union that occurs before >>>>>>> exporting an STL file. If we get rid of top level implicit union, and the >>>>>>> top level element in a script is a call to convex_decomposition() on >>>>>>> non-convex input, then we can't meaningfully export to STL. There is a >>>>>>> manifoldness check prior to STL export which *should* report this problem >>>>>>> (issue #1215). Exporting the same object to AMF can be supported, because >>>>>>> we can put each convex polyhedron into a separate volume. >>>>>>> >>>>>>> In summary, OpenSCAD should support models that contain disjoint >>>>>>> subvolumes with shared faces. There are features we need to add and >>>>>>> bugs/design flaws we need to fix before this support is complete. >>>>>>> >>>>>>> On 4 February 2016 at 02:13, <arnholm@arnholm.org> wrote: >>>>>>> >>>>>>>> On 2016-02-04 06:54, Triffid Hunter wrote: >>>>>>>> >>>>>>>>> non-manifold means that the topology is somehow ambiguous. >>>>>>>>> >>>>>>>> >>>>>>>> No, it does not. >>>>>>>> >>>>>>>> An example of non-manifold topology is where a topological edge is >>>>>>>> shared by more than 2 faces. >>>>>>>> >>>>>>>> http://docs.mcneel.com/rhino/5/help/en-us/popup_moreinformation/non-manifold_edges.htm >>>>>>>> >>>>>>>> It is not ambiguous, and in many cases a desired feature. This kind >>>>>>>> of non-manifold topology is much used in ship design when designing FEM >>>>>>>> models with shell elements. Often, non-manifold topology is perfectly >>>>>>>> acceptable and is not ambiguous in any way. CAD systems like e.g. ACIS ( >>>>>>>> https://en.wikipedia.org/wiki/ACIS ) have no issues representing >>>>>>>> non-manifold topology. >>>>>>>> >>>>>>>> In the special case of 3d solid topological models, a non-manifold >>>>>>>> face is a face internal to the body, it has material on both sides and does >>>>>>>> not describe the external surface of the solid body. That does not mean it >>>>>>>> is topologically ambiguous. Such faces may be and are used for subdivision, >>>>>>>> for example to guide 3d solid meshing (solid FEM models). Whether such >>>>>>>> non-manifold topological entities are desirable or not depends on the >>>>>>>> application area, but it is not topologically ambiguous. >>>>>>>> >>>>>>>> It is only when the topological description is non-existent things >>>>>>>> like this become a problem. >>>>>>>> >>>>>>>> >>>>>>>> Carsten Arnholm >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OpenSCAD mailing list >>>>>>>> Discuss@lists.openscad.org >>>>>>>> >>>>>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OpenSCAD mailing list >>>>>>> Discuss@lists.openscad.org >>>>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OpenSCAD mailing list >>>>>> Discuss@lists.openscad.org >>>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> OpenSCAD mailing list >>>>> Discuss@lists.openscad.org >>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>> >>>>> >>>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> Discuss@lists.openscad.org >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> >>> >> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> >> > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > >

Ronaldo, With implicit union, a group currently acts like union. Doug, If we have: my_module() { cube(); cylinder(); } Then cube() should be children(0) in my_module and cylinder() children(1). If { ...} makes a group then they would both be children(0); On 4 February 2016 at 20:34, Ronaldo Persiano <rcmpersiano@gmail.com> wrote: > Well, this open a new world I have never been aware of. But I don't > understand what a group is. In a few tests I have just built, two > overlapping cubes in a group is previewed as two cubes (I see 24 edges) and > rendered as their union (with 12 edges). After all, what is a group? > > 2016-02-04 18:21 GMT-02:00 doug moen <doug@moens.org>: > >> Consider this code: >> >> module m() >> { >> cube(10,center=true); >> sphere(6,center=true); >> }; >> >> m() returns a group containing two children, a cube and a sphere. The use >> of '{...}' is necessary here to construct a group containing more than one >> child. >> >> Now consider this: >> >> module m2() >> { >> { >> cube(10,center=true); >> sphere(6,center=true); >> } >> cylinder(r=1,h=20,center=true); >> } >> >> I would like m2() to return a group with 2 children; the first child is a >> group of a cube and sphere, the second child is the cylinder. >> >> What actually happens is that the inner {....} brackets are ignored, and >> a group of 3 shapes is returned. >> >> This, I think, is the situation where the group(){...} syntax must be >> used explicitly. If {...} worked the way I think it should work, then you >> wouldn't need to call group() explicitly. We wouldn't need group() at all, >> and we could just use {...} in the CSG tree. >> >> In a related matter, I also think that variables defined within {...} >> should be local to the {...} in all cases, but that doesn't happen either, >> in the same case where {...} fails to form a group. >> >> Doug. >> >> On 4 February 2016 at 14:00, nop head <nop.head@gmail.com> wrote: >> >>> Yes but if {...} made a group, how would you pass multiple children as >>> separate children? >>> >>> On 4 February 2016 at 18:49, doug moen <doug@moens.org> wrote: >>> >>>> Okay, cool. That probably means we should document the group() operator. >>>> >>>> And you had to do that because {...} standing alone (not as a module >>>> argument) doesn't create a group. This is unfortunately another >>>> incompatibility with OpenSCAD2. >>>> >>>> Doug. >>>> >>>> >>>> On Thursday, 4 February 2016, nop head <nop.head@gmail.com> wrote: >>>> >>>>> I have used group() explicitly to make a bunch of children into a >>>>> first child. >>>>> >>>>> On 4 February 2016 at 18:04, doug moen <doug@moens.org> wrote: >>>>> >>>>>> Ronaldo said: "Best than just eliminating the top level implicit >>>>>> union would be to have another operator: the set (or aggregate) operator. >>>>>> The set operator would collect a set of bodies preserving each one as a >>>>>> separated entity. If you union the set, then they become one (possibly >>>>>> manifold) body only but before that the set may not represent a manifold. >>>>>> Its bodies may not even be disjoint." >>>>>> >>>>>> We already have a "set (or aggregate)" operator. It is called >>>>>> "group". The explicit syntax is 'group() { shape1; shape2; ... }'. You can >>>>>> see this operator if you display the CSG tree. Nobody types it explicitly, >>>>>> because groups are generated implicitly for every module call (the >>>>>> 'children()' of a module call is represented by a group, and the output is >>>>>> always a group). >>>>>> >>>>>> There is a design flaw in how groups currently work. In short, too >>>>>> many groups are being implicitly generated. If the tail argument to a >>>>>> module call is a single (non-compound) statement, like a for loop or a >>>>>> module call, then the results returned by that statement (which may be a >>>>>> group) are wrapped in another group with a single element. This prevents >>>>>> you from feeding multiple outputs from one module call into another module >>>>>> as its children(). This is why intersection_for() exists. >>>>>> >>>>>> There is a plan to fix this problem, but it is called "lazy union", >>>>>> because the same feature also eliminates the implicit top level union. >>>>>> https://github.com/openscad/openscad/issues/350 >>>>>> >>>>>> OpenSCAD2 fixes the problem by adopting so-called "lazy union" >>>>>> semantics for module calls, and also by reinterpreting the "{ ... }" syntax >>>>>> as the group constructor. In OpenSCAD2, groups are always constructed >>>>>> explicitly using {...} syntax, except for at the top level, where all top >>>>>> level objects are implicitly collected into a group. >>>>>> >>>>>> Even in OpenSCAD2, there is a requirement that each element of a >>>>>> group be either another group, or a manifold shape. The CGAL union operator >>>>>> requires that its arguments be manifold; that's where the restriction comes >>>>>> from. >>>>>> >>>>>> Doug Moen. >>>>>> >>>>>> On 4 February 2016 at 11:13, Ronaldo Persiano <rcmpersiano@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> doug moen brings another important aspect to this discussion: " the >>>>>>> top level implicit union that occurs before exporting an STL file". STL is >>>>>>> intended to represent one object only presumably a 2-manifold and this >>>>>>> is a serious limitation of STL format. I agree that, excluding >>>>>>> numerical approximation issues, STL allows the recovering of the missing >>>>>>> topological information if and only if the geometrical embedding of it is a >>>>>>> manifold. As I showed before by examples, we can represent several >>>>>>> non-disjoint manifolds in STL as far as they do not have common vertices. >>>>>>> But that is very restrictive. >>>>>>> >>>>>>> I would like to represent not only one body in OSCAD. I would like >>>>>>> to represent a set of distinct (not necessarily disjoint) objects. One >>>>>>> simple application of that, besides the ones Arholm brought, is an >>>>>>> animation of, say, a ball bouncing in a billiard table. If I define a fixed >>>>>>> table and a ball on it, as their union is not a 2-manifold, I may have >>>>>>> problems. Two gears may have contact. In the real world, objects have >>>>>>> contact. >>>>>>> >>>>>>> Best than just eliminating the top level implicit union would be to >>>>>>> have another operator: the set (or aggregate) operator. The set operator >>>>>>> would collect a set of bodies preserving each one as a separated entity. If >>>>>>> you union the set, then they become one (possibly manifold) body only but >>>>>>> before that the set may not represent a manifold. Its bodies may not even >>>>>>> be disjoint. May be, I don't know, there is no non-manifold objects in the >>>>>>> world but the world itself is not a manifold. >>>>>>> >>>>>>> If we go in that way, STL should be abandoned. >>>>>>> >>>>>>> 2016-02-04 13:17 GMT-02:00 doug moen <doug@moens.org>: >>>>>>> >>>>>>>> "a non-manifold face is a face internal to the body, it has >>>>>>>> material on both sides and does not describe the external surface of the >>>>>>>> solid body." >>>>>>>> >>>>>>>> The ability to partition a solid into a collection of disjoint >>>>>>>> subvolumes with shared faces is also useful in OpenSCAD; it's not just a >>>>>>>> ship design/ACIS thing. >>>>>>>> >>>>>>>> One obvious example is 3D printing of multi-material/multi-colour >>>>>>>> objects. There have been a number of discussions about how to support this >>>>>>>> in OpenSCAD. Internally, the volumes for each colour/material need to be >>>>>>>> kept separate and labeled. To export such a model, you either need to >>>>>>>> export multiple STL files (one per material/colour), or you need to export >>>>>>>> an AMF file with distinct volume elements for each colour/material. In no >>>>>>>> case should any of the individual volumes that we track internally or >>>>>>>> export contain non-manifold faces. >>>>>>>> >>>>>>>> This situation can arise in feature request #1562, which requests a >>>>>>>> convex_decomposition() operator. The result of this operator is a group of >>>>>>>> solids which share faces between them. Each group element is a convex >>>>>>>> polyhedron, which is manifold. This feature isn't useful unless we get rid >>>>>>>> of the implicit union that would otherwise occur when passing the results >>>>>>>> of convex_decomposition() to another module: see issue #350. But, issue >>>>>>>> #350 also eliminates the top level implicit union that occurs before >>>>>>>> exporting an STL file. If we get rid of top level implicit union, and the >>>>>>>> top level element in a script is a call to convex_decomposition() on >>>>>>>> non-convex input, then we can't meaningfully export to STL. There is a >>>>>>>> manifoldness check prior to STL export which *should* report this problem >>>>>>>> (issue #1215). Exporting the same object to AMF can be supported, because >>>>>>>> we can put each convex polyhedron into a separate volume. >>>>>>>> >>>>>>>> In summary, OpenSCAD should support models that contain disjoint >>>>>>>> subvolumes with shared faces. There are features we need to add and >>>>>>>> bugs/design flaws we need to fix before this support is complete. >>>>>>>> >>>>>>>> On 4 February 2016 at 02:13, <arnholm@arnholm.org> wrote: >>>>>>>> >>>>>>>>> On 2016-02-04 06:54, Triffid Hunter wrote: >>>>>>>>> >>>>>>>>>> non-manifold means that the topology is somehow ambiguous. >>>>>>>>>> >>>>>>>>> >>>>>>>>> No, it does not. >>>>>>>>> >>>>>>>>> An example of non-manifold topology is where a topological edge is >>>>>>>>> shared by more than 2 faces. >>>>>>>>> >>>>>>>>> http://docs.mcneel.com/rhino/5/help/en-us/popup_moreinformation/non-manifold_edges.htm >>>>>>>>> >>>>>>>>> It is not ambiguous, and in many cases a desired feature. This >>>>>>>>> kind of non-manifold topology is much used in ship design when designing >>>>>>>>> FEM models with shell elements. Often, non-manifold topology is perfectly >>>>>>>>> acceptable and is not ambiguous in any way. CAD systems like e.g. ACIS ( >>>>>>>>> https://en.wikipedia.org/wiki/ACIS ) have no issues representing >>>>>>>>> non-manifold topology. >>>>>>>>> >>>>>>>>> In the special case of 3d solid topological models, a non-manifold >>>>>>>>> face is a face internal to the body, it has material on both sides and does >>>>>>>>> not describe the external surface of the solid body. That does not mean it >>>>>>>>> is topologically ambiguous. Such faces may be and are used for subdivision, >>>>>>>>> for example to guide 3d solid meshing (solid FEM models). Whether such >>>>>>>>> non-manifold topological entities are desirable or not depends on the >>>>>>>>> application area, but it is not topologically ambiguous. >>>>>>>>> >>>>>>>>> It is only when the topological description is non-existent things >>>>>>>>> like this become a problem. >>>>>>>>> >>>>>>>>> >>>>>>>>> Carsten Arnholm >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> OpenSCAD mailing list >>>>>>>>> Discuss@lists.openscad.org >>>>>>>>> >>>>>>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OpenSCAD mailing list >>>>>>>> Discuss@lists.openscad.org >>>>>>>> >>>>>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OpenSCAD mailing list >>>>>>> Discuss@lists.openscad.org >>>>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OpenSCAD mailing list >>>>>> Discuss@lists.openscad.org >>>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>>> >>>>>> >>>>> >>>> _______________________________________________ >>>> OpenSCAD mailing list >>>> Discuss@lists.openscad.org >>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>> >>>> >>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> Discuss@lists.openscad.org >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> >>> >> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> >> > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > >

Nop head, If we have: my_module() { cube(); cylinder(); } then my_module is called with two children, a cube and a cylinder. The children() are a group. The only way to pass two children to a module is to use the {...} syntax, so of course {...} makes a group. This is the way I've always understood OpenSCAD to work. Apparently you have a different way of thinking about it? On 4 February 2016 at 15:47, nop head <nop.head@gmail.com> wrote: > Ronaldo, > > With implicit union, a group currently acts like union. > > Doug, > > If we have: > > my_module() { > cube(); > cylinder(); > } > > Then cube() should be children(0) in my_module and cylinder() children(1). > If { ...} makes a group then they would both be children(0); > > > On 4 February 2016 at 20:34, Ronaldo Persiano <rcmpersiano@gmail.com> > wrote: > >> Well, this open a new world I have never been aware of. But I don't >> understand what a group is. In a few tests I have just built, two >> overlapping cubes in a group is previewed as two cubes (I see 24 edges) and >> rendered as their union (with 12 edges). After all, what is a group? >> >> 2016-02-04 18:21 GMT-02:00 doug moen <doug@moens.org>: >> >>> Consider this code: >>> >>> module m() >>> { >>> cube(10,center=true); >>> sphere(6,center=true); >>> }; >>> >>> m() returns a group containing two children, a cube and a sphere. The >>> use of '{...}' is necessary here to construct a group containing more than >>> one child. >>> >>> Now consider this: >>> >>> module m2() >>> { >>> { >>> cube(10,center=true); >>> sphere(6,center=true); >>> } >>> cylinder(r=1,h=20,center=true); >>> } >>> >>> I would like m2() to return a group with 2 children; the first child is >>> a group of a cube and sphere, the second child is the cylinder. >>> >>> What actually happens is that the inner {....} brackets are ignored, and >>> a group of 3 shapes is returned. >>> >>> This, I think, is the situation where the group(){...} syntax must be >>> used explicitly. If {...} worked the way I think it should work, then you >>> wouldn't need to call group() explicitly. We wouldn't need group() at all, >>> and we could just use {...} in the CSG tree. >>> >>> In a related matter, I also think that variables defined within {...} >>> should be local to the {...} in all cases, but that doesn't happen either, >>> in the same case where {...} fails to form a group. >>> >>> Doug. >>> >>> On 4 February 2016 at 14:00, nop head <nop.head@gmail.com> wrote: >>> >>>> Yes but if {...} made a group, how would you pass multiple children as >>>> separate children? >>>> >>>> On 4 February 2016 at 18:49, doug moen <doug@moens.org> wrote: >>>> >>>>> Okay, cool. That probably means we should document the group() >>>>> operator. >>>>> >>>>> And you had to do that because {...} standing alone (not as a module >>>>> argument) doesn't create a group. This is unfortunately another >>>>> incompatibility with OpenSCAD2. >>>>> >>>>> Doug. >>>>> >>>>> >>>>> On Thursday, 4 February 2016, nop head <nop.head@gmail.com> wrote: >>>>> >>>>>> I have used group() explicitly to make a bunch of children into a >>>>>> first child. >>>>>> >>>>>> On 4 February 2016 at 18:04, doug moen <doug@moens.org> wrote: >>>>>> >>>>>>> Ronaldo said: "Best than just eliminating the top level implicit >>>>>>> union would be to have another operator: the set (or aggregate) operator. >>>>>>> The set operator would collect a set of bodies preserving each one as a >>>>>>> separated entity. If you union the set, then they become one (possibly >>>>>>> manifold) body only but before that the set may not represent a manifold. >>>>>>> Its bodies may not even be disjoint." >>>>>>> >>>>>>> We already have a "set (or aggregate)" operator. It is called >>>>>>> "group". The explicit syntax is 'group() { shape1; shape2; ... }'. You can >>>>>>> see this operator if you display the CSG tree. Nobody types it explicitly, >>>>>>> because groups are generated implicitly for every module call (the >>>>>>> 'children()' of a module call is represented by a group, and the output is >>>>>>> always a group). >>>>>>> >>>>>>> There is a design flaw in how groups currently work. In short, too >>>>>>> many groups are being implicitly generated. If the tail argument to a >>>>>>> module call is a single (non-compound) statement, like a for loop or a >>>>>>> module call, then the results returned by that statement (which may be a >>>>>>> group) are wrapped in another group with a single element. This prevents >>>>>>> you from feeding multiple outputs from one module call into another module >>>>>>> as its children(). This is why intersection_for() exists. >>>>>>> >>>>>>> There is a plan to fix this problem, but it is called "lazy union", >>>>>>> because the same feature also eliminates the implicit top level union. >>>>>>> https://github.com/openscad/openscad/issues/350 >>>>>>> >>>>>>> OpenSCAD2 fixes the problem by adopting so-called "lazy union" >>>>>>> semantics for module calls, and also by reinterpreting the "{ ... }" syntax >>>>>>> as the group constructor. In OpenSCAD2, groups are always constructed >>>>>>> explicitly using {...} syntax, except for at the top level, where all top >>>>>>> level objects are implicitly collected into a group. >>>>>>> >>>>>>> Even in OpenSCAD2, there is a requirement that each element of a >>>>>>> group be either another group, or a manifold shape. The CGAL union operator >>>>>>> requires that its arguments be manifold; that's where the restriction comes >>>>>>> from. >>>>>>> >>>>>>> Doug Moen. >>>>>>> >>>>>>> On 4 February 2016 at 11:13, Ronaldo Persiano <rcmpersiano@gmail.com >>>>>>> > wrote: >>>>>>> >>>>>>>> doug moen brings another important aspect to this discussion: " >>>>>>>> the top level implicit union that occurs before exporting an STL file". STL >>>>>>>> is intended to represent one object only presumably a 2-manifold and this >>>>>>>> is a serious limitation of STL format. I agree that, excluding >>>>>>>> numerical approximation issues, STL allows the recovering of the missing >>>>>>>> topological information if and only if the geometrical embedding of it is a >>>>>>>> manifold. As I showed before by examples, we can represent several >>>>>>>> non-disjoint manifolds in STL as far as they do not have common vertices. >>>>>>>> But that is very restrictive. >>>>>>>> >>>>>>>> I would like to represent not only one body in OSCAD. I would like >>>>>>>> to represent a set of distinct (not necessarily disjoint) objects. One >>>>>>>> simple application of that, besides the ones Arholm brought, is an >>>>>>>> animation of, say, a ball bouncing in a billiard table. If I define a fixed >>>>>>>> table and a ball on it, as their union is not a 2-manifold, I may have >>>>>>>> problems. Two gears may have contact. In the real world, objects have >>>>>>>> contact. >>>>>>>> >>>>>>>> Best than just eliminating the top level implicit union would be >>>>>>>> to have another operator: the set (or aggregate) operator. The set operator >>>>>>>> would collect a set of bodies preserving each one as a separated entity. If >>>>>>>> you union the set, then they become one (possibly manifold) body only but >>>>>>>> before that the set may not represent a manifold. Its bodies may not even >>>>>>>> be disjoint. May be, I don't know, there is no non-manifold objects in the >>>>>>>> world but the world itself is not a manifold. >>>>>>>> >>>>>>>> If we go in that way, STL should be abandoned. >>>>>>>> >>>>>>>> 2016-02-04 13:17 GMT-02:00 doug moen <doug@moens.org>: >>>>>>>> >>>>>>>>> "a non-manifold face is a face internal to the body, it has >>>>>>>>> material on both sides and does not describe the external surface of the >>>>>>>>> solid body." >>>>>>>>> >>>>>>>>> The ability to partition a solid into a collection of disjoint >>>>>>>>> subvolumes with shared faces is also useful in OpenSCAD; it's not just a >>>>>>>>> ship design/ACIS thing. >>>>>>>>> >>>>>>>>> One obvious example is 3D printing of multi-material/multi-colour >>>>>>>>> objects. There have been a number of discussions about how to support this >>>>>>>>> in OpenSCAD. Internally, the volumes for each colour/material need to be >>>>>>>>> kept separate and labeled. To export such a model, you either need to >>>>>>>>> export multiple STL files (one per material/colour), or you need to export >>>>>>>>> an AMF file with distinct volume elements for each colour/material. In no >>>>>>>>> case should any of the individual volumes that we track internally or >>>>>>>>> export contain non-manifold faces. >>>>>>>>> >>>>>>>>> This situation can arise in feature request #1562, which requests >>>>>>>>> a convex_decomposition() operator. The result of this operator is a group >>>>>>>>> of solids which share faces between them. Each group element is a convex >>>>>>>>> polyhedron, which is manifold. This feature isn't useful unless we get rid >>>>>>>>> of the implicit union that would otherwise occur when passing the results >>>>>>>>> of convex_decomposition() to another module: see issue #350. But, issue >>>>>>>>> #350 also eliminates the top level implicit union that occurs before >>>>>>>>> exporting an STL file. If we get rid of top level implicit union, and the >>>>>>>>> top level element in a script is a call to convex_decomposition() on >>>>>>>>> non-convex input, then we can't meaningfully export to STL. There is a >>>>>>>>> manifoldness check prior to STL export which *should* report this problem >>>>>>>>> (issue #1215). Exporting the same object to AMF can be supported, because >>>>>>>>> we can put each convex polyhedron into a separate volume. >>>>>>>>> >>>>>>>>> In summary, OpenSCAD should support models that contain disjoint >>>>>>>>> subvolumes with shared faces. There are features we need to add and >>>>>>>>> bugs/design flaws we need to fix before this support is complete. >>>>>>>>> >>>>>>>>> On 4 February 2016 at 02:13, <arnholm@arnholm.org> wrote: >>>>>>>>> >>>>>>>>>> On 2016-02-04 06:54, Triffid Hunter wrote: >>>>>>>>>> >>>>>>>>>>> non-manifold means that the topology is somehow ambiguous. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> No, it does not. >>>>>>>>>> >>>>>>>>>> An example of non-manifold topology is where a topological edge >>>>>>>>>> is shared by more than 2 faces. >>>>>>>>>> >>>>>>>>>> http://docs.mcneel.com/rhino/5/help/en-us/popup_moreinformation/non-manifold_edges.htm >>>>>>>>>> >>>>>>>>>> It is not ambiguous, and in many cases a desired feature. This >>>>>>>>>> kind of non-manifold topology is much used in ship design when designing >>>>>>>>>> FEM models with shell elements. Often, non-manifold topology is perfectly >>>>>>>>>> acceptable and is not ambiguous in any way. CAD systems like e.g. ACIS ( >>>>>>>>>> https://en.wikipedia.org/wiki/ACIS ) have no issues representing >>>>>>>>>> non-manifold topology. >>>>>>>>>> >>>>>>>>>> In the special case of 3d solid topological models, a >>>>>>>>>> non-manifold face is a face internal to the body, it has material on both >>>>>>>>>> sides and does not describe the external surface of the solid body. That >>>>>>>>>> does not mean it is topologically ambiguous. Such faces may be and are used >>>>>>>>>> for subdivision, for example to guide 3d solid meshing (solid FEM models). >>>>>>>>>> Whether such non-manifold topological entities are desirable or not >>>>>>>>>> depends on the application area, but it is not topologically ambiguous. >>>>>>>>>> >>>>>>>>>> It is only when the topological description is non-existent >>>>>>>>>> things like this become a problem. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Carsten Arnholm >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> OpenSCAD mailing list >>>>>>>>>> Discuss@lists.openscad.org >>>>>>>>>> >>>>>>>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> OpenSCAD mailing list >>>>>>>>> Discuss@lists.openscad.org >>>>>>>>> >>>>>>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OpenSCAD mailing list >>>>>>>> Discuss@lists.openscad.org >>>>>>>> >>>>>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OpenSCAD mailing list >>>>>>> Discuss@lists.openscad.org >>>>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>>>> >>>>>>> >>>>>> >>>>> _______________________________________________ >>>>> OpenSCAD mailing list >>>>> Discuss@lists.openscad.org >>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> OpenSCAD mailing list >>>> Discuss@lists.openscad.org >>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>> >>>> >>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> Discuss@lists.openscad.org >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> >>> >> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> >> > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > >

nop head said: <quote> Ronaldo, With implicit union, a group currently acts like union. </quote> I didn't use implicit group but: group(){ cube(50); translate([0,0,30]) cube(50); } which is previewed as two cubes and rendered as their union. 2016-02-04 18:58 GMT-02:00 doug moen <doug@moens.org>: > Nop head, If we have: > > my_module() { > cube(); > cylinder(); > } > > then my_module is called with two children, a cube and a cylinder. The > children() are a group. The only way to pass two children to a module is to > use the {...} syntax, so of course {...} makes a group. > > This is the way I've always understood OpenSCAD to work. Apparently you > have a different way of thinking about it? > > > On 4 February 2016 at 15:47, nop head <nop.head@gmail.com> wrote: > >> Ronaldo, >> >> With implicit union, a group currently acts like union. >> >> Doug, >> >> If we have: >> >> my_module() { >> cube(); >> cylinder(); >> } >> >> Then cube() should be children(0) in my_module and cylinder() >> children(1). If { ...} makes a group then they would both be children(0); >> >> >> On 4 February 2016 at 20:34, Ronaldo Persiano <rcmpersiano@gmail.com> >> wrote: >> >>> Well, this open a new world I have never been aware of. But I don't >>> understand what a group is. In a few tests I have just built, two >>> overlapping cubes in a group is previewed as two cubes (I see 24 edges) and >>> rendered as their union (with 12 edges). After all, what is a group? >>> >>> 2016-02-04 18:21 GMT-02:00 doug moen <doug@moens.org>: >>> >>>> Consider this code: >>>> >>>> module m() >>>> { >>>> cube(10,center=true); >>>> sphere(6,center=true); >>>> }; >>>> >>>> m() returns a group containing two children, a cube and a sphere. The >>>> use of '{...}' is necessary here to construct a group containing more than >>>> one child. >>>> >>>> Now consider this: >>>> >>>> module m2() >>>> { >>>> { >>>> cube(10,center=true); >>>> sphere(6,center=true); >>>> } >>>> cylinder(r=1,h=20,center=true); >>>> } >>>> >>>> I would like m2() to return a group with 2 children; the first child is >>>> a group of a cube and sphere, the second child is the cylinder. >>>> >>>> What actually happens is that the inner {....} brackets are ignored, >>>> and a group of 3 shapes is returned. >>>> >>>> This, I think, is the situation where the group(){...} syntax must be >>>> used explicitly. If {...} worked the way I think it should work, then you >>>> wouldn't need to call group() explicitly. We wouldn't need group() at all, >>>> and we could just use {...} in the CSG tree. >>>> >>>> In a related matter, I also think that variables defined within {...} >>>> should be local to the {...} in all cases, but that doesn't happen either, >>>> in the same case where {...} fails to form a group. >>>> >>>> Doug. >>>> >>>> On 4 February 2016 at 14:00, nop head <nop.head@gmail.com> wrote: >>>> >>>>> Yes but if {...} made a group, how would you pass multiple children as >>>>> separate children? >>>>> >>>>> On 4 February 2016 at 18:49, doug moen <doug@moens.org> wrote: >>>>> >>>>>> Okay, cool. That probably means we should document the group() >>>>>> operator. >>>>>> >>>>>> And you had to do that because {...} standing alone (not as a module >>>>>> argument) doesn't create a group. This is unfortunately another >>>>>> incompatibility with OpenSCAD2. >>>>>> >>>>>> Doug. >>>>>> >>>>>> >>>>>> On Thursday, 4 February 2016, nop head <nop.head@gmail.com> wrote: >>>>>> >>>>>>> I have used group() explicitly to make a bunch of children into a >>>>>>> first child. >>>>>>> >>>>>>> On 4 February 2016 at 18:04, doug moen <doug@moens.org> wrote: >>>>>>> >>>>>>>> Ronaldo said: "Best than just eliminating the top level implicit >>>>>>>> union would be to have another operator: the set (or aggregate) operator. >>>>>>>> The set operator would collect a set of bodies preserving each one as a >>>>>>>> separated entity. If you union the set, then they become one (possibly >>>>>>>> manifold) body only but before that the set may not represent a manifold. >>>>>>>> Its bodies may not even be disjoint." >>>>>>>> >>>>>>>> We already have a "set (or aggregate)" operator. It is called >>>>>>>> "group". The explicit syntax is 'group() { shape1; shape2; ... }'. You can >>>>>>>> see this operator if you display the CSG tree. Nobody types it explicitly, >>>>>>>> because groups are generated implicitly for every module call (the >>>>>>>> 'children()' of a module call is represented by a group, and the output is >>>>>>>> always a group). >>>>>>>> >>>>>>>> There is a design flaw in how groups currently work. In short, too >>>>>>>> many groups are being implicitly generated. If the tail argument to a >>>>>>>> module call is a single (non-compound) statement, like a for loop or a >>>>>>>> module call, then the results returned by that statement (which may be a >>>>>>>> group) are wrapped in another group with a single element. This prevents >>>>>>>> you from feeding multiple outputs from one module call into another module >>>>>>>> as its children(). This is why intersection_for() exists. >>>>>>>> >>>>>>>> There is a plan to fix this problem, but it is called "lazy union", >>>>>>>> because the same feature also eliminates the implicit top level union. >>>>>>>> https://github.com/openscad/openscad/issues/350 >>>>>>>> >>>>>>>> OpenSCAD2 fixes the problem by adopting so-called "lazy union" >>>>>>>> semantics for module calls, and also by reinterpreting the "{ ... }" syntax >>>>>>>> as the group constructor. In OpenSCAD2, groups are always constructed >>>>>>>> explicitly using {...} syntax, except for at the top level, where all top >>>>>>>> level objects are implicitly collected into a group. >>>>>>>> >>>>>>>> Even in OpenSCAD2, there is a requirement that each element of a >>>>>>>> group be either another group, or a manifold shape. The CGAL union operator >>>>>>>> requires that its arguments be manifold; that's where the restriction comes >>>>>>>> from. >>>>>>>> >>>>>>>> Doug Moen. >>>>>>>> >>>>>>>> On 4 February 2016 at 11:13, Ronaldo Persiano < >>>>>>>> rcmpersiano@gmail.com> wrote: >>>>>>>> >>>>>>>>> doug moen brings another important aspect to this discussion: " >>>>>>>>> the top level implicit union that occurs before exporting an STL file". STL >>>>>>>>> is intended to represent one object only presumably a 2-manifold and this >>>>>>>>> is a serious limitation of STL format. I agree that, excluding >>>>>>>>> numerical approximation issues, STL allows the recovering of the missing >>>>>>>>> topological information if and only if the geometrical embedding of it is a >>>>>>>>> manifold. As I showed before by examples, we can represent several >>>>>>>>> non-disjoint manifolds in STL as far as they do not have common vertices. >>>>>>>>> But that is very restrictive. >>>>>>>>> >>>>>>>>> I would like to represent not only one body in OSCAD. I would like >>>>>>>>> to represent a set of distinct (not necessarily disjoint) objects. One >>>>>>>>> simple application of that, besides the ones Arholm brought, is an >>>>>>>>> animation of, say, a ball bouncing in a billiard table. If I define a fixed >>>>>>>>> table and a ball on it, as their union is not a 2-manifold, I may have >>>>>>>>> problems. Two gears may have contact. In the real world, objects have >>>>>>>>> contact. >>>>>>>>> >>>>>>>>> Best than just eliminating the top level implicit union would be >>>>>>>>> to have another operator: the set (or aggregate) operator. The set operator >>>>>>>>> would collect a set of bodies preserving each one as a separated entity. If >>>>>>>>> you union the set, then they become one (possibly manifold) body only but >>>>>>>>> before that the set may not represent a manifold. Its bodies may not even >>>>>>>>> be disjoint. May be, I don't know, there is no non-manifold objects in the >>>>>>>>> world but the world itself is not a manifold. >>>>>>>>> >>>>>>>>> If we go in that way, STL should be abandoned. >>>>>>>>> >>>>>>>>> 2016-02-04 13:17 GMT-02:00 doug moen <doug@moens.org>: >>>>>>>>> >>>>>>>>>> "a non-manifold face is a face internal to the body, it has >>>>>>>>>> material on both sides and does not describe the external surface of the >>>>>>>>>> solid body." >>>>>>>>>> >>>>>>>>>> The ability to partition a solid into a collection of disjoint >>>>>>>>>> subvolumes with shared faces is also useful in OpenSCAD; it's not just a >>>>>>>>>> ship design/ACIS thing. >>>>>>>>>> >>>>>>>>>> One obvious example is 3D printing of multi-material/multi-colour >>>>>>>>>> objects. There have been a number of discussions about how to support this >>>>>>>>>> in OpenSCAD. Internally, the volumes for each colour/material need to be >>>>>>>>>> kept separate and labeled. To export such a model, you either need to >>>>>>>>>> export multiple STL files (one per material/colour), or you need to export >>>>>>>>>> an AMF file with distinct volume elements for each colour/material. In no >>>>>>>>>> case should any of the individual volumes that we track internally or >>>>>>>>>> export contain non-manifold faces. >>>>>>>>>> >>>>>>>>>> This situation can arise in feature request #1562, which requests >>>>>>>>>> a convex_decomposition() operator. The result of this operator is a group >>>>>>>>>> of solids which share faces between them. Each group element is a convex >>>>>>>>>> polyhedron, which is manifold. This feature isn't useful unless we get rid >>>>>>>>>> of the implicit union that would otherwise occur when passing the results >>>>>>>>>> of convex_decomposition() to another module: see issue #350. But, issue >>>>>>>>>> #350 also eliminates the top level implicit union that occurs before >>>>>>>>>> exporting an STL file. If we get rid of top level implicit union, and the >>>>>>>>>> top level element in a script is a call to convex_decomposition() on >>>>>>>>>> non-convex input, then we can't meaningfully export to STL. There is a >>>>>>>>>> manifoldness check prior to STL export which *should* report this problem >>>>>>>>>> (issue #1215). Exporting the same object to AMF can be supported, because >>>>>>>>>> we can put each convex polyhedron into a separate volume. >>>>>>>>>> >>>>>>>>>> In summary, OpenSCAD should support models that contain disjoint >>>>>>>>>> subvolumes with shared faces. There are features we need to add and >>>>>>>>>> bugs/design flaws we need to fix before this support is complete. >>>>>>>>>> >>>>>>>>>> On 4 February 2016 at 02:13, <arnholm@arnholm.org> wrote: >>>>>>>>>> >>>>>>>>>>> On 2016-02-04 06:54, Triffid Hunter wrote: >>>>>>>>>>> >>>>>>>>>>>> non-manifold means that the topology is somehow ambiguous. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> No, it does not. >>>>>>>>>>> >>>>>>>>>>> An example of non-manifold topology is where a topological edge >>>>>>>>>>> is shared by more than 2 faces. >>>>>>>>>>> >>>>>>>>>>> http://docs.mcneel.com/rhino/5/help/en-us/popup_moreinformation/non-manifold_edges.htm >>>>>>>>>>> >>>>>>>>>>> It is not ambiguous, and in many cases a desired feature. This >>>>>>>>>>> kind of non-manifold topology is much used in ship design when designing >>>>>>>>>>> FEM models with shell elements. Often, non-manifold topology is perfectly >>>>>>>>>>> acceptable and is not ambiguous in any way. CAD systems like e.g. ACIS ( >>>>>>>>>>> https://en.wikipedia.org/wiki/ACIS ) have no issues >>>>>>>>>>> representing non-manifold topology. >>>>>>>>>>> >>>>>>>>>>> In the special case of 3d solid topological models, a >>>>>>>>>>> non-manifold face is a face internal to the body, it has material on both >>>>>>>>>>> sides and does not describe the external surface of the solid body. That >>>>>>>>>>> does not mean it is topologically ambiguous. Such faces may be and are used >>>>>>>>>>> for subdivision, for example to guide 3d solid meshing (solid FEM models). >>>>>>>>>>> Whether such non-manifold topological entities are desirable or not >>>>>>>>>>> depends on the application area, but it is not topologically ambiguous. >>>>>>>>>>> >>>>>>>>>>> It is only when the topological description is non-existent >>>>>>>>>>> things like this become a problem. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Carsten Arnholm >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> OpenSCAD mailing list >>>>>>>>>>> Discuss@lists.openscad.org >>>>>>>>>>> >>>>>>>>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> OpenSCAD mailing list >>>>>>>>>> Discuss@lists.openscad.org >>>>>>>>>> >>>>>>>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> OpenSCAD mailing list >>>>>>>>> Discuss@lists.openscad.org >>>>>>>>> >>>>>>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OpenSCAD mailing list >>>>>>>> Discuss@lists.openscad.org >>>>>>>> >>>>>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>>>>> >>>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> OpenSCAD mailing list >>>>>> Discuss@lists.openscad.org >>>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> OpenSCAD mailing list >>>>> Discuss@lists.openscad.org >>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> OpenSCAD mailing list >>>> Discuss@lists.openscad.org >>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>>> >>>> >>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> Discuss@lists.openscad.org >>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >>> >>> >> >> _______________________________________________ >> OpenSCAD mailing list >> Discuss@lists.openscad.org >> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >> >> > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > >