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.
