- User Since
- Jul 25 2019, 10:07 AM (12 w, 2 d)
Wed, Oct 2
I see, thanks but why doesn't this happen when baking for example smoke in the same way?
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.