COW problems with keying animation #55047

New Issue

Inês Almeida · 2018-05-13T08:48:15+02:00

Inês Almeida commented

2018-05-13 08:48:15 +02:00

Blender Version
2.8 0414b0a0be (Sunday 13May) with --enable-copy-on-write

Short Description
Some simple repro steps for problems with COW and the animation system, hoping it's useful.

Exact steps for others to reproduce the error
Scenario 1

Start with the default scene. (No auto keyframe)
Insert a Location key for the Cube.
Move the Cube. Move the timeline. -> BAD: the cube moved back to the original key position

Scenario 2

Start with the default scene. (No auto keyframe)
Insert a Location key for the Cube.
Move the Cube, totally forget to move the timeline and then Insert a new Location key.
Take a moment to berate yourself for your stupidity, then Undo the keying. -> BAD the cube goes back to the original key position

Fun continues

Ok, Ok... let's make this right. The cube is (from any scenario) at the original location and there should be only the first key for that location.
But let's be sure... key it again.. -> BAD the cube goes to the second position.

Fun never ends

AAArgh... so undo everything (cube is at original position). Delete all the keys. -> BAD the cube goes to the second position.

**Blender Version** 2.8 0414b0a0be9 (Sunday 13May) with `--enable-copy-on-write` **Short Description** Some simple repro steps for problems with COW and the animation system, hoping it's useful. **Exact steps for others to reproduce the error** Scenario 1 - Start with the default scene. (No auto keyframe) - Insert a Location key for the Cube. - Move the Cube. Move the timeline. -> BAD: the cube moved back to the original key position Scenario 2 - Start with the default scene. (No auto keyframe) - Insert a Location key for the Cube. - Move the Cube, totally forget to move the timeline and then Insert a new Location key. - Take a moment to berate yourself for your stupidity, then Undo the keying. -> BAD the cube goes back to the original key position Fun continues - Ok, Ok... let's make this right. The cube is (from any scenario) at the original location and there should be only the first key for that location. - But let's be sure... key it again.. -> BAD the cube goes to the second position. Fun never ends - AAArgh... so undo everything (cube is at original position). Delete all the keys. -> BAD the cube goes to the second position.

Inês Almeida commented

2018-05-13 08:48:15 +02:00

Added subscriber: @brita

Inês Almeida commented

2018-05-13 08:49:27 +02:00

Added subscribers: @Sergey, @JoshuaLeung

Joshua Leung commented

2018-05-13 09:49:47 +02:00

Scenario 1:
Not a bug. It is supposed to clear any unkeyed changes when you change frames

Scenario 2:
That one may be a bug. Undoing reloads the file, causing anim recalc/reflush

3, #4

That's bad

Scenario 1: Not a bug. It *is* supposed to clear any unkeyed changes when you change frames Scenario 2: That one may be a bug. Undoing reloads the file, causing anim recalc/reflush # 3, #4 That's bad

Sergey Sharybin commented

2018-05-13 09:51:17 +02:00

Some quick replies.

Scenario 1 Changing current frame always updates whole animation. I see how this is annoying in your case, but if we will start preserving un-keyed animation across the whole timeline, that would definitely ruin animators' workflow. For the record, this is nothing to do with copy-on-write or 2.8, this is how animation system always worked.

Scenario 2. This is going to be pain. Thing is, global undo (which is a case for keyframe changes in object mode), is like opening fresh file, tossing the whole evaluated data away. Now, the magic-auto-keyframe which happens behind the scenes of dependency graph is storing all required data in the evaluated datablock. This, so far, seemed to be the only solution which would allow us to have two windows at different frames.

This issue is on the list of to-be-looked-way-deeper. It's not really fixable without undo system giving some extra information to dependency graphs.

Scenario 3. This is the issue of insert-keyframe operator not ported to get value from evaluated object, belongs to the task force.

Scenario 4. Holy cow... Imagine, you've got 2 windows, two different times, window 1 tells the cube to be at (0, 0, 0) window 2 tells the cube to be at (1, 1, 1). You delete ALL keyframes, what is the expected behavior:

Use location from active window (the one you've invoked operator from). But if that window was only used for f-curve editor, then the result will likely to be different from what animator expects.
Use location from window which has that object visible, start testing with current window. This solve issue mentioned above, but makes things to be rather unpredictable.
Blender crashes with message "No idea how to move forward with life".
Cube starts to behave according to the quantum physics and is at two locations at the same time.
All above.

Some quick replies. **Scenario 1** Changing current frame __always__ updates whole animation. I see how this is annoying in your case, but if we will start preserving un-keyed animation across the whole timeline, that would definitely ruin animators' workflow. For the record, this is nothing to do with copy-on-write or 2.8, this is how animation system always worked. **Scenario 2.** This is going to be pain. Thing is, global undo (which is a case for keyframe changes in object mode), is like opening fresh file, tossing the whole evaluated data away. Now, the magic-auto-keyframe which happens behind the scenes of dependency graph is storing all required data in the evaluated datablock. This, so far, seemed to be the only solution which would allow us to have two windows at different frames. This issue is on the list of to-be-looked-way-deeper. It's not really fixable without undo system giving some extra information to dependency graphs. **Scenario 3.** This is the issue of insert-keyframe operator not ported to get value from evaluated object, belongs to the task force. **Scenario 4.** Holy cow... Imagine, you've got 2 windows, two different times, window 1 tells the cube to be at `(0, 0, 0)` window 2 tells the cube to be at `(1, 1, 1)`. You delete ALL keyframes, what is the expected behavior: - Use location from active window (the one you've invoked operator from). But if that window was only used for f-curve editor, then the result will likely to be different from what animator expects. - Use location from window which has that object visible, start testing with current window. This solve issue mentioned above, but makes things to be rather unpredictable. - Blender crashes with message "No idea how to move forward with life". - Cube starts to behave according to the quantum physics and is at two locations at the same time. - All above.

Inês Almeida commented

2018-05-13 14:34:33 +02:00

Scenario 1: you're both right :) behaviour is the same than for 2.79, nevermind!

Scenario 4: I think options get better the more down you go :D
So assuming there is:

a keyed animation for the cube to go from (0,0,0) to (1,1,1)
window1's timeline is at the first key
window2 is at the second?

If a keyframe gets deleted, I kind of expect that nothing moves. It's just not keyed, but the cubes should both stay where they were? magically?
If I move a timeline, then scenario 1 happens and the cube will jump in the window I moved the timeline. (though I still expect it to not move unless i go to a frame where there is a key. I understand that this was never the case, and that technically there is a curve everywhere)

**Scenario 1:** you're both right :) behaviour is the same than for 2.79, nevermind! **Scenario 4:** I think options get better the more down you go :D So assuming there is: - a keyed animation for the cube to go from (0,0,0) to (1,1,1) - window1's timeline is at the first key - window2 is at the second? If a keyframe gets deleted, I kind of expect that nothing moves. It's just not keyed, but the cubes should both stay where they were? magically? If I move a timeline, then scenario 1 happens and the cube will jump in the window I moved the timeline. (though I still expect it to not move unless i go to a frame where there is a key. I understand that this was never the case, and that technically there is a curve everywhere)

Sergey Sharybin commented

2018-05-14 08:29:49 +02:00

If a keyframe gets deleted, I kind of expect that nothing moves. It's just not keyed, but the cubes should both stay where they were?

The are only few things which can make same object to be evaluated differently in different contexts: animation, drivers, and overrides. In this example it's not the case, so cubes must be evaluated to the same state. Violating this will only cause huge issues in the not-that-distant future.

If I move a timeline, then scenario 1 happens and the cube will jump in the window I moved the timeline.

It needs to know where to jump to. That "somewhere" is the original DNA. Which is the same for all contexts. This is also nothing to do with animation. There are more ways which will force things to jump.

My point here is: if jump is not inevitable, do it right away. It must never be the case when one says "Hey, i've clicked Foo and stuff jumped!" and other answers "Well, that's because you've clicked Bar 10 steps before!".

I understand that this was never the case.

This is not about being the case or not being the case. This is about having consistent state of your scene, which will grant clear understanding of what's going on.

Anyway, the bottom line:

Undo needs work, to allow undoing insertion of keyframes without loosing unkeyed changed. Not sure how to do this, but it's crucial behavior to bring back.
Insertion of keyframes must use value from evaluated datablock. This belongs to taskforce, but is simple fix so can just do it now.
Dealing with different states in different contexts needs clear design put on paper, so nobody is getting confused.

> If a keyframe gets deleted, I kind of expect that nothing moves. It's just not keyed, but the cubes should both stay where they were? The are only few things which can make same object to be evaluated differently in different contexts: animation, drivers, and overrides. In this example it's not the case, so cubes must be evaluated to the same state. Violating this will only cause huge issues in the not-that-distant future. > If I move a timeline, then scenario 1 happens and the cube will jump in the window I moved the timeline. It needs to know where to jump to. That "somewhere" is the original DNA. Which is the same for all contexts. This is also nothing to do with animation. There are more ways which will force things to jump. My point here is: if jump is not inevitable, do it right away. It must never be the case when one says "Hey, i've clicked Foo and stuff jumped!" and other answers "Well, that's because you've clicked Bar 10 steps before!". > I understand that this was never the case. This is not about being the case or not being the case. This is about having consistent state of your scene, which will grant clear understanding of what's going on. ---- Anyway, the bottom line: - Undo needs work, to allow undoing insertion of keyframes without loosing unkeyed changed. Not sure how to do this, but it's crucial behavior to bring back. - Insertion of keyframes must use value from evaluated datablock. This belongs to taskforce, but is simple fix so can just do it now. - Dealing with different states in different contexts needs clear design put on paper, so nobody is getting confused.

Inês Almeida commented

2018-05-22 09:23:57 +02:00

Added subscriber: @mont29

Inês Almeida commented

2018-05-22 09:23:57 +02:00

Suggestion after talking with @mont29 :
assuming 2 windows at different times, when the user deletes a key on window 1, write the current evaluated transform in that window to the original DNA.
The end result is that the object would stay in place in the window where the user is working. On window 2 it would jump to the same position than on window 1.

Suggestion after talking with @mont29 : assuming 2 windows at different times, when the user deletes a key on window 1, write the current evaluated transform in that window to the original DNA. The end result is that the object would stay in place in the window where the user is working. On window 2 it would jump to the same position than on window 1.

Brecht Van Lommel commented

2019-02-27 20:15:03 +01:00

Added subscriber: @brecht

Brecht Van Lommel commented

2019-02-27 20:15:03 +01:00

Changed status from 'Open' to: 'Resolved'

Brecht Van Lommel closed this issue

2019-02-27 20:15:03 +01:00

Brecht Van Lommel self-assigned this 2019-02-27 20:15:03 +01:00

Brecht Van Lommel commented

2019-02-27 20:15:03 +01:00

I think this was solved since the original report, and if not we have many other reports about keyframing bugs that are more relevant to the current state of the code.

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

COW problems with keying animation #55047

3, #4