nortikin / sverchok

Sverchok
http://nortikin.github.io/sverchok/
GNU General Public License v3.0
2.22k stars 233 forks source link

Update system requirements #3058

Closed Durman closed 3 years ago

Durman commented 4 years ago

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.

related: #2770 #2380 #1934 #1990

Durman commented 4 years ago

node statistics

vicdoval commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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


Durman commented 4 years ago

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

Durman commented 4 years ago

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. slow nodes

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

portnov commented 4 years ago

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

Durman commented 4 years ago

Yes, I know.

Durman commented 4 years ago

I have managed to connect to tree origin. cool bug https://developer.blender.org/T76538

Durman commented 4 years ago

2020-05-09_08-58-06

Durman commented 4 years ago

I'm thinking about show this layout button. 2020-05-17_11-59-38

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 outputnodes 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 commented 4 years ago

I have came to the next decision. Most simple way will be to have two properties for 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 commented 4 years ago

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

updating

Durman commented 3 years ago

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

portnov commented 3 years ago

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 commented 3 years ago

Would be nice if the code could have any documentation

Durman commented 3 years ago

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.