VRChat SDK Roadmap (May 2024)

ah…
I see

Very excited for world persistence! Would love to work on developing an RPG with some people! :smiling_face_with_three_hearts:

1 Like

well, it seems that you’re just replacing browsing dev updates with browsing less frequent (but eventually still multiple) roadmap posts.
i think the best way to do this kind of thing in an ongoing project is to have a more static place, like a website page, that would be updated regularly, crossing out delivered changes etc…

5 Likes

This is awesome!
Can’t wait for VRC Constraints! My CPU frametime yippie!

Steam Audio is at least somewhat SDK related, any hopes for information on that anytime soon?

1 Like

I am pleased to hear about the announcement of the new development roadmap. I would like to make one suggestion: It would be great if PhysBones could be used in world creations. This would be an important improvement for the Japanese community.

It dramatically improves the development difficulty and enhances the user experience for live events, especially those frequently held at corporate events in Japan. These live events incorporate avatars and animations within the world for live staging. We can use methods to convert to DynamicBone for these creations, but there are challenges regarding the accuracy of avatar movements and CPU load.

In addition to live events, there may be interesting and meaningful use cases for PhysBones, such as placing avatars in the world and treating them as NPCs. This could open up new possibilities for world creation.

Please consider this!

3 Likes

Could you guys, instead of doing a post like this, just have a persistent board? Like a public Trello/Jira or something? Or some extention of the feedback canny that auto-integrates with your internal sprint/board software.

I’d love to see the features in an actual, tangible map with updated status, versus silently waiting for another dev update and having to parse a bunch of information manually.

Another problem are a lot of features that were talked about end up getting lost forever with no updates. Or with the clock, the last thing we had before it was suddenly released was that @strasz said it was “contentious” and you didn’t really have any plans to implement it.

I also hear that a lot of creators have problems due to VRChat suddenly releasing features that break their worlds or things that are in active development, which doesn’t give them time to actually fix the problems. At least if there was an active board that can be updated more frequently (plus retain old mentioned features), they could anticipate these things.

I primarily want you guys to stop delivering false promises. I would rather you just go radio silent (kinda like Valve) than what you’re currently doing. You keep promising things and then they keep getting delayed, silently cancelled, or surprisingly released with no warning. It’s very frustrating. Like what good is this roadmap when we know that most of those features are going to be significantly delayed like they always are?

It’s not on the roadmap, but Fax just marked it as “Interested” on the Canny, and said:

We’re interested in this! This has become easier to implement thanks to Unity 2022.


Yay but… still waiting for animator culling or whatever is causing very inefficient cache misses. Silly that you need an X3D processor to make this game run 10-30% faster.

1 Like

Awesome roadmap, it’s exciting to see what’s coming!
Any information about Udon OSC? I remember it being on the OSC roadmap here: Milestones - vrchat-community/osc · GitHub

1 Like

Does Unity2022’s new AI navigation also support dynamic generation of NavMesh?
If this were to become a reality, it would be possible to flexibly cover the entire wide terrain in an open world. That’s amazing!

1 Like

I agree that using an auto-integrated task board application is the best way. But I guess that is mainly a matter of human resources.

Instead, I appreciate this roadmap style as a good starting point. It is far better than the sudden release that you described. Also, I don’t accept this roadmap as a promise.

However, I hope they update this regularly within a few (3 or 4?) months.

1 Like

A bit disappointing, perhaps the commitment to VRchat should have been more emotionally cautious.


Given the current abuse of the constraints on VRchat, the impact is actually quite large, with reference to some other Unity users’ implementations I’d expect a boost in the range of 6-20x (8-15x normally).

If combined with the use of jobs I estimate that it could reach 10~50 times? (This is just a guess, not actually tried, estimated normal 20~30x)

According to the current situation I guess there are a lot of visible objects with an average of 60% fps increase, invisible cases about 80~100%.

And it may effectively reduce the pressure on a small number of threads to boost the overall CPU utilization.

Finally, I guess that in a game room with 30 people, if the frame rate after all avatars are loaded is about 25~33fps, it will be possible to increase to 50~60fps (maybe a lucky 70fps?) (single player 150+fps, all robots are about 90fps ~100fps)

But there can be quite a bit of sampling bias, and it may be different for everyone in friends+ or public.

There are so many reasons why a lot of avatars don’t have constraints turned off (but there are a few good avatars that have hundreds of constraints and over 99% of them are turned off).

it could probably be the equivalent of the great change from dynamic bones to physbones.

Only after that the player’s abuse of other parts may still cause frametime to be too high, which still needs to be observed and corrected in the long run.

Are you referring to VRChat’s UI, or UI in worlds? :thinking: I’m sure that VRChat’s UI will see a full translation eventually - but this post is about SDK-related features.

World creators can use Player API | VRChat Creation to get the user’s current language and translate their world. (However, the VRChat SDK doesn’t have a built-in prefab to make this easier!)

Thanks for asking! I’m excited about it, too - but we don’t have anything to share yet. Once we have something to share, we’ll share it in a dev update or the next roadmap!:+1:

2 Likes

We’re considering it! However, I think it would be difficult to keep a persistent roadmap up to date all the time.

For now, I recommend using https://feedback.vrchat.com/ to follow our progress on individual roadmap items. The landing page actually has a persistent roadmap - with filters!

3 Likes

I didn’t realize it had filters in that way. That’s pretty useful, thanks.

Though, it does appear that the roadmap doesn’t really get updated in sync. You often will release a feature, and then it takes 1-4+ weeks for it to get updated, so what does that say about things marked “interested” or “in progress”? It also seems to all happen in bulk around dev update time, versus progressively as you work on the features.

I do know you all recently had a shift by doing the dev updates and utilizing the canny more, but it feels a bit stagnant and unresponsive from my end.

Though, I will re-emphasize: I would prefer if you guys reduce communications about features unless you have a hard date of when it will release. It’s cool to say “we’re working on it!” or give general information. But the level of detail that some staff provide (again, re: strasz clock since it’s such a good example) is too much, and reflects the internal process too much.

I’m sure we know what it’s like to have people over our shoulders and correcting everything we do, and I think that’s what’s happening with VRChat when you end up being too transparent in your updates.

I think I’m a bit at a loss here, are you referencing to when I responded to a Canny in the past saying adding a clock was contentious? That’s the only time I can remember commenting on it, outside of Dev Updates!

If so, I’m not sure this is really a feasible request from a development perspective. If anything, I’d like to give more information, not less, as that information (and insight into the why) can help our community generate valuable feedback we can then bring to the rest of the team to help explain their position on X or Y issue.

Based on the overall response to our increased level of communication over the past year, my gut feeling is that the community really appreciates seeing behind the curtain, and my intent is to keep that going as much as possible. Of course, as with everything else, we’re always open to feedback.

I would like to make one suggestion: It would be great if PhysBones could be used in world creations. This would be an important improvement for the Japanese community.
VRChat SDK Roadmap (May 2024) - #26 by Coquelicotz

I also think that PhysBone in the World could be really helpful.
At this time, DynamicBone is completely deprecated in VRChat (especially for avatars) and the version of DynamicBone that VRChat handles is out of date and not updated.
(Source: [Script update] Dynamic bones v1.3.0 | Voters | VRChat , [script update] Dynamic Bones 1.2.1 - Friction | Voters | VRChat , Supported Scripted Assets | VRChat Creation )

This makes it difficult for new world creators to handle swaying objects in their worlds, since they have to purchase DynamicBone that cannot be used with avatars, and the available versions are newer ones that are not guaranteed to work with VRChat (the version list only includes Original (almost certainly deprecated), 1.3.2, and 1.3.3).

Also, since all DynamicBones in avatars are converted to PhysBones, recent avatar assets are constructed with PhysBones and cannot be used in worlds. (Strictly speaking, we can upload them, but they cannot be swayed.)
(Canny is here:

)

Even if it is implemented without the ability to interact with avatars, this is definitely necessary for creators.
(Udon creators may be able to handle this on their own if there is PhysBone Collider?)

1 Like

It will support dynamic generation of NavMesh… with one caveat: as it is not possible for us to create navmesh agents at runtime (a Unity limitation), you will only be able to dynamically bake the navmesh of the default agent, if you try to bake the navmesh of a custom agent at runtime it’ll actually use the values of the default agent.
It is still possible to bake a navmesh for custom agents in editor.

5 Likes

What a wonderful thing!
Dynamic generation of NavMesh will reduce the MB size of the world!Especially great news for creators like me who create a big world.Thank you!

2 Likes

Just cap the texture size to 2k and give my uncompressed size back since like 130mb of dl is pretty much 500mb of uncompressed or let people go above 500 if they want

I wish you guys had avatar audio for quest in your roadmap :sob: it makes vrchat lifeless without avatar audio.