Flare answered this earlier in thread.
2 Likes
Mhh could it be possible to upload one’s own HRTF using steam audio’s support for AES standard SOFA format ?
The docs of the:
C API
UnitySDK
Can one enter the Twitter sweepstakes with a locked Twitter account?
I’m not a fan of this, personally. When making an avatar, I already have to consider whether people have my shaders and animators on or off. If not just toggling, but adjusting how many vertices are allowed, is an option I have to consider whether they see the cloth or not, and I have no idea even what that threshold is.
Which means cloth no longer exists, because I have to design assuming they have it disabled, and if I want dynamics I have to use physbones which are performant and will be visible. If I have an animator parameter to tell me if it’s enabled or not, I could rig it for both, have the physbones default to on, and use the animator to switch to cloth instead ifit’s enabled, but that’s also increasing complexity a lot - and I’ll take the combined rating even though only one would be enabled at a time.
I did see a suggestion to allow no limit for local test avatars for movie purposes and while that partially solves it, you need external IK smoothing tools and you can’t have a third-party camera operator at that point.
As such, while the idea of making the limit of it configurable may sound good at first, I think it’d actually be a really bad solution in practice. I’d rather there be a hard cap so I can design avatars for it. Having a toggle for a high limit or default limit is at least a compromise, as I could know the lower limit will always be shown and target that, while those doing movies or those who don’t care if people don’t see their dynamics could target the higher limit. (but why would you go for such detail if you don’t care if they see it?)
Really, the best solution would be reevaluating the perf impact, maybe using a higher limit as people have commented there was a bug making the performance worse when the limits were set, and - ultimately - writing their own that has similar performance and usability gains as Physbones and VRC Constraints do, or allowing Magicka if it’s more performant than unity cloth, potentially with higher limits. I’ve only ever heard good things about Magicka.
2 Likes
I think the VRChat community has proven over the years that no one cares to even slightly optimize their avatars. So I would suggest hard limits over the usual “trust the creator community” way of thinking we have right now.
Otherwise, maybe we need the avatar performance ranks completely overhauled. Or something stupid like new ranks, such as “extremely poor” and “overwhelmingly poor” for avatars that break multiple very poor limits at once.
Of course, if a new ceiling is set, people will race to see who can reach it first it seems.
We do provide an oauth model for partners – but they have to reach out through bizdev!
I sometimes wish we could calculate the amount of extra electricity used by certain avatars. That’s probably a dangerous rabbit hole, though. 
re: feedback on cloth physics – we’re reading it! We’ll probably have more to say after the weekend. For now, we’re just indexing what folks are saying so we can bring it back to the team.
4 Likes
I also believe there should be a setting to disable AutoHold.
For example: In my case where I have grip toggle binded to a button (A) rather than actual grip (I set my playspace mover’s drag to grip).
I would have to press (A) once to grab, then a second time to activate AutoHold, then a third time to let go, then I would have to press (A) again to disable grip to be able to pickup another object.
There’s honestly a good reason as to why we normally don’t try to push for whitelisting asset store stuff anymore and it’s mostly to do with two things
- updating the third party component may break all the other avatars using an older version, especially if it’s drastically different from the previous version.
- licensing + piracy of unity asset store products since Magica Cloth is something you pay for.
Just like the idea of trying to get an in-house version of Final IK it might be a good idea for VRC to probably make their own system that might be more performant to where it could even be allowed to run on Quest hardware so the avatars SDK can be near feature parity with PC avatars.
I’m interjecting but it’s for old worlds that may never be updated again + having a setting/binding for the new grab behavior would be more beneficial on a personal level, given how it should be more of a player’s experience than the world creators. Plus as it stands you already have this with vive wands so we don’t always hold down the trigger and we can let go with the grip button, and if the creator wants to have you drop it when you let go of the grip/trigger button I thought that behavior existed already in the SDK, especially with throwables.
I’m a developer of Unity Cloth items for VRChat avatars (formerly, at least) and did my best to research the topic back then. I’d like to share some of those findings, along with my thoughts.
Prefacing any suggestions I have, perhaps the biggest issue with Unity Cloth currently is that in most ways, it’s an unchanged technology of around 20+ years ago or so at this point. After Unity acquired the technology, they’ve since given more or less zero attention to develop it in either performance or authoring tools. Even Unreal Engine has apparently deprecated PhysX (the same SDK that Unity Cloth comes from) 5 years ago already. There’s also a number of Unity-specific issues with it that I don’t believe are going to be resolved, and I’m a bit impressed that VRChat still chooses to support it at all.
That said, I’ve grown very fond of it and its potential for expressing ideas that no reasonable amount of PhysBones could replicate, let alone the rigging work required for that. I’d be sad to see it removed, and PhysBones unfortunately isn’t a replacement for all the features Cloth can offer. It’s also unreasonable to ask VRChat to step in for Unity to improve the technology yourselves.
Within Unity Cloth settings, there’s a number of parameters that have very strong effects on performance, that could be limited by VRChat as a measure. Solver Frequency is a straightforward one that should have a reasonable maximum. Self Collision and Intercollision was another that had one of the largest impacts that I had measured. From a creative standpoint, limiting settings like these, rather than vertex count, would permit more while still keeping performance in mind. Personally, I think 200 vertices was such a low limit from the start that there’s little within those constraints that couldn’t be made instead with PhysBones.
I’ve created items that use slightly over 2000 vertices, and experimented with using less but couldn’t achieve the right result; so my own answer is that I have my use-case for the limit being around that amount. I’ve done my best to optimise them and reduce heavy settings within Unity Cloth, but I can’t speak for everyone in that regard, and ultimately aspects like the initial load being heavy (but not always(?)) were also somewhat unavoidable.
Anyway, please keep it around! If ever possible, I just wish it could run a little better.
10 Likes
We looked at the approach of enabling AutoHold via a setting in a way that would be backwards-compatible with existing VRCPickups and anyone who has customized/remapped their bindings and found it was untenable - there were too many edge cases where we might break existing functionality since pickups never did quite what they said.
While this approach won’t benefit worlds until they are updated, it ensures that creators can now be intentional with AutoHold across all input types. The existing AutoHold setting worked for Vive Wands, yes - but that’s the only VR controller they supported out-of-the-box afaik, the rest of the controller types ignored the setting.
2 Likes
long story short i don’t personally care about cloth. if what @Adi mentioned above is true and these limits are all based on old performance then i’d support a re-analysis, but in general if they’re still a problem, cloth components could behave like cameras, where you need to have someone friended or force their avatar to be fully visible to actually have the cloth working. 
2 Likes
only reason why I thought it’d be better as a binding would be for those that might make custom steamvr hardware, but that’s honestly a good thing to have it as a setting in game than a binding.
What is vrchat planning, im scared 
1 Like
Less than 3% of users use the Cloth component.
The Cloth costumes I normally use generally have less than 2000 vertices.
There are no performance limitations for other components, but I don’t understand why only Cloth is required.
4 Likes
Is there fees to become a partner?
I sometimes use Cloth components to represent long skirts. For this use case, a simple skirt uses around 1500 vertices, and with additional elements like fabric overlaps, the count increases further, so the 2000 vertex limit feels somewhat restrictive.
Also, while I recognize that there can be cases where initialization takes several dozen milliseconds of load, in my experience, even with similar vertex counts, the performance impact can vary significantly depending on the mesh geometry. This makes me somewhat skeptical about whether limiting by vertex count alone is truly appropriate.
If you do decide to introduce limits, I would appreciate consideration of the following points:
- If quadratic load increase is the issue, I would prefer vertex count calculation and limit application to be per-component rather than per-avatar
- Even when exceeding the limit, I would like it to be possible to enable the components when explicitly using “Show Avatar” (similar to how current camera components work)
17 Likes
I create items that use cloth.
I believe that cloth is a very important component, as it allows for expressions that cannot be reproduced with PhysBone.
I have the following concerns about the new 2000 vertex limit.
The meaning changes significantly depending on whether the limit is set on a per-avatar basis or a per-component basis.
If the limit is set on a per-avatar basis, I am opposed, as it will greatly narrow the range of expression possible with cloth.
On the other hand, if it is set on a per-component basis, I am in favor of it.
The reason for this is stated in the NVIDIA PhysX SDK documentation:
“Performance Tips” from NVIDIA PhysX SDK Documantation.
The runtime of the cloth simulation scales approximately linearly with the number of cloth particles and the solver frequency: Simulating a higher resolution mesh with more particles and increasing stretch stiffness and collision handling fidelity with higher solver frequencies increase the time it takes to simulate one frame. Additionally, there is a performance drop somewhere below 3000 particles for the GPU solver as explained in the next section. As a rough guideline, a dozen cloth instances with 2000 particles each and a solver frequency of 300Hz can be simulated in real-time as part of a game.
What’s important is not just the number of vertices in the cloth, but the setting value for the entire component.
Limiting the number of vertices alone will not essentially improve performance, and will actually limit the expressiveness possible.
In my opinion:
I think it’s okay to allow up to 3000 vertices per component.
The things that truly affect performance are the Self-Collision and Solver Frequency values.
In particular, if the Solver Frequency value is excessively large, a large amount of computing resources will be required when used in combination with Self-Collision. This is the main cause of crashes.
Specifically:
Enabling Self-Collision increases the calculation cost several times, so we will limit it.
NVIDIA’s recommended Solver Frequency range is 120-300, so a maximum of 300 is recommended, with around 180 recommended.
Limiting these two points should significantly improve performance.
Also, there is currently a lack of documentation on the correct use of the Cloth component.
At least in the Japanese community I belong to, this has resulted in the following issues:
Experienced creators learn directly from other experienced creators and set things up correctly.
On the other hand, other users lack information and may end up setting things up incorrectly.
We believe this situation would improve if official Cloth-related documentation were provided.
I think utilizing the existing shield rank would also be an effective performance improvement measure.
For example, if the shield level is set to maximum, clothing will automatically be disabled.
I think this makes sense, as situations where the shield is used to its maximum are likely to be resource-limited.
It also seems that VRChat has not given much thought to the clothing component up until now (for example, the avatar rank criteria have not been updated).
I understand that resources are limited, but I have one request.
Please enable “Update Offscreen” for the Skinned Mesh Renderer only when using Cloth.
This was previously possible, but was disabled at some point.
However, because Cloth only performs calculations when within view, unnatural acceleration occurs when a character moves out of view and then reappears, resulting in a distorted, unsmooth movement.
If this were fixed, Cloth would look more natural and beautiful.
As long as it’s under appropriate restrictions, it won’t cause performance degradation, so I’d be happy if they released it.
I’m glad that VRChat has mentioned the Cloth component for the first time in a while.
Thank you.
48 Likes
This 
3 Likes