“buy a better PC” is not a valid argument, ever. Especially not right now.
I don’t know what you have your settings set to when you join a big instance but I’m betting you don’t have everyones avatars shown either, regardless of your hardware.
This is about respecting others. Surely you’d like to be seen by as many people as possible, so why be okay with having a badly performing avatar?
Edit:
I still don’t understand why the lazy way out is being picked when in the end it’s going to help nobody.
Allowing in those instances to show hidden avatars (gotta remind that it is only in those instanes and nowhere else), is just forcefully loading a poorly performing avatar and tanking your performance.
That’s a bad solution. Actually, worse than that. That’s not a solution, that’s just a workaround.
The true solution is if very poor avatars improved their performance. I don’t understand why this is so controversial? Surely you like having high FPS in VR, right? It’s not that complicated….
I disagree. We should absolutely punish people for having unoptimized avatars. It’s one of the (although not the only) biggest factors to VRC’s historically bad performance. You should be able to express yourself freely without requiring an insanely unoptimized avatar.
One of the best features VRC ever added was the ability to automatically hide Very Poor rated avatars. These days my experience is mostly seeing imposters. A big appeal to optimizing my avatar for me is knowing that other users who use that same feature (which seems to be a lot of people) will automatically see my avatar instead of an imposter. I consider that a form of expression as I feel my avatar does a better job of representing me than a collection of sprites.
Unfortunately this will happen to every feature VRC adds that is given the ability to assign Group Role exemptions. It has been a controversial and widespread issue ever since the Instance Queue was added. There really is no good workaround for it, the way VRC is currently set up seems to (unintentional or not) encourage cliques and nepotism, but not having the assignable exemptions would be more detrimental than allowing its abuse.
It’s an outrageous take to suggest that because some people have to run a game on low settings, developers should remove high or ultra settings. That seems to be what you’re asking for here.
“Buy a better PC” isn’t even their argument. The point is that people should take responsibility for their own user experience and adjust their own settings, rather than having those options restricted and removed for everyone.
If someone chooses to display very poorly optimized avatars, why shouldn’t they be able to? I don’t see how that impacts other users in the instance. If they decide to load and view those avatars on their own system, it’s on them to make that decision based on their hardware.
The problem with this take is that if you don’t have a PC powerful enough to display unoptimized avatars, then you have to adjust your display settings, and you get a subpar experience compared to people with more powerful PCs. This makes unoptimized avatars a “you” problem.
By not allowing anyone to override it, this shifts the problem to the people using unoptimized avatars instead - if they want people to see their full and proper avatar, they need to optimize it. This puts pressure on avatar creators to create more optimized versions of their avatar.
VRChat’s been trying to encourage people to optimize their avatars for a long time, but a lot of people haven’t because of the prevailing attitude of “just hide my avatar if your computer can’t handle it”, putting the burden (and a degraded experience) on the people with less powerful PCs. I feel this is a necessary step to get people to create more optimized versions of their avatars, and I’m glad VRChat’s basically saying “nope, no exceptions, optimize your s***”
This makes it sound like avatars that are rated “very poor” are to be considered as some kind of “ultra” setting. That’s not what I’m implying or saying. Besides, you can have an avatar look insanely high quality and be good rated.
You can make Minecraft run terribly with little effort, doesn’t make it look any more “ultra” though.
Same with very poor rated avatars. It is adding overhead to performance that is making the experience worse for everyone, and I do mean Everyone. It is taking away headroom for other avatars to be shown. That’s the definition of an unoptimized avatar.
This has nothing to do with visual fidelity.
You as the user of the avatar have to keep it shown, it takes away some of your performance and limits how many other avatars you can see with a decent frame rate, others who see the avatar will be impacted just as much, except some more than others because of hardware differences.
Now, if the avatar was decently performant, it would have less of an impact on your and other peoples hardware, allowing you to see more people at once at better performance. This is why you optimize your avatars, and that’s why I think if you don’t, be it by choice or ignorance, you are part of the problem this new function is trying to solve. I don’t know how this can be put any more clearly, this is about getting the most out of your and other peoples hardware.
When I was reading the comments at first, I thought the original suggestion of not even letting people with avatars beyond the stated limit into the gated instance was a little silly and allowing them to be there as an impostor is a nice compromise; but now I realise if they weren’t allowed in to begin with, the whole issue with being able to show them wouldn’t even have existed.
On the topic of poly count though, in my experience, at least on PC, there are usually three performance bottlenecks I see a range of people go through in an instance full of vpoors: first is the VRAM check; if they have enough VRAM, then it’s a CPU bottleneck, and only then it becomes a GPU/rendering issue - all of which makes me agree that the current poly count limit a little silly, at least until the issues that hit the CPUs so hard are resolved. I get entirely CPU bottlenecked in a high population instance with an average poly count of 140k. But at the same time I understand the need to keep the base creators in check, so I’m kinda neither here nor there on this.
While I’m all for the gating system, sadly the current performance rank system implementation doesn’t provide nearly enough control. I’m definitely looking forward to the potential instance ‘block by uncompressed size’ solution instead, and I’m definitely happy for the other events that will benefit from this as is.
How do we tell players the logic behind their avatar being rated as good in one instance and very poor in another?
There’s no need to label it as “Good”; simply put, within the current performance rank framework, I’m proposing introducing Very Poor Tier 1/2/3. By allowing up to Very Poor Tier 2 through performance gating, you could achieve, in a 10-player instance, an effect similar to applying a Poor limit in an 80-player instance.
There may be discussions about restructuring the performance rank system itself, but I hope examples like this are considered by the VRChat team. The reason is that, as a user in Japan, seeing the unchecked proliferation of Very Poor avatars on Booth, I feel that the current Very Poor category has virtually no effect in encouraging optimization. Instead, it leaves users with no choice but to make individual judgments based on their own PC performance (and as a result, assets that are clearly “heavy” for the average user tend to be criticized on social media and corrected that way).
Performance gating provides a breakthrough for this. Allowing instance owners to impose practical constraints on the spot (particularly for Booth avatars that fall into Very Poor ×2) would create a new motivation for optimization that hasn’t existed before.
Even without increasing the number of Very Poor tiers, it could also be useful to allow specifying constraints individually, such as polygon count or VRAM. While this is often considered too complex for beginners, I expect that practical local solutions would emerge as such practices are shared within the community.
Well, this is something that should probably be posted on Canny. In short, I’d like VRChat to also consider the usability of everyday 20-player Group+ instances.
To clarify, the kind of performance that gets criticized on social media is something that causes noticeable performance drops even with just two people present.
Before reaching that point, I think it would be very meaningful to be able to place several gates that are less strict than Very Poor.
That’s diluting the rating system so far down that it’s starting to lose meaning.
Why not just optimize the avatars? What is the reason the avatars are not being optimized? What good reason could there be that the avatars require to be so deep in the very poor rating?
If performance rank-based blocking only applies to group instances, avatar and costume creators won’t be motivated to optimize, and only avatar buyers will bear the burden of increased polygon counts.
I think it would be better to apply a strong restriction, such as forcibly hiding very poor avatars in all public instances (similar to how very poor avatars need to be manually displayed on mobile devices).
I don’t believe such a rigid approach will be easier to drive forward, especially since many people feel the “Very Poor” standard is not reasonable enough.
Softer limits are often more effective at solving problems than overly stiff ones.
As someone mentioned above, using “Very Poor” as a benchmark to establish a mechanism based on N-times or N-levels is also a good design philosophy.
VRChat requires a combination of soft limit incentives and hard limits for extreme cases to resolve the current issues.
Can we have an instance capacity test sometime soon to test out the minimum avatar performance feature? I think we can totally beat the record of 433 this time around.
I don’t see why users not allowed to override this setting, if I want my computer to die because it’s rendering 80 people on an instance with a majority of people there using poor/very poor avatars then I should be able to have that freedom to do so, the restriction feels arbitrary and pointless, I feel like there is a much better approach to this without controlling and restricting how people want to experience and enjoy VRChat.
You could even add a warning popup with each non-friend in the instance who you decide to show avatar informing the user of the potential performance hit by showing peoples poor avatars, etc.
On a serious note,
We already have automatic user configurable avatar blocking based on performance ranking. Not sure how this is the responsibility of group instances to enforce an avatar performance limit? It really should be the decision of the end user to decide what they do and don’t want to see.
Disappointing to see development time being spent on a rather pointless feature like this, rather than the more important improvement to avatar performance: we shouldn’t have to rely on 3rd party systems to optimize and create semi-modular avatars.
If you want to improve avatar performance across the platform, put development efforts towards tooling to help creators improve performance from a systematic level. Such as script-able avatars, so we aren’t forced to use one of the slowest things in the pipeline, the unity animator.
TL;DR: Improve tools to increase performance at runtime and let users enforce their own performance settings.
I think people complaining about not being able to override the limitation don’t realize this feature is meant for instances where wearing Very Poor avatars is forbidden in the first place. Before this feature, if you had a friend wearing a Very Poor avatar, they would’ve been asked by the staff to change it or even been kicked. So this feature is just a softer and more convenient way to enforce event rules.
My view is that this feature—performance limiting via Groups—is a very good initiative, and I think the implementation details are well thought out.
What I’m describing above is an additional point—wouldn’t it be useful to make this convenient not only for 80-player instances, but also for 20-player instances in Japan (where avatars are clearly not optimized enough for 80-player instances, but are sufficient for around 20)?
As for the group performance limiting itself, I definitely want it to be implemented (and if possible, I’d also like it to be adjustable within the instance).
(In short, people who attend 80-player events already have some motivation to optimize, even if the current constraints aren’t very strict.
If this feature becomes practically usable at this stage for people in 20-player instances—who otherwise lack motivation to optimize—it could help provide that motivation.)
being unable to force show someone’s avatar is ridiculous.
in situations like that I’m fully aware of the repercussions of showing a very poor avatar in a populated setting, and I’d take full responsibility for my game crashing.
My impression is that this feature is essentially an implementation that automates the manual moderation currently carried out by staff in 80-player instances, and from that perspective, I think it is well designed. In many cases, it won’t effectively introduce any “new” restrictions.
Using a Very Poor avatar in such settings is already considered a violation of event rules, so in that sense, the situation is unlikely to change significantly.
(That’s exactly why I’m proposing that this feature could also be used to bring about a qualitative change in 20-player instances. While this would likely involve a range of discussions—such as how to handle performance ranks or introduce more granular limits—I see it as a longer-term idea, but one I hope the VRChat team will keep in mind.)
Did you know that one of the most common issues for Quest standalone users is memory issues? And these issues are normally always caused by them showing too many poorly optimized avatars, because they disable the default VRChat settings that hide VERY POOR performance rated avatars.
In other words, some times giving people the options to screw themselves over, is not a good idea.
