If you try 55wheels.blend from the GameKit, now and then the car falls through the track and off towards -infinity.
I’ve checked the mesh geometry, and this can happen in places where the geometry is correct and seamless. So I assume this is a physics bug.
Is there any way to get around this? Thanks.
using blender 2.34 on Linux
I was doing the maze tutorial ( http://users.bigpond.net.au/blendage/pages/tutorials/tut6/maze.html )
I had the same problem.
after playing around with nearly every button and restarting from scratch,
I found where the bug lives:
Select the track and go to the Editing (F8 ) buttons and click twice
(Remove and re-Make) the button near “TexFac” in the “Mesh” section.
(The maze uses ‘UV coordinate mapping’ since it is composed out of two
materials - maybe it’s also the case for 55wheels.blend …)
salüds,
This question has also been added to the FAQ page: http://www.blendedreality.nl.tt/blendedreality/faq.html 
Wow just a matter of adding a material? I shall remember this for my future games
even when adding a material sometimes i fall through the floor, so i put a second floor underneath the first one.
Adding a material isn’t enough. Without a material, collisions don’t work at all. With a material, most of the time, objects don’t fall through the mesh. But sometimes they do. It’s an intermittent bug. And it can be reproduced with 55wheels.blend.
I’m thinking that parhaps actuator motions are being processed without proper checking for collisions, so that actuators can force collision violations.
So when you’re driving, you can accidentally cause a motion that violates collision checking, after which gravity takes over and the object falls.
What I need are useful answers like “sphere vs mesh works reliably, but mesh vs mesh does not”. I know how hard it is to do reliable game physics (see my web site http://www.animats.com), but falling through the ground is a preventable problem.
The FAQ should be up-front about this if there’s a bug.
Ooh second thing. The place where you enable the light on meshes (edit buttons F9) you also have to check it the button collision is pressed, afther that press “copy drawmode” to enable it. Sometimes this can be unchecked and no collision will be detected on some faces. THis can be really bad and cause falling trought floors or walking trought things. I need to update the faq 
There is in fact one place on the track in 55wheels.blend where that’s the problem. It’s near the silos and barn. But that’s not the only problem.
I’m starting to suspect that multiple simultaneous collisions aren’t resolved properly. Things like hitting a curb or wall are most likely to cause a collision failure.
Multiple simultaneous collisions are hard. What does Blender use to resolve them? Is there an LCP solver in there, or what?
It’s definitely a bug. See our test case and explaination: http://www.overbot.com/public/vendors/blender.
I tested the file, and it works fine to me. Blender 2.25 and 2.34, using linux.
No bug.
Cu.
As I said, it’s intermittent.
It may be related to CPU loading. Does the physics engine take step sizes which vary based on CPU load?
yes
but there isn’t an easy to eplain [in blender] reason for a cpu load spike
in a game I made there was a trememdous load spike when XP would put the buttons on the taksbar [with its fancy animation], often causing several spheres to fall out of the bounds of the world
So you’re seeing it too. Thanks.
There may need to be a ceiling on movement distance when taking oversize time steps. This may look a bit jerky, but it beats falling through the ground.
This problem is just a bug, and it’s rather anoying but isn’t too big of a problem. In 2.25 my game didn’t have any collision problems. When i load it in 2.34, the main dynamic object randomly pops under the main floor. It’s rather annoying, and i hope it’ll be fixed.
Pooba
isn’t too big of a problem.
For a driving game, when the car falls through the ground, it’s “game over”. That’s a killer bug.