Why Is There No Local Render Toggle Outside of Collection Checkboxes?

I am wanting to create YouTube thumbnails for various languages in which I would composite individual parts over each other in a layered fashion as one would do in GIMP or Photoshop. I have hundreds of collections and likely over a thousand objects (even thousands?). A given collection for a given item would have various objects that are different depending on the language. I tried to create different view layers for individual components of the final render, and I wanted to have specific items set to render just for that specific layer. I finally realized that my toggling on or off the render view in one view layer did it for other render layers. It is global, and there is no way to toggle the render for a specific view layer only. One can have some workaround for this by creating a lot of collections (that I would not otherwise have and that would thus clutter up the outliner unnecessarily) and then checking or unchecking the specific collection checkboxes, which are per view layer. But the collection checkboxes take away visibility, which I do not want, and the plan is to render some things differently to composite two final images: one as a square version (for Instagram) and one as a 16:9 version (for YouTube thumbnail), which would require extra work and duplicating items simply because there is no local render toggle. This topic has already been raised twice (see Amending View Layers to track local render visibility - #3 by Zollie and Local view should be available on rendered viewport), but nothing has been done to enable the feature. Is there a reason why a local render toggle has not been implemented in the outliner? Not having it is creating a headache for my render situation.

Questions concerning blender usage are typical posted on blenderartist, not really on devtalk.
I can see though that if you are unaware of a feature you might want to start a discussion here. To discuss its potential.

Regarding your question:
First, activate the viewlayers in the outliner

In the example file I created one ‘Master’, and then ‘A’, ‘B’, ‘C’.
Master exists solely so I can see all objects. Nothings hidden.
A,B,C are then what you would use to distinguish between different languages / thumbnails.

Viewlayer setting ‘Master’:
image

Viewlayer setting A,B,C:
image

(rename this file to .blend)
viewlayers_collections.txt (150.4 KB)

Sry - forgot the viewlayer settings, edited the .blend file
(Also went in the same trap with the object visibilities)

1 Like

Thank you for your reply. I am aware that this forum is not for feature requests. But as this was a feature already proposed and not adopted, I was wanting to know why the decision was made not to incorporate the feature, which might lead into productive discussion as to the benefits (and costs??) of the feature.

In regard to the screengrab that you have shown, that is just the checkbox workaround that I had in mind, but it has problems. Suppose you have a backdrop of various colors in one collection, one color per 7 languages (and maybe additional language(s) in the future), icon #1 in various colors for the various languages. I don’t want to have to put every one of those different colored icons in its own collection so that I can have it render locally only in that view layer. That would be unnecessarily adding a ton of collections to my scene. I already have hundreds of collections and potentially thousands of objects.
Further, if I am rendering out images for a square instagram format and a 16:9 thumbnail format, and if I want one color backdrop for the instagram one and one color backdrop for the YouTube one, I would either need to duplicate the backdrops (which I would not have to do if there were a local render toggle option) and thus have unnecessary duplicates, or I would need to put them in their own collections, which would add clutter to an already big file that does not need more clutter to make it easier to get lost. Good organization helps, but these are workarounds that get in the way of my rendering because it was decided not to implement a local render toggle option.

1 Like

I am not sure that @julianeisel was employed by Blender when a lot of the 2.80 and GSOC outliner improvements were made, but I would be interested to hear what his thoughts are on the pluses and minuses of having a local render toggle per view layer.

I think you have a valid point about the collections, I walked into that problem myself right now.
It would indeed be much more convenient to have the visibility per viewlayer.

At least I hope that the ‘Master’ workaround helps you in the meantime, to see everything at once.

Thank you for taking the time to respond and throw out the collection checkbox workaround. Your idea was basically already what I was planning to get around the problem. But as you recognize, it is a workaround, and, in my view one that is necessary only because there is a deficiency in the outliner feature set. Per view layer visibility has a local toggle (eye icon) and global toggle (screen icon). So I am curious as to why the decision was made not to do the same for rendering when it would be very convenient and would avoid otherwise unnecessary duplication of objects or avoid cluttering of the outliner with otherwise unnecessary collections.

Although I have done some coding work and plan to do more, I currently don’t have enough knowledge to write a patch to add the functionality to the outliner, and even if I did, it would be a big enough design change that it would need to be run by devs first. Hence it seems a good idea to broach the topic and inquire about the reasoning for the current global and local toggles for visibility but only global toggle for rendering.

Just to add in - I also got thrown off by this in the past. One would expect this functionality given the whole concept of view layers…
and for the time being - you could add some pre-render handler that copies the viewport setting to the render setting?

Thank you, Atair. I confess that I don’t have the expertise (or at least don’t know how) to use a pre-render handler that copies the viewport setting. I will get by for now with duplicated objects and more collections than I would otherwise need in order to compensate for the lack of a local render toggle. But I do agree that this functionality would be expected given the concept of view layers. If all you had was two objects, a square and cylinder, and you wanted to render each one in its own view layer, you would not be able to press the render button and have it do so without you first creating unneeded collection(s). If you just had the two objects, and you toggled off the render icon for the cylinder in view layer #1 to only render the square in that view layer, then that would also toggle off the cylinder in view layer #2, which is the one that you want to render the cylinder in. So you would not be able to render the two objects by themselves, one per view layer, without adding in a collection. That is a pretty big design flaw that should be fixed. But at this point I am beating a dead horse and harping on the same point. I would hope that a local render toggle gets implemented at some point if there is no justifiable rationale for the omission.

The current setup asks collections to take on three conflicting roles: organization of scene assets, local render toggle, and a second local visibility toggle (since unchecking a collection removes the visibility of objects in the collection). When those functions conflict with each other (as happens in my case) and even in the simple case of wanting to render a square and cylinder by themselves in their own view layers, the user is forced into a less than ideal situation because the outliner does not have a separation of concerns between organization of scene assets and local render functionality.

These conflicting roles are evident in what I already described. First, if I try to use the collection checkbox as a local render toggle, then I have to create extra collections or duplicate objects, which is contrary to the role of collections for organizing scene assets. If I prioritized scene organization, then I would not have created extra collections and duplicated objects in my file if there had been a separation of concerns in the outliner between local render toggle and organizing scene assets.

Second, if I prioritize the use of collection checkboxes as a local render toggle, then the fact that the checkbox is also tied to local visibility (in that unchecking it means I can’t see the objects anymore), means that I can’t work with to-be-rendered objects right next to not-to-be-rendered objects (which is useful for placement of objects) up until the time of rendering. If I have the not-to-be-rendered objects visible by having the checkbox marked of the otherwise unnecessary collection, then before I go to render, I need to go back into that scene and ask myself if and what collection checkboxes need to be unchecked now before I render. That slows me down, introduces the possibility for error such that I could forget to uncheck the relevant checkboxes, and it slows me down by causing a mental fog and uncertainty. Well, I might ask myself, did I get all the not-to-be-rendered collections unchecked? Maybe I will look again.

If I have the not-to-be-rendered objects unchecked, then I can’t adequately work in that view layer because I can’t see the objects to be rendered in that view layer in relation to the objects that would be rendered in a different view layer. The solution to this is what @rbx775 mentioned. I could have a master view layer in which I have all the collections and objects visible together that I could use to plan the final scene. This would be unnecessary if there were a separation of concerns in the outliner between organizing scene assets and rendering objects locally per view layer.

But even this solution is not entirely helpful. Again, it comes at the expense of organizing the scene, since I now have a view layer that I would not have if my main priority was organization. But that to the side, what if one wants, as in my case, to render a title that covers much of the camera view for a YouTube thumbnail, and also render an Instagram title that fits into a square area, and the two titles overlap each other? Now, if I want to avoid the cluttered master view layer, I would need two master view layers, one for the Instagram image and one for the YouTube image, and this all because there is no local render toggle. The collection checkboxes have taken on conflicting roles.

A correlate to the mental fog that I referred to above happens repeatedly when I am in the different view layers and see the render toggle. If I am in the view layer that is meant to render just one item that would composited with other items post-render, and I see different objects in the outliner with the global render icon toggled or not toggled, I repeatedly have had to stop and ask, ‘is that right?’ or address something similar. Of course, I would still have to ask if a toggle was right if the render toggle was local rather than global, but what the global toggle does to the user mentally is very different. If the render toggle is local, and I know that this view layer is just for that one thing, then it is very easy to quickly answer in my head the question of whether a render toggle setting is right. But if the render toggle is global, now I have to step back and think of what I am wanting all the final images to be and whether that particular component is a part of one of those images. That is a much longer process mentally. And it has happened repeatedly.

All of this could be solved by separating the concerns of organizing scene assets and rendering things locally per view layer. Collections in the outliner take on both of these roles and the role of local visibility, and the conflicts in these roles force the user to adopt workarounds that are less than ideal or slow down the user. The only person that I know on the team who is really focusing on the outliner is @julianeisel and I would be interested to hear his thoughts on this, even though I am not even sure that the current setup was his choice. If there is someone else, perhaps @ThomasDinges or @dfelinto might know.