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

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

Bill P.

Post a reply to this message