Update system requirements

[Durman]

I'm going to create list of desirable features which new update system should include. What can be included in this list is not obvious and can be discussed.

• Performance issue.:

  • Don't recalculate what already was calculated:

    • Nodes should keep results of their calculations.
    • All changes (in parameters, inputs, data from Blender scene ...) should be tracked.
    • Manually prohibition of recalculation (freezing mode)

  • Don't calculate if result is need for nobody:

    • Create output nodes which cause work of other nodes (viewers).
    • Mode for output nodes switch on/off of showing of calculation results

• User should understand what's going on:

  • Use annotations for showing error and other messages.
  • Color system for showing error nodes and different modes or whatever.
  • Showing performance information.

• Performance of workflow:

  • supporting of node subtrees
  • pass data without changes throu node (bypass mode. It is not possible for all nodes)

related: #2770 #2380 #1934 #1990

[Durman]

• User should understand what's going on:

[vicdoval]

Really nice!
No sure the recalculations number is that useful, I guess after 3 minutes tweaking the node-tree it must be a very high number...

[Durman]

I have found that Viewer Draw nodes effect on each other performance. For example first node update time is 1s. Then another node will update faster if the first node will be disabled. I think there should be possibilities for performance improving.

BmeshViewer has similar performance but they does not effect on each other. In this way they are faster.

[enzyme69]

If only we can ESC when Blender or SV is frozen calculating .... --

…

------------------------------------------------------------ - Jimmy Gunawan http://blendersushi.blogspot.com.au http://mayaspiral.blogspot.com.au http://houdoodles.blogspot.com.au http://puppetar.blogspot.com.au

[Durman]

I'm thinking about workflow where error nodes returns their previous result so the rest of a tree still could do something.

[Durman]

Tool which can help to find nodes with slow performance. All nodes with update time more than given value will be dyed into a color.

Also it has mode of coloring last updated nodes. Probably more for debugging purposes.

[portnov]

It seemed to me there already was such coloring... "heat map" or smth like that.

[Durman]

Yes, I know.

[Durman]

I have managed to connect to tree origin.

https://developer.blender.org/T76538

[Durman]

[Durman]

I'm thinking about show this layout button.

What I would expect from the button is to switch on/off all what is drawing in 3d space by current node tree. I see two ways to implement this.

First is where draw nodes do not know about the property and update system make decisions about whether to draw mesh or not by itself. But in this case the nodes should grant extra information about themselves. All output nodes can be splitted at least into two categories which are drawing something in 3d scene and other which can draw in node tree or do other stuff. So only nodes which are drawing into 3d scene should be affected by the property. And in this case the nodes should have interface for switching them on/off so update system could use it.

Second variant is where draw nodes do know about the property. The decision about drawing in 3d space should made inside each draw node separately. It is good in case if a node should have some complex logic on this matter and bad because all nodes should be aware the draw property of a tree what can be easily be forgotten in new draw nodes. Also in this case the option should have its own handler which would search all draw in 3d nodes in a tree and make them switch off/on.

What I'm certain for sure is that update system should know about the draw property of a tree and the draw properties of output nodes so it could make decision about whether it worth to calculate tree for particular output node.

[Durman]

I have came to the next decision. Most simple way will be to have two properties for nodes.

• is_active_output is property which all nodes will have by default with value False. It should be overridden by outputs nodes. They can return true or false dependently their own condition. This property will help to update system recalculate tree more efficiently.
• hide_viewport property will serve two purposes. It will let know to update system that purpose of a node with this property is to draw in viewport because only such nodes will have this property. And it will let to update system to toggle hide property of objects which are owned by nodes.

Whole process should looks next. Update system will get signal that the property of a tree was changed. If the property is hide it will find all nodes with hide_viewport property and toggle them. If the property is show it will find all nodes before output nodes and check their update status. If update status is outdated it will reevaluate the tree and then toggle hide_viewport property of output nodes.

[Durman]

If calculate output is too expensive it will be possible to disable output node and set properties without delays.

[Durman]

This module would help if Blender will ever use Python 3.9
https://docs.python.org/3/library/graphlib.html

[portnov]

At the moment we have sverchok.utils.topo module, which implements "stable topological sorting". As far as I remember, id does not raise exception in case of cycles, just "tears them apart" somehow.

[Durman]

Would be nice if the code could have any documentation

[Durman]

I think new update system should be as easy replaceable as possible according experience based on current update system.

class AbstractHandler(ABC):
    @abstractmethod
    def send(self, event): ...


class ConcreteHandler(AbstractHandler):
    def send(self, event):
        if event.type == 'TreeUpdate':
            update_tree()


class Tree:
    handler = ConcreteHandler()

    def update(self, context):
        handler.send(Event(type='TreeUpdate'))

In this case if someone decides to create another update system the doing next will be enough.

class AnotherConcreteHandler(AbstractHandler):
    def send(self, event):
        if event.type == 'TreeUpdate':
            update_tree_differently()


class Tree:
    handler = AnotherConcreteHandler()

It will be even possible to have several update systems if needed switching between them via addon properties for example.