Avatar Bugs & Feature Requests

I currently use MANY IK components in my avatars. (This is due to an issue with Avatar Scaling that I have posted about here: https://feedback.vrchat.com/avatar-30/p/vrik-and-grounders-with-avatar-scaling ) I recently found what appears to be a limit to the maximum number of IK Components allowed on an avatar. At roughly 90 IK Components, some IK Components seem to stop calculating entirely. Please confirm what the maximum limit.

I think it would be very helpful to be able to use copy parameter drivers to copy the VRC-Exposed (GestureRight/GestureLeft/etc) parameters to other parameters. A bit of an edge case, but there are some situations where converting parameter types of these parameters can be very helpful

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)

Remove the 10mb limit for quest avatars. Add an option for the user to select whether they want to download an avatar larger than 10mb or not. Easy solution.

(Original title: Broken performance rank) Ingame, in the SDK, and according to its stats, this avatar is ranked Poor on PC. For some reason, the rank is Very Poor everywhere else, like parts of the avatars menu and on the website. https://vrchat.com/home/avatar/avtr_ed1ab946-0bcc-4d14-b1c4-77fcc2f1b55a The VCC and SDK are the latest version as of right now.

On a Avatar's body Skinned Mesh Renderer, if you set the "Cast Shadows" option to "Shadows Only", the mesh will only be invisible to Remote players, Cameras and Mirrors, while always being visible to the Local player. This makes creating effects that can only be seen in shadow harder to do as the person who wears the avatar will always be able to see the mesh when we want it to be invisible.

This is a follow up to the following cannies: [BUG] VRC Avatar Parameter Driver does not work for a few frames after avatar loading https://vrchat.canny.io/avatar-30/p/bug-vrc-avatar-parameter-driver-does-not-work-for-a-few-frames-after-avatar-load [Bug] When other players load an avatar faster than the avatar wearer, the expression parameters can have unintended values which may cause clothes to disappear for a split second https://vrchat.canny.io/avatar-30/p/bug-when-other-players-load-an-avatar-faster-than-the-avatar-wearer-the-expressi As an avatar creator, I would like to know when the Avatars 3.0 system is loaded and ready to go, so that I can execute state machines that are sensitive to avatar loading conditions at the right moment. My proposal is to add a new bool parameter that is True whenever Avatars 3.0 is ready to function. When that parameter is True, then the Avatar creator can assume that the following assertions are true: When true, it should be assumed that Avatars 3.0 system has successfully loaded for the person who is wearing the avatar, even in the case when other players load the avatar faster than the avatar wearer. When true, it should be assumed that all of the Expression Parameters of the newly loaded avatar have synced at least once with the expected values for remote players -- that is, that bool remained false for as long as the avatar wearer has not loaded the avatar yet nor synced the correct Expression Parameter values. When true, it should be assumed that Animator Behaviors such as Drivers are going to work properly once we enter a new state that has one. When true, it should be assumed that Animator Parameters like IsLocal, VRMode, TrackingType have a defined and stable values that are unlikely going to change afterwards. This may help solve the following cases for avatar creators: On some logic layers, this allows evaluating the rest of the state machine at the right moment, triggering Driver behaviors (i.e. random number generators, etc.). On some layers, this could allow a temporary stopgate in order to enter the correct state machine that matches the user's TrackingType and VRMode. If a layer needs to handle the case where Expression Parameters have a default value that is not 0 or that is not false, this prevents the animator from carrying on until the Expression Parameters have been synced by the avatar wearer. This also avoids having to wait for an unreliable arbitrary number of frames.

The value of GestureLeftWeight and GestureRightWeight are not interpolated for remote players. For example, if the GestureLeftWeight value is used as the Normalized Time parameter to change a face expression from eyes open when GestureLeftWeight is equal to 0.0 to eyes closed when GestureLeftWeight is equal to 1.0, then when slowly squeezing the trigger while doing a fist: We observe that: Locally, the eyes will smoothly close Remotely, the eyes will suddenly jump through several positions without interpolation while closing We expect that: Locally, the eyes will smoothly close Remotely, the eyes should smoothly close

In Unity's Standard shader, the _OcclusionStrength parameter multiplies the "influence" of the Occlusion texture on ambient light. Standard Lite's occlusion slider currently multiplies the texture itself, meaning that AO has 100% influence when the slider is 0, rather than 0% like in regular Standard.

When using upper body camera tracking, if you use a mascot-type avatar with a large head, the face mirror target becomes too low and your stomach or neck will be reflected. I would like to stream camera tracking with a mascot-type avatar from my desktop, so please fix this!