On 10/12/2010 16:36, Juce wrote:
> // +W320 +H240
>
> camera { location<0,50000,-100000>  look_at<0,-10000,0>  }
> light_source {<-700000,1000000,-400000>, rgb<1,1,1>  }
> plane { y,0 pigment { color<0,.8,0>  } }
>
> #declare R = seed(0);
> #declare Count=0;
> #while (Count<  5000)
>
> sphere {
>          <0,1000,0>,
>          1360  // 1350 works fast
>          pigment { color<0,.5,0>  }
>          translate<(rand(R)-.5)*500000,0,(rand(R)-.5)*500000>
>          }
>
> #declare Count=Count+1;
> #end
>
>
> This takes over 4 minutes if the radius is 1360. If I change it to 1350 then
> Render Time is just 1 or 2 seconds.
>
> Tested with Athlon64 3200+, 3.7.0.beta.40 (Windows XP 32-bit) and 3.6.1 (Ubuntu
> 10.10 64-bit).
>
>
Confirmed.

Look at the Render statistics : 1350 get an additional line, "Bounding Box"!

Post a reply to this message

Am 10.12.2010 17:56, schrieb Le Forgeron:

>> This takes over 4 minutes if the radius is 1360. If I change it to
>> 1350 then
>> Render Time is just 1 or 2 seconds.
>>
>> Tested with Athlon64 3200+, 3.7.0.beta.40 (Windows XP 32-bit) and
>> 3.6.1 (Ubuntu
>> 10.10 64-bit).
>>
>>
> Confirmed.
>
> Look at the Render statistics : 1350 get an additional line, "Bounding
> Box"!

There is a maximum coordinate value for bounding boxes; I'm just 
guessing here, but it might be that the scene touches this borderline.

Post a reply to this message

On 10.12.10 18:06, clipka wrote:
> Am 10.12.2010 17:56, schrieb Le Forgeron:
>
>>> This takes over 4 minutes if the radius is 1360. If I change it to
>>> 1350 then
>>> Render Time is just 1 or 2 seconds.
>>>
>>> Tested with Athlon64 3200+, 3.7.0.beta.40 (Windows XP 32-bit) and
>>> 3.6.1 (Ubuntu
>>> 10.10 64-bit).
>>>
>>>
>> Confirmed.
>>
>> Look at the Render statistics : 1350 get an additional line, "Bounding
>> Box"!
>
> There is a maximum coordinate value for bounding boxes; I'm just guessing
> here, but it might be that the scene touches this borderline.

Except that spheres do not get bounding boxes.

Thorsten

Post a reply to this message

Am 10.12.2010 19:19, schrieb Thorsten Froehlich:
> On 10.12.10 18:06, clipka wrote:
>> Am 10.12.2010 17:56, schrieb Le Forgeron:
>>
>>>> This takes over 4 minutes if the radius is 1360. If I change it to
>>>> 1350 then
>>>> Render Time is just 1 or 2 seconds.
>>>>
>>>> Tested with Athlon64 3200+, 3.7.0.beta.40 (Windows XP 32-bit) and
>>>> 3.6.1 (Ubuntu
>>>> 10.10 64-bit).
>>>>
>>>>
>>> Confirmed.
>>>
>>> Look at the Render statistics : 1350 get an additional line, "Bounding
>>> Box"!
>>
>> There is a maximum coordinate value for bounding boxes; I'm just guessing
>> here, but it might be that the scene touches this borderline.
>
> 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?

Post a reply to this message

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

Post a reply to this message

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 ?

Post a reply to this message

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

On 11/12/2010 20:53, clipka wrote:

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

I would stand by the code in the bounding box: when one dimension is big 
enough, assume infinite (well, it's the opposite way: infinite object 
set the bounding box to huge bound value in 3 dimensions...)

Or we can do like my national postal service: if the sum of the 3 
dimensions is more than 1m, it's a non standard parcel... with added 
price on the stamp.

Post a reply to this message

Am 11.12.2010 21:24, schrieb Le Forgeron:

> Or we can do like my national postal service: if the sum of the 3
> dimensions is more than 1m, it's a non standard parcel... with added
> price on the stamp.

What if I define the parcel using

   box { <2,-1,-1>,<0,1,1> }

Do I get money back? :-P

Post a reply to this message

Le 11/12/2010 22:02, clipka nous fit lire :
> Am 11.12.2010 21:24, schrieb Le Forgeron:
> 
>> Or we can do like my national postal service: if the sum of the 3
>> dimensions is more than 1m, it's a non standard parcel... with added
>> price on the stamp.
> 
> What if I define the parcel using
> 
>   box { <2,-1,-1>,<0,1,1> }
> 
> Do I get money back? :-P

Well, they insist on normalising it first to length of <2,2,2>.

Back to the Volume code, it seems to be used for 2 purposes:
 - determining if the box is finite or infinite (in parse.cpp)
 - taking the smallest volume of a hand-provided bbox/clip (optimise
recomputation of bounding box ?) in quadrics.cpp & csg.cpp (and for
quadric, it's funny)

Also, csg.cpp & quadric.cpp is using a stranger code: if any side is
longer than CRITICAL_LENGTH (1.0e+6), it moves to BOUND_HUGE (2.0e+10)
for all 3. (that's a jump). But it's not coherent with the value of
INFINITE_VOLUME (BOUND_HUGE).

I have philosophical issue: comparing volume seems not the right thing
to do to choose if Make_BBox_from_min_max must be called. I would call
it all the time, updating the BBox to the new dimension & position.

The current test seems to hope to change the BBox only when the volume
is reduced (and given that the code does not allow a side to extend, in
fact that means that at least one side is reduced... but why compute a
product of 3 terms instead of comparing two set of 3 terms (with OR,
which means possible shortcut in test) ?

On the same issue, configbackend.h seems to provide a lot of infinity
values... CRITICAL_LENGTH, BOUND_HUGE... and yet they seems rather
small. MAX_DISTANCE might also be impacted. (I do not know if the TODO
FIXME is to put it at 1.0e7 (as now) or 1.0e+10 (as in first part of
comment) )

Should the values be boosted to higher values ?
Should CRITICAL_LENGTH be BOUND_HUGE ? (or it disappears ?)
Should volume computation be replaced by a test (bool) for infinite box
(in any one dimension) & a test between two sets of dimensions ?

Post a reply to this message