Expose more information to contact parameters (resulting in massive contact reduction)
SenkyDragon
In many scenarios, we could reduce the number of contacts required for systems by a factor of 8x or more if receivers exposed more information about the current collision. This is very necessary to avoid the undocumented vrchat "hard nearby contact limit."
This additional information could be exposed as parameter suffixes, just like _Stretch on physbones.
Specifically, these parameters would be very, VERY useful, and allow for an ENORMOUS reduction in contacts:
* X, Y, Z offset of the nearest collision in world units but LOCAL rotation (for example, z should be "forward" of the contact)
* Whether the nearest collision is self or others (or world?)
* Velocity of the proximity (change in collision proximity since last contact update / time delta, this is very difficult to calculate in animator since contacts do not always update every frame)
* Velocity of the sender (change in sender position since last contact update / time delta)
* Matching tags of the nearest collision. This could possibly be exposed as multiple bools <receiverparam>_Tag_<tagname> = 0,1
Log In
Tupper - VRChat Head of Community
Hey Senky, thanks for the post -- and thank you to everyone for voting on it, and finally to Poiyomi for the recent Twitter post about it.
At this time, we are not planning to expose additional contact parameters to avatar animators. This is because we are considering other, more scalable ways to support complex interaction systems on avatars, rather than the current trend of building scripts from Unity animators, which goes against their intended use.
As seasoned avatar creators will probably know, avatar animators in VRChat are amongst the worst offenders when it comes to runtime performance. This is why we have previously been taking steps to reduce the impact of animators on performance -- for example, by aggressively culling them when the avatar is not visible.
Avatars should not be built under the assumption that their animators will always be running, which makes it challenging to properly support specialist use cases, such as the one requested here.
Given this, we are eager to avoid encouraging the further use of avatar animators as pseudo-scripting environments in the absence of any actual scripting support for avatars. We are still deciding internally what an alternative to this might look like, and we cannot currently attach a time estimate to it. Please stay tuned to our developer updates for further info as it becomes available.
Tupper - VRChat Head of Community
Hey Senky, thanks for the post -- and thank you to everyone for voting on it, and finally to Poiyomi for the recent Twitter post about it.
At this time, we are not planning to expose additional contact parameters to avatar animators. This is because we are considering other, more scalable ways to support complex interaction systems on avatars, rather than the current trend of building scripts from Unity animators, which goes against their intended use.
As seasoned avatar creators will probably know, avatar animators in VRChat are amongst the worst offenders when it comes to runtime performance. This is why we have previously been taking steps to reduce the impact of animators on performance -- for example, by aggressively culling them when the avatar is not visible.
Avatars should not be built under the assumption that their animators will always be running, which makes it challenging to properly support specialist use cases, such as the one requested here.
Given this, we are eager to avoid encouraging the further use of avatar animators as pseudo-scripting environments in the absence of any actual scripting support for avatars. We are still deciding internally what an alternative to this might look like, and we cannot currently attach a time estimate to it. Please stay tuned to our developer updates for further info as it becomes available.
MondoCat
tunedness intensifies
o.oDiaraD
Tupper - VRChat Head of Community that's not very helpful as already stated there is no alternative but using animators as of now - so we need to use even more jank solutions that require even more workarounds (that are bad for performance) I see no harm in exposing more till there is an actual solution from vrc side.
Hawkley
Tupper - VRChat Head of Community
I agree that using animation controllers to perform avatar scripting is horrible, but it is literally the only option we have been given to make conditional interactivity possible and has long since been standardized within the community, like it or not. Whatever VRChat's devs might have in the works as a solution sounds like it will have to wait until Avatars V4, otherwise you're going to have a full on riot from the entire userbase for destroying all their hard work.
I don't think it helps anyone to simply say, "we don't like what you're doing now, so we're ignoring these kinds of requests." I gotta ask: how are you going to build this, I dunno, mini-scripting engine for avatars to replace the current animation controller abuse if you don't have a full picture of what avatar creators will want or need? Expanding functionality for Avatars V3 will help you figure out what all you will ultimately need to create a robust solution in Avatars V4.
Besides, having to use a bunch of additional contacts in an attempt to make up for the lack of information provided by VRChat doesn't sound great for performance either. Implementing this would at least give you more control over the problem of performance, rather than leaving it to the community to find new, ever more abusive and performance-destroying tricks to accomplish their goals.
Smash-ter
Tupper - VRChat Head of Community my hope is that one of those alternatives could be an avatar udon/u#/soba system that can run locally on player's avatars, and if you wanna have it sync on the network that could be synced similarly to how the avatar parameter list works. It'd have more bits compared to the current avatar parameter list of 256-bits but it'd only be for the new system, while the current limit would be for animators
Dor․
Tupper - VRChat Head of Community Given how unreliable timing has been on Udon2/Soba, I question whether the alternative to animators on avatars would be available before 2030.
On a more serious note - the suggested changes are a driver for improved performance at the current limitations, as to implement the needed features with the current limitations requires the use of dozens of Contacts instead of 1 or 2.
While not wanting to encourage animators to be a scripting environment, it is currently the only way for us to do anything on avatars, and will be for the foreseeable future, that does not mean that improvements to systems like Contacts will not be able to be utilized by alternatives in the future, the suggested improvements here would be just as important for any alternative as it is to animators, none of it is directly tied to our animator-based limitations, but to the limited information we get out of a single Contact.
I encourage you to reconsider your stance on improving Contacts as a whole, our current method for handling their output isn't the concern raised here.
WubTheCaptain
External feedback on X (February 10, 2026): https://xcancel.com/poiyomi/status/2021113525834482119#m
larcWoof
CVR has been doing X, Y and Z velocity since day one. Should be in VRC's implementation too.
Malacomb
I only see this as a big positive, would help with avatar bloat
choccccy
the tag matching info would be useful to a lot of stuff I'm up to, +1
DecoyOct
Could someone with an understanding of this ask give some of the negatives of implementing this? I think showing both sides would help convince people, like me, who aren't knowledgeable enough in the subject. Is it just an effort issue?
Aspǝn
Massive contact reduction? Wouldn't that kill haptic wear and abilities? I use B haptics stuff couldn't there be a work around like people got for unlimited parameters? I can give a template of things. I have made for be haptics stuff if its wanted to look at see how there set up so its not affected. If it is of any sort of help. Its controlled by a AV3 animator not entirely sure how there system works its not a vrc fury item.
SenkyDragon
Aspǝn I think you're misunderstanding the topic. This would allow us to use fewer contacts in many cases, it has nothing to do with changing the limit. Local contacts like bhaptics don't even count toward the perf limit.
Aspǝn
SenkyDragon Oh ok i probably miss read it.
Smash-ter
I feel we should also add Ints in there as well as a third option that would have the contact turn on for remote users locally
Krysiek
I really like the idea of parameter suffixes with collision tag names for contact receivers. This would instantly reduce contacts components required by CuteDancer (and probably other spin-offs like SyncDances) by half.
Dor․
"Matching tags of the nearest collision" that could be an int to the tag index too, though I do like the bool idea since they could possibly give us the option to check multiple tags with one contact, technically less optimized (as they can't interrupt execution on the first match, but that could be an advanced contact setting), but not any less optimized than having multiple contacts like we'd need to right now.
Load More
→