|
|
On Tue, 3 Sep 2019 08:59:44 -0400, William F Pokorny wrote:
>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?
>>
>> https://en.wikipedia.org/wiki/Extended_precision
>>
>
>Not in any of the mainstream versions. My solver patch branch:
>
> https://github.com/wfpokorny/povray/tree/fix/polynomialsolverAccuracy
>
>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:
>>
http://news.povray.org/povray.newusers/message/%3C5bfac735%241%40news.povray.org%3E/#%3C5bfac735%241%40news.povray.org%
>> 3E
>>
>> "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.
>
>Bill P.
I will add deferral of transformation computation and AABB calculation
next although I was doing something different right now.
I will also write down some issues with current use & intersection
calculation of AABBs.
Meanwhile here is a good read (note: really old but valid):
Search the web for "Goldberg What Every Computer Scientist Should Know
About Floating-Point Arithmetic".
The web page at oracle looked broken for me with Chrome wrt. equations
but was fine with Firefox. There are a lot of pdf versions as well.
You don't need to follow every equation, just read over them and get
an idea what can go wrong with floating-point calculations and why.
Most important are rounding errors and cancellation during subsequent
calculations with some good examples.
You'll wonder how well POV-Ray actually works :D
And we'll improve it to work even better ;)
Post a reply to this message
|
|