Avatar Bugs & Feature Requests

In the Tracking controller behavior could we get Eye Tracking, Eyelids and blinking separated so they can be individually changed from animation or tracking using animators. For example I would like it to be able to disable the blinking and the eyelid movements when using face blend-trees but keep eye tracking itself.

Interpolating float parameters locally could smooth out stuff like face tracking, which suffers from the current low update rate. Right now people use perf-costly animators to interpolate their face tracking manually.

When the player moves at high speed (locomotion) over about 2m/s physbones will flail around wildly. This would be acceptable except for that it also happens even if they have their Immobile set to 1. It doesn't make any difference if it is set to "All Motion" or "World". This negatively affects avatars such as avtr_ba3daad5-0c64-4fb4-8593-38265acd9ad3 which use physbones to measure the up direction. When walking briskly the angle of the measurement physbones will flail around wildly causing undesired animations. I feel like this wasn't originally an issue with physbones, and it started happening relatively recently, but I don't have any hard evidence to back that up.

I have an avatar that shows up as "Good" for PC in the Unity editor and once downloaded in VRChat, but both on the website and in game prior to downloading the avatar, the security scan shows up as "Very Poor". I'm not sure why there's this discrepancy, but the consequence is that the avatar is filtered out by clients who have "Poor and Below"/"Very Poor" blocked, and the opaqueness of the process means I have no way of telling how to fix the problem. Request is either for parity between the systems, such that an avatar's performance ranking will be displayed consistently between them, or else more descriptive feedback on why the security scan returned a different ranking than Unity does. I've seen this on a few avatars in the past, but currently the one I'm having issue with it on is private, but it's here: https://vrchat.com/home/avatar/avtr_937eaecf-7d00-482d-84c5-955174244294 Attached are pictures from the same avatar on PC as seen in: 1) Unity Editor 2) VRChat Client (avatar tile, pre-download) 3) VRChat Client (avatar info, post-download) 4) VRChat Website

Avatars may contain GameObjects that are used only locally. For example, camera extensions and inventory systems based on Avatar Dynamics. I think that they should be excluded from performance rank calculation if they are always disabled in remote environments. I know that it is hard to determine which objects are local by inspecting animator controllers. My proposal is based on explicitly marking and runtime content modification to avoid animator inspection. Mark local objects as "local only" by tag or custom component. Remove marked objects while loading avatars as with camera components in avatars used by non-friends. This feature makes the performance rank system more accurate and reasonable. It will help to motivate developers to optimize their avatars.

Emission map is enchaning effect on the shader. As standard lite shader is a only one has emission property, many people cost the performance or break some asthetics, just to their avatars glow. So we need a lite emissive shader similar to toon lit.

I think it would be very helpful to be able to use copy parameter drivers to copy the VRC-Exposed (GestureRight/GestureLeft/etc) parameters to other parameters. A bit of an edge case, but there are some situations where converting parameter types of these parameters can be very helpful

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)

128 bits is plenty but ints can be wasteful, and it's complicated to set up bitwise logic with bools. A good compromise is letting us specify how many bits our integer parameters can use; 2 to 8 (perhaps longer?) This would let toggles use a lower amount of bits and make it easier to squeeze more parameters into the 128 syched bits available. It would be up to the user to make sure they stay within the range they specified.

Currently all variables listed in the "Avatar Parameters" list count towards the 128 bit limit and are synced. This is unnessecary as sometimes you want to locally have a button/toggle/slider which is then used locally in an animation to drive a synced variable. I would seperate these two concerns by adding another "Synced" checkbox (like the "Save" checkbox) and only count those variables towards the 128 bit bandwidth limit. This would enable more complex behaviour without any additional cost.