Quest Avatar Limits
Kenoli
In VRChat, performance depends on the complexity of user-created content. Because of this, users are largely responsible for maintaining their framerate by selecting the content they view. Users do this by avoiding poorly-optimized worlds, hiding problematic avatars, and meeting with smaller groups of users.
With the introduction of the Quest, there are now many users with fixed, low-power hardware. These users need additional features to help them maintain framerate.
Regarding Quest avatar performance, using strict polygon/bone/material/etc limits is a poor option, because being able to experience a wide variety of content is the core value of VRChat. Low performance degrades user experience, but so does lack of content.
VRChat needs both performance controls and content freedom. Consider implementing additional settings that let users manage the avatars they see. Such settings can be useful for both PC and Quest users.
Suggestions:
- A setting to hide avatars based on their performance rating.
- A setting to hide avatars based on their distance from the user
- A setting to hide more or less avatars based on the current framerate.
Log In
tallsuperboo
can you please make it so we can upload avatars bigger than 10 mb
GearBell
im against having options to hide avatars based on performance rating. cause "poor performance" ranges from very functionally complex avatars that can do all sorts of effects to a basic avatar that has one light. Ive seen avatars get poor performance ratings over having a singular light and even 3 dynamic bones with collision but beyond that it was a low poly optomized avatar. vrchat's determination of "poor performance" will cut out about 95% of all avatars youll ever see if you "turn off" poor performance avatars. what they have currently in the safety settings works as is. Quest users cant see any pc avatars anyways so they are safe.
N
Nanachi~Saisho
GearBell: oh how they should have listened to you instead...
Lhun
One thing that could assist this is supporting VRM format in addition to fbx. My request has 200+ votes now. https://vrchat.canny.io/feature-requests/p/support-for-vrm-3d-humanoid-avatar-format-for-vr
I need to revisit my explanation on this: I should put more information, of course unity does convert some things to it's own native mesh formats when compiled in a scene as a game package, of course - the import settings determine a lot, but that's not what I'm talking about: It is lightweight and directly readable by the GPU, it includes your PBR node materials, textures, LODs, animations: GLB is a binary format and can be loaded at RUNTIME: which is what I'm suggesting, much like Collada and FBX can, as the current built-in types. Since we're loading avatars this would make them far more portable, and wouldn't require asset packages in the same way that we do now, you would be able to support uploading them natively in the client without needing unity at all.
https://vrm.dev/en/ Even nintendo is among it's users now.
GLB/GLTF meshes are optimized for mobile and there are already a large number of mobile applications to use VRM format avatars, designed for lesser hardware than what can be found in the Quest.
I would be very surprised if virtualcast (a direct japanese vrchat competitor in some ways) doesn't have a quest client soon https://virtualcast.jp/ - they added support for "looking glass" 3d display recently so they do care to go beyond pc.
https://www.moguravr.com/virtualcast-10/ Mogura does things in VRChat as well.
VRM format has a very optimized "springbone" system that would support networked ik and might even allow for locally calculated IK again.
Khronos developed mesh formats are optimized for mobile, and again, this is what VRM format uses:
This would allow for higher poly, higher fidelity models and a more robust toon shader built in, as well as a dynamicbone system that works on mobile.
If you want to see how incredibly fast it can be on a mobile device, simply download and install VPocket, https://play.google.com/store/apps/details?id=com.BooApps.VPocket which is a unity application much like vrchat. You can take an extrordinarly high poly model and see what kind of performance you get even with dynamic fabric.
And besides, VRM springbone works better than dynamicbone for IK calculation for performance as it was designed for things like anime hair, tails and skirts.
The unity add-on would be fairly easy to implement and it could run in ADDITION to unity's built in formats. It's compatible with unity 5.6 all the way to 2019 and even contains support for emotes and a canned templates for emotion expressions that works across all models.
The design of the system abstracts the bone naming process: allowing you to use for humanoids and would simplify avatar creation.
These kinds of posts just further solidify my argument that adding VRM is the way to go, and it would be a hit with the japanese community too. Besides, FBX is a licenced commercial format and VRM and GLB are open source - it wouldn't even cost anything to add.
Cibbi
Lhun: There is no such thing as adding vrm format support in vrc, cause every mesh format that gets imported into unity gets automatically converted internally in it's own format, meaning that as long as you can import that format into unity (like using uniVRM for VRM models) then you can upload it to vrc. Only thing that could be added is the support to some uniVRM components (like the springbone). But at that point, considering that uniVRM components are pretty much their own avatar system and vrc already has it's own components for handling avatars, i would rather have an alternative of dynamic bones made by the vrc devs themself and optimized for vrchat specifically, so then i can apply it to every model indipendently from the format that was imported as.
Lhun
Cibbi: if they added direct support for univrm by including the sdk in the actual game engine, they could support the GLTF (glb) mesh format natively, which unity 2017 does not support out of the box. You need the Khronos GLB library, which VRM adds.. I'm not sure you fully understand how that works.
The univrm system provides ABSTRACTION to avatars, much like the vrchat sdk provides abstraction to the standard unity humanoid rig. they would simply attach the relevant parts in the same way, by 1:1 attachment of the bones.
I've literally written code to do this for rootmotion VRIK in the past.
Cibbi
Lhun: Yes, i do understand how mesh importing works, quite well, what seems like you didn't get from my previous comment is that once a mesh is imported into unity with whatever importer (being it the one for the fbx format, vrm, obj or whatever) then it is internally converted to his own format, so unity doesn't have to ask itself what format conventions needs to use for every single mesh and instead uses his own (also the internal data rearrangement helps the engine for the rendering process and some other stuff that would go off topic so i'll cut it off).
What is actually uploaded to vrc is pretty much an asset bundle containing a prefab of the avatar gameobject, with every component it needs already "baked" with it's own conventions, meshes included.
So at the end if you have univrm you can already import vrm models and then upload them in vrc, what you can't use is all the univrm included components for it's own avatar system.
And that's fine in my opinion since as you already said vrc has it's own for humanoid avatars (actually generic ones would mostly work too if they will ever fix the clientside issues, but that's another story) and putting this one on top would probably break quite a lot of stuff. And while vrm avatar system in univrm is intended for vr in general, is not specifically made for vrc, which means that they would need to rebuild most things they already have to work with the univrm system. Way too much effort for adding support to a single format that you can already get to work in vrc with just 10 more minutes spent after importing it into unity.
Lhun
Cibbi: okay, we're on the same page, that's clear. I assumed you didn't understand what you explained in the previous comment, I'm sorry about that.
I'm actually instead suggesting they support directly glb and vrm in a quasi "native" way. This would allow vrm imports without needing to even touch unity, (they could have people link to them from the website) and would bring the performance benefits as well.
This would require a Vulcan build, however.
Cibbi
Lhun: with the way they currently store avatars right now, i don't think i direct import like that would be easily doable unfortunately. More feasable would be making a separate downloadable application that imports a vrm avatar and then automatically applies the components needed based on the informations contained in the vrm file, and just uploads it to your account.
1029chris
I would really like to see avatar LOD too, a high poly avatar for up close, a low poly decimated version for further away.
K
Konchu
See I personally see the limits as a good thing overall cause quality is a must and I don’t feel there would be a good experience running full pc on quest.
I would personally like if they abandon the term for “quest” I would like users to be able to select a universal avatar and a enhanced avatar. This way you could restrict some worlds that need the performance for more players.
And if everyone had a basic avatar I could see that on my quest. Could even have a standard to like the low and hires versions like an old system for avatars hell through a billboard option for far away and maybe we could get even more quest people on server.
S
ScrinnodStudios
There is already selectable settings in the game already for each trust rank from visitor to trusted user, you can already enable or disable features for a rank as listed, Voice, Avatar, Audio, Lights and Particles, Shaders, Custom Animations, and Dynamic Bones, Quest users will have everything hidden if an avatar is not quest/crossplay by default if you do not know what each thing dose heres what they do
.
Disabling Voices will mute that rank, Disabling Avatar will hide the whole avatar, Disabling Auto will mute any and all auto the avatar has on it, Disabling Lights and Particles will disable the lights and particles an avatar has for that rank, Disabling Shaders will disable any non vrchat approved Shaders NOT TEXTURES, Disabling Custom Animations will stop custom overrides and animations for that avatar for that rank, and Dynamic bones is already explains what it dose ingame but Dynamic bones are bones with polygons that have been weight painted to the Bone so they can move/flow like hair or dresses etc,
.
In terms of Worlds thats up to the uploader and creator of the map/world and because anyone can upload a world to the community Labs (and then public) after they get the "new user" rank they can upload any contents to the game after that point and everyone does not know how to optimize or use unity or even know how the 3D model at all and that is why most worlds are poorly made and unoptimized, then you have vrchat themselves uploading new versions of game with new sdks that people have to learn again in order to figure out what makes the game run and what makes things optimized, with the Oculus Quest being very brand new we and others do not know what makes the Oculus Quest tick yet and what makes it perform good however, with feedback and bug reports from all parties this can be hastily speed up to make the game even more perform better, but everyone loves to complain instead of help in any way they can so that's going to take a little bit longer,
.
the problem with performance in vrchat is not JUST and ONLY due to the world's or the avatars it's mostly due to the amount of people because of the IK that the game has to track for each individual users to sync up with all their avatars bones to their controllers and Full Body in X,Y,Z locations back and forth between one and another for everyone in a server, then and only then can you account for what the users have on their avatars that also has to sync up with the previously mentioned details as well as sync up with whatever the world has between each other in between each user that is across the world across the town across the country across anywhere back and forth synchronizing everything of the player in VR or full body with everything on their Avatar synced up with the world synced up with all the IK with all the programs and components a world and Avatar has to be synced up with the server back and forth between users,
.
Polygons on their own do Nothing, Bones on their own do Nothing, Materials only effect based on how much and that their settings on the shaders they use, you can have a 10 Million Polygon avatar and it dose nothing if you know how to Optimize it, also the quest can only load at or under 50MB of content so an avatar or world with at or under 50MB is good to go but it matters on how the people made and choice the settings of everything that will determine the performance of an avatar/world even if you make the MOST BEST Optimized world and avatar in the game every, it comes down to player IK Sync that is the most demanding of them all the more people = more sync = more demands.
Jar
ScrinnodStudios: I have also observed that the overhead per player seems to have a decent performance impact regardless of avatar, but actual avatar specs doesn't amount to "nothing", it's still the responsible thing to do to keep them as performant as you can, regardless of how slow the base game functions are.
That being said, maybe instead of the OP's suggestion of hiding avatars with distance, the game could disable non-avatar-specific stuff like animators, IK sync, etc at a distance, if that would even help.
Jar
Additional features to hide avatars and boost performance is always good, but I disagree with the message in your post and in the other comments here. Content does not have to equal worse performance. Just make optimized content. Historically, restrictions often spark creative solutions. There is no reason to raise the polygon, material, bone limits on quest since they are fine right now and an approximate one-size-fits all solution just makes sense for fixed-spec hardware like quest. If there are frames to spare, that's a good thing.
CurtisVL
From my understanding, polygon count doesn't have a huge impact on performance until it's at insane numbers. (Such as above 70k which the VRC SDK tries to limit users to - Consider avatars in many other games are only 15k to 20k polygons)
The biggest performance hits come from choice of shaders, material count, and dynamic bone usage.
You could have a 5k polygon avatar with some crazy multi-pass shader and 5 materials and it'd perform worse than a 40k polygon avatar with a single-pass shader and 1-2 materials.
Maybe the polygon limit should be raised a bit, but other components of avatars should still be limited heavily to avoid performance issues.
PMS_Jordan
CurtisVL: I completely agree about the poly count. My FPS is fine with other quest users with 10K+ avatars. I like the other suggestions, but from what I've been told us Quest users don't have access to specialized shaders. On my settings the ability to view shaders is blocked out. Also, I've been told that we can't see dynamic bone usages and I personally can't see it. I never see other parts of avatars move at all, such as hair and clothing. However, I have seen people with avatars made with 4+ different materials, but i haven't checked my FPS around people like that yet so i don't know how hard it hits my performance. I haven't really noticed any big dips from it. The only thing I've noticed that wrecks my FPS is rooms with over 20 people in it.
PMS_Jordan
Quest User here! Please don’t limit our polygon counts to something low. I rock an avatar with 24k and most of my Quest friends have ones with 15k+. I don’t notice any performance issues from them. I’ve actually had worse performance FPS with the default under 5K avatars provided for us.
Kenoli
To elaborate on the main post, unoptimized avatars alone don't necessarily cause bad performance. Other factors, such as the number of users in the world, and the detail of the world itself, are just as significant.
Having specific limits on certain model stats isn't a solution that can adjust to the different situations that users might be in. It's a one-size-fits-all system, which will leave small groups in simple worlds with unnecessarily low-quality avatars, while large groups in complex worlds will be stuck with low performance anyway.
This is why there are suggestions for various methods of hiding avatars, which can be done more dynamically. The core suggestion here is adaptive performance controls.
Load More
→