Ctrl+G should be bound to Move to Collection > New Collection, not Create New Collection

Thanks for looking into this! You are definitely right that the current binding is both broken and highly misleading. What is the process to have that default keybinding removed for the 2.83 release? Is that something you could do?

That is an interesting consideration about keeping the keyboard shortcut available for future use. But it’s also worthwhile to weight the utility of current-day use against the speculative possibility of a future potential use that has greater utility, along with the cost to change the mapping in the future and cause users to relearn it. I personally often select multiple objects and “group” them into a new collection, so CtrlG would save time and avoid extra unnecessary thinking. So while it’s very important to remove the erroneous keybinding that is currently set, I also want to express that I would indeed find this binding to be useful. I wouldn’t consider it a waste of a future keymap to bind it to CtrlG in the present day.

1 Like

Praise to Common Groups! (I remember that video from jun 2019 )
They are very welcome.
Also, don’t have a clue how it is possible to implement them without messing with hierarchy, if to take into account cumulativity issue, when same object can be placed into multiple collections.

I’m sure I am just wrong for many good reasons, but I really still think that was a bad decision from the beginning. Fine to allow things to belong to multiple “groups” when those groups are not hierarchical. But items should only be allowed in one collection, since those are hierarchical containers. But again, I am probably just missing some details.

2 Likes

I agree, the collections system in Blender is so confusing to me and I still barely understand it. In my opinion, it should work just like in Unity where objects can just be parented to other objects and their position moves relative to their parents. But I don’t use Blender in a studio capacity where I’m referencing many objects so perhaps that complexity is needed for use cases I don’t understand. But if I was designing it from the start, I would take that approach and maybe create some sort of “instance” object that acts as a clone of another object in the hierarchy.

I tried to design some possible Common Groups realizations here, including hierarchical (hard to create, easy to manage) and non-hierarchical (easy to create, hard to manage) solutions.

I my opinion cumulativity brings a lot of excess freedom to a system (easy to create, hard to manage), but, well, it cannot be taken back. Gin of excess freedom was released from the bottle =)
We always afraid of such a gins in scene content management systems, because they add control difficulty levels.

Collections are not groups. They should not be involved in heirarchical 3d space grouping activities.

A single object can exist in multiple collections. That is a wonderful feature and incompatible with single-parent grouping structure.

Ctrl + G should do exactly what it does in other programs like Maya.

Ctrl + G should create an Empty (can we rename these to Locators?) that has no visual representation in viewport (add “invisible” to the list of “Display as” options) and the currently selected objects should become children of that Empty.

That is it. There is nothing else to think about. That is all 85% of us need.

One minor additional thing that many would also enjoy on top of this is a “Display as” option for empties named something like “Bounding Box of Children”. This makes the empty be represented by a bounding box that encompasses the bounding boxes of all of its children.


http://thinsoldier.com/wip/blender/dynamic-empty-group-parent.gif

One major additional thing that is probably very important to have with “groups” is the ability to change the origin point of the Empty that is the parent (simple when using an invisible empty) without changing the location of the visuals that represents the Empty (important when using “Display as: Bounding Box of Children” but you want a customized origin point for the group)


Parenting objects is the equivalent of “groups” in something like Maya.

Collections are the equivalent of Layers in Maya.

I enjoy the collections system as it is and if someone is struggling with them it would be a good idea to try setting up your workspace like Maya as in make one outliner that does not show collections at all and make another outliner that ONLY shows collections, this makes that outliner similar to the layers window in Maya.

Maya Layers https://www.youtube.com/watch?v=c410VZVkY6g

Maya Outliner

https://i.imgur.com/ba6x07d.png - the item “Table” is the equivalent of Empty in Blender except it is invisible in the viewport. That is all “grouping” is!. The item “Bowl” is a mesh object that is the parent of 4 more objects.

Blender configured to mimic Maya’s Outliner and Layers:

Grouping is Parenting. Parenting is Grouping. Ctrl+G should be a parenting shortcut that simplifies adding an Empty and making the selected objects children of that new Empty automatically. That is all we need. Collections are irrelevant to grouping/parenting.

Parenting in Blender vs. Parenting in Maya

3 Likes

I watched Your comparison betwen Blender and Maya on YT. My pratice betwen Maya and Sketchup showing, that Sketchup have bether solution where is something like “imersion” to entry into groups/components additionaly, then user not need to work with outliner - 2x click, and you are inside other viewport orientation of group/component like integrated object/assemby to operate where any object can be individually moved/edited.
https://developer.blender.org/T86052#1129275

What is advantage for “commponet” and imerssion in relation to parent? On Viewport user not need to find the parent if want move whole, and not need collection that is “compresed” to move all or select all.

Right now is problem with collections coz can’t be used for this modifier as typical object and limiting.

Collections as dir should be neutral, and should exist new type of object like component normal that organizig object inside or component unique, that was duplicated but is not linked (changes inside not changing the main patern) - then is more like Group. But the component normal like added collection must have option to be edit as all inside in any place, not only the main patern. Then we can manage the components in collections etc. what is waek around sketchup and forcing always parenting to organize something to manage layers in right way.

This feature request going in direction to grouping collections with status as Group and this as Primary object. I think is due that, coz Collection as Primary is not speending needs as Collection of Collections. Group of Collections?

I second what Keavon suggested and I would like to add this:

Currently if we want to organize objects into a sub collection, and use the m - move to collection - new collection:

The objects are moved outside their current collection. We now have to move the newly created collection back into the original collection.

Having ctrl+g group the selected elements into a new collection and stay in the collection where they already are would be very welcome.

1 Like

I came here from @thinsoldier link on Right Click Select, and I can’t stress enough how much I agree on the Idea of Maya like grouping and the “bounding box of children” empty drawing mode.
Collection are fine, they can be improved, but yeah, IMHO CTRL+G should do exactly what thinsoldier describes.

1 Like

I do agree that you should be able to double-click a collection instance, wherever in space it may be, and edit its contents on the spot, but that is not heirarchical grouping that most people think of when they think ctrl+g in other programs.

I agree with most of that but it should be on the M key and not ctrl+g

But should be maybe and in different way. The last disscus before posts lost history of all was good, I mind the convert Collection to some Empty as parent with childs and in opposite direction (convert Empty to Collection). Blender now doing this by Group from collection, but can be editable - and this is what we need I think.
We must have easy option to duplicate whole objects relations in parent with childs.

Discussing Common Groups paradigm?

This disallow to select the entire group by selecting an individual item of it.
Also, it sounds like a simple solution to script.

It seems to be that way in Maya and I was just proposing the simplest things to get a bare minimum version of groups. Some others have suggested an open/closed or unlocked/locked state for groups that allow selecting the whole group by clicking any child when the group is closed/locked. I would prefer for groups to always behave like the closed/locked state and you double click child objects in order to select them individually. But, I’ve seen some other conversations about double-clicking in the viewport in general that make it seem like my wish would never happen.

Please consider making it if you have the time and ability :slight_smile:

1 Like

The problem is that Maya groups are not related to Common Groups paradigm, presented in 3dsmax/AutoCAD/Sketchup/Revit and other software.
Maya groups are related to parenting systems.

I am not a programmer, I hire programmers to solve different tasks.

I was thinking maybe similar to how the move tool has “Affect Only [origins, locations, parents]” perhaps selection tools could have a mode for “Select Only [objects that have children, objects that have parents]”. In select only objects that have children mode clicking any child or grandchild would select the parent?

1 Like

Interesting idea, such a movement will allow to cover some basic demands better than regular parenting, but another point of common groups is the ability to keep groups inside of groups, and the ability to edit groups as an objects that contain other objects.
Not sure it is possible via parenting engine.

1 Like

Interesting proposal)
Also, grouping, cumulativity (when some object is placed in different collections) and other system design problems was discussed in Layers Maniphest.