William F Pokorny <ano### [at] anonymousorg> wrote:
> 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.

Hi Bill,

Thank you for your suggestion. However, it doesn't work, even when trying, e.g.,
scale <1+1e-3,1,1+1e-3>. I suspected some numerical issues as well (as a POV-ray
beginner, I also just encountered a section called "CSG Pitfalls" in the
Introduction to POV-Ray, which sounds very similar). In a way, it is not a huge
problem to reduce the coordinates, but found it important to understand why it
doesn't work. Anyway, thank you for the advice:)

Jasper

Post a reply to this message