MisutaaAsriel
Preface
Whilst the team at VRChat likely has busy schedules, and especially in the wake of the realization that perhaps focus on rapid iteration of QoL & accessibility features is necessary, I was hoping someone with technical knowledge could take the time to explain a little further on how the Hide Avatar by Distance system functions,
on a technical level
?
There is, I'm sure,
plenty of us in the VRChat community who would more than love the,
I quote
,
"pretty in-depth"
explanations of how one of our favorite platforms work.
— For some of us, that is the difference between knowing
why
something behaves the way it does, being capable to work with it, and
being able to file effective feedback
; and merely filing generalized feedback whilst we operate under the assumption that VRChat is "broken" or in disrepair.
On Write Defaults
As it stands,
Write Defaults is a necessity for many complex state machines
on Avatars; Working without Write Defaults is nigh impossible with these avatars, as the sheer amount of "exit animations" required, let alone the conflict of blended/intermingling states, would
more
than double the work, if not triple, needed to carry out the same functions.
However, there's still questions to how avatars are actually, well,
hidden
.
And How?
As it stands, the behavior
appears
to exhibit the following, based on both user experience and existing developer language:
  • Avatars are removed from the visual plane
  • Animators themselves continue to run
  • Animator
    properties
    , or animations themselves, are perhaps
    partially
    culled.
  • Properties or Animations which are culled do not properly reset when un-hidden
  • This is perhaps why Write Defaults is problematic; The nature of animators
    without
    write defaults means that they will have a series of "exit animations" which will effectively
    reset
    the avatar's state; upon being un-hidden, these animations will fire, essentially meaning that
    all
    avatars are broken, but that avatars
    without
    Write Defaults are
    self-recovering
    .
Speculating, there are a number of ways which the avatars
could
be hidden, each with unique drawbacks. However, I myself lack some knowledge in Unity behaviors to have any
solid
notion exactly how the VRChat team has done this.
Unity is like an onion...
The easiest method, to my understanding, however, would be to
leverage Unity's layer system to move avatars to a reserved layer which is "culled" from the player camera
; This would essentially make player avatars present,
but invisible
, removing them from draw calls whilst still running their logic in the background.
In
theory
, as I do not yet have a full grasp on the intricacies of Unity, if the Animator's
cullingMode
was set to
AnimatorCullingMode.AlwaysAnimate
, it would continue running critical animations
off-screen
, meaning avatars with Write Defaults would not break.
However
, conversely, this would mean that logic & animations for these avatars would continue to run in the background, reducing the performance savings. The only savings would be on the actual drawing of the avatar to the screen.
This would still offer a considerable benefit to platforms, like Oculus Quest, where complex avatars making frequent draw-calls severely hamper performance.
There is a reason the avatar ranking system is so drastically different between mobile & PC, after all.
— In public lobbies where there are a considerable number of complex avatars, where a user may desire to see those avatars when up close, but no longer when they are actively nearby, this could still offer a potentially-considerable performance boost.
By other means...
Tupper laid out in the August 5th Developer Update that there are other means, for sure, which could be used to hide the avatar, or to resolve conflicts with Write Defaults, but each with their own issues.
｜
As for some examples: fully unloading and reloading/reinitializing the avatar is really heavy. We can’t do that. Stopping the animator isn’t good either, as we could run into issues. Can’t hide renderers easily, as we’d have to fight with animators for control – setting something every frame, which could be bad for performance.
From this it is at the very least clear:
  • The avatar is not being "unloaded" — The GameObject itself is still present.
  • The animator
    itself
    is continuing to run; disabling this would likely cause issues with
    all
    avatars getting stuck, rather than just those with Write Defaults,
    I imagine
    .
  • The Mesh Renderers are not being disabled; this makes sense, as this could break avatars with multiple meshes which are intermittently displayed.
But Why?
In all, you may ask yourself:
"Why go through the effort to explain the technical underpinnings of something that is subject to change?"
However, the VRChat community isn't just filled with
e-Kid avatars and asset rippers
. Heck,
the modding community itself has, if you will bare with me, proven an invaluable asset in helping VRChat these past couple of years determine the direction future feature-updates should take;
OSC, accessibility updates, QoL improvements, Avatar Dynamics,
and more!
By being up front with us; By
going into those
"in-depth explanations"
; VRChat can potentially leverage the more talented and technically inclined folk to power future solutions to VRChat's problems; To collectively brainstorm, troubleshoot, and implement solutions which further the very platform.
...
After all, people didn't mod VRChat for no reason.
Perhaps they felt they were not being heard.