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.
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.
a
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.
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.
Yep, saw that a while ago but never tried it. I think to do something like this neatly it’d need to be done internally. Don’t quote me on this, I’m not a coder.
I for one am super happy I can’t tear off windows even if I wanted to, but if people are keen it could be an option in the preferences.
That’s because it is hard to make floating windows crossplatform.
Also, Floating windows is bad design solution - usually, if you feel need in something floationg across your screen, it means that your work is not organized properly.
So it is missed on purpose.
Obname and meshname are incompatible, so obname can’t be equal to meshname on purpose - this makes handling linked data objects (instances) clear.
Because lists of objects usually are way longer than list of collections. So there are way more indexes to handle.
It could be regular viewport shading color mode.
Are you sure?
Previously 3dsmax and Maya was borrowing ideas from Blender, but it reversed starting at 2.8
Cumulativity…
I don’t think it’s practically possible at GSoC conditions. It is just too deep.
Hierarchical issues are always hard to explain, to solve such issues you have to basically, see them, and to see them, you have to face them regulary during work.
Artists are way more about composition/color perception rather than system/hierarchical perception.
This is why, for example, add-ons such as Collection Manager were started as add-ons.
Granted, that is a difference. I’m not convinced it’s a good enough reason though. I’d argue it’d be more confusing than practical. I’d just keep that functionality consistent, same as in most other softwares.
Yes, I think object colors are used for differentiation as is, since they’re being optional to display that could work for me.
For sure, I would also like to be able to sort objects manually, but I also understand possible realization problems and performance issues on such long lists.
I may be wrong, but in my opinion this is a difficult mathematical problem.
Absolutely, I realize a lot of things might be a lot harder to solve than it would seem to regular users. That’s something that’ll never change though. Like the undo-gate, if it is slow in Blender and instant everywhere else people will throw huge tantrums until it gets solved.
I’d say this is the case especially in Blender, since it’s so accessible and opensource. I can only imagine how the Maya bug tracker would look if people could just comment on it.
I always disliked how finnicky it is to reorder items when you have to aim precisely for the narrow space inbetween items, and if you miss you suddenly did a parenting instead… that happens in Maya, AffinityPhoto and Krita (and probably others!). So if I had to choose I’d keep the shift modifier for parenting. Maybe only in “view layer” mode, or maybe throughout… I mean why not ? → click+drag could be considered the “reorder action” and clift+shift+drag the “parenting action”. Seems pretty simple to me.
…and this suggestion comes from a rigger ! IE somebody who does a LOT of parenting ! What do you guys think ?
edit If indeed we go the way of “both parenting and reordering” then I suggest looking at Krita because in my experience it is where the “hotspots” are better done. Maybe it’s just three thirds, maybe not, but it just feels right and the room for error is pretty minimal.
