← All ideas
  • Published 17 Jul 2024

Appending Collections Should Keep Their Original Visibility

We are transfering a lot of collections between files in our workflow. And a lot of times, collections inside collections dont keep their visibility settings but are toggled on.

This results in a lot of errors when things that were f.e. old versions and their collections turned off, suddenly reappear after being appended.

It would also make sense if the child collections would keep their original visibility settings when appended to a new file.

100%

Development Status: Open

Upvote 8 Downvote 0
mikolas.fiser
17 Jul 2024

5 Comments

Lauloque

Use "Disable in Viewport" instead of the regular "Hide":

demo picture

As the tooltips suggest, hiding is just a temporary option, while disabling is global, and preserved when appending or even reusing data in other scenes.

You can also use the View Layer exclusion checkbox.

Plus in both cases it gives better performances I think.

1
thinsoldier

Any idea why they chose to have visibility reset for all children when toggling the View Layer checkbox. It makes it useleess for the organization ability I wish I could have had in Blender.

Lauloque

AFAIK the idea is that "Hide" is temporary, "Disable" is permanent (and also animatable, easily accessed from python or drivers, ...). So, you should rely on "Disable" for a permanent organization.

It's a bit complicated to grasp, I'd blame that on multiple things such as "Disable" being a weir name and not even shown in the outliner out of the box, but this hide/disable duo system does allow some flexibility, especially when making assets used elsewhere.

If I were the BF, I would consider maybe make "Disable" shown in the outliner by default instead of "Hide", or both of them. But also consider that maybe it would be simpler for everyone to get rid of the dual system altogether and assume that anything hidden is always hidden till the user decides otherwise. Just as it was before.

mikolas.fiser Author

Thanks for the explanation. I would argue that the system indeed could use simplification, as we (a production studio of 10 people working in Blender for 2 years) haven't figured this behaviour out by a trial-error method.

1
Lauloque

I would argue that learning should ideally not be limited to only brute force trial and error. But It's a good thing to point out! It illustrates things not making sense by themselves to begin with.