Avatar Bugs & Feature Requests

Since the Reference Cube has AudioLink support, even on Quest, it only seems natural that Quest avatars should be able to have an AudioLink-supported shader whitelisted/added to the SDK next. Quest users are often missing out on AudioLink, since Quest only allows certain shaders to be used, otherwise it gets replaced by the infamous error shader. Could we have an AudioLink shader or add support for it for Quest avatars?

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.

(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.

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

Currently, avatar performance rank can be affected by bounding box size in a way that appears inconsistent when avatars use different default/import scales. Two avatars can have the same effective in-world size, mesh complexity, materials, textures, physics, and runtime behavior, but receive different performance rankings because one has a different default scale or authored scale. In that case, the bounding box metric is not measuring actual runtime impact consistently. Reproduction steps Take the same avatar with identical meshes, materials, textures, shaders, and physbones. Upload one version at a normal avatar height (~1.5m). Upload another version scaled to ~15m height. Scale both avatars to the same effective in-world size during runtime. Observe that the larger-authored avatar receives a significantly worse performance rank due to bounding box size, despite equivalent effective runtime appearance and behavior. The bounding box check should ideally normalize the bounds relative to avatar size. Large bounds can still be a legitimate concern for culling or visibility behavior, but equivalent in-world avatars should not receive different rankings solely because of differing default scale metadata.

Currently synced custom paremeters consume either 1 or 8 bits out of the 128 bit total available for each avatar. If I store my selectors as Ints, I feel like I have enough ideas per avatar to easily exceed this limit. But some selectors don't necessarily require 8 bits of storage. For example, if I have 8 facial expressions, I could encode that information in only 3 bits. That means my Int parameter is wasting 5 bits, which could easily contain another selector or maybe a bunch of toggles. If I have at least 2 low count selectors in my avatar, I can kind of do this by having a single "Command" or "Macro" Int parameter for the menu to set, where each position represents an unrelated command, then encode everything else using Bools and drive the Bools with parameter drivers. But that's an unnecessarily cumbersome method and also breaks my ability to use Toggle controls in the menu (or, in other words, to display state). The easiest solution for this problem would be for the SDK to provide shorter integers as synced parameter types for storage. At least 2 and 4 bit integers, although due to the size of radial menus I feel like 3 bits would be extremely useful too. In the playable layers, all of these would be translated into regular "ints", but truncated if their value exceeds their capacity when being synced or stored. The idea in https://feedback.vrchat.com/avatar-30/p/feedback-control-the-not-sync-parameters-from-expressions-menu also mitigates this problem (though it's worse), since it would allow local variables in the menus to display state and integrate features in a more human-friendly manner. It would still require encoding into Bool parameters to be performed with parameter drivers, though. Another great way to solve insufficient storage woes would be to give VRC+ users the ability to store 256 bits per avatar (as the uploader). Seems like the sort of thing people would actually pay for.

Previously, I was using Stop action particles, in a manor somewhat similar to touch triggers, to detect when a particle hit something and play a sound An example would be the sound of a missile exploding on impact (Done by an invisible trigger particle shot along side the visual particle) The setup is similar to how particle based touch triggers work, except it's triggered by contact with the world (and thus, a purely touch trigger system would not be suitable) I believe a similar system is used in avatars that have an effect when you swing a sword fast enough.

Recent changes have removed the ability to use custom or animator-driven scaling methods that many users relied on. These methods were not just workarounds—they provided functionality that the current in-game scaler does not support. The current scaling system has several limitations: No numeric input for exact values Poor precision when using sliders No way to reproduce a specific scale consistently No ability to save or reuse scale presets Previously, users could create consistent, repeatable scale presets. This is no longer possible. Existing alternatives have significant downsides: Manual scaling is limited, imprecise and cannot be reliably reproduced Duplicating avatars for different sizes: clutters the avatar list (9 outfits times 5 scale presets = 45 avatars) wastes storage (9 avatars times 3 platforms times 5 scale presets = 135 avatars) Reduce cache efficiency, leading to more frequent re-downloads, longer load times, and increased bandwidth usage Additionally, there is currently no way to control avatar scaling externally or programmatically. This prevents integration with external tools and advanced setups. Request: It is time to stop relying on the community to use workarounds to provide the scaling options you should provide. Preferably this should be done before breaking the current external scalers. Please add official support for: Direct numeric input for avatar scale Saveable and reusable scale presets per avatar Fine adjustment controls (e.g., small increment buttons) An OSC input channel for avatar scale control An SDK-accessible method for setting and reading avatar scale Measurement modes (eye height, top of head including kemomimi, top of head excluding kemomimi, direct scale input) This would replace the lost functionality in a supported way and significantly improve usability for both casual users and avatar creators.

First of all, I know a major point of this update was Avatar Performance recalculation- but I can confirm it's very incorrect. I've handcounted Material Slots and tried reuploads of exact avatars and been met with exact data size yet completely different calculations of VRAM, Avatar Bounds, and most abundantly, Material Slots. It seems like every avatar I've uploaded has suddenly gained +1 Material Slot, despite both handcounting and VRChat's SDK's calculations. Examples: A Pokemon-Esque commission I did has a reported 32 Material Slots, ~118 mb VRAM, and no animated bounds at less than 2m per side (is smol.) These would Parallel the SDK within VRChat, and give perfectly symmetical in-game data. On Build 1695 a version of the avatar uploaded in March 2025 reports 18 Material Slots, 129.98 mb VRAM. The bounds are insane at 2860.40 per side. I double-checked, no avatar bounds are animated. However, a version of the exact same avatar (with no modifications) uploaded today, August 29th 2025 12am EST reports 33 Material Slots, 129.98 mb VRAM, and ludicrous asymmetrical bounds at 4798.35, 798.61, 1002.50. Once again, nothing abnormal within the avatar and nothing reported in within the SDK. And once again, absolutely nothing avatar-bounds related is animated- in fact, ERASING the FX and Action layered Animator Controllers does not change the Avatar Report at all. All enabled objects are found within range of the object. And no other animator controllers are present within the avatar's hierarchy. VRAM, Material Slots, and Bounds are all found to be calculated incorrectly. This issue is present on 20+ and counting separate uploads of avatars. Some have skyrocketing VRAM peaking 300+ MB post-update despite Windows platform overrided DXT1 and DXT5 Crunch Compression, some have +1 to +2 Material Slots. Some have -12 to -14 Material Slots. Some have astronomical bounds despite all instanced renders being online/enabled at once, reporting within the SDK being less than 5x6x5, and with not one animation affecting their transform. In other findings, deletion/negation of Animations providing Material Swaps as a functionality on Particle Systems, Mesh Renderers, Skinned Mesh Renderers, and Trails do not affect the miscalculation of "Material Slots", Bounds, nor VRAM. Nothing changes within avatar performance on deletion of their animator controllers besides download size. Most likely being the deletion of referenced Animation File Size. Another Example can be found on my Twitter: https://x.com/speedbuiz/status/1961261519640940710 Please do not dismiss this as my fault. I've posted to the canny before and been given the cold shoulder and ignored. I can confirm with multiple hours of discovery that these avatar performance calculations are completely incorrect. I expect there to be more abnormalities than just VRAM, Material Slots, and Bounds. Please reply with any discoveries, and please upvote this problem so VRChat can assist their Avatar Creators.