Trouble with rigidbody falling through mesh colliders on tileMaps

[dbanfield]

Hi,
sorry for the bombardment of tilemap questions recently 

My new problem is the player passing through the mesh collider for the tilemap. I have a rigid body character controller. The player can take control of different sized characters. Even the ones that aren't *that* small though, all I have to do is jump repeatedly for a while and sooner or later he'll fly through the floor.

The thing is, I don't see any of these problems if I use my old BoxCollider driven platforms. I've been experimenting a bit with the collision detection method, and even tried the infamous DontGoThroughThings script to no avail.

-------------------------------------
EDIT: I've realised that if I marked the chunk collider as convex the problems go away, as in the case of the box collider. It also then occurred to me that this makes sense - if it is a convex collider, the physics engine is going to push the rigid body out. I can verify by this by starting off the level with my player inside the collider, and he will be correctly pushed up to be on top of the collider.

This is not so with a concave mesh collider, since unity is only going to test the collision if it is an accurate collision from the outside. If we get the collision in between frames we have the well established and documented problem of the collision not being detected.

All this is very well and good, but the problem remains
------------------------------

At the moment I'm considering diving into the tilemap code and somehow rewriting the collision part to somehow compose the collision out of box colliders, since my environment composition is all rectangular. Not exactly fond of the idea though.

TIA for any advice
Dan

[dbanfield]

After some research, essentially the issue is kind of similar to this
http://answers.unity3d.com/questions/331628/concave-collision-issue-with-2d-game.html

i.e. My requirement would be for the Collider's of the tilemap to be a set of convex compound Colliders
(search for compound Colliders here http://docs.unity3d.com/Documentation/Components/class-BoxCollider.html).

This seems to be an established problem for accurate physics calculations when convex vs concave colliders are involved, and indeed some very sophisticated solutions such as this are available on the store
http://forum.unity3d.com/threads/154361-Concave-Collider-Generate-compound-colliders-with-one-click!-RELEASED


In a perfect world I would be able to tick a checkbox for the tilemap settings to indicate convex Colliders only. Instead of using one huge concave Collider, a set of convex compound colliders would be used to fill out the mesh.

[unikronsoftware]

It would be incredibly wasteful to create the tile map out of convex colliders, the overhead will be significant considering how complex a tile map collider can be. It would be much better to have the moving objects convex.

Or wait for Unity 4.3, the 2D physics in there doesn't have that limitation, and we have a new version of tk2d nearly ready for when they release 4.3 which will support the 2D physics engine.

[dbanfield]

I assume the overhead is simply the fact that you would need a lot more colliders to achieve it?

My issue is similar but not the same as concave mesh colliders not colliding. I gather the box2d not having that limitation is what you mean.

What I find great about the behaviour of convex environment is that I have zero concerns about my player passing through a wall. With convex geometry, if the collision is missed because it happened inbetween a frame, physics will pick it up the next time round and take care of it - no two objects can occupy the same space and the player is pushed out of the wall again. Making the moving object convex doesn't achieve this.

[dbanfield]

I created a scene with 1024 convex cylinders and still got 60fps on my nexus 7 (which is capped anyway AFAIK - it seemed to spike occasionally to 75fps or so). I can't imagine a level needing more than that.

Anyway, will be waiting for Unity 4.3 since I'll prolly find I'll have to rewrite everything again (for the 2nd time this year. Sigh).

[unikronsoftware]

1024 colliders isn't too many - you'd get that with a 32x32 tiles... You'd run out of 1024 colliders pretty quickly, even if the colliders were merged. It wouldn't go very far. However the tk2d collider generation for Unity 2D physics really well so far, it isn't as unstable as physx - any work done right now to optimise for physx like this wouldn't be a good idea, as 2D physics performs and works much much better.

[dbanfield]

Ok I see what you mean. I was thinking most of the environment would be taken care of by large blocks (eg a big ground platform that was say 6x32 could just be one collider). It depends how irregular the environment was e.g. lots of individual floating tiles would add up quick.

Point taken on the new 2d physics though. Will wait patiently for U4.3!
Thanks