Inserting new keyframe deletes previous ones #61173

New Issue

Marc Rohrer · 2019-02-04T11:19:26+01:00

Marc Rohrer commented

2019-02-04 11:19:26 +01:00

System Information
Operating system: Lubuntu (Linux)
Graphics card: GTI 1050i

Blender Version
Broken:
blender-2.80-8a51af7d1c98-linux-glibc224-x86_64

Short description of error

Addding a new keyframe sets back the other keyframed values to previous (see below)

Exact steps for others to reproduce the error

First I insert (in the "N"-panel) a keyframe for rotation, one for location and one for scale. Second I move further on in the timeline (dopesheet) and change some or all of these values and want to insert new keyframes for all the changed values. If I now add a keyframe for the first changed value (e.g. rotation) it automatically sets the other values back to the first keyframe values. Any fix planed on this?

**System Information** Operating system: Lubuntu (Linux) Graphics card: GTI 1050i **Blender Version** Broken: blender-2.80-8a51af7d1c98-linux-glibc224-x86_64 **Short description of error** Addding a new keyframe sets back the other keyframed values to previous (see below) **Exact steps for others to reproduce the error** First I insert (in the "N"-panel) a keyframe for rotation, one for location and one for scale. Second I move further on in the timeline (dopesheet) and change some or all of these values and want to insert new keyframes for all the changed values. If I now add a keyframe for the first changed value (e.g. rotation) it automatically sets the other values back to the first keyframe values. Any fix planed on this?

Marc Rohrer commented

2019-02-04 11:19:26 +01:00

Added subscriber: @CultLess

blender-admin commented

2019-02-04 11:19:26 +01:00

#59555 was marked as duplicate of this issue

Jacques Lucke commented

2019-02-04 11:38:22 +01:00

Added subscribers: @brecht, @JacquesLucke

Jacques Lucke commented

2019-02-04 11:38:22 +01:00

Can confirm this...

@brecht, maybe this is related to blender/blender-staging@83f8f44791?

Can confirm this... @brecht, maybe this is related to blender/blender-staging@83f8f44791?

Hans Nolte commented

2019-02-05 10:55:11 +01:00

Added subscriber: @ditos

Hans Nolte commented

2019-02-05 10:55:11 +01:00

I think it's the same Bug as here.
https://developer.blender.org/T59555

The whole keyframing in Blender seems to be completely confused at the moment.

I think it's the same Bug as here. https://developer.blender.org/T59555 The whole keyframing in Blender seems to be completely confused at the moment.

Jacques Lucke commented

2019-02-05 10:57:00 +01:00

Added subscriber: @s.barbieri

Joshua Leung commented

2019-02-27 14:00:03 +01:00

Added subscriber: @JoshuaLeung

Joshua Leung commented

2019-02-27 14:00:03 +01:00

What's probably happening in this case is as follows:

First, only one of the changed properties got the new values keyframed. All the other changed (but unkeyed) values exist on only on the original datablock at this stage (as set directly by the property buttons)
After the first keyframing operation, the depsgraph gets evaluated. Most likely, this is because we tag it to do a copy-on-write flush (i.e. necessary or else the COW-domain data doesn't get refreshed to know that there is now a keyframe on the current frame, causing problems in the UI with the buttons not showing the right colors).
To deal with the problem of not being able to keyframe/frame-changed evaluated state values in various operators (e.g. clear transform operators, and a whole bunch of other ones), we introduced a "copy back" step to the depsgraph evaluation to flush the results of the animation evaluation back to the original SDNA data. This allows normal operators to see the depsgraph-evaluated results when simply querying the SDNA state.
This is where this bug in particular occurs: Normally there's a write-protection check performed (i.e. see https://developer.blender.org/diffusion/B/browse/master/source/blender/blenkernel/intern/anim_sys.c$1619) that would prevent overwriting. However, here old_value (i.e. SDNA value, unkeyed above) != new_value (i.e. result of animation evaluation, from F-Curves that don't know about this new value, as they don't have keyframes in place to enforce that yet). Hence, the values from the F-Curves get flushed back to SDNA, overwriting the unkeyed values.

In 2.5, we avoided this scenario by making it so that animation evaluation only ever happened on frame change. In other words, if the frame doesn't change, animation evaluation doesn't happen to flush away unkeyed values.
AFAIK, right now doing a COW flush pretty much forces the evaluation of everything downstream from it (since we can't really know whether the change which necessitated the flush occurred because some value changed that other things need to rely on - e.g. a property's value changing after user interaction the UI). Thus, COW flushing often means that animation (+ proxy/override stuff) needs to re-run on top of these newly re-synced datablock(s) to get things in sync with the current frame again (just in case a particular COW/graph is looking at a different point in time).

What's probably happening in this case is as follows: 1) First, only one of the changed properties got the new values keyframed. All the other changed (but unkeyed) values exist on only on the original datablock at this stage (as set directly by the property buttons) 2) After the first keyframing operation, the depsgraph gets evaluated. Most likely, this is because we tag it to do a copy-on-write flush (i.e. necessary or else the COW-domain data doesn't get refreshed to know that there is now a keyframe on the current frame, causing problems in the UI with the buttons not showing the right colors). 3) To deal with the problem of not being able to keyframe/frame-changed evaluated state values in various operators (e.g. clear transform operators, and a whole bunch of other ones), we introduced a "copy back" step to the depsgraph evaluation to flush the results of the animation evaluation back to the original SDNA data. This allows normal operators to see the depsgraph-evaluated results when simply querying the SDNA state. 4) This is where this bug in particular occurs: Normally there's a write-protection check performed (i.e. see https://developer.blender.org/diffusion/B/browse/master/source/blender/blenkernel/intern/anim_sys.c$1619) that would prevent overwriting. However, here `old_value` (i.e. SDNA value, unkeyed above) != `new_value` (i.e. result of animation evaluation, from F-Curves that don't know about this new value, as they don't have keyframes in place to enforce that yet). Hence, the values from the F-Curves get flushed back to SDNA, overwriting the unkeyed values. In 2.5, we avoided this scenario by making it so that animation evaluation only ever happened on frame change. In other words, if the frame doesn't change, animation evaluation doesn't happen to flush away unkeyed values. ~~AFAIK, right now doing a COW flush pretty much forces the evaluation of everything downstream from it (since we can't really know whether the change which necessitated the flush occurred because some value changed that other things need to rely on - e.g. a property's value changing after user interaction the UI). Thus, COW flushing often means that animation (+ proxy/override stuff) needs to re-run on top of these newly re-synced datablock(s) to get things in sync with the current frame again (just in case a particular COW/graph is looking at a different point in time).~~

Joshua Leung commented

2019-03-01 14:24:13 +01:00

Closed as duplicate of #58721

Joshua Leung closed this issue

2019-03-01 14:24:13 +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

Inserting new keyframe deletes previous ones #61173