But do we actually know the rate at which it changes? If we increase the limit by 30,000 to 100,000, that means up to 80 people would go from 5,600,000 polygons max to 8,000,000 polygons max.
That is the wrong style of argument. Medium can be the rank that targets the 80-player instance, and it can stay as-is. Now imagine a 40-player instance, that would want to get the same 5.6M polygons on avatars, assuming that’s somehow the holy grail number. Suddenly, each one of them can have 140k polygons for the same performance target. It’s not expressed in the current performance ranks in any way - you can either have your GPU underutilized with just 2.8M in a rank-limited instance, or let the combined polycount be completely unbounded, possibly resulting in worse performance than the target.
Nobody is asking to uncap the good rank to 300k polygons. People are asking for more nuance that could be applied in every not-80-player scenario, of which there are many.
So what we really need is a “obscene” rank that applies to avatars that are on the deeper end of “Very Poor”. Am I understanding this correctly?
If so: Then great, lets do that and adjust the ranking system/group instance perf tool to compensate for that.
But I don’t think the existing ranks should be changed outside of that.
Make a canny for that feature.
To add: I do agree that the performance rank system could be adjusted. I think weights could be added to consider the overall impact of each aspect of an avatar, and that total rank number would determine what they fall into.
It’s just up to VRChat to determine what those weights actually are and to migrate the system to that. But I still think the general thresholds that we have in our current system should be relatively maintained.
If your issue is that it’s annoying to turn people’s avatars on and then off, why do you want it so that you can’t turn them on at all, instead of some solution to having them be turned off again automatically, like turning them on temporarily?
Will there be an option to turn this off mid instance via the world master?
Sometimes events run heavy/popular for awhile, and as the night winds down the population drops to more manageable levels and it would be nice to remove this restriction so that players could switch to other avatars.
I personally believe local override should 100% be determined by the user not the instance. I would rather see performers and friends and hide the rest then see 50+ fallback and low poly avatars. The only real benefit of forcing local behaviors for this is streamers since you would be recording people in fallbacks that they may be unaware/unhappy about. I don’t buy the “awkward show my avatar” reasoning. If someone is at a large event and hassling people about that then you probably wouldn’t show them anyway. Why remove the players ability to choose what they want to see?
Well, overall, this is a good update. Any instance control over performance moderation is overdue, and this will help groups passively “moderate” and all that.
That said, restricting what users are allowed to render locally isn’t great for every hardware configuration. Personally not a big fan, I want to use my machine for what it’s capable of rendering. Communities like the rave/club scene already operate with established etiquetes for optimization and have done so for years. This new system may help with the rave scene (which is probably why it’s being implemented) to help newcomers and serve as a great aid for moderation.
However, this shouldn’t be treated as a one-size-fits-all or final solution.
The whole group role to bypass, it highlights a tool gap in the current SDK/APIs. World creators and event organizers would benefit from more granular control. Imagine if we had power user tools to interact with groups that are first party. Imagine, exposing avatar performance metrics (rating tiers or individual stats) through something like VRCPlayerApi, which would allow worlds to implement their own logic. We already have hand rolled many auth and moderation systems in venues, this could make things even better.
We already have precedents for exposing fields and data (VRC+ flags), so this doesn’t seem like an unreasonable addition. Only been waiting years for this opportunity.
As mentioned multiple times in this thread: This is not about user preferences. This is about event spaces being able to enforce a consistent and good experience.
I do agree with most of what you said. But I want to reiterate again:
It’s not about the fact that your hardware can handle it. It’s about making sure the average experience is good and consistent for everyone.
If all very poor are blocked, it means there is a higher chance that more avatars are shown. This improves immersion for everyone.
Personally I like the idea of Poor being 100k but mandate that going over a max size of 80 requires a Medium cap (only bypassable by a whitelist of fewer than 50 members).
Alternately, make an Extremely Poor rank with some reasonable numbers, maybe even something dynamically calculated so “barely Very Poor, but in every respect at once” is rightfully considered Extremely Poor. I’d love to toggle that one myself when things get too busy, as someone who has a top-end setup but likes good framerates.
I would like to raise concern about respecting user choice.
The instance performance change took control away from players which seems to go against existing VRC philosophy of respecting player settings and choices. There needs to be a individual overwrite option because they should be able to see their friends if they choose to instead of a fallback. A user should be able to choose to show everyone as they are given that they explicitly opt in to do so.
This may not be the primary issue with avatars, but it is still worth discussing. I have seen it stated that, as of around 2023, major engines on screen should be capable of handling roughly 6 to 7 million triangles while maintaining 60 FPS. If that estimate is divided across 80 users, it comes out to roughly 75,000 triangles per avatar, which does make the 70,000 limit feel understandable from a technical reasoning standpoint.
I will set aside the separate point someone raised about an 80 person server, because I believe the target should be closer to 100 users unless the world design itself cannot realistically support that scale.
The question I keep coming back to is whether our current Unity version, and by extension the SDK and client built around it, is still the most performant path toward achieving those goals of 80 to 100 person instances at 60 FPS. Or, put another way, is remaining on Unity 2022 holding VRChat back from more meaningful technical improvements?
My interest is much more in long term performance and quality preservation than in what feels like a gatekeeping gimmick for groups. I keep finding myself asking what this change is actually meant to solve, and why VRChat is prioritizing this instead of other areas.
Is this primarily a group management solution? Is it meant as a creator restriction or soft enforcement mechanism? Or is it a broader attempt to curb performance strain for lower end systems such as Quest, older PCs, and eventually mobile platforms?
As for where we differ, I must make it clear that these are personal thoughts regarding the feature.
Ultimately I preferably want everyone to have a great experience in VRChat instances.
I believe that it is something that can be improved a lot by VRChat development and by a community effort to optimize.
However this feature should seek to take a stronger stance on things it enforces. Although I understand the difficulty in trying to please everyone, it’s not easy.
But let’s put it this way:
I give you a PC with a 40/50 series RTX GPU, a equivalent CPU and plenty of RAM. Then I tell you that with this you can render about anything you throw at it. And finally, I tell you that we need a “consistent experience” in our game and you will not be able to utilize all that powerhouse of PC.
Do you still believe wholeheartedly that this makes a good point for VRC?
Either way you are entitled to your opinion, but I urge you to consider this the way it is perceived by a sizable portion of users.
User choice directly conflicts with Group choice and combined experience. This point of this feature is specifically so groups can maintain a more consistent experience and make the experience of all users on average more enjoyable. It does not matter what individuals think in this context.
When a user is joining a group instance, they are respecting the instance rules. If a group has a rule of “No Very Poor Avatars”, then they should be able to enforce that. All this feature does is help enforce that and give people more of an incentive to use avatars above the Very Poor rank.
You as a user do not get to decide what a Group should or should not do. You must respect their space.
If it does turn out that groups are restricting even Poor or Medium and the users generally disagree with that, they can raise a stink with the Group and not attend the event. This is more of a social problem and it will solve itself, and I am sure that VRChat may adjust this going into the future.
I do believe VRChat might be able to utilize some features of newer versions, or even current versions, to help. However, as VRChat says, the majority of performance issues stem from User Generated Content, AKA: Avatars themselves.
Yes. I have a 5700X3D and an RTX 3080 with 64 GB of RAM. This is still above average for what users have on VRChat. Even with that, I can sometimes only manage 20-30 FPS in many instances when showing Very Poor, even if it’s only 40-60 users. Often times, disabling those avatars bumps up my performance 10-20 FPS. Someone made the argument that if I still showed those users but they weren’t Very Poor, it wouldn’t be that significant of an improvement. I agree, but it surely would still be at least 5-10 FPS.
I really think we should be targeting the average hardware on the Steam Hardware Survey. The goal should be that under the maximum scenario, that a user with that hardware could ideally run the game at least at 30 FPS, preferably 36, 40, or 45 FPS (common divisions of half the refresh rate, so interpolation algorithms can have the best chance of working).
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?
“You can not choose to show specific people (locally)” - Yes you can, even if you have culling and such you can choose who to show, default and hide on your client. However if the instance has a avatar performance requirement, that is the max you can be.
example; I tend to auto show excellent and good avatars since they tend to be well optimized while auto hiding anything above that. If I’m in a lobby that requires poor or better ranked avatars, the medium and poor ranked avatars will still be hidden on my client unless I show them. This also applies to anyone who might be in a Very Poor that is given the role to bypass the restriction (typically event staff like dancers, DJs, Hosts, ect) in that they will still auto hide on my client.
Say that only Poor or better are allowed. This means that everyone in the instance is forced to not see any users avatar that is Very Poor and will only see their fallback/impostor.
Same goes if the minimum is Medium or Good. Any avatars below that rank, in that instance that has the flag set, will only be visible to the user using that avatar. It will fallback for all other users.
It’s the same functionality as if you had the shield setting configured (default) for viewing that user’s avatar and blocked Very Poor in your Avatar settings in the big menu. Except it is strictly enforced for all users in the instance and you can not override it by showing their avatar.