Add Dynamic Props & Modular Elements | Voters

Add Dynamic Props & Modular Elements

MisutaaAsriel

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.

March 19, 2024

Kazy

I think the main problem is that the way Unity works, you can't just "not load" something into memory, even if it won't be shown.

It takes time and processor power to load something into memory (thus the blue diamond avatar while an avatar is loading), and you would have to revert to that every time you're loading a new prop into memory.

MisutaaAsriel

Kazy you can actually, via Destroy. And you also misread, because I explicitly mention that all props (first category) would have their resource usage calculated cumulatively
. That is, all props would count towards memory usage together. If props are enabled, they are loaded in memory together and counted. Full stop. Regardless of which props are displayed, their memory impact would be the same.
What wouldn't is modular elements (second category).
 But what I described would still possible.
Conceptually, if the SDK were to track these objects, it could separate them from the base prefab, allowing them to be dynamically loaded. For props
 (first category), these objects would be bundled into a single separate prefab, so if for any reason their display is restricted (performance, safety), they can be destroyed as a unit. For modular elements 
 (second category), individual items would be stored separately, so they can be loaded and destroyed at will.
You are correct, this process will incur a momentary performance impact, as objects are loaded and destroyed in memory. However, the impact would be close to that of loading a cached avatar from disk, which is significantly more performant than loading from the network. This would also offer a trade off in the form of a better performing avatar, and, most importantly, would be better if not no different than if every permutation of avatar combinations were uploaded as separate avatar IDs in terms of performance.
Even still, there are likely other ways to achieve this effect, each with its own unique series of trade offs. Hence why I said "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."

垂暮龍-青月

In my opinion, there is also a need to implement Bidirectional animation parameter drivers and object hierarchy placement to realize skeletal binding effects when loading, and even to allow constraints or physbones and contact settings when conditions allow.
Even deeper, there is Overlay Animation to replace the original animation and so on.
Except that this introduces a degree of coupling between the two objects or modules, and requires an abstract idea of a common specification to simplify the overall structure, or for people to decide the details.
If this could be done, it would be a great achievement, and would successfully unravel the complex relationships within the modular incarnation.
These ideas also apply to the world.