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,
. 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
worse with each additional article.
Likewise, many avatar creators may provide props or other objects which are not
to the avatar's function, but which may inadvertently affect its performance ranking.
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
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
    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
    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
    would, in the
    display an
    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
    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
    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
    avatar IDs, whilst outperforming them by some metric by reducing network load, and maintaining a
    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
    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
  • 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
  • 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.
    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.
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.