I'm going to suggest something I heard from someone else but don't see suggested here

Why not add a poly count limit between static and skinned meshes while upping the total poly count limit with both mesh types together?

Static meshes are far less demanding than skinned mesh. Though worth benchmarking just how much more less demanding they are to create logical max poly counts

So something like, doesnt have to be these values or ranking specifically:

-Good rank

Max poly count: 175k split between static and skinned

Max static mesh poly count: 95k

Max skinned mesh poly count: 80k

At least if we can figure out proper ratios for each ratings, Static poly limit should be higher than skinned, all while making the skinned poly limit slightly higher than the original limit for that performance level and also higher than its previous perf rank

The reason I suggest skinned meshes max poly count is slightly higher than its original limit and slightly higher than its previous perf rank is so any previously optimized avatars for their respective ranks dont all suddenly gain +2 perf rank and so avatars that have very poor because of its poly count only, but shouldnt, goes a rank or 2 down, but also give us a bit more polys to work with on an already optimized skinned mesh and more stuff to add on a basic meshes without breaking the rating and without giving ourselves headaches.

Dont take my word as is though, this is just an idea I wanted out there and possibly expanded on by people more knowledgeable than me.

Personally I feel this would also push makers to learn how to manage meshes properly, and no longer punish makers who do actually optimize their work

Edit:

Turned this idea into a slightly more fleshed out post if anyone feels this needs attention https://feedback.vrchat.com/feature-requests/p/seperate-max-polycounts-for-basic-and-skinned-meshes-increase-from-current-rank

Considering current users behavior, raising the limits will only lead to a never-ending cycle.

It seems unlikely that a feature to filter by polygon count will be implemented. Well, I thought so.

When applying performance rankings to group instances, it seems inappropriate to set values ​​based on a uniform assumption of 80 users. Shouldn't we revise the criteria to allow for limiting performance based on the scale of events, for example, "Good" for 80 users, "Medium" for 40 users, and "Poor" for 20 users?

I can see a reasonable argument to raise the tri count for poor avis but 300k is absurdly higher than needed... I can see an argument for 100k but not 300k

If they're going to introduce avatar performance gated instances, I think it's important to create a system that fairly ranks modern avatars. The current performance ranking was made so long ago that it no longer properly reflects the environment of the game. I agree that you should have more fine control over what your system blocks. But the fact that a light 2mb avatar can be ranked as very poor in the same category as a 4k texture full world screen effect avatar is absurd. One of these would obviously cause issues in a large venue world, and the other wouldn't. Especially as the average power of peoples computers is improving with time.

The problem is people don't optimize their avatars and avatar creators don't optimize their bases. 70k is perfectly reasonable, and most bases aim for 30-40k polys to give users room to add clothes and accessories before hitting the 70k limit.

I'd also argue that if this system were to be implemented, it should be far stricter.

Good: 70k polys

Medium: 100k polys

Poor: 150k polys

Very Poor: 200k polys

I think more granular control over perf blocking would be the best solution. Let people set their own thresholds for poly count, material count, lights, physbones, etc etc. If any of them goes over the user-set limit, bam avatar is perf blocked and you get an imposter.

As a bonus, this could be extended to instance moderators. Then you can set up automatically enforced limits for your events, anybody wearing an avatar that crosses those limits will just be globally changed to an imposter for everybody there

Instead of a revision, why not make a HARD cap of polygons ? Something like 500k ? So any content above that would not work. That could stop the polygons increasing in avatars over the years. It feels like that number is just getting higher with every new hardware unlocking new limits of processing.

I organize live music events and also create avatar costumes and avatars. I would like to share my perspective based on these experiences.

First, avatars ranked as “Very Poor” are essentially not functional. They can create a situation similar to the “tragedy of the commons,” where shared system resources are heavily consumed.

During events, avatars often place a much higher load on the system than the world itself. This can cause issues such as audio desynchronization and stuttering. For this reason, it is difficult to allow “Very Poor” avatars in event environments.

The Avatar Culling feature can help reduce system load to some extent. However, record or stream events, it is still preferable to use avatars with lower performance costs. In practice, avatars rated “Poor” or better can generally run in an 80-player instance without major issues.

Another issue relates to penalty for creators. Currently, there is no penalty for high polygon counts, and there is little motivation to optimize models. As a result, creators tend to prioritize the visual quality of shop images, which leads to increasing polygon counts. This situation can disadvantage creators who follow guidelines and spend time optimizing their models.

At the same time, reducing polygon counts is not easy for most users. Therefore, it may be more practical to address this issue through system-level measures rather than relying on individual effort.

One possible approach is to define a clear maximum polygon limit and prevent uploads that exceed it. Without such a standard, polygon counts may continue to increase. A shared guideline would also help build common understanding among users and creators.

In addition, it may be helpful to introduce an automatic polygon reduction process during the build stage before upload. Instead of reducing all models to a fixed threshold, such as 70,000 polygons, the system could apply stronger reduction to models with higher original polygon counts.