Serious mesh collider bug discovered

Unity Engine
1

Mesh colliders are unusable for background collision meshes.

UPDATE: In case anyone stumbles across this – this was a bug in Unity 2.6.1 which seems to have been fixed by Unity 3.3

In my game, for my backgrounds I have separated visual meshes and a lower-poly collision mesh. The floor of the world is made up of mesh colliders. Smaller collider+rigidbody objects regularly fall through the floor (slow moving) when impacting the collision mesh on a triangle edge (seam between 2 faces). I have objects fall through as large as radius = 0.3, height = 0.6 (capsuleCollider), whether they are BoxColliders or CapsuleColliders. Objects are falling using normal physics gravity set at -9.81. Objects may only fall a distance of 1 meter before hitting the ground, so object speed is not very fast, yet they still fall through.

*** Colliders do not fall through when collision occurs entirely on a polygon face
*** Colliders FALL THROUGH when collision occurs touching a triangle edge between polygons

Edit: The following image illustrates box 1 landing on the flat face of the triangle correctly and box 2 in the midst of falling through because it collided on the triangle edge.

I don’t understand this at all. Why would a triangle edge cause a collision to fail?

My collision meshes are made of relatively large flat polygons. Any time a small object collision happens on the flat face of a polygon, it does not fall through. Anytime any part of the small collider touches a polygon edge, the collision fails and the object falls through the floor.

This does not happen with BoxColliders. I tested a box collider as a floor and NEVER saw an object fall through, I assume because there are no polygon edges on the flat top face. However, I simply cannot use box colliders for my backgrounds and must make the mesh colliders work somehow.

My original floors were are all planar meshes of varying size. The testing meshCollider is about 85m X 50m (planar). I tested a v-extruded version (about 4m thick) thinking that maybe having a thickness to the collider would help, but the results are exactly the same.

It doesn’t vary with distance from world origin, so I can’t blame 32-bit float imprecision. (It even falls through almost exactly near 0, 0, 0).

FYI, Physics.minPenetrationForPenalty = 0.01

All items are built on realistic scale. Therefore a small item such as a gun, even with a somewhat oversized box collider, easily falls through the floor if it hits a triangle edge on the collision mesh.

PS: This is a repost with information sorted out better. My old post’s title didn’t accurately describe the problem and I got zero responses.

2

note that one box is above the plane and the other is intersecting it.

3

That’s my attempt to illustrate the fact that one is falling through. It’s a mockup done in maya, not actually from Unity.

I edited the above post to clarify.

4

hmm… you can’t tell me nobody out there uses mesh colliders for backgrounds.

5

Don’t forget to send a bugreport…

6

I’ll do that when I get time to put an example scene together. That nobody’s found this problem before is totally beyond my comprehension. This is huge. Forget doing any kind of FPS game.

7

I’ve run into this issue when oversizing meshes. If the polys are stretched too much, they become more unreliable. I resolved it by resizing the model and reimporting with better meshes. Also try to import the mesh to the correct size and try not to resize it in the editor.

8

Personally I’ve never seen it, and I tried duplicating your results and was unable to.

There have been a number of FPS games done with Unity without a problem.

–Eric

9

Hi, thanks for the reply! Sorry for the delay in responding.

Okay, I’ve finally made a scene + Unity package that shows this problem is easily reproducible. There are two sets of boxes on each of the 3 floor types. All the scattered boxes have a velocity of 0, 0 ,3.0 applied on Awake because this seems to make seam failure happen easier. You will notice that every box that collides with the floor plane on the diagonal polygon border falls through the floor and every box that collides with the flat of the face does not.

The 2nd set of boxes in the lower right on each floor (the ones all in a row) have no velocity applied and just show the effects of gravity.

Download the Unity scene + package here (Sorry about the ugly download page. Go down to the middle and click “Download This File”.) There’s also a web player build of it in the zip file if you want to just see it happening.

Start:

End:

It’s pretty obvious from these tests that something is seriously wrong with MeshCollider compared to BoxCollider. Box collider doesn’t even fail on one single object, whereas both mesh collider box and plane fail on a large percentage of the falling objects.

  1. Collisions on polygon seams in MeshCollider fail much more easily than on flat faces
  2. ALL collisions on MeshCollider fail more easily than BoxCollider

EDIT: An additional test I just tried was to take the cubic mesh collider and make dozens more divisions so the cube had 672 tris. After adding all these divisions, all but 2 of the boxes fell through the cube. So, therefore, the more triangle edges on the surface, the more collisions will fail.

I believe the size of the falling rigid body colliders makes a difference. I see this happen all the time with colliders of smaller objects such as guns. However, I have seen this triangle edge collision failure happen with a much larger capsule collider as well radius = 0.3, height = 0.6, which is not small.

FYI:
Unity Version: 2.6.1 (would appreciate anyone who could test it in U3 since I haven’t installed it and don’t have another system to test it)
All meshes imported are .FBX exported from Maya

10

Thanks for your suggestion. I did a bunch of tests with polys of various sizes thinking that may be the problem, but it didn’t make a difference. I also tried various ways of modeling/importing the fbx files to eliminate any scaling, but that didn’t help either.

11

Unfortunately there’s no scene included, so it’s not really usable.

It’s generally not worth reporting bugs on a version that old; Unity’s been updated 5 times since then and has a different physics system (it’s still PhysX, but it’s a different build).

–Eric

12

If you want something fixed:

  1. supply a valid unity project with source code we can run our end and fix it
  2. use latest version of unity (in case it got fixed)
13

Hmm… I included the .unity and the .unitypackage file. These should be enough, shouldn’t they? I tested this myself just now by making a new project, copying both files in, importing the package, and opening the scene. Everything was working.

I may have posted my message first and then updated the link to the file. Below link does have the .unity file in the zip. I just downloaded and tested.

http://www.filedropper.com/meshcolliderproblem_1

I figured as much. I had hoped to finish out this project on the version of Pro I bought and not have to go through all the issues involved in migrating to 3. I will do some tests in 3 and post back.

I was hoping this was a known issue with an easy workaround.

Thanks for your help.

14

never seen this either but that has likely more to do with the fact that I follow basic physics rules which were completely ignored here.
To explain that:

  1. You used a plane. A plane has no backface, which means its not closed which means it has no volume and no volume means you are in trouble for anything that is able to be in front the wall on step X and behind the wall completely in step X+1. non-volume tri mesh colliders have no swept collision.
    Use something thats equal but with backface and a depth > 0.0 (or more accurately > penetration depth cause thats the min thickness your object must have to even trigger a “tunneled through check”) and it will stop tunneling.

  2. don’t use MeshColliders if you don’t need them as in case of your plane. They work on distinct triangles and K-Tree collisions which are very time intense and they have fundamental limitations compared to something as simple as the primitive colliders (box, capsule, sphere) which are simple math functions, not dozens to hundreds of plane equation resolutions etc

  3. Sorry for sounding angry, but coming up with a “test case” that proofs your point by using something that is by definition an incorrect and invalid setup does not show a bug at all, more a lack of following basic rules and principles.
    Unity uses PhysX 2.8.4 and the TriMesh Colliders existed for half a decade in physx, trust me if anyone ever considered such a bad setup a bug, Ageia or PhysX would have fixed it long long ago.
    I though would agree if you said its a bug in the unity documenation to not mention the limitations and requirements throughout enough, expecting people to know PhysX to know what to look for on the web.

As a comparision example to what you do here: You don’t drive a ferrari with 200km/h against a tree, go back to the ferrari seller and tell him the care is fundamentally flawed cause it deformed when you crashed it into the tree at 200km/h either, do you?

If you want to learn more about the limitations and how to setup, the unity docs contain a few points and the PhysX documentations and resources contain a host of points to keep in mind due to limitations on numerical precision, realtime simulation, time step length, penetration settings, resolution counts, …

15

Thanks for your comments!

Please see my message 5 posts above. I even mention it in my first post that the same thing happens with a solid shape. I have tried solid shapes with thickness of 5-6 meters and it still happens.

My example of a simple flat surface is just that – an example to illustrate the point. My in-game geometry does vary in shape and height and therefore needs to be made of mesh colliders, not primitive colliders. And I am not using terrains.

Again, I used both a plane and a solid box. Same results.

16

You are right. I only went by the initial posting on my answer.

I know that it needs to hold for more complex cases otherwise mesh colliders would be useless but thats the problem, in more complex cases it will normally (unless you have really reached the tunneling speed ie speed > thickness + 2x penetration) because the planes are not equavelent on adjacent triangles as it is with a “mesh cube” or “mesh plane” where you pile together quads at orthogonal angles everywhere.
Thats basically a pretty bad setup due to the numerical consequences that allow tunnels to happen because there are no 2 different equations checking at the gap or 2 orthonormal planes doing it.
its numerically not possible to make it fail save without wasting multiple times as much processing time on all triangles independent if its such a case or not.

That being said, I recommend that you wait for Unity 3.4 with all its changes and additions and report it if you see it still not working then as 3.3 is old and 3.4 is around the corner from what mentioned in different occasions. That way you can save yourself the time to retest it directly again as the staff is going to ask you if it still happens on 3.4.

17

You should include the scene in the .unitypackage. I don’t know that a separate .unity file would work consistently, especially not between different versions.

–Eric

18

Okay, I’ll do that next time. Sorry.

An update: Well, I installed Unity 3.3 and find my results completely different from 2.6.1.

I no longer get different results for objects on a polygon edge. I guess this was noticed and fixed.

With all the same settings, general physics behavior is very different. Now almost all the falling objects pass right through both “Mesh Cube” and “Mesh Plane”, yet all land perfectly on BoxCollider.

So I went digging for possible solutions:

  1. Increase thickness of all falling object’s colliders.
    U3 now requires a thickness of 0.16 to get a similar behavior to Unity 2.6.1’s thickness of 0.0947 (objects not falling through). MOST (not all) objects land properly in MeshCollider, ALL land properly on BoxCollider. Higher objects (read: slightly faster moving) still fall through MeshCollider – thickness of ground cube does not affect this

  2. Change Collision Detection Mode.
    If I change collision detection mode to Continuous on all the falling objects, ALL land properly on MeshCollider, ALL land properly on BoxCollider. BUT all the objects colliding with MeshCollider “pop” in and out of the floor surface, almost as if “bounced” back up after penetrating too deep, then continue with a slide across the surface in the direction of their velocity. This does not happen on BoxCollider.

  3. Change MeshColliders to “Convex”:
    Works for “Mesh Cube”, obviously fails on “Mesh Plane”. This is the closest I can get to mimicing the BoxCollider’s behavor with a MeshCollider. There’s no rigid body on the MeshCollider surfaces so I don’t see why Convex is necessary. Not sure if this will work for my surfaces in my game. I read some stuff about 255 polygon limits on Convex shapes in PhysX, so this may be a problem for me with my background meshes.

Summary:

  1. The triangle edge bug must have been solved already between releases. Sorry for posting a bug that was already dealt with.
  2. MeshColliders still do not behave the same as BoxColliders. Objects can much more easily penetrate mesh colliders (failed collision), even with thickness than they can BoxColliders. Changing Collision Detection Mode helps, but makes objects behave in unexpected ways (popping up and sliding after mid-penetration correction).

I guess there’s no solution in 2.6.1.

19

No for 2.6.1 there is indeed not much you can do. Not much cause Raycast are always there if you want to prevent teleporting against static nonmoving objects. Take last position and raycast to the current one and see if you hit. But this only works if the other side is static and not moving as raycasts would fail sweep tests naturally.

Problem is for Unity 3, PhysX was updated from the many years old PhysX 2.3.x ( think it was 2.3.x) to the last year current PhysX 2.8.4 which makes a major difference on continous collision detection and “tunneling” as well as a plentitude of numerical stability and performance stability related problems.

20

Sounds like it’s just a case of the objects being on one side of the collider during one physics frame, and on the other side the next. That’s why setting the collision detection mode to “continuous” fixes the problem, and also why a box collider works. (Although if the objects are moving fast enough, even the thickness of a box collider won’t help, since the objects could be “teleported” through the box collider–that’s what “continuous” fixes.) Without continuous collision checking, increasing the rate at which physics runs will help, since the objects won’t move as far between physics frames, with the obvious downside that the more often physics runs, the more CPU is used.

–Eric