Page MenuHome

F-Curve Handles cannot be scaled along x-axis in Graph editor
Closed, ResolvedPublic

Description

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.)

Details

Type
Bug

Event Timeline

David Brennan (davidbrennan) raised the priority of this task from to Needs Triage by Developer.
David Brennan (davidbrennan) updated the task description. (Show Details)

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.

This is from my own commit, rB6cc5bdc99e63b05248f132833bfe0259c2a27923

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).

@Joshua Leung (aligorith)
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.

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

Joshua Leung (aligorith) lowered the priority of this task from Needs Triage by Developer to Confirmed, Medium.Mar 28 2014, 12:05 AM

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.

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.

If we can't find a good solution, it may be best to revert my commit for 2.70a and investigate changes for 2.71.

Added this to 2.70 project.

+1 - I think it's best we revert for 2.70a and then work out a better long term solution

reverted, will tackle this after 2.70a is out.