Woohoo! Loving this update! I know some don’t like additional limitations being put in place, but if it increases stability for more folks, I’m 110% on board I see it like a dangerous road, yea, a speed limit wasn’t originally posted, but there were lots of avoidable accidents. Policing VRAM with safety settings could really help improve the overall user experience
Also, just curious, do y’all have any plans to release a PSVR2 version of the client? If so, could you consider bringing Eye tracking to base avatars without requiring a special OSC version of the Avi? I think it would be awesome to have many more Eye Tracked folks inhabiting the worlds of VRChat. Also, I think the easier it is for a new user to utilize the cool features of their headset, the more likely they are to return/stay/use VRC as their main social VR app.
Assuming it will just be Buttons and Sliders with Text Fields, will we have the ability to add our own Icons to the said Buttons as well? Most people who aren’t familiar with English can reference quickly to what it does if it has an Icon (make it be a Large Button Variant similar to what it looks like currently on the Launchpad of the Quick Menu).
You can implement rules as to what types of Icons can be accepted. Like, only 1 Color (preferably White) so that the Udon UI will automatically set the Icon’s color to match with the rest of the Quick Menu’s Color Scheme.
Please research on how different Constraints affect performance. It’s wise to know that there are Furry Avatars out there that use Digigrade Rigging, which relies on Rotation Constraints. At most they require 12 Rotation Constraints in order for the Digigrade to operate properly as they should.
Can we get a separate setting for limiting vram? As I would want to limit the weird avatars with 500MB usage that i see sometimes, but keep all others avatars still enabled.
Currently its rearly an issue, but with older GPU 90% of time I was lagging it was because of the vram, I don’t want to hide some avatar just because they have disabled cloth and are now very poor or some other useless metric - but would love to hide these few vram clogging avatars without scrolling thro everyone manually.
VRC did start compiling shaders for Single Pass Stereo Instanced (what’s required for the new render pipeline) back in April last year, so any world that has been uploaded or updated since then with compatible shaders (a lot of the common ones) will be fine.
I absolutely ADORE this type of technical avatar write up! It explains the problems beautifully and WHY you need to do certain things to have a good running avi! Please do more of these theyresuch a treat.
如果不是因为比特币矿潮您甚至能买到20GB VRAM的3080ti，或者16GB的3070ti。
You can even buy 3080ti of 20GB VRAM or 3070ti of 16GB if it is not for the Bitcoin boom.
而现在却只能在二手市场买到他们
Now they can only be bought in the second-hand market
I would love to see the Polygon Performance rankings getting touched as well. While I really welcome the vram change, the issue still stands, that for a lot after hitting 70.001 Polys means “it’s very poor anyway, so why even care?” Of course I could not tell reasonable numbers here and would rely on your experience regarding that, but I think giving ppl an easier time to reach poor would give an incentive towards vram optimization as well. Or give potentiaal new ranks, very poor - abysmall - potential crashing etc. Right now “very poor” rated avatars can be anything from avis outperforming good rated ones up to “try to load and your pc dies” - which is a very wide area (this is extreme case talking here)
Thanks a ton for this update! This is really huge for multiple reasons, and I am really looking forward to the string loader.
It would be awesome if y’all could do some performance testing on parented objects in the armature hierarchy. To my understanding, these still count as “constraints” in a way, since it needs to calculate placed objects relative to each other.
This is especially notable for people that add clothes. I learned that clothes will often have their own armatures, which is apparently an inherent thing of how Unity works. However, instead of being able to just merge them with the avatar, they often place the armature for the clothes alongside the existing bones. When you have dozens of clothes… this adds up quick. I haven’t done my own testing for this since I haven’t had the opportunity, but since it seems like y’all know what to look for, an investigation into this would be great.
It surely would account for probably the majority of lag if it is the case, since people may have dozens of different clothes with their own armatures. Plus many people seem to not know about tools like this or this which allow you to swap the meshes so the clothes are attached without also adding the additional armature.
This is great and I am very happy with the values you chose. VRAM was a heavy topic in a community I’m in recently, so it’s nice to see it is officially recognized in some capacity.
The poly count rank is probably to make sure a single mesh never exceeds the 16-bit vertex buffer Unity uses for meshes.
Edit: when the rank was made this was actually even worse, as Unity’s old behaviour was to split a mesh in two instead, effectively doubling your material count.
If a single mesh exceeds that buffer, it switches to a 32-bit buffer, which takes significantly more space.
They could check all meshes on the avatar and make sure none of them exceed that limit however.
Another problem is when you have lots of players in a world, there are no LODs for avatars like a normal game, where far away an avatar could be 200 triangles without anyone noticing. ^^"
Even if VRChat whitelisted LODs for avatars, no one except maybe me would use it. xD
Thanks for your explanation:
I see that this might be a problem, but even then 70.000 on the dot doesnt make sense, since that split or swapping over to 32 bit should already happen at 65.535, since thats the max value a 16bit can have. (except unity being unity and they do some internal shenanigans i am not aware of)
If that still would be an issue, an approach like you mentioned, X amount of meshes less insert number here might be an option.
And agree as well on LOD stuff xD noone expect the advanced users might make use of that. Will be eager to see if vrchat wants to tackle the poly perf rank or not
I wonder if a solution for constraints by VRChat itself would be feasable at all,
I personally still want an actual driver system for mechanical gears and rig shenanigans, akin to the driver system in blender
though I’m unsure if it would be possible to make a flexible system like that more performant than the current constraint system by unity
The limit being 70 000 tris is strange yeah, but it might just be that it’s more common to list triangle count than vertex count for any models, even though vertex count matters way more than triangle count.
It’s just not common to list vertices unless you’re a massive nerd. xD
I suppose you could make a 0 tri 65535+ vert model, which is… yeah.
Parented objects that have weights to a skinned mesh are more like adding more bones to your armature, it’s even reflected in the Bones performance rank.
Bones do have a cost as well, albeit much smaller than a constraint, if you have a bit of Blender knowledge it’s quite easy to attach the clothes to your avatar’s armature instead of adding additional bones in Unity.
P.S. Nice that there are Unity tools for merging properly as well!
I see it like a dangerous road, yea, a speed limit wasn’t originally posted, but there were lots of avoidable accidents. Policing VRAM with safety settings could really help improve the overall user experience 