Avatar Bugs & Feature Requests

I've been noticing and increasing number of issues with physbones over the past couple of months. 1. Immobile used to work with Gravity, but now bones with gravity always shake violently while the avatar is moving quickly, completely ignoring immobile. Example: avtr_ba3daad5-0c64-4fb4-8593-38265acd9ad3 avatar uses that to determine the up vector for the cat, walking around causes the cat to jump around, it never used to in older versions. 2. Physbones resting on or inside colliders vibrate, sometimes even to the point where they seem to struggle to stay inside inside-out colliders. This used to be stable with no vibration. In minor cases this can sometimes be mitigated with "physbones as spheres", but it never used to be necessary. Example: avtr_04a9d322-e228-4934-93b1-6e20b62cfded The boxing gloves on this avatar are long physbones with squish that are held back by inside-out colliders, they now vibrate violently at all times, they used to stay calmly in place.

Issue: Textures used in a material swap on particles seem to use an incorrect mipmap compared to textures used on the original material used by the particle system. VRChat Avatar showcasing the bug: https://vrchat.com/home/avatar/avtr_985cb361-cea2-4502-b406-72fe3b56acb1 The avatar contains a particle system that has toggles for 3 material swaps: The Red material is the default material the particle system was uploaded with The Blue material is the swap material and showcases the incorrect mipmap level The Blue(NoMipMap) material is the same as the Blue material but using a duplicate of the blue texture where the 'generate mipmaps' toggle in the texture import settings was unchecked. This material does not have the same bug as above. All textures used on materials for this particle system test were 512x512 and should look identical aside from color. Additional Notes: This seems to only apply to textures that are not in use on the avatar in it's initial state. i.e. adding an additional mesh/material to the avatar that is using the same texture used on the Blue material will result in the particle system using the correct mipmap level on the Blue swap. Reproduction Steps: Create a particle system Create an animation that swaps the material of the particle system with a material that uses a separate texture. Activate the particle system, observe the normal texture Swap materials being used by the particle system, observe the lower resolution texture Expected Behavior: The expected behavior is that the textures used in the particle system look as high quality as they need to, i.e. using the correct mipmap level for the distance they are at from the camera. Attachments Description: Attached is a video showcasing the bug.

On a Avatar's body Skinned Mesh Renderer, if you set the "Cast Shadows" option to "Shadows Only", the mesh will only be invisible to Remote players, Cameras and Mirrors, while always being visible to the Local player. This makes creating effects that can only be seen in shadow harder to do as the person who wears the avatar will always be able to see the mesh when we want it to be invisible.

Currently, the shader type called Hidden that can be specified as a fallback shader is introduced on the following page as: > Hidden // (this will hide the mesh from view if the shader is blocked, useful for things like raymarching effects.) > https://creators.vrchat.com/avatars/shader-fallback-system/ However, if a mesh using this shader has an animation that sets the _Color alpha parameter to 1 , the mesh that should have been hidden by the fallback shader becomes visible. My guess is that this happens because the Hidden fallback shader is actually reusing an existing shader (such as Unlit/Color ) and simply sets the color alpha to 0 in order to hide the mesh. When an animation overrides the alpha value, the mesh ends up being rendered. As a solution, I would suggest either providing a dedicated Hidden shader, or adding a special “hidden” flag to the existing shaders so that polygons are not rendered at all.

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.

My avatar has perfect fullbody without any issues in SDK2, but in SDK3 my viewpoint and head will shift backward to align with my hips for whatever reason, causing the spine to bend backward awkwardly and it ruins the tracking. Maybe this is related to hip flipping but I had to do that because previously there was a slight tilt to the side in my hips and that was the only way to fix it. EDIT: The same exact problem occurs regardless of whether or not the hip is flipped, and I already undid the fix and tried following the tracking guide. There is also another problem with fullbody: avatars will actually move their head and torso to be able to reach when the avatars arms are shorter than the user's real arms. Reaching forward for example will make the avatar lunge forward and bend over, as opposed to the previous behavior where the arms extended as far as possible. The new viewpoint system is likely the culprit for everything and it also causes all default animations to look really awful. Here are 2 examples, one without calibration and one with:

Ever since somewhere around 1711 physbone colliders sometimes fail to work until the physbone is toggled off and back on. Toggling the collider does not fix it. It affects randomly locally to the viewer. It is not dependent on whether you are the wearer or not. This is most obvious on floor colliders for tails, but can break other avatar systems that depend on physbone colliders.

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)

Avatars using Final IK's Execution order have their VRIK locomotion settings changed. The two settings that seem affected are the Step Threshold and Step Speed. In the attached gif is the difference between the builds. Multiplying the step threshold by two and dividing the step speed by two restores the VRIK closer to its original status in game, but then it is incorrect in the editor. Deleting the Execution order also makes the VRIK act as it does in the live build, but in this set up the Execution order is vital for the avatar to work correctly.

When the following conditions are met, a PB placed under an object with a Constraint setting will not follow the Constraint’s movement, regardless of whether it is Local or Remote. (Contacts follow correctly without any issues.) An animation within the Animator manipulates the Transform of the object that has the Constraint setting. (This applies even if it's in an isolated state.) The Constraint applied to the object is in an enabled state. Once the Constraint is disabled and the animation is able to move the object, the PB starts following to the correct position. (The avatar where this bug was discovered has a somewhat complex setup, so there may be other contributing factors.) The avatar ID where the issue occurs is as follows: avtr_d45ac5bc-cb20-4bce-8c03-bf45e81f0dec SDK: 3.8.0 BuildVersion: 1628 --------------------------------------------------------------------------------------------------------------------- [JP] [特定条件下でPBはConstraint設定されたObjectの動きに追従しません。] 以下の条件を満たすとき、Constraint設定されたObjectの配下に設定されたPBがLocal/Remote問わずConstraintの動きに追従しません。 (Contactは問題なく追従します。) ①Animatorの中にConstraint設定したObjectのTransformを操作するAnimationが含まれている。 (孤立したStateでも同様) ②Objectに設定されたConstraintが有効状態になっている。 Constraintが無効になりAnimationで動かせるようになると、PBは正しい位置へ追従するようになります。 (バグを発見したアバターは少々複雑な作りをしているため、他にも原因があるかもしれません。)