The plan is to make it groups and collections the same thing. All collections would be datablocks, and as a result linkable into other files or usable as e.g. collision groups.
Collections could be linked in scenes, or just exist outside of scenes as groups do in 2.7x.
This sounds like a smart move although it sounds like a good deal of work?
Do you think it would be technically feasible to make a toggle to treat collections as single objects when working with them?
Often objects are in fact a collection of smaller objects and it makes sense to move and work with them as a single object. Think of a car, house, vacuum cleaner, robot, character with clothing etc.
I made a RCS post here which with some relevant discussion:
https://blender.community/c/rightclickselect/Fzbbbc/
We talked about this, and it's technically feasible within the design, but out of scope for the code quest.
+1 on @Ejnar Brendsdal (ejnaren) 's suggestion. Crucial when dealing with large interior / exterior sets, repeating complex elements in large numbers and alternating and variating those scenes.
Extension of the topic on RClick: https://blender.community/c/rightclickselect/Drbbbc/option-to-enable-selecting-groups-as-single-objects
Another thought, after reading some of the topics in the code quest. There is a possibility we will end up with a workflow problem here.
I am always glad when a simplification is made in the workflow and things are made simpler to understand. But i am not quite sure groups should be dissolved and merged with collections.
Why? Well, 2.8 is obviously going in direction to set up a standard layering system via collections - unlimited number of items, naming, toggling, nesting, showing them in a list that can appear in the viewport. And that is great, that feels like home.
But! There is definitely a need for a standard grouping system - a lightning fast way to temporarily unify objects (ctrl+G) for easier manipulation in the 3D view just by clicking on them and transforming them just like single objects - no naming (too slow), no lists (too much elements, too much scrolling, too much eye diverting, too slow). Just a simple way to make groups of objects act as one object. This includes transforming, material manipulating, instancing, accessing sub - elements - but in a lot faster way than collections are envisioned right now. I am not sure you will be able to satisfy both criteria in one system.
That is why most of graphic apps (at least that i used) have two distinct systems incorporated - a LAYERING system with selectable lists, common properties etc, and a fast GROUPING system for temporarily making sets of objects act as single objects in 3D view, in as much aspetcs as possible. No more, no less - two distinct synchronized systems. There are many commercial examples of this and it is basically a standard, but if you want an open source reference - Inkscape.
Be careful with this groups / collections / layers thing, it is a very delicate topic and can be a core workflow boost / bottleneck in the future. Think it thoroughly through.
The existing groups in Blender are nothing like the functionality you are asking for, so there is no point in keeping them separate for that purpose.
If we ever add such functionality in the future, then it will be helpful not to have the old groups anymore, since otherwise we'd end up with 3 layering/grouping/collection systems.
Yeah, that is one of my biggest mysteries of Blender - how did it get through 20 years of existence without a classical grouping system? It would be awesome to see it at one point. So far i am using an addon that i made to fill the gap.
So what is the plan then? Making collections act as a layering system and filling the group gap later? Or is there a plan to keep the collections as a hybrid system along with an expanded layering system?
I must say i am a bit in the fog as to how are these two systems going to live with each other. Especially with the probable classic grouping system topic waiting around the corner.
Collections will handle everything that layers and groups do in 2.7x, which is mainly scene organization and linking / instancing parts of a scene.
What they do not handle is parenting and transforming or selecting objects together. There are no plans to make changes regarding that for the code quest or 2.8, it's simply not a problem we are trying to solve now.
Once the code is a bit further along we'll do a blog post to explain it more.
Collections will handle everything that layers and groups do in 2.7x
That is the exact thing that worries me. Perhaps i'm wrong, but those are likely to be tasks for two distinctly different systems.
There are no plans to make changes regarding that for the code quest or 2.8, it's simply not a problem we are trying to solve now.
That is the second thing. How on earth did the absence of a real grouping system go under BF's radar for so long? How do you people speed up your work? I've been an extensive Blender user for 6 years now and i see everyone doing their grouping in half the possible speed.
Anyway, thanks for the time and the answers Brecht. And thanks for putting up with our feedback bombardment, you guys are doing a terrific job!
If you allow, a few notes on this. I've been thinking, i will layout the basic logic behind my experience on layers and groups - perhaps you can use it in your future thinking. I've used this systems in literally hundreds of files in various graphical apps. Some of them were quite complex.
LAYERS - a scene organizing entity - often represented in a scrolable list. Possible adding, naming, hiding, locking, rendering, printing, selecting, order moving. I' ve used layers in different apps for almost all of my projects - usually there are as minimum as 5 of them and in my most complex projects i didn't go over 80. This is very important - they were representable in a UI list that was scrolable and the number of items in it was comprehensible. Max four times the length of the list represented on screen. You could keep the list always present on the screen but it was best when i could call it in a pop-up for fast check and toggling. Max 5 - 10 seconds on screen. You can best refer to ayers as a CATEGORY of scene data.
GROUPS - quite different item from a layer - a fast, light-weight feature, accessible under a keystroke (ctrl+G), for gluing objects, moving, scaling, fast instancing... And very important - there could be THOUSANDS of them through duplicating and nesting. Because of that - naming is NOT required, lists are NOT required, selectable right there on screen with one click, shift+click, alt+click, duplicable, instannce-able, editable etc. In case of groups listing is possible (when groups are hidden, obscured, on closed layers), but it usually requires searching through thousands of items - something layers do not go well with. A layer list is comprehensible with one look at it.
COLLECTIONS - now this is where i get puzzled - what is the future nature of collections? They seem to take over all of the scene organizing capabilities now. Will people use them as groups? If so, list in the N panel could not handle that - outliner with search filter is required. Or are collections future layers? Then parenting, transforming, instancing is not for them, layers don't do that. They seem a little bit hybrid, eating a lot of functions which could make them cumbersome to refine later when users get used to them.
I know this is not the task for this, i realize it iz probably a good strategy move to eliminate current groups and i agree with you on that. I am just posting this here because i see Blender is finally getting rid of a lot of it's quirks, because i have some experience with it and i see a bit down the road. Perhaps you can use these remarks for thinking through later.
Again, great work whatsoever :)
I understand you want a concept like the light-weight groups you mention, but it's simply out of scope here. We are not making design decisions or implementing a concept like them now. Collections will be a replacement for layers and groups as they exist in Blender. Neither layers nor groups in Blender handle parenting and transforms, and collections won't either. Collections will support linking and instancing.
Unified collections with support for linking and instancing are important for animation production. It means you can replicate collections from one file into another with naming, nesting and visibility preserved. This way an animator can link in a character collection and animate it, a lighter can assemble collections from various files and distribute them in render layers, etc. Anonymous groups would not be a good fit for this.
People might use the new collections as light-weight groups until there is an alternative, and maybe it's somewhat workable when there are many if you don't expand nested collections that deep. But it's not a design goal.
Ok Brecht, thanks for the explanation. That puts this issue into a new perspective.
Keep up the good work!
Does this also mean that u can make collections and render-layers the same thing!
I like the solid concept of 'compositions' in after effects, can we have a similar approach.
This way we only need to add a 'collection-node' as input in the compositor, and all the sittings in render-layers panel can be found in this node.
I'm not sure if this is possible, you guys know better.
best of luck
View/render layers will remain a separate feature. These need to support quite a few features like overrides, render passes, camera/indirect visibility, ... putting all that into a compositor node would not be ideal.
I see @Okavango (Okavango) needs, they are common.
A cheap way to accomplish what he asks without making big structural changes would be having the ability to "seal" or "unseal" a collection. Then selecting any object in that collection would select also all the others, so that - selection wise - a collection acts as a single object
The list of Common Groups realization discussion treads.
Basically, there are two approaches I would like to mention.
It is industry standard approach (that works in dynamic context - "I want to group that object and that object", instead of static context - "I want to group all the trees")
Common Groups is a separate incorporeal (with no RTOs) hierarchical structure, that is independent from Collections static context separation.
Since it is dynamic context tool, it refers to cross-hierarchical solution - it creates its own non-cumulative hierarchy of groups, which is viewed and controlled separately from main collections-based scene setup.
Usually uses ctrl+G shortcut, which was reserved in Blender.
Nearest implementations in Blender
Group Pro addon we want to get rid of (because it makes scenes, where it was used, unusable without it, which is gross violation).
Quick Instance addon which works with non-animated objects.
This approach allow to seal/unseal non-cumulative collections (collections that doesnot contain cumulative objects - objects which are hosted by multiple collections)
This way collections can be manipulated as static context realization of common Groups, but it will not be common grouping, since it will be viewed in scene setup and created as a static context organization.
Nearest implementation in Blender - regular Collection Instances.
Basically, both of them are needed, but they conflicts with each other, so there could be the need in switching between them.
Possible grouping realizations was also considered there.
This turned out nice.
Collections are in and working very well.
Thanks for the amazing work.
On a side note, the mentioned behaviour of being able to work with collections as if it was a single object.
Any new thoughts on this?