I feel as if I’ve been using 2.8 for long enough to really explore collections. At first I was excited; a week later I was frustrated; now I’m just a little disappointed. I’ve looked at some of the other feedback threads regarding collections and didn’t see my particular complaints expressed.
My experience previous to 2.8 was that I rarely needed more than 20 layers. When I did, I implemented workarounds very similar to modern collections: I would use groups to establish extra layers; I would create non-rendering text objects to label my layers. This isn’t really any more work than the current collection system. The difference with the current collection system is that it starts to demand this work before it’s necessary. This is basically meaning that I’m barely using layers/collections now, and am instead working with multiple 3D viewports and using local view heavily-- a workflow that I don’t consider ideal.
Which is a shame, because there are a few simple problems that could be fixed with collections that would actually make them functional in the same way as layers, without any architectural changes.
-
’m’ ‘2’, ‘2’ leaves your object invisible. Scene collection is included on the menu for add to collection, but not on the menu for change collection visibility, which creates a hotkey asymmetry that hurts my head. If you want to move an object to your third collection, you need to hit ‘m’ ‘4’.
-
Auto-numbering of collections. This isn’t a big deal, because it’s solvable with a startup file, but hotkeys to change visibility are connected in user’s heads with numbers, not with words. There is no connection between any text string and any of 19 hotkeys (“layer” 20 lacks hotkeys, because of 1) above.) Displaying the number on menus, collection membership would significantly reduce headaches for those using more than a few collections.
-
Identify collections for selected objects-- even hidden selected objects. A large part of my workflow, previous to 2.8, was putting control objects, empties, mesh deformers, collision bodies, etc, onto different layers to leave my view uncluttered. With proper, reasonable parenting, most of the time I didn’t really have to keep track of exactly which layer these objects existed on-- which is a good thing, it let me organize them better. I could select an object, hit [ to select parent, and immediately see what layer I needed to switch to in order to edit that parent.
In 2.8, selection of hidden objects seems to work a little differently, and of course there is no display of the collection of the selected object. This means that I have to switch to properties/object, find the collection, switch back to whatever property tab I need, figure out what number that is (see 2 above), and finally add that layer to visibility. This is enough extra work to discourage my frequent use of collections.
It doesn’t have to work that way. We have text info in our 3D viewport. When we select a hidden object, Blender could easily tell us what collection that object exists in, which would tell us immediately what we need to do to make any changes.
- Active collection is not necessarily a visible collection. When you add a cube, you expect to see a cube. I cannot imagine any case where a user would want to add a new (or appended, or duplicated) object to an invisible collection.
There are some additional problems that aren’t quite collections problems, but they are sequelae of collections, and I’d like to write about them a bit.
- Per-viewport visibility. The use of unlocked layers was an important part of my workflow when editing mesh deformers-- I could edit a deformer in one view and see its effects in another. This now requires further workarounds. If I don’t want to be stuck editing in wireframe, I have to create materials for all of my control meshes and use a rendered view.
(Note also that hiding our edit-mode-hidden verts in rendered view is not a feature. Rendered view is the only way that we can see the effects of a hidden-vert-limited proportional edit. Hiding verts is an important part of many weight painting tasks. By implementing this in Eevee, Workbench, you’ve made Cycles an essential editing tool. Cycles is the last way we can actually see our edits in realtime. And as we all know, Cycles isn’t particularly realtime…)
- Outliner confusion. The addition of collections meant an outliner that tried to serve two masters: collections and parenting hierarchies both, at the same time. This means multiple instances of every object that make it difficult to select the actual object from the outliner. Zooming to a selected, hidden object via numpad . won’t necessarily give me the “true” instance of the object, showing me which collection it belongs to, allowing me to make it visible. Changing to a scenes view won’t let me use numpad . to zoom to an object not on a visible collection, period.