Graph Tool Foundation

It seems as of 2023.1.0b16, the API has changed and this project no longer works out of the box - specifically the following lines in ComboAsset.cs:

Code (CSharp):

1. GraphAssetCreationHelpers.CreateInProjectWindow<ComboAsset>(template, null, path);

This fails because CreateInProjectWindow has reordered its parameters, the fix is simply moving `path` to the second parameter.

Code (CSharp):

1. window.SetCurrentSelection(graphAssetModel, GraphViewEditorWindow.OpenMode.OpenAndFocus);

is more complicated - SetCurrentSelection and GraphViewEditorWindow.OpenMode both no longer exist, and it's not clear what the equivalent replacement functionality is.

 

//var window = GraphViewEditorWindow.FindOrCreateGraphWindow<ComboWindow>();
var window = GraphViewEditorWindow.ShowGraphInExistingOrNewWindow<ComboWindow>(graphAssetModel);

 

This project is too poorly engineered. GraphTools Foundation should honestly be archived and written down as a path not worth following.

Honestly if anything it is over engineered. Nothing is simple or straightforward, the documentation does not even begin to encompass its inner workings.

I am moving my own tools to the browser, UIs in Unity are too much of a nightmare. I will try to constrain my reach to within the inspector pane as much as possible.

 

The package hasn't been updated in like two years. All progress is internal only. It might look wholly different now, no one knows.

 

It would have been very hard to change some aspects of the package without an almost blank slate restart. I don't think the person who designed it should be in charge of designing any sort of API at this point, though I'm sadly not surprised Unity as a corporation let that happen.

To show where I am coming from, this is a fork of GraphTools Foundation I made in 2022 where I took it upon myself to make the package minimally usable, including being able to compile it into a game build: https://github.com/marcospgp/com.unity.graphtools.foundation/tree/master

This shows the changes I had to make: https://github.com/needle-mirror/co...cospgp:com.unity.graphtools.foundation:master

I haven't been that stressed since I gave up on the package. That code is seriously traumatizing.

 

They changed something? I tried with the lastest beta of 2023.2 and i got a lot of errors (misses classes)

 

Can't really disagree with them liking to overengineer new systems in Unity. Seems like a side effect of people coming in from AAA where they worked on proprietary technology with poor UX or unrelated industries with similar practices. The easy to pick up and go nature of Unity is slowly disappearing. That more than anything is making me question my future with this engine as a developer in teams of 5 or less.

 

So... what now?

Do we just stick with something like Graph View and implement everything on our own? I did try to look at APIs that abstract Graph View but even then they're in the same state as GTF (not updated in 2 years).

 

I'm building a node graph UI on the browser, using Blazor web assembly. This means I can write in C# and share code between my web and Unity codebases.

In my experience Unity editor UI is not dependable, so for anything that the inspector view is not sufficient for I'd rather move my UI externally and then provide an export to Unity option.

This has the upside that other export formats can be added, and there is no lock-in to Unity.

 

There are good news about Graph Tools Foundation!
Several commits related to GTF could be seen in the 2023.1 / 2023.2 branches of Unity's main repository, including adding the entire new module of GTF into Unity Editor itself. Though they're still in internal level (which means "under implementation" I think), you can already access them in 2023.1 Editor by reflection, or use some asmdef hacks.
I expect that in a not-so-far future, we can use GTF already without any package installing.

Here's the latest GTF module scripts:
https://github.com/Unity-Technologies/UnityCsReference/tree/master/Modules/GraphToolsFoundation

 

Is there a way to start building on top of these internal APIs now? I'm happy to hack it, but I don't see how to use asmref's to extend these modules, since they're not Packages anymore.

And reflection doesn't allow you to extend from internal classes, as far as I'm aware.

 

Hah, the GraphToolsFoundation assembly already exposes several InternalsVisibleTo attributes, so you can use the internal methods, as long as you name your Assembly Definition correctly. For instance, an asmdef called "UnityEngine" allows internal access.

I have no clue if this will work properly in all cases, but it seems to compile, and strikes me as safe.

Here's the full list of names you could use:

Code (CSharp):

1. [assembly: InternalsVisibleTo("Unity.DigitalTwins.HMI.Tests")]
2. [assembly: InternalsVisibleTo("Unity.DigitalTwins.DataBinding.Tests.Editor")]
3. [assembly: InternalsVisibleTo("Unity.DigitalTwins.DataBuilder.Editor")]
4. [assembly: InternalsVisibleTo("Unity.DigitalTwins.HMI")]
5. [assembly: InternalsVisibleTo("Unity.ShaderGraph.Editor.Tests")]
6. [assembly: InternalsVisibleTo("Unity.DigitalTwins.HMI.Editor")]
7. [assembly: InternalsVisibleTo("Unity.DigitalTwins.HMI.DataBinding.Editor")]
8. [assembly: InternalsVisibleTo("Unity.DigitalTwins.HMI.Workflow")]
9. [assembly: InternalsVisibleTo("Unity.ShaderGraph.GraphUI.Tests")]
10. [assembly: InternalsVisibleTo("Unity.ShaderGraph.Application")]
11. [assembly: InternalsVisibleTo("Unity.ShaderGraph.Editor")]
12. [assembly: InternalsVisibleTo("Unity.ShaderGraph.GraphUI")]
13. [assembly: InternalsVisibleTo("Unity.DigitalTwins.HMI.Tests.Editor")]
14. [assembly: InternalsVisibleTo("Unity.CodelessFoundation.Editor.Tests")]
15. [assembly: InternalsVisibleTo("Unity.DigitalTwins.DataBinding.Tests")]
16. [assembly: InternalsVisibleTo("Unity.CodelessFoundation.Editor")]
17. [assembly: InternalsVisibleTo("Unity.CodelessFoundation")]
18. [assembly: InternalsVisibleTo("Unity.DigitalTwins.HMI.SystemConfigurationGraph")]
19. [assembly: InternalsVisibleTo("Unity.VisualScripting.Shared")]
20. [assembly: InternalsVisibleTo("Unity.VisualScripting.Editor.Tests")]
21. [assembly: InternalsVisibleTo("UnityEditor.Importer")]
22. [assembly: InternalsVisibleTo("Unity.XWave")]
23. [assembly: InternalsVisibleTo("Unity.VisualScripting.Editor")]
24. [assembly: InternalsVisibleTo("Unity.VisualScripting.Tests")]
25. [assembly: InternalsVisibleTo("Unity.XWave.Tests")]
26. [assembly: InternalsVisibleTo("Unity.XWave.Editor")]
27. [assembly: InternalsVisibleTo("Unity.XWave.Editor.Tests")]
28. [assembly: InternalsVisibleTo("Unity.SignalLab")]
29. [assembly: InternalsVisibleTo("Unity.SignalLab.Tests")]
30. [assembly: InternalsVisibleTo("Unity.CodelessFoundation.Tests")]
31. [assembly: InternalsVisibleTo("Unity.DigitalTwins.DataBinding.Workflow")]
32. [assembly: InternalsVisibleTo("Unity.DigitalTwins.DataBinding.Graph")]
33. [assembly: InternalsVisibleTo("Unity.DigitalTwins.DataBinding.Editor")]
34. [assembly: InternalsVisibleTo("Unity.ShaderGraph.Application.Tests")]
35. [assembly: InternalsVisibleTo("UnityEngine")]
36. [assembly: InternalsVisibleTo("UnityEditor")]
37. [assembly: InternalsVisibleTo("Unity.GraphTools.Foundation.Testing.Editor")]
38. [assembly: InternalsVisibleTo("Unity.GraphTools.Foundation.Editor.Tests")]
39. [assembly: InternalsVisibleTo("Unity.ItemLibrary.Editor.Tests")]
40. [assembly: InternalsVisibleTo("Unity.GraphTools.Foundation.Editor.Tests.Performance")]
41. [assembly: InternalsVisibleTo("Unity.ItemLibrary.Editor.Samples")]
42. [assembly: InternalsVisibleTo("BlackboardSample")]
43. [assembly: InternalsVisibleTo("ContextSample")]
44. [assembly: InternalsVisibleTo("ImportedGraphEditor")]
45. [assembly: InternalsVisibleTo("RecipesEditor")]
46. [assembly: InternalsVisibleTo("SimpleMathBook")]
47. [assembly: InternalsVisibleTo("VerticalFlow")]
48. [assembly: InternalsVisibleTo("TestSample")]
49. [assembly: InternalsVisibleTo("SharedSample")]
50. [assembly: InternalsVisibleTo("Unity.Animation.StateMachine.Tests")]
51. [assembly: InternalsVisibleTo("Unity.Animation.Hybrid")]
52. [assembly: InternalsVisibleTo("Unity.Animation.Hybrid.Tests")]
53. [assembly: InternalsVisibleTo("Unity.Animation.GameObjectBridge.Tests")]
54. [assembly: InternalsVisibleTo("Unity.Animation.Editor")]
55. [assembly: InternalsVisibleTo("Unity.Animation.Editor.Tests")]
56. [assembly: InternalsVisibleTo("Unity.DigitalTwins.DataBinding")]
57. [assembly: InternalsVisibleTo("Unity.SignalLab.Editor")]
58. [assembly: InternalsVisibleTo("Unity.VisualScripting")]
59. [assembly: InternalsVisibleTo("Unity.SignalLab.Editor.Tests")]

 

This is the biggest problem with many modules in Unity! Many necessary APIs are internal, and Unity itself extensively uses InternalsVisibleToAttribute when using these modules, so they are unaware of the issues that not exposing these APIs can cause for users. As users, the only way for us to access these internal APIs is by modifying the Unity source code.

While it is possible to access these internal APIs by placing our own code in a specific named assembly, but in a solution there cannot be multiple assemblies with the same name. This approach means that you would occupy the position of the assembly that actually uses that name, and it is also inconvenient for use as an open-source repository.

This problem is particularly evident in UIToolkit. Without modifying the Unity source code or using reflection, we can only assemble new UI components using the built-in UI components, and we cannot achieve the ability to create custom UI components with entirely new features by inheriting from the underlying UI components.

 

Yeah, I would *love* an official way to depend on internal APIs. As an engineer making a game, not a library, a little bit of breakage here and there is perfectly fine. 99% of the time internal APIs don't break -- we shipped our last game on top of quite a few of them. It'd nice to not need the hacks.

There should be a project setting (hidden deep that's hard to find). That way:
- Application developers can enable it based on their risk tolerance.
- Library developers would still be locked to public APIs.

 

I've remade the recipes sample for the Graph Tools Foundation in Unity 2023.3.0a5. Enjoy!

chikacc/RecipesSample (github.com)

 

On the whole, what's the major improvements for Graph Tools Foundation over the older GraphView?

As someone writing a visual scripting language in GraphView, is there a big reason to upgrade?

 

How did you get around the protection levels with this? I was able to import it into my project but once I started renaming the classes and scripts I can no longer access the sealed classes. I have the exact same formatting as yours as well :/

 

Somewhere up this thread it was mentioned that at some point in the future, GraphView will be deprecated. But that point might be years from now.

 

Please ensure that the name of the assembly definition is specified as the assembly for InternalsVisibleTo. For a list of usable assembly names, refer to Unity’s official GitHub repository at UnityCsReference/Modules/GraphToolsFoundationEditor/AssemblyInfo.cs at master · Unity-Technologies/UnityCsReference (github.com).