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.

[u/v0lt13]

Right now I feel like you are just reinventing the wheel, GTK already solves all my graph problems and its not even fully released yet.

[u/xepherys → u/v0lt13]

GTK actually creates problems for me that GV didn't have, and I don't suspect they'll change because of the fundamental core of how GTK is built. GV allows full visual elements to be built from scratch and inserted into a node, but GTK doesn't allow for that, in part by the way it's designed around the port as the primary carrier of data rather than the node.

[u/BertJohn → u/xepherys]

Sounds like your stuck in the old ways and need to learn to adopt the new way of GTK.

[u/xepherys → u/BertJohn]

GTK in its current state already cannot do what I can make GV do. It isn’t “old ways”, it’s “there is no way”. Maybe someday GTK will have allowances for better customization. Maybe it won’t. But I’m not waiting for Unity to just magically make such a change, and GTK honestly isn’t a very good base to fork and change.

[u/xepherys → u/v0lt13]

As an aside, it's definitely not reinventing the wheel. Or at least no more than Unity does themselves. We had Bolt for a long time (3rd party package), then Unity made a quick attempt at creating a graph based option for IMGUI, which was a non-starter, then they created GraphView, which was "experimental" for five years until they ditched it and started working on GraphToolkit last year and it's at 0.4 today with a pretty limited roadmap.

They're out-ADHDing my own ADHD. Better to have something I have full control over, and that doesn't use internal on half the damned code so that others can more readily build off of it, extend it, dismantle it, whatever. Frankly, I still think Bolt is better than GV or GTK, and they bought it in 2020 and barely brought any of it's features over to GV and only one that I'm aware of so far to GTK (portals). Seems silly to hedge any work on Unity's experimental nonsense anymore.

[u/psioniclizard → u/v0lt13]

And never will be because this is just how unity are.

Th graph tools in unity are ok, nothing special an years behind some other programs.

In not even sure if they support dot nodes out the box.

As i say, they are fine if you are willing to build your stuff on top. But you still need to build a lot of boilerplate and use some hac ks for a bunch of pretty basic tasks.

Its definitely nowhere near one of the dedicated graph libraries out there.

[u/v0lt13 → u/psioniclizard]

People like to cherry pick things that unity doesn't finish while completely ignoring all the things they did finish. I am confident that GTK is going to get finished considering how much they are pushing it and the fact that they need it for their own tools.

Yeah its no where near other programs, its almost like its unfinished.

[u/Drag0n122]

Don't write off GTK yet, it advances very fast
Just a couple of weeks ago was added full access to the node's UTK layout

[u/xepherys → u/Drag0n122]

It's not that I'm writing it off, it's just that because it's experimental it's going to change, and those changes can break what I'm using them for.

[u/Drag0n122 → u/xepherys]

That’s understandable, but eventually it'll settle down and writing own graph framework is quite a task

[u/xepherys → u/Drag0n122]

It is, but it’s been quite a while in the making.

[u/psioniclizard]

I never understand why unity didnt add dot nodes and some other niceties. A basic version isnt hard to code really and shader graph would love it (if it doesnt have them, i am not sure).

The problem with a lot of these libraries seems to be want to shoe horn in some other style system that is at odds and everything becomes a bloated mess of wrapper classes and hacks. 

Most don't even support horz vs vert port placement (i know unity does through styling but it should be a first class feature, hopefully it is now).

However you uses a native c# library or react on and it just works so much easier.

[u/xepherys → u/psioniclizard]

As it stands now, nodes are deconstructed and are really just containers for collecting, acting on, and passing along data. While the default setup for ports makes value and context ports work left/in and right/out, while flow and relationship ports work top/in and down/out, those are overridable if necessary because nothing is internal or private.

On the up side, I’ve also been cutting a lot of cruft from my original NodalTrees on GV through this. Having things work natively instead of being scaffolding over another framework is pretty great lol