In reference to this instruction, I think the first step (to keep it as simple as possible) is to only create an exclude mode first. (I think this was suggest before).
In fact all lights are include by default.

I humbly disagree with this notion. Having the ability to only link a certain light to an object via an Include list will in many cases be WAY faster than excluding all other lights. It's been years since I last used C4D, but I seem to remember that it had both an include and exclude list, and I found it extremely intuitive and easy to work with. Oversimplification will do the feature a disservice in my opinion.

Hi dear dev!
Lighting link is a basic function that every DDC must have. I've been a user of maya for many years, its lighting link UI design is very easy to understand, it would be best if we can refer to it.
BTW, I'm curious what's going on here from 2019 till now? why hasn't blender had this basic feature in 3 years?

It’s kinda forbidden to reference other software, but I like this light linking way of working. Blender could improve on it by making the selection easy to understand with icon toggles, same as the outliner. This turning blue thing is confusing and just looks like a random selection. It’s a clear opportunity for Blender to build the best and hopefully visual solution.

In T68915#1367653, @Neo_Hoa (NEEO) wrote:

Hi dear dev!
Lighting link is a basic function that every DDC must have. I've been a user of maya for many years, its lighting link UI design is very easy to understand, it would be best if we can refer to it.
BTW, I'm curious what's going on here from 2019 till now? why hasn't blender had this basic feature in 3 years?

Hi Neo,

We already talk about that Idea on previous posts.
The main point is that we can't just copy past that.
Also create a double ui list is not simple as that, it need to create a light linking UI and dev adapted to Blender and as you can know, blender is not programming as maya or other software.
It's also difficult to create a proper UI without the backend programmation because it's often staying at the speculation step.

Moreover, do not post images from other software. If I'm not wrong, it's forbidden, so carefull :)

As I mentionned on previous posts, creating a double ui list for light linking (or other template) is in my todo liste, but I don't have the time to work on it at the moment and that's not so easy... I Hope someone will create and share some Idea(code) here.

Resources are limited, many other features made it, for example Light Groups and NME for 3.2, there is one person working on this that cannot dedicate full time, if you can find a developer that want to help, you are mostly welcome, we all agree that it is an important feature, but resources are required for it to be developed and this is as important as other features :)

Regarding the Maya reference, no, it cannot be used as a reference due to copy right matters, so if you want to explain your vision of how the feature may work it will be great, but you have to explain it from the ground up, no references to other softwares at all.

P.S.: please @Neo_Hoa (NEEO) delete those pictures, they are breaking the rules :)

IMHO the UI for light linking should be represented in Nodes, in the same way we handle objects/collections in GN, the lights already have a nodes UI and it can be leveraged for this.

IMHO the UI for light linking should be represented in Nodes

That could be a complete mess for complex jobs. How would you handle parented objects? Like I want the light linked only on the windshield but not the reste of the car.

In T68915#1367658, @Juan Gea (juang3d) wrote:

IMHO the UI for light linking should be represented in Nodes, in the same way we handle objects/collections in GN, the lights already have a nodes UI and it can be leveraged for this.

I think the idea is rather good, it echoes the geometry nodes and the will of Blender: "everything nodes".
I don’t know much but I know that this system already exists in other softwares like Guerilla (and Houdini?)
From what I know, it seems a little less "friendly users", however it seems to be more dynamic.
However, it must not be easy to implement.
In terms of nodes, I also agree with you, there are already nodes for lights that have in my opinion no usefulness (or at least I never needed them). It may indeed be appropriate to exploit them.
it refers to a proposal I made earlier, which, I agree, is not perfect:

In T68915#1297857, @Quentin (Eqkoss) wrote:

Hi guys !

As mention before, this is a little presentation of what a light linking in nodal could be. This is a rough and lots of things can be added or simplify. This is based on what already exist in the shader graph.(Node color is simply for comprehension purpose)

• Global Illumination simply said if the light illuminate all the scene it's a boolean value (can't be 0.1, 0.2, 0.003 etc only 0 or 1).
• Include/Exclude is also a boolean value (can't be 0.1, 0.2, 0.003 etc only 0 or 1).
• Combine Emission is dynamic, it's automatically create a new input "Emission" when the previous one is plug.
• Collecioin Linking only look for Collections in the scene.
• Geometry Linking only look for Geometries in the scene.

there are already nodes for lights that have in my opinion no usefulness

You might want to check this out: https://www.youtube.com/watch?v=C4UM57HAt0E&t=4s

In T68915#1367668, @Robert Rioux (riouxr) wrote:

there are already nodes for lights that have in my opinion no usefulness

You might want to check this out: https://www.youtube.com/watch?v=C4UM57HAt0E&t=4s

Indeed make sens !
But never used it, thanks for the link mate :)

In T68915#1367665, @Robert Rioux (riouxr) wrote:

IMHO the UI for light linking should be represented in Nodes

That could be a complete mess for complex jobs. How would you handle parented objects? Like I want the light linked only on the windshield but not the reste of the car.

GN can be quite complex, managing a big amount of objects / instances / geometry sources / curves / point clouds, and it’s very manageable, pretty clear and easy to manage.

Besides remember that the node tree is per light, so we are talking from a light to object perspective here, in the end it’s pretty similar to what other packages do, but node based.

Also if you want to manage big amount of lights as one nothing stops the system to have an aggregator to manage that “group” of lights in conjunction instead of using the light node tree.

Nodes can be quite flexible :)

In T68915#1367677, @Juan Gea (juang3d) wrote:

In T68915#1367665, @Robert Rioux (riouxr) wrote:

IMHO the UI for light linking should be represented in Nodes

That could be a complete mess for complex jobs. How would you handle parented objects? Like I want the light linked only on the windshield but not the reste of the car.

GN can be quite complex, managing a big amount of objects / instances / geometry sources / curves / point clouds, and it’s very manageable, pretty clear and easy to manage.

Besides remember that the node tree is per light, so we are talking from a light to object perspective here, in the end it’s pretty similar to what other packages do, but node based.

Also if you want to manage big amount of lights as one nothing stops the system to have an aggregator to manage that “group” of lights in conjunction instead of using the light node tree.

Nodes can be quite flexible :)

Really good explanation, I agree with that.

Moreover, nothing prevents to extend it later to object to light perpespective (if usefull)

Just wanted to throw in that as long as the low-level implementation allows one to express all the needed lighting relationships, and it has a good Python API interface, then it should be possible to write add-ons that allow creation and display of the information in whatever way the add-on implementer(s) think best. I would thus suggest focusing at first on the low-level functionality and get that implementation out there with a minimal UI (or even no UI) and let people experiment and find out what works well, rather than feeling like you need to invent the perfect UI which will be all things to all users from the beginning.

OOOh, I didn't expect so many replies overnight, thank you to everyone who cared about this dev thread. BTW, sry, I'm not familiar with the rules here, I'm sure the maya screenshots have been deleted.
Maybe we can look at K-CYCLES and E-CYCYLES, which completed the development of the light link earlier and implemented it as UI.
Seriously, I was really surprised to see the 'light groups' appear as node, which undoubtedly made it difficult for ordinary users to understand. Of course, it does not include those who are good at using nodes.
Maybe "everything nodes" encourage people to explore nodes, but it's getting extreme. Yes, I mean 'light groups' is catastrophic, hate to say that but it definitely add time cost, when a new blender user is using these basic functions, they’ll check the UI for the first time, definitely not the nodes, many people will dread including me when blender becomes a ‘pure node editor’.
The software must be user friendly, right?

In T68915#1367828, @Neo_Hoa (NEEO) wrote:

Maybe we can look at K-CYCLES and E-CYCYLES, which completed the development of the light link earlier and implemented it as UI.

I would suggest to mainly look at E-Cycles because K-Cycles light linking is more like a post processed/composited effect(Once path tracing is done only then it shows the result) whereas E-cycles seems to have light linking that the path tracer acknowledges as it is rendering however the UI of E-cycles is not exactly user friendly.

In T68915#1367970, @Yuneth Alwis (Alwis2000) wrote:

In T68915#1367828, @Neo_Hoa (NEEO) wrote:

Maybe we can look at K-CYCLES and E-CYCYLES, which completed the development of the light link earlier and implemented it as UI.

I would suggest to mainly look at E-Cycles because K-Cycles light linking is more like a post processed/composited effect(Once path tracing is done only then it shows the result) whereas E-cycles seems to have light linking that the path tracer acknowledges as it is rendering however the UI of E-cycles is not exactly user friendly.

Thanks for the info, they're actually pretty bad UI look, feel and logic, but they're the only Cycles mod that includes Light Links right now, even though I had to pay for it.
P.S. maya light links UI is the best design so far, there is no shame in borrowing from it.

GN is great, It gives more room for free creation on a low level basis, but some work that relies on UI to be done quickly and intuitively, they just shouldn't all become nodes, it's unwise to add unnecessary complexity to the actual work just for the slogan 'everything nodes'.
Please don't make blender more and more like a coder tool, it should be an artist's brush.
Maybe I'm too used to the rules of maya and c4d, but time will tell.

In T68915#1367828, @Neo_Hoa (NEEO) wrote:

Maybe "everything nodes" encourage people to explore nodes, but it's getting extreme.

I could not agree with this more. PLEASE don't over complicate this! A simple INCLUDE/EXCLUDE list with an object picker is all we need.

Want to include entire Collections? Great, just put everything in the same collection. Project can be as simple or complicated as you want to get... without the need for an excessive interface.

Why not start small and work up. If you want to keep it simple for now and avoid having light linking scattered all over the interface, why not just make it part of the object properties like in LightWave (image attached).

Then people could just right-click on the object from Blender's Outliner to bring up a panel that lets you check or uncheck the light that you'd like to exclude.{F13165291} (As I add more lights, they populate the list and it's per-object).

I'm sure, at this point, people would like to have any form of light linking -- even a rudimentary one.

In T68915#1374747, @Nebulous (Nebulon1212) wrote:

Why not start small and work up. If you want to keep it simple for now and avoid having light linking scattered all over the interface, why not just make it part of the object properties like in LightWave (image attached).

Then people could just right-click on the object from Blender's Outliner to bring up a panel that lets you check or uncheck the light that you'd like to exclude.{F13165291} (As I add more lights, they populate the list and it's per-object).

I'm sure, at this point, people would like to have any form of light linking -- even a rudimentary one.

I don't think it's smart, when there're too many lights and objects, it will definitely increase the amount of mouse clicks, imagine you have to click on each light or object's property, this may be hundreds of times mouse repeat operation! We just need to add a double list to the render bar, simple, easy and clear, that's all, this is the best way to handle it till this moment.
idea made by someone, just don't do this👇🏼

What does “add a double list to the render bar” mean? What is the render bar?

If the image in your comment is to illustrate what you mean then yes, that is 100% the way to do it. An include/exclude list in the Light properties. This really would be a game changer.

Sorry, I mean we can add a double list called ‘light linking’ with drop-down in the 'render properties' bar, most of the rendering functions are here, it's also UI logical.

I don’t see how putting it in the render properties makes sense. You nailed in that second image above, stick an include/exclude list under Light Linking in the Light properties. Simple and powerful.

This feature is a must for an advanced rendering engine.

In T68915#1374800, @Neo_Hoa (NEEO) wrote:

In T68915#1374747, @Nebulous (Nebulon1212) wrote:

Why not start small and work up. If you want to keep it simple for now and avoid having light linking scattered all over the interface, why not just make it part of the object properties like in LightWave (image attached).

Then people could just right-click on the object from Blender's Outliner to bring up a panel that lets you check or uncheck the light that you'd like to exclude.{F13165291} (As I add more lights, they populate the list and it's per-object).

I'm sure, at this point, people would like to have any form of light linking -- even a rudimentary one.

I don't think it's smart, when there're too many lights and objects, it will definitely increase the amount of mouse clicks, imagine you have to click on each light or object's property, this may be hundreds of times mouse repeat operation! We just need to add a double list to the render bar, simple, easy and clear, that's all, this is the best way to handle it till this moment.
idea made by someone, just don't do this👇🏼

this is right.

In T68915#1374813, @Ryan Rickett (glencandle) wrote:

I don’t see how putting it in the render properties makes sense. You nailed in that second image above, stick an include/exclude list under Light Linking in the Light properties. Simple and powerful.

The meaning I can centrally manage light links here without click properties for each light, it clearly lists exclude and include options, includes all objects and lights in the scene, all operations here, maximize reduction mouse click and makes life easy.

If you have seen maya light linking UI you'll understand that this is a very clever design.

In T68915#1374927, @Neo_Hoa (NEEO) wrote:

The meaning I can centrally manage light links here without click properties for each light, it clearly lists exclude and include options, includes all objects and lights in the scene, all operations here, maximize reduction mouse click and makes life easy.

In my opinion this still makes the process over complicated, especially for smaller scale projects, VFX/motion graphics/etc. How many times do you have hundreds of lights in a scene!? I think it is much more common to have only a few lights.

Anecdotally: Imagine you have your scene molded and you start placing your lights. It would be a huge benefit to be able to tweak the light settings (type of light, intensity, color, etc) and include/exclude objects to illuminate, all in one interface, without having to click away. This is a lot easier than your proposed method.

Your solution is very Maya, I will grant you that, but then again Maya is an over-complicated team sport (which is I why I stopped using it) and Blender is better suited for individual artists; so let's just please focus on simplicity.

We can always start here and add a central Light Linking tab later, no?

In T68915#1375094, @Ryan Rickett (glencandle) wrote:

In T68915#1374927, @Neo_Hoa (NEEO) wrote:

The meaning I can centrally manage light links here without click properties for each light, it clearly lists exclude and include options, includes all objects and lights in the scene, all operations here, maximize reduction mouse click and makes life easy.

In my opinion this still makes the process over complicated, especially for smaller scale projects, VFX/motion graphics/etc. How many times do you have hundreds of lights in a scene!? I think it is much more common to have only a few lights.

Anecdotally: Imagine you have your scene molded and you start placing your lights. It would be a huge benefit to be able to tweak the light settings (type of light, intensity, color, etc) and include/exclude objects to illuminate, all in one interface, without having to click away. This is a lot easier than your proposed method.

Your solution is very Maya, I will grant you that, but then again Maya is an over-complicated team sport (which is I why I stopped using it) and Blender is better suited for individual artists; so let's just please focus on simplicity.

We can always start here and add a central Light Linking tab later, no?

I have to take this idea with a grain of salt, I just created a medium scale scene that uses 16 lights and you never know how many lights for your next project.
The e-cycles light link makes the mouse run fast and I have to click repeatedly the LL ID of each light and object to make sure it's correct, which is a nightmare as a maya user. (I'm not a fan of maya, but it has advantages)
In any case, I firmly believe that unified operation in a panel without switching is the fastest.
BTW, it looks like the developers have their own ideas and timelines, until then we'll just have to wait or use a 3rd party solution, just hope it won't be another 3 years.

Any temporary solutions has a problem of crating legacy that is always hard to enhance and maintain.

Any solution with no single access point (like per light setup) has a problem of a setup readability, so it is fast to create, but hard to tweak/edit. The complexity of such a setup grows accordingly to lights count, and is especially critical during collaboration.

The way E-Cycles uses Light Linking is the worst way I have ever seen in a 3D App.
We all have to make sure to not end up with a rubbish solution like E-Cycles is using / offering.
Otherwise you'll be in bad dudu with heavy scenes. Or can you remember what kinda light 3, 11, 45, 47, 89 is !?

Also it's really time to start light linking development, otherwise it will take significant longer to become industry standard .... (not to talk about industry standard keymap.....)

Yes, it was discussed that dynamic context management system paradign doesnot fit light linking, since names are important there, so context of this system should be static (name-based).

Also it is important to prevent "feature hunger" - a wish for having a desired feature at any cost bypassing proper design, that includes taking into account not only the possibility of fast creating setups, but convenient handling already created setups (proper data management).

In T68915#1385946, @Guido (Nurb2Kea) wrote:

The way E-Cycles uses Light Linking is the worst way I have ever seen in a 3D App.
We all have to make sure to not end up with a rubbish solution like E-Cycles is using / offering.
Otherwise you'll be in bad dudu with heavy scenes. Or can you remember what kinda light 3, 11, 45, 47, 89 is !?

Also it's really time to start light linking development, otherwise it will take significant longer to become industry standard .... (not to talk about industry standard keymap.....)

yeah, I'm avoiding B3D in large projects just because of the lack of light linking.

Just want to chip in here to say that it'd be really useful to be able to be more specific about how the light behaves with certain objects rather than just a blanket "this object is affected by this light" - for eg whether a specific object will occlude a light, whether the object can receive direct illumination or only indirect etc.

I think maybe there's some over-thinking going on here.

The example from LightWave is simple and it works. Speaking as someone who has worked in the trenches and used to be part of the film union, I can tell you that a typical case for light-linking is not as complicated as some might think it is.

Usually, you just need to exclude a wall from the light solution. The approach of unchecking the offending light from the object's properties panel is the correct approach.

Starting from the light properties and unchecking objects is a backwards approach.

Keep in mind that the majority of the features in LightWave were direct requests from Hollywood studios for getting the job done efficiently, and yes -- that includes Digital Domain.

An additional note: The above assumes people want to keep certain lights from casting onto specific objects. It doesn't address cases where you want a light to pass through an object while shadows are enabled. That point is addressed in my later comment. Just thought I'd mention that in case some users are looking to light linking as a way to take care of the latter as well.

In T68915#1422004, @Nebulous (Nebulon1212) wrote:

I think maybe there's some over-thinking going on here.

The example from LightWave is simple and it works. Speaking as someone who has worked in the trenches and used to be part of the film union, I can tell you that a typical case for light-linking is not as complicated as some might think it is.

Usually, you just need to exclude a wall from the light solution. The approach of unchecking the offending light from the object's properties panel is the correct approach.

Starting from the light properties and unchecking objects is a backwards approach.

Keep in mind that the majority of the features in LightWave were direct requests from Hollywood studios for getting the job done efficiently, and yes -- that includes Digital Domain.

How to select all the walls that has a specific light excluded in a scene you has got from someone that was previous in production pipeline?

In my humble opinion, I think that Blender already has a good system for managing objects by collections, I think that it should follow the same functionality as the rest of Blender, and not make a specific interface.
Simply add a checkbox in the light properties: "Only collection". And managing one or a thousand lights is simple, "ALT+MouseCLick" activates the option on all selected lights.
For handling collections "M" or "SHIT+M" and generate or add to the collection with all lights selected and objects selected, and affecting sub-collections of objects.
Independently, each light can have its tree of nodes of how the light will react on the objects it illuminates.
If then you want to generate a specific section in the outliner, such as "Library Overrides", with specific functions, that is already separate, or even add some type of icon in the Collection Outliner such as "Indirect Only".
The collection system and Outliner already have their own object and collection search and management system for the problems you are raising.
I think it would be the most intuitive and correct.

Taking into account the feedback above regarding collections and the possibility that someone might actually want to exclude a thousand lights from casting onto an object, perhaps the following as a rough mock-up of what I'm thinking of...

For the collection that's checked, all lights within that collection would no longer cast onto the selected object.

I.e.:

• Select the object in Outliner
• Click on Object Data Properties
• Expand [Light Linking]
• Check items that you don't want casting light onto that particular object.

With any luck, it would be a feature that would work in both Eevee and Cycles.

The above would take care of keeping checked lights from hitting a specific object. However, for the case where you want a light to pass through an object (like a lightbulb) and still cast shadows onto another object (tell the light inside the bulb object to ignore the lightbulb object so that the lightbulb doesn't block the light)...

That would mean you'd be looking at a second panel (one in Light Properties this time) that would provide the option to exclude objects(s).

In LW3D it looks like this (two panels):
{F13568621}

And in Maya it looks like this (Object-Centric and Light-Centric):
{F13565667}

{F13565668}

Two approaches to the same thing.

A good explanation of both scenarios in Maya is outlined in this quick video:
https://www.youtube.com/watch?v=4NG6bOM5QTc

That interface encompasses certain solutions to a panel dedicated to light linking. However, I think that following the Blender philosophy, that panel should be in the Outliner editor, in an extra section.
The ideal would be to be able to make a quick and easy configuration, let's see the case of LineArt: you can limit by scene, object or collections. Then in the LineArt object you have the complete configuration. Finally a dedicated panel in object properties, on those objects that can support LineArt, to access complex settings per object.
This way of working is fast and versatile, you only configure what is necessary without navigating through lists and panels, in addition to being able to support multi-object configuration (although currently the LineArt object panel does not yet support multi-object configuration, XD ).
You can translate all of this into light linking, and then, if you like, a dedicated editor complete with lists for lights and objects in the Outliner editor, like "Orphan data" or "Library override".

Object to Light linking is the number one thing I miss coming from Maya! (Well, besides viewport move undo). I spent a lot of time in the light linking dialog in Maya. It is great, it works, it's simple and direct! I would really like to see this in Blender. But not based on collections. Make it independent and directly down to the mesh, no matter in which collection the mesh is.

Hi guys, little disclaimer,

As far as I know, screenshots from other software are not allowed here. So pls be carefull, and delete them.
If you want to illustrate it, pls dis a mockup or code it directly in python. That will be more usefull than a simple image :)

Hi! Just wanted to say that having the ability to tell an object to only see a particular light (not by creating render passes) is an extremely powerful tool for me, particularly in commercial workflow, where I do not have time to export and comp multiple passes when I have clients sitting the meeting room waiting for a render. I.e. That rim light needs to hit the that one object, but nothing else. Should be simple (for the user ha). I shouldn't have to set up a a fake shader/normals solution either. (Additionally, having the ability to tell an object that its shadows should be darker was also very helpful, not just that it has or doesn't have them)

Thanks.

As far as I know, screenshots from other software are not allowed here.

May I ask why? Imho that’s ridiculous, besides any legal reason to do so.

In T68915#1437565, @Alex Furer (alFrame) wrote:

As far as I know, screenshots from other software are not allowed here.

May I ask why? Imho that’s ridiculous, besides any legal reason to do so.

It is not a matter of opinion, please just respect the rules.
This has been requested to no end, and yet from time to time it comes up again.
There is a full Blender Artists thread about it, and even an official video from Pablo Vasquez explaining why.

So yeah. Legal issue. Completely understand. Thanks!

I can’t count how many times this has become a major issue that has required composing tricks to fix. It’s the only thing that really makes me consider trying another program. It really seems like something so fundamental, and I was shocked when I realized it wasn’t something I could just solve in the shader editor or by using collections.

As someone who probably can’t contribute to anything by way of code, is there something I can do to help with this project through testing, debugging, or anything else?

I thought about a way to do this. A new mode (like edit, object, sculpt etc) called light linking. First step is to turn on light linking on the light itself to tell it that it won't light everything by default. Then you choose a color that would represent it. When you switch to light linking mode, everything is grey shaded. The light icon will take the color that was previously chosen. From there, you can select object directly in the viewport to create the link. You could also do it from the outliner, with collections too. I think it's a very visual way of seeing light linking and to my knowledge no other 3D software is using that method. So no need to deal with lists and stuff. It becomes complicated if you have too many links. You can't put that many colored squares in the outliner but maybe there could be a + sign (like when you have many objects) and when hovering over it, it could show all the colors. This would work only one light at a time though as you could only display one color at a time the light linking mode.

[EDIT]: I forgot to add the torus on the top image. It should be there and white

In T68915#1445736, @Robert Rioux (riouxr) wrote:

I thought about a way to do this. A new mode (like edit, object, sculpt etc) called light linking. First step is to turn on light linking on the light itself to tell it that it won't light everything by default. Then you choose a color that would represent it. When you switch to light linking mode, everything is grey shaded. The light icon will take the color that was previously chosen. From there, you can select object directly in the viewport to create the link. You could also do it from the outliner, with collections too. I think it's a very visual way of seeing light linking and to my knowledge no other 3D software is using that method. So no need to deal with lists and stuff. It becomes complicated if you have too many links. You can't put that many colored squares in the outliner but maybe there could be a + sign (like when you have many objects) and when hovering over it, it could show all the colors. This would work only one light at a time though as you could only display one color at a time the light linking mode.

[EDIT]: I forgot to add the torus on the top image. It should be there and white

This is cluttering up the outline very quick as you said.
I guess we need a list editor window (similar to the outliner). All the scene stuff in this list by default is illuminated and color marked as illuminated .
So you can select a light / emmisive in this List editor.
The stuff that should not get illuminated you can unmark by click in this list. This list can be shown/sorted by illuminated or not illuminated scene stuff.
This way we are open (have the ground stone) to more advanced lighting scenarios LATER in blender development. (interaction with other lights, reflection, refraction, etc)

Same as we know from other software.
And this is nothing we would implement for the industry, but for every user, for example want to backlit it's logo/mesh/volume ....
This is no copying. We have so many things in blender that is done the same way as in other software. Or did we find another way to save a file !? I don't think so.
And finding another way just for blender means making it more complicated for what reason...???

ps: we don't need many different charging cables for EVERY phone on the market!!!

Hi! This is a proposal on the Light Linking and Light Panel reestructure.

1- The "Light Panel" shouldn't always require having a selected light for it to appear. It's always there and you can select the light you're working on from a dropdown list.

2- "Sync by Selection" can be on or off, so if it's on it would always show the last selected light (with the clear indication you're working on that specific light).

3- This Panel doubles down as a "Light Linking" panel. It works directly with the outliner + with selections (the easier workflow).

4- On the Outliner you can have a "Light Linking Mode" (Lamp icon?), that syncs the light you're currently working on with the "Light Toggles Interface" that is added to the outliner.
This would give you clickable toggles for "on and off" on Collections and objects. Same principle to the current visibility. Option to override by object if they differ from the collection selection on the menu.

5- Since this is an "activatable (?)" mode you could have an Outliner open just for Light Linking on while still working on the outliner with it turned off. This would make use of the panels that already exist and are familiar without cluttering the interface. Options to work from the "Object or Collection Perspective". Meaning the lights in the scene are automatically added to their dropdowns (you could see which lights affect the object and toggle those on and off from there too).

On my workflow this could work, but there are more to be studied. Hope you like it!

I just found this out. k-Cycles nailed it. All I could wish for and more.

https://www.youtube.com/watch?v=M-MZ3sMtE5A&t=565s

In T68915#1453057, @Robert Rioux (riouxr) wrote:

I just found this out. k-Cycles nailed it. All I could wish for and more.

https://www.youtube.com/watch?v=M-MZ3sMtE5A&t=565s

What a shame he is not contributing to this...

In T68915#1453057, @Robert Rioux (riouxr) wrote:

I just found this out. k-Cycles nailed it. All I could wish for and more.

https://www.youtube.com/watch?v=M-MZ3sMtE5A&t=565s

Doy you mean light groups or light linking?

Both! :-) Fast, easy to use, fully featured.

In T68915#1453361, @Robert Rioux (riouxr) wrote:

Both! :-) Fast, easy to use, fully featured.

Indeed, looks promising. There are two possible issues that came into mind:

• there is no selection buttons yet. You can create subset of data but cant select it - without selection ability such a system will be "easy to set but hard to edit" one.

• Light groups are supposed to be non-cumulative, while light linking are supposed to be cumulative (allow same objects in different sets). I may mistake but I am not sure light linking based on light groups are fully featured.

Anyway, indeed an interesting concept.

Good points. What's stopping us from using it is the use of an external render farm. So we badly need a local solution. I saw on Twitter that k-cycles is supposed to release the code because of the GPL license but refuses to do so. Would have been interesting to take a peek at it. But that's for another discussion somewhere else.