Quantcast

Bounding box?

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bounding box?

droftarts
Is there any way to get the size and position of a bounding box around an OpenSCAD part? I have built a model with a number of sub-assemblies, and it would be good to show them all separated out. But as each is a different size, this means a list of objects, individually translated, at the moment. I'm thinking of something like https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Tips_and_Tricks#Arrange_parts_on_a_spatial_array but with parts that are very different in size.

droftarts
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bounding box?

adrian
Getting a bounding box is something that has been asked for before.  Unfortunately, this is not possible currently as the points are not available internally until the object is rendered.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bounding box?

Ronaldo
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 <[hidden email]>:
Getting a bounding box is something that has been asked for before.
Unfortunately, this is not possible currently as the points are not
available internally until the object is rendered.



--
View this message in context: http://forum.openscad.org/Bounding-box-tp20220p20224.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bounding box?

doug.moen
In reply to this post by droftarts
You might be able to solve your problem using the Relativity library.

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 <[hidden email]> wrote:
Is there any way to get the size and position of a bounding box around an
OpenSCAD part? I have built a model with a number of sub-assemblies, and it
would be good to show them all separated out. But as each is a different
size, this means a list of objects, individually translated, at the moment.
I'm thinking of something like
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Tips_and_Tricks#Arrange_parts_on_a_spatial_array
but with parts that are very different in size.

droftarts



--
View this message in context: http://forum.openscad.org/Bounding-box-tp20220.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bounding box?

Ronaldo
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 <[hidden email]>:
You might be able to solve your problem using the Relativity library.

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 <[hidden email]> wrote:
Is there any way to get the size and position of a bounding box around an
OpenSCAD part? I have built a model with a number of sub-assemblies, and it
would be good to show them all separated out. But as each is a different
size, this means a list of objects, individually translated, at the moment.
I'm thinking of something like
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Tips_and_Tricks#Arrange_parts_on_a_spatial_array
but with parts that are very different in size.

droftarts



--
View this message in context: http://forum.openscad.org/Bounding-box-tp20220.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bounding box?

doug.moen
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 <[hidden email]> 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 <[hidden email]>:
You might be able to solve your problem using the Relativity library.

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 <[hidden email]> wrote:
Is there any way to get the size and position of a bounding box around an
OpenSCAD part? I have built a model with a number of sub-assemblies, and it
would be good to show them all separated out. But as each is a different
size, this means a list of objects, individually translated, at the moment.
I'm thinking of something like
https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Tips_and_Tricks#Arrange_parts_on_a_spatial_array
but with parts that are very different in size.

droftarts



--
View this message in context: http://forum.openscad.org/Bounding-box-tp20220.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bounding box?

woferry
In reply to this post by adrian
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



> On Jan 25, 2017, at 6:19 AM, adrian <[hidden email]> wrote:
>
> Getting a bounding box is something that has been asked for before.
> Unfortunately, this is not possible currently as the points are not
> available internally until the object is rendered.
>
>
>
> --
> View this message in context: http://forum.openscad.org/Bounding-box-tp20220p20224.html
> Sent from the OpenSCAD mailing list archive at Nabble.com.
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bounding box?

doug.moen
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 <[hidden email]> 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



> On Jan 25, 2017, at 6:19 AM, adrian <[hidden email]> wrote:
>
> Getting a bounding box is something that has been asked for before.
> Unfortunately, this is not possible currently as the points are not
> available internally until the object is rendered.
>
>
>
> --
> View this message in context: http://forum.openscad.org/Bounding-box-tp20220p20224.html
> Sent from the OpenSCAD mailing list archive at Nabble.com.
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bounding box?

Ronaldo
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 and has appeared again recently here in the forum. 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 <[hidden email]>:
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 <[hidden email]> 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



> On Jan 25, 2017, at 6:19 AM, adrian <[hidden email]> wrote:
>
> Getting a bounding box is something that has been asked for before.
> Unfortunately, this is not possible currently as the points are not
> available internally until the object is rendered.
>
>
>
> --
> View this message in context: http://forum.openscad.org/Bounding-box-tp20220p20224.html
> Sent from the OpenSCAD mailing list archive at Nabble.com.
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bounding box?

cacb
In reply to this post by doug.moen
On 25. jan. 2017 16:20, doug moen wrote:
> 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.

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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bounding box?

Ronaldo
Two disjoint objects may have the same bounding box, which is the best bounding box for their intersection. But their intersection is void.

2017-01-25 21:31 GMT-02:00 Carsten Arnholm <[hidden email]>:
On 25. jan. 2017 16:20, doug moen wrote:
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.

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


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bounding box?

cacb
On 2017-01-26 05:52, Ronaldo Persiano wrote:
> Two disjoint objects may have the same bounding box, which is the best
> bounding box for their intersection. But their intersection is void.

If you mean there are border cases, I agree. If e.g. 2 spheres have the
same radius and location, the bounding box of their intersection will be
the ideal one whether you compute it from their boxes or from their
meshes. If they are located so their boxes don't touch, the bounding box
of their intersection will still agree and be void in both cases. But I
agree there are some cases where the intersection of the bounding boxes
becomes non-void when the intersection based on meshes is void.

I also think Dougs point was that e.g. rotating bounding boxes may cause
the resulting box in a csg treee to be larger than the ideal. Having
thought about it, I agree with that as well.

In general, bounding boxes computed this way will be guaranteed to be
large enough, but may not always be the ideal (smallest possible) box.

Carsten Arnholm

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bounding box?

jdawgaz
So, a fork of OpenSCAD is out of the question then?

We could have 2 executables, OpenSCAD and OpenSCAD2. the source files would be .scad, and .scad2




--
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 Thu, Jan 26, 2017 at 12:20 AM, <[hidden email]> wrote:
On 2017-01-26 05:52, Ronaldo Persiano wrote:
Two disjoint objects may have the same bounding box, which is the best
bounding box for their intersection. But their intersection is void.

If you mean there are border cases, I agree. If e.g. 2 spheres have the same radius and location, the bounding box of their intersection will be the ideal one whether you compute it from their boxes or from their meshes. If they are located so their boxes don't touch, the bounding box of their intersection will still agree and be void in both cases. But I agree there are some cases where the intersection of the bounding boxes becomes non-void when the intersection based on meshes is void.

I also think Dougs point was that e.g. rotating bounding boxes may cause the resulting box in a csg treee to be larger than the ideal. Having thought about it, I agree with that as well.

In general, bounding boxes computed this way will be guaranteed to be large enough, but may not always be the ideal (smallest possible) box.


Carsten Arnholm

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
tp3
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bounding box?

tp3
On 01/29/2017 03:12 PM, Jerry Davis wrote:
> So, a fork of OpenSCAD is out of the question then?
>
I certainly hope so. But then, that's for other people to
decide and the licence would also allow this. I personally
see that type of fork as worst option possible though.

ciao,
  Torsten.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bounding box?

blobule
In reply to this post by droftarts
Hi,

I proposed a solution to this which works very well. See here:

https://github.com/openscad/openscad/pull/1388

and then (a valid pull request)

https://github.com/openscad/openscad/pull/1713


I proposed to use probe() on geometry which set local variables
containing bounding box information, and even the volume and center of
mass.

This was rejected for many reasons I don't care to discuss anymore.

The key idea here is that when you really need bounding box or volume,
then you are willing to spend the rendering time required to get the
information, and usualy its fast. This has not been understood and I am
losing patience as I consider this an essential feature of any CAD
system.

This lack of bounding box and other measures is crippling Openscad in
my opinion. This also makes it impossible to align text, so now the
text() command provides its own alignment, which is not an elegant
solution at all. We should be able to measure any geometry.

Anyway, sorry for my lack of patience, but the "is there a bounding
box" question returns often and every time its the same waste of emails
discussing why we cant do it while in pratice its simple.


Cheers,

Sébastien


Le mercredi 25 janvier 2017 à 04:48 -0700, droftarts a écrit :

> Is there any way to get the size and position of a bounding box
> around an
> OpenSCAD part? I have built a model with a number of sub-assemblies,
> and it
> would be good to show them all separated out. But as each is a
> different
> size, this means a list of objects, individually translated, at the
> moment.
> I'm thinking of something like
> https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Tips_and_Tricks#Ar
> range_parts_on_a_spatial_array
> but with parts that are very different in size.
>
> droftarts 
>
>
>
> --
> View this message in context: http://forum.openscad.org/Bounding-box-
> tp20220.html
> Sent from the OpenSCAD mailing list archive at Nabble.com.
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bounding box?

nophead
Yes there have been a lot of good pull requests that got rejected because of the OpenSCAD2 proposal. I would much sooner see these implemented than a new language.

On 30 January 2017 at 18:15, Sebastien Roy (DIRO) <[hidden email]> wrote:
Hi,

I proposed a solution to this which works very well. See here:

https://github.com/openscad/openscad/pull/1388

and then (a valid pull request)

https://github.com/openscad/openscad/pull/1713


I proposed to use probe() on geometry which set local variables
containing bounding box information, and even the volume and center of
mass.

This was rejected for many reasons I don't care to discuss anymore.

The key idea here is that when you really need bounding box or volume,
then you are willing to spend the rendering time required to get the
information, and usualy its fast. This has not been understood and I am
losing patience as I consider this an essential feature of any CAD
system.

This lack of bounding box and other measures is crippling Openscad in
my opinion. This also makes it impossible to align text, so now the
text() command provides its own alignment, which is not an elegant
solution at all. We should be able to measure any geometry.

Anyway, sorry for my lack of patience, but the "is there a bounding
box" question returns often and every time its the same waste of emails
discussing why we cant do it while in pratice its simple.


Cheers,

Sébastien


Le mercredi 25 janvier 2017 à 04:48 -0700, droftarts a écrit :
> Is there any way to get the size and position of a bounding box
> around an
> OpenSCAD part? I have built a model with a number of sub-assemblies,
> and it
> would be good to show them all separated out. But as each is a
> different
> size, this means a list of objects, individually translated, at the
> moment.
> I'm thinking of something like
> https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Tips_and_Tricks#Ar
> range_parts_on_a_spatial_array
> but with parts that are very different in size.
>
> droftarts 
>
>
>
> --
> View this message in context: http://forum.openscad.org/Bounding-box-
> tp20220.html
> Sent from the OpenSCAD mailing list archive at Nabble.com.
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
tp3
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bounding box?

tp3
In reply to this post by blobule
On 01/30/2017 07:15 PM, Sebastien Roy (DIRO) wrote:
> This lack of bounding box and other measures is crippling
> Openscad in my opinion. This also makes it impossible to
> align text, so now the text() command provides its own
> alignment, which is not an elegant solution at all. We
> should be able to measure any geometry.
>
Nope, it does not. The alignment parameters of text() are
based on the font metrics and not on on the geometry. So
geometry measurement is missing for text() too.

ciao,
  Torsten.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
Loading...