Graph Tool Foundation

So recently I stumbled upon this package called “Graph Tool Foundation”. Its purpose was self explanatory and after downloading it and taking a look at the attached sample I realised it’s potential. It is essentially a remake of the experimental Graph View API, and it looks promising, but apart from the package website and some confused users on a forum post there is nothing written about it.



It seems to have a lot of cool features (some shown in this Twitter thread I made) but no one seems to be talking about it. There should be a sub-forum dedicated to it, so people can test it out and give feedback, but there is nothing.

Is there anyone working at Unity who can say or do anything about it? I know it’s experimental, and it is only in version 0.8. But still, we have forums like the UI toolkit forum which has been there since almost the very beginning of the package, and having used that forum a lot, I have seen the value of early feedback in such APIs.

 

Thank you! I hadn't taken a look at the Manual since 0.5 and looks like there's a bit more documentation now to get started. Happy to see a common graph library is moving forward and not behind an internal gate

 

No problem! This API has the potential to change Unity tools forever, but only if people know about them. The samples are a good place to start and they seem to be updating the package frequently, so that's a good thing.

 

The only place this is really being talked about is in the Visual Scripting for Unity forums. The devs there talked about switching the front end of VS from Bolt to Graph View Foundation. It's still not ready yet as they've said so not a lot of tools are using it yet but it will be the standard for all of them soon.

Also if you have used the early versions of DOTS Visual Scripting, those also used Graph View Foundation. That was the first major Graph Tool I know of that used it and where I first saw it mentioned.

 

OK, so I have gotten some time to experiment with it now, and due to the lack of a dedicated forum for this, I am just going to write some of my thoughts here:

Good:
First of all I just wanted to say that so far my experience with Graph Tool Foundation has been really good. I like that it takes care of the basics such as:
1. copy/paste (Even between graphs)
2. saving/loading
3. connecting ports and compatibility (+ portals & control points)
4. navigation + minimap
5. undo/redo
6. creating/deletion

I also like how easy it is to create properties in the blackboard and how far you get with the recipes sample in terms of useful functionality.

Needs Improvement:
1. Access to the node UI given a node model (this might already be a thing, but not as far as I could find). In the Graph View API this was really easy, and it made it possible to do things such as this (change title container color and header font size and weight):

2. Color should not change the entire node, only the title content to avoid ugly colored thin edges like this:

3. Per node boolean overrides for things such as "CanDelete", "CanChangeColor", "CanRename" etc. which would change how the contextual menu behaves when this node is selected.
4. Blackboard properties should be drawn in the inspector.
5. Node properties are currently a hazzle to deal with and feels like a workaround.
6. The node inspector should show up as a floating window next to a node hen you click it, and not be a static panel.

Questions:
Even though the step by step get started guide is really good, there are still some API related questions I have, such as:
1. Where do you insert nodes programatically if you want them to be created the first time you open the graph? (Answer in next reply)
2. How do I utilize (or remove as I might not need) this:

3. What are these icons and how can I change them?

4. How can I change the color of the edges?
5. What are execution ports and how do I use them to something useful?
6. How am I supposed to traverse the graph structure given a NodeModel to start from?

Bugs:
Although most of the package runs as expected, I still stumble upon some unexpected behaviour from time to time.
1. Properties from the blackboard can only be connected to a single port and when you try to connect to more, it creates a new property node:

2. (More bugs in additional posts as I am limited to only 5 attachments per post)

 

Alright, so I figured out the first and most important question. In the Stencil, there is a method called "PreProcessGraph" which you can override. Here, I cast the "GraphModel" property to my own graph model type and call "Initialize" on it. The Initialize method just adds my root node, but you can put all sorts of functionality in here.

Stencil:

Code (CSharp):

1. public override void PreProcessGraph(IGraphModel graphModel)
2. {
3.     if (GraphModel.NodeModels.Count == 0) ((InterfaceGraphModel)GraphModel).Initialize();
4.     base.PreProcessGraph(graphModel);
5. }

GraphModel:

Code (CSharp):

1. public void Initialize()
2. {
3.     CreateNode(typeof(RootNode), "Root", Vector2.one * 250);
4. }

 

Awesome work! Thanks for putting in the effort and sharing your findings. Definitely going to play around very soon, will come handy with something I'm working on for a later time. Looks like it's headed in a great direction though.

 

Another interesting thing I found was "Execution Ports". Don't know how to use them, but this is how you make them:

Code (CSharp):

1. protected override void OnDefineNode()
2. {
3.     base.OnDefineNode();
4.     this.AddExecutionInputPort("Input");
5.     this.AddExecutionOutputPort("Output");
6. }

It will look like this (Notice the yellow edge and the square port):


And placeholder ports, which makes your graph look angry:

Code (CSharp):

1. protected override void OnDefineNode()
2. {
3.     base.OnDefineNode();
4.     this.AddPlaceHolderPort(Direction.Input, "Input");
5.     this.AddPlaceHolderPort(Direction.Output, "Output");
6. }

 

This is how you make tooltips for the nodes:

Code (CSharp):

1. public class StyleNode: NodeModel
2. {
3.     public override string Tooltip => "This is a tooltip";
4. }

 

Getting closer to figuring this out. By using some built in TypeHandles such as TypeHandle.Float and TypeHandle.Vector2 you get ports with other icons and different colors. Somehow there must be a way to make my own icons and colors..


Not related to ports, but I figured out how to disallow certain behaviour on nodes, such as deleting, moving and collapsing (Place in your node script):

Code (CSharp):

1. protected override void InitCapabilities()
2. {
3.     m_Capabilities = new List<Capabilities>
4.     {
5.         //UnityEditor.GraphToolsFoundation.Overdrive.Capabilities.Deletable,
6.         //UnityEditor.GraphToolsFoundation.Overdrive.Capabilities.Droppable,
7.         //UnityEditor.GraphToolsFoundation.Overdrive.Capabilities.Copiable,
8.         UnityEditor.GraphToolsFoundation.Overdrive.Capabilities.Selectable,
9.         UnityEditor.GraphToolsFoundation.Overdrive.Capabilities.Movable,
10.         UnityEditor.GraphToolsFoundation.Overdrive.Capabilities.Collapsible
11.     };
12. }
13. protected override void OnDefineNode()
14. {
15.     base.OnDefineNode();
16.     InitCapabilities();
17. }

More correct? way of doing it:

Code (CSharp):

1. this.SetCapability(UnityEditor.GraphToolsFoundation.Overdrive.Capabilities.Deletable, false);

 

@LaurentGibert --

I want to interject that I would like to create nodes that don't simply take ports with "input" -- but rather rely on data predefined elsewhere (during edit time mostly -- but in special cases, during runtime as well).
The UI for this likely would just be a simple right-click on the node to define its source in the graph view (rather than a dropdown or input-box or whatever).

The node itself would specify the type of data source it would need as an input (i.e. DOTS entity, DOTS entity prefab, Serializable Object, Scriptable Singleton, Scriptable Object, Monobehaviour Variable/Type, Monobehaviour List of Variables/Types).

A few possible sources for this node's input data that I can see using ALL THE TIME:

1. a convertible DOTS prefab's entity data (and/or its respective "dataless tag" entries -- not necessarily the "active" dataless tags that exist for the entity however, but these need to be considered as well in some special cases)
   
   
2. a serialized database object (serializable object -- i.e. scriptable object, scriptable singleton)
   
   
3. a set of variables (i.e. a list of scripts, objects, types, tags, layers, etc.) that can be referenced from anywhere, as long as they are explicitly told to be accessible in a particular scope (such as by using "dataless tags" -- see any forum post by me that discusses these for defining scope)

Lastly, defining a node that is simply an image (and a background image that is simply an image) that can be zoomed in/out with the nodes (in cases where I need to keep track of particular groups of things visually -- relative to the nodes themselves and their actual sizes). The background image should be able to be set to be non-zoomable as well (i.e. a logo or whatever defining the particular type of graph being displayed). Clearly, the background image visuals should be able to rely on conditional display (i.e. a graph without nodes should be able to display an "empty" logo, for example). In my case however, I need the background image to stay at the graph origin and be zoomable (i.e. scaled to the current zoom level). I can see no need for it to follow the view in my use-case (or be independent of its scale).

There should be support for multiple BG images though -- i.e. the main image follows my zoom scale (but not view positioning), but the logo behind the main image is independent of the zoom scale / view positioning.



Lastly, and most importantly:

I also would like for some nodes to allow me to specify that they navigate me to a particular graph type (and then right-click the node to specify which specific graph that is). This right-click menu should be editable (so I can define my own UI / UX for specifying those particular graphs / types of graphs in a special way if I deem it necessary). This is extremely critical to letting me use existing Visual Script graphs and adding in my own way of working with them that is more streamlined (and productive) for my particular game's (overall) architectural approach.

I would like to specify my own "Scope" using dataless tags, for example -- then execute different graphs based on the scope I've setup with the tags I've chosen for certain objects in my game.
In other cases in my graph, I would simply like to edit these nodes to point to a particular UI that lets me set some specific data within the graph-view that is NOT node-related (despite being located somewhat within the node context). This is for convenience and UX -- not out of necessity (except where time and speed of my workflow is concerned). This would be a godsend for the GraphView toolset.

Please pass my feedback on to the GraphView teams. Thanks.

The nodes themselves should not _assume_ they are going to be used in a node-based context.


I can see the nodes themselves being used as (in-context) tools and utilities for entirely different tooling purposes, mostly related to UI and UX workflow improvements. Rather than simply a linear execution of node-based logic, which is the typical use-case of nodes, some nodes would be disconnected from the graph flow and act as "windows" to other toolsets / panels / EditorWindows / pop-ups -- that are more conveniently placed (in-context) with the game logic, allowing them to be accessed quickly -- in context -- with the logic that utilizes (or is acted upon by) the EditorWindow or inspector / pop-up / tool / UI-element one needs the Visual Script behavior for.

A good example of this in games might be to set/remove dataless tags and even the object itself (in-context with the script) to change the entire scope of the behavior or the entire scope of the script's execution while debugging its logic (and/or stress-testing the project's overall architectural approach).

In other words, instead of debugging the ONE object a script is attached to -- a user can change the object itself from within that script to a "testobject" that only has certain (limited) data and behaviors, letting one isolate problematic logic (and problematic approaches to program structure) and reprogram scripting architecture in moments (rather than in hours) -- identifying a huge benefit to Visual Scripting that standard text-based coding does not have -- since it cannot change its inflexible text-based UI (ans therefore its overall UX) without changing the entire language itself.


@LaurentGibert --

The above changes to GraphToolsFoundation are _extremely_ important for Visual Scripting to have a decent (and flexible) structure that allows easy OOP-like ECS behavior when implementing DOTS systems and architecture (flexibly) alongside Monobehavior architecture.

You signed up for overseeing this Monobehaviour/DOTS hybrid -- not me -- but believe me when I say this:

After years and years of research (on my own time) into the UI / UX of game development of all scales -- I am telling you that you need this kind of more flexible UI / UX approach in your underlying GraphToolsFoundation in order to provide users with the flexibility they _need_ to properly (and comfortably) define, scale, and maintain their projects' code architecture -- visually -- on projects of any scale and/or complexity -- that must later increase (or decrease) in scale / complexity -- because architectural changes are generally constant (as you are learning with Unity itself), so to define the needs early -- and to prepare for that kind of flexibility -- you are making people like @willgoldstone happy, while also making your userbase happy (and proud of you) as well.

Just my two-cents. Take it or leave it. But hopefully -- for everyone's sake -- you take it.

 

More Bugs:
1. Moving multiple nodes + an edge that is not connected to any of the nodes produces this result:


2. Reordering edges will produce an error about a layout update gone wrong. This sometimes also happens if you connect multiple inputs/outputs to one single execution port:


3. Setting the EdgeLabel of an IEdgeModel does not make the label show up.

4. Can't connect to portal even though the port type is of the right type:


5. EVERYTHING is serialized. Even my private variables such as "visited" which I use to keep track of which nodes have been processed. Only public variables and variables with the [SerializeField] attribute should be serialized. When that is not the case, you need clever workarounds for things that should happen automatically such as private variable reset. Currently I can get around this by resetting the variables in OnDefineNode().

 

Quick question: Version 0.9 of GTF was just released, but are there any estimates on when it will have support for 2021.X? Currently, only 2020.1 is supported.

 

What happens if it's opened in 2021.1?

 

You get a compilation error about a namespace that is inaccessible. It prevents you from entering play mode and using the graph tool altogether.

 

Whatever it is, the next step is probably the documentation and integration of this tool...

GTF will be used by all unity graphical tools. (VFX, ShaderGraph, Visual Script. Animation Rig...) I just hope that the next update will include the possibility to use the icons in the inputs / outputs as in the current Visual Script.

 

Works in 2020.3, but the documentation page is outdated, you don't need to add an override registry anymore.

 

Actually, it works in 2021.1.0f1 as well.




Found a few bugs:

1. If you drag and drop a blackboard item to an input port, you get the UE4 like behaviour of an automatic connector, but it instantiates two copies of the blackboard getter for some reason.
2. It results in a null reference exception if you connect an output port to another output port.
3. Can connect two ports on the same node.
4. If you drag out of an output port and use the newly instantiated searcher to attach the next node, it'll automatically connect that output port to the first whichever input port of the new node.

 

In our current project, we have 3 different graph based systems all running on the "old" Experimental.GraphView API.
Thinking of switching so I don't have to implement things like cut/copy&paste, Groups, SubGraphs and so on ... but one system runs on GameObjects instead of Assets:
- BehaviourTrees (Asset)
- DialogueTrees (Asset)
- LogicGraph (GameObject)

The LogicGraph is somewhat like Bolt, just there are very specific Nodes which have Save&Load (ingame) implemented. Every node is a monobehaviour (on a child gameObject of the GraphHolder GameObject).

I wonder if a setup like this would be possible with the Graph Tools Foundation (?)

 

Thanks for sharing. This is a vast improvement to GraphView and I'm looking forward to see this project evolve.

The examples are very useful but how do you run/execute a graph?

 

I am excited to be starting into GraphView. One thing that I noticed right off the bat is that everything, including nodes, seems to inherit from UIElements.VisualElement.

Are the model and view essentially married in this API? What if you wanted a nodegraph edited in GraphView, but then processed at runtime (and not rendered to a graphview)?

For example, in Archimatix, the runtime graph code leaves out the Editor rendering of the graph.

I know that UIElements is runtime as well, but it feels funny to have a data model inheriting from UI.

 

Correct me if I'm wrong but isn't GraphView API deprecated? Graph Tool Foundation is whole different beast.

 

Ah - good to know! Thanks, @PanthenEye!

 

Hi!

Any ideas on how to connect that to runtime?

 

Hi ! I might have found a (quite annoying) bug. In the sample project linked in the documentation https://docs.unity3d.com/Packages/com.unity.graphtools.foundation@0.11/manual/recipes-sample.html It is said that :


However I can't seem to make it work, since none of the following fields are displayed.


Is this broken in 0.11.2 ?

Thanks in advance

 

bump

 

How do you get this package? I can't seem to get it to work, when I follow the documentation to download it just gives me access denied.

 

You can put the name (com.unity.graphtools.foundation) in "Add by URL" and that should do it.

 

Ah thanks!

 

You need to create a new class which inherits FieldsInspector to display stuff on Node Inspector. Recipe sample has an example of this, so feel free to check that out. Although, I haven't been able to figure out how to not display node inspector at all, plus being able to define custom edge colors are a bit tricky, despite my CustomEdge.uss stylesheet and custom edge factory extension implementation, it only changes the hover state and clicked state's edge color.

Along with that, I was trying to spawn a custom window, like blackboard window does but after inheriting from GraphViewToolWindow class, it all seem fine. Until, I discovered that GraphViewStaticBridge is internal somehow and doesnt't let me have a copy of this function/call this one somehow.

Code (CSharp):

1.         public static void ShowGraphViewWindowWithTools<T>() where T : GraphViewEditorWindow
2.         {
3.             var windows = GraphViewStaticBridge.ShowGraphViewWindowWithTools(typeof(GraphViewBlackboardWindow), typeof(GraphViewMinimapWindow), typeof(T));
4.             var graphView = (windows[0] as T)?.GraphViews.FirstOrDefault();
5.             if (graphView != null)
6.             {
7.                 (windows[1] as GraphViewBlackboardWindow)?.SelectGraphViewFromWindow((windows[0] as T), graphView);
8.                 (windows[2] as GraphViewMinimapWindow)?.SelectGraphViewFromWindow((windows[0] as T), graphView);
9.             }
10.         }

 

No updates since July. I hear it's getting integrated into the core, so we probably have to wait until 2022.1 (maybe even 2022.2 ) at the earliest for any further development.

 

Is it possible to reuse this package in runtime? Let the player making graph like this for coding game

 

no, unless you somehow intercept seriliazation of the graph, or convert already serialized scriptable object into json (or something similar).
Thats one of the reasons why this package is bad, it does waaay too many things for you.

 

Has anyone seen anything related to subgraphs? My use case for a graph more or less needs subgraphs. From what I gathered, GTF does not have any subgraph support at all? But GraphView that Shader Graph is build on should have that I guess? But that API seems more or less undocumented. I'm I understanding the state of things right?

 

The point is if the library is not strictly require and rely on Unity Editor namespace, I might as well reuse the library as much as possible. At least for the UI and component structure

 

Has anyone figured out whats up with the UI PartList thing?

I am trying to rewrite the Dialogue Tree Editor to work with the new Graph Tools Foundation. I thought this would be easier. xD

Instead of just inserting VisualElements into existing Nodes, this is now handled by the so called "PartList" inside the "ModelUI". But I can't add a part between the left and right ports ..

Wanted:


Got instead:


Because the whole input-output-port thing is one part on it's own.
Is it possible to replace the UXML of a node completely? I've only found options to replace the USS so far ..

Why is this package so different to any other Unity-Tool? I need a specific class for everything.
Node Model, Node UI, Events sent between the UI and model as classes, a specific class to apply the UI to the model, .. why?

This attribute makes no sense

[GraphElementsExtensionMethodsCache(typeof(RecipeGraphView))]

.
All it does is to connect a UI for a node to a Model of a node.
In every other Unity-Tool, like custom Inspectors, the attribute isn't above a class that connects things, the attribute is would be over the specific UI.

So instead of

Code (CSharp):

1. [attribute]
2. static class ConnectStuff{
3.     static void ConnectAB(a){
4.       a.con = new B();
5.    }
6. }

it should be

Code (CSharp):

1. [attribute(typeof(A))]
2. class B{
3.     public override void BuildUI(VisualElement container){
4.       // ui code
5.    }
6. }

Then the event thing ... why should we write events for our stuff? Everywhere else in unity this is tracked automatically. Changing a value in the inspector -> automatic event. Moving a gameObject in the scene -> automatic event.

Here, we have to write those events for every value that can be changed? Why?

The Node inspector. Why do I have to write a class for the node inspector? Nodes are Unity-Objects or serializable at least, the inspector should be as automatically generated as usual. There is no difference between the GraphToolsFoundation Inspector and the default Inspector Window, it displays values from selected things. Here the selection is a node, usually the selection is a GameObject.

I mean, the Copy&Paste feature, placemat and so on are cool and I want to use it, but right now this seems like 10x more code than my previous solution which was basically hacking into the Shader Graph Code, more or less ..

Also why does the

GraphElementModel

require a

GraphAssetModel

instead of a

IGraphAssetModel

?
I wanted to make my own

IGraphAssetModel

which isn't an asset but a

MonoBehaviour

instead - seems impossible with this requirement as

GraphAssetModel

derives from

ScriptableObject

.

I am tempted to hack into this as well
- roll my own reflection based thing to assign the correct UI to my models with a custom attribute
- make a dead folder where scriptable objects are created for GraphModels, but all calls are delegates that are forwarded to my MonoBehaviours
- inject the UI using

VisualElement.Q()

- use only one dummy event for all variable changes and add a Undo Command automatically
- use reflection to automatically build a node inspector
- use

VisualElement.Q()

to remove the minimap and other buttons I don't need

But thinking about all this work, I might stick with the old solution and just add the groups, copy&paste features there.

This is still in Preview, I know, and what you are doing is cool - it just needs more automation to avoid all this boilerplate code.
I hope you keep improving it. ^^

 

@LaurentGibert can you provide us small update about the current state of package? I don't expect any official info, just roughly how it goes, is it still developed, maybe something changed meantime, is there any ETA?

 

Awesome! Happy to hear GTF will get some love. Do you estimate this new version will land on the 2022.x cycle or can we assume it's going to take more than a year?

We're a bit undecisive whether we should develop tools using GraphView or wait for GTF. If you could provide some insights on the current state of the package would help a lot!

 

So are you guys calling off any plans to continue updating the Graph Tools Foundation package publicly? As you can see in this thread, this is a highly anticipated and badly needed tool for developers who are invested in adding functionality to the Unity editor - it would be a shame to keep all this potential locked away. Not to speak of all the feedback and beta testing that would be made available to the internal team.

As to specific issues with the package, the main one for me is the absolute verbosity and boilerplate-filled-ness of it in its current publicly accessible state.

I am basing a new tool's code on the MathBook sample available with the package and I am past the dozen-file mark with no end in sight - I still haven't copied enough functionality to open my own graph editor!

Speaking of the samples, those seem to be the only reliable source of information on how to use the package. In the manual, the set up instructions don't work - I found out how to install it through Nexer8 themselves on another thread.

Also I'm not sure what this is about:




I am grateful for your work, and hopeful that perhaps I misunderstood the intention of taking this beloved package into the dark.

 

Since you said to send feedback your way, I shall do so real quick.
I was looking at using GTF for well... a graph tool. But decided not to for a couple of reasons.
Firstly because the package had not been updated for a while and I figured that it was moving to the core of Unity (I guessed right! )

Secondly, because it honestly felt like more work to use it then to make my own using GraphView, even if that isn't actually the case.
Part of the reason is because there is so, soooo much boilerplate to get even a basic graph. Another part, and almost more important is that its architecture and naming doesn't match that of the rest of the UI/editor stuff in Unity. It feels (from what I remember) a lot more like WPF or something similar.

Thirdly, from the brief look I had, it looked like the graph asset was editor only(?) which wouldn't work for me.

And fourthly, it lacks features like vertical nodes, and foldout properties/ports like the ports in VFX Graph.

I am sure some of these are no longer the case, but I can tell you that as the GFT is now, I genuinely don't know if I would use it for a graph tool apposed to making my own using GraphView. I mean, I would most likely, if only for compatibility and integration. But I hope that it illustrate my dislike for its current boilerplate, structure and overall approach.

I should also mention that I am really looking forward to GTF, and having it be a core part of Unity! I really like graph based tools (just in general, not even Unity specific), I think they are just cool and fun. I just want GTF to be really nice to use!

 

I would assume this is because as they said it will be a part of the core editor, and they are integrating it more tightly so having it as a package just isn't feasible. It also means (I think) they are more free to break the API since it is not public. This is just my thoughts though.

 

To sum up my previous post, regarding feedback to GTF:

• Too much boilerplate that's completely unnecessary
• Way different to other unity stuff
• Handling of the data structure should be optional - provide interfaces and a default way of saving things, using those interfaces, but don't force any data structure, because at the end, most (all?) of these graphs are just there to provide a nice view on complex data, such as dialogue trees ... some don't need data at all, I've seen debug tools that auto generate a graph temporarly just to show a specific problem in a structured way.
• The main feature we all want from these graphs is rendering, everything else should be optional. And what to render should be customizeable: the inspector, the minimap, the toolbars & buttons, the blackboard, even the search window provider,
  let us choose what features we want in our graph tool
• Nodes should be completely re-designable, like the whole UXML & USS classes. Some may just want to show a few connected dots on a screen, others want to display entire character inventories inside them, you will never know how your tool will be used

How to provide all this customization without a lot of boilerplate code or general complexity?
Overrides and Attributes.

The core unity editor itself is actually quite customizable, overriding inspectors, the hierarchy, there is an asset called Rainbow Folders, which changes the color of folders in the project window (so even that's possible somehow).
Some are attributes, some are delegates to subscribe to and for some you have to derive from specific classes (PropertyDrawer, Editor). When you need it, it's there and when you don't need it, those things are basically invisible.

 

The part of this package that stands out the most for me in verbosity is the commands - where you have to define a new class for every input field on a node.

I'm working on a GenericCommand class that maybe I'll be able to reuse:

[Code screenshot removed since I'll share the final code soon]

I'm surprised that the original author did not consider something of this sort. Maybe there is a reason for this that I won't be able to get around? Either way we shall see!

Update: I'm also working on a generic UI part for any kind of input field - just like the PropertyField of UI Toolkit.

 

Hello, I'm experimenting with MathBook example, I created simple graph with Addition, but I have no idea how to use created MathBook.asset. Maybe someone has some example how to execute such graph?

 

Hi! Can we expect GTF in the 2022.x cycle?

 

Hi!
I would like to know like PanthenEye if the package will be included in the 2022 cycle.

I also have a problem: when I click on "unknown" in the Type option of a CustomTypeHandle (or TypeHandle.Unknown) in the blackboard, the type list is empty in the searcher, is this normal, or I'm missing something?

 

This is such a cool hidden Unity gem!

I don't suppose you have an update as to when we may be able to expect these features to land in the "core product" — even just as preview/experimental features?
And on another note, has design philosophy changes happened to GTF, or has mostly migration occurred since GTF's last update?

 

Does anyone know how I could instantiate a node at graph creation time to serve as the output, similarly to shader graph?

This node would ideally be immovable and undeletable.

Edit: Going crazy here, trying everything, delving into the graphtools foundation source to find a way through, send water and nutrients

Edit 2: @Nexer8 cometh to the saving again by mentioning

PreProcessGraph

in the Stencil class earlier in this thread. I tried basically everywhere else and didn't notice this method, and apparently it is the only one that works. I was getting null exceptions everywhere else.