NH
nop head
Thu, Feb 4, 2016 11:06 PM
Ah, I see now. Children are passed as a group and children(i) indexes into
it and fishes one out. So the outer { ... } creates a group but inner ones
don't.
Yes it would be better if all { } create a group and a new scope. Then I
don't think group() is needed in the syntax.
Now here is a weird one: -
a = 1;
group() {
a = 2;
b = 3;
echo(a,b);
}
echo(a);
WARNING: Ignoring unknown variable 'b'.
ECHO: 1, undef
ECHO: 1
I expected group to force { ...} to make an new scope but it does something
weird instead. However union() does force a new scope:
a = 1;
union() {
a = 2;
b = 3;
echo(a,b);
}
echo(a);
ECHO: 2, 3
ECHO: 1
On 4 February 2016 at 20:58, doug moen doug@moens.org wrote:
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
Ah, I see now. Children are passed as a group and children(i) indexes into
it and fishes one out. So the outer { ... } creates a group but inner ones
don't.
Yes it would be better if all { } create a group and a new scope. Then I
don't think group() is needed in the syntax.
Now here is a weird one: -
a = 1;
group() {
a = 2;
b = 3;
echo(a,b);
}
echo(a);
WARNING: Ignoring unknown variable 'b'.
ECHO: 1, undef
ECHO: 1
I expected group to force { ...} to make an new scope but it does something
weird instead. However union() does force a new scope:
a = 1;
union() {
a = 2;
b = 3;
echo(a,b);
}
echo(a);
ECHO: 2, 3
ECHO: 1
On 4 February 2016 at 20:58, doug moen <doug@moens.org> wrote:
> 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
>
>
NH
nop head
Thu, Feb 4, 2016 11:12 PM
I am not sure why you say it is previewed as two cubes. It looks like a
union to me unless I turn on show edges. But that is exactly what union()
does. The preview never does a real union. It just draws both objects.
On 4 February 2016 at 21:36, Ronaldo Persiano rcmpersiano@gmail.com wrote:
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
I am not sure why you say it is previewed as two cubes. It looks like a
union to me unless I turn on show edges. But that is exactly what union()
does. The preview never does a real union. It just draws both objects.
On 4 February 2016 at 21:36, Ronaldo Persiano <rcmpersiano@gmail.com> wrote:
> 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
>>
>>
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>
MK
Marius Kintel
Thu, Feb 4, 2016 11:35 PM
That looks like a bug.
-Marius
On Feb 4, 2016, at 18:06 PM, nop head nop.head@gmail.com wrote:
Now here is a weird one: […]
WARNING: Ignoring unknown variable 'b'.
ECHO: 1, undef
ECHO: 1
I expected group to force { ...} to make an new scope but it does something weird instead. However union() does force a new scope:
That looks like a bug.
-Marius
> On Feb 4, 2016, at 18:06 PM, nop head <nop.head@gmail.com> wrote:
>
> Now here is a weird one: […]
>
> WARNING: Ignoring unknown variable 'b'.
> ECHO: 1, undef
> ECHO: 1
>
> I expected group to force { ...} to make an new scope but it does something weird instead. However union() does force a new scope:
>
RP
Ronaldo Persiano
Fri, Feb 5, 2016 12:32 AM
I'm sorry but I still do not understand what is a group. What is the
difference between grouping and unioning?
2016-02-04 21:35 GMT-02:00 Marius Kintel marius@kintel.net:
That looks like a bug.
-Marius
On Feb 4, 2016, at 18:06 PM, nop head nop.head@gmail.com wrote:
Now here is a weird one: […]
WARNING: Ignoring unknown variable 'b'.
ECHO: 1, undef
ECHO: 1
I expected group to force { ...} to make an new scope but it does
something weird instead. However union() does force a new scope:
I'm sorry but I still do not understand what is a group. What is the
difference between grouping and unioning?
2016-02-04 21:35 GMT-02:00 Marius Kintel <marius@kintel.net>:
> That looks like a bug.
>
> -Marius
>
> > On Feb 4, 2016, at 18:06 PM, nop head <nop.head@gmail.com> wrote:
> >
> > Now here is a weird one: […]
> >
> > WARNING: Ignoring unknown variable 'b'.
> > ECHO: 1, undef
> > ECHO: 1
> >
> > I expected group to force { ...} to make an new scope but it does
> something weird instead. However union() does force a new scope:
> >
>
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
DM
doug moen
Fri, Feb 5, 2016 12:48 AM
Ronaldo, do you know what a module is? A module is kind of like a function,
except that you can pass zero or more shapes to a module as arguments (the
shape arguments are called "children"), and a module returns zero or more
shapes as results. "union" is one example of a module. For example,
'union(){cube(10);circle(6);}' is a call to the "union" module. This module
call has two shape arguments, a cube and a circle, and returns a single
shape as its result. A group is the data structure used to pass multiple
shapes as arguments to a module, and is the data structure used when
multiple shapes are returned as results. You can explicitly create a group
using the syntax 'group(){...}' but this is of limited usefulness (although
nop head, as an expert user, has found a use for groups).
On 4 February 2016 at 19:32, Ronaldo Persiano rcmpersiano@gmail.com wrote:
I'm sorry but I still do not understand what is a group. What is the
difference between grouping and unioning?
2016-02-04 21:35 GMT-02:00 Marius Kintel marius@kintel.net:
That looks like a bug.
-Marius
On Feb 4, 2016, at 18:06 PM, nop head nop.head@gmail.com wrote:
Now here is a weird one: […]
WARNING: Ignoring unknown variable 'b'.
ECHO: 1, undef
ECHO: 1
I expected group to force { ...} to make an new scope but it does
something weird instead. However union() does force a new scope:
Ronaldo, do you know what a module is? A module is kind of like a function,
except that you can pass zero or more shapes to a module as arguments (the
shape arguments are called "children"), and a module returns zero or more
shapes as results. "union" is one example of a module. For example,
'union(){cube(10);circle(6);}' is a call to the "union" module. This module
call has two shape arguments, a cube and a circle, and returns a single
shape as its result. A group is the data structure used to pass multiple
shapes as arguments to a module, and is the data structure used when
multiple shapes are returned as results. You can explicitly create a group
using the syntax 'group(){...}' but this is of limited usefulness (although
nop head, as an expert user, has found a use for groups).
On 4 February 2016 at 19:32, Ronaldo Persiano <rcmpersiano@gmail.com> wrote:
> I'm sorry but I still do not understand what is a group. What is the
> difference between grouping and unioning?
>
> 2016-02-04 21:35 GMT-02:00 Marius Kintel <marius@kintel.net>:
>
>> That looks like a bug.
>>
>> -Marius
>>
>> > On Feb 4, 2016, at 18:06 PM, nop head <nop.head@gmail.com> wrote:
>> >
>> > Now here is a weird one: […]
>> >
>> > WARNING: Ignoring unknown variable 'b'.
>> > ECHO: 1, undef
>> > ECHO: 1
>> >
>> > I expected group to force { ...} to make an new scope but it does
>> something weird instead. However union() does force a new scope:
>> >
>>
>>
>> _______________________________________________
>> 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
>
>
RP
Ronaldo Persiano
Fri, Feb 5, 2016 1:38 AM
Thank you, Doug, for your explanation. I grasped a bit more of modules from
it. I can't see however why did bring groups to the discussion. You has
said that the set operator I would like to have in OSCAD already exists it
is the group operator. I can't see how.
What I meant by a set is a aggregate of independent bodies. A collection of
meshes. Each component of a set might be a manifold but their union are
possibly not. You could display the set by displaying independently each of
its components without any explicit or implicit union. So the system would
never check if the set is a manifold or if their components are disjoint.
A set would be a way to represent different materials of a body to be
printed. Or to represent the set of parts of a mechanism where they touch
each other. Or a (ghost) ball crossing a wall in an animation. No boolean
operations would be required for that.
I can imagine doing boolean operations with sets (after all, Minkovski
added two sets!) but that would be another story.
2016-02-04 22:48 GMT-02:00 doug moen doug@moens.org:
Ronaldo, do you know what a module is? A module is kind of like a
function, except that you can pass zero or more shapes to a module as
arguments (the shape arguments are called "children"), and a module returns
zero or more shapes as results. "union" is one example of a module. For
example, 'union(){cube(10);circle(6);}' is a call to the "union" module.
This module call has two shape arguments, a cube and a circle, and returns
a single shape as its result. A group is the data structure used to pass
multiple shapes as arguments to a module, and is the data structure used
when multiple shapes are returned as results. You can explicitly create a
group using the syntax 'group(){...}' but this is of limited usefulness
(although nop head, as an expert user, has found a use for groups).
On 4 February 2016 at 19:32, Ronaldo Persiano rcmpersiano@gmail.com
wrote:
I'm sorry but I still do not understand what is a group. What is the
difference between grouping and unioning?
2016-02-04 21:35 GMT-02:00 Marius Kintel marius@kintel.net:
That looks like a bug.
-Marius
On Feb 4, 2016, at 18:06 PM, nop head nop.head@gmail.com wrote:
Now here is a weird one: […]
WARNING: Ignoring unknown variable 'b'.
ECHO: 1, undef
ECHO: 1
I expected group to force { ...} to make an new scope but it does
something weird instead. However union() does force a new scope:
Thank you, Doug, for your explanation. I grasped a bit more of modules from
it. I can't see however why did bring groups to the discussion. You has
said that the set operator I would like to have in OSCAD already exists it
is the group operator. I can't see how.
What I meant by a set is a aggregate of independent bodies. A collection of
meshes. Each component of a set might be a manifold but their union are
possibly not. You could display the set by displaying independently each of
its components without any explicit or implicit union. So the system would
never check if the set is a manifold or if their components are disjoint.
A set would be a way to represent different materials of a body to be
printed. Or to represent the set of parts of a mechanism where they touch
each other. Or a (ghost) ball crossing a wall in an animation. No boolean
operations would be required for that.
I can imagine doing boolean operations with sets (after all, Minkovski
added two sets!) but that would be another story.
2016-02-04 22:48 GMT-02:00 doug moen <doug@moens.org>:
> Ronaldo, do you know what a module is? A module is kind of like a
> function, except that you can pass zero or more shapes to a module as
> arguments (the shape arguments are called "children"), and a module returns
> zero or more shapes as results. "union" is one example of a module. For
> example, 'union(){cube(10);circle(6);}' is a call to the "union" module.
> This module call has two shape arguments, a cube and a circle, and returns
> a single shape as its result. A group is the data structure used to pass
> multiple shapes as arguments to a module, and is the data structure used
> when multiple shapes are returned as results. You can explicitly create a
> group using the syntax 'group(){...}' but this is of limited usefulness
> (although nop head, as an expert user, has found a use for groups).
>
> On 4 February 2016 at 19:32, Ronaldo Persiano <rcmpersiano@gmail.com>
> wrote:
>
>> I'm sorry but I still do not understand what is a group. What is the
>> difference between grouping and unioning?
>>
>> 2016-02-04 21:35 GMT-02:00 Marius Kintel <marius@kintel.net>:
>>
>>> That looks like a bug.
>>>
>>> -Marius
>>>
>>> > On Feb 4, 2016, at 18:06 PM, nop head <nop.head@gmail.com> wrote:
>>> >
>>> > Now here is a weird one: […]
>>> >
>>> > WARNING: Ignoring unknown variable 'b'.
>>> > ECHO: 1, undef
>>> > ECHO: 1
>>> >
>>> > I expected group to force { ...} to make an new scope but it does
>>> something weird instead. However union() does force a new scope:
>>> >
>>>
>>>
>>> _______________________________________________
>>> 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
>
>
DM
doug moen
Fri, Feb 5, 2016 2:10 AM
Yes, there have been a number of discussions about adding these kinds of
capabilities to OpenSCAD, but the plan is to use groups as the "aggregates
of independent shapes" and to change or extend the language semantics to
make groups more useful.
On 4 February 2016 at 20:38, Ronaldo Persiano rcmpersiano@gmail.com wrote:
Thank you, Doug, for your explanation. I grasped a bit more of modules
from it. I can't see however why did bring groups to the discussion. You
has said that the set operator I would like to have in OSCAD already
exists it is the group operator. I can't see how.
What I meant by a set is a aggregate of independent bodies. A collection
of meshes. Each component of a set might be a manifold but their union are
possibly not. You could display the set by displaying independently each of
its components without any explicit or implicit union. So the system would
never check if the set is a manifold or if their components are disjoint.
A set would be a way to represent different materials of a body to be
printed. Or to represent the set of parts of a mechanism where they touch
each other. Or a (ghost) ball crossing a wall in an animation. No boolean
operations would be required for that.
I can imagine doing boolean operations with sets (after all, Minkovski
added two sets!) but that would be another story.
2016-02-04 22:48 GMT-02:00 doug moen doug@moens.org:
Ronaldo, do you know what a module is? A module is kind of like a
function, except that you can pass zero or more shapes to a module as
arguments (the shape arguments are called "children"), and a module returns
zero or more shapes as results. "union" is one example of a module. For
example, 'union(){cube(10);circle(6);}' is a call to the "union" module.
This module call has two shape arguments, a cube and a circle, and returns
a single shape as its result. A group is the data structure used to pass
multiple shapes as arguments to a module, and is the data structure used
when multiple shapes are returned as results. You can explicitly create a
group using the syntax 'group(){...}' but this is of limited usefulness
(although nop head, as an expert user, has found a use for groups).
On 4 February 2016 at 19:32, Ronaldo Persiano rcmpersiano@gmail.com
wrote:
I'm sorry but I still do not understand what is a group. What is the
difference between grouping and unioning?
2016-02-04 21:35 GMT-02:00 Marius Kintel marius@kintel.net:
That looks like a bug.
-Marius
On Feb 4, 2016, at 18:06 PM, nop head nop.head@gmail.com wrote:
Now here is a weird one: […]
WARNING: Ignoring unknown variable 'b'.
ECHO: 1, undef
ECHO: 1
I expected group to force { ...} to make an new scope but it does
something weird instead. However union() does force a new scope:
Yes, there have been a number of discussions about adding these kinds of
capabilities to OpenSCAD, but the plan is to use groups as the "aggregates
of independent shapes" and to change or extend the language semantics to
make groups more useful.
On 4 February 2016 at 20:38, Ronaldo Persiano <rcmpersiano@gmail.com> wrote:
> Thank you, Doug, for your explanation. I grasped a bit more of modules
> from it. I can't see however why did bring groups to the discussion. You
> has said that the set operator I would like to have in OSCAD already
> exists it is the group operator. I can't see how.
>
> What I meant by a set is a aggregate of independent bodies. A collection
> of meshes. Each component of a set might be a manifold but their union are
> possibly not. You could display the set by displaying independently each of
> its components without any explicit or implicit union. So the system would
> never check if the set is a manifold or if their components are disjoint.
>
> A set would be a way to represent different materials of a body to be
> printed. Or to represent the set of parts of a mechanism where they touch
> each other. Or a (ghost) ball crossing a wall in an animation. No boolean
> operations would be required for that.
>
> I can imagine doing boolean operations with sets (after all, Minkovski
> added two sets!) but that would be another story.
>
> 2016-02-04 22:48 GMT-02:00 doug moen <doug@moens.org>:
>
>> Ronaldo, do you know what a module is? A module is kind of like a
>> function, except that you can pass zero or more shapes to a module as
>> arguments (the shape arguments are called "children"), and a module returns
>> zero or more shapes as results. "union" is one example of a module. For
>> example, 'union(){cube(10);circle(6);}' is a call to the "union" module.
>> This module call has two shape arguments, a cube and a circle, and returns
>> a single shape as its result. A group is the data structure used to pass
>> multiple shapes as arguments to a module, and is the data structure used
>> when multiple shapes are returned as results. You can explicitly create a
>> group using the syntax 'group(){...}' but this is of limited usefulness
>> (although nop head, as an expert user, has found a use for groups).
>>
>> On 4 February 2016 at 19:32, Ronaldo Persiano <rcmpersiano@gmail.com>
>> wrote:
>>
>>> I'm sorry but I still do not understand what is a group. What is the
>>> difference between grouping and unioning?
>>>
>>> 2016-02-04 21:35 GMT-02:00 Marius Kintel <marius@kintel.net>:
>>>
>>>> That looks like a bug.
>>>>
>>>> -Marius
>>>>
>>>> > On Feb 4, 2016, at 18:06 PM, nop head <nop.head@gmail.com> wrote:
>>>> >
>>>> > Now here is a weird one: […]
>>>> >
>>>> > WARNING: Ignoring unknown variable 'b'.
>>>> > ECHO: 1, undef
>>>> > ECHO: 1
>>>> >
>>>> > I expected group to force { ...} to make an new scope but it does
>>>> something weird instead. However union() does force a new scope:
>>>> >
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>
>
A
arnholm@arnholm.org
Fri, Feb 5, 2016 10:24 AM
On 2016-02-05 02:38, Ronaldo Persiano wrote:
What I meant by a set is a aggregate of independent bodies. A
collection of meshes. Each component of a set might be a manifold but
their union are possibly not. You could display the set by displaying
independently each of its components without any explicit or implicit
union. So the system would never check if the set is a manifold or if
their components are disjoint.
I have seen similar needs as well. In AngelScript CSG you can create
aggregates of independent bodies:
double r=10,s=15,h=20;
solid@[] solids = { sphere(r), cube(s), cylinder(h,r/2) };
"solids" is here the variable name of a collection of disjoint solids,
in this case a sphere, a cube and a cylinder. The "[]" syntax indicates
an array serving the same purpose as your set, and the "solid@" syntax
indicates a reference to a solid. So "solid@[]" is an array of
references to (disjoint) solids.
Obviously you can use it later to do
solid@ model = union3d(solids);
i.e. an explicit union of the solids from the array into a single solid.
Whether or not to retain non-manifold edges/faces in such a union would
typically need an additional parameter.
OpenSCAD could probably benefit from similar features.
Carsten Arnholm
http://arnholm.org/
On 2016-02-05 02:38, Ronaldo Persiano wrote:
> What I meant by a set is a aggregate of independent bodies. A
> collection of meshes. Each component of a set might be a manifold but
> their union are possibly not. You could display the set by displaying
> independently each of its components without any explicit or implicit
> union. So the system would never check if the set is a manifold or if
> their components are disjoint.
I have seen similar needs as well. In AngelScript CSG you can create
aggregates of independent bodies:
double r=10,s=15,h=20;
solid@[] solids = { sphere(r), cube(s), cylinder(h,r/2) };
"solids" is here the variable name of a collection of disjoint solids,
in this case a sphere, a cube and a cylinder. The "[]" syntax indicates
an array serving the same purpose as your set, and the "solid@" syntax
indicates a reference to a solid. So "solid@[]" is an array of
references to (disjoint) solids.
Obviously you can use it later to do
solid@ model = union3d(solids);
i.e. an explicit union of the solids from the array into a single solid.
Whether or not to retain non-manifold edges/faces in such a union would
typically need an additional parameter.
OpenSCAD could probably benefit from similar features.
Carsten Arnholm
http://arnholm.org/
RP
Ronaldo Persiano
Fri, Feb 5, 2016 1:22 PM
Thank you for the reference, Carsten. I will take a look on it.
2016-02-05 8:24 GMT-02:00 arnholm@arnholm.org:
On 2016-02-05 02:38, Ronaldo Persiano wrote:
What I meant by a set is a aggregate of independent bodies. A
collection of meshes. Each component of a set might be a manifold but
their union are possibly not. You could display the set by displaying
independently each of its components without any explicit or implicit
union. So the system would never check if the set is a manifold or if
their components are disjoint.
I have seen similar needs as well. In AngelScript CSG you can create
aggregates of independent bodies:
double r=10,s=15,h=20;
solid@[] solids = { sphere(r), cube(s), cylinder(h,r/2) };
"solids" is here the variable name of a collection of disjoint solids, in
this case a sphere, a cube and a cylinder. The "[]" syntax indicates an
array serving the same purpose as your set, and the "solid@" syntax
indicates a reference to a solid. So "solid@[]" is an array of references
to (disjoint) solids.
Obviously you can use it later to do
solid@ model = union3d(solids);
i.e. an explicit union of the solids from the array into a single solid.
Whether or not to retain non-manifold edges/faces in such a union would
typically need an additional parameter.
OpenSCAD could probably benefit from similar features.
Carsten Arnholm
http://arnholm.org/
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Thank you for the reference, Carsten. I will take a look on it.
2016-02-05 8:24 GMT-02:00 <arnholm@arnholm.org>:
> On 2016-02-05 02:38, Ronaldo Persiano wrote:
>
>> What I meant by a set is a aggregate of independent bodies. A
>> collection of meshes. Each component of a set might be a manifold but
>> their union are possibly not. You could display the set by displaying
>> independently each of its components without any explicit or implicit
>> union. So the system would never check if the set is a manifold or if
>> their components are disjoint.
>>
>
> I have seen similar needs as well. In AngelScript CSG you can create
> aggregates of independent bodies:
>
> double r=10,s=15,h=20;
> solid@[] solids = { sphere(r), cube(s), cylinder(h,r/2) };
>
> "solids" is here the variable name of a collection of disjoint solids, in
> this case a sphere, a cube and a cylinder. The "[]" syntax indicates an
> array serving the same purpose as your set, and the "solid@" syntax
> indicates a reference to a solid. So "solid@[]" is an array of references
> to (disjoint) solids.
>
> Obviously you can use it later to do
>
> solid@ model = union3d(solids);
>
> i.e. an explicit union of the solids from the array into a single solid.
> Whether or not to retain non-manifold edges/faces in such a union would
> typically need an additional parameter.
>
> OpenSCAD could probably benefit from similar features.
>
> Carsten Arnholm
> http://arnholm.org/
>
>
>
>
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
