Page MenuHome

Inserting new keyframe deletes previous ones
Closed, DuplicatePublic


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

Blender Version

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?



Event Timeline

I think it's the same Bug as here.

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

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