Avatar Bugs & Feature Requests

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 would like to see the VRC Avatar Parameter Driver functionality extended or a new State Behaviour that implements four arithmetic operations between parameters. It would be great if you could also add a function that allows exception handling by specifying a parameter of any bool type when a calculation result overflows or divides by zero. Another feature that would be very useful would be to add a State Behaviour that outputs the results of comparisons between Animator Parameters to a specified bool parameter. We believe that implementing these functions will enable more complex expressions and increase the readability of Animator compared to the implementation method using BlendTree, so please consider it. (The translation was done using Deepl and may contain unnatural expressions.) VRC Avatar Parameter Driverの機能拡張、もしくは新規のState Behaviourとしてパラメーター同士の四則演算を実装して欲しいです。 計算結果がオーバーフローした場合やゼロ除算が発生した場合に、任意のbool型のパラメーターを指定して例外処理などを行うことが可能な機能も追加していただけると嬉しいです。 そしてもう一つ、Animator Parameter同士の比較の結果を指定したbool型のパラメーターに出力するState Behaviourも追加していただければ非常に便利になると考えております。 これらの機能を実装することでより複雑な表現が可能になり、BlendTreeを用いた実装方法よりもAnimatorの可読性が上昇すると考えていますので、ぜひご検討ください。

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.

Currently, if you are using VRIK (often used for followers and quadrupeds) or IK Grounders (often used for laser pointers, guns, placeable objects... ect) there are many parameters that cannot be adjusted at all when your avatar scales larger and smaller. To my understanding, this is due to a limitation with how Final IK is configured. These parameters are not allowed to be animated in the editor and are expected to be adjusted via code when implemented in games. As such, my current solution is to include SEVEN copies of each of these scripts and toggle between them based on my current height. This is very inefficient. Attached are some screenshots of the current setup and the specific variables that need to be adjusted. This is not a comprehensive list, just the specific variables that I am referring to in this request. This request is to either automatically scale these values based on avatar height, or to provide us a way to control these values.

I would like to propose the addition of native parameter smoothing functionality within VRChat, directly supported by the VRChat client and SDK. Currently, creators must rely on animator-based feedback loop smoothing to mitigate the slow network update rate of float parameters, particularly for advanced use cases such as full face tracking. However, this approach introduces significant inefficiencies and complexity. Feedback-loop smoothing via animator logic results in extremely bloated and overly complex animators. This not only complicates the animation setup process, but also has measurable negative performance impacts. Based on my own testing and benchmarking, a single avatar using full facial tracking with feedback-loop smoothing can increase CPU frame times enough to cause a 5–10 FPS drop in CPU-limited environments, with mirrors disabled. It is 100% reproduceable especially with OSCmooth and Pawlygons facetracking templates. This is purely based on the smoothing logic only, not the actual facetracking logic. The performance degradation scales linearly with the number of face-tracked avatars present in a given instance. This makes the current approach unsustainable, especially as more users adopt advanced tracking setups. I propose that VRChat introduce native parameter smoothing functionality configurable directly through the VRChat Unity SDK. This could be implemented by expanding the existing animator parameter list interface in the SDK to include: A checkbox to enable native smoothing on a per-parameter basis. Two smoothing strength values, ranging from 0.0 to 1.0: Local Smoothing: Applied to the user's own view of their avatar (e.g., for responsive and accurate feedback). Remote Smoothing: Applied to how other users see the avatar (e.g., to compensate for low parameter update frequency over the network). This native implementation would eliminate the need for animator-driven smoothing workarounds, significantly reduce complexity, and greatly improve performance across all facetracked avatars moving forward, especially in CPU-constrained scenarios (me 99% of the time, same can be said for most people nowadays). Such a feature would improve performance by a very measurable amount once it becomes standardized over the current hacky avatar-based feedback-loop method. It would also have huge positive implications for Mobile/Quest as they are much more CPU restricted, yet don't have any facetracking/animator limitations at all. We need more tools to optimize animators, and this would be a great step forward, thank you.

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

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!

I've found that contact receivers that are looking for a "Hand" contact have odd behavior. If you enter the contact with any part of your hand, it works as expected, but if a single finger gets removed from the contact, the contact will act as though the entire hand was removed from the contact, even if the rest of the hand is still present in the contact. This was tested with a constant contact that drives a bool parameter. This bug may lead to unusual effects with avatars that need a hand's constant presence, but the receiver isn't fixed onto the hand.

Of all the Default Av3 Parameters, I am in need of one that doesn't exist, Eye Rotation. This would be especially useful for animating 2D texture Eyes. I would like a Float for Vertical ranging from -1 to +1 and Horizontal -1 to +1. Perhaps name it "EyeRotationX" and "EyeRotationY"? Also a Bool for Randomized Blinking would be a nice-to-have, but not as important as that can be animated