Avatar Bugs & Feature Requests

I would llike to see the camera have a depth filter for taking pictures like this:

Unity Int and Float parameters are 32 bits in size, and VRChat does actually support higher-than-8-bit precision on float values between -1 to 1 assigned by the radial (as can be seen in the save files within LocalAvatarData) or other menu options (buttons, toggles) for the local user, regardless of parameter sync. However the same does not hold true for float values below -1 or above 1, as well as int values below 0 or above 255, even when using unsynced parameters, which seems like an arbitrary limitation or simple oversight given that the full 32 bit types are still being allocated, they simply cannot be set by the menu. Please allow menu options to specify 32 bit values when using unsynced parameters.

Currently float and int parameters are hard-set as 8 bit parameters... This is fine for people who don't need a lot of parameters... but it uses more bit space than what is needed most of the time (as you will rarely see anyone use even close to 255 seperate values for every interger) and the radial float puppet does not allow going into the negatives despite it being synced. I think that allowing the user to use lower bit-rate floats or ints with the limiting factor being less precision, also for floats not allowing to go below 0, Example situation: Someone makes a radial float puppet that doesn't require a lot of precision, instead of using 8 bits with half of the range being unused due to a negative being involved, use only a 6 bit float that ranges from 0-1, which is still precise enough for most cases, and some cases can use only 4 bits if they need more room. (4 bits = 16 int limit, a single 0-1 float at 4 bits is a 0.0625 increment, this is still enough for most radial puppets)

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.

I know that you guys are aware of this issue (Tupper himself said so), but I'm posting this canny so it doesn't get forgotten. A fair amount of people, including myself, were excited for this new state behaviour, but sadly it was removed for 2020.3.2. What we don't want is this implementation be forgotten, and plan this redesign and give a small priority in bringing back this state behaviour, if possible.

I remember a scale/size changing feature that affected the view point being showcased in the Avatars 3.0 Beta, wouldn't it be nice to bring it back ?

Avatars may contain GameObjects that are used only locally. For example, camera extensions and inventory systems based on Avatar Dynamics. I think that they should be excluded from performance rank calculation if they are always disabled in remote environments. I know that it is hard to determine which objects are local by inspecting animator controllers. My proposal is based on explicitly marking and runtime content modification to avoid animator inspection. Mark local objects as "local only" by tag or custom component. Remove marked objects while loading avatars as with camera components in avatars used by non-friends. This feature makes the performance rank system more accurate and reasonable. It will help to motivate developers to optimize their avatars.

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!

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.

For both Physbone versions 1.0 and 1.1, the world immobile behavior has been reliant on ignoring any position data from the root of the avatar, but the main issue is that it still inherits the model's rotational velocity. The idea I would like to propose is something that is in the newest version of Magica Cloth 2 which is to have a game object's transform be referenced as an anchor in relation to the assigned root transform for the physbone. The idea of having an anchor referenced can help with the issue of physbones and calculating rotational data for the scripts to ignore. For the world immobile it could grab the avatar descriptor and auto assign that as the anchor point for the physbones to ignore, allowing IK transforms and animations to behave properly. Best way to sum up the idea is: All Motion: Reduces any motion as calculated from the root transform's parent World Immobile v2: (old method) Reduces position movement from locomotion, any movement due to animations or IK still affect bones normally. (new method) Reduces any motion based on the avatar descriptor's location in the hierarchy, any movement from animations or IK still affects bones normally. Anchor Reduces any motion calculated in relation between the root transform and the anchor's transform, any movement from animations or IK will affect bones depending on the anchor's location. Edit: Basically like with the new VRC Constraints adding something like a Source Transform component where the physics would be calculated from. This in turn would make it so if you were to freeze a physbone component in World Space with the new VRC Constraints, when you move the physbones physics wouldn't be calculated.