Correct, creators choose whether they’d like to choose Soba, Udon Graph, or UdonSharp. I think of Soba as a successor to Udon / UdonSharp - I think that’ll be easier to understand once we share some code examples!
1 Like
This concerns me. I thought you guys planned to use ready solutions (Roslyn+Blazor+WebAssembly) which embeds full-featured performant and well-sandboxed language implementation, but it looks like you have to build new partial bicycle once again. If so, development cycle will take few more years 
10 Likes
Is Soba still going to be using WASM, or are we junking that now? It looked like progress was good in previous developer updates.
If it’s being junked I’ll be a little sad, but if the plan is to run the WASM-based VM side by side with standard Udon, it’ll be great for computationally expensive systems which up to now have only been feasible to amortize and offload to the GPU.
7 Likes
Wait so will new features be added to both systems in the future?
Or will original Udon just revive bug fixes etc once Soba is out?
1 Like
From what I’ve been told the WASM approach was thrown out the window and Soba is something completely different on the back
I assume they will hold works on Udon1 language/compiler/VM features, but will continue exposing APIs, including new ones, into both implementations.
btw from prev dev update:
Why? Any changes there? Why it’s a problem to expose PhysBones and new Constraints to the worlds?
6 Likes
Is there any focus on performance for Soba? A big promise for Udon 2 was better performance. And worlds only continue to get more complex.
Newer, more complex game worlds continue to run worse than ever. I would hope that Soba would try to solve this. And let creators build bigger things
8 Likes
Will we be able to see something like this for Soba any time soon?
4 Likes
whats even the point of soba if it does not really improve much on anything? Even current Udon fork was just released with generics support. Thats not the Udon 2 we were hearing about, that just Udon 1.1 or something.
Just how behind vrchat must always be on everything, and always choose most lazy and limiting approach, just sad…
6 Likes
If I could offer an alternative: Tagging.
Folders honestly are so outdated at this point as a sorting method. It’d be nicer to tag items, since an item can have multiple tags (folders).
I have some thoughts about this but it’s probably best to not say it here. But I’m sure everyone else is thinking the same thing.
And you’re right. The lack of WASM being mentioned is concerning. That was the pinnacle of the new system.
If this is what we think it is, then I’m not happy. Udon 2 was supposed to be a game changer, and this new messaging tells me otherwise.
How much will be different from U# to Soba? Will there be fundemental changes with stuff like networking or the VRChat world api, or will the actual logic required be largely unaffected?
I’m asking because I’m currently in the proccess of rewriting large parts of my world’s code and I’m wondering if I should maybe wait a bit before continueing with that
That was the original name that I had for it before working at VRC actually.
4 Likes
Interacting with VRChat’s networking or our worlds API is mostly the same!
We are uncovering small improvements now and then, such as VRChat components that should or shouldn’t be exposed. But for the most part, Soba should feel very familiar if you’ve used UdonSharp before.
Yes! Soba contains performance enhancements that should make it run faster than Udon.
Soba contains lots of improvements! We’re looking forward to letting you try them during the Soba Closed Beta.
2 Likes
Real annoying that VRC will not actually tell the community why it introduced this big regression in functionality other than being super vague. What happened to being open? Are you afraid of being refuted by me or the community?
23 Likes
Any improvements compared to the previously announced Udon2?
2 Likes
Nice to see “Udon2” or i guess Soba now, is still being worked on a fair bit.
Naming scheme is a little hmm… I mean, i can see it maybe catching on, but Udon actually sorta sticks sounding like a code-like platform somehow, like even from when it came out, even having a long familiarity with udon, using it for the development engine sorta worked mentally for some reason. I wonder if Soba will end up sounding like that for people?
I have similar concerns with others here; i was waiting entirely on Udon2 to start doing world dev, exclusively because of the transformative platform that would strip away a lot of the processing steps and allow it to run much more straight forward and gain immense performance improvements.
The entire reason i’d been avoiding getting into world dev, is because i’m not convinced i can achieve the things i want to whilst maintaining very high framerates (80+ with many non-intensive avatars) without CPU bottlenecking.
. . .
I have a lot of tricks up my sleeve for significantly reducing CPU and GPU time for engine rendering stuff (cluster lighting, extensive instancing etc), but with udon itself being slow (and i notice this greatly even in simpler worlds with just some basic stuff like video player and some other doodads), it puts a heavy limitation how much performance i’d be able to squeeze out of things. The perceptual impact of udon always felt like it was steep the more things people did with it beyond very basic triggers.
While nothing i want to make is complex by any stretch of the imagination when it comes to scripting, the difference is the frame time goal on lower end systems without sacrificing modern visual fidelity, and i don’t need something like udon making things more difficult.
As a note: I also have every intention of describing and hopefully making tutorials on how to go all-in on these techniques so others could implement them as well. Because there’s a lot of things people could do differently to reduce frametime and memory footprint, while increasing visual quality, that are non-standard. But i want to be able to make my amazing looking world with extremely good performance to show it off and draw attention to it.
Most people don’t need a heavy VM wasting performance in their worlds, if they only require simple triggers, maybe some basic math, and maybe some gameobject manipulation or transform data copying. I had originally intended to do my work in SDK2 even because of this.
1 Like
I’ll do a mention here; you don’t need to wait for Soba to get much of this functionality, U# 1.2 has a beta with much of the functionality already, including non-behaviour classes, and generics which Soba apparently won’t have initially. Release UdonSharp 1.2-beta1: Non-Behaviour scripts, Lists, Dictionaries, and more · MerlinVR/UdonSharp · GitHub
19 Likes
without generic, then you soba not also have to repeat a lot of writing the same program?
and giving up off-the-shelf tools and having to maintain them entirely on your own, unless a team of 100 persons is dedicated to doing this, why not choose to change to an open source project?
with bad luck, trying to have enough features for a language may drag the company down, or the language itself may become very bad.
What are the reasons for abandoning the existing path in favor of this one?
5 Likes