Valid point. Could just keep it consistent with the rest of Blender. Currently holding left click and drag is moving, pressing right click at the same time is opening the right click menu on top of that operation. That could be used to cancel whatever you’re doing.
yes that makes sense, either right click or dragging it to the topbar of the outliner close to the search tool.
I was thinking the same a couple days ago, have no brought it up yet as I wanted to test stuff first. But I think that is a good idea. Right click for reverting during a drag operation.
Just a note here I would like to add, you CAN already use the esc key to revert while dragging, but yes right click is much more accessible
Yes, I’d keep it as simple as possible. Despite me gotten used to it I’m generally not a huge fan of Blenders spread out keymap. If we can do things with one hand why add another button press to it. Also, there are a lot of tablet users out there (at the current company I’m working for, out of 80 modelers maybe a handful are using a mouse, myself included. Definitely a minority, I’m inclined to say a dying breed. I even seen people complaining to HR that were annoyed by clicking noises ) and a lot of mainstream packages are accommodating for that. I do realize it’s not something we can implement in all the workflows, but working in the outliner it’s possible and there are good examples for it.
Yep. Or that. Also I guess dragging something into the viewport/out of the outliner should cancel the operation. That’d probably bring up a bigger conversation about dragging modifiers and materials though, so not sure about other things than collections or objects. Could be a tradeoff between cool features and convenience.
there the selection is completely canceled
Currently, it is the case. A Collection is linked to another by using Ctrl as a modifier.
Tooltip also says that using Shift as a modifier allows to parent ( which has absolutely no sense in context of drag and drop for a collection).
You probably never tried to link a collection into another one.
You are right. Ideal solution should be a drag & drop that is intensively context sensitive and do what is most pertinent relatively to dropping row in outliner.
Currently, in branch, simple stuff does not work.
We can’t reorder children of an object. So, at least that should be working before trying to reorder hierarchies.
Then, there should be a way to unparent/parent and order in one go.
Then, when it will be working, we could test reordering of hierarchies inside same collection.
And after that, reordering and moving of hierarchies from one collection to another one.
Currently, if you parent children from one collection to another object inside another collection, children are not moved to parent’s collection.
If we change that behavior to be a more intuitive move of children to another collection ; how do we handle the case of current case of parenting without collection change ? How do we handle a possible collection nesting or linking ?
Drag and drop in outliner is already doing a lot of stuff. I don’t know if it is possible to keep same amount of features without keeping modifier keys.
How do these other packages link stuff (parenting without moving to collection, linking a collection into another one) ?
To unparent, do you need to drag to first or last row of outliner ?
I’m linking collections from time to time, it’s not something that I do all the time though. Not nearly as much as I parent stuff.
In other packages it varies from software to software. Unfortunately we aren’t allowed to post screenshots, but in Maya for example the outliner and the layer system is decoupled, you don’t have collections per se, you work with hierarchies. In Houdini it’s way more complex, the scene view has a much wider set of functionalities which is required for complex data structures. While non of them could translate well into Blender, sorting hierarchies is straight forward.
You’d just need to drag it out of the collections, same as groups, or you just press the unparent hotkey.
Tried that build and found that dragging object with other objects inside it to a custom collection reset the object hierarchy
maybe it should move object with hierarchy instead?
dragging link works as expected
also I can’t sort objects inside another object
but I think it’s a known issue…
and this is not implemented yet?
anyway Big Thank You for your work!
Blender’s outliner has a Scenes display mode.
Scenes View is perfect to parent objects without moving children to parent’s collection.
So, if things are done to adopt a different behavior for drag and drop according to Display mode.
There is no problem to move children to parent’s collection as default behavior, in View Layer display mode.
There 2 reasons for me not using the scene display mode -
- Blender doesn’t have groups. Next best thing are collections.
- There’s no way to filter out object contents in that mode, makes the whole thing hard to work with.
I admit I probably don’t use collections as intended. But without such a fundamental thing as groups I have the feeling that many others are doing the same thing. The whole “put the same object in many collections” construct is probably much more rare than just having the need for sorting and organizing objects. Just a wild guess though.
Actually, I don’t even care that much how objects to collections parenting is sorted, it’s more about objects to objects. I can sort collections and objects to collections just fine as it is now. That left/right side of the name thing is not working for me very well, when it comes to object parenting.
I think you did not understand what I meant.
I propose to use Scene display mode to link collections or make unusual parenting without move to parent’s collection. (complex and rare uses).
But that should facilitate parenting of objects in View Layer mode by doing parenting of objects with move to parent’s collection.
Most of time, user is using default View Layer mode. And for rare cases, he will use Scene’s one.
Ah, got you. Yes, that’s fine with me, makes sense.
The whole view layer management as it is now didn’t get much love as is. I’d probably use it more often if it was a bit more friendly.
But ye, scene display mode for all the special cases works for me. I do have a crispy $10 bill saying de-coupling functionality won’t fly with the devs though.
Hi Nate, just tried the build! The only thing is that even with manual sorting, objects and collections still can’t be sorted between each other: collections can only be above objects, and objects only below collections.
For me they should both be moved freely in the outliner, right now it seems that objects and collections have separate sorting systems, which is a little bit misleading: with manual sorting, every element in the outliner should be moved wherever the user wants.
This would be nice to resolve, but I don’t know if it’s a good summer of code task. The reason why collections are sorted before objects in the outliner is part of the structure of collections themselves. Each collection has two internal lists, one for child collections, and one for linked objects. The outliner builds the tree from each collection, first the child collections, and then the objects.
The current implementation of manual object sorting is to directly reorder the lists inside each collection, just like manual collection sorting already does. At the moment this is the easiest approach, but it keeps collections and objects separate because their data is separate.
To resolve this, I see two possibilities, but I’m not positive on the full implications of either.
- Collections could be reworked to maintain a single list of children (objects & collections). This might have issues when you only want a list of child objects or collections though.
- The outliner could save the tree in the .blend file. Right now the outliner stores a sort of flattened tree in the .blend file, this is for performace reasons. Again, I’m not sure on the performance/complexity implications here either. Another effect here is that sorting would be per-outliner rather than effecting the whole .blend file.
I’ll look more at this, but for now I think what we have is good.
Nate! I’m already benefiting from your work all the time, the outliner is just becoming better and better, so thank you very much.
In the latest graphicall build I’ve run into some strange stuff, in case you haven’t come across this behavior.
If you reorder objects which are not visible, or reorder objects then toggle their visibility, visibility and selection highlighting becomes mismatched.
As you can see in this video, when I toggle the visibility of an object before reordering it, afterward selecting that object will highlight the wrong object in the viewport, and toggling the visibility of the object will toggle the visibility of the wrong object as well. Though you still edit and move the correct object.
Looks like a big fat bug that you need to report
Yes, I haven’t gotten the bases (which store visibility settings) syncing with the objects yet, that’s still something todo Should be resolved next week.
If I recall correctly Ton mentioned in some interview that he wants to stick to a non overlapping interface. I for one prefer it like it is. I really hate overlapping interfaces, they become a big mess when using multiple sessions.
Opinions are split though, many people would love to have it. My money would be on “won’t happen” unless someone makes a custom build. Lucky thing monitors are getting wider every year.
There is already an addon that does that but it only works on windows
we can already have multiple windows the only missing part is that we can’t keep them always on top.