09-07-2019, 11:18 AM
(09-07-2019, 10:57 AM)josemendez Wrote: 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.