I skimmed a tweet (I think it was a tweet?) from @tupper that mentioned how Blendshapes were computationally expensive and that they probably shouldn’t be used to hide geometry. I tried to go back to find that topic but I couldn’t so I figured I’d ask for more information here where posts are a lot less transient:
As I see it, there are three ways (Are there more?)
Blendshapes that deform the geometry such that it is hidden inside the model.
Separate Meshes that can be enabled or disabled through animations.
Material swaps that remove textures from the geometry that make it transparent.
What are the recommended methods for ‘hiding’ geometry for things like clothing pieces, jewelry and accessories?
Correction
I think maybe it was this post on here that I saw rather than on Twitter? (Would explain why I couldn’t find it!)
So maybe I just answered my own question - I suppose it would depend on how vertex-heavy the in-question geometry was. That’s still a little vague but maybe a good rule of thumb would be something like, 'It the thing you want to Blendshape out of existence has more verts than your actual avatar, maybe split that out."
Another random thought: If you did break out multiple clothing pieces but they all used the same material (Atlas texture), would that save on overall texture memory even though each mesh would need its own material renderer?
For multiple users of a texture the game engine can just keep track of the users, keep the texture in memory until nobody is using it.
I guess it’s a good thing to test for every once in awhile, but I would definitely consider it a bug if within the scope of one avatar the texture get uploaded to GPU more than once.
For blendshapes I’ve seen recommendation to put the head as one renderer and the rest is on another skinned mesh renderer. Curious to see what shakes out.
Overall, enabling/disabling renderers would probably be the best way to handle this. Since you will only have a few renderers enabled at once (one outfit), the others will just be skipped reasonably efficiently. This technique also has a fairly predictable computational cost.
The other techniques still result in geometry that must be processed by the video card at least per vertex. Transparent material swaps won’t work on Quest at all.
Another random thought
You can have different mesh renderers, and even different materials. As long as they all reference the same instance of a texture, it won’t be duplicated in VRAM.
This is correct! Even though the performance system (necessarily) counts disabled meshes, in the end, turning off a mesh is way more performant than using a blendshape to shrink it.
Blendshapes are applied during the GPU’s skinning call, so something that’s shrunk down is still rendered with all the costs that come with it, with the additional cost that’s brought along with the skinning itself.
This is one of the bigger failures of the performance system. As it stands today, there’s not really a great way around it-- you kinda just have to accept the potential Perf Rank downgrade that comes with using disabled meshes.
I just had possibly the silliest idea, it’s in two parts.
One: allow VRChat users to opt in to send avatar stats to VRChat. I see your avatar and my client sends all the performance value, including constraints. If there are disagreement in values, VRChat can use some computer time to determine the correct answer and react accordingly.
Two: for showing very poor avatar or not, let users route this to a program as a RPC, aka a local http request, either get the numbers from VRChat, or load the avatar and get the numbers and if the RPC program says no, unload it. Users can then evaluate the numbers as desired using whatever language they want.
Although maybe javascript makes more sense, pass in one object and get back a Boolean (true or false) then people can share their idea in code. The JavaScript or whatever engine just needs math.
