By mistake, forgetting union() in some copy paste sequence, I found that, as far as I can see, using only {} has the same effect as union(){}. Example: color([1,0,0]) union(){ sphere(50); translate([0,0,60]) sphere(35); translate([0,0,110]) sphere(25); } makes exactly the same red snow man as: color([1,0,0]) { sphere(50); translate([0,0,60]) sphere(35); translate([0,0,110]) sphere(25); } I suppose it's an effect of lazy union, but are there any hidden pitfalls, and is this an intended feature that can be relied upon to work in the future? -- Sent from: http://forum.openscad.org/

> On Nov 24, 2017, at 1:58 AM, Troberg <troberg.anders@gmail.com> wrote: > > color([1,0,0]) { > sphere(50); > translate([0,0,60]) > sphere(35); > translate([0,0,110]) > sphere(25); > } > > I suppose it's an effect of lazy union, but are there any hidden pitfalls, > and is this an intended feature that can be relied upon to work in the > future? > The {} grouping belongs to the color() module, as color() is just another transformation. You can do the same for e.g. “translate([x,y,x]) { cube(); sphere(); }”. This is indeed an implicit union. We may change this in the future to not actually perform a full union operation, but in that case we’d announce it properly and probably offer some sort of backwards compatibility or upgrade functionality. -Marius

intersection() union() { ... stuff ... }

intersection() { ... stuff ... }

On 11/23/2017 10:58 PM, Troberg wrote: > By mistake, forgetting union() in some copy paste sequence, I found that, as > far as I can see, using only {} has the same effect as union(){}. > > Example: > > color([1,0,0]) > union(){ > sphere(50); > translate([0,0,60]) > sphere(35); > translate([0,0,110]) > sphere(25); > } > > makes exactly the same red snow man as: > > color([1,0,0]) > { > sphere(50); > translate([0,0,60]) > sphere(35); > translate([0,0,110]) > sphere(25); > } > > I suppose it's an effect of lazy union, but are there any hidden pitfalls, > and is this an intended feature that can be relied upon to work in the > future? Note that it is not always equivalent; operators do not always union their children. For instance: intersection() union() { ... stuff ... } is very different from intersection() { ... stuff ... }

OK, so, the smart thing is to use union() explicit, just to make sure. It's neater anyway, it's always good to show what you are doing. -- Sent from: http://forum.openscad.org/