I found another limitation, some clue on where to look to try to fix it is welcome.

If the light is against the background and the background is transparent the light won't be visible in that part.

The invisible light in front of the background isn't a problem in Cycles - if you check the pixel values of the rendered image, you'll see that the lamp is actually there, but they also have an alpha of zero.
This is consistent with the lamps being transparent - after all, the point of transparent background is that you can composite it over your own background, and since the lamp is transparent, you're supposed to get both the background and the lamp.

The real issue here appears to be in the Image Editor, which does not show the pure-emission pixels correctly. With unpremultiplied alpha (aka correct alpha ;) ), a pixel with zero alpha but nonzero color is perfectly valid.

As for lamps being transparent in the first place - yeah, that's expected as well. After all, if you stack two area lights, the floor will be twice as bright. Therefore, the second light can't be occluding the first one.

Finally: Sorry for not seeing the questions earlier. There's some review comments in the original patch that still apply here, is it fine with you if I fix those?

Of course please! Go ahead, I’m just trying to help and learn, if you want I imagine I can give you permissions in this patch or you can update yours, it doesn’t matter :) the idea is to have this working because it’s a small leap forward of being a finished patch :)

The same applies to the light groups patch, we fixed a bug with collections (@Martin Felke (scorpion81) fixed it :) ) but the patch is already finished IMHO, unless you think something more is needed.

I can upload a diff with all the updates for that one too if you want.

(Now that I think about it... you already have write permissions here, right? :) )

In D5769#132920, @Lukas Stockner (lukasstockner97) wrote:

The invisible light in front of the background isn't a problem in Cycles - if you check the pixel values of the rendered image, you'll see that the lamp is actually there, but they also have an alpha of zero.
This is consistent with the lamps being transparent - after all, the point of transparent background is that you can composite it over your own background, and since the lamp is transparent, you're supposed to get both the background and the lamp.

The real issue here appears to be in the Image Editor, which does not show the pure-emission pixels correctly. With unpremultiplied alpha (aka correct alpha ;) ), a pixel with zero alpha but nonzero color is perfectly valid.

As for lamps being transparent in the first place - yeah, that's expected as well. After all, if you stack two area lights, the floor will be twice as bright. Therefore, the second light can't be occluding the first one.

Finally: Sorry for not seeing the questions earlier. There's some review comments in the original patch that still apply here, is it fine with you if I fix those?

Sorry but this is very wrong behavior. There should be no such thing as pure emission pixels, neither should it be possible to stack the area lights behind each other and get twice the illumination. That's not how any physically based renderer should work. Area lights should be same as emissive geometry, just with better sampling due to representing primitives which can be sampled analytically.

If I create an area light with the intensity of 0.1, I expect to get an opaque plane with the emissive intensity of 0.1. No transparency. If I add two area lights behind each other, I expect the area light closer to the surface to occluded illumination of the area light further, casting a shadow. I do not expect any ghost geometry. I expect the shadow casting of the area light to be possible to be disabled by unchecking the shadow ray visibility flag:

If the patch ends up working this way then the usefulness of the area lights will be extremely limited. Area light surface should represent a solid object, not a volumetrics.

There is no mainstream production renderer out there which renders area light as non shadow casting transparent objects. If that would be the case, then such behavior would turn very problematic in many production scenarios.

Well, I agree in that having the light as a opaque object should be the expected behaviour, I imagine that if the problem is that is stacks two lights then one of them should be disabled or at least disable it's emission capabilities, that we we would not have double light, but the alpha should be 1.0 as soon as we make the light visible, at least I cannot imagine any other situation where I could want to have a 0 alpha light.

But if you can imagine some case it's as easy as making it an option, something like "solid light" to enable/disable the alpha of the light, that way any situation would be covered I think.

In D5769#132929, @Juan Gea (juang3d) wrote:

Well, I agree in that having the light as a opaque object should be the expected behaviour, I imagine that if the problem is that is stacks two lights then one of them should be disabled or at least disable it's emission capabilities, that we we would not have double light, but the alpha should be 1.0 as soon as we make the light visible, at least I cannot imagine any other situation where I could want to have a 0 alpha light.

But if you can imagine some case it's as easy as making it an option, something like "solid light" to enable/disable the alpha of the light, that way any situation would be covered I think.

Well, I would not clutter UI with fakes that someone may, or may not use. If you don't want to see the light, then you can simply turn off the Camera ray visibility flag. If you want to see the light but don't want it to occlude other lights, then simply turn of Shadow ray visibility flag. All that's really needed here to cover most of the production scenarios is that every single of these flags works correctly with area lights :)

I tried to find where is the alpha of the light managed, but I'm unable to find it, so I'm very curious with your evolution on this patch @Lukas Stockner (lukasstockner97) :)

In D5769#132935, @Ludvik Koutny (rawalanche) wrote:

Well, I would not clutter UI with fakes that someone may, or may not use. If you don't want to see the light, then you can simply turn off the Camera ray visibility flag. If you want to see the light but don't want it to occlude other lights, then simply turn of Shadow ray visibility flag. All that's really needed here to cover most of the production scenarios is that every single of these flags works correctly with area lights :)

Or maybe we can just manage the alpha with the alpha defined in the color, by default it would be 1.0 and leave the user decide, this would be useful for "modifying" the actual shape of the emission.

For example we could use a circle gradient in the color to define the actual distribution of a studio light softener

And use the same alpha to define which zones could be more transparent, hence being able to use a rectangle area light with different shapes that could be adapted to any other shape, or this can also help to give variance and defects to the emitting light, for example it could allow to have a "whole" with 0 emission in the center of the area light.
Of course alpha should multiply with the light intensity in those zones, so we get 0 emission where alpha is 0.

Being able to add "masks" to area lights it's a great feature.

In D5769#132941, @Juan Gea (juang3d) wrote:

In D5769#132935, @Ludvik Koutny (rawalanche) wrote:

Well, I would not clutter UI with fakes that someone may, or may not use. If you don't want to see the light, then you can simply turn off the Camera ray visibility flag. If you want to see the light but don't want it to occlude other lights, then simply turn of Shadow ray visibility flag. All that's really needed here to cover most of the production scenarios is that every single of these flags works correctly with area lights :)

Or maybe we can just manage the alpha with the alpha defined in the color, by default it would be 1.0 and leave the user decide, this would be useful for "modifying" the actual shape of the emission.

For example we could use a circle gradient in the color to define the actual distribution of a studio light softener

And use the same alpha to define which zones could be more transparent, hence being able to use a rectangle area light with different shapes that could be adapted to any other shape, or this can also help to give variance and defects to the emitting light, for example it could allow to have a "whole" with 0 emission in the center of the area light.
Of course alpha should multiply with the light intensity in those zones, so we get 0 emission where alpha is 0.

Being able to add "masks" to area lights it's a great feature.

At that point, you would probably lose the efficiency of area light which comes from a solid constant color which can be sampled by solid angle. It would make much more sense to use geometry with emissive material and importance sampling enabled. It would be same performance, but much easier setup to modify and transform UVs on geometry than the area lights.

Honestly, I'd first focus on making sure all the ray visibility flags work correctly and the lights are not transparent before finding ways to complicate things with textures and masks.

True, then the best thing would be to do what you say, focus in finalizing this patch so lights are not transparent :)

BTW @Lukas Stockner (lukasstockner97) I'm eager to see your changes and how do you deal with the alpha thing in the lights, I'm learning a lot from your patches :)