Hi, the recent change to performance rank that accounts for material swaps makes sense, but it seems like it’s using the total of all possible material sizes, as opposed to just looking at the VRAM of the worst-performing materials that can be loaded in any given animation. Do all materials stay resident in VRAM at all times? If not, it would be nice if the server processing would account for how you can’t have more than one material loaded on a material slot at any given time.
3 Likes
it is very likely it stays in ram until its needed. until then it will be in vram. and stay there. but honestly you are better off not doing material swapping what so ever as it can easily break batching and other optimizations.
Please use feedback.vrchat.com for feedback and feature request. This forum be not watched by developer team.
I wasn’t really looking to make a feature request here so much as getting clarity on the new VRAM accounting changes.
It’s called “Texture Memory” for a reason, because texture memory is not just VRAM.
But yes, all materials are always loaded in the texture memory - regardless of material swaps.
Are you sure about that? From various performance metrics it seems like it only loads the texture when it’s first used by an active material. And when a material isn’t being actively used its texture resources might still take up VRAM but they’d be the first things to be unloaded from there if other textures need to be loaded in and the VRAM is all full. It would still take up system RAM if Unity isn’t allowed to unload the inactive materials though.
I mean I’ve never seen VRChat load anything from the HDD when switching textures (texture swaps are always instantaneous and happen without hiccups), and I’ve never heard anything suggesting VRChat supports on-demand loading for any avatar resources (in fact I’ve heard the opposite - see link below), so I’m assuming all textures are always loaded into either RAM or VRAM. The “Texture memory” performance metric doesn’t distinguish between different types of RAM, as their placement is usually determined by the engine or platform drivers.
It makes sense though, because imagine if someone creates an animation that swaps textures every frame - while technically they’re never displayed at the same time, they’d still all end up cached in VRAM anyway.
Here’s the link I mentioned earlier
In my experience, if a material uses a texture that doesn’t have “streaming mipmaps enabled” there’s a bit of a performance hitch when the material is first loaded, and that hitch goes away if the streaming mipmaps are set correctly. My assumption is that when the material first loads with that option set, it’s starting with the lowest mip level first and it just completes so fast that you don’t notice the texture quality improving over the next few frames. But I don’t have any particular insight into what Unity’s doing here.
Per-frame material swaps are definitely an edge case that has to be considered, and in thrash situations that would still cause a performance issue for others. I guess targeting the worst-case behavior has some value.
Sadly, VRC loads all your kaboose in to working Memory when the avatar is downloaded. Purges do happen over time, but sadly (AFAIK) what you see is what you get in terms of resource usage. it’s also no using texture streaming or dynamic mesh LOD , which is where things are cached on disk and streamed in to VRAM on load at varying degrees of fidelity based on camera proximity. This is why Avatar culling is such a boon in busy instances, because even though you can’t see the 50 odd people who are well outside the distance of your view, your PC still wants to burn a fan shaped scorch mark through your drywall when you pop in to a busy world with it turned off off.
Yeah, what that post from 2023 shows is just that VRChat doesn’t know how it’s really working:
either you know how it’s calculated and implemented or you don’t.
A vague as Sh*t post that doesn’t really give any answer to how it works just shows how bad their understanding of how it works is …
it’s more than time to dig seriously in a better non load everything into VRAM / uncaching and on the fly loading of the real used textures imho.
The new way of calculating and including the texture swap /materials makes sense and is more precise, if it is really loading 100% of everything that is into the avatar’s package (but why ???)
but the fact that it differs from what the SDK calculates is crap!
Thry’s Texture VRAM calculator has been able to do that with a good enough precision for years now, why the heck doesn’t VRChat implements something similar so that we know beforehand the real rank we’re gonna be.
It’s not because the server side language is not the same than the SDK language that you cannot do it..
Just do it and impletement it on both sides when you’re ready only !
Now fortunately I have already optimized all my avatars to medium or better and taken material swap into accounts through the use of Thry’s excellent tool. But it sucks not to be 100% sure and having to check everytime on the server side if it’s gonna be poor or verypoor.
Now also, my main complaint is that as it has taken years for VRChat to implement these material swap calculations, the VRAM limits are way outdated and should be revised
Because VRAM on Graphic card have increased in all those years.
the limits are outdated and should be increased.
Same for the max poly count on avatar meshes.. (and it makes no sense to jump from medium to verypoor directly if you’re >70k !)
VRChat : time to update those limits !
My main complaint for the performance calculator is that it ranks you based on the lowest score instead of the overall score. I have an avatar that by all accounts is pretty much Quest Compatible, most of the stuff in the performance metrics are green or bright green, there’s a few that are orange, and the only one red, but it’s not over the quota, but the avatar is still rated Poor despite being mostly fine.