Yes, if fixed we could do both, right.
By default, keyframe handles in Blender are set to Auto Clamped. If you select a key and hit V, you can change the handle type and see different behaviours. For example the Aligned setting will make the key behave the way you expect it to in Maya etc.
2 Likes
No paper cutā¦ I just wanted to say, Iām LOVING the new color icons. They look really nice and they do help A LOT! Thank you!
Three observations here:
1.- The cross is off center.
2.- You can not delete the textures directly (it is essential to do it from the Shader Editor).
3.- It would be nice to be able to directly access the options of mixing textures from the tool, like in BPainter:
2 Likes
and add Brush, color and blend mode to RC in Painting mode (please)
4 Likes
Because the size of the bones is only visible in B-Bones or Envelopes, the Bone Size active tool should automatically and temporarily jump to one of these display modes.
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?