Op 03/11/2019 om 16:40 schreef jr:
> 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.
> 

A few thoughts derived from this.

- rotating the object changes the 'tightness' of the standard BB. I did 
that with a simple cylinder: when properly aligned along one of the 
axis, the BB test is always optimal; rotate the cylinder (e.g. 
<45,45,45>) and do the test, and the standard BB becomes too wide.

- the test is also useful with hyperboloid, superellipsoid, and 
isosurface objects. Quartic and parametric objects do no comply, 
probably they are not 'solid'? I did not test this thoroughly.

- I include the test scene file for you to play with.
-- 
Thomas

Post a reply to this message

Attachments:
Download 'utf-8' (9 KB)