Am 9/24/2017 um 16:32 schrieb William F Pokorny:

Sorry for the late response, was away for a week.

>>  From what I can tell, especially aimed at architectural
>> pre-visualisation,
>
> So these could likely be a little sloppy. Good to know.
>
This is not what I meant.

>
> - 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?
>
Yes.

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

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

> - 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.
>
Yes.

> - If those two tools have optional script outputs, might we get a look
> at code snipets from both tools with example use?
>
No script output, if this is indeed what you mean. But for sure script 
input ;)


> - Also wonder if full spherical profiles are common or if it is
> primarily spot/directional lights?
>
There are e.g. light bulb and neon tube IES profiles as well. But as far 
as I understand it, IES profiles are focused on the fixture and
others than spotlights are hard to come by and/or are not very 
reliable/useful.

> 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?
>
No.

> 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.
>
Both are unbiased, brute force render engines so I guess the few extra 
calculations simply don't matter given the extreme amount of rays they 
shoot anyway.

> One last question. Do these other ray tracing tools implement EULUMDAT,
> ..ldt, support too?
>
No. But, as far as I understand it, this would be even better.
Maxwell Render and Mental Ray (I once tried the free trial versions of 
both, just to see what the Pros are working with) do support them.


> 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.
>

A few links from my collection that might be of interest.

A freeware IES file viewer:
http://www.photometricviewer.com/

A small collection of IES profiles for "artists" that DO work very well:
http://www.derekjenson.com/3d-blog/ies-light-profiles

At the bottom of the side is a tool that claims to convert EULUMDAT to 
IES, but I haven't tried it by myself yet:
http://www.helios32.com/resources.htm



-Ive

Post a reply to this message