Automerge Editing option really, really should have old good button in 3D View. I forgot to disable it and noticed that some fine details are gone. 20 minutes had passed and there is no way to bring it back. It was really useful button, too useful to just throw it away.
3 Likes
While great, I’d also add a pin option. so that some modifiers that you choose are always visible. Sometimes it’s good to have two or more visible modifiers to copy/paste values or compare stuff between them.
5 Likes
@billrey @Oskar
You should probably ask some animators around the studio, like the ones who worked on Spring, if they agree with sudden changes to the way keyframe selection work or if it’s really a bug.
Because AFAIK and like user “foodi” said, this is because of how the keyframes are by default set to Auto Clamped, which means that they will try to adjust their shape automatically, if you don’t also select the handles.
And I’m an animator and can think of a number of cases where I’d want the curves to adapt automatically (which is a plus behavior compared to the limited Maya or After Effects examples) or cases where I’d want to select the keys without selecting the handles. You basically removed that option from whoever wants to do that.
Do the people who worked on Spring complained? Because if not, it’s probably because those things were working as expected.
Edit: I just fired up 2.79 and 2.49 and the same expected behavior is there: if you only select the middle, you only move the middle and the curve adapts (unless it goes above or below the extremities).
Which basically means that for a good decade, or even more if this behavior comes from previous versions, this behavior is present and working as intended. If someone wanted to complain, they had 10 years to do so… and so far this is the only complaint one that I’ve seen so far.
1 Like
There’s no ‘sudden change’. I changed the IC keymap, which they don’t use, to work like the built-in keymap.
I would rather make it work differently so you can box select the handles, but cannot due to the aforementioned bug.
Keyframe selection is unrelated to the default handle type, which hasn’t changed in 2.8. It’s still Auto Clamped by default.
1 Like
Well, selecting only the middle keyframes not also selecting the handles was NOT a bug apparently, or I misunderstood what you are saying?
Did you change so that If I box-select the keyframe will automatically select the handles? This is changing decade old expected and loved behavior for animators.
But I agree that not being able to box-select the handles only was always a issue that I had. (Which is different from auto-selecting handles when I don’t want to)
Anyway, if you check Orkar’s original complaint, he is clearly selecting only the middle, not the handles. And like I’ve proven with the above gifs, this is working as intended.
But, I once complained about not being able to work with multiple handles of different curvers on the Animation Improvement topic, and someone answered that there’s an option that helps, does this makes it so that you can box select them as well?
1 Like
@foodi
I gave it a try, but changing the handle type didn’t help. The problem is somewhere else.
@Evandro_Costa
I think there is a misunderstanding. In the example you showed the key is selected by clicking on it.
When you click on the key it works as it should and you can also select the handles by clicking on them.
But when you select the keys with box select, one of the handles stays pinned.
So if you like the box select to work as the click select you have to disable the ability of box selecting the handles (disable “Include Handles”).
Fixing this bug will make possible to box select keys and handles and work as click select does.
1 Like
Yes you seem to be misunderstanding. Selecting only handles or only keys is not a bug, it’s an operator option. By default, box selecting keys will automatically select the handles also. This was the case in 2.7x and previous and is still the case in 2.8. That hasn’t changed.
This has nothing to do with the default handle type, which also hasn’t changed.
If you set the box select operator to be able to select handles and keys individually, there’s an issue with transforming. But it doesn’t work this way by default.
1 Like
Making the toolbar wide enough to display the name of each tool is useful, however it takes up more space than just the icons. To conserve space, I often tweak the width of the toolbar to display the name and be as thin as possible, but to not collapse into displaying only two columns of icons. It’s a small but annoying ordeal 
It would be helpful if the toolbar snapped at the thinnest possible width to display the names of the tools. It already snaps to one and two columns of icons, so why not also snap to the wider display? One could still make the toolbar wider than the position where it snaps, but when the width is near enough, it would snap to that position.
Hopefully, this helps explain what I am trying to describe 
6 Likes
Very well. But this is more complex than might seem at first…
First there is just the complication of having to measure all the visible text lines when you start dragging. No biggie, I guess…
But even if you do that there will be still be collisions between what different users want. By default it breaks at a point that is too narrow to actually display all of “Annotate Polygon” (click and hold on that “Annotate” button to change it). So in that state you might want to prefer a break point that is wider than it is now in order to see all of it.
But I might want it half as wide as that before doing so, so I can see “Select” but I’d prefer the rest to be cut off and end in ellipsis. But I can’t do that right now because it changes to two columns of icons long before that.
These two problems might seem completely at odds, but they can be reconciled because saving the startup file saves this preference. So the breakpoint should be made narrower than it is now (to make me happy) and then we both rely on saving our startup file to get the result we like. So it can accommodate both of us.
So if it were up to me the breakpoints would be closer, more predictable, and accommodate more user preferences.
In the following, how it works now is on the left, how I’d like it is on the right. Each side has three yellow lines of where the arrangement changes. The leftmost one is where it it drags to nothing, which is right on the edge currently. The middle one where it turns to two columns of icons, and the third where it turns into icons plus text. The spacing on the right would feel better and allow narrower “icon plus text” if that is desired.
1 Like
Yes indeed, the breakpoints just seem to be too far apart, meaning the Toolbar has to be extremely wide if you want to see the text.
Was no better remove the hability to resize the T-shelf and make only avalaible by menu or area controls?
In the example above, that would allow to get to about here before it changes to two columns of Icons:
1 Like
This would actually be rather great to fix if you can 
-
Wrong icon for the Light Probe ObData icon on the Properties Editor’s tab (orange U15 instead of green T12):
-
Proportional Edit mode toggle button uses one pictogram for both its states (I21) - enabled and disabled. I20 should be displayed when the mode’s Off and I21 when it’s On, for better state indication.
@billrey - two low hanging fruits to pick by the way of icons update.
1 Like
- Shouldn’t this become a drop down button without a tooltip reading “add new scene by type: new”, since the button triggers regular menu?
BTW, material, texture etc., could get the drop down button instead too.
@billrey The world in cycles is not limited to being a simple material, there are many more things so the icon should not be red color .
2 Likes
I meant to say that the toolbar snaps at the break-point from the two-column icon layout to the name layout (right now it only snaps at the two-column-layout ‘side’ of the break-point but not at the name-layout side), not that it would snap wherever all the names can be fully written without ellipsis.
1 Like