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