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.

this makes clothes of any avatar fade off the further you go. Kids are seeing things under clothes that they shouldn't see on a game and it ruins the game. Please fix this because i have tested everything and its a huge problem for quest users.

Currently, avatar creators use the built-in animator parameters Seated and InStation for chairs, stations, and MMD dance worlds. Recently, many worlds have introduced vehicle and moving-platform systems that allow avatars to follow elevators, trains, cars, and other moving objects without using Sit. However, these systems are also beginning to use InStation or Seated. This creates a conflict because these two use cases represent different behaviors. Current Issue InStation has long been used by MMD-compatible avatars as a signal to switch from VR tracking to animation playback. As a result, when a vehicle-following system activates InStation, avatars designed for MMD worlds may: Disable VR tracking unexpectedly. Become stuck in an idle pose. Switch into animation mode even though the user is simply standing on a moving platform. The behavior required for vehicle following is fundamentally different from the behavior required for stations and dance worlds. Proposal Please introduce a dedicated animator parameter for vehicle-following systems, for example: InDrive (or another appropriate name chosen by the VRChat team) This parameter would indicate that the avatar is following a moving object while remaining under normal player control, without implying that tracking should be disabled or that the avatar should enter station animation mode. Compatibility Avatar creators have already demonstrated their willingness to support new animator parameters, as seen with MMD-compatible avatars. If VRChat officially introduces a dedicated parameter and announces it, new avatars will naturally begin supporting it while existing avatars can gradually adopt it through updates. Benefits Prevent conflicts between MMD worlds and vehicle systems. Preserve the original meaning of InStation. Provide a clearer separation of animator states. Improve compatibility for future transportation and moving-platform systems. Without separating these behaviors, the same parameter will continue to represent two incompatible purposes, making avatar development increasingly difficult. This is not an issue caused by MMD worlds or by vehicle systems themselves. Both are using the existing parameters appropriately for their own purposes. The problem is that one animator parameter is now being used to represent two fundamentally different behaviors. Separating these concepts would improve compatibility for everyone. Thank you for your consideration.

Avatars in seats without any "avatar" set in the animator lag behind when the seat is moved in worlds. avatar without "avatar" set in animator: avtr_017879f6-dd90-42f3-90c5-f6390b2edbbe avatar with "avatar" set in animator: avtr_1129036e-0fa4-487b-bfaa-9f17397a1bf2 create avatar without "avatar" set in animator sit in a seat in a world move the seat around and the avatar will lag behind it World you can use to test this where everyone is placed in seats: wrld_650084ad-f500-49da-b0a9-4ff498f7f23c

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

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?

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)

Can we get a bool to determine if the animator currently running is on the local mirror clone? There's a couple of niche use cases where I'd like to do have an animation do something different on the local mirror clone versus the main avatar. For example, on an avatar anything that has rigidbody physics will locally spasm and fly around. The main avatar and mirror clone can collide with each other, thus the mirror clone version of the rigidbody is constantly colliding with the main avatar's causing it to freak out. This can be solved by animating off the colliders on the mirror copy, which we could do if there was a parameter that indicates if the animator is running on the mirror copy. This is a rather complex example, but I'm sure there are other use cases where you might want the mirror clone to behave differently than the main avatar.

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.

Currently float and int parameters are hard-set as 8 bit parameters... This is fine for people who don't need a lot of parameters... but it uses more bit space than what is needed most of the time (as you will rarely see anyone use even close to 255 seperate values for every interger) and the radial float puppet does not allow going into the negatives despite it being synced. I think that allowing the user to use lower bit-rate floats or ints with the limiting factor being less precision, also for floats not allowing to go below 0, Example situation: Someone makes a radial float puppet that doesn't require a lot of precision, instead of using 8 bits with half of the range being unused due to a negative being involved, use only a 6 bit float that ranges from 0-1, which is still precise enough for most cases, and some cases can use only 4 bits if they need more room. (4 bits = 16 int limit, a single 0-1 float at 4 bits is a 0.0625 increment, this is still enough for most radial puppets)