What about outside scad script, i.e. in commnad line?

On Aug 11, 2017 9:45 PM, "Michael Marx" michael.marx@tpg.com.au wrote:

Hi,

Le samedi 12 août 2017 à 14:44 +1000, Michael Marx a écrit :

I coded an extension("probe()" wich provides bounding box information,
as well as volume and center of mass.

As Michael says, this feature requires a "render" of the geometry, even
when previewing the geometry, which should be as fast as possible. In
fact, every time your ask for a bounding box, it is exactly equivalent
to calling render().

My opinion is that some features, like knowing the bounding box of some
geometry (especially imported stl) is sometimes essential. This means
that the wait for rendering is fully justified by the usefulness of the
feature. Note that I do not suggest to automatically compute this
information, but only on request, so whoever use it realize that he is
going to slow down his rendering. I dont see anyone putting "render()"
all over their code just to slow it down for for no reason... why
should it be different with a probe() function to get geometric
information?

I consider that the lack of such simple geometric computation as the
bounding box is a weakness of openscad, which makes a whole category of
models impossible to code.

As for using an outside program, this is ok when you need the
information once, but openscad strength is parametrization, which is
not compatible with running helper programs by hand.

If there is interest, my "probe" branch is still available. Sorry for
bringing back this discussion, but I did not start it :-)

Sincerely,

Sebastien

On 8/11/2017 9:44 PM, Michael Marx wrote:

It's not really relevant to the discussion, but if somebody could check
my mental model I'd appreciate it: my impression is that the issue is
that OpenSCAD generates a full list of the primitive objects and their
positions in space and the boolean operations to be applied to them, and
then does the boolean operations.  Because the bounding box is
dependent on the results of the boolean operations, it's not available
during the first phase when everything is placed in space.

If all you want is to analyze an STL file, and if your STL files are
text form (as the ones coming from OpenSCAD are), you can write a
relatively simple program in almost any language to read them and
calculate the min/max values.

Here's one in awk:

BEGIN {
m = 1000000; // Make larger if your model is really large
maxx = -m;
minx = m;
maxy = -m;
miny = m;
maxz = -m;
minz = m;
}

$1 == "vertex" {
maxx = ($2>maxx ? $2 : maxx);
minx = ($2<minx ? $2 : minx);
maxy = ($3>maxy ? $3 : maxy);
miny = ($3<miny ? $3 : miny);
maxz = ($4>maxz ? $4 : maxz);
minz = ($4<minz ? $4 : minz);
}

END {
print minx,miny,minz;
print maxx,maxy,maxz;
}

this works great. thanks for another tool in my arsenal!

--
Extra Ham Operator: K7AZJ
Registered Linux User: 275424
Raspberry Pi and Openscad developer

The most exciting phrase to hear in science - the one that heralds new
discoveries - is not "Eureka!" but "That's funny...".- Isaac. Asimov

On Sat, Aug 12, 2017 at 9:09 AM, Jordan Brown <openscad@jordan.maileater.net

On 12. aug. 2017 18:09, Jordan Brown wrote:

I think your mental model is correct. Your last sentence describes how
OpenSCAD works, but it is more a reflection of the design choices than
what is theoretically possible (ref. below).

a) it is possible to compute the final bounding box without performing
mesh boolean operations, but that is not how OpenSCAD does it.
b) you also need a way to query/use such computed information, and that
is not possible in a functional language.

Therefore, your best option is to export to STL (or other format) and
use other software to compute the bounding box from the file coordinates.

However, to illustrate that these things are not fundamental, but result
from software design choices, consider a trivial OpenSCAD example:

module main_shape()
{
cylinder(h=100,r=10);
translate([0,0,100])cube(50,center=true);
}
rotate([0,30,0])  main_shape();

To obtain the bounding box for the resulting solid object, one must
export to file as discussed.

I had similar needs to obtain bounding box information and therefore
implemented it in my own application (based on the AngelScript language)
where the a) and b) restrictions do not apply. The bounding boxes are
directly available for any solid, primitive or compound, and they can be
queried. The trivial example restated in AngelCAD:

shape@ main_shape()
{
solid@ cyl  = cylinder(h:100,r:10);
solid@ cub  = translate(0,0,100)cube(50,center:true);
solid@ thing = rotate_y(deg:30)(cyl + cub);
return print_box(thing);
}

solid@ print_box(solid@ body)
{
boundingbox@ box = body.box();
pos3d@ p1 = box.p1();
pos3d@ p2 = box.p2();
cout << "boundingbox: ";
cout << "x=[" << p1.x() << "," << p2.x() << "]  ";
cout << "y=[" << p1.y() << "," << p2.y() << "]  ";
cout << "z=[" << p1.z() << "," << p2.z() << "]  " << endl();
return body;
}

The script output is

boundingbox: x=[-21.6506,84.1506]  y=[-25,25]  z=[-12.5,120.753]

Note the bounding boxes are computed without performing any boolean
operations on mesh level (mesh booleans are done in a separate
application later, https://github.com/arnholm/xcsg ).

In summary, your mental model is correct given the OpenSCAD design choices.

Carsten Arnholm

How do you calculate the bounding box of a difference without calculating
the mesh?

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

On 13. aug. 2017 12:50, nop head wrote:

By computing the difference between the bounding boxes of the input objects.

It means you need a way to compute union, intersection and difference
for bounding boxes, i.e. a mini boolean engine for bounding boxes only.

It should be said that in some cases, this approach can overestimate the
volume of the resulting bounding box, compared to computing it from the
mesh, but it is guaranteed to be large enough.

Carsten Arnholm

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