i think collections will be a positive change in the long run i think but there are some issues and busted functionality vs what we used to have with groups. namely in the hiding of groups vs the hiding of layers which has been brought about by how we don’t have the ability to hide individual objects anymore.
with groups, we could hide entire groups easily even if some of the objects inside were in multiple groups. didn’t matter how many groups an object was in if we selected a group and hid it. the whole group was hidden.
with layers, objects stayed visible as long as they were in any visible layer regardless of how many hidden layers they were in.
when hiding things, groups and layers worked the exact opposite way.
it was useful to have objects in multiple groups to get the opposite hiding functionality as we had with layers.
when it comes to hiding things
collections work well if you just treat them as layers.
collections work terribly if you treat them as groups.
logical conclusion is that complete group functionality doesn’t seem to have been merged into collections. how it worked in relation to hiding seems to be overlooked due to how similar the functionality seemed but since we can’t hide individual objects anymore it’s an issue.
so was it overlooked? broken as planned?
are we getting some new “force hidden” feature to use on collections so that we actually get that group functionality back?
maybe two different types of collections get the group functionality back?
as similar as groups and layers may have been functionality wise i don’t imaged we’d have had both if they weren’t fairly different in usage.
also, selection of things in the 3d viewport seems to be acting up on the current build (June 1st) based on different factors of how your collections are set up and even which ones are hidden. it affects things that aren’t hidden and in some cases entirely keeps them from being selected though the viewport.
What do you mean by this, are you talking about group instances? There was no way to hide groups themselves in 2.7, only objects that instance a group.
So is what you are really asking to bring back per-object hiding, so that you can individually hide objects that instance a collection?
About that, I’m waiting to see back the individual options in outliner.
And the hotkeys to show and hide collections like old layers. It is one of my main hotkeys in my workflow and I don’t see reason to don’t implementate in collections.
guess that was a bad example…
i’m more asking for the ability to make one collection’s hidden setting overrule the visibility settings of other collections. which i asked about as a “force hidden” option. i don’t know if that would require per-object hiding or not but it would enable us to actually have group functionality again.
add a single object to multiple collections that are not nested. that’s useful for easy selection of varied groups. it’s exactly what groups offered us. now lets say you want to hide everything in a collection. you hide it and yet not everything in it disappeared because they were in other collections.
how do you hide the leftovers when you only wanted to hide everything in the collection you specifically hid?
are you supposed to ruin the collection sets for easy selection you’ve made by taking that object out of it just so the other collection is completely hidden like you wanted?
if so that’s not really giving back the functionality of groups so much as just telling us to set things up as if we only had layers but oh we’ve got as many layers as we want now. it forces us to group things based on visibility options and only with very specific overlap rather than by what we think should be collected together for easy selection.
groups were very free in how you could set them up. there could be a lot of overlap. they could even be entirely engulfed by other groups (like a nested collection) or they could be partially overlapped (like two separate collections even on a hierarchy sharing some objects) or entirely separate and they had nothing to do with visibility options though i often set them up as if i’d set up a nested collection i didn’t always do it that way.
having the visibility tied to collections the exact same way as it was to layers really messes that up because now you’re forced to set up your collections as if they were layers and can’t really set them up as if they were groups for easy selection of certain things.
it’s not group functionality it’s just infinite named layers. as such i asked if we’d be getting a “forced hidden” option or a second kind of collection maybe one that doesn’t deal or affect at all the visibility options set up by other layers.
personally i think the best case would be to have both of those but if i had to pick one i’d probably pick the forced hidden one.
@DaedalJS, collections can do everything that groups could in 2.7 and more. That means you can create collections that are not part of the scene hierarchy, and then create instances of those. You can go the outliner, Blender File view, and set the filter to see only collections to get the equivalent of the old Groups view. We will improve the UI for creating and editing such collections still.
As far as I can tell what you are describing is either new functionality that was not in 2.7, or things that are still possible in 2.8 but perhaps harder to discover.
it in such a small amount of space, but we don’t think it’s practical with nested / named collections. There’s no way to show the nesting, the numbers would either change or become scrambled as you add and remove collections, the relation between what’s in the viewport and outliner would be unclear. Someone could create an add-on for this though.
Not really, collections do not involve parenting, objects can be in multiple collections, and collections generally do not affect what happens with selection and transforms. I think it would be good to add support for groups as they exist in other software like Maya in Max, but the Blender groups were never like that. With the unification of collections there is room to bring in a “proper” group type, though that’s out of the scope of the code quest.
However for temporarily hiding objects our idea is to make a more powerful local view instead. Basically you’d be able to hide objects with H, shift+H, alt+H in the viewport without affecting the visibility controls in the outliner. The replacement for the layer buttons in the 3D viewport would also put collections in and out of this local view.
We will have a panel/menu to show/hide collections, but we don’t think a tiny row of buttons like there was in 2.7x can properly represent named and nested collections. If it’s bound to a shortcut key and then appears under the cursor it should still be quite fast to use.
I don’t know for other users, to me the tiny rows is a good indicator of the pertenenc
I don’t know about other users. For me the tiny list of layers was a perfect functionality to determine the peternance of an object to a layer or several layers. But actually the visual representation is not what’s important to me right now and I don’t want to discuss it.
What matters most to me is how quickly I can show or hide collections by simply clicking on a number, as is done in 2.79. And I think it is something easily applicable to collections by allowing the user to assign to the collections with the context menu a number of the old layers, and that all the default layers belong to 1, for example.
This is very important in my workflow because I mentally order the scene in different ways
For example
1 - Low poly
2 - High poly
3 - references
4 - helping geometry
Or
1 - Object X
Alt-1 - Object X High poly
2 - Object Y
Alt-2 - Object Y High poly
3 - Object Z
Alt-3 - Object Z High poly
This, which may seem silly, is one of the pillars of my workflow and probably some of the hotkeys I use most every day along with tab and space. In other programs I completely break the modeling process having to go to the outliner and find the layer I want to hide and unhide. As I said before, from my point of view it is a specific function of blender, which although unknown by many users as soon as one knows it, it gives an unbeatable speed.
The best thing about blender, without a doubt, is that you can currently focus on the creation process without having to stop looking at the model. Making the modeling completely fluid and the program responsive to you. without that hotkeys blender break that “trance” situation.
In Blender pressing number keys (or a letter) in a menu activates the corresponding entry in the menu, so we would ensure that works for the collection hiding menu. So at least there will be an automatic association with a number or letter.
We also discussed letting users define their numbers, and it could be done builtin or as an addon, but there’s no decision on it at the moment.
yea very likely that it’s just harder to discover and somewhat is new functionality.
it’s not that it wasn’t possible in 2.7 it’s just that it wasn’t exactly in the form i suggested. some of it did rely on being able to specifically hide a selection of objects at one time thanks to having a quickly selected group and per-object hiding.
i really don’t mind not being able to hide objects one at a time but i also don’t think only being able to hide objects when you hide every collection they’re in is a good solution either.
so i still think being able force everything in a particular collection to be hidden regardless of if it’s objects in other groups as well would still be a benefit.
i don’t think i really used hide on a more individual piece basis outside of edit mode but i did specifically hide groups for various reasons.
i mean lets say i make a few tree assets in the group for said assets i’d have the trunk, maybe a level of smaller branches and then leaves in green, maybe some small budding leaves, and also another set of fall colored leaves.
they’re all in the “tree_maple” collection since groups are no longer a thing. i then create a few variations for that so i’ve got “tree_maple 2” and “tree_maple 3” collections as well.
i do the same thing with “tree_oak” “tree_oak 2” “tree_oak 3”
and then again with “tree_pine” “tree_pine 2” “tree_pine 3”
i plaster several instances of these collections around.
being able to hide the smaller branches and leaves would benefit performance during animation or working. so i create a collection for that. lets call it “branch_leaves” it contains the small branches and all the leaves for all of the 9 tree variations because hiding one collection is easier than popping open the hierarchy for 9 sets and hiding 9+ collections.
i also split the “branch_leaves” collection into subcollections because i don’t want all the variations of leaves visible at once.
i then go to hide the “branch_leaves” collection or one of it’s subcollections and nothing happens.
why?
because the objects in “branch_leaves” are shared with 9 other still visible collections i made for the trees.
am i doomed to rework the collections back into the base tree collections and as a result have to hide at least 9 collections, more if i actually want to only show a subcollection for seasonal leaves, rather than being able to hide just one?
how exactly do i work around that without the hierarchies becoming a mess to deal with if i can’t force a single collection to hide everything inside of it even if those objects are shared with a visible collection?
that’s part of how i used groups along with per-object hiding but nothing like that is available now in 2.8 as far as i know.
to be clear i’m not suggesting changing the way one of the collection visibility settings works so much as adding a third visibility setting that doesn’t work the same way the visibility settings for layers did. still not a per-object thing but it further helps keep the outliner a bit cleaner and easier to use while also bringing back a bit of the useful functionality we lost when we got rid of per-object hiding.
Ok, what really happens in 2.7 when clicking the eye icon in the outliner next to the group is hiding all the individual objects in that group. So if that was available again your workflow would be possible I think.
exactly! it didn’t work like the visibility settings for layers.
i never really used the outliner for it because swapping the outliner’s display mode back and forth felt slower than using shift+g and h.
i do think having visibility settings like how layers work is useful too so as i’ve been suggesting maybe rather than a simple boolean toggle it could cycle through three options.
it would probably be a little less understandable how the second and third options are functionally different at a glance but i think a tooltip could help with that.
