Layer Manager
Closed, ArchivedPublic

Description

Current Issues

  • Layers can't be named.
  • The number of layers is limited to 20.
  • Layers can't be grouped.
  • Current layer manager has low discoverability - it has no description or icon, takes little space in the UI, and it is highly non-standard.

Solution

Add a dedicated "Layer Manager" window type, or a mode in the Outliner.

GSoC 2016: Layer Manager Proposal

This topic is being worked on by Julian Eisel in his GSOC. See his proposal here: https://wiki.blender.org/index.php/User:Julianeisel/GSoC-2016/Layer_Manager_Proposal

Here is his UI design doc: https://wiki.blender.org/index.php/User:Julianeisel/GSoC-2016/UI_Design

Mockup (PLyczkowski)

EDIT UPDATE:

Description:

These are layer visibility icons:

The equivalent in the current interface:

Rows with a folder icon are Layer Groups. They can contain only Layers, not Objects.
Arrows (like the ones used currently with Panels) are next to Layer Groups, plus icons (like the ones currently used in the Outliner) are for Layers. Differentiating helps distinguish the functionality - Layer Groups are like folders for Layers, they don't contain any data, they are just a GUI construct, so they don't have the tree structure containing Data Block like Layers and Objects (I guess in the mockup objects should have pluses as well). In General the content of a Layer, when you unfold it with a plus, is just like in the Outliner.

The Selectable/Renderable Icons work as follows:

Settings higher in the hierarchy override lower settings, but only subtractively.

So an 'unselectable' setting in a Layer overrides a 'selectable' setting in an Object. An unselectable setting in a Layer Group overrides a 'selectable' setting in all it's Layers.

But a 'selectable' setting never overrides 'unselectable' setting in an element lower in the hierarchy. For example, a 'selectable' setting in a Layer doesn't override an 'unselectable' setting in an Object on that layer.

Same for renderability.

If this is deemed too powerful (a toggle in the Layer Manager restricting selectability and renderability of objects, despite their local setting), the toggles for Layers and Layer Groups can be removed, leaving only the toggles for objects, and replaced with batch operation from an RMB Menu - 'Make Objects Unrenderable', 'Make Objects Renderable', 'Make Objects Unselectable' etc.

----Standard functionality I think should be implemented:

Ability to select Layers/Layer Groups. LMB once on row to select, Shift-LMB to add to selection. This is different to making layers visible - it's purpose is to run commands on layers, and also makes the newly added objects be added to selected layers (ignoring Layer Groups).
Newly created Layers and Layer Groups are created above all selected Layers and Layer Groups, except when a single Layer Group is selected - then ther are created inside that Layer Group on the top.
Drag and drop.

----Blender-specific functionality I think should be retained:

Managing layer visibility (i.e. current square layer checkboxes, not object visibility depicted by eye icons). LMB on visibility icon -> make only this Layer/Layer Group visible. Shift-LMB - add to visible layers. ~ -> make all visible.
It's impossible to turn off layer visibility of all Layers.

----Layer visibility inside groups could work as follows:

Clicking on a layer visibility icon of a layer inside a layer group makes it visible.
Clicking on layer visibility icon of a Layer Group makes all layers inside the group visible. Shift clicking on already visible layer inside a Layer Group turns off it's visibility.
Shift-clicking on a turned on layer visibility icon of a Layer Group makes all layers inside it invisible, while retaining layer visibility of all other Layers and Layer Groups.

----Here is old to new Layer Manager conversion (happening when you open an old file):

OLD MOCKUP:

It would retain how the current system works, while adding some functionality:

  • Click on a square on the left side of the layer's name to show that layer and hide all others, shift-click to add to visible layers. This system works well with a 3d application, since it is a more frequent scenario that the user wants to see only one or two layers at any given time, to save computer resources and reduce viewport clutter. In a 2d application the user usually prefers to see the final 2d output, so the most common scenario is that all layers that will be visible when saving the final image are also usually visible when during the creation of the image.
  • Press ~ to show all layers.
  • A dot on a layer shows that it contains objects. An orange dot shows that it contains selected objects.
  • Double click on a layer's name to rename it.
  • Drag and drop to move layer up and down in the list (just for organizational purposes), and to drop layers or groups into groups, or remove layers or groups from groups.
  • Click on the layer's or group's bar background to select it, and prepare for operations (drag and dropping, Deleting). Ctrl-click to add or remove from selection, shift click to select all layers or groups between the last selected layer or group, and the clicked layer or group (works only on layers or groups that are on the same level of grouping).

Alternatives

  • Add Layer Manager as a submode to the Outliner. Pros: Would be easier to switch between the Outliner and the Layer Manager. Cons: Less discoverability. The outliner already has too much display modes.
  • Make the Outliner and the Layer Manager two tabs of a single window. I'm not sure about the name of this new window.

Handling unlimited layers

Adding unlimited layers would change how Render Layers, Relations panel and Dupli Visibility in the Groups panel would handle them. Here is an example how it would be done in the Render Layers tab in the Properties window:

Here we have the render layers at the top, as currently, and below we have a way of choosing what a layer contains. This is a moment where layer nesting really shines, because a render layer can contain a Layer Group, meaning that each time you add an object to that group, it will also be on that render layer on the next render.

It's also a natural evolution of the way this works currently, so that means less GUI-change-shock.

Other areas would do it in a similar way.

Quick 3d View Access

Currently the layers are accessible in the 3d View window. This currently proves useful when working fullscreen. If the above proposition would be implemented, this would also provide a way to keep the workspace layout simple, by removing the Layer Manager window from it, and using the quick 3d View access button exclusively.

The popup windows would work like this example (you can click multiple times inside popup, and click/hover outside to close):


(click to play gif)

Details

Type
Design
There are a very large number of changes, so older changes are hidden. Show Older Changes

Honnesly I like the idea to have everything in the outliner.

Like you said, the outliner can show the layers, but, that should be possible to move an asset to another layer directly in the outliner.
No need to have two menus to make the same thing.

Personnaly I never place an asset in multiple layers, but I can understand why it's usefull.
You can make several version of an asset withe objects in differents layers.

Hi, I would be happy to test and give feedback during development

one suggestions btw :
The api should give the possibility to overides object/material settings by layer :

For Exemples:
Display mode (box, wire, shade)
cycle Material
samples number
cycles visibility (camera,shadow,diffuse,glossy)
wirecolor

I don't know if it's in or out of the scope of this proposal honestly.

The mock up is very cool, this functionality it will be a big improvement for Blender.
Maya has recently improved its layers rendering, I recommend that you take a look at their news.
https://www.youtube.com/watch?v=AZu-zjtd6PQ

I think the layer manager should be in the outliner. The outliner is for scene organization and inspection, and that's what layers are for too. If layers are a way to organize objects in a scene, then being able to browse objects in the outliner using that same organization seems important. Being able to drag and drop objects into layers in the outliner seems like a logical feature to have as well.

Having objects in multiple layers is something that used to be more important, but with groups now that's no so true anymore. Layers can be used for example to ensure collision or lighting only happens between objects on the same layers, but groups can now be used for that as well.

Removing the ability to have objects on multiple layers breaks backwards compatibility and might affect some workflows a lot, so definitely would be good to get feedback from artists to understand what they use objects on multiple layers for. I do like the idea of clarifying layers as a hierarchy for organizing objects into, and groups as a more loose collection of objects that does not follow any hierarchy.

It might be useful to think about how possible future layer overrides would be affected by this, but adding overrides is way out of the scope of this project.

A point mentioned in another layer manager discussion and which is worth consideration: current nochups and the idea as it is put forward now has the benefit of supporting the layers hierarchies of many other applications. Like Rhino, AutoCAD, c4d, max, modo etc.
This brings great interoperability with it.
Please consider keeping this strength in the planning as it goes forward.

Layers are not just use as a container for a given property like groups would be.

They are mainly used as bricks for a layer set. Layer sets that are numerous and may be animated.
Enabling/disabling of Exclude Layers, Mask Layers, Collision Layers (for RB simulation in viewport, not BGE) can be keyframed.
Actually, we have no way to animate a group content.

But basic idea is that with same bricks at a starting point, we can build several and very different layers sets.
Several render layers sets displayed in render layers tab. But also several lighting sets, collision sets, one per object used in scene.

In current proposal, there is a lack of solution for object layer sets.

Actual groups are just selection sets. They don't express this idea of reusable bricks.
A combinaison of groups is not a set. It is just a selection that can only be stored as another group extending group list.
Replacing object layers by groups potentially means blend files with a group list longer than object list.

But for 2.8, object properties will become nodes.
So,the idea of animateable bricks of a layer set per object could become an animateable nodetree. That would solve mentionned problems.

personally the only thing I use the multiple layers per object for is to keep reference objects or lights visible while I focus on individual layers. This could be replaced by a layer lock that would keep a layer visible until unlocked. I know I could hold down shift and swap layers that way but its just more convenient not to worry about what layer your lights are on.

on the UI side, here's a suggestion; It might be a separate task on its own but I think it provides a logical place to put the layer manager(if separate from the outliner) , so it might be of relevance here, and has several other advantages. the layer manager would be the tab next to the outliner

  1. grouping scene management and settings apart from object properties into separate banks of tabs - makes for a clearer distinction, and also reduces the width needed to see all the tabs
  1. auto focus with a click, no more more constantly scaling the outliner up and down to work
  1. it's completely customization, the mockup is just a suggestion for default, the user could configure his own tabs/editors, even to recreate the current setup if desired. the tabs could also be tied to workspace presets , so that a custom configuration could be made for task specific work spaces. this would (I think) fit in well with the work space presets project planned.

proposal here:https://rightclickselect.com/p/ui/5gbbbc/implement-properties-editor-as-a-customizable-dock

  • I think it would be useful to have a way to sync layer selection and visibility, having to click a small icon to toggle visibility would probably slow down the process.

Layer selection and visibility are two different things. Ex: You want to select only a layer named "Character" to add new object only to it, while still having a layer named "Background" visible. Ex 2: You might want to select layers "Character Old", and "Parts Old" to drag and drop them to the "Backup" Layer Group, while still having layers named "Character" and "Parts" visible.

  • I wouldn't add the layer manager to the outliner whose main purpose is to display scene hierarchy, not editing data.

Keep in mind that I meant adding it as a mode to the Outliner. IMO Outliner and Layer Manager both do very similar things - managing object visibility/renderability/selectability and general organization and finding objects.

  • As @Chris Offner (chrisoffner3d) already pointed out, the layer manager shouldn't list the objects of a layer, that's again the job of the outliner. Instead the outliner could have a layer view mode which would show objects in relation to their layers, but without features for editing them.

It could be only as an option, with layers generally 'closed', like in my mockup. This simple plus (the icon that allows to unfold the contents of a layer) shouldn't bother anyone, while providing a lot of functionality - maybe even allowing the Layer Manager to replace the Outliner for some people.

  • Is it really useful to have the icons to restrict render/viewport visibility and selection in the layer manager? Can't we just leave them in the outliner? (The layer mode mentioned above could be used to allow toggling visibility/selection of entire hierarchies)

As said above, having Outliner functionality in the Layer Manager would allow it to replace the Outliner in many cases. Having to have both the Outliner and the Layer Manager open at the same time to have all of the functionality would make the already cluttered interface even more cluttered.

And also, one more question that should be evaluated:
In practice, is the ability to have an object on multiple layers useful even? Without it things would become quite a bit easier, but if it is useful, it should be kept.

Sometimes it indeed is useful.

@Paweł Łyczkowski (plyczkowski) & @Chris Offner (chrisoffner3d), you both seem really enthusiastic about this project. Are you available for feedback and testing during the development? We'd be happy to have some stakeholder artists on board!

Sure!

Honnesly I like the idea to have everything in the outliner.

Keep in mind that I suggested a mode for the Outliner, not adding layers to the current Outliner. Current Outliner functionality shouldn't be touched by the Layer Manager project.

would be good to get feedback from artists to understand what they use objects on multiple layers for.

I personally use it for versions, but not very often. Ex: If I have one versions of a model that is composed of parts A and B (each part composed of many objects), and second that is composed of A and C, I add A to two layers. That could also be done using Group Instances, but the way Group Instances have to currently be created is so cumbersome that it's not worth it. It can be solved also like that, or that.

It might be useful to think about how possible future layer overrides would be affected by this, but adding overrides is way out of the scope of this project.

  • Is it really useful to have the icons to restrict render/viewport visibility and selection in the layer manager? Can't we just leave them in the outliner? (The layer mode mentioned above could be used to allow toggling visibility/selection of entire hierarchies)

Well what would you manage about layers in the Layer Manager if not their visibility? :)
There aren't that many things that layers are used for, so I'd sort of expect those things to be managed in the thing that's called the 'Layer Manager'.

And also, one more question that should be evaluated:
In practice, is the ability to have an object on multiple layers useful even? Without it things would become quite a bit easier, but if it is useful, it should be kept.

I do suppose it's useful. I don't think it's necessary. I've worked for years professionally in Maya without this feature,

If you do decide to implement this, I think it's important to establish a very clear and intuitive paradigm about layer settings overriding each other in case of conflicting settings.

For example: Item A is in both Layer X and in Layer Y.
But Layer X's viewport visibility is set to OFF and Layer Y's viewport visibility is set to ON.
In this case I suggest that the order of the layers in the Layer Manager decides the order of operations.
I.e. if Layer X is above Layer Y in the Layer Manager, Item A is invisible.
If Layer Y is above Layer X in the Layer Manager, Item A is visible.

Or maybe the order of operations should be the other way around (i.e. top-to-bottom), as is the case with modifiers I believe? In any case it should be intuitive and consistent with the rest of Blender, otherwise the Layer Manager may introduce more confusion than clarity.

@Paweł Łyczkowski (plyczkowski) & @Chris Offner (chrisoffner3d), you both seem really enthusiastic about this project. Are you available for feedback and testing during the development? We'd be happy to have some stakeholder artists on board!

When exactly is the development time? I'd love to contribute my feedback where possible if I'm free during this time. :)

Like you said, the outliner can show the layers, but, that should be possible to move an asset to another layer directly in the outliner.

I would expect to be able to right-click an item in the Outliner and get a "Add to Layer > ..." option. That *and* the option to "Add selected object(s) to layer" in the Layer Manager.

I think it's an interesting idea to approach the Layer Manager with the goal for it to eventually *replace* the current Outliner entirely as it matures. Blender's Outliner is currently quite unintuitive, limited and non-standard in its design, so I for one highly suggest a complete overhaul of it.
If this could be achieved by building the Layer Manager in a way that it could over the course of some iterative cycles take over more and more of the Outliners purposes and functionality in an intuitive and highly artist-friendly fashion, it could eventually replace the Outliner entirely.

Not sure if that's something you'd be open to, just a suggestion I find worth making considering the dire state of Blender's Outliner.

Except that the layers override substractibamente visibility and selection, I do not see that differ too much from the groups. I believe that the layers should also allow overwrite smoothing, and wireframe visibility, and other object properties.

If you do decide to implement this, I think it's important to establish a very clear and intuitive paradigm about layer settings overriding each other in case of conflicting settings.

For example: Item A is in both Layer X and in Layer Y.
But Layer X's viewport visibility is set to OFF and Layer Y's viewport visibility is set to ON.
In this case I suggest that the order of the layers in the Layer Manager decides the order of operations.
I.e. if Layer X is above Layer Y in the Layer Manager, Item A is invisible.
If Layer Y is above Layer X in the Layer Manager, Item A is visible.

Or maybe the order of operations should be the other way around (i.e. top-to-bottom), as is the case with modifiers I believe? In any case it should be intuitive and consistent with the rest of Blender, otherwise the Layer Manager may introduce more confusion than clarity.

The visibility of the object Item A outside the layer membership is controlled in the Outliner and i think it should stay that way. So, it's not a great example. If an visible layer has that object it should be displayed. Currently it's like that.

However, I do understand the problem of possible conflicts between Layer's shading and display overrides (like wireframe). Presently, the Layer Management addon has a wireframe display override. In the case when there's an object on multiple visible layers even if one them has the toggle set on, it will be shown as a it.

The problem of the stack of layers is obvious in 2D applications (with all of them visible). There's a difference. They inherently override each other based upon their stack position > each layer on top covers the bellow one and only if an blending mode or transparency is set, it will allow lower ones to influence the final image. They are opt in. On the other side, in Blender everything influences the image if visible you have to opt out to remove them from the final render/display.

Simple example with all layers visible. If a big plane is closest to the camera so that covers the whole frame, no matter if it is on layer 1 or 20 it would be the only thing rendered. In a 2D app, an 2D equivalent (a 100% opaque layer - normal blending) will show up or not at all depending on the position in the stack and other layers on the export. That makes layers in a 2D image editor more similar to objects than what layers are in Blender (which are more similar to layer groups in the image editors). Of course, WYSIWYG helps a lot. :)

That makes hierarchy intuitive in a 2D app and not so much in Blender (albeit the modifier stack has a tendency of proving the opposite with different results depending on the position - however they still operate all at the same time, they don't exclude the lower elements in the stack apart from breaking things).

One, maybe, better solution in the vein of the differences in how layers work compared to an 2D app is user selection/tagging/highlighting of the layer. In the described case of layer display overrides with objects on multiple layers the settings of an active or highlighted layer will have supremacy. Personally I think, highlighting would be the best option.

I disagree that it's a bad example and suggest that, like in Maya and other industry standard applications, a layer's visibility setting should override the one in the Outliner for a given object if it's invisible.

Basically, 'invisible' overrides everything else.
If my object is in a visible layer but hidden in the Outliner, it doesn't get drawn.
If it's visible in the Outline but in a hidden layer, it also doesn't get drawn.

For other settings that are non-boolean (on/off), like drawing style or whatever else might be controlled by layers, a stack-based order of operations will be necessary to sort out conflicting settings of the same object in different layers in an intuitive manner.

However, it could get confusing because the behaviour between Outline vs. layer visibility setting would be different ("Hidden" always wins) than between different layers (last layer in the order of operations always wins).

So maybe for boolean settings, OFF always wins but for non-boolean, the last in the stack order always wins?

I'm talking about non-cumulative things here (unlike modifiers). You cannot draw a mesh in two drawing styles at the same time for example. You don't draw a mesh as wireframe and default and material style at the same time - but it can be in three layers with different drawing override settings.

Basically, 'invisible' overrides everything else.

That's what I meant by "Settings higher in the hierarchy override lower settings, but only subtractively" btw. Your version is much clearer : )

Per Layer visibility/selectability may be a bad idea in the end - it gets really confusing with Blender's ability to have objects on more than one layer, which should be kept to allow for opening older .blend files (or are there workarounds for that?).

Also, here is how I imagine old to new Layer Manager conversion (happening when you open an old file):

Basically, 'invisible' overrides everything else.
If my object is in a visible layer but hidden in the Outliner, it doesn't get drawn.
If it's visible in the Outline but in a hidden layer, it also doesn't get drawn.

Well, it is already the way it works in blender.

Currently Blender allow to have an object in several layers, the mock up of
Paweł Łyczkowski, maintains this possibility. Is an extension of the current model and looks great.
If the objects were unique for a layer, the next a mock up would make sense.


The two systems seem right, just I think it is worth making one last thought. One keeps compatibly with Blender itself, the other is more similar to other programs.
By the way, I do not see the need to individually access the parameters of each object. It is assumed that the layers serve to treat objects in groups

Hi,
I didn't read through all the comments, so it might have been mentioned before, but I just want to stress that it is really important to have some grouping functionality inside a layer (called Partitions in good old Softimage, and now Collections in the Maya ripoff). This makes it possible to have multiple override materials and properties inside a layer. Here is a screenshot that might explain how it works (otherwise ask, or google Softimage partitions).

Edit2: removed Image and provide a link that explains SIs partitions

Edit: Also while working you have one Layer active, so all visibility options from that layer are applied... if you want to work on another layer, just make that one active. It's a bit like Scenes inside Blender, but that would solve the visibility-override-hierarchy duscussion earlier in the comments.

Ohh yes Thomas, for me it's the perfect solution. With "Active layer" could be possible to preserve the old Blender's funtionalities, and overwrite objects representation.
I would add the possibility to filter objects's visibility by object's name or anything else (subtractively).
I guess the partitions are intended to render layers, not for the 3D viewer, isn't it?
Here a fast mockup.

All that the softimage is doing is integrating the render layers into the layer management directly as the partitions are essentially layers in they're own right. subordinate to the render settings for the layer.
So basically every layer is child to a render layer from the start.

Interesting idea, but it seems that it's more about rendering than organization, which is what blenders layers are focusing on. still it makes a lot of sense to integrate the two in the same manager as they're pretty closely related

Sorry, my bad. I was mixing up layers and renderlayers... personally I find it quite confusing to have both, and I almost never used the layermanger in Softimage which doesn't mean it doesn't have any use cases.
The strength of the Softimage (and now Maya and probably others as well by now) system is, that you can have totally different settings/object-groups/overrides per renderlayer. And renderlayers are build from objects, not from layers. I think this is the most important part, because it gives you absolute freedom in organizing what you want to render.
The most common use case for this is probably the creation of additional RGB-masks for comp (which probably will be obsolete when every renderer is supporting some cryptomatte stuff).
Let's say you have a complex model and want to create a mask for some parts because you really would like to tweak it in comp. Unfortunately all these parts are on the same layer and you can't reorganize the without breaking other renderlayers. So you end up copying stuff and pollute your scene. This is how it works in Blender right now, is it? (I might be totally wrong...please correct me if I am).
In Softimage you would just generate a new renderlayer, which automatically has one Partition that contains all renderable objects. Put a constant black material on this partition, and then create partitions with a red,green and blue material. Just move the objects of your choice to one of the colorMat partitions and you have an nice RGB mask in no time without polluting your scene. (btw, partitions also exist for lights in the same manner, plus you can have totally different environment settings per renderlayer)

This is of course a Softimage fan-boy talking here, but they took this concept into the latest Maya version for a reason!

But is this the right place for this discussion, or should renderlayers have their own thread and be considered a separate thing? I don't want to hijack it, just because I got it wrong in the first place...

@Thomas Volkmann (knekke) what you're saying is totally valid and in fact I was already thinking about merging render layers with regular layers. However, this is not a planned part of my GSoC coding period (yet), since updating the current layer system is the first step to take. Same goes for overrides btw.

Oh and as Brecht said earlier, please don't post screenshots of other software here, we have to be careful about that.

@Julian Eisel (Severin) I removed the Image and posted a link to a description instead. Didn't see Brechts post before, sorry.

So my last take on this before I shut up:

LayerManager

  • Do a new layermanager to where you can sort your scene and set visibility/selectability/renderabilty (viewport drawing mode maybe?).
  • Add options like "create new layer from selection"/"select all objects in this layer"/etc.
  • Make drag&drop from the outliner work.

RenderLayers

  • There is always an active Renderlayer defined, just like with scene, and it's maybe a dropdown selector right next to it.
  • Renderlayers should have their own fileoutput or filename at least
  • You should be able to set a different active camera for each renderlayer
  • probably even have the ability for a custom frame range and other settings as well (in form of a rendersettings override)
  • Inside a Renderlayer you can create layers just the same as with the Layermanager to organize your objects.
  • A layer inside a Renderlayer should probably not be called renderlayerlayer. I call it partition for now... (do we have to find a own word for it?)
  • When switching the active renderlayer all overrides/visibilty settings on the partitions in that renderlayer will be applied
  • A fresh new renderlayer has a default partition that holds all objects. (as you would have a default layer in a fresh scene)
  • "create new partition from selection"/"select...."/etc just like the layermanager plus "create new partition from selection in all renderlayers"/"move selected objects to the partitions where the active object is in on all renderlayers"(linking dialog probably)/stuff like that
  • partitions can have overrides (material, transforms, properties, whatever ...you could have one particle system, but different seed/count/etc per renderlayer)
  • drag&drop from outliner and layermanager

A word on visibility:
There would be 3 ways of setting visibilty for an object: object, layer, partition.
If a object is hidden by one of these, it will be invisible.
I would be cool to see in the outliner/layermanager/renderlayermanager who is hiding the object

I think that's it for my part...

Hi,

I hope I am not too late with my proposal but I found this thread only few days ago and it took me a while to read through the whole discussion and come with my own approach. Anyway here it is:


I made a google document with some text description.
The main problem in the current approach with new layer manager editor (eventually incorporated into the outliner) is that you can't set custom layer visibility for each 3d editor individually from an independent editor. There is no way how to tell the layer manager editor which 3d view you want to affect. This is essential functionality and it should definitely be kept in blender. This means that you will need some sort of layer manager in each 3d view anyway and I think it would be best if this would be the main editor for layers with all the important functionality.
I am very interested in the new layer manager and I would be happy to help with testing during the development.

@Marek Moravec (marek) true but would that not be solvable if these properties were able to be overwritten in the viewport?
So visibility is set globally but could be overwritten in a single viewport to help modelling etc...

@Ejnar Brendsdal (ejnaren): This would be a usable solution but you will end with two layer managers - one in 3d viewport for local visibility settings and one in a separate editor for global visibility setting. They will have the same functionality and very similar UI. Wouldn't it be better to keep them both in one place and just pick if you want to set the global or local values?
Another thing to consider: There is already a grease pencil layer manager with unlimited layers in Blender. Why should the scene layer manager have a different UI (the layout of buttons, separate editor x inside N panel)? IMO the UI should be consistent and the grease pencil layer manager is pretty good and fits into the Blender's UI well.

@Marek Moravec (marek) ahh you misunderstand or I'm not making myself clear. Sorry about that. I don't suggest to have multiple layer managers. The ui proposed in this thread is very much to my liking.

I was thinking a bit more like the way we set keys or drivers on properties already.

Ie. Say you have an object on a layer and that layer is hidden. And say you want a single object on that layer visible in one viewport.

Then find the visibility property for the object in that viewport 'n' panel and press some key (like 'i' for insert key now) to overwrite the layer setting locally.

I don't know. Maybe it's too quirksome...
Local overwrites is a good idea though if a good workflow was found. Probably out of the scope for this GSOC though...

@Ejnar Brendsdal (ejnaren): I think I get it now - you will be able to override the visibility setting of the layer for each object in each 3d viewport individually. I can't imagine how you would manage all the object overrides (?) if you have thousends of objects in your scene.
What I was talking about is this functionality currently present in Blender for years:


Here is an example how this is used:

In the top viewport you have a camera view with global layer visibility so that you can see the final composition. The bottom view shows only a few layers so that you can easily see your cameras so that you can easily pick the right camera and move it in xy plane.
In current blender it is very easy to setup - just disable the 'use global layers' button and switch off the unwanted layers. In my design proposal the process is the same. How would I set this up in the current design proposal?
Just for comparison here is the same view without the local layers settings:

It is very hard to even see the cameras and it is even harder to select them because you will very likely end up selecting all the objects around the camera before you select what you want.


I don't actually care too much if this is in the scope of this GSOC or if this will be implemented later. The problem is that here is a design document that has a serious design flaws and many things are unclear. Still this document is a basis for a new layer system which is an essential feature in blender. I believe that those things should be decided before the actual coding begins otherwise there is a high risk that you will end up with a layer system that would be worse than the current.
Btw. did anybody read the document I wrote? Don't you have any thought about the other issues that I brought up?

@Marek Moravec (marek) i see your point about the overwrites. You may be right about it being too confusing to have it per object and not pose layer as you suggest.
Overwrites would make more sense in linked duplicates. But that is for another thread...
Anyway I have in fact read your document. I agree with some of your points but generally like where the project is already headed.

Only one thing concerns me a little.
The multiple layers per object issue. I see why it's smart to have the feature, but what happens if you want to export to a file format that only supports one layer per object?
Is it mentioned already or has this issue been resolved?

@Ejnar Brendsdal (ejnaren): The main point that I wanted to bring up is that there are some serious problems with the current proposal that can cause big troubles in the future. I don't think that my proposal is the only possible solution but I am sure that the current proposal needs a lot of work to be good and future proof. I am a bit disapointed that you are the only one who is willing to discuss it.
About the mulple layers per object issue: IMO this is absolutely essential decision that should be made first. I can imagine both systems and they both have their advantages and disadvantages but they both need different aproach and different tools to manage them. I can't see how a single proposal can manage them both. I think it would be best to make single layer per object - it is easier to manage, the export import is easier and the only big disadvantage is the compatibility of older blend files. It is also crucial to make a new system for saving the visibility settings for all the layers - I called it 'viewport layer set' in my proposal and it should work very similar as the RenderLayers but you would save viewport visibility settings instead of render visibility.
It is nice to have a layer system with unlimited number of layers but it is useless if you don't have the tools to edit all the layers quickly and efficiently. The current proposal just adds confusion and complexity and removes some essential functionality.
Btw.: There are some very good comments by others (especially by Warren Bahler) but I don't see them being reflected in the original proposal.

Sorry for being so quiet in this task, but there's only so few time for so many things....

Just a quick update for people who don't follow the mailing lists:
Last week I've been visiting the Blender Institute for a layer manager design sprint. Ton wanted to be sure to capture the 'big picture', for getting maximum potential out of the layer manager idea. I worked on a doc since then that's ready for review by Ton (had one finished before, but started over after the design sprint). It is a bit longer but shows the big picture, some non-obvious aspects and proposals for the UI (not too detailed, otherwise we'd easily end up with 30 pages :P).

@Ejnar Brendsdal (ejnaren), what do you mean by 'current proposal'? There have been many proposals on this topic, not sure which one you're talking about.
I did have a (rather brief) look on your document some days ago and I agree about quite a few points. It is a different approach than I have taken, so I'm curious what you'll think about it. I really hope I can publish it within 1-2 days so I can finally focus more on code ;)

@Julian Eisel (Severin) Just to be clear. The document is created by @Marek Moravec (marek). I have just read it 😉

To answer your question on when I refer to the 'current proposal', I simply mean the layer manager as a separate editor, group layers and the mock-ups you have shown. It's just selfish hope that it will benefit the IO between rhino and CAD apps as that is my other main tool.

It may be different now you have visited the blender institute and I am quite sure what you have come up with is well thought through.

Anyway however it will end up it's a great step for the development of blender and I forward to seeing more of it.

@Julian Eisel (Severin): That was meant for me I guess. Thank you for your answer! By 'current proposal' I meant the initial post on this page by Pawel Lyczkowski. I am glad to hear that you prepared a detailed document and I really look forward to see it. I will definitely look at it and comment if I find some issues with it. Untill then there is nothing more to discuss I guess :) .

Bah, my apologies for confusing you guys :S

@Julian Eisel (Severin): By 'current proposal' I meant the initial post on this page by Pawel Lyczkowski.

Added link in the description to Julian's proposal wiki page to avoid (or at least manage) confusion : )

Okay so here is the UI design doc I've been working on: https://wiki.blender.org/index.php/User:Julianeisel/GSoC-2016/UI_Design
Nothing is set in stone and I plan to update it whenever there's a need for it. I'm curious to get your feedback!

Ton is planning to send me some remarks the coming week, after tackling those I'll probably spread it a bit more.

so I read the design doc, very promising, I especially like the rendering and compositing features working together.

the biggest concern that hit me, was the proposal to keep the 'visibility bits' as a layer property. It seems the idea is to use layers as a sort of higher level management for rendering/display, and keep the visibility bits as the working object level visibility management tool. I understand this makes an efficient and fast way of working in the viewport, but I'm not sure its worth the complexity it adds

In the future, with object and viewport overrides, we will have 4 levels of visibility for an individual object eg. Scene Layer, local viewport override, visibility bit, and object. This complexity seems unnecessary, and potentially very confusing. I think the current proposal for hierarchy will be sufficient to organize "sub layer" visibility via the folder structure.

as an alternative why not make a pop up in the viewport similar to the OP which will display only the active layer's hierarchy "siblings", for example: If I am working with a character I can call the menu to quicky toggle the sibling layers inside the character folder like Rig, Proxies, and Mesh. this would be strictly for visibility toggles, and leave the rest of the functions for the main layer manager. basically the same concept, just using the active folder of layers instead of the visibility bits as "sub layer" divisions.

hopefully makes sense, cheers

Reading the proposal, to me it seems a lot of the features are aimed at replacing render layers, but not actually defining how render layers fit in, which makes it difficult to understand the purpose of everything clearly.

In my opinion we should make a clear distinction between:

  • Object layers for organizing collections of objects
    • Control how objects are displayed in the viewport for editing
    • Visibility, wireframe colors, draw types control
    • Object layers can be nested
  • Render layers for organizing and customizing the renderer output
    • Object layers can appear in multiple render layers
    • This is where render engines can register custom properties
    • Render layers can not be nested

With that distinction in mind, some comments on the specifics of the proposal:

Layer Compositing

I have a hard time understanding what this is exactly.

Do we actually need SSAO or DoF settings per layer, is anyone asking for this? Rendering multiple layers with such different settings would have a significant performance cost too. Blending modes and filters make sense for 2D-ish grease pencil layers, but not for 3D object layer.

To me it seems like we should instead have:

  • Generic layer override support for object or material properties (which would include draw options)
  • Compositing nodes support in the 3D view for fancy blending of render layers in the 3D viewport

We might not have that for a while, but I don't think we need "layer compositing" as an extra concept in the design.

Layers and Render Engines

I think renderers should be able to register properties for render layers, but not for object layers.

Viewport as Render Engine

I don't know what it means exactly that the "viewport is going to be handled as a regular render engine".

At least with the way current render engine API works, it's not a good fit for the viewport. Having two render engines (e.g. Viewport and Cycles) active at the same time does not fit the current design either. It wouild be good to have a realtime render engine as a choice in the render engine menu, so that e.g. F12 renders that way. But the viewport still needs to operate outside of that too.

Scene vs. Local Level

I think we should only allow selection of a single render layer per 3D view. That way users can create, name and manage these object layer subsets in the layer manager, no extra UI needed. Being able to share object layer subsets between 3D views, and name and store them could be convenient too.

Perhaps this is abusing the concept of render layers too much though. But one way or the other I think that the UI for managing these object layer subsets should be in the layer manager, not the 3D view.

Grease Pencil Layers

I kind of like the idea of having grease pencil objects and handling grease pencil layers in a more unified way in the UI. But I think we have to be careful about overloading the concept of object layers too much. We should not pretend that 3D object layers can be composited just as if they were 2D grease pencil layers.

Hierarchy

In my opinion the hierarchy should be such that objects are placed in a single object layer, and as such there can be no object layer conflicts with overrides. For render layer overrides, with objects appearing in multiple render layers, there should also be no conflict because each render layer would be rendered separately.

Regarding top-to-bottom or bottom-to-top order, this makes no sense to me for 3D object layers. With compositing nodes you might blend them in a particular order, but I don't think the layer manager should provide any tools to reorder 3D object layers, they should just be sorted alphabetically.

Maybe render layers could have an order, and that's where grease pencil compositing fits, but I'm not sure.

Mode Conflicts

Maybe just automatically exit the mode when the active object's layer becomes invisible? I would not attempt to have one active object per layer, it's more hidden state that users need to be aware of.

I really like the design doc but there are many things that I find problematic:

Visibility bits
As already mentioned by @Warren Bahler (russcript) this adds unnecesary complexity but does not enhance usability - this means that everything you could do with the visibility bits you coud do with the object layers as well. Now you propose two different systems doing the same thing. I understand that this is the way how to keep old files compatible but AFAIK this new layer system is meant for Blender 2.8 so the files won't be compatible anyway. The only good thing on this is that you can set the number of bits to 1 and not to use the visibility bits at all.

RenderLayers
I have to disagree with @Brecht Van Lommel (brecht) here. We should understand the RenderLayer as a container that contains some layer property values (render visibility, render masking, etc.) that affect rendering. The user sets the property for each layer and then saves it as a preset (called RenderLayer in Blender). The user can then use different presets to render the scene with different layer visibility settings. This concept works well and IMO it should be incorporated into the current design by @Julian Eisel (Severin) . It would be best to move it from properties editor into the new layer editor because this is the place where you can easily set the properties of each layer.

Local layer settings override
This is absolutely essential feature of the layer system. IMO it is much better to make the local layer independent from the main layer manager (I think it is good enough to edit just the visibility per viewport) because it allows faster editing. The main task that I use all the time in current Blender is soloing the layers in the local viewport (so that I don't mess up my render settings) and I believe that soloing layers by using override would be a bit more complicated. There should also be a button to enable the local settings so that you can quickly switch back to the global settings.

I also not fan of preserving 'visibility bits'. This will be very confusing and super error-prone. While managing scene users must not only take care of layers but also set up this visibility bits. This is basically forcing users to do same task twice, every time he move objects between layers. We can just use sub-layers for similar behavior but make everything clear, intuitive and familiar.

I can easily imagine common issue if we leave those dots. User enable visibility of single layer and see that there is nothing in the viewport, he decide that layer is redundant and delete it. But in fact there was objects on this layer, hidden by visibility bits system.

Instead of brute force gluing old visibility bits to new system we should think of tools for working with layers within 3Dview.

I like how the Layer Settings are designed in the doc, GUI-wise.

Compositing Layer, changing compositing settings of multiple layers at once

If this indeed is needed, and possible to do, how about utilizing Layer Groups for this? Insert all the compositing settings in to the Layer Settings area of a Layer Group?

Switching Blender’s top-to-bottom convention to the bottom-to-top

Huge +1 to this. (For those that haven't read, I wrote about it at length here)

A simple solution would be to just switch to object mode and deactivate the active object if needed, whenever there’s a mode conflict. Alternatively, each layer can store an active object and a mode for it. In example above, the previously active layer will be activated again and the active object of it will be switched into the mode it has been in earlier (object mode by default).

I'm in favor of the first solution. Not many people know anyway that the modes are local to objects, and not global (with the exception of the pose mode).

Is support for objects on multiple layers still useful? (Probably most urgent question)

I would vote no. In the case of importing older files, how about the object will be placed in the layer with the lowest number from the layers it's on? So if something is on layer 1, 2 and 3, it will be placed on layer 1.

Do we want layer grouping?

I would say yes, especially if they would also be used for compositing (see above).

Visibility Bits.

Also not a fan. Seems more dictated by nostalgia than how it fits in the design : )

Alternative to Visibility Bits Switcher:

A scrollable layer list that provide an instant tooltip on hover with layer name?

Local layer settings override

Hmm, I fail to find usecases for this that can't be achieved using Local View (which is also local to the editor). Examples please?

Couple of questions regarding the doc:

Is there an Active Layer where new objects are added, and how is it selected?

Does layer visibility work the same as in current Blender, so clicking on an eye icon shows that layer while hiding every other layer, or like in Photoshop, where clicking on an eye icon toggles that layer visibility, and alt-clicking hides every other layer?

The lock icon is making the objects on a layer unselectable, overriding their per-object setting, right?

Local layer settings override

Hmm, I fail to find usecases for this that can't be achieved using Local View (which is also local to the editor). Examples please?

I posted a typical use case for local layers earlier in this thread:

@Ejnar Brendsdal (ejnaren): I think I get it now - you will be able to override the visibility setting of the layer for each object in each 3d viewport individually. I can't imagine how you would manage all the object overrides (?) if you have thousends of objects in your scene.
What I was talking about is this functionality currently present in Blender for years:


Here is an example how this is used:

In the top viewport you have a camera view with global layer visibility so that you can see the final composition. The bottom view shows only a few layers so that you can easily see your cameras so that you can easily pick the right camera and move it in xy plane.
In current blender it is very easy to setup - just disable the 'use global layers' button and switch off the unwanted layers. In my design proposal the process is the same. How would I set this up in the current design proposal?
Just for comparison here is the same view without the local layers settings:

It is very hard to even see the cameras and it is even harder to select them because you will very likely end up selecting all the objects around the camera before you select what you want.

In this case you could select all the objects on those layers and then enter the local view but what if you have restricted selectability for those reference floor plans? How do you push them into local view if you can't select them?

Another usecase is soloing the layers vithout affecting the global layer visibility settings - In camera view you usually need to see whole scene without the reference and support layers. In the second view you can solo a layer with furniture to be able to easily sellect the chair you want to edit, then you can enter the local view to hide other furniture in that layer and edit the chair. You can still see the whole picture in your camera view. This is a quick and effective workflow that is currently inside the Blender.

I posted a typical use case for local layers earlier in this thread:

Thanks, but the example you provided can be achieved using the View > View Global/Local setting.

I was thinking that a good example where Local Layer Settings Override would be needed would be if you want to have a viewport for fast playback, so you override most layers in it to wireframe, except main character for instance, and viewport for editing next to it, where everything is solid/textured... but then again playback happens in all viewports.

'Lock camera and layers' is so badly named btw, and has such a bad tooltip. It has nothing to do with locking, and everything to do with having local settings for layer visibility in the viewport you turn it off.

@Julian Eisel (Severin)
So there are 4 places where you set object display mode - main viewport display mode, layer, object (max display mode), and local layer override? That seems a lot...

I posted a typical use case for local layers earlier in this thread:

Thanks, but the example you provided can be achieved using the View > View Global/Local setting.

I don't know if my english is so bad or what is the problem in comunication, but I know how to use the View Global setting and you cannot use it in the usecase I showed you. So here I try again:
Imagine that you have an object that has locked selectability (you can't select it). How do you view it in the Local view if you cannot select it?

The other usecase is also quite clear example of a situation where Local view is not a solution. If you have many object in the scene, selecting one you want to edit is almost imposible. That is why you need to solo a layer to reduce the number of models in the scene - then you can select the needed object and then you can enter the local view to edit it.

Imagine that you have an object that has locked selectability (you can't select it). How do you view it in the Local view if you cannot select it?

Oh, sorry, I wasn't replying to that, your english is fine. The answer: currently you can't, and Local Layer Settings Override would be a solution to all that, but I'm not sure if that wouldn't make the number of places where you set types of display too high (4).

As for the local view override, the solution @Brecht Van Lommel (brecht) proposed is pretty solid: allow a viewport to display a single render layer, as well as in the future, the viewport compositor output. A render layer can contain both the viewport display overrides as well as the render engine settings as needed. essentially, if a viewport is a renderer, then it makes sense to use the render layers to control their output.

In the viewport a dropdown can quickly switch between full scene layers, single render layers, or viewport compositor output. this eliminates the need for a second layer manager in the viewport but still offers a way to customize individual views. This would also be useful to test render layers output in rendered viewport mode.

this way, for example an animator could have one viewport+ render layer drawing a stripped down scene for working and another displaying an full openGL camera render piped through the compositor for effects.

we may have to wait for the viewport compositor nodes to get advanced control but I agree its probably better than trying to integrate "FX layers" into layer manager for now.

Don't understand everything guys, sorry, but for the render layers, why not use nodes instead of layers ?

You add a tag to a mesh or group of meshes and connect this tag to a render pass. that would also work for AOV's and it's dependant from layers who are there to manage a big scene.
I would love to have tags in blender, it's really usefull and works with nodes since the 2.8 will be full nodes.

Viewport as Render Engine
At least with the way current render engine API works, it's not a good fit for the viewport. Having two render engines (e.g. Viewport and Cycles) active at the same time does not fit the current design either. It would be good to have a realtime render engine as a choice in the render engine menu, so that e.g. F12 renders that way. But the viewport still needs to operate outside of that too.

The two render engines are conceptually the same though, from a user perspective. A non-interactive OpenGL renderer for final shots should be set up (in the UI) similarly to Cycles whether or not they work the same in the code.

We might need to start calling the interactive 3D view the "Viewport" and the non-interactive renderer something else to avoid confusion. They're different use cases built on the same technology.

Regarding top-to-bottom or bottom-to-top order, this makes no sense to me for 3D object layers. With compositing nodes you might blend them in a particular order, but I don't think the layer manager should provide any tools to reorder 3D object layers, they should just be sorted alphabetically.

Render passes in the viewport certainly will have an order, but this is independent from layers as grouping. All visible objects on visible layers are rendered into the same space. The order of objects within one pass is arbitrary.

I don't understand the unification of Layers (for grouping objects) with Render Layers. To me they seem like totally separate topics.

As for the local view override, the solution @Brecht Van Lommel (brecht) proposed is pretty solid: allow a viewport to display a single render layer, as well as in the future, the viewport compositor output. A render layer can contain both the viewport display overrides as well as the render engine settings as needed. essentially, if a viewport is a renderer, then it makes sense to use the render layers to control their output.

In the viewport a dropdown can quickly switch between full scene layers, single render layers, or viewport compositor output. this eliminates the need for a second layer manager in the viewport but still offers a way to customize individual views. This would also be useful to test render layers output in rendered viewport mode.

this way, for example an animator could have one viewport+ render layer drawing a stripped down scene for working and another displaying an full openGL camera render piped through the compositor for effects.

we may have to wait for the viewport compositor nodes to get advanced control but I agree its probably better than trying to integrate "FX layers" into layer manager for now.

I failed to understand that solution by @Brecht Van Lommel (brecht) after first read (sorry for that). Now I finaly get it and I think it is a great way how to keep all the layer settings in one place. It also covers my two usecases that I mentioned earlier and also solves the problem mentioned by @Paweł Łyczkowski (plyczkowski) that the layer visibility would be set in many different places.
My only thought: Instead of integrating the viewport overrides into the RenderLayers wouldn't it be better to make a separate vieport RenderLayers that would only store the viewport setiings? I don't quite like the idea that I have one big list of Renderlayers, some of them affecting the viewport and some of them for the final render.

There are a lot of ways people can use (and will use) layers. When I worked with Julian on the design we looked at it from many angles and tried to find a good middle ground that will satisfy most use cases, while keeping sufficient compatibility with the past, and especially supporting how the viewport in 2.8 will work and how I envision workflow (and workflow configuration in general) to work.

By keeping a separation between 'visibility layers' and 'render layers' we will run quickly into very nasty design problems in 2.8. I prefer to drop this separation and unify that. That means that conceptually, the new Layer type in Blender will resemble more that of a Photoshop or Render layer. You will use it to control the viewport (the active renderer).

With advanced viewport render engines coming, a lot of interesting tools for view/rendering/editing will come available this way.

I also know from practice that configuring layers for a render nearly *always* conflict with how artists like to configure the layers for work on characters, for scene layouts, for modeling, environments, lighting, compositing, etc. This usually gets solved by creating new scenes with own layers and link in groups or link other data. For each step in a workflow layers can mean something else (you have the freedom organize data in a way it draws best for you). If final render can use the same layer concepts in Blender as everywhere else, you make things nice clear. And especially: we get ready for the novel concept that in the future viewport renders will be used for 'final' much more.

A layer should not (really, think about the implications) be used as a way to manage assets or collections, that is a completely different project (talk to Bastien). Layers should also not be linked around or be copied or shared. They're properties of a Scene and and a way to configure your display (or render). That's it. And powerful it can be that way! :)

So why keep the old bits? Because these are the simplest and fastest way to manage visibility flags. I'm afraid that the practical overhead of managing the new (powerful) layers will annoy a bit too much if you just want to manage visibility for a number of objects that belong together quickly. I might be wrong though, but this is something we should test and decide based on experience. (Note: Keeping the old bits is not more work, in contrary its a nice way to migrate stuff).

So why keep the old bits?
this is something we should test and decide based on experience

We'll have to wait for the prototype then.

I think there needs to be some data structure to organize objects, one that persists across scenes. Maybe that's the role of groups, or another concept that does not exist yet, but layers are used for that currently, and if they only exist within a single scene that won't work anymore.

If you have separate scenes for modelling / animation / rendering, then it should be possible to add an object in the environment in the modelling scene, and then have that show up automatically in the animation and rendering scenes as well, in the appropriate layer. Having to manually synchronize layers across such scenes would be a pain.

For rendering, you typically have a small number of render layers. Both because each render layers adds extra time and memory to render, and because having many render layers quickly becomes unwieldy for users to manage in the compositor, if they want to do any compositing at all. In many cases a single render layer is enough.

I would argue that also in a rendering scene, you want to have a finer grained data structure to organize objects in your scene. Something that is not coupled to the amount of render layers the render engine needs to deliver, because if you have a single render layer then only having a flat list of objects is difficult to navigate.

For animation, say you're animating two characters over a background, and you want to quickly show/hide those. Would you put those in 3 separate (render) layers? And would Cycles or the viewport renderer then be expected to render those 3 (render) layers into 3 different buffers? Or would you use groups or something else for that kind of organization?

I think there needs to be some data structure to organize objects, one that persists across scenes. Maybe that's the role of groups, or another concept that does not exist yet

Something like this perhaps? - https://docs.google.com/document/d/1ScPMbHv8WRCU2znB7IU2l-W9hH-NLs5weQKLkjqmgpA/edit#heading=h.k20w9k3djv7c

If you have separate scenes for modelling / animation / rendering, then it should be possible to add an object in the environment in the modelling scene, and then have that show up automatically in the animation and rendering scenes as well, in the appropriate layer. Having to manually synchronize layers across such scenes would be a pain.

I don't want an automatic update of my animation and rendering scenes each time, I will add a primitive while modelling.
I just want an update when my asset is finished with meaningful proportions for the animator and lighter.
Anyways, it means a conscious and manual update.

During modeling process, you can add primitives just to use them as a gabarit and put them on another layer than edited primitive. You can model a complicated part at a big scale and reduce the scale when the part is achieved. You can keep a duplicate without applying its modifiers in an hidden layer to be able to retrieve first steps of modeling session.

During rigging process, you will do several iterations of a rig trying different and complicated armature with many constraints before funding the smoother and simpler solution. You will have to hide parts of your model.
Custom shapes of bones are stored in an hidden layer.
This have no relation to rendered scene.

Layers are a lot easier to manage through visibility bits than groups for a temporary trashcan of things to hide.
Visibility bits don't influence selection like Hide operator does.
Probably creating a container to hide would be a good alternative.

But common work should not destroy the work of the lighter searching the best renderlayer set.

For rendering, you typically have a small number of render layers. Both because each render layers adds extra time and memory to render, and because having many render layers quickly becomes unwieldy for users to manage in the compositor, if they want to do any compositing at all. In many cases a single render layer is enough.

Of course, people will prefer to deal with the lowest number of renderlayer.
But it means that they are creating renderlayers when they did not find any other alternative.
It means that their renderlayer set is always important and should not be mess up by other manipulation.

@Brecht Van Lommel (brecht) , the way I understood, is that the render layers are basically containers or groups for the normal layers, containing render properties, and passes, and display overrides for the layers they contain. they don't actually set layer visibility, that will be determined by the layers themselves.

in that case by default all new layers will be children of the first render layer until the user creates another. I don't see the difficulty in switching individual layers for characters here? there is no need for many render layers.

the normal layers should be able to be included in multiple render layers, so the user could create for example, a render layer for the viewport modeling, one for Cycles, and one for low poly animation playback. To keep "viewport" layers from exporting to cycles, we just have the normal render flag set to viewport, external, or both.

It is sane design to separate the data side of things (assets, objects, scenes, groups, referencing and linkage) from the display organization of things (layers). The fact we were using bitflag layers in the past to organize things was always a weak design (physics, metaballs)

I am running design ideas back and forth with Sergey and otehrs for how to formally treat DNA data, scene data (depsgraph controlled), and render engine date for 2.8. Will come with a write up asap. It will make clear how layers fit in well.

Thanks for the diagram, I won't comment on the overall design of that here since it would lead us off topic.

I agree making render layers a core part of the viewport can be very powerful. But it's still not clear to me how making object layers the same as render layers will work in actual workflows.

The diagram says each layer can optionally be rendered separately. How would that work specifically? Nested layers, objects being members of multiple layers, a boolean toggle per layer that makes it render as part of a special global layer, ....?

Since USD is being mentioned in the diagram as well, some notes about USD layers:

  • Can have sub-layers (nesting)
  • Are not tied to scenes, they are reused across scenes
  • Do not correspond to render layers delivered by the renderer

Different departments will reference and compose layers created by other departments, adding to and overriding data in those layers. Rigging, animation and physics departments would reference the layer from the previous department and create a new layer adding a rig, animation or physics simulation.

Note that they make the analogy to Photoshop layers, but combining USD layers is not done through compositing rendered layers, it is about combining data before rendering. So if we provide some kind of USD compatibility, a Blender layer as proposed and USD layer would be different concepts.

Ton Roosendaal (ton) added a comment.EditedJul 21 2016, 1:43 PM

USD layers are (entirely) different concepts than what we have working in Blender currently. If we would redesign Blender's animation system that way, then yes - there's a need for 2 different "Layer" systems.

It's very interesting to investigate, but it was not the scope or topic of the layer editor. We don't even know yet what to do with USD and Blender (probably only export and import).

USD layers are integral part of a functional scene definition (i.e. independent of display) and can be used to link to the data across scenes/files (like Blender groups now) and can define multi-layered data operations on models, for animation control, for overrides, etc. Really awesome stuff, but Blender doesn't have this functionality, and we'll have to make a number of big design steps before we will.

I agree we aren't ready for USD at all and that implementing USD layers is out of scope here. Just wanted to clarify this distinction since the diagram is not explicit about it.

I will be on a Siggraph Pixar lunch where USD gets launched, will talk to them about how Blender works and what they'd advise to us. I think their design doc is really great, but it's oriented at big studios with mixed software pipelines. We can make sure Blender fits in well though.

Thanks for the feedback. Read the comments carefully and noted some interesting comments. I think it's definitely time to make some preliminary decisions, seems like we agree about the following points:

  • Visibility bits: We'll try it first to see if it's useful in practice.
  • Mode Conflicts: Switch to object mode when there are conflicts.
  • Support for objects on multiple layers: Not needed.
  • Layer nesting/grouping: Yes.

Render Layers

My opinion on this is: Either we manage to integrate render layers really well with object layers, or we keep them completely separate (e.g. Maya completely separated render layers from their display layers in Maya 2016 - turned out to work quite well too). In the end, what matters is the complexity and flexibility it brings for the users.
TBH, I'm having a hard time imagining how a nicely merged system would work, but I think I have an idea that could work quite well:
Render layers are indeed basically presets, so maybe one solution would be to handle render layers more like presets. But we could take it even further: Layer trees (the hierarchical list of layers) could be (unlinkable) datablocks so you can have multiple, independent layer trees. It would be possible to copy them and add new clean ones (with all objects on a default layer). That way you can tell the viewport and every other render engine which layer tree datablock to use and you have a big pile of flexibility. It would also be consistent by using an existing approach.

This is in the task description, but maybe I'll provide some more info on this. My opinion is that what you render, and what you want displayed, are very often entirely different - that's why merging these two in any way, as mentioned here for example:

I think we should only allow selection of a single render layer per 3D view

will be limiting, and that the current separated system is in the right direction. The way to build on it with unlimited layers could be done like this:

So, here we have the render layers at the top, as currently, and below we have a way of choosing what a layer contains. This is a moment where layer nesting really shines, because a render layer can contain a Layer Group, meaning that each time you add an object to that group, it will also be on that render layer on the next render.

It's also a natural evolution of the way this works currently, so that means less GUI-change-shock.

But we could take it even further: Layer trees (the hierarchical list of layers) could be (unlinkable) datablocks so you can have multiple, independent layer trees. It would be possible to copy them and add new clean ones (with all objects on a default layer). That way you can tell the viewport and every other render engine which layer tree datablock to use and you have a big pile of flexibility. It would also be consistent by using an existing approach.

This is IMHO a bad idea. Here is why:
The layer system is especially useful for heavy scenes with hundreds and thousands of objects. It would be extremly time consuming if you have to assign every single object to a new layer every time you make a new layer tree. It would be also very difficult to remember which object is on which layer because you could have many different trees. If you decide to copy the layer tree and keep them the same it would be very dificult to propagate the changes from one tree to another.
It also wonder where the new objects will be placed. You will need to place them in a single layer in each individual layer tree - you can end with many different trees - each one with a different active layer.

Final note - if a user needs the extra flexibility of this system he can always use Scenes for that - It is IMHO better to have multiple scenes with linked objects and a single layer tree per scene than having single scene with different layer trees.

This is in the task description, but maybe I'll provide some more info on this. My opinion is that what you render, and what you want displayed, are very often entirely different - that's why merging these two in any way, as mentioned here for example:

I think we should only allow selection of a single render layer per 3D view

will be limiting, and that the current separated system is in the right direction. The way to build on it with unlimited layers could be done like this:

Render layers are indeed basically presets, so maybe one solution would be to handle render layers more like presets.

Imho the best way out of this is to introduce presets for the layer tree. Each renderer (and viewport render) would have its own presets with only the values that are relevant to the respective renderer - this means that the viewport visibility and selectability would be in 'viewport layer presets' and the render visibility, exclude and mask (or other settings) would be in the 'render layer presets'. Those presets would be placed inside the new layer editor. You could assign a single viewport layer preset to each viewport or you could make a render queue and asign a single render layer preset to each render task in the queue.

This comment was removed by Kurt Kuschinski (Kukuschi).
Aaron Carlisle (Blendify) raised the priority of this task from Low to Normal.Sep 4 2016, 6:46 PM

Quick update on the render layer vs. object layer discussion - I started a new thread in the bf-viewport mailing list since this is a quite important topic for the new viewport. We might have to open a separate design task for it though.

I believe we can close this now that Collections are mostly implemented? This no longer applies.