Lights in Local View.

* @testure * what's the real intention from the Devs? because this sound counter-productive to remove something that speeds up users workflow and if it can be done with a small script then it should be brought back on the stock version.

* @testure * Hell yeah, this will come very much in handy. I do miss the isolation with lights.

* @Cobra * There was a lot of discussion about it last year, ultimately the rationale was that the 2.7x behavior was misleading. New users expected only the selected objects to be visible after a local view. There were too many logical edge cases that depended on user intent- for example, if I'm working on a large scene the size of a downtown city block with dozens of lights but want to work on a single building's facade, I'll still have dozens of lights visible even though the majority are not relevant to this object. Then the argument turns into "well you could lay your scene out in such a way that... " and then it becomes "well if you could do that, you could also just select the lights you wanted to be isolated". And here we are.

For those working on individual props the 2.7x behavior made a lot of sense, for the rest of us it did not. Remember that something that speeds up your workflow might slow down other workflows, and in some situations there is no win/win solution. I agree that having an option in the localview operator would be useful, but then do you have an option for people who are working with curves? particles? empties? armatures? it starts to unravel pretty quickly.

* @testure * Well then the option could be more generic like "include all Extras" and add their local view option in the object type visibility popover , it will cover any of those scenarios and gives users more control.

* @testure * As long as it's an option, I think the debate wouldn't even be needed. It makes sense in the workbench to isolate only selection. In render preview, it makes sense to isolate with lights. Both systems need to exist.

* @Andres Stephens - Trinumedia * One of the initiatives Ton gave for 2.8 was to reduce the number of options because there was so much redundancy and overlap that it was overwhelming to a lot of people. There's this tendency for the blender community to say "I want X my way! but only a few people are going to want it so lets not force it on everybody- make it an option". If that happened every time somebody requested a feature you'd need a PHD to navigate all of blender's options, and many of those 'options' would enable truly bizarre functionality (just look at some of the posts that show up here on RCS). Not saying this one is bizarre, but the need is very niche.

One of the concepts behind Blender is that a robust Python API empowers the community to solve problems for itself and not rely on features being built-in.

* @testure * Yeah, tell me about the redundencies. I've worked on tasks for a UI fork of Blender and they've removed more than a few dozen double entries, even same operators with different names repeated 4 times throughout the UI. But I don't see this one as that redundant. But yeah, nice a script exists already.

* @testure * Can you help out a noob here? I've pasted your script into the startup folder but can't seem to find the operator within blender. Thanks for the help.

I did not find it neither and hope I will because I spend my time in the dark in local view, and switching the lights back on in isolated view.

Here is the post I had made about it (it concerns isolated view but it is the same principle): blender.community/c/rightclickselect/Xthbbc/

Many thanks for the script, though.

I still did not get very well the startup file and userprefs procedure (in this mysterious hidden folder that can only be accessed through a %appdata% and not by navigating in the folders -?-)

Hey. Apparently it doesn't work anymore in 2.93 ((( Can you please take a look whey you will have a time? I'd be happy to have this as an addon.