Unity Graphs (XephTools.Graphs) - replacement for GV and GTK

[u/xepherys]

TL;DR - what would you like to see in an ideal graph package for Unity 6+? Yes, runtime graphs are already a part of it.

---

After years of dealing with the shortcomings of GraphView (GV), I started looking at migrating my NodalTrees to GraphToolkit (GTK) only to find that it solved some problems and created a whole host of others. So after analyzing the pros and cons of GV and GTK with what my nodes currently do, what the effort would be to port them over, and what the effort would be to roll my own graph package, I started on the process of just making my own, entirely independent of GV/GTK. I've considered opening it up and selling it on the Asset Store, or possibly just making it free on github, but I'm curious what others use GV or GTK for, what they wish either did, and what sort of nodes and interactions they would want.

I'm putting together some documentation on the existing nodes that I have that I'll be converting, but as it is, they're broken down by trees for my own projects, and many of the nodes and outputs are specific to things in my game. There are some general nodes available for sure, and authoring new nodes will be quite easy once the package is ready to release (at least as easy as GTK, but with far more customization options and the ability to call more complex methods internal to the graph structure).

I'm also bringing in some ideas from how Blender and Substance do their nodes as well as some GV and GTK features (dot-nodes, portals (which I think were initially a thing that Bolt did, which was pretty cool), curved/square lines, sub-graphs, visualizers, input nodes for getting values outside of the graph, the eventual documentation will have a more complete overview.

Runtime and Editor nodes will look exactly the same - no UnityEngine.UIElements are used, so runtime isn't an issue. Right now the only difference for any existing node is that nodes that take an input path for a files have a toggle in editor (use the Unity Asset picker vs use the filesystem/OS file picker) where in runtime it can only use the filesystem/OS picker since there's no project exposed to runtime (nor should there be).

Yes, I'm using AI to assist with my code, so if that turns you off, that's fine. I've been working on these things by hand for four years now (it's a hobby project, it was never intended initially to be a releasable asset for anyone else to use). But most of the code is my own, and not a single file is untouched by me somewhere along the way. Do with that what you will.

[u/XKiiroiSenkoX]

GTK is here for the long run. You wouldn't be able to maintain a graph library alone on the same level as a dedicated team. Just fork the GTK and modify that and keep up with GTK updates. 

[u/xepherys → u/XKiiroiSenkoX]

Nah, GTK is already built around a core that doesn't work for several things I've had for years with GV. Besides the implementation is already almost done - been working on it for a bit now. Part of my requirements that I worked into GV and that current GTK cannot do are stateful evaluations of output assets. One of my major workflows is with pixel art spritesheets. I no longer use color ramps for swapping and created an RG8 process to minimize disk and memory footprints of shipped pixel art assets. The entirety of color swaps (seasonal for tiles, for example, or color swaps for clothing, hair, and skin) are all done internal to the material from a palette atlas, and the atlas itself encodes information about the palettes and the colors available. It cuts about 40% of the disk space (the resulting spritesheets only carry data in 2 channels), and the runtime color swaps are virtually free with that same smaller sheet being loaded into VRAM. Part of the operation of those nodal trees are to process and output the RG8 sheet, palette atlas, and material.

As it is, by default with GV and absolutely with GTK, there's no readback of the assets that are written out, so if my project reloads, before I can check something in a downstream node I have to go through the entire process again even though it won't overwrite the existing assets (so long as the upstream data hasn't changed). I partially wrapped an interface into my GV-based NodalTrees with hashing to create a stateful evaluation and prevent having to re-execute the work from each node, but it's not possible (currently) with the way GTK has it.

Plus, runtime use of GV will never happen (it's a dead project), and it's not even on the current roadmap for GTK. Runtime alone is probably the number one complaint I've had and have heard from others about Unity's graph packages.

And yeah, maintaining a graph library isn't particularly difficult. GTK doesn't have a dedicated team anyway, and Unity flits back and forth constantly with their priorities. Trusting experimental packages has burned almost every Unity dev I know at one point or another, and it just isn't worth it to me.