Multithreading Mesh.Bake.PhysX.CollisionData

Hello, i've come into a bottleneck problem with mesh deformation. For my project i'm trying to deform meshes for terrain collision every frame. The range of vertices necessary to be synced by physics ranges from 300 to 10k. The lag comes from using the updated meshes inside a MeshCollider, which causes physics to rebake the collision data. The performance hit on my i7-5820k is about 1ms for every 1k vertices manipulated with an odd spike which doubles the lag amount. Making the meshes bigger or smaller has no noticable effect. The lag mostly correlates to the amount of vertices changed in total. Making the maximum amount of vertices i can manipulate each frame without really high performance costs of about 2-3k.

While the lag isn't much if i keep the maximum vertice count low, i'd prefer not to limit myself gameplay wise to such a degree. It would mean i would have problems using any fast projectiles in my game, as well as, greatly reduce the amount of objects i could have in a scene which should collide with the terrain.

After digging the forums a bit i found that "Mesh.Bake.PhysX.CollisionData" running on a main thread seems to be an issue running back many years when it comes to procedural mesh generation. Has there been any changes regarding this with the new versions of Unity? New method indroduced with 2019.3 "Physics.BakeMesh()" does not have any effect on the actual PhysX initialization and neither do the various MeshCollider baking options. The new Mesh API changes in this link doesn't talk about physics regarding meshes at all. I hope i didn't hit a complete dead end here.

Hopefully someone can shine some light on this. Thanks.

 

I see, thanks for the reply.

 

Any updates on this now since new mesh scripting API is updating frequently? No replies on this!

 

If anyones interested, they added support for mesh collision generation in unity jobs: https://docs.unity3d.com/ScriptReference/Physics.BakeMesh.html