Outliner: Show/Hide By Type
Closed, ArchivedPublic


This patch allows to hide/show tree elemensts in the outliner based on their Type.
Idea behind this is not only having some more control over whats shown and what not, but also to gain performance in heavy scenes.
Quick tests here show that hiding object data alone can give a 10x performance boost :) [just having 2500 cubes and hiding the mesh datablocks]

Atm moment this is quite granular (see below), but the different options are grouped, so the user can quickly hide all "Object Data" e.g.
There is also an operator to quickly "Show All Types" again.

This will also enable a request like here:

here's how it looks:


Differential Revisions
D1136: Outliner: Show/Hide By Type

General functionality review,

Would prefer have a flat top-level menu, this way you can (at a glance) see whats on or off, nesting 3 levels.

Also think this is far too specific (that you would want to have metaballs on, lattices off?... not sure of this use case...)

Suggest Categories

  • Objects
  • Object Data (Mesh, Curve, Lattice, Cameras... etc)
  • ObData Extra (bad name UV Layers, Vertex groups)
  • Object Groups (instances etc)
  • Object Extra (//bad name, Constraints, Modifiers)
  • Bones (Bones, Pose Bones, Bone Groups)

  • AnimData
  • Shape Keys

  • Shading (Material/Textures)
  • Images

  • Render (layers, passes)
  • Grease Pencil

This probably needs tweaks - but think its worth to group them otherwise the list expands really quick to become unmanagable.

thanx for having a look!

regarding flat-level-menu:
agree (you meant "not nesting 3 levels", right?)

regarding Hide/Show object types:
not sure about this. atm it is not easy to focus on a mixed selection of two or three types (e.g. maybe @Leon Cheung (leon_cheung) can comment on this scenario here, I could also think of "only show cameras/empties" in some 'photoreconstruction' scenario...)
Possible [but not so efficient] alternatives atm.: The "Same Types" Outliner mode is useful but only works on the active object (so no mixed selections here), the "Select grouped" operator has to be called multiple times -- and is for selection only...
Also not sure if it makes sense to hide all object types at once? (as your first category suggests?)

regarding other categories:
your suggestions regarding groupings lgtm. we should make clear though [in the tooltip? menu entry itself might get too long...] what exactly is included in such a grouping.

I'll update the diff once we agree on final groupings, OK?

@Philipp Oeser (lichtwerk), right - not 3 levels of menus.

Can see maybe its useful to show different object types...

In that case list may be...

Objects (label)
... enumerate object types (10 or so, could have Curves/Surfaces as a single item) ...

Object Data (label)

  • Object Data
  • Object Data Extras
  • Object Groups
  • Object Extras
  • Bones

Shading (label)

  • Materials/Textures
  • Images

Animation (label)

  • Anim-Data
  • Shape Keys
  • Grease Pencil

updated the diff D1136: Outliner: Show/Hide By Type to address functionality review by @Campbell Barton (campbellbarton)

looks like this now

@Philipp Oeser (lichtwerk), I think the menu is still far too big.

How about this?

  • Move the existing Search menu into a single icon dropdown on the right of the search text field.
  • Add a new top-level menu called Filter, which only has types to display.

Considering the amount of toggles here, I suggest making it a single button icon (or, having all four top-level datatypes nested in a separate top-level menu called "Filter", similar to @Campbell Barton (campbellbarton)‘s idea), and leaving all sub-level toggles nesting in a pop-up menu, like F6 popups in 3D view.

The advantages are obvious:

  1. Minimized the menu length.
  2. Minimized time for targeting sub-menus. If we make it behave like F6 popups, it would be much more effective to control all in one floating panel, instead of having to open menu for several times to have things toggled one by one. (I believe that it's very likely that users need to toggle on/off multiple things among them when using this filter feature)
  3. Drag-to-toggle feature may also benefit in this way, which make it even more effective.


Yeah, this kind of option bundles are usually not placed in nested menus in software, but in popup windows. Blender does this only for the program's main Preferences, but maybe this would be a good time to introduce this. Display settings in the 3d View could also profit from such a treatment, because a sidebar is also not a good place for them, like @Brecht Van Lommel (brecht) stated some time ago.

So: View > Visibility Settings (or Filter), a draggable popup window appears, working like the Preferences one, or, like @Leon Cheung (leon_cheung) said, the f6 window.

Hi everyone and thanx for the suggestions...

I dont have a very strong opinion on the menu/layout, but a couple of thoughts:

  • if the list gets too long in a flat menu, we could also remove the grouping labels ("Objects", "Object Data", "Shading", ... )? Then we end up with roughly the lenght of the "Object" menu in 3dView...
  • we could also put it in a submenu and consider getting D834: Don't close menus when clicking on checkboxes. in? (I know Campbell has objections though...)

I've made both suggested changes (I've updated the diff *twice*)
so Diff 3 of D1136: Outliner: Show/Hide By Type is Campbells suggestions
and Diff 4 of D1136: Outliner: Show/Hide By Type is invoking a popup with all the options... (with all the goodness of "Drag-to-toggle" like @Leon Cheung (leon_cheung) mentioned...), which looks like this:

Let me know what you think!

There are a couple of major problems with the proposal.

  • it is only useful in a very minor way, so it should not take so much UI space, nor changes in the code
  • doing this with pulldown menus is clumsy and slow, and it conflicts with the header options we do now
  • pulldowns should resttrict to operations (like set a mode, or do something) and not be used for settings.
  • the fact you can think of options (and usually each option can be useful in theory anyway) is not a good start for outliner maintenance. In general: adding options should be avoided at all costs, it is not 'good ui design' by definition. Sometimes taking away options is the way to go. Outliner is getting too heavy already.
  • why not check on a regex button in the header to filter based on a py equation?

I still think this lets you work in a faster and more organized way (especially in heavy scenes) -- it just hides away things that are not in interest atm...
I also think improved performance in heavy scenes is quite something.
So, calling this useful "only in a very minor way" seems subjective [it doesnt hold for me - and apparently others]

I can follow the general mantra of "No Options!", not sure I can follow the mantra of "No Pulldowns for Settings!" (why?).
In what way do you think the outliner is getting to heavy? UX-wise? Code-wise?
I have to admit I am not very experienced in UI design, but are certainly willing to learn here... atm this is nothing "excellent" or "daring" but mediocre [but gets the job done... :)]

doing something like regex/py-equation could work, but:

  • if this is not done on names only it might get non-obvious for the user as well? e.g how would you hide obdata ?
  • do you have something in mind [syntax-wise?]

Happy to hear other opinions, and will also think about this more...

You propose to have a way to filter and categorize data types drawn in outliner. Sofar so good. I can see the use for that.
The problem (which your UI illustrates) is that the amount of choices and options here easiy goes out of control. There is no obvious selection possible either. That is why a regex could work. Like: "Ob type is mesh and has subsurf". (In reality these look quite more clumsy).

A big downside is that this slows sequencer down even more. So that has to be tackled (but this was an old issue we have for a decade already).

Further - Pulldown menus are for actions, button panels for settings. I wouldn't know how to explain this... just a sane design guideline.

A simular UI as you suggest is in file window, a long row of icons which you can use to filter. Also this is not very friendly to use... (see screenie). I don't know a very quick solution for this, but not trying to cover every filter with a complete complex menu tree is not the solution either.

(BTW: I am surrounded here by artists who help making Blende better. For each idea or suggestion they have we carefully examine together how good it would work or how to do it well. A feature like this was never suggested... but they might think it's useful sometimes? Will ask :)

@Ton Roosendaal (ton): thanx for your feedback -- UIs are quite a complex subject and you are right it takes time/experience to nail these... (will pick up some literature/links on that matter as well- got some good advice?)
@Ton Roosendaal (ton): did you mean "slows the outliner down even more"? not sure about this... you mean with regex? (because my current implementation actually speeds it up once you hide stuff... like 10x only hiding objectdata...)

couple of unordered thoughts:

  • if panels are for settings, should the outliner get a T-Panel/N-Panel perhaps? we could put all options/settings there [also search-options, 'sort alphabetically', 'Show Restriction Columns']
  • You've got one artist sitting in the studio suggesting something like this [read Manu here :) ], Campbell also mentioned this in IRC, and my list of things for the Outliner comes from other artists/colleagues that are looking for a replacement of Softimage ;), I didnt make these up myself (mostly)
  • I am letting that "Filter-Tag-Expression" search box boil in my brain for a bit [like it actually, just cant think of something that doesnt get clumsy atm...]

there's something like this already in the dopesheet, the collapsible 'Filter' button... think using icons makes sense here too
or maybe just a 'ligh mode' -only object names- for heavy scenes? if you get a such speedup then it is good to have it

@lower case (lowercase): thanx for the suggestion. This could very well get overboard as well [number of buttons -- even if they are collapsed by default], I think, except we restrict to only a couple of options ['light mode']. What do the others think?

No progress on the "Filter-Tag-Expression" thing here, still needs more thought...
Any other suggestions from the UI-team? (afraid this will go down the drain otherwise...)

Anyho, thanx for pushing me everyone, hopefully we'll still come up with something...

I am in favor of a column with panels.
Text Editor have less display options than outlliner and it have its own properties region with its Properties panel.
Its Find panel also allows renaming. It could be inspiring for a search panel in Outliner.

Outliner could contain several display panels like 3DView properties.
If a dozen of icons represents a problematic row in outliner's header, it becomes a really small and easy and fast to access as a pack of 3 rows of 4 icons on a panel.

A lot of people would prefer to add their addons with a purpose of organization in outliner rather than in Scene properties or 3DView.

IMO, there are several benefits to add a region to Outliner.

Sergey Sharybin (sergey) closed this task as Archived.Apr 10 2015, 10:57 AM
Sergey Sharybin (sergey) claimed this task.

The interface is really clumzy, it is to be simplified and made nice in order to be accepted for master. it makes sense to switch to an according Design discussion before jumping into the code. For until the interface solution which satisfies everyone is found i'm archiving the patch, it's easy to re-open it once the updated code is submitted.