Avatar Uncompressed Download Size Limit Bypassed
tracked
Celaline
This is tested with 13 4K PNG textures; normal compression (first image), normal compression + crunch compressed at 50% quality (second image).
Contrary to popular belief avatar download size (as suggested in unity) is not significantly reduce for avatar uploads; VRChats LZ4/LZMA compression is already handling the heavy lifting of download size reduction so there is evidently severe diminishing returns to using crunch compression.
From my understanding the LZ4/LZMA algorithm is exceptionally good at finding and removing redundancy. Adding Crunch compression on top provides diminishing returns because there's little additional redundancy for LZ4/LZMA to compress.
Here is what needs to be addressed immediately:
Uncompressed size being drastically reduced in avatar stats when fundamentally this is not what crunch compression does. This in turn is letting people bypass the 500mb uncompressed download size limit.
This whole dilemma could be resolved by simply disabling crunch compression for avatar, especially since crunch compression will cause loading textures onto the GPU to be a bit slower for virtually no reason.
Photo Viewer
View photos in a modal
Log In
Tupper - VRChat Head of Community
Hey, thanks for the detailed writeup and screenshots. this is a good one to talk through because the terminology is confusing.
The "Uncompressed Size" stat is reporting correctly here. It's measuring the size of the asset bundle's data when decompressed from LZ4/LZMA, _not_ the amount of VRAM the textures will consume at runtime. Crunch compression changes the actual texture data that gets stored in the bundle, so the uncompressed size does genuinely go down. That's not a bug or a bypass, it's what the stat is measuring.
"Texture Memory" is the stat that reflects GPU memory usage, and as your screenshots show, that stays the same at ~138 MB regardless of crunch settings. That's the number that matters for runtime performance impact on other players.
So the 500MB uncompressed limit isn't being "bypassed," it's just that uncompressed bundle size and texture memory are measuring different things, and the naming makes it easy to assume they're the same.
That said, I think the underlying concern here -- that someone can have a very high texture memory footprint while staying under the uncompressed size limit -- is a fair one to raise. I can't make promises on timeline or specifics, but it's something we're aware of.
Tupper - VRChat Head of Community
Hey, thanks for the detailed writeup and screenshots. this is a good one to talk through because the terminology is confusing.
The "Uncompressed Size" stat is reporting correctly here. It's measuring the size of the asset bundle's data when decompressed from LZ4/LZMA, _not_ the amount of VRAM the textures will consume at runtime. Crunch compression changes the actual texture data that gets stored in the bundle, so the uncompressed size does genuinely go down. That's not a bug or a bypass, it's what the stat is measuring.
"Texture Memory" is the stat that reflects GPU memory usage, and as your screenshots show, that stays the same at ~138 MB regardless of crunch settings. That's the number that matters for runtime performance impact on other players.
So the 500MB uncompressed limit isn't being "bypassed," it's just that uncompressed bundle size and texture memory are measuring different things, and the naming makes it easy to assume they're the same.
That said, I think the underlying concern here -- that someone can have a very high texture memory footprint while staying under the uncompressed size limit -- is a fair one to raise. I can't make promises on timeline or specifics, but it's something we're aware of.
Celaline
Tupper - VRChat Head of Community
I didn't think texture memory and uncompressed size were the same.
I was assuming that uncompressed size included decompressed/uncrunched VRAM-compatible textures, thanks for clarifying.
I still think current avatar statistics model encourages crunch compression which is not good for a enjoyable vr experience considering the compromise.
20%~ less download size for increased load times and hitching is a very poor trade in a dynamic environment like VRChat where assets are loaded during gameplay.
Celaline
Tupper - VRChat Head of Community
I would also like to ask; what is the actual point of "Uncompressed Size" then?
You're right that "Texture Memory" is the key stat for VRAM, which is the main factor for sustained performance. My point is that the uncompressed size has a direct indirect impact on real-time gameplay because it allows avatars to include significantly more data (animations, meshes, asset files) by hiding the true cost of textures via crunching, potentially allowing a extra 450mb of data to be uploaded "Secretly" defeating the performance ranking aspect completely.
Since crunching can reduce texture data in the bundle by up to 90%, creators can pack in much more content while staying under the 500MB "Uncompressed Size" limit (I feel like i have to make this clear, i'm not talking about the Texture Memory limit here). This means the uncompressed size no longer reflects the total asset complexity (If that is the actual purpose?).
The performance cost isn't just in VRAM; it's also in the CPU time required to uncrunch textures during loading, which causes hitching and freezes (extremely uncomfortable for people in vr by the way). So while the limit isn't technically bypassed, the current system incentivizes a practice that degrades the real-time experience for everyone while also making performance statistics less accurate.
it's simply a lose-lose situation regarding specifically avatar uploads (it's actually good practice for worlds). One could argue that the 20% download size reduction does benefit vrchat pockets (spend less money on cloud servers/storage and bandwidth) but that compromise is very anti-consumer.
I really feel like this invalidates the performance estimation purpose of the whole ranking system and should definitely be addressed prior to the upcoming Avatar Performance Gating system.
TL;DR:
Crunch Compression allows creators to pack significantly more non-texture data (animations, meshes, etc.) into an avatar by drastically reducing the texture data's contribution to the "Uncompressed Size" limit.
Celaline
Tupper - VRChat Head of Community
I'll ask again; What is the actual point then?
The appearance of optimization or the reality?
How do we get better performance in VRChat?
Well surely not by changing the triangle count rating brackets or fiddling with what colour your precious avatar has in it's statistics.
The actual upload limits is what really matter.
Why degrade the game to please ignorance and refuse change?
This is why we can't have nice things.
'What is the main reason fps is low in a populated VRChat instance?'
From my understanding:
GPU:
High-resolution textures
CPU:
Animator complexity
BOTH:
Material and mesh count
So, how do we actually enforce good performance yet keep the sexy anime girls that the loudest people in the community treasure so much?
Create fundamentally functioning evaluation and limits for the things above so people are brute forced to learn how to have the cake and eat it too.
Right now the hard limits for uploading a avatar is obnoxiously bad and might as well not even exist.
-Texture Memory- 500mb limit and pseudo-included in 'Uncompressed Size'
-Animator complexity- ONLY Download size is included in 'Uncompressed Size'
-Material count- HAS NO LIMIT
-Mesh count- HAS NO LIMIT (mesh download size in 'Uncompressed Size')
So how do we solve this realistically at the moment with the least amount of effort? be it a temporary solution or not things has to change and i can't see a better opportunity than now (Avatar Performance Gating system).
First: A limit for material count and mesh count, why this has not been done yet is baffling to me and i assume this has been discussed before but please enlighten me if there is a valid reason for this not to be limited.
Second: Lower the limit for 'Uncompressed Size' and 'Texture Memory',
I suggest HALVED for both with leeway on 'Uncompressed Size'.
Third: Ban Crunch Compression for avatar uploads specifically.
StormRel
marked this post as
tracked