We're using Unity to develop the first in a series of puzzle games. Often a puzzle involves a ball rolling around in/on a mesh. Not far into development, we are running into some very disappointing physics collider performance, which essentially renders things unworkable. I'd like to understand if we are doing something incorrect, or if this is expected performance of Unity and PhysX. So I've set up a super-simple app to demonstrate a basic problem of ball falling through collider. It is simple... - a 'platform' (scale = 50x1x50, primitive Cube with Mesh Collider, and Rigidbody configured as Kinematic, and 'Continous' Collision Detection) - a 'ball' (scale=2x2x2, primitive Sphere with Sphere Collider, and Rigidbody configured for 'Continuous Dynamic' Collision Detection). The platform's tilt is controlled via mouse (rotation is applied in FixedUpdate), and the ball simply rolls around on the platform. http://bit.ly/18axHmB Result: It is very easy to tilt the platform and cause the ball to fall right through. I have spent hours trying to get collisions working for our game, experimenting with various scales, Time and Physics settings (Fixed Timestep, Solver Iteration Count), mesh vs. box collider, Rigidbody settings (mass, etc), different thickness surfaces, etc. But to no avail. I can improve the performance a little in some cases, but never to a reasonable degree. Note that I am using Mesh Collider instead of Box Collider on the surface, as that's what our game must use, and the improvement in performance is not significant with a Box Collider (ball still falls through) Many in the community suggest cranking up Solver Interation Count to 100, or cranking down Fixed Timestep. But I've found only partial benefit from that. Actually, I've found that in some cases, more Solver Iterations gives worse results. In all the combinations I have attempted, the ball falls through with disappointing ease. And I do know about the "DontGoThroughThings" wiki script, and I appreciate the efforts of those who developed that. But come on, we're talking about a slow-moving ball rolling around on a relatively-slow tilting surface here. Not a fast-moving projectile or something. Why should we have to implement that kind of script when we have this supposedly-world-class fancy PhysX engine under the hood? Alas, I hope the answer is that I am overlooking something. Surely this cannot be the actual expected performance? I am attaching the simple demo app package in hopes that a UT person or super-smart community guru will be able to shed some light on my predicament. I really need help, and would greatly appreciate it.