VSE strip transforms do not animate correctly and persist after clearing the animation #98015

New Issue

Omar Emara · 2022-05-10T13:36:53+02:00

Omar Emara commented

2022-05-10 13:36:53 +02:00

Short description of error:

Animating the transforms of a VSE strip causes erratic movements at the key frame locations and persist even after clearing the key frames. Moving the strip in the editor causes the transforms to update and work correctly.

Exact steps for others to reproduce the error:

Add an image strip and scale it to be a bit smaller.
Enable auto keying and insert key frames for the xy position and rotation of the strip.
Move to frame 10, set the position of the cursor to the corner of the image, and rotate around the cursor.
Play the animation. You will find that the image jumps at frame 10 for no reason.
Move the strip in the editor. The issue goes away.
Remove the key frames. Notice that the animation still exists.
Move the strip in the editor. The issue goes away.

20220510-132701.mp4

**Short description of error:** Animating the transforms of a VSE strip causes erratic movements at the key frame locations and persist even after clearing the key frames. Moving the strip in the editor causes the transforms to update and work correctly. **Exact steps for others to reproduce the error:** - Add an image strip and scale it to be a bit smaller. - Enable auto keying and insert key frames for the xy position and rotation of the strip. - Move to frame 10, set the position of the cursor to the corner of the image, and rotate around the cursor. - Play the animation. You will find that the image jumps at frame 10 for no reason. - Move the strip in the editor. The issue goes away. - Remove the key frames. Notice that the animation still exists. - Move the strip in the editor. The issue goes away. [20220510-132701.mp4](https://archive.blender.org/developer/F13064688/20220510-132701.mp4)

Omar Emara commented

2022-05-10 13:36:53 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Omar Emara commented

2022-05-10 13:36:53 +02:00

Added subscribers: @OmarEmaraDev, @hamza-el-barmaki

Philipp Oeser commented

2022-05-10 13:54:58 +02:00

Added subscribers: @iss, @lichtwerk

Philipp Oeser commented

2022-05-10 13:54:58 +02:00

Think this is basically covered by one of the following @iss?

#90041 (Update property when adding or removing keyframe)
#94542 (VSE: Animation operators missing cache invalidation)

Think this is basically covered by one of the following @iss? - #90041 (Update property when adding or removing keyframe) - #94542 (VSE: Animation operators missing cache invalidation)

Richard Antalik commented

2022-05-23 21:35:18 +02:00

Changed status from 'Confirmed' to: 'Needs User Info'

Richard Antalik commented

2022-05-23 21:35:18 +02:00

This doesn't quite look like one of issues above, cache should be cleared since strip property was changed. I can't reproduce this issue with steps provided.

@OmarEmaraDev is it possible that you have disk cache enabled and is it neccessary to reproduce this issue?

This doesn't quite look like one of issues above, cache should be cleared since strip property was changed. I can't reproduce this issue with steps provided. @OmarEmaraDev is it possible that you have disk cache enabled and is it neccessary to reproduce this issue?

Omar Emara commented

2022-05-24 08:26:57 +02:00

Changed status from 'Needs User Info' to: 'Needs Triage'

Omar Emara commented

2022-05-24 08:26:57 +02:00

Disk cache is not enabled.

Philipp Oeser commented

2022-05-24 12:47:27 +02:00

I can confirm (both the persistence after clearing the animation as well as the "hop").

Regarding the persistence:

In #98015#1363186, @iss wrote:
This doesn't quite look like one of issues above, cache should be cleared since strip property was changed.

Yeah, strip property was changed (in theory), but clearing animation/ adding / removing keyframes does not touch the RNA callbacks, thus no cache clearing (see your own explanation in #90041)
So I do think this is the underlying issue.

Regarding the "hop" I have the following question:
is this an issue based on the fact that we dont also keyframe Position when rotating around the cursor? (tbh, I think this should be done -- we do the same when rotating an object in 3D around the cursor)
could look into this, since I was responsible for ffd1a7d8c8

I can confirm (both the persistence after clearing the animation as well as the "hop"). - [x] Regarding the persistence: > In #98015#1363186, @iss wrote: > This doesn't quite look like one of issues above, cache should be cleared since strip property was changed. Yeah, strip property was changed (in theory), but clearing animation/ adding / removing keyframes does not touch the RNA callbacks, thus no cache clearing (see your own explanation in #90041) So I do think this is the underlying issue. - [x] Regarding the "hop" I have the following question: - is this an issue based on the fact that we dont also keyframe `Position` when rotating around the cursor? (tbh, I think this should be done -- we do the same when rotating an object in 3D around the cursor) - could look into this, since I was responsible for ffd1a7d8c8

Richard Antalik commented

2022-05-25 00:35:19 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Richard Antalik commented

2022-05-25 00:35:19 +02:00

Ah sorry I did rotation around strip pivot point, not 2D cursor. So I can reproduce and indeed I think that position should be keyframed in this case.

Philipp Oeser self-assigned this 2022-05-25 10:21:14 +02:00

Philipp Oeser commented

2022-05-25 10:21:14 +02:00

@iss: what about the persistence thing then? should we split that off of this report?

Will claim for the keyframing of location...

@iss: what about the persistence thing then? should we split that off of this report? Will claim for the keyframing of location...

Philipp Oeser commented

2022-05-25 10:25:10 +02:00

Also noticed that autokeying image transforms in preview only works if you have a keyframe already (this is inconsistent with auto keyframing elsewhere, will also check on that)

Philipp Oeser commented

2022-05-25 10:41:00 +02:00

Also noticed this should probably respect autokeying setting which relate to Keyingsets (will also check on that) as well as Replace / Add & Replace -- not sure about Layered Recording (but is worth checking also.

Also noticed this should probably respect autokeying setting which relate to `Keyingsets` (will also check on that) as well as `Replace` / `Add & Replace` -- not sure about `Layered Recording` (but is worth checking also.

blender-admin commented

2022-05-25 13:00:18 +02:00

This issue was referenced by 9ccc21dde3

This issue was referenced by 9ccc21dde372d57fa841a494d72527b30d2948d2

Philipp Oeser removed their assignment 2022-05-25 17:25:13 +02:00

Philipp Oeser commented

2022-05-25 17:25:13 +02:00

@iss: I have most of the autokeyframing improvements done (will clean up the patch and post tomorrow)

also keyframe loc when rotating (around cursor)
create action/fcurve if this was not keyframed before (switch from ED_autokeyframe_property to insert_keyframe directly)
autokeying transforms while playing back the timeline wasnt working (now also works with Layered Recording)
respecting KeyingSets

However, I am not sure how to prevent the "hop" when transforming (but not actually setting a keyframe) -- as was described in the original report also in step 4.
This is present with master and has nothing to do with autokeyframing (or the rotation around cursor) though:

#98015.blend

open file
keyframe position X/Y on frame 1
go to frame 10
translate image somewhere (but dont set a keyframe)
scrub the timeline (the unkeyed change on frame 10 will remain in some cache)

So what I have done are mostly improvements, the two issues described here actually remain though (and are probably bugs that you can handle better)

@iss: I have most of the autokeyframing improvements done (will clean up the patch and post tomorrow) - [x] also keyframe loc when rotating (around cursor) - [x] create action/fcurve if this was not keyframed before (switch from `ED_autokeyframe_property` to `insert_keyframe` directly) - [x] autokeying transforms while playing back the timeline wasnt working (now also works with `Layered Recording`) - [x] respecting KeyingSets However, I am not sure how to prevent the "hop" when transforming (but **not** actually setting a keyframe) -- as was described in the original report also in step 4. This is present with master and has nothing to do with autokeyframing (or the rotation around cursor) though: [#98015.blend](https://archive.blender.org/developer/F13104629/T98015.blend) - open file - keyframe position X/Y on frame 1 - go to frame 10 - translate image somewhere (but dont set a keyframe) - scrub the timeline (the unkeyed change on frame 10 will remain in some cache) So what I have done are mostly improvements, the two issues described here actually remain though (and are probably bugs that you can handle better)

Richard Antalik commented

2022-05-26 12:59:46 +02:00

In #98015#1364264, @lichtwerk wrote:
However, I am not sure how to prevent the "hop" when transforming (but not actually setting a keyframe)

If I understand this correctly, the "hop" frame from report was the only correct frame, since it was rendered after transformation was done. So I would say if keyframes would be set this would not happen.

> In #98015#1364264, @lichtwerk wrote: > However, I am not sure how to prevent the "hop" when transforming (but **not** actually setting a keyframe) If I understand this correctly, the "hop" frame from report was the only correct frame, since it was rendered after transformation was done. So I would say if keyframes would be set this would not happen.

Philipp Oeser commented

2022-05-26 14:27:09 +02:00

In #98015#1364664, @iss wrote:

In #98015#1364264, @lichtwerk wrote:
However, I am not sure how to prevent the "hop" when transforming (but not actually setting a keyframe)

If I understand this correctly, the "hop" frame from report was the only correct frame, since it was rendered after transformation was done. So I would say if keyframes would be set this would not happen.

Yes, if you would set a key there, this would be fine.
But if you dont set a key there [which is totally fine], this is wrong. And this has nothing to do with autokey or the cursor rotation (see my previous example/comment).
Once you change frames, the unkeyed change needs to vanish (but atm. it remains in the cache).

The equivalent in 3D would be:

keyframe the cube at 0/0/0 at frame 1
go to frame 10 move the cube (but dont set a keyframe)
scrub the timeline --> the cube should return to 0/0/0 and stay there (or would you expect the cube to "hop" on frame 10? No!)

> In #98015#1364664, @iss wrote: >> In #98015#1364264, @lichtwerk wrote: >> However, I am not sure how to prevent the "hop" when transforming (but **not** actually setting a keyframe) > > If I understand this correctly, the "hop" frame from report was the only correct frame, since it was rendered after transformation was done. So I would say if keyframes would be set this would not happen. Yes, if you would set a key there, this would be fine. But if you dont set a key there [which is totally fine], this is wrong. And this has nothing to do with autokey or the cursor rotation (see my previous example/comment). Once you change frames, the unkeyed change needs to vanish (but atm. it remains in the cache). The equivalent in 3D would be: - keyframe the cube at 0/0/0 at frame 1 - go to frame 10 move the cube (but dont set a keyframe) - scrub the timeline --> the cube should return to 0/0/0 and stay there (or would you expect the cube to "hop" on frame 10? No!)

Richard Antalik commented

2022-05-26 23:05:34 +02:00

Ah right that's correct. Not sure what would be good solution. Sounds to me that in case when property is animated, cache entry should be created only when keyframe is inserted, but even that is not quite enough - it would have to check if all properties that were changed were keyed. Looks quite complicated to handle this.

In any case it is different issue than reported indeed.

Ah right that's correct. Not sure what would be good solution. Sounds to me that in case when property is animated, cache entry should be created only when keyframe is inserted, but even that is not quite enough - it would have to check if all properties that were changed were keyed. Looks quite complicated to handle this. In any case it is different issue than reported indeed.

Philipp Oeser commented

2022-05-27 08:51:14 +02:00

I think it makes sense to split this report up in multiple reports (will do that).

In #98015#1364993, @iss wrote:
Ah right that's correct. Not sure what would be good solution. Sounds to me that in case when property is animated, cache entry should be created only when keyframe is inserted, but even that is not quite enough - it would have to check if all properties that were changed were keyed. Looks quite complicated to handle this.

Havent looked at cache internals (where the entries are made, when/how exactly this get invalidated), could check if you give me a hint, but looks like this is essential funtionality that is just behaving wrong (by design?)

I think it makes sense to split this report up in multiple reports (will do that). > In #98015#1364993, @iss wrote: > Ah right that's correct. Not sure what would be good solution. Sounds to me that in case when property is animated, cache entry should be created only when keyframe is inserted, but even that is not quite enough - it would have to check if all properties that were changed were keyed. Looks quite complicated to handle this. Havent looked at cache internals (where the entries are made, when/how exactly this get invalidated), could check if you give me a hint, but looks like this is essential funtionality that is just behaving wrong (by design?)

Philipp Oeser commented

2022-05-27 08:54:01 +02:00

@iss: you also have not commented on the "persting-after-clearing-animation" issue (if this is a duplicate of the mentioned report)

Philipp Oeser commented

2022-05-27 10:37:00 +02:00

Changed status from 'Confirmed' to: 'Archived'

Philipp Oeser closed this issue

2022-05-27 10:37:00 +02:00

Philipp Oeser commented

2022-05-27 10:37:00 +02:00

I have split this up in multiple reports (claimed the first three related to autokeying for now), see
#98429 (VSE autokeying transforms in preview only creates keyframes for rotation/scale if rotating/scaling around cursor (should keyframe position as well))
#98430 (VSE autokeying transforms in preview only creates keyframes if there is an FCurve already)
#98431 (VSE autokeying transforms in preview does not work during animation playback)
#98432 (VSE unkeyed transforms in preview persist in cache)
#98433 (VSE keyframed transforms in preview persist in cache after keyframes have been cleared)

this will make this report redundant though, will close.

I have split this up in multiple reports (claimed the first three related to autokeying for now), see #98429 (VSE autokeying transforms in preview only creates keyframes for rotation/scale if rotating/scaling around cursor (should keyframe position as well)) #98430 (VSE autokeying transforms in preview only creates keyframes if there is an FCurve already) #98431 (VSE autokeying transforms in preview does not work during animation playback) #98432 (VSE unkeyed transforms in preview persist in cache) #98433 (VSE keyframed transforms in preview persist in cache after keyframes have been cleared) this will make this report redundant though, will close.

Richard Antalik commented

2022-05-29 01:21:33 +02:00

In #98015#1365188, @lichtwerk wrote:
I think it makes sense to split this report up in multiple reports (will do that).

In #98015#1364993, @iss wrote:
Ah right that's correct. Not sure what would be good solution. Sounds to me that in case when property is animated, cache entry should be created only when keyframe is inserted, but even that is not quite enough - it would have to check if all properties that were changed were keyed. Looks quite complicated to handle this.

Havent looked at cache internals (where the entries are made, when/how exactly this get invalidated), could check if you give me a hint, but looks like this is essential funtionality that is just behaving wrong (by design?)

Most modal operators would invalidate cache right after strip data is modified(here recalcData_sequencer) along with sending notifiers to redraw/re-render. Images are cached during rendering(seq_cache_put). So technically this is behaving wrong by design. Sequencer would have to know that property is not keyframed yet and not cache any image in such case, which is quite a bit outside of its scope IMO.

There is mechanism in cache for discarding images that are stored recently, but this is due to memory limits and fact that all images within same frame must be stored (size of all images is known only after they are stored and possibly over the limit). So technically this could be solved, but not sure how to signal this situation to sequencer. Even depsgraph does not care about data you have manually tweaked and not keyed when you change frame - it just discards everything and calculates animation from ground up.

In #98015#1365190, @lichtwerk wrote:
@iss: you also have not commented on the "persting-after-clearing-animation" issue (if this is a duplicate of the mentioned report)

Sorry, yes, that would be same issue as described in #90041.

> In #98015#1365188, @lichtwerk wrote: > I think it makes sense to split this report up in multiple reports (will do that). > > >> In #98015#1364993, @iss wrote: >> Ah right that's correct. Not sure what would be good solution. Sounds to me that in case when property is animated, cache entry should be created only when keyframe is inserted, but even that is not quite enough - it would have to check if all properties that were changed were keyed. Looks quite complicated to handle this. > Havent looked at cache internals (where the entries are made, when/how exactly this get invalidated), could check if you give me a hint, but looks like this is essential funtionality that is just behaving wrong (by design?) Most modal operators would invalidate cache right after strip data is modified(here `recalcData_sequencer`) along with sending notifiers to redraw/re-render. Images are cached during rendering(`seq_cache_put`). So technically this is behaving wrong by design. Sequencer would have to know that property is not keyframed yet and not cache any image in such case, which is quite a bit outside of its scope IMO. There is mechanism in cache for discarding images that are stored recently, but this is due to memory limits and fact that all images within same frame must be stored (size of all images is known only after they are stored and possibly over the limit). So technically this could be solved, but not sure how to signal this situation to sequencer. Even depsgraph does not care about data you have manually tweaked and not keyed when you change frame - it just discards everything and calculates animation from ground up. > In #98015#1365190, @lichtwerk wrote: > @iss: you also have not commented on the "persting-after-clearing-animation" issue (if this is a duplicate of the mentioned report) Sorry, yes, that would be same issue as described in #90041.

hamza.SMA commented

2022-06-07 12:18:43 +02:00

peace,
those commits cannot be also gor 3.2.x ?

peace, those commits cannot be also gor 3.2.x ?

Philipp Oeser commented

2022-06-07 12:37:29 +02:00

In #98015#1369796, @hamza-el-barmaki wrote:
peace,
those commits cannot be also gor 3.2.x ?

too late in the release cycle...

> In #98015#1369796, @hamza-el-barmaki wrote: > peace, > those commits cannot be also gor 3.2.x ? too late in the release cycle...

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

VSE strip transforms do not animate correctly and persist after clearing the animation #98015