Page MenuHome

Change operators to add new "group" collections to the scene
Changes PlannedPublic

Authored by Hans Goudey (HooglyBoogly) on Jan 8 2021, 5:11 AM.

Details

Summary

This commit changes the behavior of the "Add" and "Create" collection
operators (found in the property editor and under ctrl-G respectively)
so that the new collections are added to the scene collection heirarcchy
as children of the active collection.

Without this patch, when collections are created with these methods they
are not linked to the current scene. This make it necessary to switch to
the "Data API" or "Scene" display modes in the outliner, or look in the
"Collections" panel in the property editor to see that the operator
actually worked. In fact, a common piece of feedback from users about
these operators (especially ctrl-G) is that they don't work!

Besides that, there are a few more reasons to change the behavior:

  1. It's consistent with the "Link to Collection" operator, which actually provides the option to create a new collection.
  2. It creates a teachable moment in the outliner when the user sees clearly that objects can be in more than one collection.
  3. It provides more visual feedback, which can be a starting place for improving the "grouping" behavior of collections.

One downside of this change is that there may end up being more clutter
in the outliner, as new collections created with these methods will be
linked to the scene, and therefore displayed, by default. However, the
outliner is meant to display these sort of things, and the collections
can be easily collapsed, or even moved inside another collection.

The naming and tooltips of these operators are also slightly adjusted
to be more clear about what they actually do.

Diff Detail

Repository
rB Blender
Branch
new-collection-link (branched from master)
Build Status
Buildable 12041
Build 12041: arc lint + arc unit

Event Timeline

Hans Goudey (HooglyBoogly) requested review of this revision.Jan 8 2021, 5:11 AM
Hans Goudey (HooglyBoogly) created this revision.
source/blender/editors/object/object_collection.c
465

You could make a convincing argument that these two operators should be merged somehow, and I'd agree, but that's out of the scope of this patch.

Hi Hans,

I could not agree more with all the points you listed. This gets a go from me. From looking at the code it's exactly what I expected, but I didn't compile it yet. A discussion on why we need Ctrl+G when we have M (which can also add objects to a new collection) should follow, but that's outside of this scope - it's great that we make that behavior understandable first!

Cheers,
Thomas

+999!

This should be considered a fix and make it to 2.92, since the current behavior of Ctrl+G in master is pretty useless.

This revision is now accepted and ready to land.Jan 10 2021, 3:42 AM

As discussed in the UI meeting, this should probably link Edit: move! the objects to a new collection - in real grouping systems, creating a group also doesn't suddenly make the objects appear another time in the scene hierarchy. The linking of objects (having objects in multiple collections) is pretty weird and confusing, I'd rather not expose it for simple operations like Ctrl+G.

One thing to consider is making the new collection an instanced collection. That way selecting any object of the group selects the entire group, and the entire group transforms together. Mimicking what other apps do. Issue is when users want to edit the individual objects - think they'd have to link it into a new view-layer and do the edits there, or something like that. We could automate this, in a way it's a temporary local view for the source collection.
A good idea might be operator options for OBJECT_OT_collection_add: [ ] Instance Collection; [Link Objects | Move Objects | Add Objects]

No matter what we go for here though, the real issue is the lack of a proper grouping system as typical for numerous other graphics apps. Hopefully this will be there in future, so I look at this as transitional change.

As discussed in the UI meeting, this should probably link the objects to a new collection - in real grouping systems, creating a group also doesn't suddenly make the objects appear another time in the scene hierarchy. The linking of objects (having objects in multiple collections) is pretty weird and confusing, I'd rather not expose it for simple operations like Ctrl+G.

One thing to consider is making the new collection an instanced collection. That way selecting any object of the group selects the entire group, and the entire group transforms together. Mimicking what other apps do. Issue is when users want to edit the individual objects - think they'd have to link it into a new view-layer and do the edits there, or something like that. We could automate this, in a way it's a temporary local view for the source collection.
A good idea might be operator options for OBJECT_OT_collection_add: [ ] Instance Collection; [Link Objects | Move Objects | Add Objects]

No matter what we go for here though, the real issue is the lack of a proper grouping system as typical for numerous other graphics apps. Hopefully this will be there in future, so I look at this as transitional change.

well put! +1

As discussed in the UI meeting, this should probably link the objects to a new collection - in real grouping systems, creating a group also doesn't suddenly make the objects appear another time in the scene hierarchy. The linking of objects (having objects in multiple collections) is pretty weird and confusing, I'd rather not expose it for simple operations like Ctrl+G.

I don't recall that this topic was completely settled there. One one hand I agree-- seeing the object twice is a bit odd at first. But on the other hand, this is the grouping system we have. It isn't perfect, but the behavior needs to live within the design of Blender's collection system.
So to me, the statement "I'd rather not expose it for simple operations" doesn't make much sense. The underlying behavior is complex either way-- the choice is whether you expose the complexity in a useful way or if you hide it and leave users confused if Blender is even working.

One thing to consider is making the new collection an instanced collection. That way selecting any object of the group selects the entire group, and the entire group transforms together. Mimicking what other apps do. Issue is when users want to edit the individual objects - think they'd have to link it into a new view-layer and do the edits there, or something like that. We could automate this, in a way it's a temporary local view for the source collection.

While this sounds like an interesting idea, it's a large design topic, so I think it's outside of the scope of this patch.

A good idea might be operator options for OBJECT_OT_collection_add: [ ] Instance Collection; [Link Objects | Move Objects | Add Objects]

I think you mean that this new behavior should be an option? I'm not sure what "Add Objects" would do in this case.
If not being an option is a deal-breaker here, I'm happy to add an operator property to control it. At least if people have the redo panel open it might make more sense.

As discussed in the UI meeting, this should probably link the objects to a new collection - in real grouping systems, creating a group also doesn't suddenly make the objects appear another time in the scene hierarchy. The linking of objects (having objects in multiple collections) is pretty weird and confusing, I'd rather not expose it for simple operations like Ctrl+G.

I don't recall that this topic was completely settled there. One one hand I agree-- seeing the object twice is a bit odd at first. But on the other hand, this is the grouping system we have. It isn't perfect, but the behavior needs to live within the design of Blender's collection system.

@Julian Eisel (Severin) As I unfortunately was not able to attend said meeting, I can't tell what you agreed on. But I vote against re-imagining the underlying system and fix existing things first. The original issue was that grouping objects with the mentioned methods was leaving people wondering what happened. This is imho resolved with this patch.

So to me, the statement "I'd rather not expose it for simple operations" doesn't make much sense. The underlying behavior is complex either way-- the choice is whether you expose the complexity in a useful way or if you hide it and leave users confused if Blender is even working.

One thing to consider is making the new collection an instanced collection. That way selecting any object of the group selects the entire group, and the entire group transforms together. Mimicking what other apps do. Issue is when users want to edit the individual objects - think they'd have to link it into a new view-layer and do the edits there, or something like that. We could automate this, in a way it's a temporary local view for the source collection.

While this sounds like an interesting idea, it's a large design topic, so I think it's outside of the scope of this patch.

I'm totally in for giving groups a transformation matrix, giving them different outlines and making it more similar to other applications, but I would not tackle that with this patch. And I really doubt that we should now redefine the behavior of G - let's not create too many construction sites. Earlier, when M was "move to layer" and Ctrl+G was "group objects", the distinction was easier. Now with the mixed situation that we caused by mangling everything together in Collections and redefining M to "move to collection" the situation is worse - we should fix the pressing issue first (not detecting any change when grouping objects).

A good idea might be operator options for OBJECT_OT_collection_add: [ ] Instance Collection; [Link Objects | Move Objects | Add Objects]

I think you mean that this new behavior should be an option? I'm not sure what "Add Objects" would do in this case.
If not being an option is a deal-breaker here, I'm happy to add an operator property to control it. At least if people have the redo panel open it might make more sense.

With "redo panel" you mean the "adjust last operator panel"? If so, that's a fine solution...

Best, Thomas

I think putting objects in multiple collections in the scene hierarchy is not something that we should encourage, it's mostly confusing and not that helpful in my opinion. An operator that does this should be more explicit about it.

There are also still reasons to create collections not linked to the scene. For example for collision, instancing, effectors, booleans etc, where you want to select a subset of objects in the scene but not change the scene hierarchy.

What I would suggest is to show a popup, with a name for the new collection, which I think is good to encourage users to set immediately. And then some options, possibly:

  • Link Collection to Scene (default to enabled)
  • Move Objects into Collection (default to enabled, only active when the above option is enabled)

It can be done as operator options in the redo panel, but I think a blocking popup is better for this case.

Hans Goudey (HooglyBoogly) planned changes to this revision.Feb 24 2021, 5:42 PM

Okay, I'll work on making this an operator option, at least for the operator controlled by the ctrl-G .

I noticed I said something wrong in my comment above. In the first sentence it should say "this should probably move the objects to a new collection". That's the consensus from the UI module as far as I remember, and the rest of my comment tries to justify that. So yes, I agree with Brecht's points.

Mockup of the blocking popup based on Brecht's suggestions (and a friendly nudge for this to be tackled for the LTS :)

When pressing Ctrl+G, the user is prompted with the following dialog:

  • The name field should be in focus, so the user can start typing the new collection name right away.
  • The button to confirm should be the default action so the user can hit Enter to quickly accept and dismiss the dialog.

The experience would be:

  • Ctrl+G, type the new collection name
  • Hit Enter once to accept the name
  • Hit Enter again to accept the dialog

Optional: The operator could have a confirm option, so advanced users can disable the prompt by editing the keymap.

(I know in reality the confirm button would be OK and there'd be no way to cancel other than moving the mouse away, but I'm adding this for completeness).