Avatar Bugs & Feature Requests

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.

I’ve always been under the impression that after generating an impostor for an avatar, such as iOS, I would then be able to log into the iOS version of the game and see the impostor for that avatar locally. This never seems to be the case. Any avatars I’ve generated impostors for still show up as a “caution bot” when worn and I can’t see my own avatar. Why make impostors remote-only? They should be visible to all users, including the wearer. This should work the same across all platforms. If a Quest player uses an avatar that isn’t actively uploaded to Android but has an Impostor, they should be able to see that impostor on their own body locally too.

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.

Allow parameters animated inside an animator to be used as a source to copy to another parameter. Currently the only way to do this without using another animated parameter (which has limitations) you need to use the value to animate the distance between a contact senders and proximity contacts reciever.

The idea is that there should be 2 different local modes: Local-to-Touch: This behavior would allow avatar creators to make things on their model that remote players that interact with the contact would only see. So as an example, if there's an animation on my model that turns a cube from red to green, only those that touch the cube would see the cube turn green, while those that aren't touching it would see it red. This would behave similarly to the VRLabs Selective Animation Prefab without needing the Final IK components to do this trick. (Source: https://github.com/VRLabs/Selective-Animation ) Local-to-Self: This is the current behavior of local contacts, especially in regards to triggering animations that you can see for yourself.

I just realized this, but many VRChat characters seem less alive by the simple principle that fake eye-movement lacks the very speedy and energetic "eye-darting" that real-life humanoid eye movement has, and its particularly hard to unsee when it is visualized, here is a demonstration through someone else's tips while I was looking up help for animation:

I would like to have the ability to place where on my avatar the voice would come out of. There are many cool puppet avatars that attach to your hand yet the voice comes out of the center of players head bone. This throws off immersion. This could be something that is added onto the avatar, as a component. and points to an empty game object. If it's not present, it defaults to normal microphone placement.

I would love to have the ability to optimize my avatars even further by using hand-made Level of Detail models at a distance. This sounds like it could be easily exploited, but with enough restrictions, avatar creators who want to go the extra mile could optimize their avatars to a ludicrous degree. Perhaps the polygon count on LOD models could be rigidly locked to a percentage value of the avatar's original polycount. For example, LOD1 could be 75%, LOD2 could be 50%, and so on. If I have an avatar that's 70k triangles, then LOD1 would have to be 52,500 triangles or less, and LOD2 would have to be 35,000 triangles or less. Perhaps LOD models past LOD1 could be forced to only have 1 skinned mesh. LOD models could require that you use the same textures and materials as the main model, to prevent the exploitation of swapping to unoptimized materials. Perhaps the number of custom materials could be reduced to 2, maximum. Maybe the Quest fallback version of a model could just be the lowest custom LOD model instead, if the LOD model in question is optimized enough. If there was a separate Performance Ranking System for LOD models that restricted the ability to upload them if they went over the limit, I don't see this feature being exploited. At worst, most users would ignore it, and automatically generated LODs could be used instead. At best, an avatar could be optimized massively, which could lead to improved performance across the board, especially on Quest or Android. The only downside would be an increased download size, but if the LOD models are forced to use the same textures and materials as the main model, the impact would be negligible.

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.

A boolean animation parameter for jumping. Grounded boolean parameter is not reliable for jumping as it also flips when falling, walking on uneven or steep colliders, being picked up, flying, double jumps, etc.