Optimizing your avatar or world or 3D asset is a massively important part of the avatar creation process. In general, increasing the render efficiency of your avatar means that it has less impact on your, and other people's framerates.
VRChat has performance ratings, but these are only rough guides to actual optimisation. They're not that bad when you actually understand optimization, but this article will focus on one thing: Reducing the time it takes for your avatar to render. It is definitely possible to make an 'Excellent' avatar that is godawful, or a 'Very Poor' avatar that's extremely performant; at the extremes, but even at middling values it only records the totality of the avatar and does not represent what the avatar is like during render time. With Avatar 3.0 and lots of toggles it has become increasingly unrepresentative.
The Process
Actually working on optimizing your avatar will be a balancing act between how many shits you give, what kind of environment you expect to use the avatar in, and how many features you want.
It's recommended to focus your efforts on making appropriate avatars, rather than min-maxing optimisation every time. For example, an avatar you're going to use in a crowded instance you will definitely want to optimise as much as you can, else you'll be performance blocked and no-one will see your cute avatar. For instances where it's just a few people... or just two people.... then you can basically not optimise at all and be fine. Plus, some optimisaiton is harder than others. For most avatars doing the quick wins can get you a lot of extra frames for little effort.
Optimisation covers both blender and unity since the final asset is built in both. Some things are kind of blended between editors.
Focus areas:
Number of distinct mesh objects
Vertex Count (number of polygons)
Texture Size
Material Quantity
Shader settings
Use of Blendshapes on high poly-count meshes
Number of bones
Physbones (previously dynamic bones) count
Number of animator controller layers
Other crap added (particles, Lights, etc)
The main render/resources to be focused on are:
VRAM / RAM usage
GPU Frametime / Framerate (How long the avatar actually takes your GPU to render)
CPU Frametime (How long the CPU takes to go through all the avatar's logic and drawcalls and shit)
Download size
Unity Rendering tidbits
Understanding how unity renders things is important. Details may be in the focus areas but in general:
Inactive game objects contribute to file size and VRAM/RAM usage, but if they are deactivated they are not rendering and do not effect frame times.
Unity treats the VRAM and RAM as a sort of hybrid cache; the takeaway is that assets from inactive game objects get moved to RAM after a while, but pulling shit from RAM to VRAM is still slower than pulling from VRAM to present something onto the screen. Larger the inactive game objects, the larger the lag spike when the game object is toggled on.
Textures are uncompressed in VRAM. Texture size is the single largest overriding factor in VRAM usage.
Focus Areas
These should be roughly sorted by ease of optimisation. Removal tends to be the most efficient optimisation for any part of an avatar.
Other Crap added (Particles, Lights, etc)
Reduce these as much as possible, basically. Easy to optimise since you have to go out of your way to add these things.
For the Dynamic Penetration System, this uses lights to coordinate mesh bending.
If they're turned off they won't do anything though. Optimise by leaving them OFF by default, and try not to leave them on accidentally.
Remove from optimised avatars
Using Pumkin's tools - open the pumkins tools tab, load your avatar into the tool, and look for the "delete all" options. Or look through your avatar for particles and other items and remove them.
If using a prefab, they'll typically be on a toggle so you can check the toggles to indicate what you should remove.
Leave off when not in use
Shader settings
Generally: don't use effects you don't need, and try and use the same shader as much as possible. Shaders are basically code that runs on your GPU and the fancier the effect the longer it takes. GPUs are fast at running them so you honestly don't need to worry about performant shaders much at all.
Except in a few cases like reflection probes, grab passes, and computational heavy stuff that usually has to do with light bendingy and lensy type effects.
Don't be scared from using shader effects and material maps and caps and such, they're pretty and not that bad at all. Normal maps and mat caps were developed as faster ways to render detail than polygons or fancy lighting effects, after all.
Access the shader settings through the material settings. Conceptually, a material is the shader, as the shader is just code that runs that decides how the mesh is rendered. Multiple ways to do this:
For External materials, the settings can be found by locating the material in the project folders, and clicking on it to make it appear in the inspector. Remember you can lock a tab to the current thing; since clicking around happens quite a lot.
The settings can also be found in the mesh object. If you select a mesh object in your scene, there will be a drop-down menu for each material that is applied to that mesh.
Process
Avoid using heavy shaders like ones with transparent grab passes.
A transparent grab pass has to pause all rendering to render what is behind the transparent object. While this is useful for things like lenses and other light refraction type effects, it is an effect that is expensive to render time.
Performance: Opaque > cutout > transparent
Leave (back) culling on if you can. Nobody actually needs to see your nipples from the inside.
Using maps, cutouts, speculars, etc etc all have a minor performance draw
funny poiyomi effects also have a small impact
Number of bones
More bones = more shit that the game has to calculate when you move around. To optimise, reduce the amount of superfluous bones.
Performance impact from this is low for just having bones that exist; but pretty high for bones that will have physbones attached to them. Long chains of lots of little bones are bad for performance.
Minimal effort: Delete bones you aren't using. For example you deleted a skirt mesh, get rid of the bones too.
Low effort: Use CATS to merge the bones. Merging them with CATS will take the weights from one bone and merge them into the other, and delete one of the bones.
Find Model Options > Merge Weights.
Select the bone you want to merge and remove; then use ctrl-click to select another bone. Then hit Merge Weights - To Active. Or select one bone and hit 'To Parents' to merge it to the parent. This is most useful for reducing the amount of bones in a chain; some hair has a million bones and even with physbones it's overkill.
Reduce Bone count by deletion or merging
Number of Animator Controller Layers
The number of layers in your animator does actually matter when it comes to performance. Generally don't worry
at all about it under 20 layers; but if you start to make loads of layers you can save some performance by redu
cing them down. additionally, weight 0 layers take up CPU time and that's a unity bug.
Try not to do more than 20 layers
Zero weight layers still count
Use of Blendshapes on high-poly meshes
Shapekeys work by recording the difference on every single vertex between one state and the other and interpolating between them for the partial shapekey activation effects. This actually takes additional processing power
and gets more difficult the more vertexes there are.
Facial gestures in VRC are usually done with shapekeys on the face. If the entire avatar is just one mesh, each time the shapekey is used the GPU has to calculate positions for every single vertex in the entire avatar, clothing and all - not just the face. This is why you make or keep the face seperate - the facial gestures are activated often and cause a performance drain if there are lots of polygons.
Keep in mind that If the avatar is under 20k polygons in total it's not a big deal, the render cost goes up a little non-linearly.
Number of Distinct Mesh Objects
Every seperate mesh requires a drawcall to activate. This is a set of instructions that lags the GPU until all
the resources required to render the mesh are loaded and calculated. This happens every frame. Uncombined meshes basically waste GPU time on absolutely nothing and there is usually no reason to have them seperate.
Join meshes in Blender. Use ctrl-j to join your meshes. One except: High poly areas with shapekeys, like the face. Do not join the face to everything else.
Before joining everything like a madman, there are several reasons you'd actually want seperate meshes:
To have different outfits/props.
to save performance on shapekeys.
To reduce the amount of polygons rendering at once.
Actual optimisation is going to be a balancing act between enough meshes to get the functionality you want, without being too laggy. However; when making a maximal optimised avatar at above ~30k polygons you should have only two meshes; the face, and everything else. For avatars that are specifically low polygon, the reduction in drawcalls helps more than the shapekey issue. Balancing act.
Note that only active meshes actually take a drawcall. You could have 10 meshes, but if only face, clothing, body are the three meshes all at once, this will actually perform the same as a 3 mesh avatar. The VRC performance stats can't tell the difference between 10 all at once and just 3.
Minimise meshes that are rendering at the same time
Join meshes
For unjoined meshes, do not have many active at once.
Vertex Count / Poly Count
Fairly intuitive, more polygons the more rendering that needs to be done.
Polygons are also often referred to as verts, so a vertex count can be thought of as an analogous measure, as polygons themselves can be tris, quads, or beyond.
The general rule is to reduce the amount of polygons to a sensible limit. Like all other optimization efforts, there is a balancing act between effort, performance and fidelity. A model with more polygons will usually have more detail, although detail can be added with effects such as normal maps, mat caps and other shader rendering effects. Also keep in mind that shapekeys are per separate mesh object, and the amount of vertexes affects how much computation is needed to process a shapekey when active.
Reducing vertex count can be done in a number of ways, some more time intensive or destructive than others.
Mesh Deletion
The simplest and most effective means of vertex reduction is simply to delete mesh you don't need. This can be excess ribbons, adornments or other features, or deleting mesh that isnt even visible, such as skin under clothing, or layered outfits.
To delete mesh that is part of a mesh object, [>>todo: explain the difference between a mesh object and linked vertexes] select the certexes you want to remove in edit mode and press delete. To help you select mesh the following can be used:
Circle select - c
Box select - b (middle mouse button deselects from current selection)
shift + clicking individual verts
select linked - l and ctrl-l
Different views: wireframe, xray mode
h and alt-h to hide current selection to preview your deletion
knife tools- to cut new vertexes into the mesh for finer deletion
separate into new mesh object - p
You can also delete entire mesh objects, removing them from the model.
When deleting your mesh it is worth also checking the armature to see if any bones were for mesh you just deleted and removing them too as they are now useless.
Also important is that deletion is a destructive process and you should save iterative copies (ctrl-shift-s) so any mistakes can be easily fixed down the line. Trust me on this one.
Decimation
Decimation is another destructive process that forcefully reduces vertex count by automatically merging polygons together. Most useful on suspiciously high polygon clothes, attachments and hair.
To decimate, first separate out the mesh you want to have the polygon count reduced on by selecting it and pressing p.
Then in object mode with the mesh selected, go to the modifiers tab (blue spanner) and find the decimate modifier. Use the modifier to reduce the polygon count. if you get a non zero shapekey error, open the dropdown on the mesh object and delete shapekey data. This will delete all the shapekeys on that mesh.
Decimation is a pretty brutal process but it can be very effective, but keep in mind the following guidance:
Don't decimate the face. it has so many goddamn shapekeys and is what most people will be looking at the most
Hands, fingers and other joints get super fugged by decimation so avoid those areas.
It is often a good policy to not decimate the base skin mesh at all. the topology on that is often efficient already, and you'll likely cause yourself some problems.
Separating Mesh Objects
This is for when you have multiple meshes, such as outfits, but you don't need them on at the same time, such as two different hats, even two entire different outfits.
Why this is optimisation and not just a weird opposite of the earlier message to join meshes, is that your priority with a unity avatar is to reduce the amount of meshes rendering at the same time. Any deactivated game object is not taking up draw calls or other resources, so to have multiple outfits, the optimal play is to have only one rendering at once, one mesh, one outfit; for a total of 3 meshes rendering: face, body, outfit. And with many outfits on the same avatar that can be switched to but only using 3 draw calls at once.
Of course the most optimised is to have just one outfit, merge the body and outfit, delete unwanted mesh [>>todo: example use cases] and not change outfit. But to change outfit you would need to change avatar, and that would make everyone else in the instance reload the entire avatar just to have you put a hat on. The balance between fun and performance should always be a factor in how hard you optimise.
Anyway, the blender part of separating meshes is pretty simple:
Select the mesh you want separate
Press p to make it into a separate mesh object
Give it a name
Make a toggle for it in unity sometime later
Some people will make outfit toggles that are shapekeys which hide the alternate outfit inside their body or something. These people are indeed wrong, but they are saving a draw call or two. However, they are also adding two more performance hogs: the hidden mesh is still rendering and will take frames even though it is hidden inside the avatars. The shapekeys are still requiring calculation on the higher poly mesh of both outfits at once. This usually outweighs the benefits of saving a drawcall. I think- if anyone wants to test how many polygons a drawcall is worth that would be good to quantify.
Retopologising
This is an advanced technique that is for when you are making a from scratch model and want to clean the topology. it will murder your texturing, though. best done before texturing.
VRAM usage
Everything your avatar uses to render is stored, relatively uncompressed, inside the VRAM of people's GPUs as they render your avatar. VRAM is a limited resource, and while unity does some dynamic memory pool stuff between RAM and VRAM, when it swaps data between these two locations it is relatively slow. Once VRAM is overloaded rendering slows down significantly and frame rate drops. Therefore for an optimized avatar you will want to reduce the amount of VRAM your avatar uses.
when a texture or mask or map is loaded into unity, you configure what size the image is resized to when bundled into the game asset. The size or type of the image you drag into unity doesn't matter, it's resized as one of the things that unity takes so long on when uploading an avatar.
VRChat now checks for VRAM usage, thankfully, so everyone is going to actually pay attention now. Like you should have been in the first place.
Crunch compression compresses the textures OUTSIDE of VRAM. It affects download size and not how much a texture uses in VRAM. What affects VRAM usage is primarily texture resolution. Compression quality (not crunch!) affects VRAM usage a little, but it is going to be way less effective than lowering the resolution.
Textures and Maps
Materials use image files for texturing, for masks and for maps. They can be set at resolutions in the import settings, and this changes what the image is resized to for the uploaded version of the avatar. Higher resolutions will use more VRAM to render more pixels of the texture. If the texture goes in low quality, resolution won't help.
To access your texture import settings, find the texture file used in the material and view it in the inspector
.
Search for it in your project folder
Find the material, and through the material click on the texture to highlight it in the project folder
Manually look through your texture folder.
Use https://github.com/Thryrallo/VRCAvatarTools to check the VRAM your avatar uses, and deal with the high numbers. Alternatively, VRChat (open beta?) now shows texture usage as part of avatar stats (the difference is that it doesn't show how much VRAM the mesh uses). Everyone else can see these numbers too.
Lower their in-unity import resolution. Remember, a 4K texture uses 4 times as much VRAM as a 2K texture, and a 8K texture uses 16 times as much as a 2K texture, and 16K... we don't talk about that. (64 times more).
Remove mat caps/normal maps/ etc if you don't need them.
Import settings has a tab in the texture import that allows overrides for windows If you don't need the alpha channel (transparency, IE you have an opaque material), go to PC texture override on the import settings and change the compression format to DXT1 (usually rather than DXT5). You'll see it's RBG rather than RBGA. This should almost halve texture size in VRAM.
Turn off crunch compression and set a texture to 'high' quality compression before upping the texture resolution if you want more detail.
If there's a specific area in your texture you want to have at a higher detail, consider moving the UVs around in blender to expand the area that this detail uses. Examples such as T-shirt decals, tattoos, nipples, etc, can be shifted around so that on a 2k texture they take up more pixels, for more detail.
What to aim for
Aim for Under 80MB texture usage (at least for avatars for use in large instances).
The reasoning is follows: Assuming 8GB of VRAM, 80 people will have 100MB each. However, 20MB is used by the mesh, so that's 80 texture, 20 mesh. Now I hear you say, not every instance is 80 person, I'm hiding people using avatar hider etc; The map uses VRAM too. Sometimes a lot. There's no way for me to reliably measure map usage but I bet you some maps are fucking horrendous.
Examples
That's all well and good but how to actually do it? Here are some (one) case study of examples.
I take a 100k 50 component booth model and do optimization: the results will SHOCK you: Booth_Optimization_example
