On 5/10/19 7:22 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. In order to
> do so, I combine
> 
> (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.
> 
> My camera view is from above, simulating a satellite view (Z-direction is "up")
> and assuming a simple planar object in xy. While the above-mentioned method
> works in most cases, it seems that for large coordinates (e.g. 1 000 000
> translation of both camera and luminaire in the xy plane), it no longer does (it
> becomes a regular point source), and some black dots appear in the resulting
> image. The strange thing is that it is not the case for translations of, e.g.,
> 100 000.
> 
> Has anyone encountered similar problems and/or knows the reason for this?
> 
> Jasper
> 

Suspect you are seeing numerical issues of some sort. With POV-Ray today 
a good rule of thumb is to keep everything numerically between say 1e-4 
and 1e5, if you can. You can sometimes achieve better and worse. The 
blob's low end is 1e-2 or so, for example. There is a hard upper range 
limit in the code called MAX_DISTANCE currently at 1e7. Long rays to an 
object tend to be numerically more noisy too - I've only very recently 
come to understand how significant that part is.

That said, you are using a sphere and it's one of the shapes POV-Ray 
will move during parsing when it can rather than 'work' in a normalized 
space with transforms to the actual final location as other objects do.

Something you could try... Immediately after you define your sphere add 
a very small non-symmetrical scale like scale <1+1e-6,1,1+1e-6>. Then do 
your translates as normal. If I'm remembering the code correctly this 
should immediately create a transform internally preventing the movement 
of the sphere. Perhaps this would lead to numerically more stable 
results. I'm interested in whether it helps or not if you do try it!

In any case movements by 1e6 in x and y (can mean 1e6 * sqrt(2) max 
ranges) so your playing up near the +-1e7 hard upper limit there no 
matter what.

Bill P.

Post a reply to this message