So if you punch a hole through a cube with a cylinder that is longer you
get a negative bounding box?

I can't see how you get remotely the correct answer in a lot of cases.

On 13 August 2017 at 13:26, Carsten Arnholm arnholm@arnholm.org wrote:

​Are you sure? Will your​ "mini boolean engine for bounding boxes only"
compute an overestimate of the bbox of:

module cross() { cube([100,20,20],center=true);
cube([20,100,20],center=true);}

difference(){
cube([100,100,20],center=true);
cross();
}

​??
​

2017-08-13 13:26 GMT+01:00 Carsten Arnholm arnholm@arnholm.org:

On 13. aug. 2017 15:38, nop head wrote:

you get a negative bounding box?

No, in that case the result will be the same as for the cube only. A
bounding box will only enclose remaining material, not the difference tool.

shape@ main_shape()
{
return print_box(  cube(size:100,center:true)
- cylinder(h:500,r:20,center:true));
}

produces
boundingbox: x=[-50,50]  y=[-50,50]  z=[-50,50]

... i.e. the same as what you will get from calculating the bounding box
from the mesh.

Obviously it depends on correct implementation of booleans for bounding
boxes.

If you have cases you think will not work, I can check it.

Carsten Arnholm

I've implemented this idea for my Curv geometry engine as well, which I
stole from ImplicitCAD (an OpenSCAD clone). As Carsten says, it sometimes
overestimates the size of the bounding box.

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.

On 13 August 2017 at 10:32, Ronaldo Persiano rcmpersiano@gmail.com wrote:

On 13. aug. 2017 16:32, Ronaldo Persiano wrote:

In this case it is also exact, similar to the nop_head example.

solid@ cross()
{ return cuboid(100,20,20,center:true)
+ cuboid(20,100,20,center:true);
}

shape@ main_shape()
{
return print_box(cuboid(100,100,20,center:true) - cross());
}

boundingbox: x=[50,50]  y=[50,50]  z=[10,10]

What I was thinking of was when several rotations are involved, but I
must admit I do not have an example demonstrating this problem :-)

Carsten Arnholm

In general, for difference, the answer can be anywhere between the original
size and zero depending on how much the second shape overlaps a boundary of
the first shape. I don't see how an answer that can be that inaccurate is
useful.

On 13 August 2017 at 18:01, KeithSloan52 keith@sloan-home.co.uk wrote:

On 13. aug. 2017 18:05, Carsten Arnholm wrote:

Sorry, I missed the obvious missing minus signs here, the answer is
wrong. I will look into this bug.

Carsten Arnholm

On 13. aug. 2017 19:15, Carsten Arnholm wrote:

If was a classification bug in my boundingbox difference. After fixing
that I now get the expected result:

boundingbox: x=[-50,50]  y=[-50,50]  z=[-10,10]

Sorry for the confusion.

Carsten Arnholm

On 13. aug. 2017 18:04, doug moen wrote:

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:

shape@ main_shape()
{
return print_box(cube(size:100) - translate(30,0,0)*cube(size:100));
}
boundingbox: x=[0,30]  y=[0,100]  z=[0,100]

For the real case where the bounding box is over estimated, consider

shape@ main_shape()
{
return print_box(sphere(r:50));
}
boundingbox: x=[-50,50]  y=[-50,50]  z=[-50,50]

vs.

shape@ main_shape()
{
return print_box(rotate_z(deg:45)*sphere(r:50));
}
boundingbox: x=[-70.7107,70.7107]  y=[-70.7107,70.7107]  z=[-50,50]

The issue is that the only the bounding box of the sphere is rotated,
resulting in an expanded bounding box, since a bounding box is always
aligned with the main axes. This was the case I was thinking of.

Carsten Arnholm