Avatar Bugs & Feature Requests

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

Currently, the shader type called Hidden that can be specified as a fallback shader is introduced on the following page as: > Hidden // (this will hide the mesh from view if the shader is blocked, useful for things like raymarching effects.) > https://creators.vrchat.com/avatars/shader-fallback-system/ However, if a mesh using this shader has an animation that sets the _Color alpha parameter to 1 , the mesh that should have been hidden by the fallback shader becomes visible. My guess is that this happens because the Hidden fallback shader is actually reusing an existing shader (such as Unlit/Color ) and simply sets the color alpha to 0 in order to hide the mesh. When an animation overrides the alpha value, the mesh ends up being rendered. As a solution, I would suggest either providing a dedicated Hidden shader, or adding a special “hidden” flag to the existing shaders so that polygons are not rendered at all.

I tryed to send "/avatar/change" osc message but it does not work. I also sended "/avatar/parameters/..." together and it works. osc.send({address: "/avatar/parameters/BustSize", args: [0.5]}); // works osc.send({address: "/avatar/change", args: ["avtr_0eb0aeff-5a47-4c01-86e7-943cfcc1e8b5"]}); // not working

User is unable to change into an avatar using the "/avatar/change" OSC unless it is a favorited avatar. The user however should supposedly be able to change into any of their own uploaded avatar or a recent avatar, as stated in the 2025.1.2 Update Log. "You can only change to avatars in your favorites, your recents, or that you've uploaded yourself." https://docs.vrchat.com/docs/vrchat-202512

I have noticed that server processing is making changes to the avatar performance rankings without any indication as to where the problems could be lying within the avatar. This can cause a particular problem where an avatar creator has gone through the effort of optimising the avatar to at least poor or better as indicated by the VRChat SDK, however, in game it goes back to being rated as very poor. Take this example. I have an avatar that is Very Poor to begin with, but, the Bounding box rating is Good according to the SDK readout. Because this avatar has VRCFury components on the avatar, I needed to rule out that it is VRCFury. I proceeded to create a local build and test version for the avatar. When loading the build and test version on VRChat, the bounding box also is good according the VRChat stats. I then upload it to the VRChat servers and when I load the uploaded version, the bounding box goes from Good to Very Poor with no indication of where that detail is coming from. This therefore rules out VRCFury on the avatar and likely indicates that the server processing is doing something to the ratings without prior knowledge. For VRChat devs, here is the avatar ID that I am talking about (private avatar): avtr_77276e80-fdcc-4f0c-9f3d-2613f9bf28a1

For those that commissioned an avatar and are unable/unwilling to upload an avatar themselves. My idea is that if we upload an avatar, as an avatar creator, we can choose someone to transfer the avatar to, on platform, and without sharing of account information. I do avatar commissions and I either have to walk novices through how unity works, or just hope for the best from them. I know some folks share passcodes, and that in and of itself is an awful idea from a security and tos standpoint. It makes avatar artists very liable if we choose to do that, and a lot of people don't have the option to upload themselves, (don't have a computer and play via question, don't have a strong enough computer, etc) Pros: possibility of selling one-of-a-kind avatars on the marketplace commissions with vrchat currency (maybe? like a mix of roblox and the vrc marketplace) no need to share passcodes, and can transfer ownership to another user maybe add permissions (similar to characters on toyhouse) for transfering, like can't transfer within x amount of days, or unallowed to make public, or sell, etc. avatar adopts and overpriced digital products (great money opportunity for vrchat, a la roblox) ~artificial scarcity~ for the marketplace with one-of-a-kind Cons: can't easily change after-the-fact without making uploading avatars more confusing idk probably has some sorta exploit/risk, maybe if an acc gets hacked and avatars get transferred out and can't get em back idrk

I have a big suggestion that speaks for ALL paid avatar creators. We spend a lot of time, money and effort creating our avatars and we tend to make our promotion version of our avatars public so that our promotion team can take pictures in them. It frustrates us when people outside of our promotion team gets a hold of the avatar because it is posted in avatar search worlds for everyone to use which leads to our work getting ripped! My suggestion would be to be able to limit avatars that we upload to friends only or by VR Chat user. This would protect our work significantly. Please take this into consideration!

Since more and more avatars use face tracking, the currently available amount of bits for avatar parameters is getting very low. Face tracking alone takes about half the parameters available. One way I got around this on an avatar is to utilize two 8 bit parameters to sync mutiple values in sequence, which makes it basically possible to have an "infinite" amount of parameters. The downside of that is that the sync is not in realtime (stutters for other players since every parameter synced this way has to be synced every tick after each other) and when joining a world the initial sync to set all parameters for other players to be visible takes also a bit of time. About 10 parameters a second is the maximum. Im seeing more and more people using that kind of sync for those parameters so I think lots of people are interested in having more parameter space. Even doubling the current amount would be a huge help. If that is for some reason not possible. More fine adjustments would also help. Like defining the precision of int and float values. Lots of radials dont need the full 8 bit of range. Or make some parameters static, so that we have static and dynamic values where static ones only change when used in a radial and dynamic ones are those which are constantly changing (like face tracking for example). The static ones only would need to be synced on world join / other player join and when changing the value manually via toggle or radial. That could possibly save on network bandwith if thats an issue.

Ever since somewhere around 1711 physbone colliders sometimes fail to work until the physbone is toggled off and back on. Toggling the collider does not fix it. It affects randomly locally to the viewer. It is not dependent on whether you are the wearer or not. This is most obvious on floor colliders for tails, but can break other avatar systems that depend on physbone colliders.

I recently found out about Thry's Avatar VRAM Calculator. I didn't really have any idea that I should be looking into how much VRAM my models were using before uploading them. I realized this week that most of my complex models could easily go up to 800MB in VRAM with all features enabled. I feel like I would have made a more conscious effort to keep this number low if it was made aware to me via the SDK. It is really nice to know how bad my model could impact others with these metrics. Thry's VRAM Calculator very bluntly let's you know how much Video Memory is being used. Please add some form of metric for this with the Avatar SDK or Creator Companion.