Climb stairs problem in FPS game.
Author
Please forgive me if I make mistake in my sentences, I'm really so poor in English.
I'm programming a FPS game, the collision detection of that is implement by intersecting test with triangular face. I can simulate the sliding on the ground by moving the position of next frame alone face normal, it works great now. But i don't know how to make the player climb stairs automatically when he walks on it. Who can help me?
How is your player represented? AABB? Ellipsoid? Is your world in a BSP tree, or just raw triangles?
Well, walking DOWNSTAIRS is easy as you probably already know... All you have to do is implement some gravity and some collision to make sure the character doesn't fall through the floor.
As for walking upstairs, here's a basic idea... I'm writing all this off the top of my head so forgive me if there is any mistake, but anyways this is roughly what I am doing in my game..
When moving a character in the XZ plane, basically ignore collisions that are below the character's knees... So if you're doing raycast based collisions, send the ray out from a higher point than usual. If it's based on an AABB, you could truncate the box.
Then, also every frame you can cast a ray downwards from the point that is "STAIR_HEIGHT" above the character's feet. (so around their knees). If it collides with the floor and the distance from the character's knees to the collision point is less than STAIR_HEIGHT, then it means his feet are "underground", so adjust his y coordinate appropriately to boost him back up onto the ground. This way, when you're walking upstairs, your feet will go underground every time you move from one step to the next step, but then it plops you up to higher ground
Hope that makes sense ;)
roos
As for walking upstairs, here's a basic idea... I'm writing all this off the top of my head so forgive me if there is any mistake, but anyways this is roughly what I am doing in my game..
When moving a character in the XZ plane, basically ignore collisions that are below the character's knees... So if you're doing raycast based collisions, send the ray out from a higher point than usual. If it's based on an AABB, you could truncate the box.
Then, also every frame you can cast a ray downwards from the point that is "STAIR_HEIGHT" above the character's feet. (so around their knees). If it collides with the floor and the distance from the character's knees to the collision point is less than STAIR_HEIGHT, then it means his feet are "underground", so adjust his y coordinate appropriately to boost him back up onto the ground. This way, when you're walking upstairs, your feet will go underground every time you move from one step to the next step, but then it plops you up to higher ground
Hope that makes sense ;)
roos
I do two things for stair walking right now. One is to use a ( 1, 2, 1 ) ellipsoid ( in meters ), and then I turn off gravity if I detect enough upward facing trianges under the character's feet.
What I do is drop the character's elippsoid by 0.2 of its vertical radius, and then gather all tris it touches. I then get the triange normals, weight them by penetration depth, and renormalize. If the normal.y value is above a threshold, like 0.3f or so, I turn off gravity for that character.
That helps him not have to fight gravity on his way up the stairs. I was also considering giving him a vertical velocity boost if the dot product between the 'average normal' below his feet and his desired velocity is in a certain range.
What I do is drop the character's elippsoid by 0.2 of its vertical radius, and then gather all tris it touches. I then get the triange normals, weight them by penetration depth, and renormalize. If the normal.y value is above a threshold, like 0.3f or so, I turn off gravity for that character.
That helps him not have to fight gravity on his way up the stairs. I was also considering giving him a vertical velocity boost if the dot product between the 'average normal' below his feet and his desired velocity is in a certain range.
Author
Thank you very much. You're so warmhearted, I mean u r good people.
In truth, I'm just a beginner for game programming. I used a sphere to represent the player, I know it's so fool, i just have a try by it first.I not used BSP tree for scene manager yet, i'm just using a hierarchy scene node tree for it now. I don't know that how to build a BSP tree from the mesh exported by 3D modeling software even.
I can understand the method that roos used, that's smart, i will have a try for it, thank u.
But i have a little confusion about the method SimmerD said, what's meaning of "weight them by penetration depth"? Is that ur means the ellipsoid will slide up along the STAIR FACE automatically? I'm so poor in English, sorry.
And who can tell me how QuakeIII implemented this?
Thank u again.
In truth, I'm just a beginner for game programming. I used a sphere to represent the player, I know it's so fool, i just have a try by it first.I not used BSP tree for scene manager yet, i'm just using a hierarchy scene node tree for it now. I don't know that how to build a BSP tree from the mesh exported by 3D modeling software even.
I can understand the method that roos used, that's smart, i will have a try for it, thank u.
But i have a little confusion about the method SimmerD said, what's meaning of "weight them by penetration depth"? Is that ur means the ellipsoid will slide up along the STAIR FACE automatically? I'm so poor in English, sorry.
And who can tell me how QuakeIII implemented this?
Thank u again.
Author
Oh, I forgot to tell u that the world I used for collision detection in my game just is raw triangles, subdivided by scene node.
Elipsoid collision detection has the huge advantage that it will not make the movement as jerky, it will stay smooth. Don't worry about the bit you couldn't understand. It had me tilting my head sideways a little also.
The main thing is that Elipsoid colision detection is a great method, and can be enhanced by various means to make it even better. Once you've implmented it you'll know what might not be quite how you want it, and can think of your own improvements.
The main thing is that Elipsoid colision detection is a great method, and can be enhanced by various means to make it even better. Once you've implmented it you'll know what might not be quite how you want it, and can think of your own improvements.
Heya,
An alternative [that I don't use myself, but that could probably still be mentioned here] is to build a seperate physics model for your level, which contains simplified versions of the geometry. You can create your stairs with a single sloped plane so that your character can move from standing on one to standing on another.
The implementation that I would personally have if using a simplified physics model is to have simplified tris representing all of the ground areas, and then have your world editor 'join' the edges of these ground triangles together, on an edge to edge basis. Then you keep a track of which ground tri the character is standing on, and whenever they move over the edge of a tri, you determine if it's joined to another tri. If it is, they move to the same point on the edge of the next tri. If it isn't, you just determine where the edge of that tri lies and determine the angle that you're going against the ground there so you get [basically] free sliding collision with walls and stuff... Of course, the implementation for areas that you have to crouch to move around in or jump up to can be handled by tagging particular triangles with properties.
This stuff mainly comes in handy when you want to do simplified [read fast] collision detection with the world, or dynamic acoustics or whatnot, but you can pull off a bunch of neat tricks by representing the world in a simpler, low poly, not-for-view way.
CJM
An alternative [that I don't use myself, but that could probably still be mentioned here] is to build a seperate physics model for your level, which contains simplified versions of the geometry. You can create your stairs with a single sloped plane so that your character can move from standing on one to standing on another.
The implementation that I would personally have if using a simplified physics model is to have simplified tris representing all of the ground areas, and then have your world editor 'join' the edges of these ground triangles together, on an edge to edge basis. Then you keep a track of which ground tri the character is standing on, and whenever they move over the edge of a tri, you determine if it's joined to another tri. If it is, they move to the same point on the edge of the next tri. If it isn't, you just determine where the edge of that tri lies and determine the angle that you're going against the ground there so you get [basically] free sliding collision with walls and stuff... Of course, the implementation for areas that you have to crouch to move around in or jump up to can be handled by tagging particular triangles with properties.
This stuff mainly comes in handy when you want to do simplified [read fast] collision detection with the world, or dynamic acoustics or whatnot, but you can pull off a bunch of neat tricks by representing the world in a simpler, low poly, not-for-view way.
CJM
Sorry if my post was confusing.
The idea is to find an average facing direction for all triangles under the player, so as you move across a rough terrain or a possibly highly tessellated staircase, the movement is not jerky. If you only find a single triangle under the player, it's possibe to have a problem that one frame you detect an 'upwards triangle' that you can walk on, and the very next frame you moved only slightly and now the nearest triangle is different, and it points more sideways. This can lead to jerky movement or getting stuck. My solution is to filter or average the triangle normals under the player so the normal used for determining if he's on the ground changes smoothly as he moves across the environment.
How I do it is that you move the sphere or ellipsoid downwards, and find all triangles it intersects. This is not a swept test where you find only the first collision.
For each triangle intersecting the sphere, you find the point on the triangle closest to the sphere center. These distances will all be less than the sphere's radius ( otherwise they wouldn't be colliding ). These distances are the penetration depths between each triangle and the sphere. The deepest one also corresponds to the triangle that you would have collided first with. So, take each triangle normal, multiply it by that triangle's penetration depth, and sum into a vector. After all triangles are processed, then renormalize the vector. This gives you an smooth, average normal under the player.
The idea is to find an average facing direction for all triangles under the player, so as you move across a rough terrain or a possibly highly tessellated staircase, the movement is not jerky. If you only find a single triangle under the player, it's possibe to have a problem that one frame you detect an 'upwards triangle' that you can walk on, and the very next frame you moved only slightly and now the nearest triangle is different, and it points more sideways. This can lead to jerky movement or getting stuck. My solution is to filter or average the triangle normals under the player so the normal used for determining if he's on the ground changes smoothly as he moves across the environment.
How I do it is that you move the sphere or ellipsoid downwards, and find all triangles it intersects. This is not a swept test where you find only the first collision.
For each triangle intersecting the sphere, you find the point on the triangle closest to the sphere center. These distances will all be less than the sphere's radius ( otherwise they wouldn't be colliding ). These distances are the penetration depths between each triangle and the sphere. The deepest one also corresponds to the triangle that you would have collided first with. So, take each triangle normal, multiply it by that triangle's penetration depth, and sum into a vector. After all triangles are processed, then renormalize the vector. This gives you an smooth, average normal under the player.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
