On 5/15/19 3:36 PM, Alain wrote:
> Le 19-05-15 à 10:11, William F Pokorny a écrit :
>> On 5/13/19 1:56 PM, Norbert Kern wrote:
>>> "Jasper" <nomail@nomail> wrote:
>> ...
>>>
>>> OK, this doesn't have anything to do with radiosity - so I agree on 
>>> floating
>>> point precision issues as cause...
>>>
>>> Norbert
>>>
>>
>> Is this still true for you with recent v38 releases?
>>
>> I'd captured the case(s) you posted a couple years back - my notes say 
>> in 2016. I wasn't able to run what you posted directly on my little 
>> machine, but a cut down scene was fixed when I tested a v3.71 branch 
>> March 17, of 2017.
>>
>> Bill P.
> 
> The version don't matter when you hit the FPU's limits.
...

True. However, the reason I was digging into Norbert's particular 
radiosity normals issue is that I intended to open up a github issue for 
it so we didn't lose track of it.

My view is that unlike other places in POV-Ray where we hit numerical 
issues, really tiny normals should just be treated as zero normals / no 
normals - or perhaps be normalized somehow so they don't cause issues.

Probably good too if 'bad' normal scalings can be detected and the user 
warned before they get ignored - but that's probably hard to the point 
of being practically impossible.

In any case I didn't think his situation should be causing artifacts 
like we were seeing in the output image.

The scaled very tiny normals were causing issues with Norbert's original 
renders in 2016. When I looked at the issue in 2017 to create a github 
issue, it looked like the issue had been fixed. The complication was the 
original scenes as posted - I think even one smaller one posted later - 
were too costly for my little machine. So, I evaluated behavior on 
something I thought similar hoping to use it as the scene for the issue. 
I might have gotten something wrong. I might have done something which 
caused the issue to be there in (v??? don't remember) and gone in the 
3.71 version I was testing against.

If Norbert still sees black spots with his original scenes using a 
current v3.8, the issue still exists and I think we should open a github 
issue for it. It's on my list again to try and run one of his originally 
posted scenes again with v38 - but I'm in the middle of several other 
projects and that won't happen for some time.

Suppose I'm hoping for a quick - "Oh, it works OK now" - answer/status 
from Norbert to save some time! :-)

Bill P.

Post a reply to this message