Avatar Bugs & Feature Requests

Most VRC Avatar Components (Contacts, Constraints, Physbones, Etc.) have a root transform or target transform field, allowing the component to be placed on one gameobject and the functions of the component to originate from or act on another gameobject. It would be nice for the Raycast component to maintain consistency with the other commonly used components and have the root/target transform field.

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

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.

Current behavior: When a self global collider is in contact with a Physbone where Self Collision is allowed, disabling Self Collision will still allow the global collider to collide until it is no longer in contact with the physbones. Expected behavior: The self global colliders should not collide with the Physbones when disabling Self Collision. Current behavior: When a self global collider is in contact with a Physbone where Self Collision is not allowed, enabling Self Collision won't allow the global collider to collide until it is no longer in contact with the physbones. Expected behavior: The self global colliders should collide with the Physbones when enabling Self Collision. Here's the avatar ID for testing: avtr_d34c9e59-4083-4433-bfa4-02a337132cd0

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

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 This would replace the lost functionality in a supported way and significantly improve usability for both casual users and avatar creators.

Avatars may contain GameObjects that are used only locally. For example, camera extensions and inventory systems based on Avatar Dynamics. I think that they should be excluded from performance rank calculation if they are always disabled in remote environments. I know that it is hard to determine which objects are local by inspecting animator controllers. My proposal is based on explicitly marking and runtime content modification to avoid animator inspection. Mark local objects as "local only" by tag or custom component. Remove marked objects while loading avatars as with camera components in avatars used by non-friends. This feature makes the performance rank system more accurate and reasonable. It will help to motivate developers to optimize their avatars.

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 can already add a constant value to our parameters, but being able to add the values of two parameters together would be very helpful!

With the addition of the VRC Animator Play Audio state behavior, it's become very hard to ignore how frustrating it can be to make modifications to an animator that uses VRC state behaviors. It was already a bit of a pain with the Parameter Driver behavior, but it's on a whole different level with the Play Audio behavior. There are so many options you can choose, it becomes an absolute chore if you need to move things around between different states. Or simply trying to have similar settings in each state you play audio from. Our only recourse right now is to either use Unity presets (which is also fairly cumbersome), or to rely on community-made tools. Please give us a built-in way copy/paste not just with the Play Audio state, but with all VRC State Behaviors.