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.

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.

Add something to the SDK to select the blendshapes to use for selfie expression (Like we can for the visemes and blinking) , or add a parameter in the Built-in Parameters for selfie expression. Using the webcam in VRChat is a really cool feature and a cheap way for people use their avatars more expressively, but currently there's little to no documentation about what blendshapes are being used. You also can't use a custom blink animation if you want to have the option to use selfie expression since it's trying to use the blendshape specified in the avatar descriptor.

It would be really useful to be able to build avatar systems based on your current status. I would love to add an indicator to my avatar which describes if I'm Blue/Green vs Orange/Red. This would also allow avatar creators to make some safety systems, such as having a minimum amount of clothing enabled when the user is Blue or Green. I can imagine this as a simple Int which is then readable by the avatar's animators.

Animators area huuuge reason VRChat performs so poorly, mainly as FX layers stack up. FX layers, while cheap, adds animator idle time linearly. Blend trees while more expensive due to typecasting most times, seems to be the way to go to avoid the mass load of layer idle timers. All this comes down to Compute Time, it can be labeled as "Active Animator Time", measured in either Microseconds or Milliseconds. This can be done on the server as animators are single thread and most single thread workloads on servers are generally about as slow as a mid-range VR PC, and thus the time it takes to compute on the server then gets graded into Excellent, Good, Medium, Poor and Very Poor ranks, with a hard compute time limit (Medium or better?) set on mobile platforms like Android, iOS, and Quest Standalone which don't have as much CPU horsepower.

Currently, you can have an avatar rated as “Good” at 70,000 polygons, but adding even a single triangle beyond that will instantly drop the rating to “Very Poor.” Obviously, this doesn’t make much sense and can actually discourage some people from optimizing their avatars. (Why bother optimizing other stats if the polycount alone tanks the rating the moment you go over?) I’d like to suggest increasing the polygon thresholds for Medium and Poor ratings, with a gradual step-up between each level. This would make a lot more sense and give creators more flexibility! I’d really love to see this system improved. The VRC team should ultimately decide on the final values through proper testing, but personally, I think a Poor rating could go up to around 120k, and Medium could sit around 90k. Of course, those numbers are just based on my experience, and I’m sure the team can come up with even better thresholds through data and testing.

This is something that feels like has been lacking for a good while, but having components that could take vectors of a transform property and output them to either a custom string for either a material property or an animator parameter to use. The implementation would be similar to how Physbones allows creators to use custom strings to name parameters that the animator will use and output specific animation reactions depending on the value. Example for the animator: Rotation Offset: There's one feature that Blender has that Unity lacks, and that is using corrective shape keys. Corrective ShapeKeys is a thing in Blender that lets users use bone transform angles to correct deforming mesh based on the angle. So you could bend your elbow in a specific way without needing to redo your weight paints or mesh topology. You could limit the angle of influence of how far the rotation can go for the blendshape amount within the driver itself in Blender. Positional Offset: Similar case to the above, you could also use a child of an empty game object to control how blendshapes look dependent on the child object's transform positional offsets relative to the parent object. If I say dragged a ball that was in world space to the left, I could make the face look angry, or make a character on the screen of a prop on my model move to the left. Examples for shader properties: Vectors, Floats, and Colors: Genshin Impact, love or hate it, is a decent game with an interesting shading style, especially with how they do their facial shadows. HoyoVerse uses SDFs to achieve this effect by getting the forward and right vectors of the head bone to determine the lighting angle along a gradient, and flip the gradient depending on specific conditions. The problem is the only method of doing this within Unity is to change the root bone of a skinned mesh renderer to the head bone rather than the hip bone, which is bad for those that want to have a consistent bounding box across all meshes and for shaders that manipulate the vertices of the skinned mesh. A way to solve for this would be to have a component that could output the forward, right, and even upward vectors to a custom string for a material property to read from and inherit the transform values of. Alternatively you could also output the transform positions for proper dissolve effects or for motion capture based systems that use colors to output, or to even give a good wobble effect/get the volume of a glass bottle for a liquid shader, or have it magically fill up. If possible, this could also be an extension to the Avatar Dynamics, and it could also be implemented into PhysBones for the transforms, but having this be extended to other use cases like the ones mentioned would be extremely helpful and possibly more optimized than using lights + depth tricks, CRTs + Cameras on our avatars, or whatever jank and unoptimized methods we use for our creations.

For both Physbone versions 1.0 and 1.1, the world immobile behavior has been reliant on ignoring any position data from the root of the avatar, but the main issue is that it still inherits the model's rotational velocity. The idea I would like to propose is something that is in the newest version of Magica Cloth 2 which is to have a game object's transform be referenced as an anchor in relation to the assigned root transform for the physbone. The idea of having an anchor referenced can help with the issue of physbones and calculating rotational data for the scripts to ignore. For the world immobile it could grab the avatar descriptor and auto assign that as the anchor point for the physbones to ignore, allowing IK transforms and animations to behave properly. Best way to sum up the idea is: All Motion: Reduces any motion as calculated from the root transform's parent World Immobile v2: (old method) Reduces position movement from locomotion, any movement due to animations or IK still affect bones normally. (new method) Reduces any motion based on the avatar descriptor's location in the hierarchy, any movement from animations or IK still affects bones normally. Anchor Reduces any motion calculated in relation between the root transform and the anchor's transform, any movement from animations or IK will affect bones depending on the anchor's location. Edit: Basically like with the new VRC Constraints adding something like a Source Transform component where the physics would be calculated from. This in turn would make it so if you were to freeze a physbone component in World Space with the new VRC Constraints, when you move the physbones physics wouldn't be calculated.

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.