Am 11.12.2010 13:54, schrieb Le Forgeron:
> On 10/12/2010 20:15, Thorsten Froehlich wrote:
>> On 10.12.10 19:20, clipka wrote:
>>>> Except that spheres do not get bounding boxes.
>>>
>>> But I guess they are included in the bounding box tree, so they'd
>>> normally
>>> be bounded hierarchically if I understand the bounding mechanism
>>> correctly,
>>> right?
>>
>> IIRC yes.
>>
>> Thorsten
>
> Excepted that in source/backend/parser/parse.cpp, the volume of each
> bounding box is compared to INFINITE_VOLUME (aka BOUND_HUGE, i.e. 2.0e+10).
> (even if sphere does not use bounding box for pruning intersections'
> computation, it got a bounding box which is use for the volume)
>

> as infinite in parse.cpp, not entering the bounding tree.
>
> I would ponder the usage of BOUNDS_HUGE as a criteria against a volume.

> than (or equal) BOUNDS_HUGE) should still be infinite.
>
> What about comparing each dimension of the bounding box instead ?
> (if it's bigger in at least one dimension, it's infinite, otherwise it
> stay finite)
>
> volume computation has issue with very large & very thin bounding box: a
> larger thin object might be more finite than a smaller but thicker one
> (who could be tagged if infinite).
>
> E.g: bbox of size <1e+7, 1e+7,1e-4> is finite.
> bbox of size <1e+6, 1e+6, 1> is infinite.
>
>
> Your thought ?

I guess the idea behind this mechanism was, "if the bbox covers a lot of 
volume, it will cover a lot of visible area, so we can just as well 
presume we'll get a bounding box hit in virtually every direction anyway".

The flaw with this idea, which shows in this particular scene, is that 
in reality the visible area covered will not only depend on the object's 
volume, but also on its distance to the camera.

Maybe a good idea would be to test the volume in relation to the 
distance to the camera:

   if ((a*b*c) / pow(dist_to_camera,3) >= INFINITE_VOLUME) ...

Post a reply to this message