Empathy List Archives

RP

Ronaldo Persiano

Thu, Jan 26, 2017 4:52 AM

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 arnholm@arnholm.org:

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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

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 <arnholm@arnholm.org>: > 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 > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >

A

arnholm@arnholm.org

Thu, Jan 26, 2017 7:20 AM

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

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

JD

Jerry Davis

Sun, Jan 29, 2017 2:12 PM

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, arnholm@arnholm.org 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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

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, <arnholm@arnholm.org> 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 > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >

TP

Torsten Paul

Sun, Jan 29, 2017 2:44 PM

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.

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.

SR

Sebastien Roy (DIRO)

Mon, Jan 30, 2017 6:15 PM

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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

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 > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

NH

nop head

Mon, Jan 30, 2017 6:33 PM

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) roys@iro.umontreal.ca
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
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

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) <roys@iro.umontreal.ca> 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 > > Discuss@lists.openscad.org > > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org >

TP

Torsten Paul

Mon, Jan 30, 2017 6:45 PM

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.

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.

discuss@lists.openscad.org

Bounding box?