Thomas de Groot <tho### [at] degrootorg> wrote:

> >> ... I wrote a macro which "scans" an object's BB ...
> >
> > find attached an updated version of 'Bounder'.

So - those are pretty impressive differences between what POV-Ray does and what
you trim it down to!  :O

The methods I suggested are probably too complex to see any implementation any
time soon, but maybe if someone who reads and translates c++ or other languages
into SDL faster (and more accurately) than I can, converts a script or two -
then it would be a powerful tool for this as well as point clouds and other
tasks.
I doubt they'd be included into source - but I can dream a little.


I'm curious about how your BB compares to the native one aside from just size.
Does it shift?
Does the center move?  Is the space on either side equal for all 3 axes?
Presumably your bounding box is TIGHT - if you difference away an inverse box,
do you get points of overlap / coincident surfaces?
I'm just wondering if you ought to include a tiny buffer of 2x10E-6 or whatever
the safe distance is on either side, depending on usage.

Maybe have a switch in the macro call to omit or include that buffer space.

Perhaps an interesting addition would be to add an animation .ini file that
rotates the CSG object around an axis by some fraction of 45 degrees and then
does the analysis - to see if the _AA_BB gets any smaller.




Pretty nice work, and a striking demonstration of how much empty space an
automatically generated bounding box can have.
I knew there was some, but:   WOW.

I can see this being really useful for BB dependent operations like scanning
with trace (), and probably a few others that I can't clearly envision at the
moment.  Basically anywhere that a lot of ray-object intersections need to be
tested.


This is solid.

Post a reply to this message