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.)

In Unity's Standard shader, the _OcclusionStrength parameter multiplies the "influence" of the Occlusion texture on ambient light. Standard Lite's occlusion slider currently multiplies the texture itself, meaning that AO has 100% influence when the slider is 0, rather than 0% like in regular Standard.

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.

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)

Normally, avatars with an incomplete skeleton (such as mine with no fingers) animate fine when walking but retain walking animations when crouched or prone. When using the same avatar on the A3 beta, no animations are used and the model perpetually t-poses.

I am using Avatar SDK Version 3.5.1 and i am unable to use alpha blended shader on the android build as i get this error `Avatar uses unsupported shader 'VRChat/Mobile/Paftieles/Alpha Blendecf. You can only use the shaders provided in 'VRChat/Mobiie' for Quest avatars.` and there also seems to be a missing line on the Avatar ShaderWhiteList was this intentional?

The IVRCSDKPreprocessAvatarCallback API requires providing a callbackOrder value to define the order in which your callback is invoked. However, there is no guidance given as to how to select this callback order; in practice, there are key thresholds such as -1024 , where all IEditorOnly components are deleted. Having official guidance as to the intent for various ranges of callback orders will help avoid problems where new VRCSDK-built-in processing hooks are added in the future. It would also be helpful to have a place to record where we're placing our callbacks (maybe as part of a future official wiki...?), or really any documentation at all on the official documentation page for this API.

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.

There are some camera extension prefabs provided by the user community to complement the lack of camera functionality. They capture a scene with photo quality for all frames because there is no way to detect whether high-resolution capturing is required for the current frame or not in the animator. Of course, it requires too many computations for a 4K/8K camera. Using preview quality for non-shooting frames can reduce this cost. This proposal introduces some animator parameters that represent the states of the built-in camera for the current frame. They will make it possible to optimize rendering quality for photo shooting. CameraState : is an integer that represents the state of the built-in camera for the current frame. 0: Built-in camera is disabled. 1: Photo camera is enabled and previewing. 2: Photo camera is capturing for saving photos. 3: Stream camera is enabled. CameraResolutionX and CameraResolutionY : are integers that represent camera resolution for the photo camera or screen resolution for the stream camera.

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.