Avatar Bugs & Feature Requests

Steps to repro: Add a raycast to avatar and give the parameters a name so they show up in the Debug window Create a toggle that Constraints or Animates the raycast to a new position Open up the debug window and observe the parameters. Toggle on the animation and observe the parameters In some worlds the parameters do not update with the new animated position of the raycast Expected behavior is that the parameters should match the current animated location of the raycast which seems to not be the case in some worlds. It seems world dependent which is quite odd. My thought is that it may be some sort of race condition. Many use-cases for raycasts involves them being attached to gameobjects that are animated and/or constrained so this bug effectively makes the parameters useless in those uses-cases while it exists. Avatar used to test: https://vrchat.com/home/avatar/avtr_c4932ab2-7dde-41f4-be23-0993287a2253 Avatar has 3 raycasts. By default the raycasts are to the Left, Right and Forward. The raycast with the green sphere is constrained Forward when the toggle is activated. The raycast with the blue sphere is animated Forward when the toggle is activated. Worlds where I DID encounter this bug: Avatar Testing Chamber https://vrchat.com/home/world/wrld_a5e9ec13-36b1-4e63-ae0c-dab9023401f9/info Nico's Garage https://vrchat.com/home/world/wrld_91fe29d2-9c55-4d2f-88a6-1a3e838f2564 1's Optimized Box https://vrchat.com/home/world/wrld_1a8b8684-3b19-4770-a4a7-288762f57b29 Worlds where I DID NOT encounter this bug: BrainrotTestZone https://vrchat.com/home/world/wrld_858aa698-08e3-4f1d-b8ff-5f1a43e41f20 DaggerTest https://vrchat.com/home/world/wrld_b42e2d5e-da85-475e-a701-cd15bc3c4efd/info ［Initial D］ Lake Akina https://vrchat.com/home/world/wrld_fff707c6-bec1-442c-b4d6-41a707166f37/info Additional Notes * Tested on both Live and Open Beta, behavior occurs on both. * Parameter data when the bug occurs seems to come from the raycast's original location/direction Attachments: * RaycastBug1.mp4: Video takes place in Avatar Testing Chamber, showcases the bug as the parameters for the Raycasts should be almost identical when the toggles are activated but they continue to show behavior similar to the untoggled state. * RaycastBug2.mp4: Video takes place in Lake Akina and showcases the bug NOT occurring, aka what the expected behavior should be. Raycast parameters are almost identical when the toggles are activated as the raycasts are animated to nearly the same direction/position.

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.

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.

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.

I think that the eyes and the eyelids should have their own checkbox, allowing for more control over the eyes. I would like to be able to disable and enable eyelook and blink independently of each other.

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.