Here are two examples of outfits that make ideal use of the Cloth component.
These are exceptionally well-crafted models.
ALMARIAN RE by LACHEXIA
LilyBell Re-order by Sweet Serenade
Here are two examples of outfits that make ideal use of the Cloth component.
These are exceptionally well-crafted models.
ALMARIAN RE by LACHEXIA
LilyBell Re-order by Sweet Serenade
To the VRChat Developers
I would like to add a follow-up.
The main cause of crashes related to Cloth is not the “vertex count.”
If you truly want to prevent Cloth-related crashes, the following measures are necessary:
Disable Self-Collision
Disable Continuous Collision
Set Solver Frequency to around the recommended value of 180
By implementing these measures, the computational cost of Cloth will be greatly reduced, and the likelihood of crashes will become extremely low.
On the other hand, if you only restrict the “vertex count,” crashes will continue to occur as before whenever parameters are configured improperly.
Furthermore, if strict vertex count limits are imposed, it will become impossible to create high-quality, visually appealing items.
Please do not lose sight of the original purpose.
NO. Of course, the vertices number can cause a performance issue, but it is not the only cause.
This will fail because even if you limit the number of vertices, malicious actors will attack with other parameters = Solver frequency.
Unless you want only to feel accomplished, stop adding the limit to the vertices number. For the limit to be effective, some more complex calculations would be required, for example, removing vertices not processed on ClothSim(Cloth Constraint/Max Distance = 0m), multiplying by the Solver Frequency, taking into account self/inter-collision settings, etc.
If the goals you present to users don’t have a technical proper, sure, but the limitation you impose on developers should have that.
I introduced very very good cloth creators!!
Istria cooperation item↓
https://booth.pm/ja/items/5819995
https://sweet-serenade.booth.pm/
please checking there items!!
wow ! beautiful !!
As a virtual fashion modeler, I consistently use the Unity Cloth component in my avatar outfits—mainly to keep the clothing looking natural and beautiful when sitting down. I recently released a long skirt outfit (like in the attached image) and got a lot of nice feedback about how the cloth skirt moves. I’ve been keeping my designs under 2000 Cloth vertices, but it’s getting difficult when working with layered tulle or multi-layered skirts. With the proposed limit, some expressions might no longer be possible. I’d really appreciate it if you could consider limiting things like Solver Frequency or Self-Collision settings instead of vertex count. Cloth creates a unique experience that’s hard to replace, and I’d love to keep using it.
First, my opinion on how hard limits should be applied. I think a well-balanced implementation would be to only perform security checks on the server side.
And next, my opinion on what properties the client/server should refer to when limiting. You should also consider other properties such as `Solver Frequency` when determining the limit. However, I think the cloth hard limit is intended to reduce the performance cost of component initialization (rather than the runtime cost). That’s why the limit is based only on the number of vertices…right? If that’s not your intention, you should change the limiting method, but if that’s your intention, it might be fine to leave it as is. I’d like additional comments on this from users who are knowledgeable about cloth initialization costs.
Would you be in favor of a reduced hard limit to avoid not just crashers, but also reduce the amount of avatars causing hard stutters on loading and scaling further?
This might be a bit off-topic, but if this is a real issue, it might be better to limit scaling specifically for avatars that use the Cloth component, rather than restricting vertex count. Personally, I’d rather see one VRChat feature temporarily disabled than have my avatar break entirely.
Of course, I understand that from your perspective, you want the feature you create to work perfectly… But so do we! We want our content to work perfectly, TOO. The most valuable part of VRChat is that the content created by the community continues to work and remains accessible.
Maybe the reason this announcement hasn’t been well received is that people are afraid their avatars might be the next ones to be burned…
To add to the Unity Cloth discussion…
At the risk of sounding like advertising, I’d like to share two works I’ve made using Unity Cloth for VRChat. I don’t feel like I have any suitable alternatives for recreating these, without significant compromises. These are 2,532 and 1,601 vertices respectively, so they’re both somewhat in danger by the proposed limit: Item 1 and Item 2. Both links are YouTube videos, because I believe Cloth is still unmatched when in motion.
I’ve done my best to make these appear high detail, with texture work, normal maps etc, but for reference: the triangle counts of these are only 4,901 and 3,152 tris. More complex clothing like dresses I think would be impossible with the limit in place.
hello!
I’m talking about only the cloth limits but,example I want to choosing shield level that show me much cloth vertice (and other heavy components)with.
sure thought it is so cannot be allow to show me too heavy components to stay there comfort,for good experience with friends.
For example if include so heavy components,wanna show the button for alert to show or not. hmm
As mentioned before: VRChat client performance has been steadily degrading over the past year.
It’s true that everyone wants a good framerate in the VRChat and no more crashes, but hey, we’re not going to fix VRChat Unity Animator Lag | Voters | VRChat | [1694] Performance fallback while loading and unpacking avatar | Voters | VRChat or anything else that’s affecting everyone. Let’s focus on Unity Cloth, which is only used by 3% of avatars.
“What were they thinking” is the first reaction of almost everyone I know when they read this article. The worry then becomes, who’s next? PhysBone? Light? Too deep PB/Constraint nesting levels? Too many animator controller layers?
Let’s be frank: performance ranks don’t “rank” performance at all. This new limitation in Unity Cloth will only infuriate creators, because they’ll lose another useful tool from their already small toolbox, even though most people will never use it. Because everyone knows that the tools will only get fewer and not more. That’s the point.
The primary reason VRChat has attracted users and achieved unrivaled market share lies in the rich expressive freedom granted to its users.
My experience is that many Japanese creators have remained in VRChat precisely because it serves as a place where they can casually share their meticulously crafted creations, much like at Comiket in Ariake. We must not forget that this has been driven by the dual pillars of captivating Worlds and diverse Avatars.
Claiming the impact is small because only 3% of avatars use the Cloth Component is sophistry.
This is because repeated requests for improvements to the performance evaluation standards of Cloth Component have been made since 2019, and Canny clearly demonstrates this is a sign of demand.
Repeating such careless decision-making errors will inevitably lead to throwing away the fruits of our labor.
This resembles a common sneaky tactic used when seeking to shut down local public transportation: deliberately changing the system to be inconvenient under the pretext of funding shortages, thereby naturally reducing ridership.
These expressiveness-diminishing modifications will render the Cloth Component obsolete. Several creator friends who have sold Cloth-compatible outfits despite enduring inconvenient restrictions will likely give up this time… not just giving up on getting the Cloth Component into their dress, skirts, but also on trying to make constructive requests to VRChat.
I wish to continue using my friends’ high-performance outfits. Therefore, I cannot overlook these intolerant specification changes without mentioning the history of requests from Canny.
Under the current performance evaluation limit of CLOTH MAX VERTICES, we get a result in a “very poor” rating for nearly any use case of an avatar’s effect of appearance with Cloth.
In fact, for me, I’ve used an avatar for years, for which most metrics are “medium” grade, except CLOTH MAX VERTICES, which is 760/200, but it’s dropping to “very poor” solely.
The decline in Cloth Component users isn’t due to a lack of incentive to use this compelling technique for naturally flowing cloth costumes. It’s because VRChat avoided confronting complex issues for years and neglected to review the weak evidence values for the medium 100 / poor 200 vertexes. Users have also conducted verifications like the following:
You have already lost the trust of one engineer possessing this knowledge when you were implementing EAC in force, yet this information still remains beneficial.
I also think so. This issue may be avoided not by limiting the vertex count, but by restricting the values for Continuous Collision, Self-collision, inter-collision, and Solver Frequency.
I am courious i have a dress outfit that i have running with physbones but i wanna convert it over to unity cloth, what is the best ways and tips to actually use cloth?
If you use Blender, separating the part of the mesh affected by Cloth into a standalone object makes it much easier to handle.
Avoid using Inter Collision, as it is very performance-heavy.
Properly adjusting Distance and Surface Penetration values can solve many clipping issues.
Implement a reset Cloth function, you will need it.
All vertices should be connected as much as possible. If a section, such as an opening or a pocket, is not connected to the main mesh, it will behave like a detached object and fall away.
Complex clothing designs are difficult to drive with Cloth.
Avoid applying Cloth to too many vertices, as performance will drop sharply.
Disable Cloth when it is not needed.
While the Cloth component allows you to assign unlimited colliders, in practice only up to 32 colliders are valid. Any beyond that will be ignored.
Solver Frequency that is too high consumes excessive performance, while too low reduces quality. Keep it roughly between 60–180.
Thanks for your feedback. This is the current situation.
We have tested Cloth in modern versions of Unity and Cloth components with 1500 or more vertices. These components can cause significant hitching during loading and while scaling an avatar, which can be seconds long. Internal and external testing confirm this, as well as multiple Canny posts. Hitches of this magnitude represent a performance issue and need to be fixed.
In addition, while it is not a method currently used to crash people, it is a vector. It represents a significant issue with the base Unity cloth implementation. This is where our concern originally came from.
We made this post primarily to gather feedback, not to show intent to take immediate action. Thank you for posting feedback.
Based on your feedback:
このセクションはChatGPTを使用して機械翻訳されています。内容の明確さや意味に問題がある場合はご了承ください。
ご意見ありがとうございます。現在の状況をお伝えします。
私たちは、最新のUnityバージョンにおけるClothと、1500頂点以上を持つClothコンポーネントをテストしました。これらのコンポーネントは、読み込み時やアバターのスケーリング時に大きなスタッターを引き起こし、数秒間 に及ぶことがあります。内部・外部のテストや複数のCanny投稿でもこれが確認されています。この規模のスタッターは重大なパフォーマンス問題を示しており、修正が必要です。
さらに、現状ではこれが人をクラッシュさせる方法として使われてはいませんが、その可能性があります。これはUnityのCloth実装自体の大きな問題を示しており、私たちの懸念はここから始まりました。
今回の投稿は、即座の対応を示すものではなく、フィードバックを集めることを主目的としています。ご意見いただきありがとうございます。
いただいたフィードバックに基づき、以下の対応を行います。
パフォーマンス問題を引き起こすセルフコリジョンについて、調査および回避策・修正を実装します。多くの方が独自の調査で原因として指摘されており、私たちも調査します。
Clothコンポーネントあたり2000頂点のハード制限は実装しません。この判断が正しいかどうか確信が持てなかったため、皆さんに質問しました。回答いただきありがとうございます。
このフィードバックを、将来的なClothシミュレーションシステムの代替検討に含めます。
残念ながら、このシステムのETA(提供予定時期)を提示することはできません。しかし、VRChatのパフォーマンスを改善しつつ、美しく滑らかなClothを実現したいのであれば、代替システムの構築が不可欠であることを、皆さんのフィードバックが強く示しています。
多くの方がMagica Clothのようなサードパーティコンポーネントの利用を提案してくださいましたが、これは私たちがVRChatを構築していきたい方針とは一致しません。確かに、導入すれば早く成果が得られると皆さんは考えていることを理解していますが、それは私たちの開発方針に反するため採用しません。
To the VRChat Developers,
Thank you very much for making decisions based on the comments and feedback provided.
Regarding the restriction of Cloth vertices to 2000, it was initially unclear whether this limit applied per component or per avatar.
If it had been enforced on a per-avatar basis, it would have severely limited avatar expression.
I would like to continue exploring better ways to utilize Cloth together with the ongoing development of VRChat.
On the issue of hitching when using Cloth with more than 1500 vertices during loading or scaling:
When an avatar is loaded, many processes are initialized simultaneously, and it seems that sufficient resources may not be available to also initialize Cloth components at that exact moment.
For this reason, I personally use an animation clip to delay the enabling of Cloth components by a few frames after loading.
This method helps improve the user experience to some extent.
As for scaling, one possible measure would be to temporarily disable Cloth components during scaling, and then re-enable them once scaling is complete.
Once again, I sincerely appreciate that you have taken the feedback here into consideration.
I believe the reason they don’t want to implement it or even use it as a filler solution for the meantime was because they didn’t want another Dynamic Bone situation. A long outdated SDK that only updated because VRChat dropped support and DynBones lost an estimated 90% their sales overnight and floundered to recover that income
However, Magica Cloth is a group effort and even has a roadmap with active development
If VRChat decides to do so, they can choose a specific version to support and approve an update later on
The biggest drains I see aren’t the flashy features people blame—they’re the habits we’ve all picked up while making avatars and effects. Here’s a cleaner pass at what actually hurts, what helps, and what would make the platform more fun.
Cloth gets singled out a lot. It can be heavy, but most slowdowns come from other places. Two simple guardrails would already help:
Uploader nudge. If an avatar includes cloth, the upload window could show a gentle, yellow notice with a link to docs and a reminder to toggle cloth after loading has finished.
FX-layer assist. Give animation clips a cloth helper the same way VRChat exposes other special parameters: a small set of presets that behave well during load and offer predictable on/off behavior.
I still want better cloth. Dresses and skirts are rare because creators avoid them. If cloth is both pretty and predictable, people will use it—without tanking their friends’ FPS.
The old pattern goes like this: every item is its own skinned mesh, you flip objects on and off, and you hide body parts with blendshapes. With modular clothing packs built for common bases, folks often tack pieces on without merging or reducing bones. That’s how you end up with duplicated bone chains, extra scripts, and weird conflicts that follow you from outfit to outfit.
There’s a smarter way that barely anyone adopts: one combined outfit mesh, one material, and a second UV map (call it UVHide). Put the toggleable parts into separate UV tiles (a 4×4 grid gives you sixteen slots) and drive visibility with a shader’s UV‑tile discard. For body clipping, push the matching faces on the body into their own tiles too. Same trick, no blendshapes. The result is fewer draw calls, less overhead, and a much calmer frame time.
If the standard fallback shader understood UV‑tile discard, creators wouldn’t be punished when others disable custom materials. Expose a bit more control to custom shader authors (think Poiyomi and friends) so their discard logic survives fallback scenarios. Teaching UV‑tile workflows only makes sense if the fallback path doesn’t break them.
Roleplay and combat lean hard on particles, and right now we rely on hacks—buffered sub‑particle nesting, odd setup tricks—to make guns and effects feel consistent. A supported alternative would go a long way. I know we’re on Unity’s BIRP, not VFX Graph, but an in‑house solution (or a practical hybrid path) would let creators build bigger moments without resorting to duct tape. This isn’t just a performance topic; it’s a fun topic.
The new pickup flow is a step forward, but Index users in particular run into a wall: dropping can feel clumsy, and you either grip too softly and lose the item or grip ever harder until your hand aches. A simple mode—grip once to hold, grip again to drop—solves that. Let it be the default, with a toggle for people who prefer classic behavior. “Just don’t grip hard” isn’t realistic; bodies tense over time. It’s the same reason flight sticks wear you out without the right ergonomics.
I even recall VRChat having a grip‑strength setting in its early builds, though I’m not sure if that memory is accurate. Whether it truly existed or not, something like that would be welcome again.
Long‑range effects die when the avatar isn’t visible. RP groups work around this by attaching a hidden, oversized skinned mesh to keep the FX system alive—a silly hack that everyone knows about. Please give us an option to control animation/particle culling so combat and long‑distance cues remain reliable without tricks.
VRChat has real strengths: hosted worlds and networking that don’t collapse onto a player’s PC, no storage paywalls at the first sign of scale, and mature custom shader pipelines that advanced users rely on. Resonite, on the other hand, lets people express themselves in ways VRChat doesn’t yet match. If they fix hosting, performance, and provide shader parity, many power users would at least experiment there. I haven’t moved because running two avatar workflows is pain—but it’s a reminder that steady improvement matters.
Make cloth predictable and worth using. Normalize UV‑tile discard and teach it. Modernize particles so weapons and toys don’t need hacks. Bring back a humane grip option by default. Expose an anti‑cull switch for FX when players want it. Keep investing in physics and creator tools so the platform feels like VRChat and a bit more like a VR game.
We all come here to build worlds and have scenes that feel alive. Better habits, a few smart defaults, and some targeted engine love would do more for frame time—and for fun—than focusing only on cloth.
Last thought
I know some people who keep all their avatars jammed into a single Unity project that never stays up to date. When they’re finally forced to update—sometimes a year or more later—they get frustrated and blame VRChat for pushing them, even though the real issue is neglecting updates. A lot of folks only see Unity as an upload button and nothing more. I don’t have a perfect fix for that, but it shows why performance complaints are often about habits as much as features.
From my own experience, when I take care to keep both my avatars and my PC well‑maintained, VRChat runs far more smoothly. Since the anti‑cheat rollout, the addition of chatbox, earmuffs, culling options, and other quality updates, performance has steadily improved. GPU VRAM stability in particular is much better than it once was. That work hasn’t gone unnoticed. What would be amazing now is if avatars themselves, along with particles and cloth, could receive that same kind of focused love.
They should implement an in-world notification system to replace the need for an avatar to carry around a bunch of baggage just to send signals to others. It could be part of the Groups system as an added feature. This would allow for permissions and avoid it being abused in random public worlds, etc.
IMO… just an idea for one use case.
i think this is an exceptional idea in particular, and should be called out as a potentially lower-hanging fruit for improvement
there are two canny posts i can find related to this, one about adding the same functionality to mobile shaders and one for fallback shaders, both of which are worth consideration:
uv discards aren’t really viable for performance optimization stuff, only to basically serve as toggles