- User Since
- Jul 25 2019, 10:07 AM (90 w, 6 d)
Dec 21 2020
Yes, seems to be a duplicate of T81804. Sorry.
I have tried this on two PCs with Arch Linux and also on Windows. Happens everywhere, even in the latest beta.
Including the sound file and a video. Blend file is not needed, happens in a clear default one.
Dec 20 2020
Apr 21 2020
@Sergey Sharybin (sergey) Can be similar principle used for custom compositor node properties? The problem sounds quite similar.
Yes this is quite an annoying problem. I solved it by using bpy.app.handlers.frame_change_pre but...
EDIT: Seems like I just was able to call update but not to get the actual correct value from the property :-(.
EDIT2: Weird, in compositor for example I can see the good result but not when rendering even when using bpy.app.handlers.render_pre. Seems like when changing frame like when clicking or pressing arrow key the animated value is working but not during render. Is it related to T63548?
Apr 19 2020
Feb 13 2020
I understand that, either way the two update callback functions in the API are confusing and as you said should be removed if not implemented or redefined. However the inability to get the updated socket value is a drawback when creating a custom node. Traversing the tree manually is quite annoying since many possible things can happen and the original value might be transformed along the way. It feels like the custom nodes via Python API functionality is still very limited.
Oct 2 2019
I see, thanks but why doesn't this happen when baking for example smoke in the same way?
EDIT: I guess it's because the rest creates external cache directory.
Sep 12 2019
I understand that MVC leads to a clean code but for some reason I think that programming a node should not cover stuff like analyzing the nodes outside and the whole graph. I'd think of node as a unit with interface (sockets and properties) and logic inside, just like a class in C++ for example. But yes in current API situation you are right about that being the best approach. Thanks for sharing that! It helped me a lot. :-)
Yea the traversing idea is what I don't like actually :D. What you described feels far too complex for someone who just needs to add a new node type. It would be far more clean to be able to access the socket value directly from the basic API. It'd be more addon-friendly :D, focusing just on the particular functionality without the need to go outside your own node checking the graph state. But maybe I'm not seeing all the advantages and disadvantages of both approaches.
As I wrote in the comment above, I'd be interested in any kind of value, not just the non-connected one. I think that a unified interface for this would be helpful or a way to get the current value from link.
I see. Anyway I'd like to point out that with the socket update callback the current value of the socket (not just the default_value but also the one coming from the connected node) should be available in some way.
Sep 11 2019
Aug 19 2019
Aug 7 2019
I see, I would really appreciate this feature, it is quite crucial cause this seems to be the only way to make the socket value update work when working with custom nodes. Without it custom nodes lack an important ability to be the part of the compositor nodetree. Thanks for the cooperation.