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

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!

I'm aware that we have the avatar scaling parameter exposed and can use them to drive other things, but the ability to do the opposite would be incredibly useful. Example case: I have an avatar that has a werewolf transformation. Ideally, part of the effect would be having the avatar slowly grow from 1.47 meters to 2.2 meters tall. Currently, this is impossible as setting parameter drivers to the scaling parameters do nothing ingame (even though they work fine in editor) Avatar scaling is already something we have direct control over in our menus. There is no reason we should not be able to write directly to the parameters themselves.

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.

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.

Avatars can have 2D (global) audio sources on them, these can be quite disruptive at times. To make instance moderation easier, it would be nice to have an avatar overlay that shows at least the active, if not all, avatar audio sources.

First of all, I know a major point of this update was Avatar Performance recalculation- but I can confirm it's very incorrect. I've handcounted Material Slots and tried reuploads of exact avatars and been met with exact data size yet completely different calculations of VRAM, Avatar Bounds, and most abundantly, Material Slots. It seems like every avatar I've uploaded has suddenly gained +1 Material Slot, despite both handcounting and VRChat's SDK's calculations. Examples: A Pokemon-Esque commission I did has a reported 32 Material Slots, ~118 mb VRAM, and no animated bounds at less than 2m per side (is smol.) These would Parallel the SDK within VRChat, and give perfectly symmetical in-game data. On Build 1695 a version of the avatar uploaded in March 2025 reports 18 Material Slots, 129.98 mb VRAM. The bounds are insane at 2860.40 per side. I double-checked, no avatar bounds are animated. However, a version of the exact same avatar (with no modifications) uploaded today, August 29th 2025 12am EST reports 33 Material Slots, 129.98 mb VRAM, and ludicrous asymmetrical bounds at 4798.35, 798.61, 1002.50. Once again, nothing abnormal within the avatar and nothing reported in within the SDK. And once again, absolutely nothing avatar-bounds related is animated- in fact, ERASING the FX and Action layered Animator Controllers does not change the Avatar Report at all. All enabled objects are found within range of the object. And no other animator controllers are present within the avatar's hierarchy. VRAM, Material Slots, and Bounds are all found to be calculated incorrectly. This issue is present on 20+ and counting separate uploads of avatars. Some have skyrocketing VRAM peaking 300+ MB post-update despite Windows platform overrided DXT1 and DXT5 Crunch Compression, some have +1 to +2 Material Slots. Some have -12 to -14 Material Slots. Some have astronomical bounds despite all instanced renders being online/enabled at once, reporting within the SDK being less than 5x6x5, and with not one animation affecting their transform. In other findings, deletion/negation of Animations providing Material Swaps as a functionality on Particle Systems, Mesh Renderers, Skinned Mesh Renderers, and Trails do not affect the miscalculation of "Material Slots", Bounds, nor VRAM. Nothing changes within avatar performance on deletion of their animator controllers besides download size. Most likely being the deletion of referenced Animation File Size. Another Example can be found on my Twitter: https://x.com/speedbuiz/status/1961261519640940710 Please do not dismiss this as my fault. I've posted to the canny before and been given the cold shoulder and ignored. I can confirm with multiple hours of discovery that these avatar performance calculations are completely incorrect. I expect there to be more abnormalities than just VRAM, Material Slots, and Bounds. Please reply with any discoveries, and please upvote this problem so VRChat can assist their Avatar Creators.

As of June 24th 2025, VRChat 2025.2.3, build 1664, Avatar previews that I have spent hours fixing have been rebroken. In the latest particular case, my suspicion is the patch note "Avatars will now update constraints before they are scaled to fit in the preview UI." I was intentionally utilizing constraints in the preview pose animation to manipulate the scaling in the preview UI by not updating the constraint until after it was calculated. For example, in the second attached image, I was intentionally uploading the model with the arm at origin because somehow the mesh of the right arm would cause the preview to calculate the scale incorrectly, so I used constraints to restore the arm after calculations. The only remaining method I believe to resolve this Avatar Preview would be to pre-pose the resting pose of the .fbx in blender to have the arms down at her sides, but although the humanoid rig still functions, applying that armature modifier then causes the shoulders and so on to behave fundamentally different with IK as the arms are lifted again via locomotion/IK. I have gone back and forth with Fax (who recommended opening this canny) and other internal members for insight, and here's an overview of everything I know about avatar menu previews and what I've done to workaround them over the last few months to shed some light on what we've tried. ----- The menu preview is based on not just the unity bounds of the avatar, but more specifically the bounds that VRChat calculates during the first frame including your animators and any logic they perform (supposedly). Therefore things that may contribute to this (and multiple things may be contributing) Unity Bounds of an Avatar (like its meshes) FBX Bounds of an Avatar (like out of blender, including "exploding shapekeys" used for programs like Substance Painter) Positions of Gameobjects (such as like empty gameobjects that are floating around your avatar too far) And whether those things may or may not be animated on or off at runtime during the first frame ----- For example on our other AVM model, it had 3 underlying issues that each individually caused the preview to break so I had to find and fix each one The FBX uploaded literally by itself had a small preview. Solution: Posing the arms straight down like a pencil pose image.png The Blade in the left hand even existing broke the bounds. Possibly because in blender it was sideways at origin. I didn't want to go edit it in blender. Solution: I disabled for a few frames in the preview clip at the beginning before reenabling it for it to dissolve in I had a series of arbitrary empty gameobjects used as constraint sources that hovered around my body in a large area Solution: I scaled the root of the objects to 0, so all of its children that were scattered around your body all condensed into a single point, and i rescaled it back to 1 at runtime via animation ----- For the current problem avatar at hand (attached images), the primary issue we had was that the right cyberarm (which uses a duplicate armature) for some reason its mesh at tpose triggers the menu preview to shrink because I guess VRC thinks its horizontal bound was too big. Since this arm is still the same size of an arm and same mesh, but just on a duplicate armature, it seems that VRC treats parts of the mesh weightpainted to non-humanoid bones differently than to humanoid rig bones. The previous solution: I had to upload the avatar like this and use constraint animations to repair the arm at runtime. Latest VRChat update breaks this solution, as it seems to calculate the constraint regardless of when it is animated (even beyond the 1st frame bounds calculation) prior to applying the preview scaling. ----- Overall, please advise what can be done to work around these avatar preview menu issues, or implement some fixes/offer some alternatives to manipulate these avatar previews more consistently. It can be frustrating enough to constantly upload and iterate to test these previews alongside another current avatar preview bug where previewing the same avatar at different times can yield inconsistent sizes (which I'll open a separate canny about and link here)

Right now you can only have a parameter driver act instantly, instead of being able to spread the change out over time like you can with the animator layer controller. This means that if you want a change in a parameter to be gradual you essentially have to create a loop that adds a tiny amount to the parameter over and over again while counting up until it's added enough times, which probably isn't great for performance and looks stuttery.