Cycles LightAttribute Feature Request

It would be great if Cycles shaders had an input for light attributes. In addition to the Attribute Node there would also be an input node called LightAttritbute. You could then set attributes on light sources. When a ray reached a surface from a light source with an attribute the value of the attribute would be made available to the shader.

There are tons of applications for a feature like this. You could set a LightAttribute called EyeOnlyLight=1 for a light to bring out sparkly eyes without spilling onto the face. Or you could set a LightAttribute called BlackLight=1. The shader could add a totally different color (like purple) if that flag is set from the light ray.

The shaders would have to be clever to take advantage of LightAttributes, but it opens doors to effects that aren’t currently possible.

Please Comment as an upvote if this feature would benefit you.

I’m not sure if they would add this feature being that it would likely create significant overhead in the ray traversal code that would slow things down for the majority of artists. Being that pathtracing works in the reverse of the real world, light rays are never emitted from lamps, so to make this feature available it would require a lot of back tracking and checking every time a ray hits a light source. In some cases entire paths would be jettisoned (and the time taken to trace them wasted), and every single time a lamp is directly sampled from a surface shader, the code would have to check the lamp first to see if it has the right attribute.

yeah as jdent02 pointed out, it doesn’t work like that.
But still iirc you can attach messages to rays in OSL. So (if my information is correct) you can already do something like that except only in OSL and only in the opposite direction.

Interesting. I’ll have to check out the OSL route and see how that works. Thanks for the suggestion.

Would it really slow down the renderer so much? As I understand a ray is traced from the camera and bounces a bunch of times until it finds a light, at which point all the surface shaders in the path are evaluated using the intensity information from the light. First the first bounce (closest to the light), then the second bounce, on back to the camera. What I suggest is just to hand each shader along the way a handle to the light.

Am I misunderstanding how this works?

The code would probably have to analyze the entire path and tag the last ray segment before it terminates at the light (optionally with a different tag depending on what group the light or the object containing the material is in). I think it might be doable in terms of the Cycles paradigm, as the ray analysis would be similar to what’s already accessible via the lightpath node.

The only caveat, I guess, is that the light properties could only affect lighting calculations and not surface properties. For instance, you couldn’t use a light property to modify a surface normal or the roughness of a surface because by the time the data would be available it’s already too late.

But this would be quite useful for adding unrealistic lighting effects, and I readily admit such a thing would be VERY useful for product renderings.

That would be because in Cycles currently, the way things work is sample > evaluate > sample

What would be needed in this case is a way to introduce a two stage evaluation model for each sample, so you go to…

sample > evaluate > analyze > re-evaluate > sample

The analysis stage would get the color and other surface information and the re-evaluation stage would alter that information through means like applying color change or activating another part of the node tree based on the light intensity.

Limiting a light to a material should be possible. Camera shoots ray, when the ray hits the material it gets a message attached, ray travels further, when it hits the light the shader of the light checks wether the message is attached and acts accordingly. No back-traversal needed. This way you could limit lights to materials without having to resort to the current options of diffuse only or glossy only which are rather limited.

This is actually quiet common in other render engines and called “Light Linking”. The only difference would be that you link the light to a material while in other engines you usually link to objects.

How about an “IS NOT DIRECT” light ray property so we can deal with shadows more easily, putting something over existing images or video. I imagine using a ground plane with this option, controling he shadow vs transparance over the backdrop

Light linking (or grouping) is on the cycles todo list, when will it be implemented, I don’t know.

That is great to hear! Blender and Cycles are awesome software. I was honestly surprised to find that this feature didn’t exist. It seems like a required feature for serious professional work. And it’s just plain handy for hobby work too :slight_smile: