Developer Update - 3 August 2023

Welcome to the Developer Update for 3 August 2023!

This Developer Update’s thumbnail features the world “VR art ‘New place’”, an amazing gallery of 3D VR art! Lee Jae-hyuk’s art is featured in GreatMoonAroma_'s world (constructed by Jetdog). Go check it out!

If you’d like to catch up, you can read our previous Developer Update from July 20.

Important Info / Announcements

VRChat 2023.2.4 Released!

Earlier this week, we released VRChat 2023.2.4! This release included the much-requested Avatar Scaling feature!!!

In addition to the normal full patchnotes available in our docs, we’ve also got a video for you that has a summary of the features and changes.

VRChat 2023.2.4p1, too!

Right before this Dev Update got finished up, a new patch went out that fixed a few bugs with 2023.2.4. Check those patchnotes out here.

VRChat 2023.3.1 Open Beta

We also have an active Open Beta! Check out the Discord to learn how to join.

The patchnotes for the version currently on Open Beta are available here, but there’s also a big feature in it that’s important for people using OSC to make tools for VRChat: OSCQuery!

OSCQuery

VRChat 2023.3.1 includes support for OSCQuery! This is a system that makes it easier for applications to set up and connect over OSC. Some applications will now be able to automatically find and connect to VRChat, so users don’t have to manually find and input IP Addresses and OSC ports themselves. This feature also enables VRChat to send to multiple OSC applications at once instead of only one!

Developers who are interested in integrating with this new feature can read our OSC Wiki Page on OSCQuery for details on VRChat’s implementation and requirements.

In order to accomplish this, we built our own open-source OSCQuery library for C#, since there wasn’t an existing one we could use. We did this in collaboration and communication with some of the amazing OSC application developers from our community - thanks to you all for your feedback and patience as we developed this over the course of a year!

VRChat IK Beta

The IK-Beta has completed closed beta testing and is now available for everyone to try on the Steam “IK-Beta” branch. There have been some new changes since we last discussed it in a developer update:

Tracker Rework – Adjust Motion Prediction

You’ll now be able to choose how much motion prediction SteamVR applies to your FBT trackers. The more prediction, the more jitter (it’s trying to guess where the tracker will be in the future, and sometimes gets it wrong). The new default will use no motion prediction, so jumping around and stomping your feet should now look much more stable. Feel free to play with the “Tracker Motion Prediction” slider in the Tracking & IK main menu page to see what’s best for you.

Tracker Rework – Losing Tracking

When SteamVR trackers lose tracking (for example getting blocked by your clothes or chair) they’ll now temporarily freeze in place rather zoom off to outer-space.

When you use the “Freeze Trackers on Disconnect” option, your frozen trackers will stay just where they were in your playspace, rather than being dragged around by your head.

Spine Improvements

Lock-Head mode will now support some subtle positional chest tracking (previously only Lock-Both mode had this). This version is softer than the Lock-Both positional chest tracking. Isolation dancers will likely still prefer Lock-Both for chest tracking.

Video Preview

Here are some of the new changes in action:

We’ve continued to iterate on your feedback during the IK-Beta handling lots of edge case avatars and poses. Please give it a try. It’s live compatible!

VRChat Community Guidelines Update

We did a soft announce for this yesterday, but we’ve just updated our Community Guidelines, and added the new “Creator Guidelines” page!

Check out our latest blog post, or you can dive right into the Community Guidelines or Creator Guidelines.

Generally speaking, none of these guidelines are new or a surprise. No new rules have appeared, and no changes are being made to our enforcement.

What it does mean that our guidelines are much more clear and easy for you to understand!

The Community team spent a lot of time on this project! It took quite a while to do the proper research, iteration, and editing to get this document precisely where we want it to be. All of the language we deliver in our guidelines is quite deliberate and phrased with intent.

Keep in mind that no matter what, the VRChat Terms of Service are the law of the land. The Guidelines are just us telling you “hey, here’s generally how we operate here.” Reading them is a great way to understand how we expect you to behave in VRChat.

… in other less-serious words, attempting to rules lawyer or “heh, GOTCHA” using guideline wording isn’t really the vibe we’re going for. We want people to understand WHY we wrote the guidelines the way we did, and we expect VRChatters to use their own judgement to make calls when they need to. Ideally, that way, many issues never have to rise to the point where Trust and Safety has to get involved and start swinging hammers around. :sweat_smile:

If you have questions, feel free to ask in this thread!

Ongoing Development

New VRChat+ Feature: UI Color Customization and Color Picker!

We’ve got a brand new VRChat Plus feature on the way for a future release…!

We’re adding UI color customizations for VRChat Plus subscribers as a new benefit!

You can use this feature to select colors for 6 different categories to be used in place of our default color palette. You can then save those palettes and swap between them!

Development Deep Dive - Avatar Scaling and Custom Scalars

Every once in a while, we’ll have a deep dive on something a bit more technical in nature. These take longer to put together and review, so don’t expect them too often!

This one’s called “How does Avatar Scaling deal with Custom Scalars? (the technical side)”

The first iterations of avatar scaling shipped to our open-beta broke avatars that had custom scalers, such as “GoGo Loco Broke”. This was a big pain-point, and while it was considered to just declare this “broken by design”, we figured out a workaround in the end that satisfied our design and performance goals.

Community members have been curious as to how this was achieved, so we’ll try my best to explain it here.

The Problem

Custom scale animations apply to the root transform (where the descriptor lives) of the avatar every frame. We used to apply the new avatar scale only once, right after it loaded, which means afterwards (and in fact, before we even “measured” it for FBT and such, which is how scalers originally worked) animations could affect the scale again. Our internal systems would now however assume that the scale we set is still active, which led to inconsistencies in eye height and expected scale.

Setting transform.localScale in Unity comes with a cost, especially if it needs to run for every avatar in an instance, so simply running it all the time is not a great idea. It also requires careful timing, as animations and other parts of our avatar system may run concurrently. (yes, VRChat is multi-threaded…)

One other suggestion that immediately came from the community was that we should just remove the scaling animations on load. Unfortunately, Unity’s way of packing Animators does not preserve much detail, and there currently isn’t much we can do to extract or modify individual animations on an avatar. Did you know that even the layer names in the in-game avatar debug panel only work because the SDK specifically saves them?

The Solution

SDK3 avatars in VRChat use Unity’s PlayableGraph API. Without going into detail, the general concept is replicated in community tools such as Av3Emulator, which you can check out if you’re interested. All your animations and animator layers are part of a single graph that controls what your avatar does.

Unity supports custom scripted nodes in such a graph (called animation jobs), which will be evaluated together with any animations. The solution then is to simply insert a node near the end of this graph, which applies the root scale that the native avatar scaling system has calculated. In comparison to the “just set transform.localScale every frame” solution, this solves 2 major issues:

  • Performance is mostly unaffected, since the job is Burst compiled, and will run asynchronously together with the rest of the graph
  • Applying the transform values happens together with the rest of your animations, which means timing will match that of existing scalers

Almost There

Let me tell you, it’s not just you, fellow creators - sometimes we have to fight Unity’s weirdness internally as well.

Unfortunately, Unity 2019 (at least) has a bug where accessing or writing scale on the root transform from a Playable graph will produce bogus (though quite entertaining) results if root motion is disabled:

You were very close to experiencing this yourself, by the way, as it got caught fairly late in the QA process! For some reason it works on a lot of avatars, but very specific ones break. Never figured that one out.

Turning on root motion alone is not a solution, as this could mess with our IK solution. So we need to get creative! Unity allows you to declare a function called OnAnimatorMove, which will be used instead of the built-in one to apply root motion. And in a momentary stroke of genius (or madness), we came up with the solution that we ended up shipping - let me present to you, the most powerful root-motion application script known to VRChat™:

void OnAnimatorMove()
{
    // just don't do anything
}

don’t worry, legal team - I changed what the comment says, so I’m not disclosing trade secrets here :wink:

With this in place, we can enable root motion on the Animator, Unity will happily give us access to all root transform data in our graph, and then we discard the changes at the end so our IK is unaffected.

Uh, the End?

So, what’s the lesson? Simple feature or bugfix requests can often turn out to be vastly more complex than you’d think!

If you want to learn about the more relevant parts of avatar scaling, you can check out our creator docs here.

Conclusion

That’s it for this Dev Update! Our next update is scheduled for August 17th, 2023. See you then!

22 Likes

UI Customization is going to be hype!

11 Likes


I love that UI Color Customization yay!! :3

3 Likes

Since the most important thing in the guidelines seems to be that users consent to whatever is going on in an instance, could we get a feature where instance creators can define a text popup that shows to anyone who wants to enter that instance, and they need to press OK to this message or be sent back to their home?

5 Likes

Anything to report on the upgrade to Unity 2021/2022? The 2019 editor needs to be buried as soon as possible, it’s missing so many basic QoL features compared to later releases.

4 Likes

Not a bad idea, but it isn’t in our plans.

Also, the difficulty of informing and gaining informed consent from everyone present is a feature, not a bug. It is meant to make it prohibitively difficult to gain active permission from everyone present in unplanned, active, and “churny” spaces like random Friends+ instances.

The onus of responsibility, after all, is not the person dropping in on the instance without knowing what’s going on. It’s on the people expressing the content in question as defined by the Guidelines.

Not at this time, sorry!

I’m glad y’all like it, honestly I wasn’t paying attention and this feature popped up out of nowhere and it looks so cool

4 Likes

So hype for UI Customization!!! I cant wait!

1 Like

OSCQuery Wooooooo! Been popping open the git every day for a long time hoping it would release. Though a little disappointed it didn’t launch with a simple router for legacy apps~ but that doesn’t really matter since the community on top of it in a few days. (Along with adding OSQuery support to maintained apps)

Freeze on disconnect now being relative to playspace instead of to the head is such a good change.
Bless Kung.

1 Like

I for one, appreciate the novel approach to solving the root-motion problem.

1 Like

It would be cool to be able to change the background of the vrc menu to any picture from the vrc+ gallery

4 Likes

How is the mobile app coming along? It’s 3-4 months later, so I’m just curious. Personally my bet on updated expectations is 3-4 months :wink:

Also thanks for posting the new VRChat build on Monday. I like having more time to ponder changes before a dev thread.

I’ll have to look into oscquery details. One question I have is if it’s for on the computer, or if it’s also useful for a phone FBT application to find my computer / standalone Quest 2.

2 Likes

Does the ToS still need to be updated to match the new guidelines? 9.4c of the ToS still sounds like it might not be compatible with the community guidelines.

1 Like

Cool idea, we’ve definitely had this one too a few times. No plans but it’s in the back pocket.

Me too, our engineers are wizards.

No updates at this time, but a huge amount of our work time is dedicated to it right now.

AFAIK, this is the reason we made a whole new library-- you can implement the library on top of your application and it should Just Work with VRChat OSCQuery.

4 Likes

Im not sure if this is revivent to the post but i have to ask this, is there any word on the two mobile version of VRCHAT? I want ti experience the game so much, and even tho that i will get a headset in sometime this month, i want to experince it on my phone, i heard yall were annoucing it sometime back in march or april and there hasn’t been any word since, also follow up question since chromebooks are typically made wity android parts, does this mean that the mobile version of VRChat will work on there or does that need it’s own special code?

Nope. Chromebooks don’t run Android, they run ChromeOS, an entirely different thing.

In addition, Chromebooks simply don’t have the hardware that’d make it possible to run VRChat. We don’t have any plans to release to ChromeOS at this time.


Edit: I’m kinda wrong here! I’ve been told that Chromebooks can run Android apps natively. However, we’re not targeting them at all and won’t be providing direct support. Also, you still have the hardware problem.

… what I’m saying is, once Android VRChat is out, give it a shot, it might work? If it does, nice. If it doesn’t, that’s unfortunate.

3 Likes

Have you guys considered shipping some default UI Color presets?
That way people could also just pick a default one if there is one they like instead of having to make their own.
You for example have a grey, white (idk why anyone would use those), red, blue etc. preset by default. ^^

Edit: I hope the color picker comes soon! Can’t wait for it to be out :p.

Edit 2: Maybe you could even make one that would be fitting for every background :p.

5 Likes

The new Creator Guidelines contains a lot of doublespeak, I think it would be helpful if you could explain what VRChat defines as “provocative” and “intimate” content for example.

Because the Terms of Service seems to be in conflict with these guidelines no matter how you look at it.

1 Like

I noticed in the Scaling update patch notes today, there is a changelog for,

  • Fixed translation offsets for position constraints not scaling correctly

This sounds like constraint offset values are being accounted for on VRChat’s end when Avatars are scaled.

I understand the motivation behind this change as it fixes many previously non-scale friendly systems, but am I correct to assume this then becomes an inconsistency with the behaviour of constraints when testing in native Unity?

Will tools like the AV3Emulator likely have to implement this behaviour for proper testing Unity-side?

This also seems to cause issues who intentionally use the design of native fixed-offset behaviour of constraints, as they will now have to workaround this behaviour by adding scale constraint(s) to prevent the offset scale.

Overall, I’m not complaining since this fixes things for the majority, just asking for clarification on potential inconsistencies between editor vs in-game.

1 Like

There’s currently a bug since the scaling update that breaks manually uploaded avatars above the udon limit of 100m. Locally it appears fine, but for remote users, the scale is clamped causing the avatar to float in the sky for them. This is a really annoying issue cause it dramatically limits the size abilities we would otherwise have to use. Certain worlds were made for scales bigger than this, so I hope this issue is being investigated. Any info on this would be appreciated.

These are intentionally left undefined and I won’t be going deep into defining terms or edge cases in this thread. Our guidelines aren’t a legal document and you shouldn’t try to parse or pick it apart like one. I encourage you to look up common usage of those terms and roll with that.

Sorry, I’m not really grokking you here. Also, this thread isn’t really the place for bug reports (if it is one?) :sweat: Can you make post on our Feedback boards instead?

I’m kinda surprised the SDK lets you upload avatars that large. Things start breaking above a certain height…

You should file a bug, but I will be candid here and say that it probably isn’t going to be a very high priority fix. 1/10th of a kilometer tall avatars aren’t exactly our main target user! :sweat_smile:

As I told Sleightly above, this thread isn’t for bug reports. Please post bug reports to our Feedback boards! (otherwise, they aren’t gonna get logged)