On 8/20/19 8:33 PM, Andreas Kaiser wrote:
> On Mon, 19 Aug 2019 17:41:16 -0400, William F Pokorny wrote:
>> That bit of code came in with v3.0, but I have no idea why. I 'think' it
>> might be doing what's intended...
>> The aim isn't to shrink the bounding box, but rather to make it so
>> large, if already >1e6 on any side, that it is seen as an infinite
>> object and not included in normal bounding. BOUND_HUGE is larger than
>> MAX_DISTANCE (1e7). I say this without verifying that this the real
>> behavior though.
>> Bill P.
> 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.
> 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.
> What should be done (and is done most often) is to clip all
> coordinates of a BBox to +/-BOUND_HUGE/2.
> IMHO this should be done in Make_BBox(...) always, not in the caller's
I agree with you and take the code to which you point to be a hack of
some sort to get around some bounding based issue. Unfortunately, there
is not a central library of test cases for past problem scenes. I don't
myself have access to the perforce code control system so don't even
know who introduced the code. We can only remove the hack and see
whether anything breaks.
I work mostly with my own version of POV-Ray. I'll put it on my list to
create a branch which removes these hacks before I build my next
personal POV-Ray version. Suppose some test cases aimed at triggering
the code hack in order too. I'm pretty certain I have nothing in my
personal test case collection which will trigger this code.
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
Post a reply to this message