Deleting keyed field's keyframes cleverly pretends to work. #61169

New Issue

Jaggz H · 2019-02-03T23:26:35+01:00

Jaggz H commented

2019-02-03 23:26:35 +01:00

Debian stable.
Build from 2019-01-28 (cad1016c20)

A secondkeyed frame, when removed, does not fully clear the keyframe.More detailed:
Keying a field (VSE -> new Color track -> Opacity field) to 1, then in a later frame keying that one to 0, then removing with Alt-I (over the field), will brown the field and remove the keyframe from the graph, but the values still change when scrubbing (and they all appear brown, between the original 1.0 keyframe and the removed keyframe).

A couple Notes:

I-Key keys the field and makes it yellowish-green. Alt-I causes the field to change brown (which seems to be the color for manually-changed but non-keyed values. ie. it should revert when scrubbing. However, all frame positions between a keyed frame and this deleted-keyframe show as brown. Neat.
Saving and reloading with a fresh blender instance clears this. The fields all appear gray again and their values don't change.

Steps to reproduce (because, if at first you don't succeed, try over and over to make sure you can't succeed):

New blend.
Change to VSE and add a Color track.
Go somewhere midway through track and hit I over the opacity field (to key it to 1.0).
Go later and I-key the field to 0.0.

Alt-I to clear the field makes it brown but scrubbing shows the values changing, as if it were still keyed.

Might be related to:
https://developer.blender.org/T61148

Debian stable. Build from 2019-01-28 (cad1016c20b5) A ***second***keyed frame, when removed, does not fully clear the keyframe.**More detailed:** Keying a field (VSE -> new Color track -> Opacity field) to 1, then in a later frame keying that one to 0, then removing with Alt-I (over the field), will brown the field and remove the keyframe from the graph, but the values still change when scrubbing (and they all appear brown, between the original 1.0 keyframe and the removed keyframe). A couple Notes: - I-Key keys the field and makes it yellowish-green. Alt-I causes the field to change brown (which seems to be the color for manually-changed but non-keyed values. ie. it should revert when scrubbing. However, all frame positions between a keyed frame and this deleted-keyframe show as brown. Neat. - Saving and reloading with a fresh blender instance clears this. The fields all appear gray again and their values don't change. Steps to reproduce (because, if at first you don't succeed, try over and over to make sure you can't succeed): - New blend. - Change to VSE and add a Color track. - Go somewhere midway through track and hit I over the opacity field (to key it to 1.0). - Go later and I-key the field to 0.0. # Alt-I to clear the field makes it brown but scrubbing shows the values changing, as if it were still keyed. Might be related to: https://developer.blender.org/T61148

Jaggz H commented

2019-02-03 23:26:35 +01:00

Added subscriber: @jaggz

blender-admin commented

2019-02-03 23:26:35 +01:00

#61790 was marked as duplicate of this issue

hudson barkley commented

2019-02-03 23:42:16 +01:00

Added subscriber: @snuq

William Reynish commented

2019-02-03 23:52:20 +01:00

Added subscriber: @WilliamReynish

William Reynish commented

2019-02-03 23:52:20 +01:00

I can reproduce this. Even if you remove the keyframe, as you say, it still changes over time.

William Reynish commented

2019-02-04 00:05:15 +01:00

Actually, the bug seems to have nothing to do with the Opacity property, but with using Alt-I. If you use Alt-I to remove keyframes, something isn't being updated correctly.

The problem seems to happen on all properties if you use Alt-I to remove keys.

Actually, the bug seems to have nothing to do with the Opacity property, but with using Alt-I. If you use Alt-I to remove keyframes, something isn't being updated correctly. The problem seems to happen on *all* properties if you use Alt-I to remove keys.

Richard Antalik commented

2019-02-04 00:26:23 +01:00

Added subscriber: @iss

Richard Antalik commented

2019-02-04 00:26:23 +01:00

I was chasing something similar... Sequencer doesn't signal to depsgraph to update data and animdata are evaluated in depsgraph.

Not sure if this can be fixed temporarily, or simply we have to implement depsgraph into sequencer.

To be fair, not sure even if my conclusion of the cause is correct...

I was chasing something similar... Sequencer doesn't signal to depsgraph to update data and animdata are evaluated in depsgraph. Not sure if this can be fixed temporarily, or simply we have to implement depsgraph into sequencer. To be fair, not sure even if my conclusion of the cause is correct...

Richard Antalik commented

2019-02-04 00:33:08 +01:00

In #61169#612940, @WilliamReynish wrote:
Actually, the bug seems to have nothing to do with the Opacity property, but with using Alt-I. If you use Alt-I to remove keyframes, something isn't being updated correctly.

The problem seems to happen on all properties if you use Alt-I to remove keys.

deleting curve in dope sheet editor has the same effect as alt+I.

in curve editor:

right click on channel -> delete channels -> crash
select channel -> move mouse to editor area -> {key del} -> no crash, same effect as alt+I

> In #61169#612940, @WilliamReynish wrote: > Actually, the bug seems to have nothing to do with the Opacity property, but with using Alt-I. If you use Alt-I to remove keyframes, something isn't being updated correctly. > > The problem seems to happen on *all* properties if you use Alt-I to remove keys. deleting curve in dope sheet editor has the same effect as alt+I. in curve editor: - right click on channel -> delete channels -> crash - select channel -> move mouse to editor area -> {key del} -> no crash, same effect as alt+I

William Reynish commented

2019-02-04 00:34:54 +01:00

Alt-I as in Iran :)

I key over a property inserts a keyframe, Alt-I removes keys from the current frame.

Alt-I as in Iran :) I key over a property inserts a keyframe, Alt-I removes keys from the current frame.

Richard Antalik commented

2019-02-04 00:41:08 +01:00

Got that later :)

edited comment...

Got that later :) edited comment...

Baran Yagcioglu commented

2019-02-04 11:32:18 +01:00