Keyframed parameters are not preserved when frame_change_post handler is used #71908
Open
opened 2019-11-26 00:44:51 +01:00 by Fran
·
67 comments
No Branch/Tag Specified
blender-v3.3-release
main
blender-v3.6-release
temp-sculpt-dyntopo
asset-shelf
temp-sculpt-dyntopo-hive-alloc
brush-assets-project
tmp-usd-python-mtl
asset-browser-frontend-split
node-group-operators
blender-v2.93-release
universal-scene-description
temp-sculpt-attr-api
blender-v3.5-release
realtime-clock
sculpt-dev
gpencil-next
bevelv2
microfacet_hair
blender-projects-basics
xr-dev
principled-v2
v3.3.7
v2.93.18
v3.5.1
v3.3.6
v2.93.17
v3.5.0
v2.93.16
v3.3.5
v3.3.4
v2.93.15
v2.93.14
v3.3.3
v2.93.13
v2.93.12
v3.4.1
v3.3.2
v3.4.0
v3.3.1
v2.93.11
v3.3.0
v3.2.2
v2.93.10
v3.2.1
v3.2.0
v2.83.20
v2.93.9
v3.1.2
v3.1.1
v3.1.0
v2.83.19
v2.93.8
v3.0.1
v2.93.7
v3.0.0
v2.93.6
v2.93.5
v2.83.18
v2.93.4
v2.93.3
v2.83.17
v2.93.2
v2.93.1
v2.83.16
v2.93.0
v2.83.15
v2.83.14
v2.83.13
v2.92.0
v2.83.12
v2.91.2
v2.83.10
v2.91.0
v2.83.9
v2.83.8
v2.83.7
v2.90.1
v2.83.6.1
v2.83.6
v2.90.0
v2.83.5
v2.83.4
v2.83.3
v2.83.2
v2.83.1
v2.83
v2.82a
v2.82
v2.81a
v2.81
v2.80
v2.80-rc3
v2.80-rc2
v2.80-rc1
v2.79b
v2.79a
v2.79
v2.79-rc2
v2.79-rc1
v2.78c
v2.78b
v2.78a
v2.78
v2.78-rc2
v2.78-rc1
v2.77a
v2.77
v2.77-rc2
v2.77-rc1
v2.76b
v2.76a
v2.76
v2.76-rc3
v2.76-rc2
v2.76-rc1
v2.75a
v2.75
v2.75-rc2
v2.75-rc1
v2.74
v2.74-rc4
v2.74-rc3
v2.74-rc2
v2.74-rc1
v2.73a
v2.73
v2.73-rc1
v2.72b
2.72b
v2.72a
v2.72
v2.72-rc1
v2.71
v2.71-rc2
v2.71-rc1
v2.70a
v2.70
v2.70-rc2
v2.70-rc
v2.69
v2.68a
v2.68
v2.67b
v2.67a
v2.67
v2.66a
v2.66
v2.65a
v2.65
v2.64a
v2.64
v2.63a
v2.63
v2.61
v2.60a
v2.60
v2.59
v2.58a
v2.58
v2.57b
v2.57a
v2.57
v2.56a
v2.56
v2.55
v2.54
v2.53
v2.52
v2.51
v2.50
v2.49b
v2.49a
v2.49
v2.48a
v2.48
v2.47
v2.46
v2.45
v2.44
v2.43
v2.42a
v2.42
v2.41
v2.40
v2.37a
v2.37
v2.36
v2.35a
v2.35
v2.34
v2.33a
v2.33
v2.32
v2.31a
v2.31
v2.30
v2.28c
v2.28a
v2.28
v2.27
v2.26
v2.25
Labels
Clear labels
Issues relating to security: https://wiki.blender.org/wiki/Process/Vulnerability_Reports
Apply labels
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
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
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
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
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
Issues relating to security: https://wiki.blender.org/wiki/Process/Vulnerability_Reports
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 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
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
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
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
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
Milestone
Set milestone
Clear milestone
No items
No Milestone
Projects
Set Project
Clear projects
No project
Assignees
Assign users
Clear assignees
No Assignees
16 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#71908
Reference in New Issue
There is no content yet.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?
System Information
Operating system: Win 10 Pro
Graphics card: GTX 1080
Blender Version
Broken: v2.81, master, 2018-11-26
Worked: (optional)
EDIT by @EAW
Short description of error
Exact steps for others to reproduce the error
End Edit
Short description of error
I have created a FlipFluids simulation in Blender 2.81 ( 2019-11-25 21:45) and added an Ocean modifier in displacement mode to the fluid_surface. Then I have baked the complete sim from within FlipFluids.
When I move from keyframe to keyframe in the default timeline everything is moving as desired in the default 3D window:
Ocean modifier waves, FlipFluids waves & wake, flags, radars...
When I render the complete animation everything EXCEPT the ocean modifier waves are moving. The ocean modifier waves remain static but the FLIPFLUIDS waves move on that surface.
ALL modifiers and elements ARE enabled for renderings. D-NOISE: AI Denoiser is on (switching denoiser off did not help).
Computer is a HP Z800 with dual Xeons, 72 GB of vRAM and a GTX 1060.
If I render & save the keyframes manually individually by hand the ocean surface moves! Which means I get the proper result.
As its working when rendering&saving each frame manually as image (Png) and its not giving the same result when saving out the same images (Png) when I hit render animation, I do suppose this might be a bug in 2.81.
Running indiviual frames via Renderpilot did not yield the proper result either. So I do suspect it might be that there is not enough time gap between saving the last frame and rendering the next. Or, something does not get purged properly.
For propriatary reasons I can not share the blend file.
Added subscriber: @Prettypicturegirl
#78866 was marked as duplicate of this issue
#77008 was marked as duplicate of this issue
#73686 was marked as duplicate of this issue
#75626 was marked as duplicate of this issue
Attached two samples showing the different results.
SingleFrames.rar
AnimationFrames.rar
Added subscriber: @rlguy
I am able to reproduce this issue in the FLIP Fluids addon. I have created a minimal script and .blend file that can reproduce the issue. It seems that modifiers with parameters that are keyframed do not update when the modifier is on a mesh that is procedurally generated in the frame_change_post handler.
Here is a script that generates a 2d grid of vertices in the frame_change_post handler:
In the .blend file setup, the 'mesh_cache' object would instance a cube over the vertices for display in rendering. An ocean modifier is added to the object with 'Geometry' set to Displace and the 'time' parameter is keyframed over a frame range.
Playback in the viewport shows the ocean modifier evolving shape during the animation. If the animation is rendered, the ocean modifier does not evolve over time and the render result is static.
Here is the .blend file including the script: keyframed_modifier_bug.blend
How to reproduce:
The result is a static animation.
Added subscriber: @mano-wii
Please follow our submission template and guidelines, also read these tips about bug reports, and make a complete, valid bug report, with required info, precise description of the issue, precise steps to reproduce it, small and simple .blend and/or other files to do so if needed, etc.
Also explained here: https://www.youtube.com/watch?v=JTD0OJq_rF4
Also keep in mind that Flip Fluid Addon is not maintained by blender.
So if the bug is related to it please report the issue to the original author instead.
Added subscriber: @Germano
@Germano
I do not understand what your issue is.
I am not a developer and tried my very best to give all information necessary in the required format.
Further the FlipFluids add-on developer himself RLGuy answered in a reply here and confirmed and even showed how the bug appears. It's clearly a bug in Blender and not in the add-on.
So, why are you downvoting a user reported bug instead of clearly indicating what further info you need?
That's not at all serving the product quality....
Further rlguy gave you a suitable blend file and detailed information of how to reproduce the issue.
Please be so kind and read his reply. It's very detailed.
I am not a Blender specialist and I can not share such a blend file as I have not enough know how of how to create such a small file.
Neither can I provide the huge original blend file as it has copyrighted design geometry within.
In the submission template and guidelines there is a clear distinction between:
Short description of error
and
Exact steps for others to reproduce the error
The steps to reproduce the problem need to be simple, without the need to install external addons.
Added subscribers: @fran-12, @EAW
@fran-12
Update the title of this report to be “Keyframed modifier parameters do not update on a mesh that is procedurally generated in the frame_change_post handler.”
It is a much more accurate description of the issue. I would update it for you but I am not a moderator.
Then copy and paste @rlguy’s comment above you original description to make this a valid bug report.
Under short description of error paste “Playback in the viewport shows the ocean modifier evolving shape during the animation. If the animation is rendered, the ocean modifier does not evolve over time and the render result is static.”
Paste the rest of his comment under “Exact steps for others to reproduce the error”.
This will make the bug report follow the template.
I am unable to test his method myself today as I forgot to pack my laptop cord and the stores are closed due to a national holiday in the USA.
Guess than I am not in the position to help you to fix a clearly existing bug in the current release. Im to much à newbie to describe it in detail.
Rlguy provided exactly what you asked for in his reply, but you seem not content with this either.
I'm fairly new to Blender and was hoping to be able to contribute to getting rid of a bug.
As this seems a complex thing to do, guess I will not endeavor in the future to file bug reports.
Which is ashame because it would have actually improved Blender...
Added subscriber: @lichtwerk
@rlguy: could you check your file again?
For me, the is no script in
ocean_displacement_test.blend
, also no "mesh_cache" object...Thanks Evan,
very kind of you. I am traveling right now, and can do this tomorrow.
Should I file a new bug report with the format you described? Or can I shuffle things around in this bug report?
Thanks,
Fran
@Prettypicturegirl : we can do this, but waiting for @rlguy to provide the updated file.
We'll get there :)
[But of course it helps if everything is there from the very start -- going back and forth just takes time, and time is really precious with the ammount of work to be done in the tracker atm...]
Everything good everyone?
Thank you Philipp. Very kind of you. And yes I'm happy now, especially if you can fix it.
I just recently switched from an expensive commercial copy of V-Ray for Rhino to Blender and am really excited what and how much more can be done with it.
My apologies, I had uploaded the incorrect file. I have updated the comment with the correct file: keyframed_modifier_bug.blend
Added subscriber: @Sergey
@rlguy
I am not a programmer, so pardon me if this is naive, but should it be
def frame_change_post_handler(scene, depsgraph):
Instead of
def frame_change_post(scene, depsgraph):
See
https://wiki.blender.org/wiki/Reference/Release_Notes/2.81/Python_API#Handlers
And
Really wish my laptop battery wasn’t right now :)
@
You are most welcome!
@EAW The name/identifier of the handler function can be set to any custom name (under the constraints of what is valid in Python). The handler function just needs to be appended to the bpy.app.handlers.frame_change_post list so that Blender runs the function on a frame change.
For example, this should also be valid API usage:
Inconsistent result saving png by individual keyframe render and animation render png of the same image.to Keyframed modifier parameters do not update on a mesh that is procedurally generated in the frame_change_post handler.Thank you for letting me know @rlguy
@Prettypicturegirl I have edited the title and description for you.
Perfect, see I'd never had the chance to rephrase tjis way, as I lack the know how in Blender at the moment. Thank you Evan.
This issue was referenced by
befc082736
Changed status from 'Confirmed' to: 'Resolved'
Changed status from 'Resolved' to: 'Confirmed'
Re-opening.
The fix caused #73029. Need to re-iterate over solution.
Added subscriber: @dr.sybren
#75626 (Changing properties of an object from a frame_change_post handler blocks animation) describes the same issue, albeit in a simpler way, with just three animated balls. The blend file & reproduction steps might be nicer to use for debugging purposes.
Keyframed modifier parameters do not update on a mesh that is procedurally generated in the frame_change_post handler.to Keyframed parameters are not preserved when frame_change_post handler is usedDeveloper note.
The system, works in the following way: when
frame_change_post
modifies some datablock an extra update of the dependency graph is done, but this update will not do animation update (with an intent to allow to manually apply changes on top of animation).For the viewport the flow in this usecase goes as following:
BKE_scene_graph_update_for_newframe
is done for dependency graph + animationframe_change_post
modifies some datablock (NOTE: modification happens on original datablock, with an intent that system will pick changes up and propagate to all related dependency graphs).BKE_scene_graph_update_for_newframe
and second round of updates is performed. This time without evaluating manimation.For the non-viewport depsgraph the difference is at step 2: there is no copy of new animated property value from evaluated to original. This makes step 5 to "override" evaluated animated value with the one from the viewport, which is likely to be wrong (since viewport is evaluated at different frame than the non-viewport depsgraph).
Since we don't have any way to know which properties were modified, I am not sure what could be a solution without breaking API, or without breaking existing mindset, or without loosing ability to override animated values from the handler.
P.S. Since I didn't have time to look into for so long, unassigning so then other developers are more encouraged to pick up and help.
Added subscribers: @StephenHamacek, @ZedDB, @StanislavOvcharov, @Alex_Rom, @jpbouza-4, @iss
@Sergey how would you feel about a way to, instead of updating the original datablock from the handler, update the evaluated datablock? To me this feels more in line with "updating after the animation has run". To avoid breaking the existing API, this could be done from a separate callback, like
frame_change_post_animation
. The callback could get the evaluated scene, and thus iterate over its evaluated objects.While this sounds like an easy solution in this specific case, it opens up a huge amount of other issues and inconsistencies:
This list can go on, with every item going deeper and deeper in design reconsiderations in all areas. So while this is not an invalid plausible path, it needs careful thoughts and clear design put on paper rather than be accepted on a feelings that it solves this specific case.
Please have a look at the existing handler signature. You can access both original and evaluated datablocks since you do have access to the dependency graph. Accessing evaluated objects is not the problem here from the API point of view. What affects on API is If we say that handlers are to modify evaluated datablocks, we are likely to break all existing handlers. One would argue that existing behavior can be preserved, but it will be same limited, it might very quickly get in a way, and having 2 semi-working ways of doing something just adds even more confusion.
Thanks for the clear explanation @sergey.
I've been thinking about this, and any solution I see keeps boiling down to keeping track of which properties are changed by
frame_change_post
handlers. That way we can avoid doing a full copy (original → evaluated) in step 5 above and only copy those properties that were updated in theframe_change_post
handler. That would keep animated property values intact, and would also allow overriding their values from Python.Alternatively, it could be possible to make the animation system run but disallow overwriting properties that were changed by
frame_change_post
. However, this would put a burden on the animation evaluation to check each and every property set, so that'll be bad for performance for sure. And in the end it also boils down to "keep track of which properties were changed".Keeping track of which properties were changed could be automatically done by RNA, but I suspect that adding even a single boolean check on all RNA setters will negatively impact performance outside of the scope of frame change handlers. Alternatively this could be done explicitly, as something special that's required for
frame_change_post
handler functions; something likedatablock.update_tag_attribute('some_attribute')
. I'm also aprehensive of this solution, as it's easy to forget that this is a necessary step, and I had rather Blender do this automatically. However, I would prefer explicitly tagging attributes over worse overall performance.This approach will not gracefully handle those cases where a single value in DNA is exposed as multiple values in RNA (for example
Object.hide_viewport
andhide_render
)Good point. When new datablocks are pulled into the graph, I'm guessing they won't get animated property values now either?
It indeed sounds more like we do need storage of some sort, but it's.. Complicated.
Complication #1: due to the nature of RNA and python scripting you would need to inform all dependency graphs about all property changes. Imagine having importer implemented in Python, ugh :(
Complication #2: Copying becomes more complicated, it needs to know that at some point it need to do one thing, and at another point another thing.
Complication #3: Handlers do not only modify properties via RNA, they might run C function (via bpy utility or via operator) which will perform modification, without using RNA API.
If the handler adds new objects with animation data, yeah, probably it wouldn't. get animation evaluated (since second round of updates only updates tags, without time).
That's only an issue when you want to have existing animation also applied. So the importer would have to be a rather special one, importing some animated data (otherwise it wouldn't have to be run on frame change) but still allowing other animations to be applied as well. I don't know of any importers that do this. Could provide a nice workflow of hand-animating some properties while others are animated by the importer.
That's only if we want to have this system work everywhere, all the time. From what I can see, it's only an issue in the frame-change-post handler, so applying the changed properties onto the already-evaluated copies could be done in a specialised function. That way simple copies remain simple.
Hmmm yes. We could consider this unsupported (as it is unsupported now as well), and only allow direct RNA prop modifications in a frame-change-post handler.
A possible workaround could be to inspect the C code and figure out which RNA properties it changes, and tagging those for update from the handler in Python. I'm not too thrilled about that approach, though, as it's not friendly and would create unclean code where the C and Python code are tightly coupled. I see this break easily.
You don't want to check whether property is animated or not prior to dependency graph tag. While tagging is not fully cheap, it is way cheaper than checking whether property is animated or not.
Nice workflow would be to "integrate" such properties hand-animation as a part of datablock evaluation. I do not see a scene-global handler which traverses objects a nice workflow.
Such things are not importer-specific, so not sure how this is relevant.
It needs to be a generic enough solution, which will live within design of many areas. You can not be limiting considerations to just "properties change of frame-change-post handler".
This isn't how the handler is used.
You can't think in terms of RNA properties.
One of usages is to generated meshes, for example, where handler can remove vertices, add new ones.
Long story short: what do I see here so far is an attempts to address some individual aspects of the problem. What I do not see here is a systematic approach which will analyze how functionality is used, how it is expected to behave, how can solution realistically fit existing design of all related areas.
After discussion with @Sergey we arrived at the following. From what we can see, the following are reasons for having a
frame_change_post
handler:Case 2. is already covered by Blender's current behaviour.
Case 3. could be seen as the frame-change handler being part of the depsgraph evaluation. This could be implemented via customisable Python nodes in the depsgraph. For performance reasons, it's probably a better idea to not do this, and to allow modifying evaluated datablocks from one single function: the frame-change-post handler. However, these changes should not modify (or require modification of) existing relations for sanity's sake. This is likely going to work fine with the current RNA update callbacks. They expect a pointer to original data, and will tag the data for update, but effectively they'll be tagging the evaluated datablock for update. These are not iterated over by the depsgraph, so tagging won't have any impact. For performance & clarity we can explicitly let the tagging functions ignore evaluated datablocks.
Case 4. requires some extra care. We could resolve this by only allowing the creation of new ID datablocks (most importantly Objects) from the frame-change-pre handler. This handler is called after the scene's current frame has been updated, but before the dependency graph evaluation of the new frame.
This issue was referenced by
614d70a87d
Added subscriber: @theres1
If I understand what you are trying to prove in your code, then changing this:
to
will render a static plane of vertices.
I have somewhat similar problem here #77008, though as you can see this line of code does not solve all problems.
Added subscriber: @LeoMoon
Changed status from 'Confirmed' to: 'Resolved'
Changed status from 'Resolved' to: 'Confirmed'
Ooops, got the wrong task number referenced in the commit.
Added subscriber: @OmarEmaraDev
Added subscriber: @brecht
@brecht Do you have any insight in this? Any preference as to one of the alternatives? See #71908#934122 for context.
Regarding #71908#934122:
More explicitly skipping depsgraph tagging of evaluated datablock sounds good to me.
Disallowing adding relations or creating new datablocks in the post handler I'm not sure about. Such changes require a depsgraph rebuild which may be relatively slow, but it's not clear to me why this is more a problem than in the pre handler. Or which specific current bug this helps with.
It's also unclear to me how these things relate to originally reported problem as described in #71908#916261.
If I understand
BKE_scene_graph_update_for_newframe()
correctly, this would be the order of things when relations change in the post-handler:When done in the pre handler:
So indeed, it doesn't look like there is much of a difference, apart from the number of operations performed (and thus performance).
It boils down to the question "when do we allow writing to evaluated datablocks?" So far the answer has been "never", which means that frame-change-post handlers were modifying original data bocks. This in turn led to a conflict between modifications made by the animation system and by the handler (as @Sergey explained in #71908#916261) , which caused this bug report.
If writing to evaluated datablocks is allowed, that makes it possible to first have the depsgraph evaluation produce an evaluated copy, and then have some Python code that modifies the same evaluated copy. This makes it possible to layer changes on top of each other. Obviously this only applies to the frame-change-post handler, because in the frame-change-pre handler there is no evaluated datablock to modify.
Added subscriber: @spiegelball
A workaround for some cases is to reassign the animated property from the evaluated datablock to the original one at the end of the script, e.g.:
EDIT:
In this case the following line enables animation of the ocean modifier:
Added subscriber: @astrid13
Could anyone tell me if this issue been fixed in any update? I am experiencing the same problem with 2.83, 2.91, 2.92 alpha. Or if anyone could kindly point me to a workaround I'd really appreciate it. Thanks
The status of this task is "Confirmed, Normal", which means that this is still an open issue.
@spiegelball Please don't repeat your own comments. This is not a support forum, but a task/issue tracker for Blender developers.
Added subscriber: @danieljabailey
I don't have the time to look at this on short notice, so unassigning myself to allow someone else to step in.
Added subscriber: @HoffmanWood
Added subscriber: @JackTheFoxOtter