F-Curve Handles cannot be scaled along x-axis in Graph editor #39457

New Issue

David Brennan · 2014-03-27T14:13:26+01:00

David Brennan commented

2014-03-27 14:13:26 +01:00

System Information
Operating system and graphics card

Windows 7, Intel Integrated

Blender Version
Broken: (example: 2.69.7 4b206af, see splash screen)
Worked: (optional)
Blender 2.70
(I'm nearly certain this worked fine in 2.69)

Short description of error
The handles on Keyframes in the Graph Editor along the x-axis cannot be Scaled (stretched) along the x-axis. In the past, you could go to an individual frame, highlight, for instance, the LocRotScale frames, and then go S > X, and those bezier handles would all stretch out. Now, they do not budge.

Exact steps for others to reproduce the error
Based on a (as simple as possible) attached .blend file with minimum amount of steps
(1) Select the default cube
(2) On frame 1, Keyframe the LocRotScale
(3) On frame 20, move the default cube and again Keyframe the LocRotScale
(4) Go to the Graph Editor and highlight the Keyframes on frame #20. To try and make the animation slower, go S > X to stretch the handles out. They will not budge.

(As a note: This has a MAJOR impact on my personal Keyframing - and so I would guess on that of many other users, too. Very often, when I'd want to just make the animation a bit slower, I'd stretch them out. Or, if I wanted a jarring start or end to an animation, I'd just go S > X > 0. Now, none of that is possible, and every single Keyframe has to be moved manually. This is VERY time-consuming and also imprecise.)

**System Information** Operating system and graphics card Windows 7, Intel Integrated **Blender Version** Broken: (example: 2.69.7 4b206af, see splash screen) Worked: (optional) Blender 2.70 (I'm nearly certain this worked fine in 2.69) **Short description of error** The handles on Keyframes in the Graph Editor along the x-axis cannot be Scaled (stretched) along the x-axis. In the past, you could go to an individual frame, highlight, for instance, the LocRotScale frames, and then go S > X, and those bezier handles would all stretch out. Now, they do not budge. **Exact steps for others to reproduce the error** Based on a (as simple as possible) attached .blend file with minimum amount of steps (1) Select the default cube (2) On frame 1, Keyframe the LocRotScale (3) On frame 20, move the default cube and again Keyframe the LocRotScale (4) Go to the Graph Editor and highlight the Keyframes on frame #20. To try and make the animation slower, go S > X to stretch the handles out. They will not budge. (As a note: This has a MAJOR impact on my personal Keyframing - and so I would guess on that of many other users, too. Very often, when I'd want to just make the animation a bit slower, I'd stretch them out. Or, if I wanted a jarring start or end to an animation, I'd just go S > X > 0. Now, none of that is possible, and every single Keyframe has to be moved manually. This is VERY time-consuming and also imprecise.)

David Brennan commented

2014-03-27 14:13:26 +01:00

Changed status to: 'Open'

David Brennan commented

2014-03-27 14:13:26 +01:00

Added subscriber: @davidbrennan

blender-admin commented

2014-03-27 14:13:26 +01:00

#39316 was marked as duplicate of this issue

Henrik Aarnio commented

2014-03-27 14:18:00 +01:00

Added subscriber: @hjaarnio

Henrik Aarnio commented

2014-03-27 14:18:00 +01:00

Previously (pre-2.70) scaling a keyframe with automatic handle type set the handles to aligned type, and now it doesn't. Scaling automatic handles does nothing, while when the transform changed the handle type scaling individual keyframes to change handle length was possible. This seems like a regression, although might be desired in some cases.

Joshua Leung was assigned by Henrik Aarnio

2014-03-27 14:18:41 +01:00

Campbell Barton commented

2014-03-27 21:48:32 +01:00

Added subscribers: @JoshuaLeung, @ideasman42

Campbell Barton commented

2014-03-27 21:48:32 +01:00

This is from my own commit, 6cc5bdc99e

The problem I found is - if you wanted to increase the amplitude of a curve, or make it take longer/shorter.
Auto handles would always be removed, and in many cases this isn't needed to change the overall scale of a curve.

You don't have to move every keyframe manually - you just have to set the handle type if you don't want it to be auto,
which you can do before transforming.

Setting handle types to aligned can be done by pressing V, A

Can you upload Blend where you would want handles to scale too? (maybe this can be detected somehow).

@JoshuaLeung
What are you thoughts on this? - it seems like there should be ways to do both actions.

Brainstorming.

Add a way to scale curve handles - since in this case this is the goal anyway, if its explicit you want to scale the handles rather then the distance between them, changing the handle types makes sense in that case (Alt+S could be used for eg).
Make it an option (I'd rather not)
Use the 'Show Handles' (This is using a view option to effect how transform works, so Id rather not do that too)
Treat single handles differently (doesn't actually address this report)
Detect these cases: Do a min-max on the transform data, If you scale on an axis which has 0.0 size, change handle types. (seems overkill and a bit hidden)
Add an option in the Handle Types menu to disable auto (so non auto handles are left alone).

If this commit is too disruptive and needs to be reverted, there really should be a way to scale without changing handle types IMHO, even if its accessed via some option, key-binding.

This is from my own commit, 6cc5bdc99e The problem I found is - if you wanted to increase the amplitude of a curve, or make it take longer/shorter. Auto handles would always be removed, and in many cases this isn't needed to change the overall scale of a curve. You don't have to move every keyframe manually - you just have to set the handle type if you don't want it to be auto, which you can do before transforming. Setting handle types to aligned can be done by pressing `V, A` Can you upload Blend where you would want handles to scale too? (maybe this can be detected somehow). @JoshuaLeung What are you thoughts on this? - it seems like there should be ways to do both actions. Brainstorming. - Add a way to scale curve handles - since in this case this is the goal anyway, if its explicit you want to scale the handles rather then the distance between them, changing the handle types makes sense in that case (Alt+S could be used for eg). - Make it an option *(I'd rather not)* - Use the 'Show Handles' *(This is using a view option to effect how transform works, so Id rather not do that too)* - Treat single handles differently *(doesn't actually address this report)* - Detect these cases: Do a min-max on the transform data, If you scale on an axis which has 0.0 size, change handle types. *(seems overkill and a bit hidden)* - Add an option in the **Handle Types** menu to disable auto (so non auto handles are left alone). If this commit is too disruptive and needs to be reverted, there really should be a way to scale without changing handle types IMHO, even if its accessed via some option, key-binding.

Joshua Leung commented

2014-03-27 23:04:32 +01:00

Added subscribers: @ignatz, @mont29

Joshua Leung commented

2014-03-27 23:04:32 +01:00

◀ Merged tasks: #39316.

Joshua Leung commented

2014-03-27 23:19:23 +01:00

I'm still not convinced about the case for why that offending commit is needed. TBH, I'd been planning on just reverting that commit - it's just that I haven't gotten around to that on my todo list this week yet!

What is clear though is that it is quite clunky to have to remember to change handle types first.

If we do eventually agree that it is really necessary to do both, I propose that we restrict the handle type changing to "individual pivots" mode (yes we have such a thing in the graph editor, like in 3d view).

Alternatively/additionally, we should ensure that it is ALWAYS possible to manipulate the handles at will if there's only a single keyframe selected. Again, any nominal consistency with 3d view behaviour is here is IMO ill founded and unnecessary

I'm still not convinced about the case for why that offending commit is needed. TBH, I'd been planning on just reverting that commit - it's just that I haven't gotten around to that on my todo list this week yet! What is clear though is that it is quite clunky to have to remember to change handle types first. If we do eventually agree that it is really necessary to do both, I propose that we restrict the handle type changing to "individual pivots" mode (yes we have such a thing in the graph editor, like in 3d view). Alternatively/additionally, we should ensure that it is ALWAYS possible to manipulate the handles at will if there's only a single keyframe selected. Again, any nominal consistency with 3d view behaviour is here is IMO ill founded and unnecessary

Campbell Barton commented

2014-03-28 00:23:02 +01:00

having a special case for scaling single keyframes, works nicely for scaling on the X axis, but scaling Y axis it would change handles unnecessarily.

Was thinking perhaps it could work like this:

Transform changes handles (as before)
After transformation executes, detect if any handles that started as auto-handles would remain the same if kept as auto handles
Set auto handles for these.

While this seems a bit over complicated, I think its not actually that big of a deal to do, and it means auto-handles can be kept in many cases.

having a special case for scaling single keyframes, works nicely for scaling on the X axis, but scaling Y axis it would change handles unnecessarily. Was thinking perhaps it could work like this: - Transform changes handles (as before) - After transformation executes, detect if any handles that started as auto-handles would remain the same if kept as auto handles - Set auto handles for these. While this seems a bit over complicated, I think its not actually that big of a deal to do, and it means auto-handles can be kept in many cases.

Daniel Salazar commented

2014-03-29 02:16:28 +01:00

Added subscriber: @zanqdo

Daniel Salazar commented

2014-03-29 02:16:28 +01:00

I think the value of preserving handle types is higher than the value of not having to change te handle type before applying this kind of specific 1 frame scale. It will of course raise some bug reports since it's a change in behavior but I like it. It preserves valuable user choices instead of trowing them away without notice.