Graph Editor Architecture

Question

Graph Editor Architecture

teodosin opened this issue a year ago · 7 comments

Answer 1 · 2023-12-20T10:20:45.000Z

Initial thoughts:
#48 Seems like a good aspirational goal. If Karta is eventually meant to appeal to programmers or writers, it would make sense that the entire UI / App would have support for keyboard only. Traditional keyboard shortcuts with the modifier keys as well as a vim-mode for those who don't want to move their hands from the home row. This could be under a feature flag.

Touch and stylus support would also be a feature. Also down the line: Vr controller and glove support. But that's not for at least a year or two or three.

One thing that needs to be decided now is whether the graph view nodes should remain as separate entities from the data they contain. I'm thinking yes. A graph node should only contain the data necessary to draw itself and interact with the graph. What happens in the scene (#49) should be a separate set of entities that work stand-alone even without the graph editor plugin.

A graph view node entity is always spawned when its data counterpart is also spawned. It may be turned invisible, but it is there. It may remain spawned after its data is despawned if it is pinned to presence. It would be nice to make it so the ui reacts automatically to the Scene World so that the Scene World doesn't have to know about the graph. The graph could be used to insert systems and logic into the Scene World but the Scene World itself doesn't have to know about the graph. This I think is a requirement for any kind of use as a Bevy game editor.

Graph view nodes should generate their preview and the cache it. They shouldn't keep their relevant files loaded. The scene will be in charge of that, if those Assets are needed by it.

An immediate change that should be made is the restructuring of context.rs. The update_context function should be split up into marking the despawnable nodes, the spawning of an individual node (the root) spawning the context of that node. Something like that. Both the spawn and despawn functions optionally take in a filter as an input to select which nodes to despawn and which ones to spawn from a context.

Answer 2 · 2023-12-26T10:44:29.000Z

How would this work as a crate that could be added to any bevy project?

Visualise entities and their relationships as well as system schedules, resources, and events.

Karta would then be an app that merely uses the graph crate to visualise itself. It would just manage the database of node networks, spawn nodes as entities and the graph representation would be generated by the graph crate just like for any other bevy app.

I personally still need a much deeper understanding of Bevy in order to make this work. I'm not clear on the separation between Karta's features and those that should belong in the crate. There might also need to be ergonomic ways to define custom node types, context menu actions and such on a per-app basis. And all this needs to play well with Karta's own scene system.

Not in scope of the thesis, I don't think.

Answer 3 · 2024-01-03T12:55:53.000Z

The context menu for the graph editor obviously needs to be defined inside the crate. Users of the crate should be then able to add their own actions to the menu. How should this be implemented? With a trait? A method that modifies some resource? How would this play nicely with the ECS?

What if context menu actions could be defined per-component? Intuitively that feels powerful. Then users could impl the trait on the components that they want to add context menu actions to. Hmmmm

Answer 4 · 2024-01-03T13:17:58.000Z

https://github.com/teodosin/bevy_overlay_graph

In preparation.

Answer 5 · 2024-01-03T13:27:33.000Z

Another important thing that needs to be iterated on is how to separate the inputs of the underlying Bevy app and the graph crate. The graph is an application by itself with navigation and menus and such, but it should not interfere with the user's app inputs. There needs to be some kind of toggle that is able to disable the user's inputs to their own app from within the crate. At least that would be most ergonomic, so the user wouldn't have to manually make sure to disable their app inputs when they want to navigate the overlay.

So far this feels like the biggest hurdle in making this usable as a crate.

Answer 6 · 2024-01-14T20:22:32.000Z

Sunday project: https://github.com/teodosin/bevy_overlay_graph now exists. It works; it spawns nodes for each entity with the GraphEntity component and displays their Name component on the node label. There's a lot of work to do there to reach feature parity with Karta's current build but without all the coupling.

I'm working on that crate in a separate workspace and using a dummy Bevy project to test it. I think that's a better path than refactoring and creating the crate while still inside Karta. This way I can build the crate to support what Karta needs without breaking Karta. Then when there's feature parity, Karta can be refactored to use the crate's API.

Answer 7 · 2024-09-19T16:41:21.000Z

Cleaning up some issues. Most of the work has been done in now deprecated repos which have been merged into this monorepo.

Graph Editor Architecture

Tracking issue and summary for determining the proper architecture for the graph entity crate. The goal is to separate this into a standalone crate that can be used by any bevy project.

Resources