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

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!

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.

Currently, you can have an avatar rated as “Good” at 70,000 polygons, but adding even a single triangle beyond that will instantly drop the rating to “Very Poor.” Obviously, this doesn’t make much sense and can actually discourage some people from optimizing their avatars. (Why bother optimizing other stats if the polycount alone tanks the rating the moment you go over?) I’d like to suggest increasing the polygon thresholds for Medium and Poor ratings, with a gradual step-up between each level. This would make a lot more sense and give creators more flexibility! I’d really love to see this system improved. The VRC team should ultimately decide on the final values through proper testing, but personally, I think a Poor rating could go up to around 120k, and Medium could sit around 90k. Of course, those numbers are just based on my experience, and I’m sure the team can come up with even better thresholds through data and testing.

Avatars may contain GameObjects that are used only locally. For example, camera extensions and inventory systems based on Avatar Dynamics. I think that they should be excluded from performance rank calculation if they are always disabled in remote environments. I know that it is hard to determine which objects are local by inspecting animator controllers. My proposal is based on explicitly marking and runtime content modification to avoid animator inspection. Mark local objects as "local only" by tag or custom component. Remove marked objects while loading avatars as with camera components in avatars used by non-friends. This feature makes the performance rank system more accurate and reasonable. It will help to motivate developers to optimize their avatars.

Interpolating float parameters locally could smooth out stuff like face tracking, which suffers from the current low update rate. Right now people use perf-costly animators to interpolate their face tracking manually.

We can already add a constant value to our parameters, but being able to add the values of two parameters together would be very helpful!

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