In this video you will learn how to optimise your avatar for Quest (but also for PC) using Unity and Blender.
We will be using these 4 methods :
Awesome! Exciting to see a Quest upload tutorial that doesn’t ignore the giant line of red exclamation marks lol
I like optimisation. It’s just difficult and time consuming.
I thought about making a PC optimisation video like “I made a very poor avatar into good performance in VRChat”, it’s a clickbait title but I could record the whole process of optimising it and actually show people. I’ve also done this before with some avatars.
Not just difficult, but also dynamic! There is no 1-2-3 set of steps that work for every single avatar, and no single number you can look at that tell you if you’ve achieved your goal or not.
However, once you really get into it, you end up understanding so much about avatars and their systems and what costs performance, and you only gain from that!
I think about what would help creators learn how to make more optimised stuff all the time, because I work with avatars everyday and I see what people make etc.
The thing is for a lot of people who really like making stuff in Blender, the Unity part is difficult for them and they do not want to spend much time setting up the avatar in Unity.
I do Unity commissions for private avatars and avatars for sale, so I can see what creators struggle with.
Tbh what would help optimisation of Quest avatars now would be a shader with a UV Tile discard.
People have to use separate meshes or bone transforms to 0 to make toggles on Quest. And you cannot really always use bone transforms for this so you use separate meshes. Which increases the amount of skinned meshes, meshes and material slots.
Please do not recommend disabling Mipmaps for lowering texture memory. They exist not just for improving how your textures look when viewed from further away, but boost rendering performance by reducing memory bandwidth usage and making certain kinds of operations more efficient. You can find more information in this write-up: Optimizing Texture Memory (VRAM) & Size | Poiyomi Shaders
Lowering texture resolution is the most important thing to do when optimizing for texture memory, but choosing an appropriate compression format can also help! Higher quality formats at a lower resolution may yield smaller file sizes and better visual quality than the default formats at a higher resolution!
I missed this in the video, as I didn’t watch it thru – yes, seconding. Please do not tell people to turn off mipmap generation, that’s bad.
If your avatar is 10.03 Mbs, it’s the most sensible thing to do, to disable mipmaps on a really small texture or a matcap.
It isn’t worth the performance cost on an already-stressed mobile GPU.
To save 30kb, it’d be much better to drop the resolution on said texture, like a mask or matcap.
Quest Shaders do not offer masking, the only mask available is Details Mask on Standard Lite. So that’s out of the window for Quest avatars.
And I tell people to lower resolutions right before I tell them about mipmaps, I specifically mention lowering the resolution of matcaps.
So the mipmaps are the end solution when everything else has been done.
You’re right on the masking.
Are these cases where every single texture is at 512 or lower? 
Disabling mips should never be done, except in very special cases where it’s required for shader usage.
Turning every texture into 512 will make it look like garbage.
I use 2k x 4k rectangle atlases and sometimes one 4k Atlas and it’s good enough to fit within the 10mb.
I am not giving up looking good, when I only need to get rid of few decimals to get below 10mb and I can do that with disabling mipmaps on something small like a matcap or a small texture.
You don’t need 4K textures to look good! That’s where the disconnect is, I think.
For comparison, this avatar of mine has been optimized such that no textures on it are above 1k:
Same for this one – (excepting the logos on the shoulder, that’s a single 2K image):
Now, these are PCVR avatars, so things are quite different. Shader features let you cheat a little bit. On Quest, you’d have to do all of this with smart UV mapping. I’m illustrating that having massive textures does not equal high quality.
However, I really don’t think it is advisable to tell someone to use 4K textures, and then turn around and disable mips to save a little bit of filesize. That’s the wrong order of operations.
Dropping to 2K will chop that texture’s size by 75%, and if your UVs are good, will not affect appearance. If things appear blurry that you want to preserve detail on, it means your UVs are not mapped well, and you should consider re-baking in a new layout.
You should also make sure you’re viewing the avatar from a reasonable distance. A meter away is ideal. If you’re shoving your editor camera up in a texture seam and see a difference when you drop from 4k to 2k, well… that’s expected. Instead, you should be checking from where 99% of people will be seeing the avatar – a meter away, at eye height.
FWIW, I’ve seen some Quest avatars with basically no detail across their texture – the one I’m thinking about is a flight suit that’s basically just black across the entire texture. I was confused by its VRAM usage, so I looked at it, only to find that it was using 8K textures (!!!) for that giant swathe of same-color space. Sixty five million pixels, all black!
Dropping mips to fit into a filesize really shouldn’t ever be a course of action you take.
How many 1k textures do you use here though ? I literally use only 1 4K atlas and 1 2k x 4k rectangle maximum, nothing else except a material with a matcap.
I also think you underestimate how peoples’ UV can be. Not everybody can be as skilled as top 1% of people and make that good assets. If people would be like “this needs to really good or nothing” most of them would not make anything because it’s unreachable for them.
And of course using 8k textures especially for something purely black makes no sense.
Off the top of my head, I think the Runa uses 3 matcaps set to 256, 3 diffuse each at 1k, and a few masks all at 512. Three normal maps, all 512, used for tiling/stochastic sampling, and one overall normal map at 1k. I think my total texture usage is just over 1.5 times a 2k texture if you sum them up?
I’m not saying “everyone should redo their UVs”, I’m saying “please don’t tell people to hurt GPU performance so they can fit a massive texture into 10MB”. That’s all. The rest of my post is fluff and demonstrative.
There are better ways to fit within that 10MB. I worry about it being mentioned as part of a tutorial, as spreading that kind of knowledge can be harmful. That’s why I’m posting here.
I don’t think it’s as harmful as you make it be. To me (And I’ve been doing this for over 3 years everyday) it just seems like chasing the perfect solution at all times. People are not going to do that.
If you want, you can delete the tutorial from here.
No, no, I don’t want to do that.
I think this discussion serves as an adequate warning. I also think that detecting disabled mipmaps in the SDK and doing something about it (preventing it, advising against it, etc) is probably a better solution… but that requires I find an engineer to work on it, which is quite hard, as all of them are busy on Things.
I like it when I stir up things and things are actually getting changed
Silent has proposed a set of rules in this Canny
While at first they seem a bit complex it’s a necessity to protect edge cases where disabling Mipmaps is needed.
I hope VRChat will consider these rules and implement it if not something similar if a Mipmap requirement is included in a future SDK.
