Inconsistent object hiding behavior between 2.8x and 2.7x?

I found a really annoying behavior in 2.8 I hope is just the result of an unchecked box somewhere or something.

Back in 2.7x, Blender was respectful of hidden objects per layer. If I have objects in multiple layers and I unhide using [alt]+[h] in say layer 2, then only the hidden objects within layer 2 will be unhidden. It left hidden objects in other layers alone.

In 2.8x, the equivalent to the older layer system is collections. However, now in 2.8x, it appears if I unhide ([alt]+[h]) with only one active collection, Blender decides to unhide every hidden object across all collections.

Is there a way of making Blender respect hidden objects per collection like it did layers in 2.7x?

I don’t see such problem with master or 2.82.
Are you working with a scene that has something special (collection instances, maybe) ?
Can you make a screencapture of outliner ?

That could be an unchecked box. Restriction Toggles not being all visible by default.
It is easy to miss something.

The equivalent is view layers, not collections. Collections replace groups. Visibility is working as it should across view layers.

I’m realizing that maybe I should’ve clarified something.

By “unhide”, I mean I’m using the hotkey [alt]+[h].

A simple exercise to demonstrate what I’m talking about:

  1. Create two collections and hide an item in each.
  2. Press 1 (or 2) to activate only one collection.
  3. Press [alt]+[h] to unhide the object in the current collection.
  4. Go to the other collection and note that the hidden item here is ALSO not hidden. =/

To compare, fire up a 2.7x Blender. Do the same.

  1. Create an object in two different layers.
  2. Press a number to activate only one layer.
  3. Press [alt]+[h] to unhide the object in the current layer.
  4. Go to the other layer and note that the hidden item here is STILL hidden.

The 2.7x is the desired behavior.

The 2.8x behavior is really annoying when the user spends time custom hiding certain elements in select collections (then Blender decides to unhide everything even though only one collection is active).

Nope, and the problem exists in 2.82 as well. =/

Not sure what you’re saying here. Collections were meant to replace the old layer system according to the official blog post (It looks like the reason why they also replaced groups was because it was expanded to be data-blocks).

This is why, for instance, when you press a number, the corresponding collection becomes active just like the old layer system. Or pressing [m] to move items to collections. Etc.

Okay. I was assuming that toggling icon in outliner and alt H in viewport was working the same.
But it is not.
Reveal operator does not support collection restriction.

So, if you want to unhide only one specific object, you can unhide it by using outliner.

@Hadriscus is also right.
Collections are an attempt to merge properties relative to layers and groups.
But in 2.8 design, viewport is supposed to be more WYSIWYG.
So, View Layers are equivalent to old Renderlayers.
In 2.7x, you had to define a RenderLayer by a set of layers. in 2.8, you define a View Layer by its set of collections.
But in 2.8, View Layer is directly visible in Viewport ; you don’t have to render to see the result.

That means that if you want different sets of visible collections/objects in viewport, you can create as many View Layers as you want for that.
So instead of switching from one collection to another, you can switch from one view layer to another.
Alt H has no impact on inactive View Layer.

The main reason it works like this is the difference between the eye icon and the monitor icon in the outliner.
Turning off a layer in 2.79 is equal to turn off both monitor and render icons in the outliner, but it’s not the same operation as pressing number 1 or 2 on the keyboard. Doing this in 2.8x turns off only the eye icon. bla blah blah…
edit: sorry for blah blah, I was writing and testing and found that you’re totally right!
Blender alt+H turns on ANY eye icon, even the ones in disabled collections! Not good.

1 Like