owlboy: That's gonna suck for the mods to check when I submit my world that has over 200 avatars and counting lol...

xxx_red_xxx: They use a bot, so it's automated. They are already prepared. You better have reasonably optimized avatars!

owlboy: How does a bot review avatars?

And they are optimized using no dynamic bones and usually 3 meshes (1 skinned, 2 max for accessory items) and 4 materials.

xxx_red_xxx: They inventory the statistics for the avatars in the world or connected worlds and show a report to the admin/mod running the report. And it sounds like you are making pretty optimized avatars! Thank you!

bote: Neat, cool to hear people are taking this seriously, even without official systems.

G1fan: Like I prefaced this suggestion with, this is only an addition to the upcoming performance system that is actually intended to deal with what you're talking about. Source below:

"Ron Millar (CCO of VRChat) - We're aware of dynamic bone and some other related stuff. There's another system coming to address that and those sorts of things. More news soon."

Depending on how the new performance system will handle things, giving some kind of indicator of how well an avatar is made might or might not be suited for it. But that's what this suggestion is for, throwing out ideas that might mature into something better.

Obviously the team already has plans to at least overlook the avatar limits and that has been discussed to death already and the same points have been made over and over, so I didn't bring that up.

G1fan: I agree with all your points tho the materials is a bit low being atlasing does take away the custom stuff of avatars when u combine materials in atlasing. Im not saying u arnt on the right track, u are but 10 is not needed that low 15 at max wont kill most people computers, anything above that is a issue imo, being some people use automatic ways and sometimes when u combine to many materials or atlas to much u lose materials u can change up in unity

G1fan: Be very careful what you suggest for performance caps. Don't go around suggesting that the dev's limit things without actually checking to see if they are actually issues. Poly count is a complete non-issue in most cases. Not only is the poly count one of the smallest performance costs currently (you can avatars in the literal 10's of millions of polys before you start to notice even a small performance hit), its almost purely a gpu cost. The game is currently extremely cpu capped with lots of headroom on the gpu side (assuming you have even a moderate graphics card).

What is actually killing the game (in terms of avatars) right now is anything that costs cpu time. The two things on avatars that are causing massive cpu problems are dynamic bone and final IK. Final Ik is used for the leg, body and hand movements and basically cannot be avoided without using a generic avatar. It is unfortunately very expensive. Dynamic bone is an even worse offender, mostly because its very poorly coded. The cost goes up quickly the more bones you're simulating, and it goes up exponentially for each collider you add. Its the primary reason rooms grind to a halt when there's more than 20 people in there at once.

Smaller cpu costs on avatars include draw calls and skinning meshes. Draw calls are the cost associated with the cpu telling the gpu to render something, and they go up with the number of materials your avatar has and the number of passes each material's shader does. If anything, limiting the number of materials on an avatar would be far more effective at increasing performance than trying to limit polys again. However, draw calls aren't as expensive as is commonly assumed. Skinning mesh renders (moving the verticies of a mesh to match the pose of the skeleton) is another cost that effects both the cpu and gpu. Each separate mesh object that is weighted to a skeleton must be skinned. If an avatar has a ton of seperate pieces, not only are the draw calls going to be multiplied by the number of pieces the amount of time spent skinning meshes will also be multiplied. This can cause severe hitching on loading an avatar in addition to the performance cost.

Ironically, the nametags have way more drawcalls than most peoples avatars. There is a separate material for the background, the name, the name's shadow, the friend icon, the talking icon, the mic-off icon, the muted icon, the particle icon, the shader icon, the sound icon, the animation icon, the possible troublemaker icon, the confirmed troublemaker icon, the rank tag, and the rank's shadow. All these are always on even if you can't see them. Just turning off nameplates can restore like 5-10 fps.

error.mdl: Wow, this was a very thorough explanation of performance costing components. Is there any way the impact of finalik could be realistically reduced? Thinking perhaps a form of IK LODs?

error.mdl:

These don't seem to add up to me.

You listed about 15 draw calls per nameplate. If every avatar in the room lost 15 draw calls they would give us 5-10 FPS too. So that means individual avatar draw calls down 15 or so plus nameplates would be 10-20FPS. Right?

It's important for draw calls to be as low as possible on every avatar. It seems.

Also, how do you know how the nameplates are rendering, and that they are consuming draw calls when not showing?

I know there is a nuance here, but I find the whole subject hard to talk about because there seems to be a counterpoint to all sorts of statements when it comes to "what makes VRChat slow?"

I ask for clarification because I would​ like to spread correct information and not misinterpret it. Recently I was misstating the fact that one or 2 dynamic bones are as impactful as 20. What I should have been saying is having 30 people with 1 dynamic bone is still a big impact. (This is why I had a rule at Halloween that disallowed dynamic bone. Instead of having a rule that allows each person 2 dynamic bones. In aggregate it's still a big impact.)

As far as Polycount, something reasonable should still be enforced right? Because memory usage and bandwidth usage are still a concern. And the more geometry a model has the more resources it uses in those domains, correct?​ Or are 30 avatars each with a few million triangles each, ​not a memory issue?

owlboy: draw calls that aren't as expensive as is commonly assumed doesn't mean you can go ham with them, just means that calling a single avatar laggy cause it has 5 materials instead of like 2 is an overexageration. it has a cost, less is better, but if an avatar spawns and you start lagging cause of it, draw calls is generally not the first issue with that avatar. For knowing if nameplates are rendering you can use a frame debugger like Nvidia Nsight where you can get all sorts of informations about what is running in the gpu at any point from any program, vrc included.

About polycount, a good limit could be around 65k polys, cause around that number this version of unity splits the mesh into multiple meshes automatically, and the way it splits them is not the most optimized way (pretty much you double your draw calls cause of that). But even then you could manually split them in blender and organize materials in a way that it having 2 meshes doesn't actually increase draw calls.

Cibbi: does my math work out though? How it’s cumulative among the number of avatars in the room. There are problems with “well one avatar can...” when it scales to 20 or 30 avatars, right?

owlboy: it scales, the difference is the magnitude, nameplates have a lot of materials (like 10-15 materials each), a 5 avatar material difference in a room of 20 people is like 100 draw calls, nameplates off are 2-3 times that, also having nameplates off can also lift some weight of the scripts that run on them, and honestly i think that's also what makes that 5 to 10 fps difference

Cibbi: I was specifically citing similar draw call amounts for avatars as nameplates. 15.

So you are making up a new number to compare with. Of course 5 vs 15 is a 3x difference. What are you saying?

I was specifically calling out the example of how 15 additional draw calls on each and every avatar adds up fast. Just like how 15 draw calls​ on nameplates adds up fast.

We have to find some limit where everyone can't think they uniquely get to use a ton of drawcalls because it's just them. If everyone things they are unique in their use of resources no one is. And we all suffer for it.

owlboy: i also mentioned scripts running on nameplates, which can be a fairly good chunk of the performance cost of nameplates. so 15 less materials on avatars is just 15 less materials in the total cost, no nameplates is 15 less materials + the weight of scripts dedicated to the nameplate. Again, did not say that you can have 20485 materials, but that limiting too much material number is not AS beneficial as people think, you can go around with 10-15 materials on your avatar with no real impact, you don't need to have 1. obviously 50+ materials of an average mmd model is a bit too much when there are 20+ people. but that is common sense.

G1fan: Or NO poly limit and replace with 10 materials max 20 mesh max.