Avatar Bugs & Feature Requests

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

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.

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.

I changed avatars and ended up accidentally into an error robot locally (attached screenshot) temporarily, until I switched to another avatar and back into the same avatar again and then the avatar loaded correctly. This issue repeated a day after, but only remotely to another user. Logs pointed to the above error. I've not been able to reproduce the issue in the past year, and I'm unable to reproduce this again. I don't have steps to reproduce this for this bug report to be actionable and I'm not sure where the problem lies either, unfortunately. Affected avatar: Comfy MoeFT Hush_Rush （lilToon） by WubTheCaptain ( avtr_5d925964-e921-4b24-81a9-f19eef7d3eb1 ) This is an eye-/facetracked avatar, with its FT parameters controlled via OSC with VRCFaceTracking 5.4.4.1, EyeTrackVR App 0.2.5.6 and Babble v2.0.7, animated on the avatar with animations (including eyes). What typically happens when this avatar's loading malfunctions: The avatar loads with eye-/facetracking parameters saved in "on" state, then based on a random chance the eye-/facetracking animations may freeze on avatar load until switching out/resetting the avatar. Rarely, VRCFaceTracking on the host PC may crash instead or require a restart. This is the first time it's given me an error robot instead in-app.

VRCHeadChop components have no effect on any non-humanoid avatars. I tested multiple avatars and settings. The bug occurs with or without custom animator layers, so it's not an issue with animations overwriting anything. Given how important this component is to most non-humanoid avatars, this seems like an unintentional error. The workaround of including an entire humanoid-skeleton is poor for both optimization and user-friendliness.

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.

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?

If feasible, the hue slider feature would be very useful on Standard Lite. Currently, mobile-content-creators must compromise between a hue slider and PBR materials.

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!

I have a big suggestion that speaks for ALL paid avatar creators. We spend a lot of time, money and effort creating our avatars and we tend to make our promotion version of our avatars public so that our promotion team can take pictures in them. It frustrates us when people outside of our promotion team gets a hold of the avatar because it is posted in avatar search worlds for everyone to use which leads to our work getting ripped! My suggestion would be to be able to limit avatars that we upload to friends only or by VR Chat user. This would protect our work significantly. Please take this into consideration!