GSoC 2020: Outliner Discussion and Suggestions

Well, the selection in the picture above is actually incorrectly drawn. In Blender, when an object is selected, the color of its title changes along with line highlighting. Therefore, I do not see any visual conflict.

@Massivetree Separation by loose parts is also an edit mode operation, and sadly I think we won’t be adding that to the context menu. You can read more about the context menu plans on the task I created yesterday: I hope that makes sense!

@rnederhorst I do want to make it easier to see what is selected when the selection is in a collection. That’s on the todo list for the summer.

Thanks for the continued collection color mockups, I’m still working on an initial design pass.

Today I experimented with hiding the inactive radio icons. It could work, but it also makes the feature a bit more hidden. What does everyone think?

left_column_show_inactive left_column_hide_inactive

I’ve made a few other (big) changes and some design proposals (for context menu cleanup and colored collections). I’ll be finishing those up and then sharing more in my weekly report tomorrow.


May I ask what is the idea behind the radio icon in the collections?

I would like to see a different icon for the cameras and the collections, those two elements have totally different purposes.

When you click on the radio icon of a camera, what it will do or enable?


Always visible is better, hidden icons feel glitchy because constant appearance / disappearance on mouse hover.


It’s not obvious for me neither. :worried:

1 Like

I’d personally go with constantly visible one. It’s a cool feature to hide the inactive ones but could be exhausting to work with in the long run. (especially since those data icons after the name are all the same color)

Side question, might not be closely outliner related but you might have more insight into this - any chance to enable deleting hidden objects? Working with heavy scenes one often wants to make such a conscious decision without having to unhide everything before deleting it.


Imo Using same radio icon (circle/ring) in same column meaning different things will be confusing. It it not obvious, so at first you have to guess what it means, and if you know what it is you would have to look at two places to know where to click to activate desired item.

Maybe use filled/empty veriations of icons i this ‘active’ column?

I guess that column will also be used for object activation?

How should the user pick the color? Supporting 8-10 color options would most likely be sufficient. The selection would likely happen from the context menu, but at the moment there are no submenus that allow picking a fixed set of colors.

Maybe several predefined colors plus extra option?


Selecting hidden objects would be great. Right now not being able to delete them is a consequence of not being able to select them, and I think it is a great limitation. That’s not strictly a problem with the outliner, though : it is a general paradigm in Blender that the user can only operate on visible things (with the exception of the node editor…).
edit this is more or less a feature request and @natecraddock has explicitly asked to not use this thread for them, so apologies.

@natecraddock I seem to have missed the train about that active camera icon. Using a new column entirely for the purpose of changing active camera (which is definitely not something you do frequently) sounds hardly justifiable to me… what’s the rationale if you don’t mind ?

Ok I dug through the thread to find the design task.
It seems that left gutter is mixing up several concepts. Active camera, objects being edited…? that does not justify a new column to me : all of these things could be solved much more compactly, for instance indicating the active camera by drawing its icon differently (either with a different pictogram or an embossing/halo around it, the solutions are plenty). Objects part of edit mode could be toggled by clicking their already existing “data” icon. Finally scenes can have their radio button to the side of them, just like collections have their checkbox.

I think if we’re keeping at this pace the Outliner is going to need its own monitor to display correctly. Already the restriction toggles are taking up a lot of space, and if we don’t add stuff in a smart and compact way it’s only going to get worse. (my personal reasoning is that the “renderable” toggle is redundant and managing renderability should be the job of view layers, but I know that’s out of scope here).


I also think they should always be visible, also beacuse it makes you understand that it’s a toggle only for cameras and collections

1 Like

(I definitely don’t mean to derail the thread, it was more a question than a request. You can select hidden objects just fine though (in the outliner) as well as being able to delete them when deleting a hierarchy. Only thing that’s not allowed is deleting single/multiple objects that are hidden, which is not a restriction that’s present in any other production oriented packages.)

Changing active cameras can be common depending on the department you’re working in. For product visualization, lookdev and even layout it is used quite frequently.

I’m using the renderable icon a lot, especially since it can be animated (same for disable in viewports) Not sure what the practical reason is for having a separate show and disable in viewports toggles though. Having all these toggles keyframeable for collections as well would be great, but I’m not a fan of removing them since we’re already allowed to show/hide them to our hearts content.

I’ll explain why there are two separate visibility toggles : one carries over between scenes, for example when a collection/object is linked to another file- and the other is purely a local override for visibility. This is why I think overrides should handle that instead of having two separate toggles. (I meant overrides in my previous post, not view layers, sorry…)

Thanks for bringing your side of the story to the “active camera icon” - even in animation I don’t use that so much since it can be animated with timeline markers. I usually rely on the graph editor/dopesheet to keep track of that but I can understand your pov. That being said, active camera is indicated in properties editor, scene panel - it’s not like it’s out of reach. Bear with me, I’m just trying to limit the Outliner expansion craziness here, I really don’t want to be stepping on anyone’s feet (toes?). I see things with my animator eyes, but Blender is such a jack of all trades…!

I agree. However one potential problem here is visibility and renderability, being two separate toggles, are not in sync. So if you’re approaching things with a mindset such as “I render what I see” then you’ve got these two separate toggles to keep track of, and keep in sync at all times, which can be a burden.

I’m ok with this but some folks have expressed frustration back on BA.

1 Like

Thanks for the explanation. As long as their state can be animated and they’re easily accessible (one single click, not a click more :slight_smile: ) I’m fine with whatever. I find the current way pretty practical, way more convenient than in Maya for example. Always great to hear other angles though.

Ye, I get your point. I was clicking the camera icon to the right to set cameras active in the outliner, I guess this extra toggle would be there to unify setting cameras and collections as active. I get people who’re conscious about screen space though - there are departments where a majority of time is being spent in the outliner and having extended functionality is a must, and others where a minimized space is more appealing as it’s used mainly for selecting objects.

As for syncing viewport and render, I have to do that frequently and I’m using a slightly modified version of a free addon to do that at the moment. It is quite crucial in many cases, let’s say you’re working on a scene doing some modeling, and you have tens or hundreds of heavy lidar scans in the scene as well. You probably don’t want to see those all the time, or even ever after a point, but you still need to show some of them in renders either as a background object or for QC purposes.

Hi all, I see there is some confusion regarding the first task of the project (Mode toggling & data activation). I’ve updated the design task with the rationale and current state of the project. I don’t want to duplicate this information in multiple places, so please read it if you are interested. You are welcome to reply here or on the task with feedback.

Many of my tasks for the summer involve the same thing: Outliner selection is confusing. A few examples to illustrate:

  • Selecting a collection will always activate it. If you want to select to reorder, nest, rename, etc, it gets activated.
  • Selecting mesh data enters edit mode, and armature bone/pose data will toggle the mode. This is helpful, but hidden
  • Selecting camera data always sets the active (scene) camera.
  • We show datablocks for most data types (modifiers, grease pencil, lights, etc.) but the icons don’t do anything useful when selected.

Also, it’s not always super clear what collection is active (the highlight isn’t the most visible). Last summer we planned a few tasks to clean up selection and activation.

This first task was planned last August. At the time we identified scenes, cameras, and collections as good candidates for this left “activation” column. I think the most important is collections, so perhaps scenes and camera could be removed. I do think at least camera activation is helpful.

The second part is to switch properties editor tabs when clicking object data. Like I mentioned above, we show light data (green) in the outliner, but selection does nothing! We want to make datablock selection useful by switching to the correct tab in the properties editor. If datablocks were still connected to setting the scene camera and mode toggling, this would again cause multiple actions on selection and be confusing.

I hope that clears things up! Thanks everyone for the wonderful feedback! I’ll be posting my weekly report in a few hours with some nice updates :slight_smile: Edit: posted here. Also, @Hadriscus feature requests are just fine here! Many ideas in my project this summer are feature requests from last summer.


I agree, making the icons always visible is better. I’ve left it that way.

@jc4d @xan2622 @Hadriscus setting the radio icon for a camera sets the scene camera. This is the camera that is used in camera view, for rendering, etc. The column is used for many things, and camera activation is just one of them. The column already is there in 2.83 and before, now it is just filled with useful information.

@dan2 in 2.83 you can use the context menu in the outliner to delete hidden objects. In 2.90 you can directly press X in the outliner to delete objects and collections :slight_smile:

@Zuorion thanks for the collection colors mockup! And about the radio icons, we are thinking of better ideas, thanks for the idea.


haha :smiley: Never tried it for some reason, thanks heaps for that! That’ll save a lot of frustration. Strange that hitting x doesn’t work in the viewport, but this definitely works for me. I got to pay more attention to the manual, just recently discovered cool thinks like hiding every object inside a hierarchy by shift-clicking the parents visibility icon.

1 Like

Something I was thinking about the keyboard shortcuts in the outliner, when pick walking, you can press right arrow to open the hierarchy of a collection/item one level, however if you shift select several items then hit right arrow it only opens the active item.Pick walking 2
I feel like it should probably open all the highlighted items. The same applies for shift+ right arrow press too, to fully open up all hierarchies. I feel the selection would start from where you stopped at, which it already does, just minus the opening of all the items.

In truth I’m not sure how helpful it would be to shift + right arrow several items, it could potentially open up a crazy amount of things, but I believe that if you can come to a conclusion based on the given tools in a software and it feels like you should be able to do that thing, then you probably should be able to do that thing. Just feels right to me, what do you think everyone? @natecraddock


Another thing that I think would make life easier is hotkeys to jump to the closest parent up or down.

This is the behavior. When hierarchies get very complicated this can be extremely helpful. I’m not sure what key would be used for this, but I noticed both ctrl and alt haven’t been used up yet in the outliner. something like crtl + up arrow to jump to the parent above, ctrl + down arrow to go to the parent below.

Much in the same vane, skipping all hierarchies to the next item in the list is also very beneficial I think.

This is the behavior. This can make getting to the items you want on keyboard really easy combined with the last one. I think shift ctrl + down/up would work.

Why all these extra shortcuts? Well it’s nice for overall I think, but this workflow is incredibly nice for riggers. Keeping it all on the keyboard is ergonomic and makes sifting through long hierarchies easier to explore.


@Bobo_The_Imp I like that first suggestion. I’ll probably get to that when I clean up the context menu. It should be a simple fix, just run the expand hierarchy function for each selected parent.

For the jump to parent and first child, that is already in the test build! It is mapped to the right and left arrow keys currently. Give it a try and let me know if it works well.

I’ll look into one for skipping the hierarchy. Perhaps now that right and left go in and out of sub trees we can simply use up and down rather than relying on key combinations.


Works perfectly! Ain’t nothing like suggesting something only to have it already be implemented haha. Thanks, riggers will be happy no doubt.

1 Like

Not sure if it’s been mentioned in the thread already, the Outliner should allow to select hidden or selection-disabled objects. It’s very confusing at the moment.