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