Avatar Bugs & Feature Requests

With the new Native FT update, windows build 1937, I've been having an issue where remote clients see my avatar's eyes with set random offsets. Locally, everything is 100% perfect all the time. Only remotes have this offset issue. After tracking the issue down, I've found that if I disable Eye Look completely in the VRC Avatar Descriptor, the offset no longer happens on remotes. (See included VRC Desc picture for broken version) It appears if you drive your own eye look bone rotations in your own animator while Eye Look setting is enabled (even with Eye-gaze field set to Face Tracking ), an offset is applied to remotes when your avatar is loaded in. Possibly an additional problem that I have 'none' set as my eye bones (defaulting to use Unity-Avatar's set Eye Bones when none?) If I had to guess, when the remote loads in your avatar, the stimulated Eye-Gaze functionality is on by default applying bone rotations and/or Eye Look param value changes. Then, the avatar is initializes with its networked params. Which freezes the simulated Eye-Gaze baking that offset into the remote user's avatar. This offset may be baked into the bone rotations, or the Native FT Eye Look parameter itself. If this issue is an intended conflicting behavior, perhaps a warning help-box in the VRC Avi Desc and an additional note in the documentation, would really help. Reproducible by: Use an avatar that uses bone rotations for its eye tracking. (you can use my linked avatar) Enable Eye Look with Face Tracking Eye-Gaze setting enabled. Drive your eye rotations via Native FT Eye Look params. Join a world with another remote user. Have the remote user observe the potential offset in the positions of the eyes. Included video: Note how when I switch avatars, the Remote eyes are completely different than the local. Including the ears rotations as they are also driven by Native FT Eye Look params. This public avatar uploaded with Eye Look enabled demonstrates this issue well. (yeah its creepy xD Just a stripped down version of my avatar): https://vrchat.com/home/avatar/avtr_b1e1f772-1b05-4556-965c-1ddeb5a8a0fc

Yes I do think NSFW avatars should be marked with those tags when uploading so they can be hidden by those settings. I always do this and if you want to make an even more extreme NSFW tag rather than just sexually suggestive that would be fine too. But punishing users for using an avatar that has nsfw features in a public instance even if they didn't use those features makes no sense. I understand moderation is hard, and there are issues with how publics tend to be, but overpunishing things that don't hurt anything isn't the answer. My voice is capable of saying slurs that could get me banned, but you don't ban me for having my mic on. You ban me if I DO THE ACTION that's against the rules. If you feel like you'd need to do something else more extreme like only showing my avatar marked with that to people who are verified 18+ then okay but you're gonna need to make that system better because it's not good right now. See all the feedback on that

i have an avatar https://vrchat.com/home/avatar/avtr_27372c1f-eece-4d6b-8685-cd3018b22e40 when built on the latest stable SDK (3.10.6) the rotation constraint chain system i have set up to puppet limbs with my arms does not sync for remote users. [EDIT: by this, i mean the constraints do not seem to be functioning at all for the limbs, as remote users view them as pointing straight out]. this issue does not occur if the avatar is built on the previous stable build (3.10.5). EDIT 2: I have found, after further testing, that this bug only is occurring when i have my visemes set up to face tracking blend shapes and have face tracking enabled.

If a person wearing an avatar opens their mouth all the way, other players observing them will see their mouth close again once it reaches 100%. This seems to affect any avatar with native FT either with full FT or driving via visemes. VRChat Build: 2026.4.1p1-1937-299983b13b-Release

Some of my avatar's toggles are being forced on for my friends, while on my side the toggles are either off or something else is toggled on that would normally toggle off that toggle. Strangely the desync only happens on PC to PC, and not PC to Quest. The toggles in question are the Harness Panties, and the Harness Bra. They are on by default, and I think that might have something to do with why they are forced on for other PC users. This also affects the other underwear toggles since when I toggle one of them on, the only thing other people see is the default ones. Flat out taking them off also does nothing for other people (besides Quest users), so I think it's an issue with the On/Off state of the parameter forcing it to be on for other PC users. Before the update, I didn't have this issue, so I know it isn't something on the avatar's end. I will link the avatar and worlds used during testing below. Avatar: https://vrchat.com/home/avatar/avtr_454e63af-eed0-4c39-8c46-51f21268173b Worlds: https://vrchat.com/home/world/wrld_8d740b03-93a4-4153-99de-9fd67d86d4ae/info https://vrchat.com/home/world/wrld_1ddfdbb6-b972-4d88-8ee9-aee00c6c75a0/info https://vrchat.com/home/world/wrld_e0434a34-2f64-4e89-99da-8e3b4a86ffe4/info In order to recreate this desync, you'll need two PC users. As the one wearing the avatar, turn off, or equip something that would turn off the Harness Panties/Bra, such as another underwear item which can be found by going to Toggles->Closet->Bottoms or Toggles->Closet->Tops->Page 2. On the other PC user's end nothing will happen, but on the avatar wearer's end, the toggle will work as intended. You may want to take off the default bodysuit for a better view, since they blend in with each other heavily. It can be found under Toggles->Closet->Bodysuits. I'd also reccomend taking off most of the accessories that it has by default, found in Toggles->Closet->Accessories since it can cause lag on lower end devices.

Avatars uploaded to meet custom fallback requirements cannot be selected as custom fallbacks from the website UI. Although the deprecation of fallbacks is listed (and active posts on these feedback forums indicate opposition to their removal), I have not been able to find any information about custom fallbacks not being uploadable anymore. Selecting a fallback from in-game has been removed some time back and outlined in an update post, but there is nothing about new avatars uploaded to be elligible as fallbacks being removed. As such, I assume this is a bug. docs.vrchat.com still lists custom avatar fallback creation process, and the avatar SDK upload panel still lists a notice about an avatar being elligible for fallback or not. Public avatars uploaded a while back, even if uploaded recently, by people I know (and which are not earmarked by VRC as fallbacks, e.g. CZ) are still selectable. It seems only newly created avatars are not selectable. Documentation and the SDK are incorrect, and if this is a known change that was not announced, this is extremely misleading and I think does nothing positive to the game whatsoever. Although impostors provide an effective, low-effort "quick fix" to avatar performance blocking, they are absolutely not a substitute to the very competent fallback system which incentivizes those who care to create much more optimized versions of avatars at substantially higher qualities than impostors could ever achieve. The feature still existing for avatars uploaded just a bit before is also annoying, as the system clearly remains in place and functional. Clarification on whether this is a bug or a known change would be greatly appreciated. Indication about whether Support can assist with making an avatar a fallback manually would also be appreciated.

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.

-- Summary of the Issue -- GestureRightWeight and GestureLeftWeight only work with Fist gesture. For all other gestures, they return fixed values (Neutral: 0.0, others: 1.0). Additionally, GestureRightWeight and GestureLeftWeight return the amount of Grip button pressed, not Trigger. -- Request -- I would like to be able to obtain the pull amount of the Trigger (the button on the index finger side of the Quest 2 controller) as a float value. -- Environment -- Quest 2 (PCVR) VRMode: 1 TrackingType: 3 (HMD + hand controllers) --- To validate the behavior of these parameters, I displayed the Debug window and tested various gestures. Extra menu > Options > Config > Debug While testing hand gestures, observe the values of Parameters > GestureLeftWeight and GestureRightWeight. The results were as follows: Gesture 0 (Neutral): Fixed at 0 1 (Fist): Varies between 0 and 1 2 (HandOpen): Fixed at 1 3 (FingerPoint): Fixed at 1 4 (Victory): Fixed at 1 5 (RockNRoll): Fixed at 1 6 (HandGun): Fixed at 1 7 (ThumbsUp): Fixed at 1 --- The weight parameters responded to the Grip (button pressed with the middle finger on the Quest 2 controller). Even if we obtain the weight of Grip, it is unnatural that parameters do not change based on pressing for gestures other than the fist (FingerPoint, HandGun and ThumbsUp). Additionally, the fact that the press amount is fixed at 1.0 for gestures where the button is not touched (HandOpen, Victory and RockNRoll) is contradictory to the documentation. Despite not pulling the Trigger, the parameters treat it as if the Trigger is pulled, which is inconsistent. As a request, I would like the ability to obtain the Weight for the Trigger on the index finger side, irrespective of the type of gesture, while maintaining the ability to obtain the Grip parameter on the middle finger side. Being able to obtain the Trigger's Weight would enable the implementation of actions equivalent to "Use" in world gimmicks in avatar gimmicks. --- (原文) -- 不具合の概要 -- GestureRightWeight, GestureLeftWeightはfistのモーションでのみ機能しています。 それ以外のジェスチャーでは固定値(Neutral: 0.0, others: 1.0)を返します。 また、GestureRightWeight, GestureLeftWeightはTriggerではなくGripの押し込み量を返します。 -- 要望 -- トリガー(Quest2コントローラーにおける人差し指側のボタン)の押し込み量もパラメータで取得できるようにしてほしい -- 環境 -- Quest 2 (PCVR) VRMode: 1 TrackingType: 3 (HMD + hand controllers) --- これらのパラメータの動作を検証するためにDebugウィンドウを表示して一通りジェスチャーを試しました。 Extra menu > Options > Config > Debug ハンドジェスチャーを試しながらParameters > GestureLeftWeight, GestureRightWeightの値を観察します 結果は以下の通りでした。 Gesture 0(Neutral): 0固定 1(Fist): 0 -- 1の間で変化 2(HandOpen): 1固定 3(FingerPoint): 1固定 4(Victory): 1固定 5(RockNRoll): 1固定 6(HandGun): 1固定 7(ThumbsUp): 1固定 weightはGrip(Quest2コントローラーの中指で押すボタン)の方に反応していました。 --- Gripの重みを取得するとしてもfist以外(FingerPoint, HandGun, ThumbsUp)では押し込み具合に応じてパラメータが変化しないのは不自然です。 また、そもそもボタンに触れていないジェスチャー(HandOpen, Victory, RockNRoll)において押し込み量が1.0に固定される点も、トリガーを引いていないのにも関わらずパラメータ上はトリガーを引いている状態として扱われ、ドキュメントの記載内容に反します。 要望としては中指側のGripのパラメータ取得を残したうえで、ジェスチャーの種類に関わらず人差し指側のTriggerでもWeightを取れるようにしてほしいです。 TriggerのWeightが取得できることによりワールドギミックにおける"Use"にあたる動作がアバターギミックに搭載できるようになります。

I suggest "VRChat/Mobile/Particles/Alpha Blended" be relabeled to "VRChat/Particles/Alpha Blended" specifically for the Avatar SDK to reduce confusion regarding Quest compatibility. you shouldn't have the Worlds and Avatars SDKs installed at the same time and the shader is not bundled with the avatar package, so I cannot imagine its path being different causing any issues.

While working on animations scaling with the new avatar scaling parameters I noticed a issue. the VelocityX and VelocityZ were being clamped between -4.17 and 4.17 even though the avatar is moving much faster. https://www.youtube.com/watch?v=C_kmAlCxHOM