At current, there is no method to use LODs for avatars, which is one of the primary causes of poor performance in populated instances.
VRChat has implemented several workarounds to this issue, but not addressed the issue directly; developing functions such as hide by distance. Whilst this is a great feature for lower to mid spec systems, this leaves a gap for users with higher end machines or who prefer visual fidelity and sense of presence over framerate.
It is common practice within game development to use LODs on assets such as characters to save on system resources by doing the following:
  1. Reducing material complexity, i.e. using simpler / less fancy materials.
-> As a practical example, disabling a grab pass on LOD1 and beyond.
  1. Reducing armature complexity to reduce the amount of physbone transforms to compute per avatar & disabling collisions.
-> Another practical example of this would be a mechanical avatar using VRC constraints and physbones in tandem to obtain a certain stylistic choice could be simplified within certain LOD group ranges to reduce the amount of processing the CPU has to do.
  1. Reducing the resolution of textures to reduce VRAM usage.
-> Whilst VRChat already has implemented mipmap streaming, this does not reduce the amount of memory being used. An implementation VRChat could use to handle proper texture management would be if an avatar has been in a specific LOD zone for too long, it unloads the streamed mipmap texture from memory and replaces it with a lower resolution texture. The correct high resolution texture could then be put back in its place upon entering a closer zone.
There are also multiple ways in which LOD handling could be done:
  1. Allowing users to select a faster performing version of their avatar they have uploaded.
  2. Allowing multiple LODs to be uploaded into the same avatar, with the client dynamically changing to the necessary avatar.
  3. Automatically falling back to imposters when beyond a user-defined limit.
-> This option would replace the diamonds we see with distance hiding.
->-> This should not replace the diamonds we see at current, rather being an intermediary step between the full avatar being shown and hiding the avatar entirely.
->-> This would also reduce the requirement of the animator being permanently loaded even if the remote user is multiple hundred meters away.
-> This option would more than likely be the simplest to implement.