Visual Studio Code - Alt Click
Unity - Alt Click
UE4 - Shift Click
That’s weird C4D would be such an outlier using Ctrl. But those kinds of paper cuts are the things the big proprietary software companies ignore in perpetuity and they’re happy to keep their quirks.
I was unaware there is actually a somewhat wider usage of Shift than I thought— I don’t use Maya, Houdini, or UE4, but those appear to be the big three that use Shift. All the other big programs seem to have settled on Alt, or forgotten to even implement it as a feature. But there’s still Unity, Photoshop, Illustrator, InDesign, all of Adobe’s other big programs, and VS Code. I would advocate for at least using both options, because users of programs that implement Alt account for a broader industry but that is certainly fair that people switching from Maya or Houdini may expect Shift.
@natecraddock
Thanks for all the awesome work. For using Blender in a professional environment these features are amazing!
I dont know if this is outside the scope of your outliner project but it seems low hanging fruit with a lot of usability and I would dare say essential missing feature.
Basic idea: Right click those broken collection link icons in the outliner and choose to relocate or reload directly from the context menu in the outliner.
Once again thanks for your contributions. You are a hero
It will only deselect the first clicked item, and only after release. Also if you start on a deselection run and continue over to items that are not active in the mode column, it will activate them, instead of leaving them be.
Also, I think it’s smart to change the dot to the mode icon on hover. It makes it very clear that a change in state can happen, which is great for discover-ability. But I still think that the hover color should be considerably more de-saturated. It’s really strange when you click something off in the mode column only to have the icon still present because that is where your mouse is. It almost feels like a bug, though it’s not at all. Without a visual difference to signify a change in state it doesn’t seem like the click has done anything:
A grid and folder view mode would be very interesting. Or even something similar to a knot tree. Even if it was just to organize a little and then go back to the list view. In a file full of things it would really make a difference to the visual understanding of the scene.
Hey everyone! I’ve shared a video on my weekly report with the current state of the project. I would appreciate some testing this last week to help find some of the remaining bugs.
I haven’t tested this branch for days, and I liked seeing the Exclude Checker as a column on the right side, it looks more orderly and it reads better.
I make some proposals for the Color Theme, which I think helps to better understand the structure and function of objects.
1 · Color the hierarchy triangles of the Collections.
2 · Brighten and reduce a little contrast to the background
3 · Contrast with the dark background and light frame, the box of the active objects.
I’m playing with the outliner right now. So far i like all the changes Great job.
A possibility to drag modifiers(horizontally) when they are collapsed would be nice addition
but not that important.
The only thing i don’t like is the management of parented objects - didn’t change much from current stable.
For example when i drag parent object between collections children should be moved to.
Deleting parent/collection - default behavior should be to delete children to.
I relay cannot find any logical reason to keep the current uintuitive behavior…
Even deleting parent in the 3d viewport should at least ask if the children are to be deleted - but probably out side of scope.
Is there any chance that this behavior could still be tackled?
Really love the new changes. Manual sorting works like a charm and colors make it easy to distinguish between collections.
For me the biggest inconvenience by far is being able to spot active collections or anything inside a collapsed hierarchy. That’s something that’s solved in every other software I’m using, and is very hard to explain to others when showing them the outliner. That light grey overlay is just not enough.
That being said, I think we’ve come very far in terms of usability. Can’t wait to have all this in the master.
Hi @natecraddock, thanks a lot for all your efforts, all these improvements will be extremely beneficial.
Even if I already expressed my doubts on the choice of removing the lines between objects (except in Collections), I imagine that right now it’s late for changing things again.
While I can get used to this “freerer” layout, I really want to stress the importance of reintroducing relationship lines for objects parented to other objects, which right now feel harder to detect.
Besides this, thanks for all of your work on the Outliner !!!
I made the borders less transparent and removed the backgrounds. I really like it! The poor contrast of a light background made things unreadable at times, and I think this is a great improvement. I also made the roundrects square rather than slightly squashed.
It could be nice, but it would be a more difficult change and I don’t think the added code complexity is worth the small inconvenience in adding row drag+drop.
This has been brought up a few times. Don’t have time during GSOC to look into it. Not moving children with the parent between collections is not a bug, but a decision on the workflow when collections were first implemented. but it’s very possible, and perhaps easy to do. On the other hand, I do not agree that deleting a parent object or collection should delete the children. We do have a handy context menu operator Delete Hierarchy for that purpose.
Agreed, and sorry for forgetting to reply to your other posts on the topic. I am not 100% sure, but the code has a TE_ACTIVE flag meant for this very purpose, but it is unused. It would need some work to get this working, but I really do want to add it. Looking back on this, I think that a row highlight is the best option.
A question about the implementation: Should the parents always be highlighted, or only when the child is in a closed subtree? And should this parent highlight be only for the active object, or for all selected objects?
I’d definitely highlight it (the whole row) disregarding if the hierarchy is closed or open, or if it’s a selected or active object or not. (Similar to most other apps) The collection highlight is usually a dimmed/somewhat desaturated color so I never found it distracting. Basically what you’d want is something that is immediately visible in complex hierarchies. If you have a layout scene with thousands of objects and complex relationships ideally you want to select something in your scene and see it right away in the outliner. Seeing which collection/parent it belongs to is really helpful since things can become messy fast.
Speaking of active objects, not sure if it’s handy or just annoying in Blender. I found the whole concept to be the later more often than not (I mean it remembering the active state. Not sure if it’s just me but if I select a bunch of objects I expect the first or last to become active. I can work with either, not so much with an object that was set to active who knows when).
It’s great to know that collapsed hierarchy can be highlighted though, I was afraid there’d be some bigger bumps on the road for that one. You’re doing a bigger service to Blender users than you’d know
Working a lot with parenting (object and bone), I feel this is better, but could still use the short horizontal lines that connect the child objects to the vertical hierarchy lines. We used to have those in 2.7, the Maya outliner has them as well, and they do add a lot of clarity to deeply nested hierarchies such as the ones you end up with while rigging characters. Maybe just for object parenting though, since nested collections already have that colored line that make things very clear.
Also would like to thank you for your work and your uncomparable collaboration with users !
I’m currently loving the way it’s looking. Great job.
There’s one thing that’s been bothering me for ages though.
The extreme padding on the left of the whole outliner. I always have to keep adjusting it to show more of the written info when I scroll. If you compare to how close the right icons are to the border, I think it could shrink by a LOT. This is specially important on smaller screens.
If you have a layout scene with thousands of objects and complex relationships ideally you want to select something in your scene and see it right away in the outliner.
I can’t stress enough how important this feature would be to me. I use a lot of Collections in my scenes to help me stay organized and the amount of time I spend trying to figure out what collection an object is in is embarassing. Having a blatantly obvious highlight would be amazing.
I’ve said it other places but I’ll say it again - this is all amazing work you’ve done and I am so excited for this to go into main. Thanks for your hard work Nate!
@dan2@Dheim@Zsolt_St I’ve started on the parent highlight. It’s a “dumb” solution, but it works very well and took about 1 minute It works surprisingly well, but I already found one issue that I think should be resolved.
The issue deals with the selection syncing algorithm. When you select an object in the viewport the outliner scans over all the objects and then flags the outliner element as active if the object/bone is active. But when you select in the outliner, a different type of element can be come active. For example, if I were to select a collection in the outliner, it would be the new active element.
The parent highlight is based on the outliner active flagged element, not the true active object or bone. I think this may be okay, but it is also possible to make this only show the active object/bone, not for other outliner selected data.
The build with the feature is already live. It only works for objects and bones which I think is just fine. It reuses the mover highlight theme color, but I think a separate color would be best. Any suggestions?
Great job.
