collision detection between player and world

Started by
6 comments, last by remdul 17 years, 7 months ago
Hi, I'm having a hard time with making proper collision detection between the player and the surrounding world. I think it can be faster, and it has its problems. The world has been divided in a quadtree. So when checking for a collision, only nearyb polygons will be checked. That's not the problem. But now there are 2 other problems, the way i check the collision, and the reaction. I think i should use a cylinder around the player, but so far I use a sphere. Not very realistic, because parts of the body are not covered and can move through polygons. And there's another problem with walking stairs. When putting the sphere too low, your feet will collide with the vertical parts of the stairs. So I place it heigher, and obtain the height below my feet another way. Another nasty problem is the reaction. When I detect a collision between the sphere and a polygon, the player stops, which is very annoying. The movement direction should change (90 degrees on the polygon normal), instead of stopping all movement I guess. Another problem is that I can get stuck. So I bounce the player back the opposite way of its movement. As long as he's still in the wall, he will get moved a little bit back further. But the result is many collision checks, and "shocking" movement when moving nearby a wall. The same problem for getting height. If the player has no collision with the floor, he starts falling. But when he hits the ground, he should be placed a little bit back. That causes the player to bounce a little bit all the time. I solved it by using some threshold before bouncing, but again, it takes extra collision checks. I guess it can be done way better than this... Greetings, Rick
Advertisement
This is a great article which you should definitely check out.
Best regards, Omid
I second that!
I've had beautiful/flawless results with elipsoid collision detection based from this. Even walking up and down stairs looks and works fine - even with 3rd person perspective (camera following behind character).
Hoi,

What you should do is calculate the amount of penetration when an object collides with the environment (or other objects), then push it back that amount + a tiny extra amount, to make sure it no longer collides.

Quote:I bounce the player back the opposite way of its movement

In addition to fixing the penetration, you can reflect the movement vector relative to the collision plane (wall/floor normal), this is easy to do:

float3 Reflect(const float3 &v, const float3 &n){ return n - v * DotProduct(n,v) * 2;}// where v = vector and n = plane normal

A capsule, cylinder or elipsoid is in general a better type of collider for humanoids and should be equally easy to calculate (as long as it stays upright).

As for the stairs problem, you could cast an additional ray in front of the player and use that push the player up a slight amount (jump), if it encounters something. Make sure that you adjust the ray with the player movement vector so it will also work when walking sideways or backwards.

[Edited by - remdul on September 7, 2006 6:47:16 AM]
With regards to stairs and other such difficult to navigate scenery I recommend using two world meshes, a detailed one for rendering and a simplified one for collision. The reason is two fold. First off you'll likely have a very detailed render mesh with lots of polygons which is very expensive to collide against so using a simplified version can give you a significant speed boost. Secondly, in the collision mesh objects such as stairs and door frames can be replaced or smoothed with ramps leading to easier navigation around the world.
[size="1"] [size="4"]:: SHMUP-DEV ::
That's not a bad idea. In fact, I have a simplified mesh of the model (for pathfinding stuff) that I could use.

But no matter how simple the mesh is, most of my problems will stay of course. I think I found the right name for the collision response thing I need; "WallSlide". I found something in a paper from the game MDK2. They said they calculated the wall slide as follow:
// Vt = Desired Target or Destination of Player// Ni = Normal to the plane of impact// Nd = The "D" of the hit poly's "plane equation"//  Vt += Ni * (-dot(Ni,Vt)-Nd)

What's the Nd? Penetration depth or something?

Everybody thanks for help. Using an elipsoid like the paper said seems to be a good idea indeed. But its going to be a hard time to understand that paper... Math is not exactly my best skill...

@remdul
Etten Leur? Dan weet je vast wat "Audoe!" betekent. Bedankt voor de hulp!
Quote:Original post by spek
// Vt = Desired Target or Destination of Player// Ni = Normal to the plane of impact// Nd = The "D" of the hit poly's "plane equation"//  Vt += Ni * (-dot(Ni,Vt)-Nd)

What's the Nd? Penetration depth or something?
Nd is the distance component of the plane of the surface you've collided with. One way to represent a plane is with a 3D vector (the normal) and a scalar (the distance from the origin along that normal). In the above equation, these are Ni and Nd.

The effect of the equation is to modify a vector (in this case the player velocity) so that it is parallel to the plane.
Quote:Original post by spek@remdul
Etten Leur? Dan weet je vast wat "Audoe!" betekent. Bedankt voor de hulp!

Haha, yup. Ooit veroveren we de wereld...again... [grin]

This topic is closed to new replies.

Advertisement