VSE strip transforms do not animate correctly and persist after clearing the animation #98015
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
5 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#98015
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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:
20220510-132701.mp4
Changed status from 'Needs Triage' to: 'Confirmed'
Added subscribers: @OmarEmaraDev, @hamza-el-barmaki
Added subscribers: @iss, @lichtwerk
Think this is basically covered by one of the following @iss?
Changed status from 'Confirmed' to: 'Needs User Info'
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?
Changed status from 'Needs User Info' to: 'Needs Triage'
Disk cache is not enabled.
I can confirm (both the persistence after clearing the animation as well as the "hop").
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.
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)ffd1a7d8c8
Changed status from 'Needs Triage' to: 'Confirmed'
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.
@iss: what about the persistence thing then? should we split that off of this report?
Will claim for the keyframing of location...
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)
Also noticed this should probably respect autokeying setting which relate to
Keyingsets
(will also check on that) as well asReplace
/Add & Replace
-- not sure aboutLayered Recording
(but is worth checking also.This issue was referenced by
9ccc21dde3
@iss: I have most of the autokeyframing improvements done (will clean up the patch and post tomorrow)
ED_autokeyframe_property
toinsert_keyframe
directly)Layered Recording
)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
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)
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:
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.
I think it makes sense to split this report up in multiple reports (will do that).
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?)
@iss: you also have not commented on the "persting-after-clearing-animation" issue (if this is a duplicate of the mentioned report)
Changed status from 'Confirmed' to: 'Archived'
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.
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.
Sorry, yes, that would be same issue as described in #90041.
peace,
those commits cannot be also gor 3.2.x ?
too late in the release cycle...