Official The road to 2021: Visual scripting in Unity

how to create switch case in unity visual scripting

 

Use one of the Switch nodes like Switch on Int or Switch on Enum.

Also, don't seek help in threads not meant for that. You can create a new post with your issue.

 

Now that we are on 2021.3.0f1 and much of the GUI items are now legacy. I notice that you have to load TMP and then for visual scripting you have to load it again. Even after this you have no way (that I can find) to access things like TMP drop down menu events. Seems odd that if TMP is the new great thing (and it is cool) and you want to push visual scripting (which I find useful) that these 2 items would not have been better implemented to work together. As I understand it there is no way for Visual Scripting to access the new UI toolset all in all I am kind of sad.

 

Anything major can we expect in visual scripting for 2022?? Version 1.8 seems to be missing from 2022 versions?? When it will be ready??

 

Latest word from one of the devs as of today is to not expect any 1.8 builds anytime soon. And apparently 1.8 preview with high performance interpreter has been officially pulled from public access. No clarification on why, though. But it seems internally things have changed for some reason.

Perhaps they're refocusing on Graph Tools Foundation migration for Unity 2022.2 or Unity 2023. They had a week long GTF training a couple weeks back for the UVS team.

EDIT: Comment from Unity developer on the topic: https://forum.unity.com/threads/high-performance-interpreter.1282751/#post-8134475

 

They said they were gonna go with a different approach to ride performance issues because generating code has problems

 

Please make sure to spam the heck out of it when there's an early copy of the Graph Tools ready for preview or whatever.

Is there a current test build somewheres to try out I wonder

 

There are any news on the current state of UVs development? The discord server seems completely abandoned by unity devs.

 

I'd like to know as well. Current implementation is a liability due to IL2CPP issues and the last update was released some 8-9 months ago. Are there any fixes coming to the current version to address IL2CPP compatibility?

And roughly when can we expect the next UVS to drop? Is it months or is it years? Currently, it's unclear if UVS 1.7x will ever address IL2CPP issues and if my own efforts will be wasted or not because there are no timelines given for anything and official roadmap is a year or two out of date.

 

I would see it as a double-edged sword.
On the one edge, you'd have needing to learn a new thing and the time that takes
And on the other, you have the possibility of new and better ways to do things and a new toy to play with.

all good either way. I just want to see it done right and not like how bolt was taken over with little documentation.
that was rough lol

 

Should add that people developing Community tools stop when told that their tools would be implemented officially, then we got silence for mostly a year now.
As someone that really was involved with bolt 1 n 2 development, seeing this course of action is a great deception.

Unity should by the least minimum have some consideration with Bolt community.

 

Well, thanks for helping to create this anyways.
couldn't imagine having fun like I do without it..
thanks everyone who worked on it ^.^

I feel like it was maybe bought out so folks would use more paid assets instead of being able to make it for themselves.
but that would be super shady and probably just my tinfoil hat starting to leech into my brain. lol

hard to believe they'd let it chill on the back-burner for no reason.
considering how it lowers the bar for entry.

maybe they're worried about low quality games who knows

 

It's just poor management. They've had several internal Mono implementations, one they showed off shortly before it was cancelled because they swapped focus to DOTS VS which again was cancelled because who in their right mind build tools for unfinished, unproven tech?

Then they backtracked back to Mono and acquired Bolt for the Visual Scripting checkmark. Worked on Bolt 2 for several months, couldn't finish it in time for Unity 2021.1 and found out it doesn't really align with their goals for Visual Scripting, which were never clearly defined before Bolt 2 cancellation.

Then they integrated Bolt 1 into the core of the engine, then found out about many of its problems after it was already integrated, never really improved it and now it's again abandoned and so we wait for UVS Next which might finally offer proper Visual Scripting in Unity.

When though? Who knows... It's likely many more years of waiting since UVS Next requires the Graph Tools Foundation framework. GTF package has been cancelled as well and they're now intending to ship it with the engine. As far as I can tell, it's not part of Unity 2023.1 alpha. So maybe Unity 2023.2, Unity 2024.1 or even Unity 2025 since they're migrating all Unity graph based tools - Animator, Shadergraph, VFX graph, UVS, etc - to Graph Tools Foundation. Migrating all these tools is no small task, and the process was started recently, so I assume the wait time is years rather than months.

GTF will include a lot of UX features of Community Addons, but Bolt is dead, and it seems like UVS 1.7 is also abandoned.

 

Yes, that poor management resulted in a tool "Bolt 2" that would take one or two years to be ready on being cancelled, a tool that tightly meted its user base needs and expectations, in exchange for what? Years of waiting for who knows what. I keep asking myself if it would be a good thing, releasing bolt 2 source code, so the community or other tool devs could finish its vision, which is by far, what we as in "bolt community" really wanted for a VS tool.

 

I dream of reverse engineering Bolt 2 and writing my own spiritual successor to it; I have source from Ludiq alphas. But it'd take years. My engineering acumen is not up to par. I've never made a tool on that scale, I code gameplay mainly in my day to day. It'd take roughly the same time Unity needs to release their next incarnation of Visual Scripting so the payoff would likely be limited assuming I can even pull it off.

 

Maybe as a collaborative project, living on donations, like blender, or mirror networking, with paid support or something,.. nonetheless, It would need a few really engaged devs, maybe we're able to gather such folks.

I´m myself not a much experienced programmer, my background is more art leaned, but improving on tool dev is on my roadmap and I can say I share the same dream on developing such vs ide vision.

 

I would like to point out how Blender exsists while tools like Poly Build could, in theory, be used to build games. A standalone visual scripting could work, something that converts nodes to code. but you'd still have to import it into Unity and hook it up to everything. How VS is built-into unity and not a separate asset package is a very important thing. let's you grab stuff from the game you're actually building at the time. rather than sort of visualize it beforehand like some sort of wizard.

I'm not a Wizard unfortunately. Too tall for the requirement.
Anyhoo, I literally would not use unity if VS was not a thing as it is. Big loss, right? But others like me would feel the same way I imagine. And it does actually help learn or teach code theory. or think about it from a new perspective.

All of my projects are done with 100% VS. No Script that's not part of some package and there's not much you can't do. Now. I'm just killing time for fun and progressing the EXP bar with game craft.. so I'm not aiming to release anything.

I think it would be foolish to even try unless you at least had a guy on the payroll who could write code required if needed bare minimum. Not into those scam type qickie games that run on copy paste code. So it kinda works for me.

Could just be a numbers thing too you know.
Like sitting in a boardroom going "ok, polls and metadata show that only 30% of our paid userbase uses this feature. because of that only devote 10 seconds of time per year" kind of deal.

im just glad Unity is free
that's dope

Member that MacromediaMX?
THAT was a rip lol

 

I'm not sure it would be similarly successful. Blender became a thing because it offered a free viable alternative to other 3D software that was out of reach for most due to the cost of entry. And most 3D software is still expensive today, even if it is more accessible, so Blender beats other software in price by default.

And Mirror networking offered a solution for something Unity didn't have natively until recently. I doubt it was/is commercially viable on its own either, although I don't know much about Mirror and how it came to be.

A paid or even free 3rd party VS solution won't be able to compete with the next major version of UVS. Not in price, not in engine integration and probably not even in functionality either. A free official solution that's also functionally viable will outcompete anything 3rd party by default.

And current graph based tools can only be made in IMGUI, which will always have editor performance issues, or GraphView API, which is very limited by design and as good as deprecated. They're making UVS Next in UI Toolkit based Graph Tools Foundation framework, which will be superior to tools available to us right now both in editor performance and usability.

They're also intending to deeply integrate all Unity's graph based tools to work hand in hand with the same UI/UX so Animator, Shader Graph, VFX Graph and UVS will share the same UI paradigms. Anything 3rd party will feel bolted on until we get Graph Tools Foundation as public API so we can code our own graph based tools, but they've mentioned in recent Q&A that public API is not their priority.

Perhaps if/when GTF receives public API, it would be viable to do a Bolt 2 successor of sorts, so it has the same feel and workflows of other Unity's graph based tools and doesn't lag behind in editor performance.

 

random question:
what actually causes the "performance issues" in the editor?

I'm thinking about it and realized there's nothing to compare it to really. As in when you type script out you need to compile and save it right? that's not done inside unity, it uses whatever your default thing to right? And Visual Strudio (confusing name in this context) can be obtained when installing the Unity core package right?

Is the issue related to the number of nodes active on a graph and, Unity also has to render the other editor viewports and continually updated shading? Or is the On Gui Update just slower because it was meant to be used to draw debug spheres and lines and stuff?

Seems like maybe if you nest a bunch of subgraphs, that seems to take longer?

With most Didital Modular Synths (for music) each time you plug somthin' in, it introduces a delay of some given number. so you can in theory calculate the offset and just correct it before it plays out the speakers for example. I would assume that each node, or maybe connection could introduce some kind of lag or latency.

I don't have an issue with any kind of preservable lag or anything.
Can't notice any kind of performance issue on my end.
Unless im doin' semithin whack like have 100 render textures spawn in dynamically.

Although I try to make things active or be running only when it's needed. and do stuff like object pools and that.
It helps just to get things actually moving on the screen to see the result of the changes you make as you do it.

like fixing an inverted Mouse Axis for example, can be done while the game is running. no need to compile and save.
that's got to count for some kind of preformance/time points right?

 

Current Graph editor window and the embedded custom inspectors are implemented in IMGUI, which redraws the whole thing every frame and scales poorly. They've hacked it somehow on the C++ engine side to redraw fewer times than every frame as a bandaid optimization for UVS graph editor, but the issue remains. Depending on your PC, graphs at certain scale become near unusable - navigating them, moving nodes around, even adding new nodes becomes slow up to the point you're basically navigating a slide show. This is especially an issue with larger state machines.

Then if you enter Play mode with Graph editor window open and displaying a large graph or state machine, the Play mode fps tanks to the point the game can become unplayable in the editor unless the Graph editor window is closed completely at which point you can't debug anymore.

Long story short, IMGUI is the source of editor performance issues, which is one of the reasons why they're migrating the tool to UI Toolkit based Graph Tools Foundation framework.

 

ah figured somthin like that. but really that could also be related to Syntax or how the actual nodes are placed

I found the optimum solution is to use subgraphs combined with state machines in such a Fason that most of the code i need to be looking at fits on one 100% zoomed in screen. (mind you my monitor is a 60 inch displlay so screen space is not super bad.

Still, you can't scale or zoom out the graphs beyond a point (like 20% zoomage) , because it simply makes the numbers disappear and can't see anything. I do utilize that Overview button a lot instead of manually navigating around. It's like pressing F to center the object in the viewport.

My point is, any slowness, can be sort of fixed or worked around by changing the layout of everything.

I never have more then a single graph open. but it's running on the second monitor to do live editing of sensitivity values and clamps and all that. And always nest everything almost as if it was meant to be shared or used by a new person.

When I dip into a complex function, that always gets nested in a subgraph within a subgraph. subgraph-seption eh?

that does take time to layout and is NOT the same as script when you normally jam everything onto a single object manager item and reference them remotely.

how VS seems to be set up, or what it feels like to me that should be intuitive, it feels more comfortable to work a certain way simply because of the actual shape and i/o of the nodes you want.

for example, folks like to use Wait alot with code,
but with Visual Scripting it is more fun to use the Timer plug things into the outputs.

I just wonder if i don't experience this issue because of how i do stuff or if my PC is just BOSS

I assume nested subgraphs are culled from the render right

 

Subgraphs don't help. A state machine is basically a collection of subgraphs and performance still goes to S*** for any sizeable state machine on the top level where you don't really see any low-level nodes. It's not really a question of how much is visible on screen, rather it's a question of how big the graph is in its entirety, including the contents of nested subgraphs. Subgraphs also add extra complexity for the CPU to resolve. It's an extra step that impacts build performance, maybe to a minor degree, but if everything's a subgraph, it adds up.

There is nothing that can be done about that beyond keeping graphs and FSMs small or swapping the technology which Unity are in the process of.