Page MenuHome

Outliner: Modes & activating cameras or scenes
Open, NormalPublic

Description

Currently, we mix up the concept of selection with switching modes and setting the active camera or scene. For example, when you select a scene, Blender also switches to that scene:


Not only can you not select a scene without switching to it, it's also hard to even see which one *is* the active one.

It's impossible to simply select the scene in the Outliner without also switching to it. The same is true for camera data, and for mesh data it's impossible to select it without switching to Edit Mode. Obviously that's not acceptable, because:

  • Users don't expect that simply selecting someting will also change the mode
  • It will break Properties-Outliner syncing T63991: Outliner - Properties syncing
  • It makes many operations very awkward
  • It's not even very clear which camera of scene is the currently active one.

We can make this whole thing a lot clearer, like so:

We will add a new column on the left hand side:


In here you can click to set the active camera, or active scene:

You can also click this column to switch objects to Edit Mode:

When you are inside Edit Mode, it's also much easier to see which objects you are editing:


And you'll be able to use these to pull in or evict objects from the current edit session.

Even for other modes, it's useful to know which object you are sculpting on, for example:


The left gutter could indicate this.

This gutter could be toggled inside the Filter popover, like the other restriction columns.

Details

Type
Design

Event Timeline

William Reynish (billreynish) triaged this task as Normal priority.

I don't find clear and communicative enough to have an additional column of icons just next to restriction indicators (that can be really crowded already).
I'd dim all data which is not in Edit Mode or change colour of its text and icons to... let's say gray. The point is to make an easy to spot contrast between all the data in and outside the Edit Mode. To visually separate edited data blocks, that an user is focused on at the moment..

I don't find clear and communicative enough to have an additional column of icons just next to restriction indicators (that can be really crowded already).
I'd dim all data which is not in Edit Mode or change colour of its text and icons to... let's say gray. The point is to make an easy to spot contrast between all the data in and outside the Edit Mode. To visually separate edited data blocks, that an user is focused on at the moment..

The text is already grey. And the purpose is twofold: one, to see what you are editing, and 2, to allow for a way to add or evict other objects to and from the current mode.

We could also display these toggles separately like so:

Well, I find Edit Mode as a kind of "local view" of the specific data.
It'd be more clear and elegant to have it this way by my mind:

or like that:

Less cluttered, at least, yet informative enough.
Using bold text and a few percent bigger icons is another elegant way to go.

Thinking of managing modes selection within the Outliner I ask myself a question - do we really need the ObData representation in the Outliner? Is it crucial to visually represent real data structure there? Why do we have to have the Camera Object bold icon with the thin Camera ObData pictogram next to it, even it it serves no purpose? Everything seems to be duplicated - similar shapes of Data and ObData pictograms can be quite confusing at first.
The way Outliner manages data right now makes it really cluttered with information and not easy to read, understand and use. Way too many possibilities and references.
Having in mind the upcoming Otuliner, 3D View Editor and Properties editor synchronization, we may consider further simplification of the Otliner's look and structure. What if we got rid of ObData icons, leaving just the Objects along with other relevant related data blocks (Modifiers, Materials, and so on...)?
The synced Properties Editor will still provide detailed info about ObData of selected Object, but we'd tidy up and simplify the Outliner's window.
The most important thing is, that visualizing and handling changes of the mode via Outliner would become way easier and elegant - the bold orange Object icon would be replaced with the thin green ObData icon. The difference will be clear and noticeable at a glance.

For detailed data structure, we can still use a different Outliner's veiw mode.

Well, I find Edit Mode as a kind of "local view" of the specific data.
It'd be more clear and elegant to have it this way by my mind:

I don't find that particularly clear at all. It's not clear why the other items are greyed out. And you haven't addressed the other purpose of this - which is the ability to toggle objects in and out of the mode.

Thinking of managing modes selection within the Outliner I ask myself a question - do we really need the ObData representation in the Outliner? Is it crucial to visually represent real data structure there?

I'm not sure what this means.

The Outliner includes a hierarchy of data, which we absolutely should not remove - it's one of the main points of the Outliner:

@William Reynish (billreynish) tell me - how many mesh ObData You can bind to an Object? One. Just one. The relation between Object and its ObData is flat. I'd agree, if it was possible to attach several different ObData blocks of let's say - Mesh, Curve, Lattice to one Object. But it's not like that. The shape of an Object's icon already indicates type of ObData attached to it, isn't it? We duplicate information with no purpose.

@William Reynish (billreynish) tell me - how many mesh ObData You can bind to an Object? One. I'd agree, if it was possible to attach several different ObData blocks of let's say - Mesh, Curve, Lattice to one Object. But it's not like that. The shape of an Object's icon already indicates type of ObData attached to it, isn't it? We duplicate information with no purpose.

It's very important to know which obData data blocks are linked to which objects. We aren't going to remove the ability to see other data in the Outliner

In any case, that's neither here nor there, and has little to do with this topic to begin with.

It's very important to know which obData data blocks are linked to which objects. We aren't going to remove the ability to see other data in the Outliner

But You know what ObData is linked to the Object without seing the actual ObData icon - Object with Mesh ObData has bolf triangle icon (ObData = thin triangle icon) and so on.

I think @Andrzej Ambroz (jendrzych) is suggesting to get rid of the inline datablock icons that appears when the item is folded (orange box in image). You can still see the object hierarchy as normal when expanded, so you can still examine which datablock belongs to which object - but it is a little redundant to tell the user that "this light has a light", "this object has a mesh", "this camera has a camera", etc. which is the only thing that the inline icons do.

Personally I think the current approach of showing all datablock icons is good enough and the reasons to change it, while perfectly sensible, are not compelling (but at this point I'm making the derailing of this thread even worse so I'm going to stop now).

To make some contribution to the actual topic: I prefer the first proposal with the edit mode toggle on the right.

Well @tom k (tomjk) got the point. We already indicate the kind of ObData linked to an Object with the Object's icon. No need for an extra datablock representation, since it serves no real purpose other than showing real data structure. I guess it's a relic from the past, when all Objects shared one generic Object pictogram and thus there was real need for another icon just to depict kind of linked Object Data. Things changed since then and we already have individual icon for each pair of Object and specific ObData. Two hierarhy levels in one icon. I can't agree that this is irrevelant to this topic. As far as I understand, we're looking for an elegant way to manage modes within Outliner and my considerations are focused on this issue. @William Reynish (billreynish)'s proposal is easy to implement, but introduces extra information into already crowded space.

My proposal needs more intensive changes, I guess, but results with cleaner UI.
OBJECT MODE (it's still clear what kind of ObData is linked to each of Objects, isn't it?):

EDIT MODE (can You point which data is in Edit Mode now?):


or even better:

O the other hand, @William Reynish (billreynish)'s way allows for indication of other modes as well - Vertex Paint, Sculpt... It's just a matter of the icon used. What bothers me the most is the fact, that the state isn't underlined enough. It should be emphasized a bit more. Like that, for ex.:

or (the cleanest one, in my opinion):

or even:

Just a few points about why I think the datablocks are good and useful. First: An object's datablock can be changed, so it is useful to display this information (mesh data, light data, camera data, etc) from within the outliner. Second, in my soc-2019-outliner branch I allow selection on the collapsed row icons. This will be very powerful with T63991: Outliner - Properties syncing. Without even opening the object data, a click on the green mesh data will open the correct tab in the properties editor. Properties syncing has been high on the list of requests for the summer of code, and I wouldn't want to add it and then remove datablocks from the outliner. If someone feels this is too cluttered, we have the "Object Contents" checkbox in the outliner filter popover which hides all datablocks.

That all being said, there are lots of icons in the outliner, so I do think it would be nice to find a way to toggle in and out of modes without added clutter. I like @Andrzej Ambroz (jendrzych)'s idea of highlighting the objects in edit mode in the outliner. To make it more obvious, we could use the existing row highlights, just with a different color.
To add and remove we could limit outliner selection to only toggle in and out of the mode. This way we could benefit from existing operators (range select, extend selection, box selection) to bring objects in and out of a mode. I also like the idea fading unsupported data elements.

Yes the highlight rows, combined with fading could work well probably, and allow for adding and removing items from the current mode.

When I have time I will update the design task above.

William Reynish (billreynish) updated the task description. (Show Details)
William Reynish (billreynish) renamed this task from Managing modes from the Outliner to Outliner: Modes & activating cameras or scenes.

Hey, while you guys are playing around in there.... you should consider hiding "hide_viewport" and "hide_select" while an Object is in Edit Mode.

It seems odd to me that we can even toggle Viewport Visibility off while in Edit mode as that just stops the very action you are in. And the Selectability toggle doesn't make a lot of sense while in Edit mode either, as that only affects selection of the object, which we can't do in that mode. You can still select vertices, edges, etc so the toggle seems to do nothing while in Edit Mode.

@Harley Acheson (harley) One reason I see to keep the visibility toggle for objects in edit mode is because we now allow multiple objects in edit mode. It may be useful to hide objects temporarily while editing.

The selectability toggle could be hidden in edit mode, but I also don't see much harm in keeping it.

@Nathan Craddock (Zachman) - we now allow multiple objects in edit mode

Yes of course, I hadn't thought about hiding one object while editing multiples.

The selectability toggle could be hidden in edit mode, but I also don't see much harm in keeping it.

Yes, that toggle was less interesting to me. I was mostly excited about the thought of "hide_viewport" because that would give some added difference to the view of that row while in Edit Mode. But without being able to hide that then "hide_select" doesn't matter much.

Oh well, I am occasionally filled full of bad ideas. Especially when short of caffeine. LOL

Besides scenes and cameras I think that we could include activating collections in the left gutter so selecting a collection to rename or move doesn't also activate it. It would also make the active collection more clear (I remember some confusion from users about active collections).

For data like materials I think it is best to keep the activation and selection together. Otherwise with properties syncing the correct material would not be the active material in the properties editor.

I also think the new column would need to be drawn on top of the tree so scrolling horizontally would not hide the toggles.

Now that I have finished my GSoC final report, I'd be happy to start working on this.

It depends what you mean by ‘activation’. It’s a little confusing because we have active objects which should be set via normal selection, but also active scene and camera, which should not be set via a normal selection.

Sorry, I meant activation of UI list data. Materials, Grease Pencil Layers, Vertex groups, etc. I am trying to see how this will work with properties syncing. If I wanted to edit a specific material, I would think clicking the material name would open the proper tab in the properties editor, with the selected material active.

But if we allow that behavior, I can see it being confusing to select a scene (on the name) and expect to edit the scene's data in the properties editor. But if the active scene was not changed (by clicking in the gutter), the wrong scene's data would be shown.

So perhaps clicking on the material name would switch to the materials tab, and then materials could also have an active check in the gutter for consistency.

@Nathan Craddock (Zachman) IMO it's probably ok if selecting a material normally in the Outliner makes that material the active one.

The exceptions are the things that are disruptive, such as changing scenes or active cameras. Those things should not change by simply selecting them in the Outliner.

@William Reynish (billreynish) That's fine and will work well I think.

Another thing that will be improved by fixing mode toggling and activation is walk navigation. Currently walk navigation only selects to prevent mode toggling while walking. It would be much more convenient and expected to move the active element on walk navigation (allowing faster renaming without taking hands off keyboard for example).

@Nathan Craddock (Zachman) Yes, that improvement to walk selection in itself would be a huge bonus.