[1281] Texture Memory stat doesn't include textures from matswaps and animations.
tracked
Fizzytaco
The new version of Thry's performance tool gives an overall texture memory value. This value was differing from the ingame stat on some avatars.
Through testing, I've discovered that if you use an animation to swap a material, the textures on that other material aren't counted in the ingame stat.
To reproduce the bug, you can upload the AD Tutorial Robot avatar included in the sdk. Thry and VRC will say it has 5.33mb of tex mem.
Then create an 8k texture and add it to a new material.
Set up an animator on the fx layer and add an animation to swap a material of the robot to the 8k material on load.
Thry will report 48mb of tex mem, but VRC will say it's still only 5.33mb.
You can see the screenshots of it below. And see the 8k avatar yourself in game with the avatar ID: avtr_95b5d5fd-0068-4513-89fc-fa1c6b6703f3
I've relogged and uploaded it separately to verify. I also checked the asset bundle log and it is including the 8k texture on upload.
This is a big issue. Someone could easily make an avatar that has 1k textures by default that get swapped to 8k on load. The performance stats would claim the avatar is fine all while it's filling up vram.
Log In
Adeon Writer
Server side avatar rank is also making this same error
Adeon Writer
VRAM metric is currently live and is not accounting for textures swapped in by animations.
This is an major problem as there is no limit to how much VRAM you can consume while still being rated as excellent both in Unity and in the app.
There is no way to know your true VRAM including animations outside of third party unity tools, which not everyone will use.
If this isn't fixed soon it may be perceived as a rating change as many avatars should be poor rated that are currently not.
_
_tau_
Merged in a post:
Cubemaps aren't counted for VRAM performance ranking
DJ_piercy
I made an avatar that uses a cubemap to achieve a visual effect. (this is the only texture used in the avatar) When I went to check on the performance data, It showed that it only used 0.67 MB of texture memory. This is obviously incorrect, as the cubemap is a 1024x6144 texture, and a 2d texture with those dimensions would require a lot more memory.
HK
tracked
DarkSwordsman
Glad this was brought up! Good it was caught early since this would theoretically be an easy way for people to get around limits, plus it would take even more texture memory for the swap to exist than just having 8K.
JessicaOnMain
Can concur this is an issue. Changed 4 textures that are part of a mat swap from 512 to 4k and while my download size went up nothing changed with texture memory.