Avatar Bugs & Feature Requests

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.

With the recent SteamVR Input 2.0 the hand posing also changed a lot. The patch notes mentions the finger posing is considering the Humanoid Muscle Settings, but to what extent is unclear. I have an avatar with each finger's "spread" range set to 0-0 and despite that the hand will still be splayed a significant amount. On another avatar I had played around with the finger angles to see if it would affect the tracked fingers (Valve Index), with no difference to be seen. I had specifically set the ranges to something realistically unreasonable just to test the limits. So it then surprised me to see its hands being fine with both "Legacy Fingers" and the new Input 2.0 fingers. So what values are considered from the humanoid setup? As it stands, it looks like nothing is taken into account.

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.

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.

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.

Currently, the VRChat Radial Menu allows for custom icons to be assigned to menu items, but these icons remain static and cannot be changed dynamically during runtime. It would be incredibly useful to have a feature that allows menu item icons to be updated in real time. Use Case: A toggle button in the Radial Menu could visually reflect its current state (e.g., switching between an "On" and "Off" icon).

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.

Unity Int and Float parameters are 32 bits in size, and VRChat does actually support higher-than-8-bit precision on float values between -1 to 1 assigned by the radial (as can be seen in the save files within LocalAvatarData) or other menu options (buttons, toggles) for the local user, regardless of parameter sync. However the same does not hold true for float values below -1 or above 1, as well as int values below 0 or above 255, even when using unsynced parameters, which seems like an arbitrary limitation or simple oversight given that the full 32 bit types are still being allocated, they simply cannot be set by the menu. Please allow menu options to specify 32 bit values when using unsynced parameters.