It’s an interesting situation. Seems like GTF is not really the successor of GraphView but rather its own thing. You use GV when you need fine-tuned, deep control, and GTF for the fastest iteration over a more concrete base. What is strange is that this is a completely new tool.
Why not create a high-level expansion over GV, similar to what NodeGraphProcessor has done? This would be a unified base that could be used for all purposes, instead of having two very different bases that target seemingly the same functionality.
Very interesting.
2 Likes
Even if deprecated, it still works. And it is at least feature complete.
Besides, aren’t some tools like ShaderGraph built on top of GraphView? No way they take GraphView down, while their tools still depend on it.
1 Like
It’s a clusterluck. 
GTF is the reason why I won’t put my money on GTK until I see it actually working on production on real tools.
1 Like
Great to see the ongoing discussion!
In my outside opinion it would be great to prioritize simple low level features that are powerful even if it requires a lot of work from the tool developer. And later focus on the higher level, convenience features.
E.g. if you provide a way to directly edit the UI elements in the graph or the inspector, people can create simple solutions for highlighting nodes (for runtime debugging) or add a button to the UI or whatever. Sure it’s not as convenient as a dedicated feature like various attributes supported for options or a specific highlighting feature but at least it’s possible.
For me at least it is currently hard to evaluate graph toolkit because so many things are locked down that I can’t get deeper into implementing a prototype for my use cases.
The things you put out so far seem quite polished and there are some high level quality of life features already made. This order of prioritization feels weird to me. I would love to see power over polish at least during experimental phase. Graph toolkit is made for tool developers not for end users, isn’t it?
Sorry if sounds too negative, I’m just really excited and feel held back.
Keep it up <3
3 Likes
I see pattern here: 1. Make a GUI, 4.replace it with 2. new CSS/XML ui and 3. make a retrofit/shim into GUI tools with CSS/XML 6. tools 7. to 5. make GUI 8. work 9. again. But unused terms and words could make package names more cumbersome.
Development needs more European software Guarantees, law regulations go some madness rampage..
Since this has been mentioned quite a few times now from Unity devs I have to give my 2 cents on this.
You built a total strawman and everybody sees through it.
GTK is experimental. What other stage would you make drastic API changes when not in experimental?
You have locked down so much, it’s actually harder to open up than to lock down. People don’t even know what they require. Nothing can be really built outside of very simple graphs so problems just arise very incrementally.
All I see here is artificial job security. You want to keep changes to your team and not outsource different implementations to other teams. I get it! It’s better to keep expertise in the GTK team than to have 3 different graph implementations in projects like ShaderGraph, VFXGraph or Animations.
But what makes a lot of sense for the internal Unity team makes absolutely 0 sense for a dev outside of Unity.
I hope you’ll realize this sooner than later because adoption rate will be terrible. Not sure if you care but Unity having yet another half-assed package is certainly not good optics.
Ah well, at least this prompted me to roll my own graph solution. I don’t think it’s rocket science and personally I’m not even sure why you struggle so much.
A cleaner/modern GraphView with the basics added like serialization, undo and model extension based on builder/factory pattern would have been probably enough for most devs to be happy.
6 Likes
You expressed all my thoughts flawlessly! Bravo!
+1!!!
Hi all,
We have created a separate thread for release announcements and notes here: Graph Toolkit Package: Release Announcements and Notes
Please watch that thread to get notifications for updates.
Thanks!
4 Likes
Cool to see that we already have a new update! Keep pushing, as soon as we reach the point of being able to add stuff to the graph via code + reuse same structure in runtime I think I will be able to do some PoC with my tools.
If GTK’s goal is to replace GraphView, then I believe it should cover all of GraphView’s features and capabilities. While it provides convenient high-level APIs, it should also expose powerful low-level APIs for full flexibility.
At this point, I honestly don’t know how to implement my needs using GTK. It offers a lot of conveniences for dataflow-oriented design, but what I need is a more capable execution flow system — for example, execution ports that also differentiate by type (i.e., event parameters).
Maybe I should try using the current data ports as execution ports instead?
1 Like
In addition, what I especially need is more intuitive loop connections for execution flow. In the context of dataflow, cycles are typically considered an error — but for execution flow, loops are absolutely necessary.
Currently, if I want to implement a loop, it seems I have to rely on portal nodes. While that works, it’s not very intuitive. Ideally, I’d like to see a visually clear, direct loop connection, as shown below.
6 Likes
Interestingly, it’s possible to somewhat reliably get VisualElement-to-INode as graph.GetNodes() contains nodes in exactly the same order as they were drawn.
So custom node elements, highlights, etc are already possible, albeit in a hacky way.
4 Likes
I’d use teleports for now
I’m sorry… but… this makes very little sense to me. I mostly agree with @Enzi here:
But… I’ll explain why in the (historically moot) hopes that a detailed explanation might gain some traction internal to your team:
- Low adoption — Two weeks after release and I already know multiple people that have evaluated and decided “Nope, can’t use this for what I want. I’m just writing my own cause its not that hard to write one for my singular use-case”. Out of those, how many do you think will come to the forum and tell you that? The expectation of “please come here and tell me why you’re not using my product” is a… let’s call it “naive” take and, on average, people are just not going to do that cause their time is valuable to them; even though, asking for this does make it seem like its not valuable to you.
- Low-value feedback — Because of the first item in this list, the feedback that does come in ends up being more likely to NOT challenge your assumptions because it was constrained by your artificial limitations. Not to dismiss this sort of narrow feedback (there’s obvious value in it), but its NOT what you should be looking at in an experimental stage. This is because the feedback you do end-up getting will have survivorship bias written all over it and will cost you in the medium-to-long term (only people that are both using it AND care enough about it to come tell you pass the filter).
- Slowness of Development — Simply put: you did a ton of extra work to wrap your code in layers of private/internal encapsulated functionality. You could’ve just NOT done that work. Experimentation-friendly people would figure out interesting ways to interact with that to achieve what they want, therefore providing you with the context necessary to build actually good APIs. And, it would likely be much faster than the unreasonable amount of time this package took to reach this state.
- Reduced Utility in Final System — Because of all the above, you can expect that the system will be used for LESS things because you put in MORE work. This is already bad for Unity’s business since you’re doing unnecessary work, bad for you because your awesome system is used by less people but.. at the end of the day, this is also bad for users (even if the way they used it would eventually become deprecated in Unity 7000/8000 or whatever and they’d have to change their approach at that point); if it works now, if they’ve evaluated it now and if they need it now, why can’t they choose to use it now? You should be trusting your users to decide if they want to take the risk of using an unsupported or experimental system or not. Diminished utility aside, I personally find this sort of “protecting users from themselves” thing is pretty condescending and also counter-productive to your product.
I recognize that managing user expectations is part of the job — it’s part of my day job too (Lead Engineer of a GBaaS SDK) and I’m not saying you’re doing anything bad by trying to keep people aware that the system is still evolving and so on… I do think, though, that…
… you guys might be too worried about breaking changes in the course of improving the software hahahaha. If you make the product demonstrably better and more flexible, people WILL pay the cost of upgrading because its in their best interest to do so. Yes, they will complain about it because the timing might suck for them a bit (which in most cases is a solvable problem on their end and most people are willing to solve it) — but ultimately, they will move to it when they see or need the value. It is your job to provide and demonstrate enough value for them to want to move to it and its actually harder to do that when you’re keeping everything locked down (increased cost of evaluation of GTK for what they want to do with it OR locks them out of using the system because they don’t have a path to making it useful by themselves).
In short (or actually, “in long” hahaha), I think this is a major problem with Unity’s position on breaking changes. You can’t make your product better if you’re afraid to make the product better. Also, API backward compatibility is NOT nearly as important as keeping feature support and dev-effort-profiles similar (thing that were possible should remain possible or have alternative paths of similar-ish cost to doing — which is not the case when comparing this with GraphView, for example, a common pain point throughout this thread).
The API is not the problem (in fact, it’s the least important part at this stage); right now, the system semantics are what’s important. Focusing on API nonsense like “making it a builder pattern or whatever” in the experimental stage signals to me that you guys might be thinking about the wrong problems and that this system is unlikely to evolve in a good direction.
You can write 30 different API flavors on top of an underlying system… but, if you don’t get the system semantics right, all 30 will fall short of a lot of people’s needs. By system semantics I mean: data structures and range of acceptable values for them, algorithms for defined operations within the system (from serialization to graph-traversal utilities to many others), extension points and escape hatches for user code modifications (how do I change the visual of nodes, properties, how do I build my own node-traversal or extend whatever utilities you provide for that, etc…). Btw, API flavors are useful, just not really that important at early stages; at this stage, simple functions and data structures would go a lot further in helping you shape the package’s direction.
And, as much as I don’t like saying this, because I’d like to think its NOT actually true… this does end up looking like a “job-security” position more than a “let’s make the best product possible” position. So I’d advise against arguing things like “people complain when we do breaking changes in APIs” in the forum in the future. Its just not a realistic argument for you releasing a system that has so many training wheels on it that the system can’t be used for a lot of real and advanced use cases.
Anyway… sorry for the rant forum-folk but this is a large pet-peeve of mine and to hear it out loud borders on comedy so I figured I’d leave some harsh-but-constructive feedback here.
22 Likes
I’m really happy to see this news and started using the package right away. But without an official API, it’s very hard to use since I have to set up every node by hand. I’m trying to build a temporary interface using reflection, but I really hope an official API can be added soon.
I really need ability to create nodes via code ASAP just for visualizing flow of SOs
Without it i cant event start testing
2 Likes
We have been waiting for this for a long time ! Thanks for making it available even in its experimental form. I’ve started playing with it on my spare time. I’ll try to take note of everything I find so far.
I know you guys wanted to know what your users will do with it. There’s at least 2 scenarios for which we needed it :
-
Loot tables : our loot tables rules are quite complex and authoring the data with the inspector, even with Odin was a bit limiting because the underlying structure we wanted was a tree and there was no elegant way to make it easily “authorable” for the designers. This is currently the use case I wanted to use as a proof of concept for GTK.
-
Our damage formulas were also authored using a node graph editor (xNode). This is also quite a common concept that would benefit us, in the long term, if we could use the GTK to fulfill the job of authoring the data.
Thanks again, and I’m eager to see what the future hold for that piece of tech.
2 Likes
Ah yes, another use case I’d like to explore that you may or may not saw it coming was to be able to author data that could be taken as input for the Roslyn code generator. I’ve mentioned above that our damage formulas for our damage system were authored using a node graph editor. While the runtime execution of that code did not turn up to be that bad it could have been used to generate C# code.
To achieve this with the current implementation of the GTK, I would probably need a ScriptedImported to generate an asset (being some kind of script, real C# code, or plain text) that could then be feed to Roslyn.
If this is not the correct way of doing this, or if you think there is an easier way, I’d be all ears.
Again, this is not something we need in a near future, but something a bit more long term.
1 Like
I believe the best package to provide this functionality is visual scripting. It needs to offer some way for us to write functions using nodes that can be called from C#. I think this alone would cover the vast majority of use cases that require a custom node graph editor.
1 Like
It must be as much as needed, not “try to keep these to a minimum”. What’s the point in constraining yourself and your customers that are willing to extend it from day one? Breaking changes are welcomed in Experimental phase, it’s not like someone is going to develop a graph tool for Production project using it.
We’ve had such productive discussions in the past - with “DOTS Visual Scripting Experimental Drop” threads, and at that time, Unity was very open about changing things.
And holy moly, it’s already been 6 long years. Too much tech debt piled up, huh?
If you guys don’t open up the API - third party assets will come out that will allow such functionality, but in very hacky ways, each being different, thus dividing the community, which defeats the whole purpose of GTK.
Feels like we’re saying basic common sense things, but it looks like most teams at Unity are pressured with keeping breaking changes to minimum, after years of ECS flop that was constantly changing in all aspects.
4 Likes