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.

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

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?

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.

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.

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.

The current performance requirements have been around for years and pc specs have greatly improved since then, it's also a bit inconsistent with 1 single triangle over the 70k recommended being "very poor" and the texture memory being just slightly higher being just "poor" and excellent avatars have game breaking shaders that tank peoples framerates more than a avatar with 70,001 triangles. With performance gated instances being implemented I feel the performance ranking system needs a overhaul as having instances only accept "good" performance means that everyone has to decimate their avatars like crazy to conform to a standard in a instance. As far as how to overhaul the performance ranking is beyond me I barely even know how to add a different texture to my avatar but I'm sure there is some way to make the system itself more optimized and not so strict on creators.

Saw this product recently that lets you manually scale your arm and leg lengths via a radial menu and thought to myself "Wait a second.. Why isn't this a VRC feature? This would be AMAZING" We all know that everyone's proportions are different, and not every avatar can accommodate that without having to manually edit it for yourself in blender. If this was built in it would make different avatars feel so much better to wear. https://nanochip.gumroad.com/l/avatarlimbscaling

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.