Cycles: Light Group render passes improvements #78008

Open
opened 2020-06-18 19:16:53 +02:00 by Brecht Van Lommel · 54 comments

Initial implementation: D12871: Cycles: Light Groups

Improvements (color indicates estimate for difficulty):

Initial implementation: [D12871: Cycles: Light Groups](https://archive.blender.org/developer/D12871) Improvements (color indicates estimate for difficulty): - [x] {🟢} [D14540: Cycles/UI: Support adding Lightgroups from the object/world properties](https://archive.blender.org/developer/D14540) - [x] {🟢} [D14740: Render: Update lightgroup membership in objects and world if lightgroup is renamed](https://archive.blender.org/developer/D14740) - [x] {🟢} [D14596: Render: Add operators to add all used or remove all unused lightgroups to a view layer](https://archive.blender.org/developer/D14596) - [ ] {🟢} Support setting lightgroup on a per-collection basis - [ ] {🟡} Support viewing Lightgroup passes in the viewport - [ ] {🟡} Support denoising Lightgroup passes - [ ] {🟡} Support splitting the sun and sky parts of the Nishita Sky model between groups - [ ] {🔴} Support having different environment lighting in each lightgroup
Author
Owner

Changed status from 'Needs Triage' to: 'Confirmed'

Changed status from 'Needs Triage' to: 'Confirmed'
Author
Owner

Added subscriber: @brecht

Added subscriber: @brecht
Member

Added subscriber: @Alaska

Added subscriber: @Alaska

Added subscriber: @AugustoCezar

Added subscriber: @AugustoCezar

This feature will be in the 2.90 release?

This feature will be in the 2.90 release?
Member

Added subscriber: @EitanSomething

Added subscriber: @EitanSomething
Member

In #78008#988005, @AugustoCezar wrote:
This feature will be in the 2.90 release?

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

> In #78008#988005, @AugustoCezar 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 #78008#988014, @EitanSomething wrote:

In #78008#988005, @AugustoCezar 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 #78008#988014, @EitanSomething wrote: >> In #78008#988005, @AugustoCezar wrote: >> This feature will be in the 2.90 release? > > No. 2.90 is in Bcon3 and no new features are being add.
Member

In #78008#988442, @AugustoCezar 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/

> In #78008#988442, @AugustoCezar 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 #78008#988772, @Alaska wrote:

In #78008#988442, @AugustoCezar 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 #78008#988772, @Alaska wrote: >> In #78008#988442, @AugustoCezar 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/

Added subscriber: @semimetallic

Added subscriber: @semimetallic

Removed subscriber: @semimetallic

Removed subscriber: @semimetallic

Added subscriber: @semimetallic

Added subscriber: @semimetallic

Added subscriber: @andersonyago

Added subscriber: @andersonyago

Added subscriber: @3di

Added subscriber: @3di

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.

image.png

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. ![image.png](https://archive.blender.org/developer/F10217091/image.png)

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

image.png

the same node could be used to seperate the combined pass: ![image.png](https://archive.blender.org/developer/F10217097/image.png)

Added subscriber: @juang3d

Added subscriber: @juang3d

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)

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.

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.

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:

image.png

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: ![image.png](https://archive.blender.org/developer/F10217367/image.png)

Added subscriber: @ahmed.hindy96

Added subscriber: @ahmed.hindy96

Added subscriber: @BintangPratama

Added subscriber: @BintangPratama

Added subscriber: @DiegoCortes

Added subscriber: @DiegoCortes

Added subscriber: @Dabreiss

Added subscriber: @Dabreiss

Added subscriber: @Garek

Added subscriber: @Garek

Added subscriber: @Reuben-4

Added subscriber: @Reuben-4

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

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.

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.
Member

In #78008#1299489, @Reuben-4 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

> In #78008#1299489, @Reuben-4 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

Added subscriber: @Max-Knol

Added subscriber: @Max-Knol

Added subscriber: @boberfly

Added subscriber: @boberfly

This issue was referenced by ad35453cd1

This issue was referenced by ad35453cd19b3db779b0b3a90feac2e93c7a73cf

This issue was referenced by 351c00d29a

This issue was referenced by 351c00d29ab1d41867bfbae77b92625e5bf442e6

This issue was referenced by 79ff65d07b

This issue was referenced by 79ff65d07bac0ecf0170542f86dc03a0228b53d5

This issue was referenced by 3214028ae8

This issue was referenced by 3214028ae822d6b9b1622589d27dd9b9746f2aa8
Lukas Stockner changed title from Cycles: light group render passes to Cycles: Light Group render passes 2022-04-04 17:46:13 +02:00

Added subscriber: @SteffenD

Added subscriber: @SteffenD

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:

image.png

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: ![image.png](https://archive.blender.org/developer/F12970426/image.png)

Added subscriber: @Yuro

Added subscriber: @Yuro
Member

Added subscriber: @LukasStockner

Added subscriber: @LukasStockner
Member

In #78008#1335155, @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.

> In #78008#1335155, @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 #78008#1337653, @LukasStockner wrote:

In #78008#1335155, @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 #78008#1337653, @LukasStockner wrote: >> In #78008#1335155, @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.

Added subscriber: @GeorgiaPacific

Added subscriber: @GeorgiaPacific

Added subscriber: @Eqkoss

Added subscriber: @Eqkoss

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 ?!

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 ?!
Author
Owner

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.

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 #78008#1348138, @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 #78008#1348138, @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.
Brecht Van Lommel changed title from Cycles: Light Group render passes to Cycles: Light Group render passes improvements 2022-05-25 16:48:47 +02:00

Added subscriber: @fldbots

Added subscriber: @fldbots

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!

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!

Added subscriber: @dursunumit

Added subscriber: @dursunumit

Added subscriber: @Emi_Martinez

Added subscriber: @Emi_Martinez
Brecht Van Lommel added this to the Render & Cycles project 2023-02-07 19:08:06 +01:00
Philipp Oeser removed the
Interest
Render & Cycles
label 2023-02-09 14:02:05 +01:00

Hi all,

Is it possbile to enable passes in lightgroup ? At the moment, a lightgroup is exported in multi-layers EXR as combined_World, combined_Key in my example and I think it's, I hope, easier to have a button to add global passes in lightgroup like :

  • DiffDir_World
  • DiffInd_World
  • DiffCol_World
  • GlossDir_World
  • ...
  • GlossCol_key

Why I'm asking for this, two things, the first one, denoising by channel Diff, Gloss and co are better than put it directly on the ligthgroup combined passe (in Blender or in Fusion using ODIN plugins or in Nuke using Neat Video, done this on a movie). The second, When you do VFX or 3D serie where you want full control in compositing to avoid re-render frame, the possibility to have all the passes by lightgroup help a lot (recompute only a GlossCol to change a glossy texture and use cryptomatte, really fast !!!).

At the moment, I do it manually using layers and it's a very slow process to build this. Make a script is possible, I need to do this, but not effective in rendering time (multiple render instead one, ok, more memory effective but...).

Hope it possible right know with a secret command or hope can by done in code for the next build.

Thank you for your time to read this and for your incredible work for Blender.
Best Regards,

Matt

Hi all, Is it possbile to enable passes in lightgroup ? At the moment, a lightgroup is exported in multi-layers EXR as combined_World, combined_Key in my example and I think it's, I hope, easier to have a button to add global passes in lightgroup like : - DiffDir_World - DiffInd_World - DiffCol_World - GlossDir_World - ... - GlossCol_key Why I'm asking for this, two things, the first one, denoising by channel Diff, Gloss and co are better than put it directly on the ligthgroup combined passe (in Blender or in Fusion using ODIN plugins or in Nuke using Neat Video, done this on a movie). The second, When you do VFX or 3D serie where you want full control in compositing to avoid re-render frame, the possibility to have all the passes by lightgroup help a lot (recompute only a GlossCol to change a glossy texture and use cryptomatte, really fast !!!). At the moment, I do it manually using layers and it's a very slow process to build this. Make a script is possible, I need to do this, but not effective in rendering time (multiple render instead one, ok, more memory effective but...). Hope it possible right know with a secret command or hope can by done in code for the next build. Thank you for your time to read this and for your incredible work for Blender. Best Regards, Matt

Can we get an update on this please? Denoising for light groups are a must. :-)

Can we get an update on this please? Denoising for light groups are a must. :-)
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No Assignees
27 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#78008
No description provided.