Page MenuHome

can't change aligned handle length when pared with free/ vector curve handle
Closed, ResolvedPublic

Description

System Information
gnu linux 64 bit/fedora 20/intel cpu/nvidia gpu

Blender Version
Broken: d1cf350
Worked: 2.70a

Short description of error
If you have a keyframe with a vector/free handle on one side and aligned on one side in the graph editor you can no longer change the length of the aligned handle.
Example of this is having a linear section of the curve with a ramp into it. editing the aligned lenght alows adjusting the amout of ease into the linear section
Exact steps for others to reproduce the error
Open the attached file


try to change the length of the selected handle (doesn't work)
used to work in 2.70a

Edit: this bug is caused by fix for T38594

Details

Type
Bug

Event Timeline

bassam kurdali (bassamk) set Type to Bug.
bassam kurdali (bassamk) created this task.
bassam kurdali (bassamk) raised the priority of this task from to Needs Triage by Developer.

I can confirm this behavior. The tension arm on the left side of the anchor is completely locked.

This may have something to do with some requested changes that were recently made to the curve tension arm editing.

Those changes were not completely finished and still have (other) bugs.

Those other problems are listed in report T39982 (not yet fixed).

But this problem is new to me and is not listed in that report.

@Joshua Leung (aligorith), think this is because of your fix which was intended to improve behavior of editing aligned handles.

Sergey Sharybin (sergey) triaged this task as Confirmed, Medium priority.May 15 2014, 3:29 PM

Note, this also gives very odd results just dragging the entire keyframe to the bottom right (but dragging around from side to side is odd whatever you do)

Compare before -> after (bottom).

The keyframe IMHO shouldn't change handle length at all when aligned and dragging the entire keyframe

Attached 2 possible fixes.

This treats fcurves differently since vertical distance isnt equivalent to horizontal with fcurves.

This basically reverts the change to how it was in last release.

At this stage, I'm leaning towards simply reverting any/all fixes made since the last release regarding how aligned handles are handled, and simply defining it all as "won't fix" territory.

Of course it sucks that one of the handles always seems to wildly overshoot when using aligned handles. But, I've personally just always viewed this as just one of the quirks that come with such a feature; it happens, but if it really becomes a problem when doing fine tuning, we can still just set the offending handle to "free" and manually tweak it into submission.

@Joshua Leung (aligorith)

Is this really so hard to fix? :(

I notice the following about this 'locked' condition.

Changing the handle type of the surrounding anchor points (A, C) seems to have no effect on the condition.

On the other hand, if you switch the handle type of anchor point B from Aligned to Free and then back to Aligned you will find that the curve is unchanged but both handles are now free to move again. After that, both handles remain editable.

It makes me wonder just how the handle got 'locked up' in the first place.

Forgot to post the image.

Checked on old/new behavior.

My patch:

reverts behavior to what it was in 2.68.

While the old behavior does give some issues with overshoot (see: T38594), generally I much prefer it to what we have now.

We could resolve the issue by passing in an aspect value to calchandleNurb_intern, this way T38594 can fixed by making fcurves behave like regular 3D curves, but passing in values from graph editor to calchandleNurb_intern seems like it could be error prone too :S.

@Campbell,

I have a suggestion that might help.

Before explaining, I would like to say that I really appreciate the time you guys have put in to try to correct what I see as doubtful behaviour in the curve editor. Of course, this isn't as easy as writing code from scratch. You are trying to patch certain behaviour, but have to respect what is already there. It is a thankless task at times.

I see that you guys are ready to go back to the previous code. And I know you guys have your hands full with other more pressing bugs and performance issues. And anyway, I cannot comment on anything that has happened since I'm no math whiz and the little amount of programming I've done wouldn't impress anyone.

But here is the idea.

What if when editing a single handle of an aligned pair you do as follows:

A) Select a single handle for editing (on either side of the anchor).

B) If 'G' is pressed to move that handle then the length of the handle on the opposite side is temporarily stored.

C) The selected handle is now moved to a new location.

D) As soon as the move is finished and the mouse button released the following automatically happens...

E) The handle on the opposite is subjected to a scaling operation (using that stored value) so as to pull its length back to what the user would have expected. This scaling operation would have to respect both the new arm angle as well as the scaling of the graph in both X and Y so as to give the impression that handle has maintained its original length (or even just something close to its original length)

Note: I would again point out that arbitrarilly locking the X position of the opposite control arm to its original X position is probably not a good idea.

I admit that this suggested solution is a bit 'Micky Mouse' as an approach. This would definitely give something of a surprise 'jump-to-position' effect at times, especially when the overshoot of the opposite arm was rather severe. On the other hand, it would probably save a lot of fussing since most of that wild overshoot effect is seldom wanted (in my opinion). And if that amount of overshoot really WAS wanted, then it is still a simple matter for the user to select that opposite arm and pull it up into some extreme position. But as it stands now, I think that most of the animators are forced to do a second select and move of that control arm anyway in order to compensate for the crazy overshoot, so this approach might ultimately be a time saver.