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.
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
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!