Avatar Bugs & Feature Requests

Avatars can have 2D (global) audio sources on them, these can be quite disruptive at times. To make instance moderation easier, it would be nice to have an avatar overlay that shows at least the active, if not all, avatar audio sources.

Currently, the shader type called Hidden that can be specified as a fallback shader is introduced on the following page as: > Hidden // (this will hide the mesh from view if the shader is blocked, useful for things like raymarching effects.) > https://creators.vrchat.com/avatars/shader-fallback-system/ However, if a mesh using this shader has an animation that sets the _Color alpha parameter to 1 , the mesh that should have been hidden by the fallback shader becomes visible. My guess is that this happens because the Hidden fallback shader is actually reusing an existing shader (such as Unlit/Color ) and simply sets the color alpha to 0 in order to hide the mesh. When an animation overrides the alpha value, the mesh ends up being rendered. As a solution, I would suggest either providing a dedicated Hidden shader, or adding a special “hidden” flag to the existing shaders so that polygons are not rendered at all.

Since more and more avatars use face tracking, the currently available amount of bits for avatar parameters is getting very low. Face tracking alone takes about half the parameters available. One way I got around this on an avatar is to utilize two 8 bit parameters to sync mutiple values in sequence, which makes it basically possible to have an "infinite" amount of parameters. The downside of that is that the sync is not in realtime (stutters for other players since every parameter synced this way has to be synced every tick after each other) and when joining a world the initial sync to set all parameters for other players to be visible takes also a bit of time. About 10 parameters a second is the maximum. Im seeing more and more people using that kind of sync for those parameters so I think lots of people are interested in having more parameter space. Even doubling the current amount would be a huge help. If that is for some reason not possible. More fine adjustments would also help. Like defining the precision of int and float values. Lots of radials dont need the full 8 bit of range. Or make some parameters static, so that we have static and dynamic values where static ones only change when used in a radial and dynamic ones are those which are constantly changing (like face tracking for example). The static ones only would need to be synced on world join / other player join and when changing the value manually via toggle or radial. That could possibly save on network bandwith if thats an issue.

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 noticed this recently with a friend. When they didn't have their FBT on they would walk or run and only their legs would move, with their torso, hands and head completely still like its always been, but when they put on FBT and turned on FBT Locomotion their head chest and hips would be bouncing a lot , but their hands would stay completely still. I've seen the same effect on pretty much any avatar, I just don't know why? I don't like using FBT locomotion because of the bouncing, but Id like to have my legs move when I move. Is there a way to fix this? Add a toggle that locks your spine and that from the Locomotion animation but lets your legs move? I'm unsure if this is a bug because it could be intentional or something that slipped through the gaps.

At the moment there is no method to find out if your avatar is performing a blink. It would be really useful to have a Bool (desynced) that lets the animator know if a blink is being performed to allow for blinking to only happen via the animator (or to suppress certain activities/animations when a blink is in progress)

I tryed to send "/avatar/change" osc message but it does not work. I also sended "/avatar/parameters/..." together and it works. osc.send({address: "/avatar/parameters/BustSize", args: [0.5]}); // works osc.send({address: "/avatar/change", args: ["avtr_0eb0aeff-5a47-4c01-86e7-943cfcc1e8b5"]}); // not working

Realtime point and spot lights don't affect these materials. This is troublesome for dark worlds on android, like where you carry a flashlight or torch. Because player avatars using these shaders appear totally black. Some worlds introduce a fallback "avatar light" toggle to address this issue. Which is a directional light whose culling mask is set to affect only player layers. But that illuminates all avatars. So it's not so nice a solution. Adding Shade4PointLights (or similar code) to the forward base pass of these shaders would fix this issue.

There is no reason not to. And no, impostors are not a valid substitute for actual authored LODs, though they could be a decent pre-cull step; neither is distance culling. Relying on occlusion is also not an option, as layouts vary greatly, often not bringing camera close enough to targets. We're currently stuck between two extremes: either you run on eleven-and-a-half vertices, or you rock LOD0 and effectively output microtriangles for anyone two or more meters away; more often than not it's the latter, and given commonly used fragment shader complexities (and their "quality") the performance impact grows exponentially. I guess this needs to be said: it's not 1996, and we can have more than 512 verts per scene. Especially in VR, where detail is paramount. Previously stated excuses for not whitelisting the component were laughable at best. Just because few people will make use of it doesn't mean no-one should be able to use it. Safety system accommodates for LOD meshes under the mesh visibility umbrella. Existing solutions rely on safety system allowing animator evals, as well as relying on contact receivers. It is janky, unreliable, and takes too much time to set up. There is no need for implementing some magical automatic LOD generator either. Most automatic generators tend to mangle topology and related attributes beyond reasonable level even for flatscreen. If an author doesn't want to properly author LOD meshes, they can choose to use existing automatic generators themselves.

(Edit: Added "for avatars" to the post title. VRCGraphics.Blit is available for worlds, but not avatars.) The Shader Community's Request for Graphics.Blit What is Graphics.Blit? Graphics.Blit allows you to copy a source texture into a destination render texture using a shader. Being able to do this allows for shaders to write to render textures in a manner that does not require cameras ---- Why do we want Graphics.Blit? Currently shader creators are using cameras and render textures to emulate what Graphics.Blit does. Cameras were not made for this purpose and have a relatively high amount of overhead. On top of this, in order to effectively mimic Graphics.Blit we need two cameras to achieve the same effect. This doesn’t mean Graphics.Blit replaces cameras though, it allows for most use cases to run much quicker. ---- What uses this camera workaround currently? GPU particles . Anyone who's experimented with GPU particles knows how much faster these particles run compared to Unity's built in particle system. GPU particles in their current form can run a million particles in 1.43ms on the GPU. That's amazing already, but because we have to use cameras, ~0.7ms of CPU time(camera0 and camera1) is spent on updating the cameras. Graphics.Blit can bring the CPU time from ~0.7ms to ~0.07ms. GPU particles are not the only shader which will perform better using Graphics.Blit. Any shader which has uses a 2 camera and render texture setup will be faster using Graphics.Blit. Other use potential cases for Graphics.Blit * GPU dynamic bones * Cheap Gaussian blur * Fluid Simulation * Grass/Hair Simulation * Procedurally generating Data * Virtual Keyboard for mutes * AI for Shader pets following you around * Simple games and puzzles. Pong, Flappy bird, and the beginnings of Doom have been done with cameras already * Worlds with snow dynamic, rain puddles, and water ripples ---- Why should time be spent on Graphics.Blit when only shader creators will be using it? Even though this is going to mostly only effect shader creators, everyone benefits from this change. GPU particles have been released to the public for a while and has been the only way for VRChat users to get millions of particle without completely destroying FPS. Graphics.Blit would increase the room for innovation. ---- What would a Graphics.Blit component from the VRC SDK look like? We would like to see two scripts added to the SDK, a Blit Controller, and a Blit Component. The Blit Controller should be a component which can be added to game objects on avatars and worlds. The Blit Controller should also have one input, an array of Blit Components. The purpose of this controller is to handle the order in which each blit is executed. In order for a shader to store stateful information, there need to be two render textures and two blits. The order in which these two blits are run is important, and this controller handle that. The Blit Controller component should run Graphics.Blit for every Blit Component in the array, in order. The Blit Component should hold two inputs, a source texture and a destination texture. Where is the material at? Well in order to allow shaders to be animated in VRC we think that using the shared material from the mesh renderer on the game object would be ideal. The blit component should have a RunBlit function which takes the mesh renderer’s shared material and runs Graphics.Blit with the source,destination, and shared material. Also the RunBlit function should pass a couple extra bits of information to the shader. Namely the game object’s localToWorldMatrix, worldToLocalMatrix, and position. We think this is important because with Graphics.Blit you get no outside information. Some of the existing camera effect require position information. We have included a GitHub link which contains a mock implementation of what we think would be the best way to implement this for the use cases we have. It is under the MIT licence so feel free to use anything from our implementation. We want to make this as easy as possible on development time. Our mock implementation: https://github.com/Merlin-san/Blit-Component We aren't sure if components update on both PlayerLocal and Player for the local player, but updating more than once per frame should be avoided if that's the case. ---- Safety System Currently the render texture/camera work around that we use requires that you are friends with another user in order for that user to see the render texture. This was implemented before the safety system. If Graphics.Blit is implemented, render textures should be either apart of the safety system under "shaders", or its own category under "render textures" The shader community, Toocanzs, Merlin, Elixir, Xiexe, Blake447, Okano, snail, Tykesha, .Captain., Claw, Quantum, Nulliel, Naelstrof, Wakamu, 1001, Nave, Neitri, SCRN, Silent