ObiCloth compatibility with 2019.1 and above

[josemendez]

Hi all,

Some of you have been having issues running the CharacterCloth sample scene from ObiCloth in Unity 2019.1 or above. Specifically, Unity spews out the error "Bone weights do not match bones" when running the scene. All other Obi assets are unaffected by this.

Since reports were inconsistent at first (some users got it to run, some others didn't), it took some time for us to get to the bottom of the issue. However the rabbit hole went much deeper than we expected.

Technical explanation ahead, scroll to the end of the message to see what we're doing to fix it.
The culprit is a seemingly innocent (and undocumented, afaik) change in 2019.1 : SkinnedMeshRenderers no longer accept an empty bone weight array.

In 2018.x we were setting the weights array to null in order to deactivate the built-in skinning, then handing over the mesh to our own library to perform custom skinning/simulation blending. Thing is, this is no longer possible and results in Unity throwing an error. We've asked if this was an intentional change and it is, so they're not changing it back to the way it was. Passing a full array with all weights set to zero does not work either, as they now enforce all weights summing up to 1. Long story short, we have to rewrite most of our system from scratch to separate bone skinning (which would be done by Unity) and simulation, then blend them together somehow.

On top of that, we switched the asset store version information to reflect that ObiCloth is not compatible with 2019.x (they let you specify compatibility per-version). However due to a bug (feature?) in the asset store, it only shows "2018.1 or higher". So we've added a warning in the asset description stating that for the time being ObiCloth is only fully compatible with 2018.1 - 2019.0, but it hasn't been approved yet so people are still downloading it for >=2019.1.
End of technical explanation

All in all, this has been a pretty disastrous event for us and we're working as fast as we can™ to fix it. We honestly expect Obi to come out the other side better, faster and easier to use than ever. While we work to make this happen, please accept our deepest apologies. We will write a blog post shortly to give you a heads-up on the development process.

To try to amend the damage caused, we're accepting refund requests from anyone that purchased ObiCloth after April 16th, the day Unity 2019.1 was released.If this is your case, please let us know by writing  to support(at)virtualmethodstudio.com and stating your Invoice Number (found in the .pdf invoice sent by the store upon purchasing).

kind regards,

[alkis]

Oh dear. I know that Unity (the company) can be a black box at times but have you tried reaching higher for a solution to this? I do not supposed they would remove the boneWeights safety checks but it could result in another way to disable built-in skinning being added.

[josemendez]

Oh dear. I know that Unity (the company) can be a black box at times but have you tried reaching higher for a solution to this? I do not supposed they would remove the boneWeights safety checks but it could result in another way to disable built-in skinning being added.

Thing is, they already have a mechanism in place that allows you to use the results of the built-in skinning without the need to disable it and roll your own: the BakeMesh function. In previous versions it was extremely slow though, so we opted to implement our own skinning which not only was much faster, but also had simulation blending built-in. For the guys at Unity, I suppose there's no real justifiable reason to allow disabling skinning in a SkinnedMeshRenderer. In retrospect it feels like we exploited a bug/hole in their API.

In 2019.1 we're using BakeMesh, which now has pretty decent performance when using the List<T> version of Mesh's API. This has required some pretty profound changes in Obi, so we're redesigning pretty much everything workflow-wise, hoping that things will not only work properly again, but do so better than they did.

I've written a blog post to try to explain what we are currently working on:
http://blog.virtualmethodstudio.com/2019...5-preview/

[alkis]

Thing is, they already have a mechanism in place that allows you to use the results of the built-in skinning without the need to disable it and roll your own: the BakeMesh function. In previous versions it was extremely slow though, so we opted to implement our own skinning which not only was much faster, but also had simulation blending built-in. For the guys at Unity, I suppose there's no real justifiable reason to allow disabling skinning in a SkinnedMeshRenderer. In retrospect it feels like we exploited a bug/hole in their API.

In 2019.1 we're using BakeMesh, which now has pretty decent performance when using the List<T> version of Mesh's API. This has required some pretty profound changes in Obi, so we're redesigning pretty much everything workflow-wise, hoping that things will not only work properly again, but do so better than they did.

I've written a blog post to try to explain what we are currently working on:
http://blog.virtualmethodstudio.com/2019...5-preview/

Thanks for the update! OT, but I'm quite interested in the Blueprints feature. We currently spawn all of our cloth assets at runtime, having a bespoke integration with an even more bespoke version of UMA. This means that we have a workflow where artists create the assets in a setup scene, export them to a custom data class that contains the topology and all constraint data precooked, and then initialise everything using that data. This allows fast switching of cloth assets in what I can describe as a "wardrobe/inventory" setting. I wonder if this would help with this use-case, should probably start a new thread.

[josemendez]

Thanks for the update! OT, but I'm quite interested in the Blueprints feature. We currently spawn all of our cloth assets at runtime, having a bespoke integration with an even more bespoke version of UMA. This means that we have a workflow where artists create the assets in a setup scene, export them to a custom data class that contains the topology and all constraint data precooked, and then initialise everything using that data. This allows fast switching of cloth assets in what I can describe as a "wardrobe/inventory" setting. I wonder if this would help with this use-case, should probably start a new thread.

Hi,

Blueprints work pretty much just like the system you currently use. The "setup scene" would be the Blueprint Editor, the "custom data class that contains the topology and constraint data pre-cooked" is the blueprint itself (which is a ScriptableObject), and runtime initialization basically involves copying blueprint data to the solver arrays, which is very fast.

If you wish, start a new thread on this and we can take a look at your use case & current solution, we're still designing/implementing blueprints so info on how you guys would use it is very useful.

[StudioTatsu]

Looking great. Can't wait to see the new features. 
I've been writing my own alternative to softbody physics and it has been overwhelming.
I personally would prefer to use Obi Softbody instead, so I can focus actually making my game. 

[Evgenius]

Thing is, they already have a mechanism in place that allows you to use the results of the built-in skinning without the need to disable it and roll your own: the BakeMesh function. In previous versions it was extremely slow though, so we opted to implement our own skinning which not only was much faster, but also had simulation blending built-in. For the guys at Unity, I suppose there's no real justifiable reason to allow disabling skinning in a SkinnedMeshRenderer. In retrospect it feels like we exploited a bug/hole in their API.

In 2019.1 we're using BakeMesh, which now has pretty decent performance when using the List<T> version of Mesh's API. This has required some pretty profound changes in Obi, so we're redesigning pretty much everything workflow-wise, hoping that things will not only work properly again, but do so better than they did.

I've written a blog post to try to explain what we are currently working on:
http://blog.virtualmethodstudio.com/2019...5-preview/

Sounds amazing! Can't wait to try it

Few questions:
- Is there any estimate for Obi 5.0?
- How hard will it be to upgrade from the current version 4.1?

[josemendez]

Sounds amazing! Can't wait to try it

Few questions:
- Is there any estimate for Obi 5.0?
- How hard will it be to upgrade from the current version 4.1?

We are aiming to release in the first half of October. Keep in mind that this is a major rewrite, not just some patches on top of the old thing .

Upgrading from 4.1 will require re-doing setups. For 5.0 we're putting a lot of emphasis on simplifying workflows and scraping the last bits of performance. And when I say simplifying workflows, I really mean it. So hopefully it will be quite easy and fast to re-do anything you had working in 4.1.

[kevjosef]

Wow what a bummer!  I hope this works out well in the long run for you guys, I found out about this recently while using cloth with a skinned mesh in 2019.1

Are you guys still on pace for an October release?  I've been developing my demo in Unity 2019 but just testing the cloth functionality with characters in 2018.3, I'm looking at giving my pitch to the publisher around November and I'm just wondering if I'm going to be able to implement cloth on my characters for that event?

Best of luck to you guys!

[nehvaleem]

I am also curious about 2019.X compatibility. I need obi cloth by my project is based on 2019 Unity so I am waiting before buy.