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