Avatar Bugs & Feature Requests

Animated Scaling for bone with Physbone applied will Jitter and never stop moving when hit with a collider. A Prox Contact receiver is used to Scale bone size 0 - 1 Physbone are applied normally Separate both parts work. Together Physbones scale but rotation is jittering and won't go in rest state On SDK 3.10.1 and 3.10.2 broken

With the recent-ish change that makes particle lights correctly count towards your total light count, I noticed a possible discrepancy with the total count. Steps to recreate: Add a Particle System to the avatar In the Particle System, scroll down to Lights Create a Point Light in the scene but outside the avatar Create a prefab of the Point Light Insert the Point Light prefab into the Light slot inside the Particle System Limit Maximum Lights to 1. Upload to VRChat Observe avatar details of avatar. Lights will be listed as 2/1 Example of an avatar that only has 1 Max Particle Light on the entire avatar but is listed as 2/1 lights in the avatar details https://vrchat.com/home/avatar/avtr_7c80a2a5-3473-421f-86ce-fdda8fa8eb3f Expected behavior: Lights should be listed as 1/1. Though I expect the 2/1 is likely due to the server-side(?) performance check adding both the light in the light prefab itself (Even though that prefab itself is not included in the hierarchy on the main avatar and is only used on the particle system) and the maximum lights in the particle system. I understand that this is a relatively niche usecase as most people would likely just use a a regular light, but having this singular light be part of a particle effect allows for some neat control of the light through manipulation of the particle. i.e. I use it as a way to add noise to the the size and intensity of the light which would be more complicated to implement using a normal light. Also, is it possible to update the performance stat calculation of SDK Test avatars to match the new behavior? It's still using the old behavior that only counts the prefab and not the particle light count itself. I need to upload the avatar to see the correct stats.

I've been noticing and increasing number of issues with physbones over the past couple of months. 1. Immobile used to work with Gravity, but now bones with gravity always shake violently while the avatar is moving quickly, completely ignoring immobile. Example: avtr_ba3daad5-0c64-4fb4-8593-38265acd9ad3 avatar uses that to determine the up vector for the cat, walking around causes the cat to jump around, it never used to in older versions. 2. Physbones resting on or inside colliders vibrate, sometimes even to the point where they seem to struggle to stay inside inside-out colliders. This used to be stable with no vibration. In minor cases this can sometimes be mitigated with "physbones as spheres", but it never used to be necessary. Example: avtr_04a9d322-e228-4934-93b1-6e20b62cfded The boxing gloves on this avatar are long physbones with squish that are held back by inside-out colliders, they now vibrate violently at all times, they used to stay calmly in place.

Mipmaps are an important technique used in computer graphics to lower the cost of rendering high resolution textures at oblique/glancing angles or great distances. They store progressively smaller, filtered versions of the main, higher resolution texture. As the size of a surface in real screen pixels becomes smaller, a higher mipmap level is used, resulting in both a reduction in visible aliasing (due to containing an average of the higher resolution texture contents) and an increase in performance (as the lower-resolution mipmaps fit better into the GPU cache, increasing rendering throughput). Mipmaps are great! Unity enables mipmaps by default. On PC, they're essential if you use large textures. And on Quest, having mipmaps can have a big positive impact on performance! However, mipmaps cost a small amount of memory, and it has become commonplace for people who do not understand or care about the performance implications to recommend disabling mipmaps to save on memory, thus causing the GPU cache to be thrashed and various other negative effects. As the SDK currently recommends people reduce their avatars' memory usage by any means necessary, it's created this incentive to disable an important performance optimization. The solution I propose is for the SDK to also provide feedback and some light restraints on mipmap settings. However, it should not force the usage of mipmaps for all textures, as there are many important cases where mipmaps are not useful or harmful due to their extra data not being necessary, or causing calculations to become inaccurate. For instance, a common technique in both stylised cel shaders and realistic shaders is to use look-up textures for things like toon lighting ramps, specular/fresnel distributions, and other types of data which does not benefit from mipmapping. For advanced users, textures are really just a data source, and mipmaps are wasted if data you're reading doesn't benefit from them. Also, this proposal is geared entirely towards avatars. While worlds are technically not any different from avatars in how mipmaps affect things, individual avatars will always use unique textures, while only one world exists at a time. Here is what I recommend: ### On PC: Show a Warning if a texture meets all of the following conditions is above a size threshold (suggested: 256x256) does not have mipmapping enabled is not a render texture, custom render texture, or similar Show an Error if a texture meets all of the following conditions is assigned to a texture slot with the following name: _MainTex, _MetallicGlossMap, _BumpMap, _ParallaxMap, _OcclusionMap, _EmissionMap, _DetailMask, _DetailAlbedoMap, _DetailNormalMap is above a size threshold (suggested: 1024x1024) does not have mipmapping enabled ### On Quest/Mobile/Android: Show a Warning if a texture meets all of the following conditions is above a size threshold (suggested: 256x256) does not have mipmapping enabled Show an Error if a texture meets all of the following conditions is above a size threshold (suggested: 512x512) does not have mipmapping enabled The PC recommendations are designed to be permissive, and only stop users from using textures without mipmapping in places that would cause issues under normal circumstances. It can't cover all cases, but it shouldn't try. Render textures are excluded from the warnings as they require mipmaps to be generated at runtime, which has its own performance impact. The Android recommendations are a bit more heavy handed, as custom shaders don't exist for Android avatars and the performance impact is more notable. Thanks for reading!

I recently found out about Thry's Avatar VRAM Calculator. I didn't really have any idea that I should be looking into how much VRAM my models were using before uploading them. I realized this week that most of my complex models could easily go up to 800MB in VRAM with all features enabled. I feel like I would have made a more conscious effort to keep this number low if it was made aware to me via the SDK. It is really nice to know how bad my model could impact others with these metrics. Thry's VRAM Calculator very bluntly let's you know how much Video Memory is being used. Please add some form of metric for this with the Avatar SDK or Creator Companion.

If you have a collider on your avatar, you could repeatedly jump and gain height. This is a flying or hovering exploit. If you walk or run while in mid air on this collider can cause unpredictable movements and throws you in some seemingly random direction at great speed. This is a speed exploit.

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?

Switch to an avatar with an animation that is triggered when the _Stretch of the Physbone exceeds a certain threshold. The moment the avatar is loaded, the _Stretch behaves as if it were stretched to the maximum, and the animation is triggered. _Stretch reacted when the avatar teleported or returned from a specific pose, etc., and the avatar's posture suddenly changed and the physbone moved. In some cases, _Stretch reacted abnormally when the player was moving too fast or under the influence of Station. The specific behavior is as follows Before the update: If Immobile is 1, it did not extend regardless of the value of stretch motion After the update: Stretch motion value is used regardless of Immobile value.

Reproduction steps: Make AudioSource.pitch or volume changable from Radial Puppet using Motion Time from float parameter. Build & Test Open QM and change parameter. Result: Audio volume goes max at the frame that parameter changed. The volume returns when stop changing value. Expected: When pitch value changed, only pitch changes. When volume value changed, volume has sets exact value what that setted, not chattering. Note: It never happenes in Unity editor, Gesture Manager. Only in the client.

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.