On 12/23/2015 09:53 AM, clipka wrote:
> Am 23.12.2015 um 08:00 schrieb Sven Littkowski:
>
>> This test code still shows the following errors (I just tested):
>> - non-textured or hollow ring-shape border errors (negative values)
>
> Here's the news: It /is/ related to numerical precision, though
> unfortunately not in the portion that is affected by the "sturm"
> keyword. If you scale the whole scene down by a factor of 0.01, those
> artifacts disappear entirely.
>
> Also, POV-Ray 3.6 shows the same behaviour, so this is not a simple case
> of just figuring out what was accidently changed and amending the new
> code accordingly. Instead, it would require someone with a knack for
> numerical precision issues to look really closely at the code for a
> while, figure out where exactly stuff breaks, and come up with some
> smart way of avoiding the issue.
>
> Until then, I would recommend keeping blob sizes in the single-digit
> range (after scaling).
>
>
>> - boxish texture problems in cupola shadow areas on cupolas
>> - no dark shadow on lower blob areas (the gray hull has them)
>
> See my other posts.
>
Christoph,

For what it is worth, I was following the same numerical accuracy trail. 
Leaving things at Sven's current scale ad changing the following in 
blob.cpp from

/* Minimal intersection depth for a valid intersection. */
const DBL DEPTH_TOLERANCE = 1.0e-2;

to

/* Minimal intersection depth for a valid intersection. */
const DBL DEPTH_TOLERANCE = 1.0e-3;

was enough to clean up the solution.

I am not an expert at numerical algorithms but I look at these two 
settings in blob.cpp and I wonder if the values are not perhaps set for 
the old single precision days?

/* Minimal intersection depth for a valid intersection. */
const DBL DEPTH_TOLERANCE = 1.0e-6;      // previous value 1.0e-2

/* Tolerance for inside test. */
const DBL INSIDE_TOLERANCE = 1.0e-12;    // previous value 1.0e-6

I'd think values such as those updated above not unreasonable these 
days. The above runs OK on the few blobs I have. I don't understand 
enough of the algorithm to know if there are other implications for 
moving to much tighter tolerances.

Aside: AA was tending to hide the numerical artifacts which happen in 
quite a few places other than the most obvious in Sven's example. 
Thinking we have perhaps we've been living with some of these accuracy 
issues for a while with AA often cleaning things up to where we don't 
notice?

Bill P.

Post a reply to this message