On 09/23/2017 08:19 AM, Ive wrote:
> 
>  From what I can tell, especially aimed at architectural 
> pre-visualisation, 

So these could likely be a little sloppy. Good to know.

there is meanwhile a huge collection of IES profiles
with and without fixtures from every lighting manufacturer available.

Yes, even when I played with these years ago, there were a lot of 
profiles out there. They seemed to be provided for every new fixture by 
major manufactures and the first version of the standard dates back to 
the 90s as I remember.

Do you have a link or two providing both MODEL and profile? I just had 
the thought with POV-Ray we could perhaps create our own 'IES profiles' 
- do the intensity measurements ourselves - if we had an accurate model. 
Suppose we'd not even have to bother with IES formats or files 
internally with that approach.

> Including headlights for cars - but surely not for an old VW van ;)
> I'm using IES profiles in Luxrender and Iray with ease and all works 
> very well - just out of the box and without any impact on render time - 
> so I actually never did think much about it ;)
>   Cool, you've used them in other tools! So when you use them, what do 
you know, or could you quickly determine, about what are you in fact using?

- Is the profile information added as extra information into a given 
light source modulating the source intensity as was done in a megapov 
patch in the early 2000s?

- Is it a complete lighting rig with predefined media around the light?

Asking because per-calculating emitting media as part of a 'light 
profile' might be doable and perform reasonably well. In other words 
faking the light/media interaction in the full render where one wants 
the profile represented in media but not the media as an accurate light 
source.

- Do either of implementations put an extra transparent surface with a 
transfer function in play as I was trying?

- Are the implementations otherwise decoupled from / not-tangled with 
the other objects in the scene? I'd guess, yes, but if not would be nice 
to know what other methods are being employed.

- If those two tools have optional script outputs, might we get a look 
at code snipets from both tools with example use?

- Also wonder if full spherical profiles are common or if it is 
primarily spot/directional lights?

I recall a free standing fixture having light bleeding through the back 
side such that the profile isn't the half sphere/horizontal angle sort. 
It had some holes on the topside/backside (venting for heat I suppose?) 
and the sampling looked to have caught some but not all the backside, 
peep hole light bolts. In this case the profile represented the reality 
poorly around part of the fixture. Suppose the support position could be 
the IES is what it is, but on seeing this I wondered whether a good IES 
implementation would offer options to perhaps force symmetry across an 
axis or something.

- Do the two tools you use with IES support 'fix-up/clean-up' options on 
import?

Wonder how it can take zero extra time given extra calculations or 
surfaces must be involved... I guess I could see how 'adc bailout' might 
happen earlier for some rays at the surface of a transparency mapped 
sphere/cylinder, but that approach generates extra rays at the surface 
and transmission calculations overall. If IES is handled in the light 
code itself, I guess it could better prune the surface-look-to-light 
rays as I believe happens today with POV-Ray's spotlights. Though I've 
not spent much time with the light source code.

Question to self: Might the profile itself affect the adapative AA 
algorithm?

I searched just now to see if since I played with IES files, perhaps 
others had come up with some public canned solutions and found this:

https://seblagarde.wordpress.com/tag/ies-parser/

but little else. Well, also one c sharp parser for one version of the 
standard, but looked like no back end for what got parsed.

No. I've not been able to find my own previous aborted attempt even in a 
couple backups...

One last question. Do these other ray tracing tools implement EULUMDAT, 
.ldt, support too?

Thanks for your time and any further information you can offer. I've 
opened up a github issue:

    https://github.com/POV-Ray/povray/issues/322

where we can roll(1) up links, discussion and information. Perhaps one 
of us will take another run at 'IES support' at some point. For now I 
have to get back to some other work.

Bill P.

(1) - On reading your response, my eye caught my previous misuse of 
'roll' for 'role.' :-)

Post a reply to this message