Developer Update - 27 August 2026

[strasz]

Welcome to the Developer Update for August 27, 2026.

Today’s featured world is room.3458 by rot34587.

Announcements

Moonchaser

We’re hosting party in VRChat… tomorrow (August 28!) at 6PM PDT (9PM EDT / Saturday 10AM JST)!

Get excited for Moonchaser! #VRChat #vrchatcommunity #virtualreality #party #moonchaser26

Moonchaser features 5 DJs (and two VJs!):

1: Clyde Machine + SoftlySteph
2: 3Marco
3: Sera Akai
4: naku + SirRose
5: yoru

Moonchaser is accessible on all platforms. Not only that, but the performance from the main instance will be broadcasted to all other instances – including a hologram of the DJ!

Can’t get in? That’s ok! We’ll be streaming on Twitch! If you watch the stream for long enough, you’ll even get a gift… just make sure to link your VRChat and Twitch accounts.

But wait… there’s more! Folks that visit the instance will also get a gift. Spend another hour there, and you’ll even get yet another gift. We’re very generous.

Can’t wait to see you there!

Spookality!!

It’s almost that time of year! We’re doing something a little earlier than usual…

While we’d like to keep the themes a secret a little while longer, here’s a head’s up on the timeline we’re expecting for Spookality this year:

• Submissions Open: Sept 3 - Oct 1
• Judging Period: Oct 2 - Oct 15
• Showcase Period: Oct 16 - Nov 2

Also, in the spirit of the jam, we’ve decided to feature ALL eligible entries in the Home/Hub world for Spookality, even if they didn’t win a prize. Note that we will not be showcasing avatars that break TOS or are off-theme: sorry to the person who submits a Texas flag on a cube every year.

2026.3.2 is in Open Beta!

Yep!

This one is a smaller release – it’s stuffed with a lot of QoL updates, bug fixes, and the like. No big feature this time, but a lot of cool little things, you know?

You can read about it here!

Unity 6, the SDK, and VCC

We’re hard at work on the Unity 6 SDK and VCC support! As of right now everything is going through QA to make sure creators get a smooth upgrade experience.

Once we get to open beta, creators will be able to automatically install Unity 6 via VCC and migrate their projects with just a couple of clicks!

Material Contacts

In addition to the bonus contact parameters we shared last time, we’re also giving you a new way to use contacts: writing directly to shader properties!

We’re calling this “Material Contacts”, and how it works is if enabled on a receiver, you select up to four target MeshRenderer components that will then have the full world-space transform matrix of each of the receiver’s four nearest contacting senders written to their material properties, in addition to the transform of the receiver component itself.

The interface looks kinda like this:

And here’s an example of an effect you can achieve with that system, a fire effect shader (credit to Zekk) masked by proximity to a contact sender with the Fire tag:

As part of this, we’re also planning to drop the update rate limit of 60 times per second currently applied to contacts. This should allow contacts to consistently update every frame when VRChat is running faster than 60 FPS.

Action Drivers

This is an early preview of a new SDK component we’re working on for avatars. Many of the details about it are still undecided, so everything here is subject to change.

Take it with a pinch of salt!

A popular use case for expressions on avatars is to do things like toggling objects on and off, adjusting blend shapes, and more. Setting up cases like these in an SDK project from scratch requires a fair amount of knowledge of how Unity and its animator system works, which isn’t always intuitive to users that are brand new to creating avatars.

To help make it easier to set up common use cases like this, we’re working towards introducing a new component called the Action Driver. The fundamental idea of it is to let avatar creators bind parameters on their avatar directly to one or more “actions” that they want to trigger, which includes common tasks like turning game objects on and off.

This will not remove custom animator support from avatars! Instead, Action Drivers would be offered as additional functionality, separate from animators, aiming to make the most common use cases easier to set up for creators that are still new to building avatars.

Here’s a preview of what the new component might look like. As a reminder, this feature is still in development and everything you see here is still subject to change!

(Seriously: this is IN DEVELOPMENT! It might not look like this or function like this when released. You’ve been warned!)

We hope to have more details available for you in the future once we’re ready to share them!

Variable Width Avatar Parameters

When defining avatar parameters, there are three types you can choose from:

• Integers, 8-bit values ranging from 0 to 255
• Floats, 8-bit fixed point decimals ranging from -1.0 to 1.0
• Booleans, 1-bit true or false values

As part of planned improvements to the avatars SDK, we’re looking at introducing a way of varying the number of bits used by integer and float parameters. This aims to address two problems:

1. If you have an integer parameter where you don’t need the entire range of values up to 255, some of the 8 bits of memory it takes up are never used, which wastes space that could be used for other synced parameters. This feature would let you reduce the bit width to only cover the range of values you’re actually using, which leaves the extra space free for other synced parameters to use. The same case applies to floats where you don’t need the level of precision offered by using 8 bits.
2. In the opposite direction, you might want an integer that has a maximum value above 255. For this case you could increase the bit width, allowing for a higher maximum value at the cost of taking up more room. Similarly, increasing the bit width of a float can be used to increase its precision.

A common pattern in avatar creation is to have multiple toggles on an avatar that should only be active one at a time, for example, worn items that overlap, with the general current approach being a set of Boolean parameters where only one can be true at a time. We hope that being able to reduce the bit width of integers will offer a more convenient solution to this that also takes up less space in the 256 bit allocation for synced parameters.

Here a basic example. The inspector is still subject to change!

• The Outfit parameter only takes up 2 bits and has a range of 0 to 3 inclusive. This allows having up to 4 mutually exclusive toggles by having each one assign one of the values from 0 to 3
• The EyeConstriction parameter takes up 4 bits. It still has a range of -1 to 1, but trades some precision for extra room for other synced parameters.
• The total number of sync bits used is 7, compared to 17 bits this setup would normally use.

Conclusion

That’s it!

See you in two weeks!

[ZenithVal]

Multiple times reading I went OH MY GOD.

Holy heck. Material contacts n’ action drivers are incredible
And to top it off, BIT DEPTH FOR PARAMETERS AHHHHH

[Tran_Fox]

@strasz

Material Contacts

In addition to the bonus contact parameters we shared last time, we’re also giving you a new way to use contacts: writing directly to shader properties!

@strasz

This should allow contacts to consistently update every frame when VRChat is running faster than 60 FPS.

Omggg these two are perfect for a shader I’ve been trying put a good while (no more jank methods of copying params into an animator onto my meshrenderer with delay and jitter :3)
Though I’m a tad confused why the Target Renderers is limited to 4 per component rather than just being a perf stat on it’s own (like physbone effected transforms)

@strasz

Action Drivers

VERY excited to see where these are going and to see how they’ll help with animator performance!

@strasz

Variable Width Avatar Parameters

Also a very nice QOL change that I know some people are really gonna be happy with, though the float bits should probably display how much precision the parameter will have in the end.

[Nanochip]

So essentially, Avatars SDK 4.0 is here! Holy massive update. Kudos!

[Zekk]

@strasz

Material Contacts

In addition to the bonus contact parameters we shared last time, we’re also giving you a new way to use contacts: writing directly to shader properties!

We’re calling this “Material Contacts”, and how it works is if enabled on a receiver, you select up to four target MeshRenderer components that will then have the full world-space transform matrix of each of the receiver’s four nearest contacting senders written to their material properties, in addition to the transform of the receiver component itself.

I have ascended to an astral plane. I must be dreaming. Transform information in my VRChat shader from a contact component? Lies and deceit.

This is genuinely amazing. So much cool shader tech just became not horrible to do with this!!!

[mackandelius]

@strasz

Action Drivers

So since everything is up in the air, it would be kind of neat if you could set mutual exclusivity on the action drivers and if the performance rankings then could reflect that.

While I am not a fan of the walking wardrobe avatars, if it was possible to make it so only one outfit, or avatar gadget, could be enabled at a time and the SDK and other clients knew that then the performance rankings could be more reflective of the actual performance of the avatar, simplest being just going through the permutations and setting the stats to the highest numbers in each category.

Edit: Of course there would need to be a hard limit on the amount of mutual exclusivity permutations, since it would need to be calculated server-side and the SDK can’t be trusted to calculate it and having the client do more than a sanity check would just be a downgrade.

[macjam]

Some of this sounds pretty awesome.

[Shadowriver]

The Action drivers (techincly they component toggles) is things that avatars toggles delt with been done since very beginning, animations are not made for that and just waste performance, not to mention complexity of setting them up and i been renting about that for while, good that they finally here.

This will also help with MMD/Seat Animation facial bland shape control setups which over complex animation setups breaks it

[Smash-ter]

@strasz

Material Contacts

In addition to the bonus contact parameters we shared last time, we’re also giving you a new way to use contacts: writing directly to shader properties!

Pinch me I must be dreaming

A question I have is when it looks at the MeshRenderer/SkinnedMeshRendereris it looking for the root transform/origin of the meshes assigned in the target renderers with regards to the _Self matrix, if not could there be an option to have a way to have an anchor override transform that could calculate from the transform override gameobject to the contact’s transform?

Besides that, the feedback I’d give would be to abbreviate the prefix with either _VRCContactReceiver or _ContactReceiver as _VRChatContactReceiver is a really long one.

[4Bakers]

Insane work!

UdonBehaviour[] in graph next, please?

[missingno123]

@strasz

Action Drivers

Is it real? Is it really real? Am I dreaming? Will tupper’s endless complaints about animators finally be put to rest?

@strasz

• Integers, 8-bit values ranging from 0 to 255

With variable-width parameters I’m wondering if this opens the possibility to also change the signedness of integers (as convenience, since technically the workaround is to offset your math by ±127)

Also, can bit width be ANY arbitrary number or does it have to be some even/power-of-two value?

@strasz

speperate

Minor spelling mistake. It’s all over. Wrap it up guys we’re done here.

[Dexvoid]

@missingno123

Also, can bit width be ANY arbitrary number or does it have to be some even/power-of-two value?

The current (subject to change) plan is for bit width to support values between 2 and 16, where 8 remains the default. So yes, you could assign 3 bits to an integer for example, which would let it express the values 0 through 7.

[RuneFox237]

@missingno123

With variable-width parameters I’m wondering if this opens the possibility to also change the signedness of integers (as convenience, since technically the workaround is to offset your math by ±127)

Seconding the ability to switch between signed and unsigned ints for the variable width ints.

@missingno123

Also, can bit width be ANY arbitrary number or does it have to be some even/power-of-two value?

Due to how the values are stored as bits it’d end up a power of 2 anyways. Can’t arbitrarily get a range of say 7->21.

you get:

1 bit - 2 values (Just use a bool)
2 bit - 4 values
3 bit - 8 values
4 bit - 16 values
5 bit - 32 values
6 bit - 64 values
7 bit - 128 values
8 bit - 256 values (Current int param)

It looks like they’ll be defaulting to the unsigned int values. i.e. 0-255 for 8 bits like the current int param.

I for one will be happy to not have to dedicate time and effort into manually creating sync bools anymore since I always tried to use the least parameter space possible.

[MysticalDerg]

Action drivers are incredibly exciting!

Will they be build into an animator on upload, or work based on something custom built by vrchat? If so that could be a very nice potential performance improvement in the long run as avatars slowly switch over.

[knah]

Not sure if this is a good spot for feature request, but the parameter bit count feature is still missing two things I’d say:

• Floats in [0; 1] range - sometimes that’s just the natural range of your data, and doing extra steps to convert it into [-1; 1] and back is wasted compute if you don’t want to waste a bit on half the range you don’t use. It’s also the range some Unity features expect, such as normalized time on animator states, layer weights, and more.
• Control over smoothing/interpolation of the parameters. Just like ye olde GestureWeight used to be non-smoothed (it is now), having the control over how a given parameter is handled could offload some pointless compute from the animator in cases where VRC’s default behavior is unsatisfactory. Bonus performance points, interpolation can be skipped for hidden/distant avatars.

As for contact material properties - any chance one could go a step above, and allow setting named metadata values on the sender, which would then be readable in the receiver? The transform matrix is already a bit of data, but adding extras (i.e. fire color in the example provided in the post) might make this feature extra good.
Not sure how to make this good UI-wise, but having the shader take an extra float4 _blah_prefix_Meta_CustomName[4] seems not too complicated?
The metadata values could also be provided to receiver’s animator parameters, although the value of those is less obvious.

[Smash-ter]

@missingno123

Is it real? Is it really real? Am I dreaming? Will tupper’s endless complaints about animators finally be put to rest?

There’s still some other functions that might need to be addressed with animator reliance, but this is still a good step in the right direction

[AirGamer]

Regarding the float range, would it not be better to show us the precision (number of significant figures?), given the range is always -1 to 1?

[Shadowriver]

I think you misunderstood the intention, they will toggle things via component C# code as toggles should always be, means toggles and switches dont need to be animated anymore as they always should not be since very begining.. yes, it was always a hack. They technically are NATIVE toggles and switches

Its animation scripting (its crazy that was even a thing) to Udon leap moment between SDK2 to SDK3 for worlds, but now its happening for avatars now

[KusticesSingers]

@strasz

And here’s an example of an effect you can achieve with that system, a fire effect shader (credit to Zekk) masked by proximity to a contact sender with the Fire tag:

I love the burn

[salena]

Spooky season! :D