Custom Prop Does Not Fire Update When Driven By F-Curve #37473

New Issue

Atomic · 2013-11-15T15:43:34+01:00

Atomic commented

2013-11-15 15:43:34 +01:00

System Information
Windows 7 x64 8GB
nVidia 460gtx 1GB

Blender Version
2.69 official release

Short description of error
Custom Prop Does Not Fire Update When Driven By F-Curve
My guess is that only a draw() event is being issued and not and update() behind the scenes.

Exact steps for others to reproduce the error
custom_node_update_issue.zip
I have attached a custom node AddOn and a BLEND file that uses that AddOn.
Drop the AddOn into your AddOn folder and activate "test_node" under User Preferences. Then open the BLEND file.
You should see a series of three Float nodes.
Put Blender and the Console side by side so you can view the AddOn output.

The first node is animated. Scrub the Node Property Value directly to observe that the node does correctly send an update to all nodes downstream of it's output. It also generated print statements in the console as events are fired.

Scrub the Timeline and you will see that while the animated node and the next companion node do update, the third node does not. This is because the update=updateProperty def is not being fired when it is driven by an f-curve. This should happen. When I place a custom property under the object panel and animate it I do get an update event fired by the property. Also you will notice that not a single print statement is generated by the AddOn when you scrub the timeline even though the property value does change. This is the result of what I am calling a "fake" update event.

value = bpy.props.FloatProperty(name = "Float", default=DEFAULT_FLOAT, update=updateProperty)

Theupdate() event of the node itself is not firing when you scrub the animation or render the animation via F12.

The only reason we see the second node update when we scrub the timeline is because there is some kind of special code in Blender that forces this "fake" update to only the first node connected. This "fake" update event should be removed from the system.

My guess is that only a draw() event is being issued and not and update() behind the scenes.

I know this is kind of a complex issue and please point out if my code is wrong. I hope this is enough info to describe the bug

**System Information** Windows 7 x64 8GB nVidia 460gtx 1GB **Blender Version** 2.69 official release **Short description of error** Custom Prop Does Not Fire Update When Driven By F-Curve **My guess is that only a draw() event is being issued and not and update() behind the scenes.** **Exact steps for others to reproduce the error** [custom_node_update_issue.zip](https://archive.blender.org/developer/F27573/custom_node_update_issue.zip) I have attached a custom node AddOn and a BLEND file that uses that AddOn. Drop the AddOn into your AddOn folder and activate "test_node" under *User Preferences*. Then open the BLEND file. You should see a series of three Float nodes. Put Blender and the Console side by side so you can view the AddOn output. The first node is animated. **Scrub the Node Property Value** directly to observe that the node does correctly send an update to all nodes downstream of it's output. It also generated print statements in the console as events are fired. **Scrub the Timeline** and you will see that while the animated node and the next companion node do update, the third node does not. This is because the *update=updateProperty* def is not being fired when it is driven by an f-curve. This should happen. When I place a custom property under the object panel and animate it I do get an update event fired by the property. Also you will notice that not a single print statement is generated by the AddOn when you scrub the timeline even though the property value does change. This is the result of what I am calling a "fake" update event. ``` value = bpy.props.FloatProperty(name = "Float", default=DEFAULT_FLOAT, update=updateProperty) ``` The*update()* event of the node itself is not firing when you scrub the animation or render the animation via F12. The only reason we see the second node update when we scrub the timeline is because there is some kind of special code in Blender that forces this "fake" update to only the first node connected. This "fake" update event should be removed from the system. My guess is that only a draw() event is being issued and not and update() behind the scenes. I know this is kind of a complex issue and please point out if my code is wrong. I hope this is enough info to describe the bug

Atomic commented

2013-11-15 15:43:34 +01:00

Changed status to: 'Open'

Atomic commented

2013-11-15 15:43:34 +01:00

Added subscriber: @AtomP

blender-admin commented

2013-11-15 15:43:34 +01:00

#95642 was marked as duplicate of this issue

blender-admin commented

2013-11-15 15:43:34 +01:00

#86675 was marked as duplicate of this issue

blender-admin commented

2013-11-15 15:43:34 +01:00

blender/blender-addons#48285 was marked as duplicate of this issue

blender-admin commented

2013-11-15 15:43:34 +01:00

blender/blender-addons#28286 was marked as duplicate of this issue

Lukas Tönne was assigned by Bastien Montagne

2013-11-15 19:57:30 +01:00

Bastien Montagne commented

2013-11-15 19:58:45 +01:00

Added subscriber: @mont29

Bastien Montagne commented

2013-11-15 19:58:45 +01:00

Assigning to Lukas to make the final decision, but I think this is a known limitation of our current depsgraph…

Lukas Tönne commented

2013-11-16 18:56:46 +01:00

Added subscribers: @ideasman42, @dfelinto, @JoshuaLeung, @brecht, @Ton

Lukas Tönne commented

2013-11-16 18:56:46 +01:00

◀ Merged tasks: blender/blender-addons#28286.

Lukas Tönne commented

2013-11-16 18:58:20 +01:00

Indeed this is a general limitation of the animation system: it doesn't execute update callbacks of properties. This has been discussed several times, but doesn't look like it's simple to implement, mostly because it would add overhead and slow down animation playback significantly (see duplicates and blog post by Joshua )

Indeed this is a general limitation of the animation system: it doesn't execute update callbacks of properties. This has been discussed several times, but doesn't look like it's simple to implement, mostly because it would add overhead and slow down animation playback significantly (see duplicates and [blog post by Joshua ](http://aligorith.blogspot.de/2011/07/gsoc11-rna-property-updates-working-for.html))

Lukas Tönne commented

2013-11-16 19:03:12 +01:00

For your specific case i would suggest using a frame update handler and do an evaluation of the node tree data there. Using update callbacks for evaluating nodes is generally not the best way to handle it, they are intended for handling updates locally.

For your specific case i would suggest using a [frame update handler ](http://www.blender.org/documentation/blender_python_api_2_69_1/bpy.app.handlers.html#bpy.app.handlers.frame_change_post) and do an evaluation of the node tree data there. Using update callbacks for evaluating nodes is generally not the best way to handle it, they are intended for handling updates locally.

Lukas Tönne commented

2013-11-16 19:07:44 +01:00

Changed status from 'Open' to: 'Archived'

Lukas Tönne closed this issue

2013-11-16 19:07:44 +01:00

Kasper commented

2018-10-28 22:45:15 +01:00

Added subscriber: @kpghost

Kasper commented

2018-10-28 22:45:15 +01:00

It's been a while since this bug was opened. Is using a frame update handler (as mentioned by lukastoenne) still the recommended way to process updates to custom properties while animating? Or is there a better/simpler way now?