Major cloth issues in v2019.2.0f1

That would be stellar, since I have been having this kind of issues with Unity cloth since they removed the regular cloth simulation on Unity 5...
Maybe it needed to be completely broken for them to fix it...

 

I had the same issue using version 2019.2.12. Disabling the Optimize Mesh setting worked just fine for me

 

It doesn't fix it, it just makes the bugs less obvious.

 

That is true. This is not a fix, just a workaround but with some tweaks it can give pretty decent results at least in my case. I don't think there's a fix yet? Since it seems to be a problem with Unity's cloth component

 

My first impression was that there are multiple bugs with cloth and the Optimize Mesh solution fixes one, but not the other. I could be wrong, but based on my observations it seems the Optimization function leads to some glitching in the Editor because turning it off stopped distortion from occurring outside of Playmode on my bugged meshes. However, going into playmode caused them to fly around wildly with random forces.

I finally received an email from the bug testing team that supposedly claim everything cloth related is being investigated with the "dissapearing" report on Issue Tracker. Those fixes are stated to come in when 2019.3 hits, but I have no clue how long that will take. And there's no guarantee that every single bug has been investigated properly but I guess we'll see.

 

OMG that would be ASWESOME!

 

Just checked the issue tracker today and coincidentally there's been a report that Cloth is "working" in 2019.3.0f1.



I'm not sure if it's been added to the Unity Hub yet but if anyone wants to try it out, maybe the 2019.3 beta will have the fixes. I'll wait for the official release if it's not already out and check when I have time. I'll report back if I can verify that everything has been solved.

 

Tested this on 2019.3.0f1. Cloth still not importing well from older version. Redoing is the only option I feel. I had to redo cloth from 2017 to 2018, then now from 2018 to 2019. I admire that Project does upgrade pretty well without any other issues. I feel working with Cloth upgradability must be a too much for Unity Team. I am planning to use Character joint based system to fix it permanently.

 

Maybe you should try this asset first: RADIAL CLOTH
Pure C#, source code included, not a single DLL or compatibility issue (unlike UbiCloth, which doesn't work on consoles)
Performance is good.
Even if it's just an approximation to real cloth, it works surprisingly well.
I purchased it two or three weeks ago and I'm planning on using it for clothing if Unity doesn't fix native clothing.
There were some issues at first with later Unity versions, but contacted the author and he fixed all of them.
Since it's not actual physics math, performance is good but requires more manual setting on your part.

 

I briefly tested release version of 2019.03. It seems better, but for me still huge issues which make cloth unusable. Huge frame drop, and still not stable looking. Only tested with one mesh, which worked fine on 2019.01. Also switched off optimization as suggested earlier.

 

The problem is the vertex order option in the optimize mesh dropdown.
Cloth seems to work like it should when it's off.

Also tried this in 2019.2 and that fixed it too.

 

It's not just that, because disabling mesh optimization completely doesn't fix all the issues: cloth no longer vanishes but it still reacts as if it was full of helium and wanted to fly away. Import a sphere from any 3d package and use the cloth component on it to check this out.
Maybe it's only noticeable on concave clothes.

 

I tested in an empty project on 2019.3.0f1 and the issue is not fixed and shows the same result. A bunch of vertices are all over the place as soon as I add a cloth component. Disabling mesh optimization only reduces the amount of misplaced vertices.

 

In 2019.3.0f3 is the same - cloth component is unusable - I hope that they fix id before public final 2019.3 version.

 

@atomicjoe I just had a chat the other day with Charles Beauchemin from Unity Team on Twitter. He claims that the physics team have found the cause of the issue and are still working on a fix. The 2019.3 official release is also expected to come out sometime in January 2020, so I'm guessing that's likely when the bugfixes will come through. Considering how many reports they've gotten I'd be hopeful that it's a full fix for both the editor glitching, disappearing/distortion/random forces, and performance issues. I'll keep an eye out for when they release and test it out.

 

I really hope they fix it, because right now my character has lost a lot of realism, since it was designed to use cloth physics everywhere and I had to disable it completely.

 

any update this issue?

 

Just what Mr. Beauchemin said last month--the 2019.3 official release (not the 2019.3.0f3 testing release) is planned for sometime this month. 2019.3 is in the final stages of testing so I wouldn't expect it to take much longer. It's also mentioned that the 2019 LTS will start soon, I'd assume they'd port all the fixes over to that build if you don't want to make the jump as well. I'm not sure how many new features are actually in 2019.3 or if it's worth it to upgrade considering more stuff might be broken... I'll have to see when that option is available. Aside from that, they now list multiple fixes for cloth vertex painting on the What's New page for 2019.3.0f3. The key bugs (disappearing/stuttering/weights not carrying between versions) are now listed as known. The issue tracker once again states that it is fixed in 2020 alpha, I would likely expect it to be fixed before the month ends for 2019.3, though there's been so many delays already I'm hesitant to get anyone's hopes up.

 

Tried in 2020, same situation/behavior as before

 

Are you sure that you tried Unity 2020.1.0 Alpha 19 and not an earlier build? They just listed a ton of Cloth fixes a few days ago here which appear to address exactly what was mentioned on this thread. If it's still buggy there then I would hold out until the official 2019.3 release (which seems to be the key release they are aiming for getting it fixed), although it's already late in January and I was thinking they'd have put it out by now.

When 2019.3 is available I'll test it out myself and if there are still issues I'll try to document them and get in contact with Unity however I can. By that point it may actually start to impact my release so if they are unable to do anything for 2019.3 I will look into custom cloth solutions and make my findings public/free if that's what it takes.

 

Magica Cloth has been just released in the asset store. Seems a better alternative than Obi Cloth: compatibility with all platforms + FULL SOURCE CODE..
Also, it uses DOTS + the burst compiler and will automatically generate a proxy low res mesh to simulate high poly clothes.

However, I don't want to use third party plugins that will eventually break on newer unity versions for things that should work by default, so I will be testing builtin unity clothing intensively and making bug reports until they fix it.

 

It's seems that in 2020.1a019 cloth component is fixed.

 

I did this to another thread, but does anyone know if there has been a deliberate change to use local space for external acceleration? If I add say Z acceleration to the cloth, then rotate the cloth object, the wind appears to follow the turning of the object. I am having to add a fix to deal with this change which is not great if its suddenly going to switch back in the next version!

As for many areas of Unity documentation, it doesn't specify whether world or local space is used.

 

Make a minimalisric project showing this behaviour and send a bug report ASAP if you want it to be fixed now that we have their atention on the cloth component!

 

I will create a bug report too. This is made in Unity 2020.1.0a19 but is the same in 2019. Just run the sample scene, then rotate the cloth in Scene view. The wind created by by External Acceleration rotates with the cloth. So External Acceleration is now in local space.

 

Good news; cloth seems to be mostly fixed in 2019.03 release (besides the new discovered bug)

 

I suppose you mean Unity 2019.3.0f6 ? (the latest official release)

 

I just tried my repro project for the cloth bugs: it's still as broken as before

 

in 2019.3.0f6 cloth is still broken, but is working fine in 2020.1.a20

 

I just downloaded 2020.1.a20 and tried the repro project (removing the cloth component and reapplying it from scratch)
Still the exact same issues.
2020.1.0a20 is exactly as broken as 2019.3.0f6
I have filled a bug report.
AGAIN...

 

Ok, go vote for this bug resolution here if you want it to be fixed SOME DAY in a distant future:
https://issuetracker.unity3d.com/is...pear-only-one-is-left-when-entering-play-mode

In the meantime, because Unity's clothing is A MESS, I bought MAGICA CLOTH in the asset store:
Works like a charm, does everything Unity's cloth SHOULD do and more, is compatible with all platforms except WebGL (unlike ObiCloth which is not compatible with consoles and will never be), runs fully inside Unity using the Jobs system, it's actively being developed and includes the FULL SOURCE CODE (again, unlike ObiCloth, which uses per platform DLLs with undisclosed code)
Go buy this guy's plugin, support his AWESOME work and fix once and for all your Unity's clothing misery!

What an embarrassment for Unity when a single indie developer in his bedroom makes from scratch something they weren't able to fix themselves for MORE THAN TWO YEARS NOW and makes it BETTER.

I guess they don't even care at this point.
They'll be grabbing money for every sale of Magica Cloth anyway.

 

Does it works with skinned meshes (distance) ? or it should be used with colliders ?

 

It works with skinned meshes but you have to manually place colliders inside the body yourself. It uses it's own colliders though, and the capsule collider is actually 2 spheres atached with 2 independent radius, which helps a lot.
I have made a feature request to implement surface penetration like in Unity's cloth component and avoid the use of colliders. The author thinks it's a cool idea and will try to make it work, but no ETA on this whatsoever.

 

I mean: you specify which vertices can move and which vertices are attached to the skinned mesh with a vertex editor, but then you have to place colliders inside the body for the cloth to avoid poking through it.

 

I try every new version, final, beta and alpha many months ago (last versions that i used 2019.2.19f1 and 2020.1.0a21) and the problem continues, Cloth system is broken, is the major problem in Unity that i remember in years, if someone in Unity try resolve this can use this free asset to see the problem, a simple flag simulation is impossible. https://assetstore.unity.com/packag...ls/the-best-flag-and-war-banner-system-124022

 

go vote for this bug resolution here if you want it to be fixed!
https://issuetracker.unity3d.com/is...pear-only-one-is-left-when-entering-play-mode

 

I have downloaded the latest official patch Unity 2019.3.0f6 and tried out the cloth fixes. All of my reproduction examples appear to be fixed. Which means I can finally have cloth on my character without random forces/lag/glitching:



This is with Optimize Mesh all settings on, the file is from Blender 2.7, and using Asset Pipeline Version 2. Not sure if there will be any difference using Version 1, or if you use a file from Blender 2.8. I know that Blender 2.8 auto-imports to Unity (through FBX) have changed since 2.7--objects parented to bones now come in actually parented to the appropriate bones instead of getting "fake" weights in a skinned mesh which are children of the root file. This means those objects are now regular mesh renderers instead of skinned meshes. It's more clear for sure since that's the intended approach in blender, but it seems like the entirety of rigged files should be skinned to me; that's just my thoughts. There may be a setting to change it now, but I won't be using 2.8 any time soon anyways.

There is still one known bug listed in the What's New for 2019.3 related to cloth:



When I checked earlier this week it was "planned", but now it says "Fix in Review" for 2019.3. Which means they've already nailed down the issue pretty quickly; we should see it come to the next patch. Although I never experienced anything weird with the simulation on rotated objects in all of my tests in the first place, so maybe it's specific to that reproduction example.

Finally, I have noticed that Cloth objects--specifically my sphere tests, do "explode" when the game first launches. However, after a second they return to normal. I expect this is just a result of initial runtime lag which causes the solver to freak out. I don't anticipate this being an issue as it can be easily hidden with a loading screen or by some combination of preloading the mesh, etc. I don't think many players will mind this small artifact either. However, if it really is an issue it can be mitigated. I've noticed that the effect is barely noticeable on my character, which has bending & stretching stiffness all the way up, and damping up pretty high. What also helps is constraining the cloth vertices, it limits their movements and causes a chain reaction to verts down the line which also help keep them in check. Those options are what made it possible to hide the glitch at the start of runtime, however I imagine some cloth cases can't afford to use that. Maybe you could make a runtime script which enables everything at the start and then turns it off once Cloth is stable... just throwing ideas out there.

Regardless, I'm pretty happy with the update. It seems like they've addressed a lot of issues, but there's still more work to be done. It would be nice if they could fix this exploding glitch, but it shouldn't be the end of the world considering how much is working for me now. I will wait a couple more weeks until I actually update my project--as always with Unity there are bound to be bugs on the initial feature releases and it's better to wait for the 2019.3.x versions which are almost always more stable. And it's a little scary updating my past 6 months of work since it seems like so much has changed which could affect development (really though, looking at the upgrade doc it's not a lot to deal with. It just seems like a big change). But it's nice to know that Cloth is on track and usable again.

Probably because they're busy with the millions of other projects and changes planned for addition to Unity and their built-in Cloth solution has so many moving parts which likely impact other areas of development. I don't know if you saw the bug fix list for 2019.3, but they've actually fixed several hundred bugs, a few of which stemmed from this exact thread. In truth we have no idea just how complicated it is to actually fix these problems, so I don't think it's very fair to compare a developer's work on a single asset to the work done potentially every day for many hours fixing countless other bugs which could actually be way more critical than what was discussed here. Not that Magica is not an impressive cloth solution--it is. But those Unity devs likely have much more on their plate than can be realized from their responses in the forums, and even focusing on just Cloth fixes is still no easy task. Without knowing the inner workings of their dev team and their workflow process, or the source code of the cloth component, it's impossible to know just how deep these bugs run and how much actually has to change in order to get them fixed.

 

Thanks for the tips but my clothes always behave badly since late Unity 2017 up until 2020.
Maybe your cloth requirements aren't as precise as mine and you can deal with it, but for me it's clearly not working as it was before.
I mean, I'm not imagining things: I got my characters clothes to behave great on 2017 and then on some update it got screwed.
I don't think I'm asking for a lot: I just want it to work as before they screwed it up.
Also, I made this same bug report several times in the past and was always told that it was a replicated bug from another one and that they will all be fixed at once, but every time they said it was fixed, it was not.
They could just run the dead simple repro project I sent them to check it out, but they didn't. They simply expect their customers to be their beta testers and it's not ok.
It's been more than a year now. I think it's reasonable to be upset at this point.

I'm sure I could sympathize with a lot of fellow developers who work for Unity, but that is not the point; Unity Technologies is not a charity and I pay every month for an engine.
I just want the current features to work as expected, instead of introducing new shiny features all the time that are never production ready.

 

How? in downloads the last patch is Patch 2017.3.1p4 Released: 13 March 2018.

 

If that is true then the active bug report should be marked as regression. Regression bugs are typically put on priority for the exact reason you specify below. Though I imagine it's pretty far back if you're talking about 2017. If you're talking about the high external force which is applied at the start of playmode I haven't experienced it in 2018 versions, at least not that I can remember. I only remember it happening sometime in 2019.

That's a reasonable stance; however Unity has to deal with more than just your own personal desires. Sadly a lot of people have been pushing Unity for years now to compete more with the engine market and increase the feature set. And it doesn't help that Unity can sometimes have a bad rep in player communities due to the ease of use and market flood, which means they want to cater towards larger studios and more advanced games. But even if that wasn't the case, I'm sure they would still be researching new tech and adding it in to create this ever-evolving product. I would agree with you--I want every release to be as stable as possible. But I know it's never going to be an easy task and what might be a project killer for some could be a minor inconvenience at worst for others. Again, that's just the nature of dealing with a huge program that caters to thousands of devs with so many moving parts. If you are truly unhappy with the engine and support it receives then you might want to consider dropping it and switching to the free version, or just going to another engine entirely.

It's understandable that you'd be upset without it getting fixed, but there are more productive means of solving your issue which don't involve screaming into this thread. I don't think any devs really read it anyways, so all you'd be doing is making people reluctant to join the discussion and wasting energy. So let's start by identifying the issue: is the bug you're talking about from 2017 only the high external force at the start of playmode? Your reproduction example states that cloth constraints go missing, but I haven't experienced that in 2019.3 during my tests. I can't download your repro from the bug site, maybe it has to do with your specific model. If you want me to take a look you can send the example and I can see if it's reproducible on my machine. Aside from that bug and the one I mentioned above, all the others are listed as fixed, and in my early test cases they are indeed fixed. Though of course I be wrong if further testing needs to be done to find them happen again.

It's on the Unity Hub installer which is the new way to acquire Unity builds and manage projects. It started around 2019.

EDIT: I should also mention that it was probably important for them to solve the other cloth bugs first since they appear to affect the behavior much more than your listed bug, and more consistently across more cases. Now that they seem to be fixed they are free to focus on other inquiries. However, as mentioned previously, there are likely hundreds of other bugs in other departments that they must deal with; I wouldn't expect them to get to it immediately. There's only so much that they can do. So in the meantime I will try to find a workaround for it, so long as I can reproduce the issue.

 

It should. I didn't get to choose.

Of course, and I have every right to complain when something doesn't work for more than a year.

That's like buying a car, the car stops working randomly for random reasons at random intervals, you go to the dealership to complain and then a random guy shows up to explain to you that cars are complicated mechanical things and that it's complicated to make them work and that you shouldn't complain for your car not working, because, you know, it's complicated.

Download the repro project and press play.

Why are you making excuses for a multi-million company?
They're not a puppy. They don't need you to protect them.

 

Buying software is not like buying a car. If your car breaks down that is a safety issue. If a bug becomes present in a piece of software it is merely a hindrance to your project and can be solved/worked around with additional patches. It sucks, because yes it can impact your workflow and potentially your money flow. And yes, you would hope that what they say works does indeed work. But again, it is complicated. Other people have issues too. How would you feel if you had hundreds of bugs lined up for fixing and someone was screaming at you for not getting to theirs first? And now how would you feel if all the hundreds of people who reported those bugs started screaming at you too? It would be chaos, and frankly unproductive. Which is probably why they don't bother to read all posts on the forums, in which case, you are wasting your time and just causing a ruckus yelling at nobody.

If you go to the dealership to complain, what exactly do you hope to accomplish? Your car won't get fixed until you actually go to a mechanic or fix it yourself. Or you get a refund/replacement. The same applies to Unity engine, but they can only offer you an exact copy of what's available publicly. The forums are meant to be a place to discuss issues and get help, not to scream at devs for missing bugs that impact your project. Getting help with the engine doesn't mean you need to put down the people that work on it. I know that's easy to say when I haven't experienced the same level of frustration, so I apologize if you are going through a tough time. But I believe the sentiment should still stand.

If you believe that Unity owes you money for the time this bug was active then you should talk to them about it. However, be warned that their software license may not make any guarantees on this sort of thing, in which case you knowingly agreed to those terms and would actually have no right to claim your money back. I'm just spitballing here, I don't know the legal specifics. But I would imagine that is typically the case for software which is distributed on the scale of Unity.

I'm not making excuses. I want them to release stable builds and I agree that it sucks that bugs can be left for years. But I'm trying to be realistic and make an approximate guess as to why it was missed. I essentially said that they have more on their plate to worry about than just the bug you listed. If you don't believe that's true then I don't know what more to tell you. I see no other reason why they would ignore bugs aside from not being able to replicate them. It doesn't benefit them in any way to let bug listings slide. So the most reasonable guess is simply that they have other priorities. Getting angry at me doesn't change that. And getting angry at them won't either. Again, I'm just trying to explain why the wait might be long--with the amount of bugs on their plate they likely cannot solve everything as soon as it pops up. That's just not how software development works at this scale.

They have a lot of resources, yes, but it's not infinite. I can't imagine them having thousands of bug fixers working on this stuff every day. If you really want to prove that they are not doing enough then you'd need to find a complete employee list as well as their yearly financial information and show that there is more money which can be spent on bug fixing. Even then, their exact spending preferences will be down to opinion, and you must realize your own ideas of software management may not line up with their own.

Exploding sphere

I've run your reproduction and found that I couldn't reproduce exactly what you explained in your bug report. Here is the result I get when I run:



So yes, it looks to be "exploding" and distorting to not a sphere anymore. However, you claimed that Cloth constraints go missing once playmode is over, yet that is not the case for me:



I've ran it many times and at no point did the cloth constraints disappear, reset, or go corrupt. However, if I enter Cloth constraint mode while the game is running I get this:



And once playmode stops I get this:



However, this is just a visual bug, one that's been discussed elsewhere a few months ago. The data is still there. The solution is to just click away from the sphere and click back. Then when I enter constraint mode:



If this is what you were talking about with concerns to constraints "disappearing" then it appears as though you're talking about an already known "bug" which is a minor inconvenience at worst. At best, it is merely a result of constraints not updating until you re-enter the mode. Nothing really to worry about.

But I won't assume anything until I hear back. So double check if this is what you were experiencing or if there is indeed a data corruption happening. In the meantime, I will talk about the exploding thing.

For one, all your constraints are .2 distance, which is a somewhat odd stress test considering normal cloth cases have constraints at 0. It means that cloth vertices can move up to .2 units away from their skinned position. But okay, I did some testing and found that the weird constant movements you experience are caused by the surface penetration option. Here are the results when surface penetration is unchecked for all verts:



The cloth just kinda hangs out at the max distance of .2 in the sphere shape, staying still. And sure enough, if I clamp the top verts I get the expected result which matches my repro tests that I explained yesterday:



So there's one quick solution: if you don't need surface penetration just don't use it. Personally, I've never used it. It is defined as being used for how deep it go into the mesh. I'm not sure if you need that feature, but if you do then you probably need to set it higher for it to not cause artifacts. Here's what I get when I set surface penetration to 10:



I don't know exactly how it works but my guess is that the more you allow for penetration the more freely it can move without worrying about intersecting the original mesh. For your sphere a penetration value of around 2 or 3 is when it starts to stop glitching out. Aside from that, it appears that no combination of enabling them before/after playmode starts affects the simulation. So it appears that not much more can be done from scripting, and more importantly the issue is not related to the start of playmode but rather runs at any time depending on surface penetration values. You may need to fiddle around with the surface values if you want to use it, but it's possible that this is actually the intended result--the simulation does not want to penetrate the surface and there's not enough freedom to move so it glitches out. Aside from surface penetration, I was also able to get the simulation to "calm down" by using bending stiffness and damping. However it wasn't necessary to stop the glitching you explained.

Let me know if you can replicate those results, and if that clarifies what could be going wrong.

 

And that's why clothing is working for you: you don't use it at full extent.
Doesn't change the fact it actually doesn't work. Just that you don't use the features that are bugged.

Also, I didn't write the bug report you are reading. I wrote the original bug report and then the Unity staff wrote the bug report you are reading, with it's own phrasing and title. You should correct him if you feel like it.

This bug has been checked and reproduced by the Unity team, so they DO can reproduce it. Just like you.

Now, please stop making excuses for poor development and broken features.
You're borderline trolling now. (proven bug for months, approved by QA team, still questioning the existence or relevance of said bug.)

 

I'm trying to help you. If you won't verify or confirm what's working on your end then I won't be able to do anything and you can guarantee the issue will remain present in your project. Bugs are not some black box which cannot be touched by users until you wait for fix--things can get done to work around them or at least provide more info on it. You're calling me a troll because I'm trying to guess at how Unity goes about bug fixing? I'm sure if you asked Unity devs they would tell you the same thing.

It is possible that things are missed by the QA team. I'm not saying there's no bug present, but you should at least reconsider how it is phrased on the site. Did your original report include the Cloth constraints going "missing"? If so, then you should test if what I explained is true--that it is merely a visual bug. That information alone should be worth your time checking out and even if it never gets checked on the bug report you will at least know that it is working.

I didn't say it wasn't bugged. I said it may be the intended behavior. But I very well may be wrong because I haven't used it. Do you need it for your project? Is there really no alternative? I wasn't saying that you should just drop the feature--I'm saying if you weren't aware that it was on and didn't need it then you could get the intended behavior you wanted without it.

Regardless, the fact is the issue may now be narrowed down--did you write about surface penetration that in your original bug report? If not, this information is helpful to the Unity devs who will work on it because they can focus solely on surface penetration. None of that was written on the site so I have no way of knowing if you or the QA team were already aware of it. Again, I would hope that the discovery would be helpful in some way, at least more than just waiting on them to review it, and could actually help them find any issues faster if they were to read what I wrote. If that is not the intended behavior of surface penetration then it would indeed be relevant and would require fixing--I wasn't doubting that. But it does change the context of the issue--it's not just a problem with "Cloth", it's a problem with a specific use case under a specific set of parameters. Not only is that useful for Unity devs, but also for other Unity users who should now know to steer clear until it is fixed.

I have tried to have a reasonable discussion. I have tried to help you. And I wasn't done with my investigation--I wasn't trying to say that there is no bug. I wanted you to follow up and clarify if I missed something. But if you dismiss what I have tried to explain then nothing will get done until they look at it, and nobody will be happy. If you continue complaining about not getting the bug fixed when there is someone trying to narrow down issues for you then I truly have no words for that sort of attitude.

 

Thanks.
Excuse my exasperation but I'm so tired of bugs on Unity that I can be quite a prick some times.

Thanks, I have tested this on my side and have added a comment specifying your findings in the bug report page.
Be sure to vote for it's resolution here:
https://issuetracker.unity3d.com/is...pear-only-one-is-left-when-entering-play-mode

 

It's fine, I know it can be frustrating. I already voted on your bug earlier so hopefully when they get to it they will check out your comment and find the issue quicker. It's hard to find any sort of information on surface penetration online, even the API only shows collisionSphereDistance which I'm not sure is the same thing. I'm not sure what exactly the setting is supposed do, apart from maybe stop intersection with itself--but it wouldn't be the same as Cloth inter-collision, so it may have something to do with the original position of the mesh, that's just a guess though. Without knowing what results you're trying to get by using it, it's hard to say if there's some other workaround that can achieve the same thing. Well, I suppose you were talking about Magica cloth, but for the sake of bug workarounds I guess it can be ignored.

 

"surface penetration" is a way to specify a vertex to only go "inwards" it's original position by at specified amount.
It's thus extremely useful for character clothing that is already modeled to follow closely the characters body: you set a "surface penetration" of zero to every vertex and the cloth will not poke through the character's body, since the vertices can't go inwards their original position.
That way, you don't have to use colliders to setup a characters cloth.
Using colliders makes the cloth follow the colliders shape instead of the original body's shape and that can ruin the cloth's draping.
This feature was working perfectly until the cloth component completely broke.

 

I see, in that case it does sound useful in clothing simulations. I know it's not the same but max distance can kind of accomplish that--the only downside is it works in all directions instead of just inwards. I don't think there's any other way to clamp cloth vertex movement, the closest workaround I can think of off the top of my head is to just use colliders. If your mesh is too complicated to manually place them there might be a way to auto-generate approximate spheres/capsules based on mesh density and set those as collision items. I know that sounds like a hacky fix but if you really are desperate to get surface penetration working that may be your best bet until they get around to fixing it.

This may not work for you but if it were up to me I would probably use approximate collision even if penetration worked anyways just because it becomes easy to map multiple cloth pieces across the same bounds. Like if my character had multiple skirt pieces I would put colliders on the legs so that all of them reflect the same physics changes. It may also be more consistent because you are no longer relying on constraint data per Cloth component, but on gameobject data which can be easily serialized from a scene/prefab. I know that can distort the shape of the original draping, however with a more complex Editor solution you could theoretically overlap colliders and get any sort of bounds shape that you wanted. Problem is, that might not scale well for performance if you need dozens of them to make the shape you want. I'd imagine most character cases should be manageable though. Let me know if that sounds interesting to you and I'll see if a prototype of that solution might be viable. Besides that, there's not much more to be done until they get around to fixing it, aside from getting more people to vote on the report.

 

I'm relived that they have decided to try to fix this in 2019 but I am a bit worried about moving to 2019.3 though as there is a lot of new stuff in there (seems weird that they put it all in so late in a tech cycle). Like moving PhysX library from v3.4 to v4.1, !!

Did you realise they are saying that the last 2018 is what we should be using for production? I thought I would be fairly safe on a late 2019, but until the LTS releases it seems we should have much lower expectations. So I am going to try to wait until 2019.4 and hope the cloth is OK and nothing else breaks for me on 2019.3/4