Outliner: Mode Toggling #68498
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
12 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#68498
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Currently we mix up selection with other actions like activation and mode toggling. This makes it unclear what action(s) will occur when you select something in the outliner. A simple solution is to add a new column on the left of the outliner to activate data and switch object modes. This task has two parts, data activation and mode toggling.
Data Activation(currently on hold)This still has some merit, but needs to be rethought for the design. Mode toggling is working fine.
There are certain types of outliner data that when selected, make a larger change in Blender. These "disruptive" types are Collections, Scenes, and Camera Data. 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 collections and camera data. If you want to select a collection, it always becomes active. This mixing of selection and activation is confusing, and it also makes it unclear which data is active.
Mode Toggling
Since Blender 2.80, edit mode and pose mode support multiple objects in the mode at a time. Currently the outliner supports mode toggle for these types which makes it easy to add or remove objects while in the object mode. However, this feature is hidden, and interferes with selection as mentioned above.
For example, to bring an object into edit mode, the object data must be selected and ctrl must be held to extend the objects in the mode. Obviously that's not acceptable, because:
When not in object mode, icons can be drawn to the left of objects that allow adding and removing from the mode. For modes other than edit and sculpt, these will allow easy switching of the current active object. For example, you can click the sculpt mode icon next to another mesh to swap to sculpt mode on that object. This last example is currently not possible to do in Blender, and would be a useful feature to add.
Progress
The current implementation (in the
soc-2020-outlinerbranch) looks like:We are using radio icons for data activation. In the past we used a dot for inactive, and a checkmark for active. One current issue is that the icons look the same between cameras, scenes, and collections. Using the camera, scene, or collection looks too busy, so more work may be needed here.
Something that we currently do is draw the data activation toggles in the different modes. I think it may look better to hide them when in an object mode.
Also, right now the icons for objects not in the interaction mode are drawn dim. In the past we used a dot, which I might prefer because it shows more clearly the difference. The faded icon lacks contrast.
We could also draw a vertical line to separate this column from the rest of the outliner
Added subscribers: @WilliamReynish, @natecraddock
Added subscriber: @jendrzych
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:
{F7657229, size=full}
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.
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.
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:
@WilliamReynish 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.
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.
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.
Added subscriber: @tomjk
I think @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 @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. @WilliamReynish'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, @WilliamReynish'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-outlinerbranch I allow selection on the collapsed row icons. This will be very powerful with #63991 (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 @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.
Managing modes from the Outlinerto Outliner: Modes & activating cameras or scenesAdded subscriber: @Harley
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 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.
@Zachman - we now allow multiple objects in edit mode
Yes of course, I hadn't thought about hiding one object while editing multiples.
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.
@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.
@WilliamReynish 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).
@Zachman Yes, that improvement to walk selection in itself would be a huge bonus.
Added subscriber: @DuarteRamos
Added subscriber: @Cedch
I am currently working on implementing the left column and buttons for this task. I have already separated this behavior from selection of datablocks. For data activation, this is relatively straightforward, but mode toggling needs some thought and decisions:
With this column being optional, all the features should be accessible from the context menu, i.e. right click on a collection to set as active collection. The context menu has options already for mode toggle, but they are very broken. With good code design, adding a context menu for mode toggle should be straightforward once the column is finished.
We should support more than only edit mode toggling. The outliner object data already supports edit mode toggle, and we also allow pose mode toggle for armatures. At the very least this behavior should be preserved, but supporting sculpt, texture paint, etc. would also be very useful because not every user does mesh editing/animating. For example, let's say we want to add support for sculpt mode toggle. When the active object is already in sculpt mode, it is easy to show an icon to toggle sculpt for supported objects.
But if we want to allow entering any interaction mode from the outliner, this becomes more complex. The first click on the button could create a menu to choose which mode to enter, then once in any mode that isn't object mode, the buttons are used
Another main goal of this design is to make it easier to add and remove objects from an interaction mode. When in any mode other than object mode, clicking the mode toggle button of a non-active datablock would bring it into that mode, and to end the interaction mode, the active object can be toggled.
This column will show in the View Layer display mode, should it also be visible in Scenes view mode? I don't think any other outliner view modes would make sense to support this column.
Which level should the icons show on? For most objects this is simple, it could show on the same level as the object itself. For armatures this is more complex because we have the Armature and Pose sub-datablocks that are currently used for mode toggling.
Finally, this column needs a simple name to be used from the UI (for the checkbox to disable).
If I understand correctly, from the description it seems you plan to make this mode toggling work on multiple selected objects at once.
Maybe the code handling selection could be made generic enough to be extended to other features of the Outliner.
Main candidates I was thinking was visibility/renderability toggles, so pressing the eye icon would toggle all selected objects, rather than just the clicked one.
Visibility toggling isn't even that much of a problem because most of the time one can just click-drag over a bunch of icons, if they are all in sequence. The most desirable use-case for this would be for keyframing visibility/renderability properties.
Since those can't be performed in the viewport and currently doing so from the outliner only affects a single object at a time, animating visibility for lots of objects is chore. Being able to keyframe visibility for all multiple objects at once in the outliner would be a very desirable quality of life improvement.
I've enabled the column in the View Layer and Scenes view so far. The View Layer mode already has a left column because it includes the space for an expand/collapse toggle) but it isn't shown. I think having two left columns looks silly (see picture) so I think the best plan is to leave the normal column, then shift the tree to the left when the toggle/activate column is disabled.
The only use for the existing left column in view layers mode currently is selection, but there is plenty of other space to select or start a box selection so I think this decision will be fine.
@DuarteRamos I actually had not made plans to include the current selection when toggling modes. The idea is the icons will show and you can toggle the modes by clicking (also click+drag). It's good to consider that as a possibility though.
I have finished the first pass of implementation in the
soc-2020-outlinerbranch. Currently the data activation icons draw in object mode, and the edit mode toggles only draw once the active object has been brought into edit mode. See the video for the current behaviorleft_column_demo.mp4
I decided to only draw the mode toggles when not in object mode to reduce visual clutter. I think this decision is for the best. I think users will rarely want to enter a mode from the outliner, but the outliner can be used to add and remove objects from edit mode easily once in the mode. Additionally, it didn't make sense to draw the collection/scene/camera toggles in edit mode.
The video shows one current limitation. The active object stores the edit "session" in a sense. Once the active object is brought out of edit mode, all other objects in edit mode are also toggled back to object mode. While technically possible to choose a different active object and leave the remaining objects in edit mode, this doesn't align with the current design in Blender; active objects are never chosen arbitrarily.
Added subscriber: @Imaginer
@Zachman Interesting video, however I find it to be a bit visually confusing and inconsistent. I know it's still early days, but here are a couple of thoughts.
In object mode, there is nothing to differentiate between the active collection and the active camera, and depending on the scene setup these icons could be very far away from their collection/camera (even at this distance I find it difficult to discern what the icons are referring to because when focusing on the new icons the rest of the information is outside of your visual focus).
In edit mode, all of the object mode data disappears which is visually jarring. And I know you're still working on mode toggling, but it feels disjointed that you can only toggle edit mode when in edit mode, and because of the distance between the new icons and their objects I think it could be hard to quickly find which belongs to what in more complex scenes. I do like that when you're in edit mode only the icons for objects that can be added to it are shown. Maybe if you greyed out the active icons when in edit mode rather than removing them it would help it to be less visually jarring?
Hopefully this helps!
Added subscribers: @ideasman42, @brecht
@Imaginer thanks for the feedback! It has been proposed to use camera/scene/collection icons for the active data toggle, but that repeats the same icon in the row too many times. We are trying alternatives right now. I definitely could be doing some dimming of the active data icons in edit mode though.
@ideasman42 @brecht I was talking with @WilliamReynish about the mode toggling in this column (and in the outliner currently). It's easy to use the outliner to add and remove objects from the current multi-object edit mode with one exception. When removing the active object from edit mode all the other objects are removed. Of course, this makes sense because the current design relies on the active object in edit mode. William and I were thinking about possibly choosing a new active from the current objects in edit mode when the active is removed from edit mode. Picking an arbitrary active object isn't (ever?) done in Blender, so that is why I'm asking you about your thoughts on this.
On one hand, its easy enough to select a new active object from the outliner while in edit mode, then remove the old active. But in the limited feedback from users on my branch, some are already confused why toggling the active removes all from edit mode.
Outliner: Modes & activating cameras or scenesto Outliner: Mode toggling & activating dataI updated the original description with more details and examples of the current implementation. This part of the project is nearly finished besides some small edge-cases and UI decisions.
Added subscriber: @myway880
Maybe this is too early to think about or out of scope
but just in case it's relevant , the keymesh idea That are being developed by Pablo, does it need any special care during your design? From what I understand keymeshs are multiple meshes under the same object? How will that appear in the outliner?
I think this is the first time I've seen this design with the new left column, and to be honest I don't think decoupling data activation from selection like this is something we should do at all. The way it works now is consistent with the 3D viewport, and as far as I know also more consistent with the way activation works in other applications. The additional column of icons also clutters the outliner even more.
What is the opinion of other UI team members on this?
Personally, my opinion is that mode toggling should not happen in the outliner, only in the 3D viewport. That's where it really matters, outliner display and available operations do not change much depending on the mode.
If we must have a way of toggling nodes in the outliner, then changing the active object along with it seems reasonable to me.
@brecht thank you for taking a look at this. I'll discuss your points with William tomorrow when we meet. If for whatever reason this specific project isn't acceptable, I have many other tasks that I can continue for GSoC.
There has been at least some UI team discussion; @WilliamReynish @ideasman42 and I first planned this back in August last year, and William and I are discussing this design currently for my project. Mode toggling from the outliner has also been mentioned recently https://developer.blender.org/D7510#180495.
First, not all activation is being separated, only for a few types. In my opinion, the camera, collection, and scene activation isn't completely necessary from the column, but the mode toggling is both useful and needed. Currently the outliner can toggle edit mode and pose mode. This is very helpful when in those modes because you can't easily add or remove objects while in the mode. The outliner makes it easy to see what is in the mode, and allows adding or removing objects. I just extended this to work for all modes, and from the column. This frees up the data items in the outliner to toggle properties editor tabs (another part of my GSoC project).
@Zachman, if Campbell also agrees on this design I'll go along with it.
I thought object activation was also done this way, but if it's just the camera, collection and scene that is better. Still not entirely sure about the collection case though.
Personally for the modes I would expect that if a mesh object is in edit mode, and you select an additional mesh object in the outliner, that other object would automatically also go into edit mode. But I can also see how that's problematic if for example you do select all, so maybe it does have to be more explicit.
Added subscriber: @slowk1d
Outliner: Mode toggling & activating datato Outliner: Mode TogglingI'm not keen on the behavior of picking a new active object for the user (when exiting edit-mode for example). I'd like to know if there is a an advantage that makes this worthwhile since it will change other things (nodes, material preview etc) in a way users will find jarring - depending on the situation.
Exiting all objects-edit mode is a quirk too, but one that's predictable, with D8641 at least, if you toggle the mode of an object, it sets another object active and leaves it active. I don't think there is a good general solution for this as setting the object active that's added to the mode also isn't ideal.
Bigger picture, I'd like to know if experienced users are often using the outliner for mode toggling, since this design dedicates a column, making it much more prominent.
Brecht mentioned in #user-interface-module
We could leave outliner mode switching working on a basic level (adding the mode-column without other changes to active object setting), and see if we can come up with a good design to perform mode switching in the 3D view, since I think users are more likely to see the contents in 3D which they want to enable.
Added subscriber: @PabloDobarro
I think that exiting the mode when toggling the active object is acceptable. It's also consistent with the current master behavior. @WilliamReynish really wanted the active object to change instead, and I agree that changing the active is a better behavior in many ways; however, the issues with undo and "jarring" activation are reasons to avoid changing the active.
I am fine with this plan. I know that @PabloDobarro was workikng on a viewport-oriented mode toggling feature for sculpt mode in D7510. In the long term it would be nice to support mode toggle in the viewport for all modes.
Changed status from 'Confirmed' to: 'Resolved'
Committed in
2110af20f5