There are plenty of cases where the nodes and edges are super relevant and useful. I’ve listed many already. Other have too.
You call it editor data because you have no use for it in runtime. Many of us do.
That’s what compilation is for. Build time takes care of these issues.
I’ve just finished translating my old xNode based generation graph to the new Graph Toolkit
I think you have some misconceptions about the purpose of graph toolkit that could be alleviated if you tried building a graph model with it. I’d especially recommend taking a close look at the VisualNovelDirector Sample project as it was what proved most helpful for me.
You can create all the structure you need using graph toolkit, but if the tool you’re building has a runtime component to it, take a look at the VisualNovelDirectorImporter which is responsible for translating the editor graph into the structure/data your game uses at run time. In my case I needed to translate the graph into structs for sending to the GPU. Previously, with xNode, there was less separation between the Graph nodes and the Runtime nodes, but I still needed code to translate data from the graph into runtime data compatible with my compute shaders.
For the GTK team: One issue I’m seeing is that despite the graph handling float3’s just fine the following is showing up in the console when I modify the graph (not save, just modify) during play:
No script asset for Wrapper_float3_0. Check that the definition is in a file of the same name.
I’m not sure what I would have to do to fix this or if it’s a known issue.
I have built a visual novel director (link here). The data structure that it needs IS A GRAPH. I do not need to translate it to any other data structure.
I seriously do not understand the argument of making the graph editor-only. If people are so determined in using importers to transform the graph into another data structure (for whatever reason you might have), you can still do it, if the graph is available at runtime. Everyone would get what they want.
Forgive me if this is addressed somewhere, but are there plans to allow us to make modifications to nodes beyond Inputs/Outputs and Options? For example, I’m planning on making a graph tool for creating procedural creatures and it would be nice if I could preview creature parts inside the graph.
We did (or at least I did), it’s a simple runtime example but a suboptimal Visual Novel implementation. It’s implemented in a way that assumes complete runtime separation from the editor since it imports some editor nodes as two runtime nodes, which might work for some but in a dialogue tool I’d much prefer 1:1 mapping with the editor and clear signaling back to the editor so I can highlight edges and nodes for debugging purposes. The short example already has a ton of nodes which have to be manually scrolled and inspected by eye when debugging, which is pretty old school. And we need most of the editor graph data for proper story branching as well, the example is entirely linear.
Don’t you want your runtime data to be as efficient as possible? If I’m a user of your tool, I don’t want serialized editor data for a runtime visualization tool that I’m not going to use in production.
Instead of Unity generating all possible data, it would be better for your tool to optionally include extra information for a runtime visualization. Then you control what data is defined on the runtime asset.
That’s the great thing about GTK’s current design. You can control what data is included at runtime. Auto generation is a slippery slope.
I will repeat it one more time:
Unused data is NOT in the build. Compilation prevents this. There isn’t unused data in production. No memory overhead. No performance penalty. Nothing at all.
If you want optimized structures according to your own criteria you can still do it, even when the graph data is available in the runtime namespace.
What I find annoying is the limitation that nodes must be in the same assembly as the graph definition. I can’t make a “base” assembly with the graph and node definitions, then add another assembly for an extension and create nodes there that inherit from the base definitions. They just won’t appear.
Is there a reason for this behaviour?
Are you sure they have to be? I’m pretty sure I saw an option that this was just the default behaviour for convenience of auto adding nodes, but you can turn off the auto find and do it manually.
As long as there are references to data/objects, they’ll be included in the build. That means even if you don’t use the meta/editor-data directly, if the graph data references it, everything ends up in the build.
I’d push back on calling it “editor-data”. That label assumes the data has no value at runtime, but that is for each developer to decide. The toolkit should not enforce that judgment by design.
Yes. If your runtime logic references something, it will be included in the build. But that is true of any Unity asset. It does not mean exposing graph data is dangerous or bloated. It just means you should structure your runtime references carefully. What you reference is what you get. This is not a flaw, it is how Unity works.
And ONCE AGAIN: if you want to optimize the structure that gets included, you still can, even with graph data exposed at runtime namespace. Hiding it only makes the tool less capable. It does absolutely nothing else.
Really, is there an option? I didn‘t find anything like that, but will check again 
After experiencing the powerful and user-friendly node system in Houdini, I would like to offer a few suggestions for the GTK node graph:
a. Use color to represent commonly used port types.
b. Omit port names and instead display port information (such as the name) on hover.
c. Remove input controls directly on the ports; instead, input values through the node inspector. If a port’s value is important enough to be visible in the graph, use a dedicated constant node as the input.
Why:
The node graph should convey only the most essential information: what each node does, and how nodes are connected. In contrast, the ports of a node tend to be relatively stable — after using them a few times, users usually remember their functions even without visible UI. When in doubt, hovering the mouse over a port can provide the necessary details. Displaying all port information directly on the graph wastes both the user’s cognitive bandwidth and valuable canvas space.
Here is a screenshot of a node graph in Houdini — it uses icons, shapes, colors, and label text to help users quickly identify nodes and key information.
Good option to be able to collapse graph to this representation
If editor asset references something you just dont care 
So only referenced assets will be part of the build
If you have Editor assembly with graph editor and everything that rely on editor tools,
you have Runtime assembly where your runtime nodes lives
and you have asset with graph that is editor graph with sub asset consisting of runtime nodes →
referencing runtime asset dont make editor asset part of the build e.g. Referencing one mesh of fbx donr make entire fbx part of the build
So for some tools we need GTK to be editor of our data so we can, in play mode, see how our data works, debug it and so on.
It is not enough to export editor graph to something else.
We need 1:1 connection to runtime nodes and show runtime state in live and allow to change it.
Like components on Game objects you see what happens in runtime and even see if runtime changes or creates you graph on the fly.
So we need to construct editor graph based on runtime nodes not only runtime nodes based on edit graph. And make then interconnected.
Several people have mentioned that they’d like to access the same graph data at runtime, and that anything unused shouldn’t be ‘compiled’. My point is that Unity’s serialization doesn’t work that way, unless maybe we’re talking about code sections excluded with #if UNITY_EDITOR, which again would be hardcoded.
It’s also possible that people are confusing the definition of the graph (e.g. a dialogue system) with the stored assets (the actual dialogues).
I’m talking about the latter. In the dialogue system example, when I save a dialogue, the UI state and references to editor assets/assemblies also get serialized. If the system had full runtime support, that would mean everything ends up in the build, whether it’s directly used or not.
As far as I know, Unity doesn’t trim serialized data. it only tracks references, not whether individual fields are actually used.
I don’t think the amount of data will matter, honestly. It’ll be a few extra nano-seconds of deserialization, and a few extra bytes for node positions and other data. Nothing that will break the bank quite frankly.
Worrying about the data size in this instance feels like a premature optimisation. I care more about how long it’d take me to implement something.
As it stands, I’d have to do this for every single node in a dialogue or even a simply high-level visual scripting system in GTK:
public sealed class SomeNodeEditor : Node
{
public override RuntimeNode GetRuntimeNode()
{
public new SomeNodeRuntime();
}
}
public sealed class SomeNodeRuntime : RuntimeNode
{
}
Which is just going to be a drag.
while you are right I showed a way where referencing graph dont mean referensing all editor nodes data or type or asset.
see. my prev post link
Reading through this, I get the feeling that the Unity devs and the people commenting on the “runtime” part are talking about 2 different things.
When reading through the replies some of the devs make, it makes me feel like they think we want the entire graph tool to be available in a runtime version as well (so we can make graphs at runtime), which would be cool and I would love that, it’s not the point.
I think what @spiney199 shows is pretty much the best basic example. Some of us already work with the data we set in the node directly at runtime, requiring we make an exact copy of the editor node as a runtime node to make it work. The frustrating part is that we need to essentially make duplicate nodes. One for the editor and one for runtime that share the same data (some, like positioning of the node might not really be needed, but it is a small amount of data anyway)
While I also don’t see why the data is editor specific, I get the idea behind it and being able to export the data to something you might want to use, not everyone is making tools that copy the data one on one. But considering the data export functionality already exists, I don’t really see why both can’t be there?
Need the exact data? Done, it’s there. Need it to be in some specific format/structure? Export it and structure it to your needs.
I haven’t really worked with it yet, just read through some code, but for me, the connections/wires are important. I made a graph with GTF where I would be able to set “evaluators” on the wires and if they evaluate to true, I would move on to that node. The nodes simply had a list of “actions” that would be executed.
Both the evaluators and actions would be abstract classes with specific implementations. I got all the data I need, no need to explicitly export it. Would love to be able to use it the same way.
Same here with VS, though I also use C# much, I find VS very useful and wrote a little lib of additional units. I also teach and we use it yearly with 100s of students to kickstart their coding skills and using Unity. AI is great and improving, but works best when they use it with the basic coding foundations.
Hope Unity doesnt abandon VS