POV-Ray : Newsgroups : povray.bugreports : Two BBox calculation bugs in CSG and Quadric? : Re: Two BBox calculation bugs in CSG and Quadric? Server Time
17 Sep 2021 06:45:43 EDT (-0400)
  Re: Two BBox calculation bugs in CSG and Quadric?  
From: Bald Eagle
Date: 2 Sep 2019 18:35:00
Message: <web.5d6d9804c6c13c7b4eec112d0@news.povray.org>
William F Pokorny <ano### [at] anonymousorg> wrote:

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

I haven't dug down to _that_ level of the source code, so forgive me if this is
a naive question, but does POV-Ray make use of "extended precision" floats?


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

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

Perhaps there's a way to track the min/max ranges and report on them in the
scene statistics?  It might help in debugging scenes, and interpreting user
feedback when there are avoidable problems simply due to scale.

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

Now that I have enough experience, and have asked enough newbie questions, I can
properly envision that CSG code tangle.  eek.   A naive question might be
whether or not a primitive could be internally/virtually/temporarily translated
to the origin and that "metadata" stored somehow.  Then the composed transform
matrix could be applied, and perhaps a modified ray/object intersection test
could be done in a domain where the float errors wouldn't mess everything up...

Sort of an automated version of your suggestion here:

"Today, you can 'sometimes' clean up many of the artifacts by
scaling the entire scene up (or down) by 100 or 1000x."

Post a reply to this message

Copyright 2003-2021 Persistence of Vision Raytracer Pty. Ltd.