On Mon, 26 Aug 2019 08:24:31 -0400, William F Pokorny wrote:

>On 8/21/19 6:09 AM, William F Pokorny wrote:
>> On 8/20/19 8:33 PM, Andreas Kaiser wrote:
>...
>>>
>>> I don't remember anything in the code where it might help to set a big
>>> but finite AABB to +/- infinity.
>> 
>> Yes, same here, but this looks to me to be the intent of that code.
>> 
>I've confirmed this is the behavior for the csg code with the test scene 
>attached to the github issue.
>
>>> Actually this turns off BBox testing for the corresponding object.
>>>
>> 
>> I was thinking this too when I responded, but it's perhaps not entirely 
>> true in 3.7 onward.
>> 
>> It's the case changes in 3.7/3.8 leave a last level bounding test around 
>> the object even when bounding is off by -mb or +mb<count>. I have code 
>> branch - now some years old - which re-enables the 3.6 and prior like 
>> behavior of -mb. In other words, my branch really disables the inner 
>> most bounding box test in a way similar to 3.6.
>> 
>> I'm wondering this morning whether that last level of bounding box test 
>> is off for infinite objects? Though I have that patch, I just don't 
>> remember the behavior of the code well enough to know without 
>> investigation. If that inner most bounding test still gets done, it 
>> might be this code hack is - in 3.7/3.8 - of no value in any case.
>> 
>
>In some quick tests it looks like when an object is infinite it's not 
>tripping the bounding tests avoided by my patch branch. Given this at 
>least sometimes true there is some potential for this code to be fixing 
>or addressing some issue. In other words, see enough already to ignore 
>the rambling above.
>
>...
>> 
>> Lastly, I'd suggest we open up a github issue. Whether a bug or 
>> intentional, seems to me the code related to CRITICAL_LENGTH should be 
>> investigated.
>> 
>
>See: https://github.com/POV-Ray/povray/issues/379

Thanks Bill for creating the issue.

I assume it was the limited accuracy of float (used in BBox code)
which caused some problems: There are only 7 significant digits.
E.g. when you translate a BBox over a large distance it literally
loses its bits.
Also adding some +/-EPSILON to the bounds when its size is 1.0e05
already no longer works.

Generally current POV code could be improved in such situations.
E.g look at void Box::Compute_BBox(): It assigns its DBL vectors to
the float vectors of BBox without checking and might lose almost all
of its significant digits that way.

bool Inside_BBox(const Vector3d& point, const BoundingBox& bbox):
It doesn't handle the implicit +/-BOUND_HUGE means +/-Infinity at all.

The recurring recalcution of an object's BBox while parsing the scene
file makes things worse and is completely superfluous:
- do some consecutive rotations and the resulting AABB will grow each
time
- translate over some large distances and off are the bits.

An object's AABB is used in the tracing stage only, IMHO POV-Ray
should simply compose all transformations during the parsing stage and
then compute the AABB once.
This could help a lot to keep AABBs as correct and close to their
objects as possible.

Post a reply to this message