They would be available after an internal render as resize() does. However,
there is no way to communicate that to the user code, Torsten said. There
is an open proposal in github to solve this.

2017-01-25 12:19 GMT-02:00 adrian adrianh.bsc@gmail.com:

You might be able to solve your problem using the Relativity library.
Documentation here: https://github.com/davidson16807/relativity.scad/wiki

To solve the general problem of computing a bounding box for any shape,
you'd need to render the object, which potentially requires expensive CGAL
operations. And there has been a reluctance to put this feature into the
language, because it would slow down preview.

However, you don't need any expensive computations to compute the bounding
box of a cube, sphere, cylinder, polyhedron, circle, square, polygon or a
translate, scale, mirror, hull, minkowski, union, linear_extrude,
rotate_extrude of these objects. You can get the bounding box information
right out of the CSG tree. And that's effectively how Relativity achieves
its effects.

I'm building a new geometry engine for an OpenSCAD-like language, and I
store a bounding box in each shape as it is constructed during evaluation,
before any expensive rendering has been done. For certain operations (like
rotate, intersection, difference), the bounding box information is
approximate: it might be larger than the actual object after rendering. The
point is that I can do this inexpensively, and the bounding box is
accessible to scripts, so you can position an object using its bounding box.

This feature could be added to OpenSCAD without incurring a significant
performance cost. Note that if we implemented "approximate bounding boxes"
in OpenSCAD, then you'd still be able to call render() on a node -- the
bounding box of a render node would be exact.

On 25 January 2017 at 06:48, droftarts ginjaian@hotmail.com wrote:

Keeping bounding box information from the CSG tree would have a great
performance impact because the boolean operation (like a simple union) of
many disjoint parts would be trivial and faster. I don't see however how to
provide the bounding box information to user code without a big language
syntax change.

2017-01-25 13:20 GMT-02:00 doug moen doug@moens.org:

I think what's needed is a function that takes a shape as an argument, and
returns a bounding box.

Of course, that's currently impossible in OpenSCAD. The syntax changes
required to support this are a big can of worms.

The easiest approach involves using a single namespace for variables,
functions and modules. So that's what I'm doing in my personal project;
it's one reason why my language is only "OpenSCAD-like", and not "OpenSCAD
compatible".

But this breaks backward compatibility, which isn't acceptable to the
community.

During summer 2015, I wrote up a proposal called OpenSCAD2, which attempted
to solve this problem. This particular proposal adds a new function
definition syntax, and a new syntax for use and include. If you use the
new syntax in your script, then your script is interpreted as having a
single namespace for variables, functions and modules. However, if you use
the old syntax, then your script is interpreted as having 3 namespaces,
which preserves backwards compatibility for legacy code. In OpenSCAD2, a
bounding_box function can be defined, but it's only useable if your script
is interpreted in "single namespace" mode.

It turns out this proposal is not acceptable to some members of the
community, because it deprecates the 3 namespaces, and forces people to put
their variables, functions and modules into a single namespace if they wish
to use certain new features. OpenSCAD2 is also not 100% backwards
compatible; there are some old scripts that won't work. Those problems are
fixable, but the main issue is that it deprecates the use of the 3
namespaces.

My second proposal is to extend the syntax of identifiers with "namespace
modifiers". In this design, you can prefix an identifier with "v$", "f$" or
"m$" to indicate which namespace the identifier is defined within. A call
to the bounding_box function might look like this:
bbox = bounding_box(m$translate([10,20]) m$square(3));
You can also pass a function as an argument to another function:
f(f$sin)
or call a function stored in a variable or function parameter f:
v$f(x)

I think this is a straightforward design. My objection is that the syntax
is really ugly. I would not enjoy using this language, as a lot of the code
I am currently writing uses first class function values for defining
geometric shapes. I'm writing functions that take functions as arguments
and return functions as results.

My third and newest proposal includes namespace modifiers, but then adopts
some of the ideas and syntax from OpenSCAD2 so that you can avoid namespace
modifiers in most cases. In this proposal, the 3 namespaces are not
deprecated, but if you want to, you can write code where you can mostly
pretend that there is only a single namespace. The goal is to satisfy two
groups of users: those who prefer to program using 3 namespaces, and those
who prefer to program using 1 namespace. The first group of users will need
to use namespace qualifiers if they want to use new features like
bounding_box. The second group of users will largely be able to avoid them.

The basic idea is that we introduce a new function definition syntax, just
like the old syntax except that the word 'function' is omitted.
f(x) = x + 1;
A "new style function definition" defines a function in all 3 namespaces:
variable, function and module. So you can pass 'f' as an argument to
another function without using a namespace qualifier.

Within the body of a new-style function definition, function parameters and
local variables are defined in both the variable and the function
namespaces. So if your function has a function-valued parameter p, you can
call p without using a namespace qualifier.

This proposal also makes shapes into first class values, as in OpenSCAD2.
This means you can pass shapes as arguments to functions, and return them
as results. Functions can be used by "single namespace" users as a
replacement for modules in most cases.

Most of the built-in modules (cube, sphere, translate, union, etc) are
defined in all 3 namespaces. In the function and variable namespaces, they
are represented as function values. Some built-in modules (like
intersection_for, assign) can't be represented as functions and are only
defined in the module namespace. The expression syntax is extended so that
translate([10,20]) square(10)
is a curried function call, equivalent to
translate([10,20])(square(10))
following the design of OpenSCAD2. In the function namespace, 'translate'
is a curried function.

So you can call the bounding box function like this, without namespace
qualifiers:
bbox = bounding_box(translate([10,20]) square(3));

There are some additional details, but that gives you the general flavour.

This third proposal is complicated, because it satisfies complex
requirements: it's 100% backward compatible, and it provides equal support
for 3-namespace programming and 1-namespace programming. On the plus side,
I can see how to break up the implementation into a series of incremental
steps, and it was never clear how to do that for the OpenSCAD2 proposal.

Doug Moen.

On 25 January 2017 at 10:32, Ronaldo Persiano rcmpersiano@gmail.com wrote:

Hi, I've been listening for a while, but this is my first post.

This general idea (introspection of a module) is the thing I most wish OpenSCAD could do.  If there was a voting system for new features it would get ALL of my votes.  =)

What sounded the best to me of all the conversations I've seen on this would be to use render() (or a function based on render, I'll use 'render2polyhedron' below), and to have it just return the polyhedron data of what it rendered.  If it would be possible to make this one "method" also return data it might just be:

polyhedron = render2polyhedron() {
<<stuff>>
}

Ideally, the above followed by polyhedron(poly) would be identical to render() { <<stuff>> }.  Or instead of a new "function" it could just be that render() itself returns the data, but I think you'd also want a parameter to indicate when you just want to inspect the polygon but not actually render it, so a separate function seems better to me than something like "render(dontRender=true)"  =P

It seems to me that if you had the full polyhedron data (which I believe is what CSG actually builds?), you could basically do anything you wanted with it, including but not limited to computing bounding boxes.  Editing the object would "just" take manipulation of the polyhedron data, realizing in many cases that's probably easier said than done, but some folks on here seem to be wizards at this, I am NOT one of those folks.  =)

Some helper functions, like one that computes a bounding box from the polyhedron data might be a nice extra thing to have built-in, or it could obviously be provided in a .scad library, not sure how much slower that would make it to do in-language.

I realize it does blur the lines a bit as functions don't take children and modules don't return data, I don't know how terrible it is to make this work in the code, I just know I'd love to have it.  And there are times when I would want more than just the bounding box, so just providing that seems like a partial solution to me.

The only argument I really saw against it was that it required the use of render() (or the work that render does), but as I see it this function is there, it has its usefulness, and to me it seems like a perfectly reasonable price to pay IF you want to do this extra level of introspection of an object.  If you don't need this data there's no need to use render(), so I don't see how it hurts anybody.  It's really no different than making an STL of part of your OpenSCAD data, then passing it to some other tool to do the introspection and feeding that back into OpenSCAD, it just lets you stay within the OpenSCAD environment which seems so much more powerful to me (especially considering what I think others on here could do with such data).

Just my $0.02, but I'd happily send it (and more) to somebody if they could implement it.  =)  Thanks.  - Will

In my language, polyhedron mesh data can be obtained from a shape, but it
works similar to how bounding_box works. The mesh vertices are only
available if they can be inexpensively computed from the data in the CSG
tree. So you can request the mesh for a cube() or a polyhedron(), but not
for a union(). The exception is if you explicitly invoke render(), an
expensive operation -- the mesh is available for a render node. There is
also a predicate that tests if a shape has mesh information available.
(This is just planned, I haven't implemented this part yet.)

I think this approach could also work for OpenSCAD, if the syntax issues
were resolved. It addresses the criticism that asking for the mesh data is
potentially very expensive, by making that operation cheap. You have to
explicitly invoke render() if you want to force CGAL to be used to generate
a mesh.

On 25 January 2017 at 14:15, William Ferry woferry@mac.com wrote:

I am a big fan of the OpenSCAD 2 proposal and I don't care if it isn't
backward compatible.

Meanwhile, there is other proposals to allow the inspection of a solid that
do not require any language syntax change. They may not be so clean as
dough's proposal but they answer to many requests for mesh inspection. One
proposal is in github https://github.com/openscad/openscad/issues/1585and
has appeared again recently here in the forum
http://forum.openscad.org/rendering-for-paper-assembly-manual-tc20108.html.
But it seems there is no plan of the dev team to embrace it for now.

All could be done with an import(<STL file name>) function returning the
solid mesh in the same format it is required by primitive polyhedron:
[<vertex list>, <face list>]. It would be easy to get bounding box
information from that and to do many other useful operations.

2017-01-25 18:28 GMT-02:00 doug moen doug@moens.org:

On 25. jan. 2017 16:20, doug moen wrote:

It should be fairly precise if you implement intersection and difference
between bounding boxes, plus transformation of bounding boxes. A
resulting box will always be xyz aligned, but I don't immediately see
any obvious reason why such boxes should be much different from what you
get after rendering.

Carsten Arnholm