Recently i started playing around with angle-dependent lights to imitage IES Lighting Profiles with Cycles. This trick works with Mesh-Lighting (Emission Shader), as well as Area Lights. I’ve found the Area Lights to behave better than Emission-Planes, mainly because you can independantly adjust the Size and Strength without influencing each other.
Change Lamp Size to vary “fuzzyness” (doesn’t influence overall brightness, unlike emission-planes).
Play around with the ColorRamp to achieve different effects.
How it works
I get the angle between the normal and the incoming ray into the light to determine the light characteristics for this angle: vector-dotproduct: ab=|a||b|cos(phi). both vectors are normalized, so |a| and |b| are both 1, we get cos(phi)=ab
Then this drives a Colorramp to determine the Color/Strength depending on “the angle”. For simplicity i don’t use the angle - arccos(ab) - but just ab, because it’s in the right range [0;1] and i don’t need a linear scale.
The additional Light Falloff Node helps reducing the overly bright spots near the lamp, so it’s not “physicly correct” but can help alot reducing noise/fireflies.
To use real .ies files, someone would simply have to write an converter to write the data into an image file, which could then replace the ColorRamp-Node. This could be a very nice feature for people doing architectural renders. making some image files as a library for different lights.
The best thing would be a direct implementation for .ies files in lights… and that’s at the moment still a bit over my head. The script sounds a bit complicated to work with (working with the second example picture with only 18 values was already a bit of a pain) reading an image would be way user-friendlier, and i only proposed this for convenience so you could get some free .ies files and convert them easily, for custom stuff you can still use colorramp, or even other textures, like a wave texture there. Feeding the dotproduct into it’s coordinates, works well too:
I believe such a thing would’ve been possible since the ramp node was committed, but he seemed to be the first one to actually try using something like the geometry node to modulate the power of the light.
Testing it myself, it looks to be a pretty impressive trick, while it is true that there’s no specific sampling or speed advantages with this setup, it essentially means that we have discovered a way to turn a mesh emitter into a spotlight without using the actual lamp type. (which means you have all of the indirect and mesh-related goodies as well like caustics and an adjustable start radius.)
Not to hijack this thread, but noting that it might be time consuming to set this up over and over again if needed, I decided to take the liberty of converting this system to a group node format which can be found in this file. Cycles_spotTest.blend (428 KB)
The group node contains various controls on the width of the light cone as well as a few more to control the visibility and falloff of a common IES type similar to what is already seen in this thread. I will note that for flexibility reasons, it may not be the best to include a pre-defined ramp node in the setup, but it’s the best that can be done until a developer gives the user the ability to embed widgets like the ramp inside of the group node interface.
Well, dont tell you not ask…
21 min, it was so cool to play with ramp. Thanks for idea.
I have no yet spot lamp support, tiny quad used as light source. (point light is not useful because it reset normal to always have dot()=1)