search

setzer22 / egui_node_graph

Build your node graph applications in Rust, using egui
MIT License
736 stars 138 forks source link

Infinite loop countermeasure #21

Open kkngsm opened 2 years ago

kkngsm commented 2 years ago

If you build the nodes in this way and click on "👁 Set active" button, the application will crash. image

How about providing a way for the library to avoid crashing if the loop is accidentally created?

For example, if I loop in blender, it looks like this and will not compute. image

setzer22 commented 2 years ago

This library is mainly about creating and displaying node graphs using egui. Execution semantics is up to the user, so the meaning of a loop should not be defined by the library. However, I'm open to a solution that detects and breaks depdendency cycles for the example crate, since you're right that the current implementation gets into an infinite loop.

I didn't include this check to avoid over-complicating the example code, but maybe a simple solution using petgraph wouldn't add a lot of noise to it. I'm a bit busy currently, but I'd be happy to review and merge a PR for this :smile:

kkngsm commented 2 years ago

Thank you for your response.

To add an addendum. First, I would like the connection to turn red when an infinite loop occurs, like in Blender. It is easy to see where the loop is. Secondly, if it should be handled on the application side, I would at least like to have a function that turns the connection red.

However, I think it would be easier to handle this on the library side. This is because there are no applications that allow infinite loops (and even if there were, they could not be implemented in this library). I don't think it's smart to implement the exact same implementation by all library users.

setzer22 commented 2 years ago

This is because there are no applications that allow infinite loops (and even if there were, they could not be implemented in this library).

What I mean is that everything depends on execution semantics. In a graph loops are not infinite, they're just loops, it's up to you how to interpret them. For instance, I can easily imagine a system where the node ports are used for control flow (like in UE5 blueprints or Godot's VisualScripting), where cycles in the graph are used to represent loops in the visual script. Some users of this library want to do just that, and while it's not exactly supported just yet, it's definitely something that I'd like to support.

Still, I see your point. If you're thinking about data flow "dependency" graphs like most things Blender uses graphs for, then yes, loops are quite undesirable in that situation because they represent a dependency cycle (i.e. a dependency that can never be fulfilled).

I would at least like to have a function that turns the connection red

I think this would be helpful. It is fair to assume many applications are going to want an acyclic graph, but this needs to be implemented in a way users that don't need it can disable it :+1:

Still a bit busy to work on this actively, but I'd be happy to guide anyone who wants to take on this issue! :smile:

kkngsm commented 2 years ago

I see! I understand now. It seems my knowledge was shallow. I would like to work on it, but my technical skills seem to be lacking😢.