On 9/2/19 6:30 PM, Bald Eagle wrote:
> 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?
Not in any of the mainstream versions. My solver patch branch:
supports a PRECISE_FLOAT macro mechanism for the common solver code.
It's expensive. Even long double which is on my i3 still hardware backed
was something like +150% slower IIRC. More detail on these and 128 bit
float experiments are posted about elsewhere.
My first concern with the comment to which you attached your question
isn't the potential loss of accuracy on any particular conversion given
our hard coded +-1e7 range limit, but that we are doing all these double
to single conversions which are fast opcodes, but not free.
There is a storage savings to using single floats and - in theory - a
potential to fit more single floats in any one SIMD register for
potentially faster math. However, I think due other v37/v38 code changes
the SIMD aspect mostly not happening in practice even on machine
targeted compiles. Such gains mostly don't happen with machine generic
compiles in any case.
A valid first accuracy concern - not an AABBs growing and growing by
rotations concern - I think is that we don't today accumulate as many
transforms (stored as doubles IIRC) as possible before updating the
bounding boxes, but rather - often enough - do them as they come. Each
seeing double to float conversions and potential value snapping.
Andreas's suggestion is to do the bounding box update once to a 'final'
transform and I agree this likely better.
>> 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.
I have thought about the parsing + bounding process creating a least
enclosing environment box which users can access. The exposure I see is
more than the final scene scale. It's that users can today use
intermediate original definitions or transformations which corrupt the
accuracy of the final rendered representation mostly without notice.
>> 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...
What you describe sometimes happens today and sometimes not. Numerically
for the solvers I'd like it to happen more often, but what that really
means for some shapes - sphere_sweeps for example, isn't all that clear.
Further there are other trade offs in play. On my list is a completely
different implementation for spheres using a normalized representation
so I can do some comparisons.
The new solver approach discussed elsewhere might support trade-offs
traditional solvers don't - normalization is potentially less important
numerically with the new approach. It's complicated - so much so I daily
doubt what I can really do - especially given my personal C++
impediment. Some recent ideas potentially break from recent POV-Ray code
direction too which means I'm not sure what, longer term.
> 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."
I now know the scene scaling is two edged. You can get into as many
issues scaling up as down. It just happens, I think, given the
asymmetric nature of our current practical range, and that people tend
to create data about zero, that scaling up often better centers scenes
for POV-Ray's current numerical condition.
Post a reply to this message