Avatar Bugs & Feature Requests

We'll be adding a new feature to Toon Standard for recoloring the base texture with a 4-channel mask. Here's how it will work: Each channel has a separate color to use for recoloring. Recoloring is done by first converting the masked area of the main texture to grayscale and then applying the color, meaning you don't need to author your main texture in grayscale to apply recoloring. This is similar in concept to hue shift, but a direct recolor instead of a shift from one color to another. Masks can also be used for emission through an emission slider for each channel. There are two options for blend modes: Multiply and additive. - In the multiply blend mode, the grayscale version of the main texture is multiplied by the color. - In the additive blend mode, the chosen color is added on top of the grayscale version of the main texture.

Summary I would like to propose providing Avatar Shaders with limited access to avatar deformation and spatial relationship data. This could include: Pre-skinned vertex data Bone matrices and bone transforms Limited avatar spatial relationship queries (such as distance-to-surface or similar performance-safe alternatives) The following restrictions should apply: Read-only access only Accessible only for the avatar currently being rendered No access to other players' avatar data No raw mesh export functionality No mesh modification APIs No runtime scripting requirements No GPU buffer write access The goal is to enable advanced shader-based anti-clipping and corrective deformation systems while maintaining VRChat's existing security, performance, and platform compatibility standards. Motivation Clipping between the body and clothing remains one of the most common and difficult problems in avatar creation. This is especially noticeable during: Full Body Tracking Dance and MMD animations Sitting and crouching poses Extreme arm and leg movement PhysBone-driven secondary motion Current solutions such as body hiding, stencil masking, corrective blendshapes, and manual mesh edits can reduce clipping, but often require significant manual work and may introduce visual artifacts. Transparent clothing is particularly challenging because hiding clipped body parts can create visible holes that often appear more unnatural than the clipping itself. Some creators have already demonstrated shader-driven anti-clipping and deformation techniques using depth-based approaches. These projects are fascinating and show the potential of advanced corrective systems. However, such solutions are often complex to author, view-dependent, difficult to maintain, and limited to specific use cases. Seeing both the potential and the limitations of these approaches is what inspired this proposal. Predictive Anti-Clipping and Corrective Deformation Access to pre-skinned vertex data and bone matrices would allow creators to develop predictive deformation systems that anticipate clipping before it becomes visible. Potential applications include: Dynamic anti-clipping deformation Clothing expansion around high-risk clipping areas Pose-aware corrective deformation Transparent clothing correction Volume preservation systems Dual Quaternion Skinning (DQS) Optimized Centers of Rotation (OCoR) Pose Space Deformation (PSD) For example, clothing could dynamically expand around the hips, shoulders, underarms, or other deformation-heavy regions during extreme poses rather than relying entirely on body hiding or manually authored corrective shapes. Reactive Anti-Clipping Systems While predictive systems can significantly reduce clipping, some situations are difficult or impossible to anticipate reliably. Examples include: PhysBone-driven motion Dynamic accessories Secondary motion systems Transparent garments Complex layered clothing To address these situations, limited avatar spatial relationship queries could enable reactive anti-clipping systems that respond to intersections after they occur. Possible implementations could include: Distance-to-surface queries Signed Distance Field (SDF) sampling Surface proximity information Other performance-safe spatial relationship APIs Importantly, this proposal does not require exposing raw mesh data, unrestricted vertex access, or cross-avatar information. The exact implementation could be determined by VRChat based on performance, security, Quest compatibility, and future maintainability considerations. Benefits This proposal does not request VRChat to implement any specific deformation technology. Instead, it would provide creators with the foundational data necessary to develop their own solutions entirely through shaders. Pre-skinned vertex data and bone information would enable predictive corrective systems, while limited spatial relationship queries could enable reactive anti-clipping systems that respond to actual intersections. Together, these capabilities could unlock a new generation of avatar quality improvements, reduce clipping artifacts, improve transparent clothing workflows, and encourage innovation within the existing Avatar SDK framework while preserving VRChat's current security and performance model.

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)

(Note: This feature is still in development, so any of the details below might change before the final release.) The Avatar Optimizer runs automatically when you build or upload your avatar. It intelligently generates atlas textures and combines meshes and materials to reduce the number of draw calls, improving performance. You can configure the optimization settings to preserve certain blend shapes, skip generating atlas textures, or disable the optimizer entirely. You can preview optimized Avatars before uploading to check if the optimizations worked correctly. At first, only the Standard Lite and Toon Standard shaders will support material merging and texture atlasing. If you're a shader developer, our documentation will explain how to make your custom shader compatible with the avatar optimizer. Once we're ready, our goal is to test the avatar optimizer in a closed beta to collect more data on its usefulness and to inform our next steps.

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.

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.

As stated, sometimes when playing on desktop with webcam hand tracking (selfie expression) enabled hands freeze in weird position in front of the face. It often looks like holding your forearm horizontally with a hand folded inwards and backwards. Sometimes hands move in some odd position and stay like this for an extended period of time (10+ seconds) or sometimes repeatedly move in and out such positions. It could happen with either left or right hand. It happens even when hands lie on a mouse and a keyboard (webcamera cannot see them from such position) Clearly showing your hands to the camera may fix it for a little bit but it never fully stops. Turning a desk lamp for better illumination also may help but it a bright light straight to the face obviously irritates eyes and worsens the vision. Obviously, webcam tracking cannot be very accurate but this issue has been present for many months (since October 2025 at the very least) but it's been happening more and more for the past few weeks. Other destop players did report similar hand behavior (original Reddit post is lost) and I feel like the reason is not only necessarily FPS or resolution but VRChat's tracking / hand recognition algorithms.

Think of having a complex avatar, say, a gun. Oculus would have to use the Grip to take advantage of any "GestureWeight", due to the grip being the detector. Index on the other hand, properly has trigger as the "GestureWeight" data. It'd be a great addition or replacement to the current gesture system if we could detect our own button presses, touches, and other more niche things, for better more universal guns. (vrc settings could even have a toggle for this too.) Oculus users cant use guns very well that are made with GestureWeight. Index users can use guns very well and it feels great with GestureWeight. I dont think vive users can use GestureWeight at all? OPTION 2: The other option which would be much simpler to implement, is a Int that outputs the type of VR controllers you use. This would be much simpler to implement, but be less powerful then whats above. Example being: 0 : No controllers 1 : Vive (No GestureWeight) 2 : Oculus (Grip GestureWeight) 3 : Index (Trigger GestureWeight) this would allow avatar creators to create functions based on certain controllers to allow better accessibility towards more people. Like having Vive users just use gestures instead of GestureWeight.

Sometimes, when I have an avatar with two nearby physbones that both have a physbone collider on them, and the physbones are set to collide with each other's collider: if I push one physbone with an open hand (i.e. without grabbing) into the other physbone, both physbones will move, as expected but if I grab one physbone, and pull it into the other physbone, the one that I'm grabbing will stop like it hit an immovable wall, and the second physbone won't react at all. If physbones were just totally unable to mutually move each other via physbone colliders, I might have just assumed it was a shortcoming of the system; but if I can push one physbone into moving another, but I can't pull that same physbone into moving the other, that seems like a bug?

I would like to have a proper way of updating the PhysBones integration forces within an animation while the PhysBone is running. This would make it possible to implement some avatar features, such as being able to remove an item (such as glasses or a hat) and drop it into the world. At present, the documentation specifically calls out the integration forces as not being animatable, and suggests an unsupported workaround of toggling the component off and on, but doing that causes other problems with the interaction. Ideally, any change to the integration parameters would automatically cause the physics to update internally, although if some other signal is required to tell it to update the simulation (such as toggling a property from the animation) that would also be acceptable.