Avatar Bugs & Feature Requests

VRChat is working on its own constraint component for avatars, replacing Unity constraints. VRCConstraints are like Unity constraints, but improved and optimized for VRChat avatars. They work on Quest and Android! Avatars can continue to use Unity constraints. However, they are automatically converted to VRCConstraints in VRChat. Unlike Unity's constraints, VRCConstraint is a single component. Instead of replacing the components, its behavior is selected via a dropdown. (This feature is still in development! The name and details of this feature are subject to change.)

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.

Constraints have been a staple of PC since the 2018 update. Having constraints would be a great asset to Quest creators as it can allow for similariton of various pc only components such as dynamic bones and final ik.

Something I feel that a lot of quest users have been missing out on has been stuff in the shader department. Although there have been improvements to the standard lite shader, at times that isn't enough, as well as how most of the shaders for quest users are similar to unity's default shaders. I feel it would be a decent consideration to have a simple yet stylized shader from VRChat could solve this issue a bit, and possibly help with mixing some properties like toon shading with PBR elements or using more than 1 uv channel for tiling+masking purposes.

As previously announced in one of VRChat developer updates , VRChat will be introducing new maximum limits for uploaded avatars. PC avatars Maximum file size: 500 MBs -> 200 MBs Maximum estimated memory usage: 1200 MBs -> 500 Mbs Quest avatars Maximum file size 10 MBs (unchanged) Maximum estimated memory usage: 40 MBs (new) The SDK will warn you if your avatar exceeds one of these limits. We came to these numbers based on an analysis of currently uploaded avatars. If we find legitimate use cases that we missed, we might change them. About 2% of avatars will be affected.

As local only contacts only appear/operate for the local user. They shouldn't be considered for stats when uploading an avatar. Local only contacts should be counted separately.

The current shader fallback system is pretty difficult to work with for an avatar creators. It doesn't let you to preview the end result in Unity and requires messing with the shader's internals. Most avatar creators don't create their own shaders, they use the popular ones like Poiyomi etc, so they have very little control over shader fallback behavior. Those shaders are too complicated to be graciously fallen back in an automated way, usually resulting in a completely broken look of the avatar. (For example one of the common problems is the emission color gets copied onto the fallback, but the emission mask isn't, resulting in a fully illuminated avatar, while it should've been just a glowing tattoo) I propose a more straightforward solution that doesn't create an unnecessary dependency on the main shader and its parameters. For any given material, an avatar creator should be able to set a Fallback Material. If set, then when fallback shaders are enabled, all references to the original material will be replaced with a references to the fallback material. Similar to Android materials, Fallback Materials will be only allowed to use the shaders that are whitelisted as fallbacks (like Toon, etc) - it can be validated by the SDK. This will give the avatar creators the full control over their avatar's look under the fallback shader conditions.

With the new cloning feature: Allow avatar creators to set a “pedestal only” option so that avatars can still be used as quest rewards or Easter eggs for special avatars in worlds, for example.

Recently, the number of avatars that add light to the avatar itself and cause load has increased. I tried disabling it in Safety, but Light off doesn't work and there are still tons of avatars causing a load.

This is a issue because if you dont have certain layers available in unity, and you set a particle system to exclude 1 layer, then any layers missing from your project are also excluded. I have come across numerous world creators using the custom layers for world geometry, so any particle systems uploaded in a project without all the custom layers added just go through these. Please fix this in the SDK, all that would need to be changed is setting up all of the custom layers that you can use to something like "Custom X"