On 8/31/19 5:09 PM, Andreas Kaiser wrote:
> On Mon, 26 Aug 2019 08:24:31 -0400, William F Pokorny wrote:
> 
...
>>
>> See: https://github.com/POV-Ray/povray/issues/379
> 
> Thanks Bill for creating the issue.
> 
> I assume it was the limited accuracy of float (used in BBox code)
> which caused some problems: There are only 7 significant digits.
> E.g. when you translate a BBox over a large distance it literally
> loses its bits.
> Also adding some +/-EPSILON to the bounds when its size is 1.0e05
> already no longer works.

Yes, thanks, conversion to float a good candidate reason for this 
special treatment. Wonder why it's only applied to CSG and the quadric. 
Is it because the quadric can be part of CSG and there's something about 
quadric bounding making the CRITICAL_LENGTH code necessary for it alone..?

> 
> Generally current POV code could be improved in such situations.
> E.g look at void Box::Compute_BBox(): It assigns its DBL vectors to
> the float vectors of BBox without checking and might lose almost all
> of its significant digits that way.
> 
> bool Inside_BBox(const Vector3d& point, const BoundingBox& bbox):
> It doesn't handle the implicit +/-BOUND_HUGE means +/-Infinity at all.
> 
> The recurring recalcution of an object's BBox while parsing the scene
> file makes things worse and is completely superfluous:
> - do some consecutive rotations and the resulting AABB will grow each
> time
> - translate over some large distances and off are the bits.
> 
> An object's AABB is used in the tracing stage only, IMHO POV-Ray
> should simply compose all transformations during the parsing stage and
> then compute the AABB once.
> This could help a lot to keep AABBs as correct and close to their
> objects as possible.
> 

While it's work that happened before I was as deep in the source code, 
the bounding box code was substantially re-worked v37 to v38. A number 
of issues were fixed while re-factoring the code. The work mostly, or 
all, Christoph's (clipka's) I believe.

With the little I 'really' understand about the two bounding methods, I 
agree, don't and I'm unsure what you mean in parts. Certainly there is 
room for improvement.

My current opinion is accuracy issues due bounding follow accuracy 
issues with our ray -> shape/surface solvers. Today the practical scene 
limits, due ray intersection accuracy, set the working range to >1e-2 to 
maybe <1e5. Though, one can do better or worse depending on many factors.

Further, numerical errors (excluding the extreme crash test kind) in 
bounding are in a different numerical domain. They matter less to the 
'visual' result than errors happening in the ray - surface/shape 
equation normalized / somewhat-normalized domain.

Numerical error in the transforms / inverse transforms matter more, but 
also not as much as the ray surface intersections to 'visual' result.

With bounding - larger is OK/safe. Missing during bounds testing of 
course bad and there is a little of that going on of which we are aware 
in v37 and v38. It's one of a tangle of issues part of the 
https://github.com/POV-Ray/povray/pull/358 effort.

The idea of accumulating transforms before calculating the AABBs has 
merit I think, though I don't see it that simply done. Usually not too 
many transforms after the primitive is created we are into CSG and 
optimal AABBs at that level don't, to me, look easy - excepting some 
cases. Better over optimal AABBs perhaps.

Aside: We've been looking a little at bits of the bbox code due a v37 to 
v38 performance degrade: https://github.com/POV-Ray/povray/issues/363. 
Something for the, what that's worth, basket - maybe my understanding of 
the bounding mechanism will deepen some as a result. I'll keep what 
you've said in mind as I thrash around.

Bill P.

Post a reply to this message