Avatar Bugs & Feature Requests

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

A popular use case for expressions on avatars is to do things like toggling objects on and off, adjusting blend shapes, and more. Setting up cases like these in an SDK project from scratch requires a fair amount of knowledge of how Unity and its animator system works, which isn’t always intuitive to users that are brand new to creating avatars. To help make it easier to set up common use cases like this, we’re working towards introducing a new component called the Action Driver. The fundamental idea of it is to let avatar creators bind parameters on their avatar directly to one or more “actions” that they want to trigger, which includes common tasks like turning game objects on and off. *Read more in our Developer Update .

Description Please consider adjusting the height threshold for the “Shorter Than Average” warning. Currently, the warning can appear on avatars that are shorter than the average human height, even when their height is completely intentional and normal for the avatar. For example, avatars around the height of Mamehinata and other commonly used smaller avatars are intentionally designed to be short. There is also a fairly large difference in typical avatar height between different avatar styles and communities. Because of this, I don’t think avatars that fall somewhere between the height of commonly used small avatars like Mamehinata and the typical height of larger Western avatars necessarily need to trigger a warning. Suggested Solution Instead of removing the “Shorter Than Average” warning entirely, lower the threshold at which it appears. The warning could be reserved for avatars that are unusually or extremely small, where their height may actually indicate an unintended configuration or could cause usability issues. This would keep the warning useful while avoiding unnecessary warnings for intentionally short avatars that are still within a normal range of avatar heights used in VRChat. ==Japanese== 「Shorter Than Average」警告が表示される身長の基準を調整してほしい 説明 「Shorter Than Average（平均より低い）」という警告が表示される身長の基準を調整してほしいです。 現在は、平均的な人間の身長より低いアバターの場合、その身長がアバターとして意図された正常なものであっても警告が表示されることがあります。 例えば、まめひなた程度の身長や、その他の一般的に使用されている小柄なアバターは、元々その身長になるよう意図的にデザインされています。また、アバターのスタイルやコミュニティによっても、一般的なアバターの身長にはかなり差があります。 そのため、まめひなたのような一般的な小柄アバターの身長から、比較的大きな海外アバターの一般的な身長までの範囲であれば、必ずしも「Shorter Than Average」という警告を表示する必要はないと思います。 提案 「Shorter Than Average」の警告そのものを削除するのではなく、警告が表示される身長の基準を、現在より低くしてほしいです。 通常のアバターとしては明らかに極端に小さく、意図しない設定になっている可能性や、実際に使い勝手に問題が発生する可能性がある場合にのみ警告を表示するようにすればよいと思います。 そうすることで、「Shorter Than Average」という警告の役割を残しながら、意図的に小柄に作られていて、VRChatでは一般的な範囲にあるアバターに不要な警告が表示されることを減らせると思います。

have you ever created an avatar and made it public for people and there's some people you dont want to have the avatar? well thats what avatar blacklisting and whitelisting is for. if your an avatar creator, you can just go into unity and type in the usernames you want to blacklist. simple.

Syncing has been a major issue between VRChat avatars for many years. Ensuring that other people see parts of your avatar in the same place—regardless of whether they’ve just turned your avatar on, joined late, or are looking in the mirror—is one of the biggest challenges for anyone creating complex avatars. The lack of a reliable way to sync avatars stifles creativity and limits what users can do. What we need is a "Freeze to World" and "Rebake Offset" option on VRC constraints, or a new command that allows game objects or bones to be synced over the network. Community-built workarounds for these issues have helped a lot (VRLabs has done some great work on this), but they come with their own performance costs and animator complexities, making them unsuitable for all situations. World objects are cool, but not every situation needs a world-droppable campfire or DJ deck. For example, I want to be able to take the helmet off my avatar, leave it on the table, and have everyone who joins see it there.

Allow parameters animated inside an animator to be used as a source to copy to another parameter. Currently the only way to do this without using another animated parameter (which has limitations) you need to use the value to animate the distance between a contact senders and proximity contacts reciever.

In many scenarios, we could reduce the number of contacts required for systems by a factor of 8x or more if receivers exposed more information about the current collision. This is very necessary to avoid the undocumented vrchat "hard nearby contact limit." This additional information could be exposed as parameter suffixes, just like _Stretch on physbones. Specifically, these parameters would be very, VERY useful, and allow for an ENORMOUS reduction in contacts: * X, Y, Z offset of the nearest collision in world units but LOCAL rotation (for example, z should be "forward" of the contact) * Whether the nearest collision is self or others (or world?) * Velocity of the proximity (change in collision proximity since last contact update / time delta, this is very difficult to calculate in animator since contacts do not always update every frame) * Velocity of the sender (change in sender position since last contact update / time delta) * Matching tags of the nearest collision. This could possibly be exposed as multiple bools <receiverparam>_Tag_<tagname> = 0,1

This is something that feels like has been lacking for a good while, but having components that could take vectors of a transform property and output them to either a custom string for either a material property or an animator parameter to use. The implementation would be similar to how Physbones allows creators to use custom strings to name parameters that the animator will use and output specific animation reactions depending on the value. Example for the animator: Rotation Offset: There's one feature that Blender has that Unity lacks, and that is using corrective shape keys. Corrective ShapeKeys is a thing in Blender that lets users use bone transform angles to correct deforming mesh based on the angle. So you could bend your elbow in a specific way without needing to redo your weight paints or mesh topology. You could limit the angle of influence of how far the rotation can go for the blendshape amount within the driver itself in Blender. Positional Offset: Similar case to the above, you could also use a child of an empty game object to control how blendshapes look dependent on the child object's transform positional offsets relative to the parent object. If I say dragged a ball that was in world space to the left, I could make the face look angry, or make a character on the screen of a prop on my model move to the left. Examples for shader properties: Vectors, Floats, and Colors: Genshin Impact, love or hate it, is a decent game with an interesting shading style, especially with how they do their facial shadows. HoyoVerse uses SDFs to achieve this effect by getting the forward and right vectors of the head bone to determine the lighting angle along a gradient, and flip the gradient depending on specific conditions. The problem is the only method of doing this within Unity is to change the root bone of a skinned mesh renderer to the head bone rather than the hip bone, which is bad for those that want to have a consistent bounding box across all meshes and for shaders that manipulate the vertices of the skinned mesh. A way to solve for this would be to have a component that could output the forward, right, and even upward vectors to a custom string for a material property to read from and inherit the transform values of. Alternatively you could also output the transform positions for proper dissolve effects or for motion capture based systems that use colors to output, or to even give a good wobble effect/get the volume of a glass bottle for a liquid shader, or have it magically fill up. If possible, this could also be an extension to the Avatar Dynamics, and it could also be implemented into PhysBones for the transforms, but having this be extended to other use cases like the ones mentioned would be extremely helpful and possibly more optimized than using lights + depth tricks, CRTs + Cameras on our avatars, or whatever jank and unoptimized methods we use for our creations.

I would like either the triangle limit for PC Excellent to be lowered, or the triangle limit for Mobile Poor to be raised. Currently, even if you create an avatar that meets the PC Excellent triangle limit, uploading it for Mobile can cause it to be rated Very Poor because the triangle limits do not align. Therefore, I would like one of the following changes: ・The PC Excellent triangle limit to be lowered to 20,000. ・The Mobile Poor triangle limit to be raised to 32,000. This would make it easier to create avatars that maintain consistent performance ranks across both PC and Mobile. PCのExcellentとMobileのPoorのポリゴン数を統一して欲しいCannyです。

Same issue when preloading the big worlds, when player/others have changed the avatar before preload is finish, game will keep loading the world anyway, and then avatars. It's understandable avatars with accessories being loads the last, but the local avatar(not cached?) is another thing, it should load first no matter what(which usually not issue unless player use accessories), otherwise in bigger lobby(or slow internet) it will surely cause issues(and more since there will be more accessories in the future) since you will have no idea how yourself looks like when people came and greets/talk to you. The percentage bar also mislead since it will show the loading progress for whole instance(until everyone joined before you finished unless culled) instead of the actual progress to your own avatar loading.(build 1854)