Avatar Bugs & Feature Requests

Repro steps: Switch to this avatar https://vrchat.com/home/avatar/avtr_e5397650-0897-4662-87b4-07ea060ab5f2 Add an accessory to "jaw.Upper", shown in the image Apparently it gets angry at long hierarchy paths.

SUMMARY The SDK's default Additive controller (vrc_AvatarV3IdleLayer) has a single layer whose blending mode is Additive, and both of its states ("Upright Idle" and "Empty") are Write Defaults OFF. When no WD OFF state in a playable layer above Additive covers it, every shape key that - is bound by some clip in the avatar's playable layers, and - has a non-zero value on the SkinnedMeshRenderer is shown at 3x its value (30 becomes 90). We observed this in the VRChat client on an affected avatar, and reproduced it with the minimal steps below in Gesture Manager. Setting only the Additive controller's states to Write Defaults ON fixes it, without changing the idle body motion. STEPS TO REPRODUCE Environment: Unity 2022.3.22f1, VRChat SDK Avatars 3.10.4, Gesture Manager 3.9.9 Use any humanoid avatar. On its face SkinnedMeshRenderer, set any shape key to 30. Create an FX controller with one layer (weight 1) containing two states: - "Idle" (default state): an empty clip, Write Defaults ON. - "Shape": a clip that animates that shape key, Write Defaults ON, with no transitions into it (it never plays). Assign this controller to the FX slot. Copy vrc_AvatarV3HandsLayer.controller (Packages/com.vrchat.avatars/Samples/AV3 Demo Assets/Animation/Controllers/) into Assets, turn Write Defaults ON on every state, and assign it to the Gesture slot. Leave Base, Additive, Action, Sitting, TPose and IKPose at their defaults. Play, stand idle, make no gesture. Expected: 30 Actual: 90 Copy vrc_AvatarV3IdleLayer.controller (same folder) into Assets, turn Write Defaults ON on both of its states, and assign it to the Additive slot. Actual: 30. The idle body motion is unchanged. Notes: - Only shape keys that some clip in the playable layers binds are affected, even if that clip never plays. - A value of 0 stays 0. - Base does not matter. - The error is hidden while any WD OFF state plays above Additive: the default Gesture controller, a WD OFF FX, or Action at weight 1 during an emote or AFK. This is why most avatars never notice it. WHY IT HAPPENS A WD OFF state asserts every animated binding of the avatar. For the bindings it does not animate itself, it fills in its held (bind-time) value. On the Additive input, which is additive, that dense pose is added on top of the lower layers twice: - once through the additive playable input, and - once more through the additive layer blend. So a shape key the Additive layer never touches still gets its default value added twice: d + 2d = 3d With an empty (zero-curve) clip in the same state, the value does not settle; it keeps growing every frame. WHY WD ON IS SAFE FOR THIS CONTROLLER We compared Additive = default (WD OFF) against a WD ON copy in every combination of: - Base: WD OFF / WD ON - Gesture: WD OFF / WD ON - FX: WD OFF / WD ON / mixed per layer - Action weight: 0 / 1 That is 24 configurations, 300 frames each, checking all 54 humanoid bones and the root. The idle clip was a muscle-only additive clip that moves the body by up to 8 degrees. Results: - Shape keys, Additive WD OFF: 3x whenever Gesture and FX are WD ON and Action is at weight 0. 1x otherwise. - Shape keys, Additive WD ON: 1x in all 24 configurations. - Humanoid motion: identical in all 24 configurations (0 degrees / 0 m difference between WD OFF and WD ON Additive). Humanoid muscles are applied as a single human pose, which Write Defaults does not affect, so the idle motion does not depend on this setting. On WD OFF avatars the change is invisible. On WD ON avatars it removes the error. Tools already apply this fix: VRCFury's "Fix Write Defaults" option marks all additive states WD ON. REQUEST Please set Write Defaults ON on both states of the SDK's default Additive controller, and on the client's internal equivalent if it mirrors the SDK asset. RELATED "[BUG] VRChat apply blend shape values 3 times" (2020, marked fixed) has the same symptom. The cause described here is in the default controller asset. https://feedback.vrchat.com/avatar-30/p/bug-vrchat-apply-blend-shape-values-3-times ------日本語------ 概要 SDK 既定の Additive コントローラ（vrc_AvatarV3IdleLayer）は、合成方式が Additive のレイヤー 1 枚だけでできていて、その 2 つのステート（"Upright Idle" と "Empty"）はどちらも Write Defaults OFF になっている。 Additive より上の Playable レイヤーに、これを覆う WD OFF のステートが無いとき、次の条件を満たすシェイプキーがすべて、その値の 3 倍で表示される（30 が 90 になる）。 - アバターの Playable レイヤー内のどこかのクリップが bind している - SkinnedMeshRenderer 上の値が 0 でない 問題が起きるアバターで、VRChat クライアント上での発生を確認した。また、下記の最小手順で Gesture Manager 上でも再現した。 Additive コントローラのステートだけを Write Defaults ON にすると、idle の体の動きを変えずに直る。 再現手順 環境: Unity 2022.3.22f1、VRChat SDK Avatars 3.10.4、Gesture Manager 3.9.9 任意の人型アバターを使う。顔の SkinnedMeshRenderer で、任意のシェイプキーを 30 にする。 レイヤー 1 枚（weight 1）の FX コントローラを作り、ステートを 2 つ置く。 - "Idle"（既定ステート）: 空のクリップ、Write Defaults ON - "Shape": そのシェイプキーを動かすクリップ、Write Defaults ON。ここへの遷移は作らない（再生されない） このコントローラを FX 枠に割り当てる。 vrc_AvatarV3HandsLayer.controller （Packages/com.vrchat.avatars/Samples/AV3 Demo Assets/Animation/Controllers/） を Assets にコピーし、全ステートの Write Defaults を ON にして、Gesture 枠に割り当てる。 Base、Additive、Action、Sitting、TPose、IKPose は既定のままにする。 再生し、ジェスチャー無しで立ったままにする。 期待値: 30 実際: 90 vrc_AvatarV3IdleLayer.controller（同じフォルダ）を Assets にコピーし、2 つのステートの Write Defaults を ON にして、Additive 枠に割り当てる。 実際: 30。idle の体の動きは変わらない。 補足: - 影響を受けるのは、Playable レイヤー内のどこかのクリップが bind しているシェイプキーだけ。そのクリップが一度も再生されなくても対象になる。 - 値が 0 のものは 0 のまま。 - Base は関係しない。 - Additive より上で WD OFF のステートが再生されている間は、誤りが覆い隠される。既定の Gesture コントローラ、WD OFF の FX、エモートや AFK 中で weight 1 の Action がこれに当たる。多くのアバターで気付かれないのはこのため。 原因 WD OFF のステートは、アバターがアニメーションしている全 binding を主張する。自分がアニメーションしていない binding は、保持値（bind 時の値）で埋める。 Additive の入力は加算なので、この「密なポーズ」は下位レイヤーの上に 2 回足される。 - 1 回目: 加算の Playable 入力として - 2 回目: 加算レイヤーの合成として そのため Additive レイヤーが一切触らないシェイプキーにも、既定値が 2 回足される。 d + 2d = 3d 同じステートに空の（カーブ 0 本の）クリップを置くと、値は落ち着かず、毎フレーム増え続ける。 このコントローラを WD ON にしても安全である理由 Additive = 既定（WD OFF）と、WD ON のコピーを、次の全組み合わせで比較した。 - Base: WD OFF / WD ON - Gesture: WD OFF / WD ON - FX: WD OFF / WD ON / レイヤーごとに混在 - Action の weight: 0 / 1 計 24 構成、各 300 フレーム、人型の 54 ボーンすべてとルートを確認した。idle のクリップには、体を最大 8 度動かすマッスルだけの加算クリップを使った。 結果: - シェイプキー、Additive WD OFF: Gesture と FX が WD ON かつ Action の weight が 0 のとき 3 倍。それ以外は 1 倍。 - シェイプキー、Additive WD ON: 24 構成すべてで 1 倍。 - 人型の動き: 24 構成すべてで一致（Additive の WD OFF と WD ON の差は 0 度 / 0 m）。 人型のマッスルは「1 枚の人体ポーズ」として適用され、Write Defaults の影響を受けない。そのため idle の動きはこの設定に左右されない。 WD OFF のアバターでは変更は見た目に表れない。WD ON のアバターではこの誤りが消える。 この修正は既にツールでも行われている。VRCFury の "Fix Write Defaults" オプションは、加算レイヤーの全ステートを WD ON にする。 要望 SDK 既定の Additive コントローラの 2 つのステートを、Write Defaults ON にしてほしい。クライアント内部の同等品が SDK のアセットと同じなら、そちらも。 関連 "[BUG] VRChat apply blend shape values 3 times"（2020 年、修正済みとして完了）は症状が同じ。ここで述べる原因は、既定コントローラのアセットにある。 https://feedback.vrchat.com/avatar-30/p/bug-vrchat-apply-blend-shape-values-3-times

I have an avatar that uses rotation constraints on twist bones for the elbows and forearms so that the elbow joints have correct rotation, but for some reason, specifically with the imposter, the forearms are dislocated. I assume this is because of those constraints, and may be due to the environment it's calculated in when the imposter is generated. The avatar works just fine otherwise.

With the recent-ish change that makes particle lights correctly count towards your total light count, I noticed a possible discrepancy with the total count. Steps to recreate: Add a Particle System to the avatar In the Particle System, scroll down to Lights Create a Point Light in the scene but outside the avatar Create a prefab of the Point Light Insert the Point Light prefab into the Light slot inside the Particle System Limit Maximum Lights to 1. Upload to VRChat Observe avatar details of avatar. Lights will be listed as 2/1 Example of an avatar that only has 1 Max Particle Light on the entire avatar but is listed as 2/1 lights in the avatar details https://vrchat.com/home/avatar/avtr_7c80a2a5-3473-421f-86ce-fdda8fa8eb3f Expected behavior: Lights should be listed as 1/1. Though I expect the 2/1 is likely due to the server-side(?) performance check adding both the light in the light prefab itself (Even though that prefab itself is not included in the hierarchy on the main avatar and is only used on the particle system) and the maximum lights in the particle system. I understand that this is a relatively niche usecase as most people would likely just use a a regular light, but having this singular light be part of a particle effect allows for some neat control of the light through manipulation of the particle. i.e. I use it as a way to add noise to the the size and intensity of the light which would be more complicated to implement using a normal light. Also, is it possible to update the performance stat calculation of SDK Test avatars to match the new behavior? It's still using the old behavior that only counts the prefab and not the particle light count itself. I need to upload the avatar to see the correct stats.

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)

Affected avatar: avtr_8ee2b82e-1ecc-490e-a67a-ec91aaa12c9d (HotDog by PolygonalMind) Legacy avatars don't appear in the Main Menu anymore, but it's a shame to see this fail security checks on iOS because it's one of the few public fallback avatars that can be used as a fallback (it's exempted from fallback avatar author/ownership checks). I don't know if the fallback avatar appears as an error robot or as an Android loaded avatar on iOS, but the expectation was that it would be seen on iOS.

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.

== Little backstory/usage scenario: On a couple of my avatars, I have a "fake left/right eyelook" setup attached to the AngularY parameter due to them not using/being unable to use eye bones, so they "look" toward where I'm turning my head. (a couple people have mistaken it for actual eye tracking, heh) Recently, as I've been using SlimeVR and Standable I've noticed my eyes don't seem to move, and occasionally they are instead stuck looking to one side. I've just now figured out the following: == Issues: In full-body, AngularY is only updated when the actual player locomotes, rather than just by the avatar's motion. This is likely a result of intended behaviour as I heard the player controller in FBT now only rotates once the user starts moving (to resolve jitter on remote), though it is now inconsistent with AngularY updating constantly for three-point tracking. It does not seem to update on controller turning. Only locomotion causes the value to update. Moving in the playspace has no effect on the value. This results in situations where AngularY is stuck around 200 while the player is perfectly still, if they happened to be rotating when they stopped walking. Similarly, it often gets stuck at small values like 8 when coming to a stop normally due to minor motions. I suppose some questions now are: Should AngularY be following the player controller (as it seems to now), the avatar's root, or the user's head direction? For my use case (and others), would it be possible to add Head/Hands AngularY/X or expose EyeLookX/Y parameters?

As part of simulating expressions such as smiling and frowning using just the visemes Selfie Expression drives the AA blendshape into the negatives. This looks very broken on all but the most basic human avatars. Selfie Expression should not drive AA or any of the shapes negative, remember that avatars can be creatures of all shapes, not just anime girls.

I found a public fallback avatar with an unusual fallback avatar performance ranking (Good/Medium), while the "Use as Fallback" button also (incorrectly?) appears for this avatar while that avatar isn't mine. Affected avatar: Ooka （Quest Compartable） ( avtr_01a7cb85-d839-4c13-ae86-33141358ad55 ) by Diṧconnect Steps to reproduce: Visit the above avatar hyperlink on the VRChat Home website, find the "Use as Fallback" button and click it. I don't know for sure how the avatar became eligible as a fallback over years of changes (since 2024). Expected result: Don't show me "Use as Fallback" if it's not my avatar or an official fallback avatar. This also shouldn't be a valid fallback avatar, because it's not Good rated on all "supported" platforms (Windows/Android). Actual result: "Use as Fallback" is visible, although not functional. ("This avatar isn't yours or an official fallback avatar․") The button is shown for a custom fallback avatar with an ineligible performance ranking. Additional info: I'm ignoring the lack of iOS avatar here as a "supported" platform, because custom fallback avatars only require Windows/Android support anyway. The likely result of actually using this avatar as a custom fallback avatar would likely result in a performance blocked robot when possible, anyway.