patch works really well. Best implementation I have seen until now in an open source renderer. UI-wise, I would add a new lamp type. I mean, actually point, hemi, spot and area lights are particular cases of what IES lights can be. For new users (and also old ones like me :D ), it's really not intuitive to make a point-light (some lights are very long or are big squares so far away from a point) and then add a texture to it that is plugged not in color like usual but strength. For an artists, it would be much better to have a IES light type.

I would like to test this new IES lamp
so wondering if there is a build available for win 64 ?

I have a lot of IES files and can test it

thanks for any feedback
happy bl

any minimum doc for this new patch
giving general data's for these IES specs ?

IES Std

there are 2 IES - one for US and one for EU

note: In the USA many large manufacturers of fixtures still have old IES std from 1990
so just hope it can be read too!

so just wondering which IES files can be read here!

Thanks
happy bl

@Sergey Sharybin (sergey) any updates here on the review front? :)

Would be good to have it early in master to have a good testing before 2.77 :)

I think you are right and this per light overhead is worth the price.

Some general questions:

• Why IES was decided to be in the ShaderManager?
• Don't see why can't we move to LUT for both SVM and OSL?
• Perhaps it makes sense to add parsing facilities to the RNA API, similar to the PontDensity? So we don't need to re-implement this code for all the render engines (upcoming OpenGL PBR?). This is something where @Campbell Barton (campbellbarton) could have storng opinion as well.

I'm working on improving this patch right now, but I've got no idea how to improve the OSL handling. I could duplicate the interpolation into OSL, sure, but in the end it will always need a way to access the LUT data and therefore need a way to call code "outside" of OSL.
However, I don't see a way to to implement this without using the texture name hack. Also, considering that it's used already for image slots, there probably is no better way to implement this.

So, I'd be open to suggestions here, but I don't really expect that there's a better way to do it...

Ok, will have a look of how to make it all nice for OSL.

could someone please revise it, i have no problems using it in experimental build & would be very welcomed if it was included in the 2.79 release

Hi everyone.
In my opinion this should be a standard feature. Not only ies but also ldt.
And should go, if possible, in a nightly build.
Is there some way to test it?
can't complie it succesfully on debian9.

I don't know of a better way to handle the OSL problem, the current method seems ok to me.

From a quick review of the patch, it seems fine to me. I did a few tiny tweaks.

Making IES parsing available to Eevee as well would be nice, but someone can always do it later.

I saw some of @Sergey Sharybin (sergey)'s comments were addressed, but did not check if it was all of them.

Thanks for the cleanup, I forgot to check the older code for style. I think I missed some comments, I'll do another pass over the patch later today/tomorrow.

Guys,i am a lighting designer and i have been waiting for so long for this feature. I tried the patch and it really worked well. I mean there was so called addon but not giving the correct result, but this patch really works like in lighting calculation softwares. Do you have any idea when it can be implemented to Blender natively? 2.8 release?

Thanks,
and great job!

Glad to hear that it works!

I think this will end up in master soon, I've just finished rewriting the processing code to be a lot cleaner and also support more IES features now (such as 90-270 plane symmetry and photometry type B files), I'll post that later today.

The next release will be 2.8, and it definitely should be done in time for that.

Awesome to hear it reaches 2.8! I am crossing my fingers!

Here is a road lighting visualization i made by using ies datas thanks to your efforts!
https://www.youtube.com/watch?v=5WhTcjNXb4U

And a piece of advise for future developments, i mean i would definitely like to do if i could do coding; light levels = lux levels
False color display would be the best i think. (please google “lighting calculation false colors”)

Great job!
Looking forward a native implement!

Oh, and regarding false-color display etc.: Just go to the color management options and set the view to False Color. If you want control over the colors, use the compositor - F3444053 shows one way to do it, with each color being one power of ten (blue = 0.001, white=10).

I should also point out that you have to be careful with units - IES files are designed for photometry, but Cycles uses radiometric units. Conversion in the IES node is currently hardcoded for a D65 illuminant (see the comment in util_ies.cpp line 162 for details). Generally, you should probably not rely on absolute intensity values.

In D1543#79498, @Lukas Stockner (lukasstockner97) wrote:

Oh, and regarding false-color display etc.: Just go to the color management options and set the view to False Color.

@Lukas Stockner (lukasstockner97) Can we get an AOV that store the amount of incoming light per pixel? That would also be an important information to be displayed as false colors (for example for architects and everyone who is in lighting simulation): http://blog.irayrender.com/post/50640565041/irradiance-buffer

The feature is also sometimes called "Illuminance".

@Orkun (OgDEV) I did the Google search you proposed and it seems like most lighting software offers both luminance and illuminance for false colour display. Cycles currently can show only luminance.

Ah yes lighting calculation softwares can show both luminance and illuminance values. Illuminance values are about the quantity of light that reaches to surface and luminance is about how bright a material is seen under that light; meaning under 500lx of illuminance a light blue material can give 30cd/m2 and a dark blue one 4cd/m2.
I advised this feature since values are important at engineering and designing worlds. Because any scene can be presented at a satisfying light level by changing some parameters, like exposure for instance or ISO. However, if i am doing a design projecting real world, i need values to understand what is going on, if i could achieve the effects on my computer screen at real life.
I have been using the lighting calculation softwares for this purpose up to now (Dialux, Relux ...). After seeing your patch that giving light beams similar to these lighting calculation softwares, i got really excited about the results and the progress you have made, and i thought that "values" can be the next target.
I will check out the compositor solution, thank you very much Lukas for the tip and advises.