If I have understood well your improvement, the bounding box of the
following solid might not overestimate the true bounding box:
difference(){
cube([100,100,20],center=true);
difference(){
cube(200);
cube([100,100,20],center=true);
}
}
2017-08-13 19:13 GMT+01:00 Carsten Arnholm arnholm@arnholm.org:
On 13. aug. 2017 18:04, doug moen wrote:
For the difference operation, difference(shape1,shape2), I just return
the bounding box of shape1 and ignore shape2. This is an example where the
result is an overestimate.
That can be improved. What I do is compute the intersection ranges in x,y
and z separately. If there is no intersection in either direction, then the
bounding box of shape1 is the result.
If there is full overlap in 2 directions, the third is checked for
possible truncation of the shape1 range in that direction. Repeat for all
directions. The result is mostly a truncated shape1 bounding box, as
expected:
On 13. aug. 2017 21:05, Ronaldo Persiano wrote:
If I have understood well your improvement, the bounding box of the
following solid might not overestimate the true bounding box:
difference(){
cube([100,100,20],center=true);
difference(){
cube(200);
cube([100,100,20],center=true);
}
}
Slightly odd example, as you just end up with the first cube
shape@ main_shape()
{
solid@ c1 = cuboid(100,100,20,center:true);
solid@ c2 = cube(200);
return print_box(c1 - (c2 - c1));
}
boundingbox: x=[-50,50] y=[-50,50] z=[-10,10]
So yes, no overestimation in this case.
Carsten Arnholm
All that said, for today's project a simplistic unioned bounding box
that can be used for positioning would be helpful :-)
Jordan said: "All that said, for today's project a simplistic unioned
bounding box that can be used for positioning would be helpful :-)"
The "General Library of Relativity" implements approximate bounding boxes
in OpenSCAD, and provides a general facility "to size, position, and orient
objects relative to other geometric primitives."
https://www.thingiverse.com/thing:349943
It works by wrapping all of the geometric primitives in new modules with
different names, and determining bounding boxes from module arguments:
'cube' becomes 'box', 'rotate' becomes 'rotated', etc. Unfortunately,
because the underlying functionality isn't built in, the Relativity library
can't determine the bounding box of an STL file :-(.
On 14 August 2017 at 00:20, Jordan Brown openscad@jordan.maileater.net
wrote:
All that said, for today's project a simplistic unioned bounding box that
can be used for positioning would be helpful :-)
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
On 8/14/2017 5:33 AM, doug moen wrote:
The "General Library of Relativity" implements approximate bounding
boxes in OpenSCAD, and provides a general facility "to size, position,
and orient objects relative to other geometric primitives."
Interesting, thanks. I haven't really wrapped my head around what it
means, but it looks pretty cool. It looks like some of the stuff I've
done (e.g. cubes that will justify or center against any side), but
multiplied by a hundred.
On 14/08/17 16:57, Jordan Brown wrote:
Interesting, thanks. I haven't really wrapped my head around what it
means, but it looks pretty cool. It looks like some of the stuff I've
done (e.g. cubes that will justify or center against any side), but
multiplied by a hundred.
The very cool bit is that you can (with some effort) get the negative
spaces in modules to "propagate" such that they make holes in other things.
I kind of do the same with a special variable called $Negative, which
lets my invoke a whole tree of stuff twice, once for positive parts and
once for holes, but Relativity makes it much neater.