Object Falls Through Floor from High Height

Hello I’m attempting to make a 3rd person shooter gane using Blender v2.74 and I have placed a cube at the player’s feet for the collision and movement. I have also created a plane with the static dynamic and use it as a floor. But when I walk the player off of a high place, the cube will fall right through the plane. The collision works when I walk across it or jump on it but when it falls from a high place the collision won’t work.

Is there any way to fix this? Am I doing something wrong?

Use marigins for collision. I’d make another collision mesh for floor with triangle mesh collision and 0.1 marigin and make it invisible and place 0.1 lower than visible floor. And make visible floor no-collision.

Make the ground a static actor. Make your character cube or box dynamic give it a box collision bound.

I added the marigin collision to an invisible plane underneath the visible one as suggested by adrainsnetlis and the collision stopped the fall most of the time. So I added the marigin collision to the cube with the same options and it worked! I can now fall from a skyscraper and land on the ground without going through it!

@VegetableJuiceF - Well, that’s not quite true. If you were simply teleporting the object, then yes. However, Bullet does handle physics for game objects effectively enough for most purposes. If you need more precision for physics, you can increase the physics substep in the World panel.

Making objects bigger is a good idea, though they will seem to fall more slowly because of the larger size; are your objects sized correctly to begin with?

EDIT: Ah, you’ve got it. Never mind.

Maybe I’m stupid,i have been told this before…
Having substeps still means that the physics runs in frames, just that these frames happen faster than the render/logic frames?
Or does it stretch the object from start to end to check collisions? That would be comical :smiley:
Also increasing the substeps would be brute forcing the problem?

I thought that instead of getting things murky, my way to view it should get the best results with least amount of knowledge of physics systems.

Also by “to make object bigger” I meant collision margins or hit boxes, but do you mean that scaling everything up would improve perfomance? I don’t get how.

The problem at hand is called tunnelling and it shouldn’t happen - because bge uses bullet in ccd mode and ccd mode stretches objects to predict collisions that happens between frames, it doesn’t warp things to location.
Unfortunately, there is something fishy going on with bge and bullet (for example the speed of things is bound to the frame rate and that is very bad) but figuring out where things go south in the code is a tedious process.
Increasing the substeps seems to mitigate the issue but, again, we’re talking about something that shouldn’t happen.

Actually, by default, CCD is not enabled in the BGE (IIRC). However, you probably don’t need it here.

Wait a minute: are you telling me that bge has a physics module in the bullet directory that is called CcdPhysicsXYZ, points to the ccd bullet framework and then doesn’t use it? And no one went to jail for that? :smiley:

By default. It’s not always useful. You can enable it in the bge.constraints module.


I dived a little in the code and I now believe that the only “Continuos Collision Detection” available is in the prefix of the names of the classes (because despite seeing the constraints methods I haven’t found the calls to actually enable the ccd dispatcher).

Do you know how many hours CCD would have saved me!


Can we have

object.setCCD = True?

or better yet, have CCD turn on automatically with fast moving objects?

CCD on my ragdoll actor = would never had to restart Wrectified X(

The bullet api provides a way to set ccd for single objects. There are tutorials that explain how. As always, the problem is transplanting those examples in the bge codebase. Frankly I’m not even 100% sure that bge doesn’t use ccd: I can’t find the calls but maybe I’m looking in the wrong place. I wouldn’t be surprised to see that the code for the physics used by the engine is in the script folder of the plugins for the UI.