POV-Ray : Newsgroups : povray.binaries.images : Having a try at light distributions Server Time: 19 May 2019 10:32:49 GMT
  Having a try at light distributions (Message 1 to 7 of 7)  
From: Jasper
Subject: Having a try at light distributions
Date: 13 May 2019 11:30:00
Message: <web.5cd95526b9d0796c51138a9b0@news.povray.org>
Hello everyone!

I am trying to introduce photometric data files of luminaires (i.e. IESNA .ies
or EULUMDAT .ldt) in Povray to get "correct" lighting distributions. This
currently works by combining

(1) a point light source
(2) a sphere with radius 0.01 and spherical mapping of an image map (.png with
the alpha channel used for transparency) which represents the lighting
distribution for different angles.

However, for large coordinates (e.g. 1e+6), I get unwanted black spots in a
regular pattern (see attached image on the left).

Jasper


Post a reply to this message


Attachments:
Download 'lum.jpg' (93 KB)

Preview of image 'lum.jpg'
lum.jpg


 

From: Norbert Kern
Subject: Re: Having a try at light distributions
Date: 13 May 2019 18:00:06
Message: <web.5cd9afd734505b1d3c1c78400@news.povray.org>
"Jasper" <nomail@nomail> wrote:
> Hello everyone!
>
> I am trying to introduce photometric data files of luminaires (i.e. IESNA .ies
> or EULUMDAT .ldt) in Povray to get "correct" lighting distributions. This
> currently works by combining
>
> (1) a point light source
> (2) a sphere with radius 0.01 and spherical mapping of an image map (.png with
> the alpha channel used for transparency) which represents the lighting
> distribution for different angles.
>
> However, for large coordinates (e.g. 1e+6), I get unwanted black spots in a
> regular pattern (see attached image on the left).
>
> Jasper


OK, this doesn't have anything to do with radiosity - so I agree on floating
point precision issues as cause...

Norbert


Post a reply to this message

From: Alain
Subject: Re: Having a try at light distributions
Date: 13 May 2019 20:32:46
Message: <5cd9d46e$1@news.povray.org>
Le 19-05-13 à 07:29, Jasper a écrit :
> Hello everyone!
> 
> I am trying to introduce photometric data files of luminaires (i.e. IESNA .ies
> or EULUMDAT .ldt) in Povray to get "correct" lighting distributions. This
> currently works by combining
> 
> (1) a point light source
> (2) a sphere with radius 0.01 and spherical mapping of an image map (.png with
> the alpha channel used for transparency) which represents the lighting
> distribution for different angles.
> 
> However, for large coordinates (e.g. 1e+6), I get unwanted black spots in a
> regular pattern (see attached image on the left).
> 
> Jasper
> 

You may try using a larger sphere when the scale of the scene get larger 
than about 1e+4. It may reduce the rounding errors to some extent.

The best thing to do is to limit the size of the scene to be less than 
1e+5 if at all possible.

Build your scene around the origin. Don't be afraid of negative numbers.


Post a reply to this message

From: William F Pokorny
Subject: Re: Having a try at light distributions
Date: 15 May 2019 14:04:13
Message: <5cdc1c5d$1@news.povray.org>
On 5/13/19 7:29 AM, Jasper wrote:
> Hello everyone!
> 
> I am trying to introduce photometric data files of luminaires (i.e. IESNA .ies
> or EULUMDAT .ldt) in Povray to get "correct" lighting distributions. This
> currently works by combining
> 
> (1) a point light source
> (2) a sphere with radius 0.01 and spherical mapping of an image map (.png with
> the alpha channel used for transparency) which represents the lighting
> distribution for different angles.
> 
> However, for large coordinates (e.g. 1e+6), I get unwanted black spots in a
> regular pattern (see attached image on the left).
> 
> Jasper
> 

Hmm, I have to say I'm curious about the regularity of those black 
spots. The numerical issues I've hit are usually noisier - or completely 
black/invisible/something when a hard numerical limit is hit.

Any chance I could get a smallish test case posted to one of the scene 
file groups? I'll stick it in my POVRay_Issues directory and at least 
take a quick look if not now a deep one.

Bill P.


Post a reply to this message

From: William F Pokorny
Subject: Re: Having a try at light distributions
Date: 15 May 2019 14:11:01
Message: <5cdc1df5$1@news.povray.org>
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.


Post a reply to this message

From: Alain
Subject: Re: Having a try at light distributions
Date: 15 May 2019 19:35:52
Message: <5cdc6a18$1@news.povray.org>
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.
Don't forget that in computing the illumination, there are a few 
squaring and square roots involved. This typically demand twice the 
number of bits of the input value if you want to avoid loss of precision.
When you square a 64 bits floating point value, you need 128 bits to 
accurately represent the result.


Post a reply to this message

From: William F Pokorny
Subject: Re: Having a try at light distributions
Date: 17 May 2019 09:29:40
Message: <5cde7f04$1@news.povray.org>
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

Copyright 2003-2008 Persistence of Vision Raytracer Pty. Ltd.