Developer Update - 28 August 2025

Official Dev Updates
41

Yes. You have some listed in your canny tickets. Until we get better tools, this can’t really change.

Don’t bundle the two together. “No, I want crashers!”, don’t be ridiculous. You caused stutters by lazily implementing scaling, it wasn’t an issue before a shoddy implementation of cloth scaling by continuously re-initialising the component, aside from per-frame performance impact itself.

2000 coeffs per component would be a good middle ground if cloth component was robust and could be used in smarter ways. There is a reason we’ve been asking for something like magica cloth or even obi cloth to be integrated, even before clothsim library swap happened. NVCloth scales mostly linearly, so it’d be nice to see an explanation to how you’ve arrived at quadratic scaling. Loading is the bottleneck, but it’s still fast for realtime.

As is, I’m actually in favour of obi cloth due to its implementation of cloth proxies that allows low resolution meshes to be simulated, and high-res meshes to just be skinned after low res’ verts. That would be the ideal middle ground here.

Suggesting physbones for clothsim is laughable. They are decent jigglebone systems and some janky inputs, not much else outside of that. Especially prominent is its limited collision detection.

But no, even 2000 coeffs isn’t going to cut it if you want your ususal, lazy way out of the predicament you’ve pushed yourselves in. Though here are some options:

  • Add clothsim to safety options (why is it not handled in the first place?)
  • Add a maximum solver rate option to performance settings (better yet: a solver rate multiplier)
  • Add a maximum coeffs option to performance settings, ideally with a toggle
  • Stop refreshing cloth on scale change
  • Implement a burst-based or compute-based clothsim

If you can implement cloth proxies, that could justify ~2000 coeffs per component, could probably even go lower. Until then we’re forced to use primary meshes for simulation, which tend to be higher resolution than typically would be necessary. What can you offer instead of axing yet another component?

Developing this from scratch?–Sure, takes a while. Not integrating an existing solution, though. A single middle/senior tools or engine programmer can audit the package and implement its integration within a week, give or take.

15 Likes
42

I don’t use Cloth, and I almost never see other users using the component, but I still don’t think that adding a hard limit across the whole service is a good idea.

I assume that, for VRChat’s business, the FPS of general users is more important than the 3% of creators. This is understandable, and I even believe VRChat should pursue a more profitable direction. However, there is no need to add a hard limit to Cloth just to secure FPS for general users. Even if such a limit were to be imposed, wouldn’t it be more reasonable to provide a default-off toggle to enable Cloth, or simply disable Cloth globally in public instances?

When I experience a severe FPS drop in public or friends+ instances, yes—that feels terrible, and maybe I might have quit playing if that was my very first instance. However, if it happens in friends-only or invite-only instances, I can just ask that person to change their avatar, and it doesn’t feel bad at all. After all, we always have the option to unfriend them.

If there is truly a strong need to restrict the component, perhaps a user-based setting like “show avatars” could work—something like an “enable Cloth” toggle. To me, this approach still feels unnecessarily painful for Cloth users, but it is better than enforcing a hard limit.

On the other hand, I am rather skeptical about providing documents and recommendations. My friends generally don’t read VRChat documentation before uploading—not because it’s in English, but simply because they don’t understand it. For most users, the Unity Editor is just an avatar uploader, not a development tool. They rarely care about performance issues, whether for others or themselves.

One thing I’m curious about is this: if there are only a very small number of avatars that actually use the Cloth component, will this change really bring a meaningful performance improvement? Crash prevention is always a good thing, but if that has already been achieved, why introduce a change that doesn’t affect most users? As I mentioned at the beginning, it’s very rare for me to see avatars with Cloth at all. I suspect this is because Cloth users tend to group with other Cloth users. If that’s the case, why can’t we simply leave things as they are?

7 Likes
43

Wait are you saying you’re going to introduce a new type of pickups that cannot be held by holding the “grab” button, and can only be used with “grab-toggle” instead? That sounds like a terrible idea for Index controllers users. These controllers have a grip sensor instead of a grab button, so you can’t reliably “click” it to grab and release. When Index controllers users want a hold toggle (or a “sticky pickup”), they usually bind it to some other button - a thumbstick click for example - because the grip sensor isn’t suited for a binary toggle interaction.

Why is the responsibility for grab behavior even being pushed onto world creators? By all definitions, it should be a user preference whether their grab functions as “hold” or “toggle.”

1 Like
44

There was a statement from tupper on this a bit ago (reshared it on the canny as well)

45

Not having a 2000 limit on Cloth components would be very helpful for clothing creators, because it would allow them to make elegant skirts and dresses. Cloth is essential for achieving that graceful, flowing movement.

Btw, if only 3% of avatars actually use Unity Cloth, will this limit truly make a difference for the performance of the majority of players?

I think limiting VRAM (Texture Memory) would be far more effective :)

5 Likes
46

Cloth places a huge burden on the CPU’s cache and PCIE lanes, as well as the GPU’s geometry frontend, leading to poor efficiency.

Random vertex access has always been a bad idea, especially when the data structure for vertex organization is not good.

This makes solving for physics collisions very difficult, which can be seen in Unity’s limitations for concave mesh solvers and mesh colliders.

To this day, there is still no good enough solution, and the same applies to engines like Unreal Engine 5.

This ultimately leads to a situation where fewer than three CPU cores are used, and the PCIE utilization, though seemingly low, is actually at its limit. Inside the GPU, efficiency drops from 50-60% to as low as 30%, 20%, or even less. These are the problems behind this technology.

Statistically, there’s also an issue. How was this 3% derived?

Does 3% represent the most commonly used avatars by all players, or all avatars in total?

Does the community a player belongs to match the overall statistics?

What about the usage habits of different groups?

If 3% is for all avatars, but people who prefer high-fidelity avatars use them, then in a real-world environment, this number could actually be 30%.

The impact needs to be analyzed, understood, and evaluated with a proper sampling method, otherwise everyone’s perception will differ.

Additionally, a limit of 2000 vertices per single component is already a huge restriction for people who don’t know how to use and understand things in detail.

There’s no need to restrict every avatar to under 2000.

3 Likes
47

I wish to reaffirm this, the percentage of Cloth users goes down as the population increases but at the same time the number of Cloth users raises constantly with the total population

So the percentage makes it sound like only 3/100 people use it when in reality it’s 6,000 out of an estimated 200,000 daily

Percentages are very easy to misrepresent data when you’re not showing the full number

2 Likes
48

I understand why you’re skeptical of documentation.
However, even if it ends up being meaningless to the majority of people, there’s a chance that the correct settings will gradually spread if only a small number of creators refer to them. Of course, I understand that this possibility is low.
Without documentation, this chance would be exactly 0%.
For this reason, I don’t think it’s completely pointless to provide documentation.

Additionally, if any of us need to help a cloth item creator, all we need to do is point them to the documentation.
Even if it’s something that the majority of people ignore, there are still people who need it.
Most people don’t read product manuals, but that doesn’t mean everyone doesn’t read them.

4 Likes
49

This is a big reason I also have not touched Cloth because this is literally right here. On top of how performant it generally is to begin with, speaking without having actually used the default Unity Cloth for what it’s worth, I just also happen to think this is ridiculously easier to work with/configure.

I’m also oddly sure that if they reached out to the developer behind Magica Cloth (which in general is on Magica Cloth 2 since the original version as well), they’d love to probably collaborate with getting this stuff integrated to VRChat, or at least it seemed like they were interested based upon some tweets I recall seeing on their profile.

In any case, I’m gonna need to see some movement on this because for me personally, this is the one thing that’d actually motivate me back to trying with creating content again, as sometimes what Physbones can provide doesn’t feel like enough, and I’m absolutely not touching the default Unity Cloth function.

50

Ourself, we’ve yet to fully get away from using a little cloth in skirts because of never being quite happy with attempts to convert to physbones previously. Ended up being just a “kinda” passable backup option for if ever visiting an extra crowded event instance.. :thinking:

51

I am opposed to the limit of cloth vertex.

I have a few avatars that use cloth, and I went to check the vertex amount.

For context I normally use it for traditional style Chinese clothing.

In most cases the vertex count is slightly over 2000, and these are done by assets I have purchased, i.e., someone who knows how to configure cloth properly.

The one avatar I have, where I added cloth later by myself, admittedly is way heavier than it should, as the mesh was not made for cloth and has a way higher vertices to start with. (I mean really unoptimized to the point any limit will kill it.)

However, knowing this it is made toggleable, and I use it only in situations such as when I am alone for photos, or with people who I know are fine with it.

People can hide this avatar and not show cloth, and even with this I have not managed to crash anyone with it, including my self-running on a laptop with VR.

Another reason I don’t want a limit is that it rids me of motivation, given I have time to learn to optimize mesh for cloth and make better settings.

I learned anything to do with 3D modelling when I started VRC and am a long way off with many things to learn, and I do it for VRC avatars.

I know you want to have every avatar super optimized, but given my goal is finding between where to compromise and where I need for avatar aesthetic, it will give me less incentive to learn as I will find it just pointless to aim for it, when using cloth.

I would much prefer a setting like particle effect in the graphic section with three options like 1. No cloth mesh, 2. Cloth mesh with max limit, 3. All cloth mesh.

I also second the integration of existing cloth-like components with less performance issues. (I know you said you won’t but, I still remember you had VRC cloth in roadmap until the EAC update.)

7 Likes
52

As others have pointed out, there are many possible approaches to imposing limits, yet this particular decision feels, frankly, dishonesty to the creators who have skillfully utilized the Cloth component to produce high-quality outfits.

There are forms of expression that can only be achieved with the Cloth component. If the reasoning becomes, “Well, it’s used by less than 3%, so it’s acceptable to omit it,” then it raises serious concerns about the future of other avatar-whitelisted components as well.

For example, I create avatar gimmicks that bring soft shadows through the Light component, and Rigidbody physics to represent natural breast movement. But if these components too might be suddenly omitted “for performance reasons,” it becomes difficult to maintain motivation to continue developing within VRChat.

translated by chatgpt

8 Likes
53

how hard is it to add support for Magica Cloth if u had the bugget to make Physbones …. sure not many of my avatars use Cloth but still if we had Magica im sure more would use asp on dress and we would finaly not had to use 60 physbones to lag people

54

having 6gb vram to join any gathering with more then 20 people and have to rejoin every 5 min to clean vram and none of them use cloth but yah lets focus on that 3%

3 Likes
55

no cloth no life

cloth limit is bad judjing

so please withdraw this statement

2 Likes
56

Not as a pioneer of unity cloth, but as for the hard limit on cloth component,

Maybe listen to the community?

I highly doubt it’s a legitimate change according to the comments.

Is it not possible at all to keep the potential alive while having a proper ranking system and good documentation as they say?

2 Likes
57

Until an alternative is available, wouldn’t the most balanced choice be to gate it behind the Safety setting, with that setting off by default?

For those who have been working on Cloth with real enthusiasm, there’s a very real possibility that disappointment will lead them to leave VRChat. I’ve seen this happen before in contexts other than Cloth. Trust is built little by little, but it can be lost in an instant.

I ask for prudent judgment.

6 Likes
58

I oppose tightening Cloth restrictions until alternatives are ready.

Please freeze any strengthening of restrictions until alternative solutions are provided.

If you proceed, base it on viewer-side (display-side) controls rather than removal on the upload side. It is unreasonable to unilaterally force creators to rework their content.

I disagree with the notion that “because usage is small, it’s acceptable to impose strict limits.” The absolute numbers and the impact on specific communities are not negligible.

There are higher-priority optimizations than Cloth. Please reconsider the order of priorities.

5 Likes
59

I think we already mostly agree on this point. It is nice to have good documentation, but that is not supportive enough for make someone reconsider about this change. That’s why I mentioned about the low percentage.

Actually, over the weekend, I started to feel like that it might be better to keep this component unknown and as-is. The more users know the component, the more would set it badly, and the harsher the limitations can become.

60

When talking about Unity Cloths, as we know PB is not a good way to simulate dress physics. It can be done, but always working with a complex PB chains and many tests. So Unity Cloths is still a useful solution. Also, sometimes we need it in some cases doen’t need so much peformance, like: taking movies, pictures, etc.

Also, some Booth assets using it and it’s hart to fix with PB, if someone doesn’t use Blender, it will be a imposible job — Those dresses always have no bones, so you can’t add PB compoments. It’s a lots of works on modeling. Also, when a dress have multiple layers of skirts/hermlines, and you wish they can work seperately, Unity Cloths is better than PB. Example asset using Unity Cloth with multi-layer dresses: LilyBell Re [45アバター対応] クラシックメイド服”LilyBell Re-order” #スイセレ - Sweet Serenade - BOOTH

So my suggestion is, keep it avaliable and tell users “Use it as your own risk“, until we have better solution.

Note: I think the perfomance of currently game client is kinda… meh. I already report them in here:

And more, I think it’s much more works on developer’s side, not simply disable a compoment. Kept a excellent application perfomance and expand the edge, it is developer’s job.
Especially is, after the avatar marketplace update, I can feel the frame rate is lower than recently average… Perfomance issue is always a complex question，requier a/many long time investment and optimization. And I believe you can do.

8 Likes