Avatar Bugs & Feature Requests

Post about current Avatar bugs and Avatar Feature Requests.
One item per post!
Non-constructive and off-topic posts will be moved or deleted.
Components that take Transform values and output them to Custom Shader properties/Animator parameters?
This is something that feels like has been lacking for a good while, but having components that could take vectors of a transform property and output them to either a custom string for either a material property or an animator parameter to use. The implementation would be similar to how Physbones allows creators to use custom strings to name parameters that the animator will use and output specific animation reactions depending on the value. Example for the animator: Rotation Offset: There's one feature that Blender has that Unity lacks, and that is using corrective shape keys. Corrective ShapeKeys is a thing in Blender that lets users use bone transform angles to correct deforming mesh based on the angle. So you could bend your elbow in a specific way without needing to redo your weight paints or mesh topology. You could limit the angle of influence of how far the rotation can go for the blendshape amount within the driver itself in Blender. Positional Offset: Similar case to the above, you could also use a child of an empty game object to control how blendshapes look dependent on the child object's transform positional offsets relative to the parent object. If I say dragged a ball that was in world space to the left, I could make the face look angry, or make a character on the screen of a prop on my model move to the left. Examples for shader properties: Vectors, Floats, and Colors: Genshin Impact, love or hate it, is a decent game with an interesting shading style, especially with how they do their facial shadows. HoyoVerse uses SDFs to achieve this effect by getting the forward and right vectors of the head bone to determine the lighting angle along a gradient, and flip the gradient depending on specific conditions. The problem is the only method of doing this within Unity is to change the root bone of a skinned mesh renderer to the head bone rather than the hip bone, which is bad for those that want to have a consistent bounding box across all meshes and for shaders that manipulate the vertices of the skinned mesh. A way to solve for this would be to have a component that could output the forward, right, and even upward vectors to a custom string for a material property to read from and inherit the transform values of. Alternatively you could also output the transform positions for proper dissolve effects or for motion capture based systems that use colors to output, or to even give a good wobble effect/get the volume of a glass bottle for a liquid shader, or have it magically fill up. If possible, this could also be an extension to the Avatar Dynamics, and it could also be implemented into PhysBones for the transforms, but having this be extended to other use cases like the ones mentioned would be extremely helpful and possibly more optimized than using lights + depth tricks, CRTs + Cameras on our avatars, or whatever jank and unoptimized methods we use for our creations.
2
Add Dynamic Props & Modular Elements
Abstract Motivated by the performance ranking system, and upcoming changes to maximum memory usage , a constant recommendation from the VRChat team stands out: "If you have multiple outfits, put each on a new avatar ID" This is, respectfully, bad . For avatars that have one or two static outfits, this would not be a major issue, as this would result in perhaps one or two additional uploads. However, this becomes a significant and exponentially increasing issue with your modern, "modular" avatar. For example, if you have an avatar with 3 tops, 2 bottoms, and 4 hats, this would result in 24 completely unique avatar IDs for one singular avatar , and the detriment of hitching as each variant is swapped to for other players. And this will only get mathematically worse with each additional article. Likewise, many avatar creators may provide props or other objects which are not core to the avatar's function, but which may inadvertently affect its performance ranking. There is good reason for the recommendation, currently; There currently is no way to strike a "middle ground" with modular avatars and their assets. However, this feedback proposes that this should be changed, going forward. This feedback proposes to do so in two distinct ways, which both seek to tackle the same problem from different perspectives, but in ways which can go hand-in-hand . Note that this feedback is not rigid, and can be used as a "springboard" for an actual implementation of any similar system or systems with which to achieve these end goals. Dynamic Props The first of this feedback is to add "Dynamic Props" via a "VRCDynamicProp" component to the VRCSDK, for use with non-essential components. The core functionality would operate as outlined: VRCDynamicProp would be added to any GameObject which the creator deems non-essential to the avatar's performance. (e.g. an umbrella, a sword, a flashlight, a slice of cake, etc.) VRCDynamicProp would have, in the Inspector an array of other dynamic props with which this prop is mutually exclusive. (i.e "this sword is mutually exclusive with the umbrella and gun, and only one may be shown at a time.") In the VRCAvatarDescriptor a list of all dynamic props will be automatically generated. In client, mutually exclusive props will be enforced. Even if two mutually exclusive props are animated to be shown at the same time, only the most recently enabled object will be shown. All dynamic props will be loaded if props are to be displayed, and the memory impact (more on that below) will be accumulative. Modular Elements The second part of this feedback is to add "Modular Elements" via a "VRCModularElement" component to the VRCSDK, to be use with interchangeable elements. Contrasting "Dynamic Props", "Modular Elements" are elements which make up variations of the same avatar, and which only the currently displayed combination will be loaded into memory at any given time. The core functionality would operate as outlined: VRCModularElement would be added to any GameObject which the creator deems modular, yet essential to the avatar. (e.g. clothes) VRCModularElement — much like VRCDynamicProp would, in the inspector, display an array of other modular elements with which this object is mutually exclusive. (e.g. clothes of the same type, such as all hats, or all shirts, etc. — Only one of each type would be shown at a time.) An additional toggle for Include with avatar by default will be provided, which, when enabled, will consider said object as included by default, and include said modular element in the minimum performance rank (more on that below). In the VRCAvatarDescriptor a list of all modular elements will be automatically generated. As with props, in client, mutually exclusive props will be enforced. Even if two mutually exclusive props are animated to be shown at the same time, only the most recently enabled object will be shown. Unlike props, only the current set of modular items will be loaded into memory at one time. This will trade memory performance for loading from disk, giving similar performance to separate avatar IDs, whilst outperforming them by some metric by reducing network load, and maintaining a singular avatar package. Left up to implementation whether or not toggling modular elements triggers an avatar reload, temporarily hides the avatar, or provides some other indication that assets are being loaded. Perhaps something like the full avatar loading display, but it's green? Safety & Performance Impact Performance rankings will receive a new "Baseline Performance" rank, which outlines the baseline performance of the avatar, without optional elements. For all categories, Dynamic Props will be calculated with all objects disabled for the baseline performance rank, and all objects enabled for the maximum rank. This means the maximum rank for an avatar will calculate props accumulatively. For all categories, Modular Elements will contain additional, graduated rankings per category which will not be reflected in the baseline rank. The baseline rank will be calculated using the base avatar with only the default set (see above) of modular elements. The maximum rank will be calculated using the highest (worst) ranking combination of modular elements. E.G. which ever combination of items receives the worst ranking. The avatar file size will include all elements regardless. An additional Safety category for "Props" would be provided, which would allow user to consider props when determining what portions of an avatar are shown by default. If a user's performance and safety settings partially displays the avatar — Props will be hidden entirely if their accumulative performance exceeds the current Safety & Performance settings. Likewise, any modular element combinations which exceed the current safety & performance settings will fall back to the default set for that avatar. A special error icon will be displayed above the user in these cases to indicate that portions of the avatar cannot be displayed. An avatar will only be shown in the event that its baseline performance rank meets or precedes (is better than) the current client safety and performance configuration, without "Show Avatar". On Android & Mobile VR (Quest), avatars with a poor or better baseline performance rank will be shown, permitting the performance rank falls within the user's current client safety & performance configuration. For Mobile VR, avatars with a very poor maximum rank must still be manually shown, irregardless of the avatar's baseline performance ranking, in order to see the full avatar — only the baseline and/or variations which are poor or better would be managed by the client's safety & performance configuration. On Android, avatars with a very poor maximum rank will be unable to be seen fully, period. — Only variations of said avatar, including its baseline which are poor or better will be able to be seen, even with Show Avatar. If the avatar's baseline exceeds Very Poor — Additional calculations will not be made for all categories except memory performance, and those which have their own distinct performance options. Summary By offering two distinct ways for avatar creators to define modular and non-essential components to their avatars, this gives them the freedom to play with complex individual avatars, whilst being given robust choices as to whether elements are included in the base avatar's performance, optional and included in its maximum performance, or interchangeable and therefor somewhere in-between. With one or the other, creators could be limited in distinct ways, but together, creators would have a strong set of tools for a more performant, modular future in avatar creation.
3
Increase the amount of bits available for avatar parameters
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.
0
Load More