Am only now seeing this. Was busy with things all day yesterday.
Thank you for the clarification.
Yes, thank you for noticing that we have been waiting for World VRCPhysBone for a long time.
3 Likes
I’m really hoping that when the technical questions are eventually answered we will get to see what the performance differences really looked like. A video showing the tests side by side with Udon and Udon2 with some timing stats would be really cool to see (though I doubt we would get that). I genuinely just want to see some of the testing that went into it and what the performance increases actually were.
I was mostly hoping that udon2 would have much faster instantiation times too since that is the slowest part of my world right now (maybe soba will be faster eventually?). Generics, non udonsharp classes, and Lists are also a huge roadblock for me right now as I have to instantiate a whole game object (which is crazy slow) to use as a data container. (I am aware of UdonSharp 1.2 but this isn’t officially supported yet)
I think that seeing the real performance metrics to compare would help show the real pitfalls of udon2 and could show the strengths of Soba over the current system.
2 Likes
Really appreciate the follow up! Keep up the good work.
1 Like
Thanks for the explanations, they do provide a lot of insight as to what happened.
If I have something to add, it’s that you probably should have come with those explanations about why you were dropping Udon2 for those reasons before, and we’re looking into something else and we will keep you updated, and not kept on saying “we’re working on it”.
Interesting read. If Im not mistaken, one of the main people building Udon 2 was also let go which stunted development. On top of that, the complaints about every VRC update would also stunt progress of Udon 2 “What would have worked yesterday, wouldn’t work now” (thats roughly what was said)
While Udon in general was great for new tools and features, it made making worlds alot more time consuming. Which is why alot of people originally just opted to use a convertor with the, at the time, already familiar and simpler SDK2.
I hope that in general, what can be made with Soba/Udon in the future, will keep what can be accomplished currently but with more tools that could help speed up/simplify world creation.
Hopefully it will be less taxing too. Udon heavy worlds tend to be laggy but I guess that is mostly up to the creator and how the optimize that
Nice PR.
But I believe the community is more interested in seeing substantial evidence that Soba is better than Udon 2, otherwise we’d rather just keep waiting.
2 Likes
Really? So what about this
4 Likes
Thank you. I think this is what many have been looking forward to (inlc. myself).
Responses:
While there are still open questions, I personally believe this is how you should communicate.
Saying you wont expand on all the technical questions here for the sake of answering correctly within the next post is very much welcome too. Just keep in mind to follow up on this within the next post. Even a mention of “We are currently still collecting information to give you transparent and correct answers.” would be appropriate (but dont wait too long).
Just two things, follow up on it and keep up the quality. Much like a documenary needs more work than a quick live stream reaction, I expect the same sort of quality logic to be present in the upcomming posts.
Benchmarks:
I understand your worries when it comes to posting benchmarks as the community often uses said benchmarks as a reference to what was promised VS what was actually delivered and consistenly creating presentable benchmarks takes a lot of time, but I also think these benchmarks are great to show your progress at the same time.
Personally I would have no issue if you were to post a benchmark every now and then with a disclaimer describing during which development state the benchmark was made, allowing the reader to classify the given information and understand the context making it less of a suprise if it gets better or worse.
Promises:
I think many are aware that what seems like it works today without issue, can break tomorrow. Saying:
how do we know this won’t happen to those things, too?
The honest answer? I can’t promise they won’t.
Is perfectly fine and I encurage to give more information about the current state of things. Just like with the benchmarks, give a disclaimer, a short explaination and nobody would expect you to follow through with something that isnt working out in the end.
The issue with the jump from Udon 2 to Soba was not in the fact that it happened, but rather that it came out of nowhere. Stay transparent, give context and allow everyone to understand the circumstances, which lead up to the decisions that finally needed to be made.
TLDR;
Well done, keep up the quality. I am looking forward to your next update!
Unfortunately, while for a lot of us, Apple support isn’t important, to VRChat it is very important, as it will presumably bring in a LOT of revenue from kids buying VRC+ subscriptions
It’s the same reason Gift Drops and Prints were implemented recently too, to give people more reason to throw their money at VRChat.
1 Like
What Apple allows or not should not be relevant for what is done on the PC. In this specific example, one of things Apple is allergic to for no good reason is JIT compilation, which works fine on every single other platform. As such, any scripting solution on iDevices is cursed to be slower than on any other platform, but there’s no reason to make other platforms as slow.
NB: there are very few exceptions where JIT is allowed, such as JavaScript in Safari. Yay monopolies and walled gardens!
In the context of WebAssembly, there are different runtimes (think software libraries) compatible with the same code format. Many offer JIT capability, some offer interpreter mode, which could be used on iPotatoes. It’s perfectly possible to use different runtimes on different platforms to run the same world scripts, with a bit of extra engineering effort. Alternatively, a runtime with both JIT and interpreter modes can be chosen.
In the grand scheme of things, Apple limits apply to everything. Just like WASM, Soba will never get access to JIT on iToasters. And in case of Soba, engineering effort is seemingly spent on implementing another slow interpreter for all platforms, instead of using existing off-the-shelf tech to get best possible performance per-platform.
2 Likes
This topic was automatically closed after 29 days. New replies are no longer allowed.