Collision Response Not Correct

Blitz3D Forums/Blitz3D Programming/Collision Response Not Correct

ClayPigeon(Posted 2010) [#1]
This might have been asked before. I'm working on a first person shooter (FPS) and I've run into a snag. B3D's collision response methods are just made to attempt to keep objects from getting 'inside' the model. To prevent this, it just says if the player is colliding, move it up or sideways until it's not anymore. Unfortunately, this means if my player walks towards a wall with even the slightest slope, the player will find himself flying up a wall. I tried to fix this with multiple methods, including 'increasing the gravity when on the ground (so it will be too strong to go up)', and 'finding the normal of all the player's collisions and if any of their Y's are smaller than 0.5, then don't allow the player to move'. None of them worked. Any suggestions?


Jiffy(Posted 2010) [#2]
Use a proxy to check the collision before you move your player. Stop is fine, revers- probably- anything else will work or not depending on environment- somewhere, someday, it'll flip out.

You can't unring a bell.


ClayPigeon(Posted 2010) [#3]
...What?


skidracer(Posted 2010) [#4]
Have you studied the source for the castle demo that comes with Blitz3D. From memory this has pretty decent solution for handling basic FPS collisions.


jfk EO-11110(Posted 2010) [#5]
I know exactly what you mean. It's the "player on ice" symptom. It really isn't so easy to turn this off in blitz.

What I did was: checking the slope under the players feet, relative to his walking direction (note, depends on player action: forward, backward, sidesteps etc.) then, only if the slope isn't too steep I will allow the player to make one step in the desired direction. If the slope is near zero and the player isn't moving then the player will be repositioned to his previous X and Z position. Gravity is applied anyway, but it doesn't matter, cause he's repositioned (so the "on ice" effect is fixed). It's a bit tricky to define the right angles to decide what to do: no sliding at all (0 to 20 deg), sliding down a relative steep slope (20 to 45 deg or so), just like in nature, and nogo slopes, more than 45 degrees or so, that will prevent movement/climbing at all.

I tried the Blitz's native commands but I ended with some homebrew angle determination: I am now doing 4 linepicks from the player towards the ground to calculate the angles. Since the Linepicks are very limited in their length, it's not such a performence hit. And I can also utilize the picking data for other tasks.

You may check the slope and then decide to make a step or not, or you may store the original position, then do the step, check the new slope and decide if the step was legal or not, and if it wasn't then reposition the player at the old location (all within one frame). Since the Player (or NPC, there isn't a big diffrence in the handling) since they will play the walking animations no matter what, it's gonna look/feel as if the player really can't go up the wall because the slope is too steep.


ClayPigeon(Posted 2010) [#6]
@jfk: It sounds to me that the problem you're explaining is like when the player continues to slide on the ground as though it's ice or has no friction. I don't have that problem. My problem is that if you walk towards even a slightly sloped wall, you will be able to get to the top without even jumping. If, in real life, YOU walked into a slanted wall, you wouldn't go flying up to the top!!

PS: I see why you would say that, it's because I said that when I was on the ground I would change the gravity. I meant to increase the gravity when on the ground, because that would prevent me from being able to go up walls because it would pull me down.

@skidracer: I couldn't pick out the part with collisions in the castle demo. All I could find was if the anim_speed was >= 0, move the player, and I couldn't find where the anim_speed was changed?


Jiffy(Posted 2010) [#7]
ClayPigeon:
If your floor is separate from the wall, then you can have different collision responses.

jfk EO-11110:
instead of linepicks (slow)
http://www.blitzbasic.com/toolbox/toolbox.php?tool=11


jfk EO-11110(Posted 2010) [#8]
Jiffy - as far as I recall I tried to use Elias_T's coldet wrapper to replace linepicks some time ago, but something was missing, I don't remepber exactly, maybe PickedSurface or so. Coldet is very useful for a number of things, of course.

ClayPigeon - seems like I misunderstood you. However, both symptoms usually go hand in hand (slowly slide down a very little slope, and the ability to walk up walls that are like 87 degree or so.) I guess the sooner or later you will also experience the first problem, it depends on the level mesh. You may have even floors only by now, but as soon as there is a slight slope, gravity plus collision (the standard gravity in most blitz game implementations) will cause the on-ice symptoms. Anyway, you can use the system I described to get rid of both problems at once.

Maybe you only need to do 2 linepicks, front and back, or left and right, depending on the walking direction. Or maybe you can handle the PickedNX() etc. commands better than me, so you wouldn't have to LinePick multiple times. It would allow you to recognize the slanted wall under your feet, allowing you to reposition the player at the old location. This is going to allow you to define an angle that stops the player from climbing up the wall completely, but it would still allow to walk up and slide down slopes of relative steepness, imagine you're walking up on a 45 degree hill, When there is enough gravity, it will feel like a loaf of gravel, that is rather hard to climb. Of course, the steeper the slope, the more gravity you may apply.


Zethrax(Posted 2010) [#9]
If your game uses momentum, then you may want to consider using a verlet equation to integrate the momentum. I found that switching to verlet from a simple euler integrator equation fixed a lot of issues like this one that I originally needed all manner of flags and checks to handle.


Drak(Posted 2010) [#10]
It's funny I've never come across this problem in any of my first person games. Although, in mine, I do move the player at very small increments each frame, not whole increments. Looking through a first person rpg I wrote awhile back, I move the player ahead .15 units every game loop that the button is held. I cannot walk up slopes greater than about 45 degrees, as gravity keeps the player from leaving the ground. (gravity is constant at -.45) Alternatively, if running, which is (.15 * 2), the player is able to make it up even steep slopes, although very, very slowly. This is counteracted by the fact that fatigue makes the player give up "climbing" the slope whether he wishes to or not, and slide back down.

Perhaps just as an experiment try either reducing the distance traveled each frame or increase gravity to see the effects. As the player's speed (or distance traveled) approaches more than about 1/3 of your gravity each frame, the easier it will be for them to climb steep surfaces.


ClayPigeon(Posted 2010) [#11]
I think I know why no one's run into this issue before. I used the .bb example that comes with Maplet as a base for my FPS engine. It uses a weird method of taking the previous y position of the player and the current and subtracting them from each other and stuff..