13-10-2021, 10:31 AM
(This post was last modified: 13-10-2021, 10:37 AM by josemendez.)
Following up the previous post (as I was in a bit of a hurry):
The whole point of MeshColliders is that they pre-process the mesh in order to allow for fast collision queries: when you first assign a mesh to the MeshCollider, all of its triangles are inserted into a spatial acceleration structure (BVH, BIH, Kd-tree, or similar, don't know Unity's implementation details). This is a costly operation but only done once, and it avoids having to brute-force test every triangle in the mesh for each collision query, every frame. Instead, this structure allows to quickly prune most of the triangles and test just a few of them for each query.
If you modify the mesh every frame then this pre-processing needs to happen every frame, which defeats its purpose: collision detection then becomes as costly, or even more, than the brute-force approach of testing all triangles all the time.
Furthermore, deforming the mesh also results in poor quality collision detection. This is because physics engines rely on CCD (continuous collision detection) for accurate collisions against moving objects, and CCD is often based on object velocities. Moving objects have a velocity, that tells the engine where they're about to move. This allows the physics engine to predict movement.
But when you change mesh vertex positions around, you're essentially "teleporting" them: vertices have no velocity of their own. The engine has no way to know where vertices are going to move next, so it can't accurately collide against triangles: only if a triangle overlaps an object (in Obi's case, a fluid particle) a collision will be registered. Triangles are infinitely thin, and fluid particles are very small, so the chance they just pass trough each other is really high: virtually no collisions will take place.
That's why attempting to deform a MeshCollider is a bad idea, both from performance and robustness standpoints.
The whole point of MeshColliders is that they pre-process the mesh in order to allow for fast collision queries: when you first assign a mesh to the MeshCollider, all of its triangles are inserted into a spatial acceleration structure (BVH, BIH, Kd-tree, or similar, don't know Unity's implementation details). This is a costly operation but only done once, and it avoids having to brute-force test every triangle in the mesh for each collision query, every frame. Instead, this structure allows to quickly prune most of the triangles and test just a few of them for each query.
If you modify the mesh every frame then this pre-processing needs to happen every frame, which defeats its purpose: collision detection then becomes as costly, or even more, than the brute-force approach of testing all triangles all the time.
Furthermore, deforming the mesh also results in poor quality collision detection. This is because physics engines rely on CCD (continuous collision detection) for accurate collisions against moving objects, and CCD is often based on object velocities. Moving objects have a velocity, that tells the engine where they're about to move. This allows the physics engine to predict movement.
But when you change mesh vertex positions around, you're essentially "teleporting" them: vertices have no velocity of their own. The engine has no way to know where vertices are going to move next, so it can't accurately collide against triangles: only if a triangle overlaps an object (in Obi's case, a fluid particle) a collision will be registered. Triangles are infinitely thin, and fluid particles are very small, so the chance they just pass trough each other is really high: virtually no collisions will take place.
That's why attempting to deform a MeshCollider is a bad idea, both from performance and robustness standpoints.