koobas.hobune.stream
Simple Collider Test - Sphere Falls Through Mesh
For a ball & maze game, we have a ball rolling around on a mesh with pathways. But we are running into some very disappointing physics collider performance, which all but 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 simply...
a primitive Cube 'platform' with Mesh Collider at scale=[50,1,50], with Rigidbody configured as Kinematic, set to 'Continous' Collision Detection.
a primitive Sphere 'ball' @ scale=[2,2,2] with Sphere Collider, and Rigidbody configured for 'Continuous Dynamic' Collision Detection
The platform is tilted via mouse input (rotation is applied in FixedUpdate), and the ball simply rolls around on the platform.
RESULT: It is fairly easy to tilt the platform abruptly (although it's not all that fast) and cause the ball to fall through.
I have spent many hours experimenting with different scales, Time and Physics settings (Fixed Timestep, Solver Iteration Count), mesh vs. box collider, Rigidbody settings (mass, etc), different thickness surfaces, etc. But without much success. I can improve the performance a little in some cases, but never to a reasonable level. I am using Mesh Collider instead of Box Collider on the platform, to mimic what we must use in our game (the improvement 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 rather disappointing consistency.
Currently the tilting 'platform' is kinematic, and as per the Unity docs I am using standard transform.rotate function to manipulate. I received some feedback that I should be using Rigidbody.MoveRotation, which seems to contradict the documentation, but I tried it and it does improve the collision performance some. However the ball still falls through when the platform is tilted quick.
I am aware of the "DontGoThroughThings" script at the wiki, and I really appreciate the efforts of those who developed that. But the thing is, I've got a relatively slow-moving ball rolling around on a relatively-slow tilting surface. It's not a fast-moving projectile like is typically problematic. So, why should it be necessary to implement an extra helper script, when we have this supposedly-world-class fancy PhysX engine under the hood? And this is using the Continuous Collider functionality? (which I observe makes little or no difference... it actually causes the ball to bounce uncontrollably at smaller scale values)
HERE is a Unity package with the basic test scene. It is updated with two platforms, one using rigidbody.MoveRotate (left), and one using transform.rotate (right). MoveRotate definitely improves collision (left platform), but a fast tilt of the platform still causes the ball to fall through. (wait for it to roll out towards the edge, then give the platform a quick tilt up)
Is this the expected collision performance of Unity and PhysX? If anyone can offer any suggestions, it would be greatly appreciated. Thanks....
Whilst not a solution to your problem, try: http://files.unity3d.com/graham/Roll-a-Ball4.0.zip which shows a similar game. I don't remember this demo doing anything special regarding physics.
I too have been encountering issues with small spheres in Unity going through meshes, bouncing uncontrollably, and just generally acting extremely erratically with PhysX. No amount of tweaking the basic settings(and at this point I've tried nearly every combination of rigid body, time, and physics setting) with no love. I've also used the DoNotGoThroughThings script(which causes its own set of problems) and stepped through everything I could. You can get it 90% there, but that last 10% is just out of reach.
The answer it seems is that PhysX, for all it brings to the table, is just plain useless in its base incarnation if you need accurate, small scale sphere interactions with meshes. I know its not the answer you want, and I'm not happy either, but it seems writing your own physics system for your objects is the only way to get consistent quality results.
Here's hoping that someone can prove me wrong.
Futch - thanks for sharing your similar experience. FYI, in regards to sphere size, I started with a sphere/ball scaled to real-world size at the default Unity scale (1 unit = 1 meter), but had very bad results, like you describe. I now use sphere scale 1,1,1 or larger, and increase gravity accordingly. It does help some, but doesn't solve the problem.
I would not say PhysX is useless. It's a widely-used and well-supported physics engine, and I have a hard time believing it is the source of the problem. I more suspect problems with Unity's implementation of PhysX. This has been been the case in the past, with several previous bugs I'm aware of.
Re-inventing the wheel and writing our own physics solver is, in my view, an unacceptable solution. We already have a very capable physics engine, but we just need to figure out why it isn't working correctly in certain cases.
I hear ya, and I certainly didn't mean PhysX is useless, just that for this specific case(small sphere on mesh colliders in Unity) it doesn't produce acceptable results. If you can find a base implementation via physics,time,collider, and rigid body settings that can produce accurate bouncing and rolling results on a mesh without code I'm all ears.
