Softbody doesn't collide with some triangles in mesh since 5.5

[MattS]

When I updated to 5.5 I started to get softbodies falling through my meshes at certain triangles (not a bullet through paper issue). I've attached an example mesh where softbodies will consistently fall through one triangle for no reason I can see (rigidbodies collide with it properly and the triangle is rendered one-sided correctly).

Repro:

https://matthewsouth.s3-eu-west-1.amazon...Mesh.asset

1. Add the attached mesh to the Ballpool sample.
2. Add a mesh collider and obi collider to the mesh game object.
3. Drop a softbody (eg the ball from the samples) onto the triangle highlighted below.
4. The ball should fall through.



Notes:

1. The softbody doesn't fall through other triangles in this mesh.
2. The softbody will always fall through the triangle 100%.
3. Rigidbodies correctly collide with this triangle.
4. This only started happening in 5.5 as far as I know.
5. Optimising the meshes did seem to help a bit, but not in cases like this.

I fully expect this will be some issue with my mesh but I'm just not sure what so any help or advice would be much appreciated!

[josemendez]

Hi Matts,

Will take a look at it asap and get back to you. Keep in mind that for most purposes, using distance fields is both faster and much more robust than using MeshColliders though, as MeshColliders are very prone to tunneling. Always avoid MeshColliders when possible.

[MattS]

Hi Matts,

Will take a look at it asap and get back to you. Keep in mind that for most purposes, using distance fields is both faster and much more robust than using MeshColliders though, as MeshColliders are very prone to tunneling. Always avoid MeshColliders when possible.

Thanks!

These are dynamically created meshes so creating distance fields, at least in the development stage, is a bit more involved than just attaching an obi collider and mesh collider component to the object. For release though I will definitely be using distance fields!

Did you get anywhere with your investigation? This definitely isn't a case of tunnelling as speed doesn't matter, it just doesn't seem to generate contacts against certain polygons in the mesh. Anecdotally it seems to be the first or last polygon in the mesh, so maybe something in the way I've generated the mesh is wrong? Also, these are deliberately not convex meshes even though the simplified one I provided technically could be.

[josemendez]

Thanks!

These are dynamically created meshes so creating distance fields, at least in the development stage, is a bit more involved than just attaching an obi collider and mesh collider component to the object. For release though I will definitely be using distance fields!

Did you get anywhere with your investigation? This definitely isn't a case of tunnelling as speed doesn't matter, it just doesn't seem to generate contacts against certain polygons in the mesh. Anecdotally it seems to be the first or last polygon in the mesh, so maybe something in the way I've generated the mesh is wrong? Also, these are deliberately not convex meshes even though the simplified one I provided technically could be.

Hi,

I'm currently looking at a possibly related bug in the bounding interval hierarchy used for collision detection against meshes, will get back to you today.

[josemendez]

There was indeed a bug in the BIH structure. Replace Obi/Scripts/Common/DataStructures/BVH/BIH.cs with the one attached, no triangles should be ignored now.

let me know how it goes,

[MattS]

There was indeed a bug in the BIH structure. Replace Obi/Scripts/Common/DataStructures/BVH/BIH.cs with the one attached, no triangles should be ignored now.

let me know how it goes,

That seems to work, thank you! I will test it some more on other cases but all the ones I've tried so far are fixed now

I had a slight issue with your change indexing out of bounds when all elements are >= to the pivot (--j will iterate below 0) so I added a quick bounds check:

Code:

...
while (bj.center[axis] >= pivot && j > 0);

I'm not sure if this implies a larger issue with the partition not splitting correctly, or just an edge case that needs patching up, but either way it works now. 

Thank you so much for the great support!

[josemendez]

You're right, that hints at deeper problems with the partition algorithm. I'll write new unit tests for the BIH and report back any additional modifications that result from that.

[MattS]

You're right, that hints at deeper problems with the partition algorithm. I'll write new unit tests for the BIH and report back any additional modifications that result from that.

Thanks again!

For what it's worth, my current case boiled down to the following situation:



https://matthewsouth.s3-eu-west-1.amazonaws.com/PartitionIssueMesh.asset

The axis chosen to split on is X in this case because it spans the largest dimensions, but all the centres of the triangles on X are identical. It might need to consider the spread of the centres instead, I'm not sure.

[josemendez]

[/url]The axis chosen to split on is X in this case because it spans the largest dimensions, but all the centres of the triangles on X are identical. It might need to consider the spread of the centres instead, I'm not sure.

There's several "pathological" cases for BIHs that result in poor partitions, this being one of them. Using aabb centers to calculate the split axis also leads to some (albeit different) worst cases, though, so there's no clear winner in all situations.

[MattS]

Very true! 

Worse case the current solution is slightly sub-optimal, but it works now which is the main thing so I consider this issue fixed.

Thank you for being generous with your time