Light linking #68915
Labels
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 project
No Assignees
160 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#68915
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Support to have a light to influence only a few objects.
This would be implemented by having a collection per light, where only the objects in the collection are illuminated by that light. This is compatible for example with light linking in USD.
On top of this basic data structure there a more convenient UI can be implemented, for example to automatically created a light linking collection from selected objects or selected collection, to view and edit the relation from the object -> light point of view instead of light -> object, etc.
There was an initial implementation in D1985, but it is no longer used in production. This implementation was geared towards branched path tracing and sample all lights. A newer implemented was being worked on in D11636, however it is in very early stages.
An acceptable implementation should build its own light CDF or tree per light collection, otherwise importance sampling will be very poor with path tracing and many light scenarios.
Added subscriber: @dfelinto
Light groupto Light groupsAdded subscriber: @AntonioNavarroBlaya
Removed subscriber: @AntonioNavarroBlaya
Added subscriber: @GavinScott
Isn't this more commonly referred to as Light Linking in other applications? That is, the ability to associate lights with specific objects to illuminate? Light Groups are also a thing in some applications (Revit as one example) but AFAIK this refers simply to grouping multiple lights together in order to affect them as a combined set. Applications that support Light Linking generally let you associate either individual lights or groups of lights with one or more objects to illuminate.
Also for reference here's the one outstanding diff for Light Linking I could find which I believe is one of Tangent Animation's early mods that they submitted a few years ago: https://developer.blender.org/D1985
Added subscriber: @AlbertoVelazquez
Added subscriber: @lemenicier_julien
Added subscriber: @frameshift
I believe we're mixing terms here? I've used the concept of light groups in Arnold in the past, as (I think) a precursor of custom AOVs, where the lights' influence gets output to a separate render pass per group. In which case this seems better covered by D4837.
@dfelinto 's task description is closer to what @GavinScott writes:
Added subscriber: @1D_Inc
There are a lot of representations in industry, that can be called Light Groups, like
I think the Light Groups concept term in Blender is not defined yet.
It can contain actually both Grouping Lights process and working with Lighting Groups process, interconnecting them in the most positive way.
This is good, because this allow to design a proper, solid workflow solution, based on production demands, and include the experience of ready-made solutions.
Light Groups in Blender is a workflow design task to do.
Light groupsto Light linkingAdded subscriber: @brecht
This task is about light linking. This feature in Blender Internal was called light groups, but we wouldn't call it that anymore. Per light AOVs are unrelated to this task.
Added subscriber: @SteffenD
Added subscriber: @GottfriedHofmann
Added subscriber: @FinbarrORiordan
Added subscriber: @Memento
Added subscriber: @JulianPerez
Added subscriber: @Dogway
Added subscriber: @c2ba
Added subscriber: @AditiaA.Pratama
Added subscriber: @Lincoln
Thanks for the clarification!
Added subscriber: @Thiagodesul
Added subscriber: @NizarAmous
Added subscriber: @cschumann
Added subscriber: @3di
can we have this as two additional outputs on the light path node too? A object ID and a material ID output, which return the material/object ID the ray is currently hitting.
This would enable us to have different environment for certain objects based on their object id or material id. For example if you look at the image below of the world shader editor, i'm setting the envinronment to be the hdri for all objects except objects that have a material ID greater than 4, which instead reflect, get lit by, and refract a solid green colour.
It would also mean we could specify in the object shader editor, which materials are visible to other objects/shaders too (by using the object output into a mix shader which has the main material and a transparent bsdf connected to it, and the light path into the factor)
Added subscriber: @PawelSwierczynski
Added subscriber: @ephelion
Added subscriber: @moisessalvador
Any progress on this? It would be great to have, I neede this in production a month ago.
^This would be fantastic as well
Removed subscriber: @moisessalvador
Added subscriber: @Pewi
As a long time 3dsmax user (since 1997) but now a loyal Blender user, this is a must-have feature. In 3dsmax this feature has always existed in lights.
This is how the workflow looks in Max:
This same workflow works for most lights in max using most renderers.
In Blender, I think could be done using light nodes.
I'm not a coder. I'm just requesting a feature that is very necessary to give the user full control over lights in most scene situations.
Very best regards to all,
Jonas, Stockholm, Sweden
Added subscriber: @GatisKurzemnieks
How is this not a high priority task? This is absolutely essential for serious lighting work!
It would make things much easier :)
Added subscriber: @pawel.palenica
Added subscriber: @PierreSchiller
Any updates on "light groups"? I guess in the end they will be called "light collections". Which serve as a "box" to put data (objects) in it, and get lit.
Collections and their elements do exist organized at RNA level in Blender, currenty.
The only turn around, would be : "Hey user, now since you always work within a collection, all the objects inside that collection will contain their own light sources. You can't -any longer- just put random bunch of lights everywhere. They need to be inside a collection. 3 collection with different objects? 3 different individual lights inside the collections!"
The workflow is already there, we just have to organize the new mentality to: collection = restriction of light.
You need to make a custom pass based on different lights in different collection? = use AOVs properties at shader level. Complex, yes, but doable.
Edgy.
"And also have instances of cumulative collections in scenes created by someone else, so deal with it somehow, no matter how much deadlineous it is now.
No more "Lights" and "Cameras" collections, parse entire scene to figure out how lights are distributed, learn python for that purposes already."
Added subscriber: @ndeebook
Completely agree. It could even be mentioned in the roadmap. This alone makes me walk away from Blender for any serious production work.
There are many problems that make us leave Blender for any serious production work, and most of them were added recently.
The difference between production and development - there are no "scopes"in development to prioritize.
Features must be added properly, otherwise they reduce the potential of the program.
Added subscriber: @lsscpp
You already have them in Object info node
Added subscriber: @BeckersC
Added subscriber: @FelipeDelRio
Added subscriber: @filiperino
Added subscriber: @DiegoCortes
Anything new? This should be a high priority task, as it is essential to further improve the lighting workflow :(
Added subscriber: @HammadAsif
Added subscriber: @mortom_ckm
@lsscpp wrote:
Yes, but they doesn't work with lights :(
Any one know anything about how works going on this subject?
This comment was removed by @mortom_ckm
Added subscriber: @renderluz-2
I agree, I was looking for a way to do this and had hoped this was already implemented as thought it to be a core functionality, specially for NPR, sometimes you want place a light on a non photo realistic place for artistic purposes but it's reflected on other objects that you dont wish to affect, not being able to selective exclude those objects from being affected by the light really reduce creative freedom when it comes to lighting a scene.
Added subscriber: @astroblitz
Added subscriber: @Kobar
Added subscriber: @wenna666
Any progress updates? it's really a important feature.
Added subscriber: @stmalk
Any updates so far? Anything for next iteration of 2.9? That is a must in a lot of archviz production, highly needed feature to exclude objects from light source.
thats my wish for christmas :)
Added subscriber: @AdamJanz
Added subscriber: @yassyboy
Added subscriber: @taroumaso
Added subscriber: @Avion
Hey there,
i am working now on my 8th medium sized production project this year and every single time i encounter this issue ;)
I want to light a scene, place support lights and have to manually build invisible blockers for lights so that they don't spill into my scene.
I also come from a 3dsMax workflow. I really really miss this.
I am now compositing the lights and reflections out or build said light blockers among many workarounds.
But the time alone it consumes ....
PLEASE vote this up on the roadmap for the next release.
@Avion There was a branch of Blender back in 2016 by Tangent Animation on Github that has this feature for Cycles. They used light linking in a production environment to light feature film shots, and indeed, it is a necessary function to add detail lighting without having those lights reflecting on unwanted surfaces. Currently, one must separate their scene into multiple render passes to achieve this which is unwieldy for many objects that require detail lighting. Unfortunately, the branch was from the 2.78 era. Really looking forward to this feature coming to Blender 2.9+ soon. Even having this feature for Eevee would be a huge plus, and would bring back that incredibly useful feature lost with Blender Internal renderer. You can vote on the feature here: https://blender.community/c/rightclickselect/5mfbbc/
Added subscriber: @Zeirus
@AdamJanz YESSSS, voted of course.
This feature is currently super high on my personal wish-list.
Removed subscriber: @AlbertoVelazquez
Yes, this should also help better with performance since separating everything in render layers or multiple renders just to render the SAME geometry is an overkill https://devtalk.blender.org/t/why-is-bvh-built-for-each-renderlayer/14670
I too encounter issues in production due to this missing feature. Listen to your professional users
I don't know why it's not a top priority feature for Blender...
please make it high priority, is it really hard to implement?
This is a very important feature. In my case, the lack of it stops me from switching to Blender at work. Hopefully we'll find out soon when to expect light linking in a blender.
Added subscriber: @danilo.dias
E-Cycles has a feature called light groups, but I think this more or less controls the ability to adjust isolated lights after a render, rather than having isolating lights affect only certain objects (which is what Blender Internal could do). However, I have not used E-Cycles before, so others would know better on this. I think the idea of light-linking received pushback from the devs initially because it was deemed a non-realistic technique and Cycles is a realistic path tracer. Nevertheless, the concept of light-linking is the only economical way I can see of providing specific accent lighting to a large quantity of isolated objects without using a massive amount of render passes. For example, for my current architectural project, I am lighting kitchen cabinet hardware independently and then rendering it in its own render pass, to avoid unwanted reflections of these lights in the cabinets themselves. This works okay for this scenario, where repetitive objects all can share the same render layer, albeit at the cost of extra render time. But if more passes were needed, the process would become very tedious very quickly.
Added subscribers: @Stefan_Werner, @LukasStockner, @scorpion81, @juang3d
Light groups are present already in Cycles, just not in master, the light groups original patch was from @LukasStockner (https://developer.blender.org/D3607) , I added it to our build, BoneMaster, and it can be downloaded by anyone from graphicall.org, so you can test it if you want.
We also implemented several Cycles optimisations and accelerations too, in general they are patches developed by @LukasStockner and @Stefan_Werner , we also feature a new Voxel Mesher modifier, currently not available in 2.91 (need refactor), but available in 2.90 and 2.83, developed by the magician @scorpion81
2.91
https://blender.community/c/graphicall/Mlbbbc/
2.90:
https://blender.community/c/graphicall/Bpbbbc/
2.83 LTS:
https://blender.community/c/graphicall/kdbbbc/
But lightgroups it's not light linking, you cannot avoid the shadow casted by a light for example and such things, those are different features.
@juang3d Thanks Juan for that info! That sounds like great additions; I will have to try those builds out. I'm sure the talented devs will find a way to implement light linking as well in time. So many great features being added to Blender these days- it's hard to keep up with them all! :-)
Added subscriber: @Grady
For the benefit of anyone thinking of tackling this problem, could anyone with more knowledge on how lights in cycles and eevee currently work offer any suggestions on what would be the starting point for implementing this on a technical level?
The starting point would be the existing patch in D1985, rebasing it, and addressing my comments regarding how this implementation is inefficient. In particular, there should be multiple light distributions created to work efficiently with cases other than branched path tracing, and it needs to be ensured that BVH traversal performance is not impacted much.
Added subscriber: @dreamparacite
Added subscriber: @APEC
Added subscriber: @Slowwkidd
Added subscriber: @Ekiwnox
Hope this feature will come soon in the main build of blender. It's so important for so many cases : Products images, architectures etc... This is just a must.
Added subscriber: @Pipeliner
Added subscriber: @Frederic-Cervini
Added subscriber: @JanErik
it would be really nice if there would be new progress on this topic :)
new years wish! light linking bring blender to next level!
My new years wish too! light linking is very important please!! :D
Added subscriber: @JohannesLubke
Added subscriber: @TimBL
Added subscriber: @VKey
Most anticipated feature atm for me. Volumes & stuff are nice to have but this is a must have. Thank you for your hard work Blender Team!
Yes, I've just run into this issue again, where accent area lights placed along the length of a client's product are erasing the key light's shadow. Without light linking in EEVEE, one must use short custom distances on the accent lights so they cannot affect the key light's shadow. However, that is a poor workaround since it weakens the lights too much. It's extremely necessary to be able to isolate the influence of your accent lights for commercial product visualization. Thanks to the talented Blender devs for investigating a solution to this much needed feature!
Added subscriber: @nacho.diaz
Added subscriber: @Cyberduck
Added subscriber: @Tasch
Added subscriber: @ayberko
Added subscriber: @MicheleFaccoli
I so need this feature to be able to even consider switching to blender.. Without it most of my product shots would be just too time consuming to do.
This is a must have thing. I signed up to just give a token to this feature. That's all I'm going to say:D
Added subscriber: @monkriss
This feature, above all, is the most important. Its one of the most used tools in 3DS (vray, corona, fstorm...) when trying to find the perfect lighting solution.
It would be good to make sure there is an INCLUDE and EXCLUDE option if you just want the light to influence only one object, or not that one object
Added subscriber: @pacobg
Added subscriber: @lucamonzon
I can't move my workflow to blender without this feature :/
Removed subscriber: @dreamparacite
Removed subscriber: @Slowwkidd
Added subscriber: @sid350
Added subscriber: @jinyicool
I can't move my workflow to blender without this feature
✅ Maya
✅ 3dsMax
✅ Cinema4D
✅ Houdini
✅ Modo
❌ Blender
:S
Added subscriber: @bdu
Added subscriber: @jimix85
Added subscriber: @Rockbard
Blender is almost perfect. But that's an absolutely essential thing to have in any software.
+1 For this awesome feature. Thank you, developers! You guys are the best.
Added subscriber: @msamilg-3
This is an absolute must-have. Really hoping we will get this in 3.0. Please, make it real, dear Blender devs :)
Added subscriber: @N005
Added subscriber: @Stinaus
Added subscriber: @MichelePoletto
I also switched to Blender from 3ds Max (Vray and Corona). Blender is a thousand times better on many aspects but this feature is a lack that is felt a lot in the product rendering and ArchViz.
I also look forward to this integration.
Thanks guys for the great job you are doing.
Yes, Blender has lots of outstanding design solutions.
This feature is heavily workflow-dependent, I think that's why BF is hiring a Rendering Software Engineer as well.
Added subscriber: @JuanOlivares
This would be so great to have
Added subscriber: @mlrodrig
Added subscriber: @marioamb
Added subscriber: @GabrielMoro
Added subscriber: @DylanLobbregt
Added subscriber: @Vasiliy
This feature is sorely lacking
Added subscriber: @piledog
Can we expect light linking for Blender 3.0? it's really a important feature.
or this GSOC proposal is the only hope? https://devtalk.blender.org/t/gsoc-2021-proposal-idea-light-linker-light-mixer/18185/14
Added subscriber: @dresban
Added subscriber: @rsgnz
Added subscriber: @lightlinker
Coming from Maya this was a shocker Blender didn't have. I signed up here for the sole purpose of loving this ticket!
Added subscriber: @Justus
Added subscriber: @AndyBCX
Added subscriber: @FrancoisRoussel-3
I'd suggest something slightly different from the OP. Rather than lock the lights to the collections they are in, I'd add a string to group items "virtually" (as in modo GROUPs, which are not the folders you place item into aka bleder collections, but a group you create virtually just to allow some specific things to happen on them. And lights should be allowed to INCLUDE those items, so you only light those, or EXCLUDE them, and light everything else. Allowing also to split between Direct, Specular and Reflection Rays, because for total control over the product lighting you might want to have certain rays affecting the model while hiding others.
You mean something like applying tags to objects? Tags that lights can use to EXCLUDE or INCLUDE ONLY?
Yeah, a tag could work. I use this to split lighting on different items within the same scene for product shots. I have an entire lighting set dedicated to a mesh, and another lighting set for another mesh, and they dont conflict with one another. (vray for modo)
@MicheleFaccoli That is pretty much how Blender Internal Renderer (2.79b) used to work. It had the ability to BOTH limit light influence at the material level (by adding lights to a Light Group, then selecting that Group for your desired materials), AND limit lighting at the layer (collection) level (to only affect objects in the same collection as the light). Both ways are incredibly useful. I think adding lights to a Light Group (Collection), and having an option on objects (or materials!) to restrict lighting to that Light Group (similar to Blender Internal) would be great. However, there should also be an option when you right-click on a collection of objects to "Limit Lighting to -> (Light Group of your choice)". That way you have both per-object and per-collection light control. To avoid conflicts, any Light Group specified at the object (or material) level would override any Light Group specified at the collection level (this is also the override behavior Blender Internal used). :-)
Sure.
It is implicit way, therefore, hard to manage (hundreds collections with different setups, and you will never met a deadline).
Complete system design is about management design as well.
Any time you have hundreds of collections there will likely be management issues. Of course, I am open to any design that allows a user to manage their Light Groups most efficiently. If there is an existing 3D application that does an extremely good job at this (better than the technique we had in Blender Internal), perhaps the design should be looked at and copied. However, I would say that having ANY form of light groups is better than having none at all. :-)
Collections were originally presented as an "infinite entity system", which is in line with the Common Layer paradigm found in most programs.
It would be strange to get a management system that works for about... twenty-two collections.
There are a lot of such applications, however, they are usually not taken into account.
In Autocad we are using thousands layers per file. It have massive spreadsheets dedeicated to layers, a separate UNDO engine for layers management and requires a lot of scripting to maintain.
The Common Layers paradigm requires addressing severe design constraints such as maintaining infinity.
Added subscriber: @sudashuo
We need this function
Added subscriber: @vojtech.salek
Added subscriber: @fantastic_courbet
Added subscriber: @ehq
Added subscriber: @in10siv
Added subscriber: @WTF1TC
Added subscriber: @Floreum
Added subscriber: @Fabricio-Lima
Added subscriber: @nunocp
Added subscriber: @nerjal
I agree, I'm making some non photo realistic design atm and, and yet I'm working like a real life photographer placing reflective panels to lit things as I need trying to avoid lighting parts I don't want lit, in the real world that is the only way to do things, but in CG land the limitation is crippling. I hope this gets implemented some time soon.
First I want to extend a Thank you to all the hard working devs that implement all this great features.
Now on the topic at hand, I agree with you and with Adam, I mean I understand that for the system to work long term it needs to mesh properly with the collection system,
however that presents the problem of waiting until the perfect solution is coded.
As a user I rather get a usable light linking system in, so the people that need it can at least solve the most essential needs to add some accent lights in some to hard to manage locations
i.e places where no matter what you do you will end up contaminating some nearby object with the fake accent light.
If such a bare bone system is some how implemented then the user can use real work photography trickery of reflective planes to get most of the work in place, (hey, that is even desirable as for the most part users do want consistent lighting, light linking on most cases is used to accent a very specif area that is not being artistically lit as you want, not to lit the entire scene that way.) in some extreme cases having an infinity solution to manage the light occlusion should be properly thought of and a good proper amount of time should be spent implementing it, but, if there is a way to implement a less flexible system that works for just say: 20 collections, well I would take that in a heart beat, such a system would give me the flexibility to at least place some of the most hard lights/occluded objects on those collections and just try to manage the rest as best I could.
As it is right now we don't have any flexibility on this problem, its 100% real world photography workflow or the highway.
I would cast a vote for a simpler system that give us some tools to work, (if such thing can be implemented without taking too much time from the current devs that is,
if hacking this, is a very time consuming task akin to designing a final feature complete solution, then, well that's that, and we need to wait.)
But in case that is not the case, and the only problem is that the system created for now will be stable, but will only work with a limited amount of collections/objects
and can be implemented with minimum effort, then that is a much more desirable alternative than waiting for many many more months or maybe years until a perfect system is devised.
Added subscriber: @Funnybob
I would suggest a system that will be as simple as possible. The render man implementation of light linking is atrocious. You have to keep dealing with popup menues and manually managing lists items per items. You click, you click, you click non-stop. On the opposite side, Maya got it right. A simple user interface where highlighted objects means they are linked, and it supports hierarchy and shaders. We just need a similar system with collections too. I think it would be a major mistake to make a light linking system solely based on collection. I made a clip to explain all of this visually. Check it out! :-) https://youtu.be/jOExOniPJGs
The system in Maya is very similar to the corresponding one in 3DsMax, of witch I was a user for 20 years.
This is how the workflow looks in Max:
This same workflow works for most lights in max using most renderers.
Added subscriber: @Jeroen-Bakker
Please don’t mention other software solutions. Keep discussion to the technical parts of the patch and workflow that matches blenders principles.
It is easy to copy paste, but it is hard to make sure that it isn’t copyrighted. solutions that work for one software might not work as expected or desired on other software.
To my knowledge you can't copyright a function, only the code that executes it. Otherwise you would never have libre office who's a complete copy of MS Word. And if you want to go this way, who was the first to introduce extrude, knife, outliners, bevels etc. I'm not talking about copy-pasting, I'm talking about taking a look at what has been done before, what works and what doesn't so it can inspire the developers. Cheers.
I agree with you, it does not sound plausible that the idea of excluding lights by having a dialog box that excludes or includes things into a light can be copyrighted, I have seen similar dialogs for a number of software, not for lights but to include or exclude something in relation to part of the operations the application does, the actual code or programmatic implementation that can be copyrighted, but at that you can´t just "grab" something from 3d Studio, because naturally the code in Blender is different, which creates the need to code the solution in the actual Blender API, but to discuss how others have done something is how you grow and find new ideas, that goes for well... everything and anything in the world :)
Removed subscriber: @HammadAsif
Added subscriber: @HammadAsif
Just look at Natron. It's a Nuke CC. It's identical at 95%. If you know Nuke, you know Natron. Even the hotkeys are the same.
Maybe if you copy the "concept" right to the most minute details and translate it into the Blender API that could be a bit of a problem...I mean UI details and all, as the the concept as a whole could be copy righted?
but if you just take parts of it, or get inspired by it, then I doubt that can be copy righted, is like the difference between taking parts of a number of recipes of other chefs for your cook book, and taking the whole thing and just change one ingredient, either way Im sure the Devs will correct us if that is really a problem.
Maya's implementation clearly works, as demonstrated in Robert's video. It's not necessary to completely re-invent the wheel when something already works well. One simply needs to look at the setup, then recreate a similar organization solution within Blender's environment.It would essentially be 2 Outliners (one for lights, one for objects + materials) side-by-side in a NEW Editor window type called, "Light Linking".
I think it's not so much a legal issue as it is a Blender policy as stated by Ton in a Tweet and blog post(?) in the last year or two (which I am unable to find after a brief search) that said that we should not post screen shots of competing product UI etc. or discuss duplicating competing features exactly, but just figure out what would be the best way to do things in Blender (my paraphrasing).
Added subscriber: @SakariNiittymaa
Well, Maya and Max solutions are technically possible (in static context for a system that does not support cumulativity) but both are far away from being good.
From the point of view of a workflow design they don't work well.
Added subscriber: @Festivity
Added subscriber: @2046411367
Added subscriber: @niazique
Added subscriber: @colorbook
Added subscriber: @Eqkoss
Hi everyone !
I don't know how to dev in C/C++ but I know little things in python, so maybe I can help with the UI part.
As explained in the light group section Light Group I think light linking system should be over collection.
As mentioned before, many solution exist in other 3D software. All come with pros and cons.
To use the previous example, I agree that the Light Linking of Renderman requires a lot of action, just for simple things. But it has the merit of existing and functioning
For the Light Linking of Maya, I also agree that the system is better thought out. It’s convenient because because you can have access to every level of your hierarchy/collection and also your shader. That is cool yes ! BUT ! When you working on a production, you don't have 3 cube, 2 lights and 1 shading. You have tones of mesh, of lights and shaders to. So the windows looks through the hierarchy and takes really long time in that case which is really annoying.
All that to say that nothing is perfect but if I need to choose I prefere the Renderman Solution, than the Maya solution OR maybe it you be possible to have a mix of both :) What do you think ?
To keep the blender function I think it would be a great idea to use a UI like "vertex group"
If the active object is a mesh, we could have a list in the object property which would be the equivalent of "Object Centric"
If the active object is a light, we could have the exact same light but it would be the equilvalent of "Light Centric"
In that case :
The little downarrow menu could add a some extra functionnality like "Add all" or "Remove all", copy/past the list to transfert it through different mesh/light
This List could also be in the "Material Property", like that we could link or unlink light in a specific shading (Shading Centric ?)
By default all lights/objects/shaders should be selected in there associated list or the panel could be a checkbox tooto define if yes or no we want to enable or disable the light linking function on this light/mesh/object.
If it’s really necessary, this list could also be in the "Collections Property" to affect all mesh inside it.
I don't say this is the solution, I'm only trying to expose possibilities to design the Light Linking feature with the existing blender UI.
Hummm... sorry but I disagree with you. Popup and check boxes and buttons are to be avoided as much as possible, not just for light linking, for everything. In the outliner, when you pick something, there's no check box. You click on the item and it's highlighted. Popups are slow and you don't see all the options at the same time. I was actually surprised in Blender Today when Pablo showed that there was an option before to have button in the shader editor for switching between world, object and line style. I want it!
So let's keep it simple. Renderman's implementation is the worst. You click, you popup, it's everything that should be avoided. Maya's much simpler. You click to highlight. Light centric or object centric. If you select the top of a hierarchy, everything under it will have the same link. And you can override any part under the hierarchy if needed. So same in blender except that we also have Collection centric. This way we are convert for every situation in a very easy to use two column interface. If we want to keep it cleaner than Maya, then we had Shader Centric. So four modes.
By the way, light or objet centric are not exclusive, meaning that it's not one or the other. You can do some linking in object centric and others in light centric.
I did a mockup to explain what I think would be the best possible interface. No check boxes, no popups. Just four buttons on top to pick which "mode" you want to be in. Then just highlight what you want to link. We could also have search fields on both columns in case the scenes are super heavy and we don't want to scale forever to find something.
I understand your point of view but in my example there is no popup. There is checkbox and buttons yes but It’s just a derivative of what already exists (vertex groups, shape keys, etc), so I think this could be studied.
By selecting objects or lights directly in the scene (context) or in the outliner, this is equal to what you explain at my opinion, except that I add a click "Add" or "Remove" to define what you want to do with it. But maybe a better way can be found to do this properly ?
You said popups are slow, I don't know but I trust you. My point is, having a menu like maya light linking would mean having a pop up... Moreover, as I mentioned before,, looking for items (mesh, light etc) through an entire view layer would be really slow to compute ... This is the case in Maya for example when a scene is huge (as often in a production) and it's worst if it's bad optimized.
This is the case in my example ... I simply split the differents parts in the associated properties... Which is, I think, the way how blender proceeds, am I wrong ?
This 4 panels could be read as "layer system". First the collection centric, then shading centric, then object and light centric. In this way it would work from the largest to the smallest.
Yes I agree, but in my example, it's not one or the other. Maybe I don't explain myself well ?
Again, what I explained earlier is just an example. I don't claim to have found the solution ;) I'm just trying to adapt what may exist in other soft, in Blender. In any case, I prefer to have the light link even if it's a bit tedious at first to set up, rather than not at all.
Can you make a mockup please? It would be easier to understand. BTW in Maya you don’t need to select anything in the viewport. The lists will show you everything that’s available. So same as the outliner.
Not sure if it is suitable solution.
Vertex group is a per-object property.
Light Groups are shared between several objects, like materials.
So you have a need to select same lightgroup objects to be able to detect them.
Added subscriber: @VDC
I know how it works in Maya, I'm using it everyday at work :). I'm not trying to reproduce it, I'm trying to inspire from it.
See the pictures below:Order Priority would be something like
Light Centric> or =Object Centric>Shader Centric>Collection Centric.As a reminder, in the example there is no need to use the 4 panels. Only one can be used or several. It depends on the situation, whether there is a need to make an exception or not.
I'm not sure to well understanding your point. Do you speak about Light Groups or Light Linking because it's not the same thing... Here we speak about Light Linking.
As light linking... no ?
Indeed, sorry, I meant linking.
Nice pictures, thank you.
Not exactly.
At the moment we have active object and its property that store other objects, so we handle them by names.
Any stored list of objects is a potential selection set.
It would be nice to have the ability to add them to selection for management purposes.
So it make sense to make 3 buttons - add, remove and select (listed objects in viewport).
I don't think it should be treated like a vertex group interface. It needs to be a general view of the entire scene otherwise it will be confusing and unmanageable. We don't need priorities. Keep it simple. I think the solution I suggested works perfectly. It's a clean and simple interface. You just select if you want to be in either of the four choices (light, object, collection or shader) and then highlight what is kinked with what. Can't be easier than that. Light linking is an editor, not something to be found in the object/light/collection/shader attribute.
Also, in Maya, lights come with a check box "illuminated by default" or something like that, meaning that the light will light everything so you don't have to link it to everything manually. In Blender, just to be different, it could be something like "use like linking". When it's ON, that means that you need to link it to something otherwise it will have no effet.
Also, this SHOULD be on a per render layer base. Maybe you want to link to only be on one layer, not all (should be the same for shaders actually, we should be able to assign shader on a per object and per layer base).
Well, since light linking defines various hierarchical relationships, I guess it deserves a separate editor with add, remove and select abilities.
But it is important to take into account that more flexible is always less manageable and vice versa.
Added subscriber: @dat1
Will there be light linking also available for Eevee?
If I'm not wrong, Light Linking is only thinking for Eevee as it's tag only in the Cycles/Cycles Features sections. But it will probably be for Eevee too in the future.
This is the instruction about how the light linking should work. So I guess we don't need a selection button. Is it really usefull to add a button which allow you to do what you can still do simply with a right click in the outliner ?
Would it be possible to create a differente collection system? Only for light linking with a different icon to differentiate it from classic collections. As it it would be easier to set up the light link with a shortcut like M in the viewport to quickly place an objet or a light in the "light linking collection" ?
Does this mean that Light's linking will be something like this?
Well, yes, I guess! This is what I understand of the description on top of this topic. And this is not a bad idea. Thanks for the illustration! :)
With that method we could add exactly what we want inside, create as many light linking collections as we want.
If this is what they think to do, I think a custom icon to differenciate light linking collection from standard collection will be a great idea. Also the possibly to add shading inside and other collection will be a good idea. Like that we can have the same thing as we talk before : collection/shader/object and light.
To extend your previous example we could have something like that :
This outliner could be a differente "outliner" or it could be in the standard outliner. I don't know what is better.
This way, we keep the collection system as everyone know. It's easy to setup, and easy to use, it's blender friendly. No need new button, simply the same features as the basic outliner.
As I said before, if this solution is approved, I think we should have a differente icons between basic collection and "light linking collection", to easly differenciate it. Give the possibility to store materials in the" light linking collection" should be also add because I think this feature doesn't exist at the moment. One more time, I think this is more what blender's devs expect and explain in the description :
Also by default, every objects/collections/shaders which are not in a light linking collection should be illuminated (affected) by all lights in the current scene (view layer)
I think we should clarify an intendent purpose.
It is hard to design a system without understanding workflow demands.
Like is linkedlight collection's content is affected only by the linked lights, or linked lights and all other lights, including skylight.
The "only the lights in the collection influence the object" result seems to be quite achievable with lightgroups.
In my example, only content inside my light link collection is affected by the light(s) inside this same collection. For example :
- In "Light Linking Collection.002", there are "Area", "Cube" and "Point". So in this situation my object "Cube", will be affected only by the lights "Area" and "Point" because they're all in the same light linking collection.
- In "Light Linking Collection.001", there are a collection "PROPS_COLLECTION" and two lights : "Spot" and "Sun", in this situation all objects inside "PROPS-COLLECTION" will be affected only by "Spot" and "Sun" because they are in the same Light Linking Collection.
- In the other case, all objects which are not in a light linking collection will be affected by all lights of the scene, which is the normal state.
To clarify, if not light linking collection are define, all objects, collections, shaders will have a normal state.
To complete my previous example, a button could be added in the collection property (but only for light linking collection) just to specify if yes or no we want our light linking collection be affected by our background/skylight/hdri. (I will try to do a picture later).
Yes indeed, but lightgroup and light linking are not the same thing. Light Group is a feature that allow us to output the passes of one light (or a group of lights) to used it in compositing, giving us more control. Light Linking is a feature that allow us to define which light will affect which objects directly inside our scene, that way we don't need to output thousand of passes to have the control of each light in compositing. Both of this features are quite complementar but they are not the same. A perfect example was give before, in some production we have a specific lighting only to rim characters. without Light Linking it's really hard to have but because the lighting is never perfect we will out put those rim in a pass (Light Group) to give us the possibility to tweak it in compositing.
Removed subscriber: @Fabricio-Lima
I am trying to imagine how difficult it would be to manage a scene set up by Collection RTOs, Light groups and Light linking simultaneously.
I agree. Keep it simple. I think the suggestion I made was clean and simple. Select your context and highlight what needs to be linked. That's it. All in one editor to have a master view of the scene. No need to mess up the outliner. No need to expand panes so see what's linked to what. Before I talked about a check box to tell the light if it should illuminate by default or not. When I think about it, we don't even need that. Lights illuminate everything by default. As soon as we link it, the light icon can change in a similar way to overrides.
Light linking is a very requested features and we don't want to screw it up by making it complex and unusable. Light groups? It's a render layer.
Added subscriber: @Nico-Traber
Added subscriber: @NunoAlexandreConceicao
I dont completely agree, both ways are not mutually exclusive, just like currently you can drag and drop a child in outliner, as alternative you can also do the same in the properties/relationship pannel. So I believe both your approach and Quentin's are correct, we need to have a more explicit way of doing things in the pannel interface, while keeping the simple way by using the outliner. This way it can be used in the cases where one or the other way fails at flexibility/usablity. If a user doesnt really grasps the logic in the outliner, he can do it in a more explicit way in the property pannel, per light or per object.
Agree, it just depends on the situation, a user can have a scene with hundreds of objects but just a few lights, or hundreds of lights and just a few objects, or both. Having the choice of doing one or the other is what is really important.
ideal workflow for me would be select objects and lights, press ctrl shift M to link to a 'light group collection' (similar to shit m which links to a geometry/empty collection), and that would be it. You could perhaps have a checkbox on the collection which specifies if it's to be treated as an include or an exclude. You can have the same lights and objects in multiple linked collections, so there are no limitations. A filter on the outliner would be nice to so you can specify what sort of containers you want to see in the outliner.
like this menu you get for shift m.
It's fast, it's using an established and understood system, and it shows a nice visual representation of which lights affect which objects. It's also easy to remove objects or lights just by unlinking from a collection.
Agree, I think this can work, but needs something more to set this particular collection apart from any other collection that has lights and objects together.
This is how I'd do it. Extremely simple and intuitive.
I think that idea is good but needs improved upon. First the developer will probably need to consider a special kind of collection to deal with this since some fundamental issues need to be adressed.
First the logic shouldnt be exacly the same, for instance objects and light should only be linked in this kind of collection not moved. Another thing in you example that should be reconsidered are the visibility flags, in this case I dont think we need another flag for light:object inclusion or exclusion, you already have that and better with the camera icon visibilty per object/collection that will indicate if that object will be or not visible in the the render of that particular ligjt collection.
but noone better to comment this than an active developer here.
That is what I suggested just before, except for the include/exclude part which I forgot, my bad.
I'm pretty agree with that. I think having the possiblity to define if it's exlcude or include directly in the outliner is a good I don't. Not sure for the level. Maybe is it better to have it in the parent level not children .. I don't know what is the best.
That exclude/include features could be also add in the "collection properties" as a checkbox for example, only for control purpose. (as for visibility in objects properties for example)
That is also what I suggest few post before :). I agree to, this is a godd way to easly set up the light linking groups but this also can quickly be a big mess, so ... I don't know
And also guys, be careful, don’t confuse Light Linking and Light Groups which are two differentes think in Blender :) so in you good example @3di "kitchen light group collection" should be "kitchen light linking collection"
Oh did you, sorry I didn't read previous posts 👍 What's the difference between a light group and light linking?
Light linking is what we are discussing here while light groups is what is convencionally considered Light AOVs or in Blender a render pass
ah ok, light linking for excluding/including in render, light groups for editing light contributions via passes in comp. Got it, thanks.
updated:
As my previous comment thos lamps icons to exclude/include are redundant, you alteady have the visibility icons to the right of those. So either the lamp goes or one of the other two should be replaced
Removed subscriber: @GottfriedHofmann
On a side note, the light collection could be double purposes, so that it can be used for light linking and light groups. A light collection with no geometry would be treated as a light group collection, whereas a light group with geometry and lights would be treated as a light linking collection.
I agree was thinking the exact same thing now
Here's my two cents about how I have always pictured Light Linking working in Blender according to what I needed in my past works:
Make it a constraint for Lamps. I think it's better manageable and you can pile up to better create and/or organize iterations via constraint/modifier ordering logic; useful if you got hundreds of objects per scene or more.
Additive and Subtractive mode for each constraint. This way you can include or exclude a few objects/collections/etc quickly without having to scroll through the outliner; also useful if you have tons of objects/collections
Possible linking modes are object/collection/material/camera. Object and collection are self explanatory. Material will make the light work only with the selected materials, useful if you don't want to navigate through collections looking for objects that share the same mat. Camera mode will make lights work only if seen in viewport cam/rendered by the selected camera.
Not sure if doable in the current state of Blender hardcode (also not pictured in my image), but an additional 'Influence' feature for each LL constraint would be awesome to test scene lighting iterations.
Removed subscriber: @APEC
Only if Light Groups will not support meshlights.
would be ok if the mesh light only had the light material on it, but if there were other materials, then it should be considered a mesh, and therefore a light linking collection.
I agree with Paul ^^ Also guys there is still a topic about Light Group here Light Group , which is currently in development, give a look and give your ideas there, so please try to stay focus on light linking in this topic.
Also I'm not sure light linking constraint would be a good idea. It will be quickly a mess mixed with other operator, and this operator would be on object, lights, shader (which can't have operator at the moment) and collection (which can't have operator too).
Moreover, I think it's importante to keep in mind the instruction given by @dfelinto on top of the topic :
Based on this instruction, I think Blender developers want to have a system with collection or close to actual collection.
I'm not agree, Visibility icon is for visibility so we need to have a different icon for light linking.
Also, as someone mentioned it before (don't remeber how sorry) because the actual outliner can be really heavy (and quickly a mess), it would be maybe a good idea to have an "outliner only for Light Linking" as we can have for View Layer, Scenes, Orphan Data, BLender Files etc ... for example.
Same Editor "Outliner" but differents Display Mode
Removed subscriber: @Memento
Added subscriber: @dalai-1
I like @nerjal idea, but if it's mandatory sticking to @dfelinto guidelines, I think the easiest way to implement light linking is a simple panel in the object properties, very similar to the collections one.
@dfelinto is not involved in the design of this, he created the task but the contents was written by me. I updated it now based on the latest discussions we had around D11636.
There are two parts to this, one is how the data structure is designed, and the other how is how the UI is presented for it. In terms of the data structures we will likely just have a collection per light object, that determines which other objects it illuminates, with some control over lighting being added or exclusive.
There's a reason that relation goes light -> object, which is that it's the best fit for a typical production setup where you link in the the same characters and props many times, but in each shot might set up different lights. If the relation would go from object -> light, you'd need to add overrides on the objects and things get more complicated. However you can still present both object -> light and light -> object relation views in the UI, while having a simpler underlying data structure, which is what other applications do. And you can have tools to easily create relations based on selected objects, etc.
The first iteration of this will likely be relative simple, and a more advanced UI would be in a second step. Add-ons can also present things in different ways.
I don't think a data structure and UI in the outliner as presented by @1D_Inc, @Eqkoss and @3di works well. In a production setup, if you want to for example add a light that adds a specular highlight on just the eyes of one character, you do not want to have to modify the collection hierarchy of that character in every shot. You want to leave the scene hierarchy unchanged, and instead adds some relations on top of it. Potentially something could be displayed or edited in the outliner, but I don't see it working well as part of the existing "Scenes" and "View Layer" views in the outliner.
I don't think we should support this at the material/shader level, it adds a lot of complexity and as far as I know it's not really a feature in other production renderers either. I don't think it makes a lot of sense anyway as a material can be re-used on many objects in the scene that may have little relation to each other. This is how it worked in Blender Internal, but I think that's the wrong design.
Shaders also have the same problem as object -> light relations in terms of overrides and setting up shots, but worse. Now if you want to light a character with a light particular to a shot, you have to override every material on that character and put the shot specific light in the shader nodes.
Removed subscriber: @dalai-1
Oh, I understand. My screen mockup showed "Material" as a light linking option just out of a specific need but I expected this to be technically unviable. It does make sense to me in a scenario where I would want specific material to have a physical feature more or less eye-catchy without relying on postprocess or extra passes for compositing. Speaking only as an artist, it is not an impossible situation comp-wise and I was trying to contemplate every situation I could imagine being in
Thank you for explanations.
I thought that collections will get another light linkage RTO that will bring the ability to turn it into light linking collection, so you collect all lighting operands (lights and objects) to it and manage on and off states from shot to shot without changing hierarchy.
If it is not like that, we should to design a workaround infrastructure that fits USD format specifications.
Added subscriber: @frogstomp-4
Hi, I am a little out of context but anyways ... lets just say some open source, lightweight game engine that works very well with blender has this solved with light culling and object light masks.
so.. imagine light culling slots:
light 1:
[x ][x ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ][ ]
light 2:
[ ][ ][ ][ ][ ][ ][ ][ ]
objects A light masks:
object B:
[ ][ ][ ][ ][ ][ ][ ][ ]
object c:
[x ][ ][ ][ ][ ][ ][ ][ ]
object A will be lit by first light, object B by the second and object C by both lights.
Note that the number of slots is expendable in the system settings.
This way you have lots of control both from individual object and individual light settings.
EDIT: I read a bunch of comments about not pasting other software solutions. I simply disagree. This just opens the mind up for good practices. And by the way, lineart by @ChengduLittleA already uses such approach for intersection masking.
EDIT 2: removed copiright stuff from my comment to be compliant with guidelines.
Added subscriber: @ChengduLittleA
It’s not a matter of agreement, it’s a rule, and it’s related to copyright laws and enforcement, so it’s not a recommendation, it is forbidden with a reason.
Please remove those pictures, you can explain the same without mentioning other software and doing a quick mock-up representing what you want to explain, no matter if your inspiration comes from other software or not, just don’t use other software material to explain and propose the feature
@juang3d thanks, I corrected my comment with your guidelines.
Thanks a lot :)
Then that would mean every tutorial on YouTube is illegal? You can get inspired by any software you want. Otherwise that would mean that Blender invented every function in the software. We know it's not the case. What you cannot do is to copy/steal the actual code. There are no laws stopping you from mentioning another software. Open Office and Natron are carbon copies of Office and Nuke. But they don't use the original code. Autodesk has other things to do than reading Blender's development forums and sue the Foundation because someone made a snapshot of Maya. Are there any precedent where another software company tried to sue the Foundation over discussions on software development? Let's not get paranoid here. :-)
There is a precedent. The point is that you are exposing Blender developers to legal risk, even if they do not post the comment or even see it. Choosing how much risk is acceptable or determining what is legal is not something you get to do for developers, so we have strict rules.
https://devtalk.blender.org/t/copyright-guidelines-for-devtalk/17331
Thanks @brecht for the update and the explanation.
Seems to be a good approch but I'm not sure to fully understand it . For light 1, you check first and second box but for object A and B you only check one of them ... :/ You don't need to check both ?
Also this set up looks a lot like Layer in the object properties Armature/Bones. Maybe this feature could be the starting point.
However, in my point of view, it’s not necessarily a good idea, at the moment this looks a lit bit messy for me. It will be maybe better if it's more visual.. I don't know, I am skeptical about this issue...
Also how do you decide if you want to exclude or include or neither ?
I stand corrected. Thanks for the clarification @brecht
You should consider using path expressions (such as in Guerilla, Gaffer and other solutions). This is how I've been working and is much more efficient than working with sets/collections of objects.
@Funnybob let's just respect the rules and move on :)
so.. maybe someone can correct me if I see this wrong, but from user perspective, you want to do things with as little setup as possible.
Having a light cull system with all slots populated by default (meaning, everytime you add new light, it will light up everthing) would enable you to quickly remove specific object from light affection and vice versa.
So in my example, there are 16 slots for both, the light and object.
It is basically saying: I, the light with slots 1, 3, 4 will lit up object with either of the corresponding slots. The combos could further be produced by some boolean-ish settings like include, exclude, union (in lineart there is exact match for example)
Removed subscriber: @cschumann
@frogstomp-4 I will :-)
I don't like the idea of using slots because you are limited to 16 and if someone else take over the shot there's no way for him/her to understand what is linked to what. That's why I keep talking about a clean and simple editor. I suggested before that it could also use linking on shaders but it looks like it's not a viable option, which is ok with me since I never used it before in 22 years of using the other software I was talking about. So just a two column system, the first one for the context (light or object or collection) and the second one for what's going to be linked. And the links are just represented by highlights. I my experience, light linking is used as a exception. It's not like every light needs to be linked. It's usually used to add an extra rim light or highlight on one or a few objects. So for the first implementation maybe it could be just that. A simple way to link lights to object or collections.
In large productions light linking is definitely not an exception.
And 16 slots is not enough to cover complex cases.
number is arbitrary, could be 32 or 128 or anything. just recently VSE was updated to use 128 track instead of 32 limit.
But anyways, although this is for me the most visually understandable way that is also easy to debug... I would back off to make room for collection approach, as the lightlinking usually comes with some inheritance rules - this is not the case with collections. Honestly I need to go though all comments to envision all proposed solutions better :)
Initial idea was to prompt people here to check the other software, not to copy things, not to make copyright infringements, but simply not to develop something half way only to realize something what not very well thought out :)
Nothing is stopping you to go to an image editor and draw/sketch on top of it and present the sketch not the original image.
Please don't, we have the strict rules for a reason, don't try to find some workaround where you are obviously still copying from another application.
I see no problem with cloning opensource software solutions in general - this is dangerous for proprietary solutions. From our experience, opensouce has lots of unexpected but incredibly efficient solutions to the industry level problems, and Blender is a nice example here.
For example, we proposed a mulilayer cloner stamp tool to GIMP to edit all PBR maps at once as a layers, it is ready after a year of a research and we would like it be copied by Krita which has awesome tiling checking feature as well.
Or copying Krita tiling checking feature by GIMP to obtain the ability to make seamless PBR maps.
But I don't like the proposed godot solution from practical point of view, since it proposes to create implicit management.
Slots paradigm stands for solution of a combinatirial task in dynamic context - this require explicit management.
For example, it is nice to use slots in QCD/Layers to manage objects sets visibility (an explicit property) to solve Multiref modeling, but in case of light linking you are managing such implicit properties as relationships which has no viewport feedback, so it will be easy to create some setup, but incredibly hard to read it back or parse for management purposes to make some required changes to it and get predictable result.
Hi everyone !
Based on our previous discussions and on what @brecht said before, I did a little mockup. This is a remake of my previous proposition, but I think, it match with the expectation.
To explain me a little bit more, this solution is completely blender friendly and simple to used.
I don't know how to use UI_List but I think we could have an UI_list instead of the current list. (what we have in my first example) The UI_List will give more fluidity and control.
Depending of which type of object is active the list contains light or mesh. This list could also be added to the collection property if we want to have the collection level in light linking.
To complet, we could have a menu who can be called by pressing "alt+L". This menu could be added to the "Object" Header menu or in "Object > Link/Tranfert Data" (directly available with ctrl+L shortcut) or in a new header menu "Lighting or Light Linking for example.
Also I found something on internet which look like this :
c.f : "How to get one UIList to control the contents of another UIList?" on blender stackexchange
(I don't know if I can share a link from this website so I Only give you the info to found it more simply)
As I said before, I don't know how to use UI_List but in this example the Ui_List on the left, "control" the UI_List on the right. I think that could be hijacked to create a double control panel as mentioned before (this is to illustrate the Maya control panel but in blender)
Here is my .py file of my simple UI (the "Active object is a MEST/LIGHT" label is only for comprehension purpose):
Light_Linking_UI.006.py
@brecht Do you think this could be a good starting UI ?
This looks like a solution for a single light linking, am I right?
Light linking belongs to scene setup process, which is performed in static context, therefore names of links are important.
An example - highlight eyes of 3 characters, named A, B and C.
You will need 3 different light links, named as LLA, LLB and LLC to highlight their eyes.
UI_List may fit that requirement if light links will be in the left part, objects + lights will be in the right part, and if ui will have select object button and will be placed in scene properties section.
My UI ? Or the double UI_list ?
I'm not sure to fully understand, but I will try to answer.
In my opinion it simply depend how the feature will be developped.
Here I did an Ui only for example, It's not a full compatible UI, because I don't know how the feature will be develop in back.
In my example there is only one list but we could have multiple list for multiple light linking (one list per light linking). The list could be assimilate as "Collection" but it's an "invisible collection"
Also this example is a good one but also a bad one ^^
There is a lot of setup possible, maybe you want to have one light for each highlight. But you can also only have one light for all. So in this case only one list(light linking) is needed.
A feature/UI induces a methodology/workflow. I think it's an important point that everyone need to keep in mind
I think if double UI_List solution has enough capacity to cover multiple light links demand, it will easily allow to handle a single one, named LLABC if it is needed.
To me this looks over complicated, just needs to mention a collection of lights or objects and if its in included or exclusive mode, no need to specifically mention every single element, imagine lists of dozens or hundreds of lights/objects ?!
Hi @nunoconceicao. If the list is develop for the collection level, it's what I have in my UI.
Add All Lights and Meshes you want in the collection then Exclude or Include it :).
The per Light or per Object linking is only for Light Centric ou Object Centric, if you prefere. But in any case you can also do it at those level because with my simple UI, you have the possibility to add/remove multiple objects / Lights in one click. So it's easier to set up. We can also add a Copy/Paste list button to quickly copy a list in another list.
Remember that's only a simple UI example, it can be improved later :) I have a lot of thing in my head but not necessary the time to develop it ... :/
Removed subscriber: @Tasch
I agree with Brecht about decoupling Light Linking from collection engine and putting it as a system on top of it - it is a wise choice since Light Linking has nothing to do with scene content management that Collections and Outliner are designed for.
Light Linking is a system for local light/mesh objects relationships.
I also like your double UI_List approach because all Light Links are located in one place (has a single access point) so you don't have to trace the entire scene or look through the entire outliner.
When you work with Light Links you are focused on them.
Little disclaimer : As I said before, this double ui_list is not a creation of me. I found it in blender stack exchange. But I agree, it's a pretty good interface if it's usable.
I also agree with both of you. This is the reason why I try to use a list system in my UI to pass on top of collection/scène system. Now I have a better idea of what you talk before with your example LLA, LLB, LLC etc.
Thinking of that I will work on the UI to see if it's possible to found a solution to mix what I currently have with another list system which will give us the possibility to Group things together and include or exclude it. I think I maybe have the solution but I need to test it a little bit before and code forsur ahah
Hi everyone ! I'm back
I have work in a new UI. Hope this one will be better.
The red part correspond to the "collection centric" part.
In the Collection Properties you define/create your different "light linking filters".
(I put the panel in collection properties for example purpose but it's maybe not the best placement. Maybe it should be better to place it in scene properties or layer properties like that we have acces to a "collection level")And you define if the filter will be in incule or exclude mode, by clicking on the little Light Icon.
If you stay in None, all light linking will be ignored.
In the Object Properties you define in which "Light Linking Filter" your object (MESH and LIGHT) will be
In the example our mesh is in LLA, LLC and LLD, our light is in LLA, LLB and Other. Because Our mesh and our light are in the same Light Linkg Filter (LLA), our light will only illuminate our mesh because the light linking filter(LLA) is in Include mode.
For this example I only put one light and one mesh but if 3 lights are in LLB and 4 meshes are in LLB and LLB is in exclude mode then our 3 lights will not illuminate our 4 meshes because they are in the same Light Linking Filter.
The blue part is the object centric (if the active object is a mesh) or the light centric (if the active object is a light).
That part allow use to specify numbers of meshes which are affect or not by our light depending in which mode we are (include or exclude). This part could also looks like an UI_list who point to objects or lights but I don't know how to do it sorry.
Why I want to keep the blue part ? Because in my head we could had something like that:
In scene properties we create our light linking filter. In Colleciton, Object(Mesh and Light) we define in which Light Linking filter they are. That way, we can assign an entire Collection to a LLF and exclude only on object of this collection for exemple
Yes, you didn't invented double UI_List, but the idea of using such a system for Light Linking is definitely yours =)
I agree with Collection level support - it is useful when you need to lightlink lots of objects.
But I am not sure about excluding option - it creates lots of implicit management.
If you need all collection's content except several objects, technically, you can place them to a subcollection and lightlink it directly - to get a predictable explicit setup, avoiding include/exclude implicit management and the necessity for making infrastructure for it.
It is hard to say how exactly such an implicit management is demanded, does it cover valuable part of demads and whether such a flexibility is not extensive.
Added subscriber: @cschumann
FYI, e-cycles now has light linking! :)
How about you have 2 different hdri in the shader editor and you only want 1 hdri affected 1 certain object and the other hdri another let's say whole collection?
Or how about a light linking based on materials too? Let's say you don't want to separate the eyes of a character to make it able to light link.
And how would you exclude the bounce lighting of another object?
Yeah! I see it. That is pretty cool. Just hoping Matthieu will give a help for the LL implementation in blender way now :) it could be really awesome.
Also he's solution is pretty cool but not visual enough for me, not explicit enough for work in production. String will be better than numbers in my opinion.
As Brecht mentioned it before :
He also said to keep it "simple" so I'm trying to respect that :). As you said, even if you don't have the material level you could simply create a light linking filter and put it inside with my solution.
For the double hdri problem, I think of that few days ago. But at the Moment because I try to keep it simple, I only focus on collection and object/light. In any case, what we have for the object/light panel could be simply add to the background to have the environnement linking or maybe add a check box to decide to include env or not in the LL filter for example. But I think this feature will be maybe the next one, after a first development. I don't know.
Currently I'm re writting a new mockup to give a better view of my previous one.
I also try to give an interest to the double Ui_list which I think could be useful but maybe to heavy but it not easy at all.
Don´t know, but it is keyable! :D
I believe eventually the developers will have to shift the world lighting into an environment light primitive.
Added subscriber: @pietrodichito
Added subscriber: @lictex_1
Hi peoplenof the blender community!! Hope you're doing well!
Is there any news here :)?
I almost re write my previous mockup to be more clear. I also working on a double ui_list panel to do a new proposition but currently I don't have the time to dev since I work on a new production.
Is some one have new ideas? That could give a new point of view which could be really helpful :)
Hi)
At the moment it is hard to me to imagine a solution that could be possibly better than a double ui_list.
I am also not sure that it makes much sense to provide anything else but double ui_list - I mean object and light data properties.
This allow to detect which LL active object belongs to, it is useful, but it is hard to say if it is much required, since working with LL is usually LL-centric, and double ui_list cover such a demand with select LL objects button, so you can view and manipulate (exclude/include) LL objects.
Collection case is even less clear though.
Added subscriber: @MattCurtis
Added subscriber: @AlexeyAdamitsky
Added subscriber: @SotirisKouvopoulos
Added subscriber: @ChAoS_O
Light linking is a rather complex task. As a Lighting Artist/TD with 20 years of industry experience i really have to deal a lot with that. So from my production POV my 2 Cents:
Please dont copy ancient workflows.
It would make sense not to scatter light linking over different places. Thats a major problem in houdini - pre solaris - workflows.
I personally think there is no really great solution out there and something like a nodegraph would be perfect to do this kinds of overrides.
Like dropping either a light, an object or a group into the graph and add special nodes like exclude/include illumination/shadow, groups, light filters, or overrides like color/temp. This would be easy to read for the user and can be extended with more nodes in the future. To give the user a complete overview there could be a summery node showing all the overrides.
Cheers
Added subscriber: @jeremybep
Added subscriber: @safaasgar
Added subscriber: @KevinCBurke
Added subscriber: @Steven-6
Removed subscriber: @Steven-6
Added subscriber: @Nurb2Kea
e-cycles having light linking makes me want to cry because eevee nor cycles don't have any.
Added subscriber: @Garek
Added subscriber: @el_diablo
To support my friend's comments here, the Nodal graph which evaluates to a path expression would be the most future proof implementation IMHO. Btw, light linking is really a necessity when doing reusable setups for episodic work. I can't even phantom working with a renderer that does not support it.
You and many people, most lighting and compositing artists I know dont even consider using Blender/Cycles just for this limitation alone.
Removed subscriber: @jimix85
Yeah, I completely agree with you. I'm a lighting artist and I'm working in the industry and I know for sure that lot of people don't want to use blender because light linking and light aov doesn't exist.
In fact that wrong, it's possible to do light aov and light linking in blender, it's pretty primitive and a little bit messy to do it but it's possible. As light aov will be implemented in blender 3.2 (if I'm not wrong) it's maybe possible to also implement light linking if we found a usable UI and if it's devlopped.
I also agree with the fact that light linking in a nodal system will be a good things. As blender said for blender 3.0 "everything node", this is the objectif. And light aov, light linking and lighting also should be nodal.
But in a first step I think just having light linking even if it's not nodal is primordial and we need to have. I do some proposition previously, I'm still working on it and trying to found a "good way" to implement it in a simple blender UI way.
Parallel to that I'm also trying to imagine a nodal way/interface (I'm only thinking about UI because I have no knowledge about C/C++). Because I don't have a lot of time after working, I'm hoping show you that in few weeks.
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)
Added subscriber: @makizar
Added subscriber: @Yuro
Added subscriber: @etlaM21
Added subscriber: @zx
Added subscriber: @htuncay-4
**Each light (standard light & mesh light) needs a dropdown menu for everything that can be lit and is in the actual scene file (switched on/off) + linked groups or meshes from other blendfiles.
By defauls everything + groups gets added to this dropdown list of each light .
THEN: everything that gets selected will be visually marked in each Light Exlude List and be excluded from the light being lit.
These lights with each exclude dropdown list can be put into light groups for compositing etc.
(( I don't want to use several nodes for a cryptomask, to use this mask to mask out parts of lights...)) That's the worst solution ever in 2022 !
That's the basics of comparing of known solutions. **
//Those single node setups aren't a solution at all. Just think of any scene for the last blender movie.
If you manage all those lights and the light groups via nodes, you can hire another company to do this job.//
There are many solutions from other major 3d apps, that do it well for years.
I would compare all of them, get the best and fastest workflow solution out of it AND fit the coding around it.
**Because, if this is logistically and workflow friendly coded, the work with light linking and groups is done ONCE by the team and devs,
otherwise all users will spend every day a huge amount of time to incl., excl. & light grouping via nodes + many windows to tell what lightgroups. etc...
**
I already tested the light groups, and it's a lot of work. It works, that's ok so far.
Only thing I noticed is with a lightgroups setup, you change the name of the lightgroup after you applied a light to it, the new lightgroup name won't get updated for the light in that group.
But to much trouble for 3 lights + a few grading layers to change the lights...
And that's just the lights, the rest in the compositor comes into the game as well, and makes the updates in the compositor a lot slower.
And for example you do your denoising yourself, you have to include/integrate those lightgroups into the denoise tree, otherwise... :-)
Hope that makes sense!
Added subscriber: @Fynn-Ribbeck
Added subscriber: @Gurra
Maya have a pretty easy but elegant solution, a light centric list and an object centric list. In the light centric one you have a list of all the lights to the left where you select one or more lights and on the right you have a list where you can deselect or select objects to be light linked to the light on the left. In the object centric list it's the other way around; you select one or more object and in the light list you can deselect or select whichever lights you want to be linked to that/those objects. No sure if there are any better way than this to do it. I did try the one in E-Cycles and it wasn't nearly as easy to use as Mayas, and also it was bugged, started to kind of "bleed through" the bigger you made the light source.
Added subscriber: @glencandle-3
So I just read this thread and I feel like there is a solution being overlooked here:
In the properties tab for each light why not simply have a list of objects to exclude from being illuminated by said light?
Conversely you could also specify only objects that will be illuminated by said light.
Wouldn't this be the simplest solution to the problem here? (Not from a code perspective, of course, but as far as functionality.)
@glencandle-3
So then managing many lights,, you have to go to each light instead of the manager that keeps all of the lights/objects in one place.
Also Gurra already explained using lights or objects.
Light manager working in many industry 3d apps in both ways already.
Anytime a function, a tool or whatever is designed, it should be reduced to the most basic way to do it. If you want to move, scale or rotate an object, you select it and move/scale/rotate it.
Light linking should work the same way. What do you want to do? I want this light to only effect that object. It should be as simple as that. That can only be done with a simple and clean user interface.
The first thing to consider is that lights illuminate everything by default. If you want to do light linking, you first need to tell the light NOT to illuminate everything. Just a check box. Because if you want that light to illuminate only one object out of 5000, you don't want to uncheck 4999 objects.
So now you have a light that does nothing. And from the GUI, you just select the meshes, collections or shaders you want the light to affect. Yes, collections and shaders should be included in the light linking process.
The last thing I want is to have to go to the object properties, find a sub menu somewhere and do this one by one, like it's the case for light groups. It's unmanageable one huge scenes. A user interface is a must.
This is exactly what I talked about in my lastest YT clip. Some people in the comments wrote that E-Cycles and K-Cycles have interesting solutions for that. I don't use them so I can't tell.
@Nurb2Kea a separate 'manager' sounds messy and over complicated in my opinion, but regardless if there was any kind of way to eliminate objects from lights it would make a world of difference
Added subscriber: @tempdevnova
Hi, apart from wanting to say that I have been longing for this feature for a long time I also want to give some input from the user side:
As someone who works on large scenes with up to hundreds of objects I think that a layer system like what we had with Blender before collections were introduced (so prior to 2.8) would be very limiting and quite frankly a horrible experience for the user.
Having the objects included/excluded by the lights be listed like e.g. vertex group would be an option, but if there are many objects in this lists (possibly hundreds), the list would get ridiculously long and the user experience would probably be worse than with an layer system.
However this could be supplemented by a collection like system, so that the tab would become something like the outliner.
As for excluding/including lights, I think just adding one of the options is sufficient as objects that are not included are automatically excluded, meaning adding both options would just be redundant. Instead we could make it such that the user decides whether objects that are listed in the "light linking" tab should be included or excluded by an e.g. tickbox.
Some kind of editor like the outliner but for both light linking and light groups. Objects, lights, shading groups or collection can be "parented" to a "linking parent". The LG is to define if we want it do be rendered as a light group (otherwise it's light linking),
It will become messy thought with the render layers on top of that.
An elegant solution would be to use a node based approach, specifically using light nodes. What I have in mind is something that works like the light path node where it would have a list of object to include and exclude and give a boolean value depending on whether or not the ray hitting the lamp is in that list or not. This output could then be used to drive the behaviour of the lamp, giving the artist great flexibility.
Of course this would mean that the list might become very long including possibly hundreds of objects which is why this should be supplemented by a collection like system, so that we would have something like an outliner within that node.
Added subscriber: @MrAlwis
Are y'all still working on the UI or have y'all moved onto development of the logic?
Added subscriber: @DanielVesterbaekJensen
I think lightgroups and light linking would be two differente and separate things. Also a proposition about a "Collection" system have still made and this proposition was push out by Brecht(as tout CAN see 8n the next quotation) Don't know if it's the case or not but pls read previous post before posting :)
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.
The interface to manage it, could be a simple tag system. I will try to made a little mockup to five a visual to this proposition and a better explanation
In my opinion
Light Groups are ok to be handled with tagging system - maybe utilize 2.7 groups chassis, which is a tagging system which was originally designed for similar purposes, solving tasks like "select objects that belongs to the Light Group of an active object" or "assign Light Group from active object to selected objects". The only difference is that Light Groups are not cumulative - you cannot place the same object to several Light Groups, which is reasonable since this allow to avoid doubling lights in compositing. This way Light Groups are structurally closer to Common Groups system (like in Inkscape or Sketchup) but without ability grouping groups.
Light Linking is better to be handled with double ui list, since it is a cross-hierarchical system that operates with named lights-objects dependencies, but it is cumulative as well, so you can place the same object into different Light Links. This way Light Linking is structurally closer to tagging systems such as 2.7 groups system.
With all those inspirations we should not forget that, however it will be implemented it must be animatable as well.
(Thinking of fade transitions etc.)
And it needs a manager like the outliner for example, otherwise you won't be able to manage big scenes if you have to select each light and/or object in one or two sidebars.
Removed subscriber: @Rockbard
Added subscriber: @MrJ-2
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.
Added subscriber: @blackpepperjam
Added subscriber: @NEEO
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?
This comment was removed by @NEEO
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.
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 @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.
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.
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:
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 :)
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 :)
Removed subscriber: @cschumann
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?
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.
Added subscriber: @heabeoun
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.
Removed subscriber: @tempdevnova
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.
Removed subscriber: @KevinCBurke
Added subscriber: @dursunumit
Added subscriber: @Nebulon1212
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.
this is right.
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.
Removed subscriber: @Stinaus
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).
yeah, I'm avoiding B3D in large projects just because of the lack of light linking.
Added subscriber: @ckohl_art
Added subscriber: @sgariepy.3d
Added subscriber: @Canopy
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.
Added subscriber: @hoxabel
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.
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?
Added subscriber: @AbrahamCastilla
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.
This comment was removed by @Nebulon1212
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.:
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".
Added subscriber: @Austin-Berenyi
Added subscriber: @JohanTriHandoyo
Added subscriber: @alFrame
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 :)
Added subscriber: @Jonah-S-Oskow-Schoenbrod
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.
May I ask why? Imho that’s ridiculous, besides any legal reason to do so.
Added subscriber: @DuarteRamos
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 [ https:*www.youtube.com/watch?v=SlB2S54pa9I | official video from Pablo Vasquez explaining why.
So yeah. Legal issue. Completely understand. Thanks!
Added subscriber: @Peter-Gerace
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?
Removed subscriber: @frameshift
Added subscriber: @YesungYoon
Added subscriber: @Sonatine69
Added subscriber: @Dangry
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!
Added subscriber: @Nominous
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...
Doy you mean light groups or light linking?
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.
Added subscriber: @alvaroperez
Hello!
I'm Pau, a Lighter working in the animation industry, passionate about Blender.
I have read the entire thread and, knowing there's no crowd pleasing design on how light linking could be implemented, I left my take on it on right click select. It works unlike any other software: It isn't that much of a bilateral link between an object and a light rather than a light masking out an object or vice versa. It's based on how light rays can already be masked based on other parameters, such as light length, depth or component and should be able to solve any situations where light linking would be needed.
A head's up: no new modes, no messy UI, no fiddling with collections.
I hope you can take a minute to review it, I'd love to hear your feedback on it.
Thanks!
https://blender.community/c/rightclickselect/JQlJ/
Two notes on that:
The only thing I've seen in the thread that this doesn't cover is its possible USD compatibility. I simply have no idea about USD standards at all.
I want to acknowledge that my proposal is accidentally similar, although simplified and more documented, to what @3di proposed 3 years ago.
I really like this comcept. it's really BLender like and it's not a rip off of another software's concept.
Fantastic idea @homspau, I like it.
@homspau I don't think doing the object-based approach where you get a output based on the sampled light is possible, due to the order in which the path is traced. The evaluation of the object's shader happens before light picking, and the evaluation of the bounce throughput happens before indirect light queries (for MIS).
The light-based approach should work (at least from a technical level), from what I can tell. Both for direct and indirect light evaluation, we have the information which object was hit before, so we can query it in the shader.
The part where it gets tricky is accounting for this in the light picking logic. For example, imagine you have a super-powerful light that is only supposed to affect one object - since the light tree is for the entire scene, it'd have to either give a high weight to that light, which means that all other objects will end up picking this light a lot only to then end up with zero contribution, or give a low weight to that light, which means that the one object that should be affected rarely samples it, leading to noise.
Then again, any sort of logic in the light shader is currently a limitation of the light tree - if you have e.g. falloff control, it won't account for that either.
@weizhen, this topic might be interesting for you as well :)
Hi @LukasStockner! Thanks for the reply and for the great explanations (I think my artsy brain gets it, so congrats!).
The only thing I don't get is the 4th paragraph. If the shader logic in the light tree works, shouldn't the falloff control via light path node (image 3 in the proposal) plus the proposed light masks work together?
I get how only light based masking would be possible and light picking would be an issue. Yet again, light falloff control via light path node should also encounter the same issue with light picking, isn't it? I get how in extreme cases can become a burden but I've been using this in production without noticing any regression.
That being said, can I ask for your thoughts on implementing something like this?
How hard is it? (I have no clue at all) Should it be a different conversation than looking for a traditional light linking implementation?
I think the interest in this feature would be there, as it would make possible to solve most of the scenarios where light linking would be needed and more.
Thanks again!
My friends who want to subscribe to this thread are getting an error. many people get errors, why?
@dursunumit could you please ask them to report that as an issue in https://projects.blender.org/infrastructure/blender-projects-platform/issues with as many details as possible so it can be investigated?
Shader logic in the light tree currently doesn't work, that's the problem. But, that's also why I think that it probably wouldn't be too much of a problem for light linking - we're not making it worse at least, it's been a todo before and it would still be a todo later.
Implementing it is not the problem, a prototype implementation would probably be a day or so.
The bigger issue is planning to make sure that this is actually how we want to do it - Cycles already has a number of features that seemed like obvious options at first but are now causing problems with other features (e.g. ray visibility options vs. path guiding).
So, we need to be careful with adding features, because once this is in you can imagine what the reaction to removing it again would be :)
There's also the point that we really don't want to have two different styles of doing light linking at the same time, so we should ensure that whatever we implement is compatible with e.g. USD (I never looked into how USD does this to be honest, but I think there's a standard?).
And of course it should also work with Eevee, which is not so easy/efficient with the node-based approach. And so on.
I learned my lesson about "just creating a quick prototype" with the scrambling distance patch, so I'd like to at least bring this up in the next Cycles meeting before writing any code.
Hi @LukasStockner, thanks for clarifying!
Totally get your thoughts on this. I get how it sure isn't a proper light linking implementation but a cool feature with a similar use case. Also, totally get the precaution.
I'll love to read the notes on the Cycles meeting. Can't wait!
This task has turned into a feature request and idea brainstorming task, which is not what developer.blender.org or projects.blender.org is for. The feedback is appreciated but this website is meant for focused developer work.
For further feature requests and design ideas please use https://blender.community/c/rightclickselect/?sorting=hot&page=1&text=light+linking.
The new task is #104972.