On 3/27/2020 10:21 AM, Torsten Paul wrote:

It seems like it would be much, much harder to compute the bounding box
of an intersection() than to compute the bounding box of a text(). 
Moreover, it would be a different kind of work - computing the
bounding box of a text() involves stopping well before the CGAL
processing, while computing the bounding box of an intersection()
requires, I think, actually doing the CGAL work, calculating the
resulting mesh so as to be able to extract some its metrics.

(And the same is true of other operations; I just use intersection as an
example that seems to me to be "hard".)

On 3/27/2020 2:20 PM, Jordan Brown wrote:

Never mind, this is all coming from my misunderstanding the scope of
that PR.

On 27.03.2020 22:20, Jordan Brown wrote:

I don't think this is generally true. You don't need CGAL to compute the
bounding box of an intersection, at least in the cases I can think of
now you don't.

In AngelACD Carve is used instead of CGAL, but computing the bounding
box of an intersection can be done without using Carve. If CGAL was used
it would make no difference.

Below is a simple example of computing the bounding box from the
intersection between a cube and a sphere. Carve is not used in this
bounding box computation:

https://gist.github.com/arnholm/e8eacdfb0293e3ddc7cc4705c189ffaf

Carsten Arnholm

But isn't Carve used to do the intersection?

If you have a mesh it isn't hard to find its bounding box. The problem is
OpenSCAD would need to do the intersection first and that would CGAL.

On Sat, 28 Mar 2020 at 12:59, Carsten Arnholm arnholm@arnholm.org wrote:

On 28.03.2020 14:05, nop head wrote:

Yes, Carve is used to compute the final intersection mesh, but you don't
have to compute the intersection mesh to compute an intersection
bounding box.

True, but it is not required for finding the bounding box.

that would CGAL.

If it isn't required in AngelCAD it isn't required in OpenSCAD.

Carsten Arnholm

[ First, let me note that my original comment was based on a
misunderstanding of the "object literals" PR.  I don't think it's
relevant to the OP topic any more. ]

On 3/28/2020 5:59 AM, Carsten Arnholm wrote:

Unfortunately, I don't have any way to see what happens inside the "&"
operator.

In the example you give, the bounding box of the intersection happens to
be equal to the intersection of the bounding boxes.  That is, indeed,
easy.  Other cases can't be done that way.

I'm not a 3D geometry expert, but in non-trivial cases I'm not coming up
with any way to calculate the bounding box of an intersection without
actually calculating the intersection.

If that's what you're doing under the covers, here's a counterexample. 
This is long for an example; most of it is presenting the various parts
of the question.

// The two objects that we're going to play with.
module a() {
sphere(10);
}
module b() {
translate([0,15,0]) sphere(10);
}

// Show the two objects.
color("red") a();
color("green") b();

// Their intersection.
translate([20,0,0]) intersection() {
a();
b();
}

// The bounding box of their intersection.
translate([40,0,0]) bbox_3D() intersection() {
a();
b();
}

// The intersection of their bounding boxes.
translate([60,0,0]) intersection() {
bbox_3D() {
a();
}
bbox_3D() {
b();
}
}

// Derive the bounding box of an arbitrary object.
// Courtesy Ronaldo Persiano.
module bbox_3D()
render()
intersection() {
a = 1e10;
hull() { // XY
translate([ a, a, 0]) children();
translate([ a,-a, 0]) children();
translate([-a, a, 0]) children();
translate([-a,-a, 0]) children();
}
hull() { // XZ
translate([ a, 0, a]) children();
translate([ a, 0,-a]) children();
translate([-a, 0, a]) children();
translate([-a, 0,-a]) children();
}
hull() { // YZ
translate([0, a, a]) children();
translate([0,-a, a]) children();
translate([0, a,-a]) children();
translate([0,-a,-a]) children();
}
}

On 28.03.20 16:37, Jordan Brown wrote:

It's relevant to what was asked in the original post
(fitting/flowing text into a given area).

It may not be relevant to what is discussed lately.

ciao,
Torsten.

On 28.03.2020 16:37, Jordan Brown wrote:

You are correct, I agree with your counterexample. I was computing the
intersection between bounding boxes, and your example shows it is not
sufficient in all cases.

Thanks!

Carsten Arnholm