hi,

"Bald Eagle" <cre### [at] netscapenet> 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

agree.  for the Boy's Surface which got me going, the BB went from 11^3 units to
8.2^3, a reduction of well over 50%.

> 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.

as I wrote, I'm game for collaboration.  if you can express the spherical
bounding you're thinking off as "pseudo code" at least, I'm sure we could work
on something.

> 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.

the algorithm goes something like this, for each axis:
  - using the resolution, work out the required axis scan increments.
  - work along the scan axis until you hit the object:
    - scan the "face" looking +axis.  if no inside() test succeeded, remember
      that face as outside.
    - scan the "face" looking -axis.  as above.

the advantage is that the last stored coords are always outside of the object.
the art, I guess, will be finding the lowest resolution "good" for the object.
(low res like for the Boy's Surface wouldn't work for, say, a model of a sea
urchin, where one would presumably miss many of the spikes)

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

the 'Bounder' is only meant to give you (the user) guide figures, by up to which
you can tighten the BB if useful.

> 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.

that's an interesting thought, re-orienting the object.  need to think about
that.

> 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.

yeah, Thomas's "reference"-style image did that for me too.  :-)

> 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.

gut feeling: scenes with a number of CSG shapes with "difficult" materials, like
glass, will benefit.  also, after a first glance, 'blob' shapes too look like
good candidates.

> This is solid.

merci bien.


regards, jr.

Post a reply to this message