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.

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)

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

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!

This odd error was found while using VRCFury on an asset I was "expanding" on. In short. The asset had 8 duplicates, each with their own ID, in turn the parameters are the same, with the exception of the last bit being their respective IDs. Ex: PiShock/Equipped/10 If you create a Menu Option as a, say Radial, gave it a parameter that either Currently Exists but later removed, or, never existed. Then change that Menu Option to a Toggle and set a different parameter, which does exist. The old parameter resides in the Menu's file (when viewed in Notepad, my case of image being Notepad++). Though I cannot say this would effect VRChat's Avatar SDK on a Vanilla level, it is hard to trace back when third party tools, like VRCFury, report that /7 is in use on the /10's menu file, yet in Unity it's not visually seen. Switching the Toggle to Radial or 4 axis, will show the incorrect parameter, which you can just simply delete, set back to Toggle, and all is fine. Though there can be multiple solutions, something to help show the old parameter still resides in the Menu Option, or maybe when the Type is changed, remove the old? I'm not entirely sure the best method to resolve the odd lingering parameters in the Menu files. The only way I was able to find this, was opening the Menu file in Notepad, and Ctrl+F the /7. When I reported this in VRCFury's discord, I was informed this same issue came up for another user back on June 6th, when said user duplicated a clothing asset, changed menu types, and resulted in errors for parameters that "shouldn't exist" in their duplicated asset's menu files.

I'm encountering an issue where my Android-compatible VRChat avatar, created using VCC3. and SDK3.8.1*, is not visible to myself or other users when I access VRChat via my Quest. Conversely, avatars I've created with VCC3. and SDK3.7.* or VCC4. and SDK3.8.1 display correctly. This suggests that updating VCC may resolve the visibility issue for affected avatars. Below is a relevant log entry from a friend who experienced this error: Error - [Behaviour] Error downloading avatar MURIYARIYUKATA/Security: Error loading asset bundle from ****: HTTP/1.1 403 Forbidden

Since a few months, it seems that the security checks fails when uploading an avatar with tracker module audio files. Before it was fine and working in game. > Unity supports the four most common module file formats, namely Impulse Tracker (.it), Scream Tracker (.s3m), Extended Module File Format (.xm), and the original Module File Format (.mod). Steps to reproduce : Create a new avatar project Add SDK sample avatar Add a new audio source and use a module audio file (from modarchive.org for example) as the AudioClip Upload the avatar Security checks will fail instantly Sample avatar that failed security checks : avtr_aebe3694-2da8-44bf-bec1-fbad6c48bdf4