Modern GPU bottlenecks are determined by vertex computation rather than triangles as geometry has limited parallelizability especially when bottlenecked by Skinned Mesh processing and outline shaders.

To maintain 40+ FPS on mainstream cards (3060/4060) with 15 active players, a 65k vertex/100k triangle limit is necessary.

Current GPUs waste 70% to 80% of cycles on vertex shaders because throughput relies on L2 cache and front-end frequencies. (RTX3060~RTX5060)

Profiling shows that unoptimized characters (100k+ vertices) combined with external factors like dynamic shadows, mirrors, and tree can drive per-frame rendering to 100 million triangles. (dozen+ players)

Generally speaking, a reasonable mesh follows a ratio of one vertex to two triangles.

After UV unwrapping, the ratio between vertices and triangles typically fluctuates such that one triangle corresponds to approximately 0.55 to 0.65 vertices.

This load far exceeds Steam Hardware Survey averages, especially with modern assets reaching 800k triangles and 100MB mesh memory, which even high-end cards (5070 Ti/5080) struggle to handle.

Have you ever seen a set of Booth clothes that reaches over 800k triangles once you put it on?

I want to add on to this because I see a lot of well formed but not helpful opinions. Yes, relaxing it may make people do even worse with optimization of triangles. But in reality, polygons are one of the harder things for people to optimize without a lot of know-how, unlike other AND MUCH MORE PERFORMANCE HOGGING THINGS like texture memory, material slots and skinned mesh renderers. You can remove clothing options, compress textures, etc all very easily in Unity and get a decent opti avi. But a layperson shouldn't be expected to also learn how to decimate the base and head to a degree that will work and not look bad.

The hardest thing to optimize, is also the least performance hungry, but once you're already very poor- why bother doing more? It won't "look" better, you'll still be very poor. Triangles should go up. Arguably? Everything else should be lower.

maybe 300k is a bit excessive, but we can easily go with 150k / 180k for poor

I think vrchat should be very conservative with changes to the performance ranks. Like how about raise the polygon count for poor from 70k to 75k, but also keep a limit of 70k for a skinned mesh renderer. The other 5000 polygons are for static meshes

Large amounts of polygons are okay in small groups, but I'm liking the ability to participate in larger groups.

For the problem of nobody wanting to wear an optimized avatar, maybe instead of force showing a users avatar choice, maybe also add an option to force show a particular avatar. Then I can opt to see someone's avatar if I feel it's reasonable, but if they then swap to something else, I don't need to worry if they're going from something close to reasonable to a hot mess. Individual avatar enables should be stored client side. But I guess that'd make avatar IDs easier to get. Hmmm. Maybe the combination of user and avatar IDs can be obfuscated.

I guess all things considered, I think vrchat should finish their avatar optimization tool, we see where that goes first

We really need just more advanced blocking options. The current system just doesn't work and increasing limits will just put us in the same situation in a few years. As it is right now though, the current system is useless for most users.

IMO the current tri limits are reasonable, and increasing them to accommodate poor optimization is a bad direction. A client side option would make more sense maybe

Its been mentioned several times in the past on the official VRChat streams that if this limit were updated, it would likely be revised down, not up!

Example:

I strongly resonate with your frustration regarding how shop-bought assets ignore performance standards. However, I find a critical contradiction in your conclusion to "loosen the limits."

If the problem is that shops are neglecting optimization, then raising the triangle limits will only validate their "technical sloth" and encourage the distribution of even more bloated assets. This doesn't solve the problem; it accelerates the degradation of the platform. Instead of giving up on the current limits, we should be discussing stricter governance—perhaps even blocking anything below a certain rank—to protect the ecosystem.

As the sudo message reminds us, leaders in this community have a responsibility to set the right example. Using hardware evolution as an excuse to stop optimizing is a step backward. Just as legendary console devs obsessed over every single polygon, we should use our modern tools to master the "art of the squeeze"—achieving the impossible within strict constraints.

The launch of VRChat Mobile was a clear signal: the future is "Universal Accessibility." Loosening PC-specific limits creates a digital wall that segregates mobile users from the rest of the community. In a cross-platform era, chasing "local optimization" for high-end PCs is a betrayal of the platform’s long-term vision.

I sincerely hope that as a technical leader, you will choose to champion the "Aesthetic of Optimization" rather than seeking the easy way out. Show us what true professional engineering looks like.

The performance ranking isn't only malfunctioning due to polygon count.

It's not good if only avatars that are VaryPoor under the old criteria are blocked simply because the polygon count was reviewed.

If a review is to be conducted, I think all criteria need to be reviewed.

The following is supplementary information.

The impact of polygon count on performance varies depending on the following factors (there may be others):

Bone skinning

BlendShape skinning

Execution of ForwardBase pass

Execution of additional passes (such as outlines)

Execution of ForwardAdd pass (once for each additional real-time light processed)

Execution of ShadowCaster pass (once for screen depth, and once for each real-time light that uses shadows)

Of these, the ForwardAdd pass is not executed unless the avatar is within the range of the light, and since an alternative method called VRCLV has emerged, I believe it can be ignored when performing performance tests.