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.

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.

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)

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.

To my knowledge, the Oculus Lipsync SDK provides each talking viseme with its own float parameter so that one syllable could seamlessly flow into the next one. So I don't see why we can't have that system available to us as avatar parameters, correct me if I'm wrong though. I basically want to replicate the viseme system with an avatar animator so that I can then modify it in-game (particularly useful for face-tracking). However, the closest I've gotten with the animator parameters (voice float to drive the blendshape amount with a transition time between syllables) didn't reach the same fidelity as the default system. It ended up suffering a transition delay if I spoke too fast or looked stuttery when I spoke slowly.

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.

it would be nice to dictate whenever something is 'active' as it seems using 'AAP' (animated animator parameters) does not trigger it. for making a Prop-Slot system look nice and not be a mess, you would need a system to detect whenever a certain 'Slot' is being used, But, once its 'taken out' of that slot, then disable the parameter seamlessly. You cannot do this with AAP as AAP requires floats, and not bools, and cannot be used in logic it seems, as they set the Value, but not the Expression value, (as tested with AV3Emulator, and ingame.) Other more complex systems could use "On Exit" aswell, as it would only be ran when the state gets transitioned out. (Parameter Driver Behaviours could even be stacked into one state, one to Enter, one to leave, unless 'Type' could be changed into OnExit instead, or the entire system Rewritten to be like AnimatorPlayAudio.) i've attached a little simple design of where On Exit could be easily placed.

Currently AudioSource components are completely disabled for Android avatars. Please allow at least one.