This feature will be in the 2.90 release?

In T78008#988005, @Augusto Cezar (hilth) wrote:

This feature will be in the 2.90 release?

No. 2.90 is in Bcon3 and no new features are being add.

So, this feature will be removed/forget? I was super excited about it.
is there a way to implement it with an Addon?

In T78008#988014, @Eitan Traurig (EitanSomething) wrote:

In T78008#988005, @Augusto Cezar (hilth) wrote:

This feature will be in the 2.90 release?

No. 2.90 is in Bcon3 and no new features are being add.

In T78008#988442, @Augusto Cezar (hilth) wrote:

So, this feature will be removed/forget? I was super excited about it.
is there a way to implement it with an Addon?

The feature is planned to make it into Cycles/Blender at some point. It probably needs a bit of polishing and potentionally a few issues fixed first (I believe the patch doesn't work with adaptive sampling, not 100% sure).

As for implementing it into Blender yourself, you can take the patch and apply it to your own build of Blender. However, I believe some manual work may be required to work with Blender in it's current state. Juan Gea has a build of Blender with this feature built in. You can find it over on GraphicAll
Windows: https://blender.community/c/graphicall/Mlbbbc/

Thanks!

In T78008#988772, @Alaska (Alaska) wrote:

In T78008#988442, @Augusto Cezar (hilth) wrote:

So, this feature will be removed/forget? I was super excited about it.
is there a way to implement it with an Addon?

The feature is planned to make it into Cycles/Blender at some point. It probably needs a bit of polishing and potentionally a few issues fixed first (I believe the patch doesn't work with adaptive sampling, not 100% sure).

As for implementing it into Blender yourself, you can take the patch and apply it to your own build of Blender. However, I believe some manual work may be required to work with Blender in it's current state. Juan Gea has a build of Blender with this feature built in. You can find it over on GraphicAll
Windows: https://blender.community/c/graphicall/Mlbbbc/

Awesome.

From a usability perspective and to keep the number of passes the same as they are now, it would be nice to have all of the light group passes combined into the existing passes (exported as multilayer exr when saving). That way a new compositor node 'light group mixer' could be used to tweak the influence of each light group for each 'combined' pass.

the same node could be used to seperate the combined pass:

That could be interesting, from and exr multilayer point of view they would be just normal passes right? (I’m thinking in using this with Fusion or something like that)

yeah, standard multilayer exr per pass when saving to exr.

Another interesting option would be to have a color per pass, to be able to lit the passes, and to enable the black body node in the compositor, that way we could render everything with pure white light and change the light temperature in post.

Is something usual, but right now we have to use a mix node in multiply and sample the right color for the right temperature.

yes, you could do that with the node above by multiplying the output of the individual light groups by a colour. It would be nice to add it to the node though for ease:

So when is it going to go live or in a beta? I can't seem to track the task.

Chaos implemented Light Mixer for Unreal Engine, now that Blender is being used in a handful of good VFX shops and studios, having a light pass implementation even in a janky but usable way is a no-brainer in my opinion.

In T78008#1299489, @Reuben Tilahun (reubenx) wrote:

So when is it going to go live or in a beta? I can't seem to track the task.

This task is intended for developers to discuss development of this feature, not for users requesting updates on development.

As for when this feature will be implemented? It will be added when it is ready. The current plan according to the Cycles render meeting is to have it implemented into Blender 3.2, but there could still be delays: https://devtalk.blender.org/t/2022-1-18-blender-rendering-meeting/22437

Would it be possible to have these light groups embedded in the individual passes (diffdir, diffind, diffcol), and then seperate them afterwards? If the denoise node could also be updated to preserve the (modified) group id data, then we could still do multipass denoising and separate afterwards. At the moment if they only live on their individual combined passes, then they're not too useful because render times will need to be dramatically increased if multipass denoising isn't possible. Denoising them all individually isn't ideal because if you have 20 light groups you'd need 20 denoise nodes, and the result would still be inferior to denoising on a pass level (dir, ind)

Seperate them after denoising with a new comp node that looks something like this:

In T78008#1335155, @michael campbell (3di) wrote:

Would it be possible to have these light groups embedded in the individual passes (diffdir, diffind, diffcol), and then seperate them afterwards? If the denoise node could also be updated to preserve the (modified) group id data, then we could still do multipass denoising and separate afterwards. At the moment if they only live on their individual combined passes, then they're not too useful because render times will need to be dramatically increased if multipass denoising isn't possible. Denoising them all individually isn't ideal because if you have 20 light groups you'd need 20 denoise nodes, and the result would still be inferior to denoising on a pass level (dir, ind)

Something like that would require a lot of modification on the compositor side and is definitely out of scope for this ticket. However, also producing individual light passes per lightgroup is something that could be added.

Thanks. I'm not sure individual light passes per light group would solve the issue because it would still require an unfeasible number of denoise nodes, particularly if you have 10 light groups for example, as you'd need 90 denoise nodes to achieve multipass denoising. Perhaps if the light groups could be represented by unique colour in the upper range of the dynamic range (colours chosen based on what's not already present in the actual render data), they could be denoised as part of the image and then extracted afterwards. That way you'd only need a maximum of 9 denoise nodes for full multipass denoising. Not sure how do-able that is though.

In T78008#1337653, @Lukas Stockner (lukasstockner97) wrote:

In T78008#1335155, @michael campbell (3di) wrote:

Would it be possible to have these light groups embedded in the individual passes (diffdir, diffind, diffcol), and then seperate them afterwards? If the denoise node could also be updated to preserve the (modified) group id data, then we could still do multipass denoising and separate afterwards. At the moment if they only live on their individual combined passes, then they're not too useful because render times will need to be dramatically increased if multipass denoising isn't possible. Denoising them all individually isn't ideal because if you have 20 light groups you'd need 20 denoise nodes, and the result would still be inferior to denoising on a pass level (dir, ind)

Something like that would require a lot of modification on the compositor side and is definitely out of scope for this ticket. However, also producing individual light passes per lightgroup is something that could be added.

Hi everyone !
Thanks Lukas for your work on this subject. I'm really happy to finally see lightgroups in blender.

Just a little question/suggestion : Do you think it will be possible to have more like a tag system to assign lights to multiple lightgroups ?
(Ex: a light with, "lgtA, lgtB, lgtC" or something like "lgtA||lgtB||lgtC" will be add to lightgroups "lgtA", "lgtB" and "lgtC" previously created with tour actual system.) This would add a little more flexibility in the assignation ?!

Lights are only in one light group by design, they are meant to sum up exactly to the combined result. There is no plan to change that.

In T78008#1348138, @Quentin (Eqkoss) wrote:

Hi everyone !
Thanks Lukas for your work on this subject. I'm really happy to finally see lightgroups in blender.

Just a little question/suggestion : Do you think it will be possible to have more like a tag system to assign lights to multiple lightgroups ?
(Ex: a light with, "lgtA, lgtB, lgtC" or something like "lgtA||lgtB||lgtC" will be add to lightgroups "lgtA", "lgtB" and "lgtC" previously created with tour actual system.) This would add a little more flexibility in the assignation ?!

It's much better if the end-user does that in the compositing software of choice.

In my workflow I use only environment lighting (not light objects) to separate the lighting setup process from the main scene (kind encapsulation approach from programming). I find the "Support having different environment lighting in each light group" is a very important feature because the HDRI map is synthes of light sources. I generate HDRI maps using a separate .blend file. The different camera positions need different HDRI "fingerprints" to receive perfect results (in product visualization, kind of conveyor rendering). Additional light groups for the second, third, etc. environment can help in the post production. It is so cool - we have only one rendering cycle to receive a multilayer .exr file with different lighting presets. Thank you guys for innovations!