Motion curve update mismatch #47762

New Issue

Ignatz · 2016-03-11T15:57:51+01:00

Ignatz commented

2016-03-11 15:57:51 +01:00

Windows 7 Professional 64-bit SP1
Nvidia GeForce GTX 760

Broken: Blender 2.75a ...up to and including current version... 2.77 rc2

Description: When moving a keyframe from within the dope sheet editor the movement of the keyframe within the graph editor does not reflect the true condition of the new curve until the action is finished.

This is a small visualization bug.

It will be seen that when a keyframe is moved in time (along the X axis) from within the graph editor the keyframe handles as well as the associated curve will change as required during the move to constantly reflect changes related to the new position of the keyframe.

When the keyframe is moved from within the dope sheet editor the keyframe will also move within the grpah editor, but the simultaneous updating of handle length and correct curve shape will not be shown. However, when the action is completed, the curve and handles in the graph editor will update to reflect the new, correct position.

curve update visualization.blend

Windows 7 Professional 64-bit SP1 Nvidia GeForce GTX 760 Broken: Blender 2.75a ...up to and including current version... 2.77 rc2 Description: When moving a keyframe from within the dope sheet editor the movement of the keyframe within the graph editor does not reflect the true condition of the new curve until the action is finished. This is a small visualization bug. It will be seen that when a keyframe is moved in time (along the X axis) from within the graph editor the keyframe handles as well as the associated curve will change as required during the move to constantly reflect changes related to the new position of the keyframe. When the keyframe is moved from within the dope sheet editor the keyframe will also move within the grpah editor, but the simultaneous updating of handle length and correct curve shape will not be shown. However, when the action is completed, the curve and handles in the graph editor will update to reflect the new, correct position. [curve update visualization.blend](https://archive.blender.org/developer/F289486/curve_update_visualization.blend) ![screengrab 01.jpg](https://archive.blender.org/developer/F289487/screengrab_01.jpg) ![screengrab 02.jpg](https://archive.blender.org/developer/F289489/screengrab_02.jpg)

Ignatz commented

2016-03-11 15:57:51 +01:00

Changed status to: 'Open'

Ignatz commented

2016-03-11 15:57:51 +01:00

Added subscriber: @ignatz

Bastien Montagne commented

2016-03-12 16:16:18 +01:00

Added subscriber: @mont29

Joshua Leung was assigned by Bastien Montagne

2016-03-12 16:16:18 +01:00

Bastien Montagne commented

2016-03-12 16:16:18 +01:00

Joshua, think this one is for you? ;)

Joshua Leung commented

2016-03-13 07:52:49 +01:00

Technically, this is not really a bug; it is however a glitch that we know about AND have thus-far decided against fixing.

This issue happens because the when transforming keyframes in the Action Editor, we do not rearrange the actual order of the keyframes in the FCurves until the transform is done. We could do so (and it is done for the Graph Editor, because it has to be done as the curves are visible), though so far, the cons of doing so outweight the pros.

Pros:

Graph Editor (if visible) will always show valid curves, and will be updated nicely
On the off-chance that the current frame falls within a zone where the keyframes have been significantly modified, it's less likely that things will go wonky while transforming.

Cons:
3) Slower keyframe editing in Action Editor
4) Significantly more complicated (i.e. really convoluted, hard to maintain, head-scratching + confusing) code needs to be in place to track and remap the "transvert" pointers to refer to the correct keyframe point values, as reordering the keyframes while transforming will constantly invalidate the old mappings. (Note: Although similar code has been created for the Graph Editor, the differences between the two are significant enough that a separate set of code for this will be needed instead)
5) Making these changes is unnecessary when considering the intended use cases of these editors - The Action Editor is used mainly for blocking animation and broad/coarse timing corrections, while Graph Editor is for fine tuning value change over time in "polish" passes (where timing changes less).

  During the blocking phase, it is more likely that animators will be using "Constant" interpolation (i.e. values are held until the next keyframe is encountered, so #2 is not that likely to actually cause much trouble, while #1 won't matter much at all - no handles/curve interpolation to speak of).

  Furthermore, there is likely to be a lot of broad scale retiming (i.e. simply shifting entire blocks of keyframes forward and back, maybe even swapping the order of one or two poses - or maybe just moving a duplicate of an earlier keyframe/keyframes to the end of the timeline). In these cases, even if the Graph Editor is open, the animator is more likely to be focussed on trying to getting the time-placement of that block of keyframes right (i.e. focussed on Action Editor, where transform is happening vs Graph Editor). Sure, things might look weird if you have both open, but it was never intended that you block animations with both open (screen space concerns in particular would suggest a only using either or, I'd think :)

 Now, if doing such broad scale retiming got sluggish because of all the remapping and/or checks for the need for remapping, that would probably be less helpful than if one of the side views just looked a bit weird for a brief moment before fixing itself.

So, overall, IMO it's better that we don't try going in fixing this, as it doesn't seem to be worth it. One or two particular feature changes may warrant a review of this, but until then, I think the current behaviour should be fine.

Thanks for the report anyway :)

Technically, this is not really a bug; it is however a glitch that we know about AND have thus-far decided against fixing. This issue happens because the when transforming keyframes in the Action Editor, we do not rearrange the actual order of the keyframes in the FCurves until the transform is done. We could do so (and it is done for the Graph Editor, because it *has* to be done as the curves are visible), though so far, the cons of doing so outweight the pros. Pros: 1) Graph Editor (if visible) will always show valid curves, and will be updated nicely 2) On the off-chance that the current frame falls within a zone where the keyframes have been significantly modified, it's less likely that things will go wonky while transforming. Cons: 3) Slower keyframe editing in Action Editor 4) Significantly more complicated (i.e. really convoluted, hard to maintain, head-scratching + confusing) code needs to be in place to track and remap the "transvert" pointers to refer to the correct keyframe point values, as reordering the keyframes while transforming will constantly invalidate the old mappings. (Note: Although similar code has been created for the Graph Editor, the differences between the two are significant enough that a separate set of code for this will be needed instead) 5) Making these changes is unnecessary when considering the intended use cases of these editors - The Action Editor is used mainly for blocking animation and broad/coarse timing corrections, while Graph Editor is for fine tuning value change over time in "polish" passes (where timing changes less). ``` During the blocking phase, it is more likely that animators will be using "Constant" interpolation (i.e. values are held until the next keyframe is encountered, so #2 is not that likely to actually cause much trouble, while #1 won't matter much at all - no handles/curve interpolation to speak of). ``` ``` Furthermore, there is likely to be a lot of broad scale retiming (i.e. simply shifting entire blocks of keyframes forward and back, maybe even swapping the order of one or two poses - or maybe just moving a duplicate of an earlier keyframe/keyframes to the end of the timeline). In these cases, even if the Graph Editor is open, the animator is more likely to be focussed on trying to getting the time-placement of that block of keyframes right (i.e. focussed on Action Editor, where transform is happening vs Graph Editor). Sure, things might look weird if you have both open, but it was never intended that you block animations with both open (screen space concerns in particular would suggest a only using either or, I'd think :) ``` ``` Now, if doing such broad scale retiming got sluggish because of all the remapping and/or checks for the need for remapping, that would probably be less helpful than if one of the side views just looked a bit weird for a brief moment before fixing itself. ``` So, overall, IMO it's better that we don't try going in fixing this, as it doesn't seem to be worth it. One or two particular feature changes may warrant a review of this, but until then, I think the current behaviour should be fine. Thanks for the report anyway :)

Joshua Leung commented

2016-03-13 07:53:07 +01:00

Changed status from 'Open' to: 'Archived'

Joshua Leung closed this issue

2016-03-13 07:53:07 +01:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Motion curve update mismatch #47762