how to solve the detection in fast objects??

[fishfish]

I want to make a FPS game, but I found that if the object speed is larger than 100.0f, such object can go through the wall, ie no collision.

Any method can solve it?

Thanks in advance

[Jim]

Hi,

This is a classical problem with collision detection and is almost certainly the result of using Bullet in a manner that is based on discrete collision detection. The problem with discrete collision detection is that we ignore what is happening between two physical time steps. That's to say the collision detection is only processed at specified intervals and if something happens in between two intervals it will be ignored. So if something is moving really fast and collides with something in between two intervals then it will be as though the collision never happened.

The solution to this problem is to use continuous collision detection. Continuous means that we do not ignore what is happening between two physical time steps, but handle all collisions at the exact time of their impact if necessary. The problem is I am completely new to Bullet so I have no idea how easy it is to use Continuous collision detection with Bullet, or even if it works well...

Maybe someone else can give more info. In any case I would recommend taking a look at the appContinuousConvexCollision demo that comes with the SDK.

Good luck.

[Erwin Coumans]

Bullet has continuous collision detection, but currently the time of impact from those calculations is not used in the physics loop.

THis will be put back in soon, when the btContinuousDynamicsWorld is re-introduced. Perhaps very soon from now. Some very old Bullet SDK demonstrates use of CCD, but due to refactoring and more robust testing of discrete (penetration based) simulation is has been disabled in the physics loop.

Hope this helps,
Erwin

[projectileman]

Hi.
Continuous Collision Detection would be the best solution for this problem, but it's an incomplete feature on Bullet because is still on development. I hope that Erwin could finish this feature soon.

However. at this moment I can tell you another method that works with the current discrete collision detection system (btDiscreteDynamicsWorld) , which consist on subdividing the current time step; it is more a brute force approach, just follow these steps:

0) Define a maximum speed constant for objects related with the current time step which guarantees that objects wouldn't interpenetrate at that speed. With a 1/60 time step, this max speed would be 10.0f

1) Traverse all active rigid bodies and take the maximum length of ther linear velocity vector. (square lenght would be more cheap, dot product )

2) Divide the maximum velocity measured on bodies OVER the maximum speed constant and you will get the number of sub steps:

Code: Select all

//pre: measured_speed is the dot product of the longest velocity in bodies
// so we have to normalize it
measured_speed = sqrt(measured_speed);

// Take the sub step factor 

float sub_step_count = ceilf(measured_speed / max_speed_constant);
if(sub_step_count < 0)  sub_step_count = 1.0f;


// subdivide the current time step:

float time_step_fraction = time_step/sub_step_count;

// simulate iterating on substeps
for(int i = 0; i < (int)sub_step_count;i++)
{
        myworld->step_simulation(time_step_fraction);
} 

______________________________________________________

It works for me, and I've already implemented this method in my game engine
http://sourceforge.net/projects/gammaleon/

http://umn.dl.sourceforge.net/sourcefor ... 061124.zip

But it is implemented with ODE. Currently I'm refactoring this engine using the Bullet engine.

[AlexSilverman]

Big thanks to ProjectileMan for that solution. I just implemented it in Bullet and it works perfectly.

Some more info for those who care about performance. I set the threshold velocity to the diameter of the golf ball, since it's the smallest (and only) moving object in the scene, and it's being collided with a static btTriangleMesh object with 690 vertices and 1077 triangles. Initially the ball is being created below the mesh, so it's in freefall, and there's no noticeable slowdown until the ball reaches about 120 meters per second, and I'm simulating nearly 6000 times per frame.

I think my conditions are a bit extreme, as golf balls are relatively small, but I'm pretty pleased with the results Thanks again for the tip.

- Alex