I notice in my own app using the Q3 level provided that when I move up the ramps in the level the camera needs to be pointed upwards or else it seems to get stuck. Likewise, going down I need to move the camera to avoid getting stuck, although that is less severe than going up the ramps.
This doesn't seem to be a problem in the tech demo, but all the example code is subject to this problem. I've adjusted gravity, the collision radius around the camera, heights and any combination therein with no real luck...any thoughts?
Ramp sticking
Hey there, I am new to Irrlicht and so my reply is probably not the best solution, but I solved a similar problem by doing the following.
I am loading a terrain height map from a grayscale BMP, and so there are lots of cliffs and what not about, and I had a massive problem in that my camera had to be pointed in the *correct* direction of movement in order for my collision detection to not stop movement.
If you look at some facts about player movement :
1. You know where your player is in the world.
2. Based on input, you know where your player *wants* to go.
3. You know your player's movement speed.
Using this information, you can calculate the point at which your character wants to be. Once you have this point, you can then perform additional checks such as the gradient at that point (If the slope is to great, your character cant go there) and other relevant checks. If your calculations determine that the point where your character WISHES to move to is a legal point for your character to exist, then simply move your character to that point.
In my situation, in terms of movement a character can only move along the X and Z axis, where Y is height. So if your character moves at 3 units per second, and he is trying to move along the X axis the only way in which height comes into play is to determine the gradient between the two points. If this gradient is within your predetermined acceptable range, then simply move your character to his new X and Z location, and his Y location will be the height at that point. This means that no matter what angle your camera is relative to the terrain, your character movement is only based on the X and Z axis, so he wont stick all over the show.
I know this is a very round about way to do things, but I have not noticed a FPS knock and combining this method with Irrlicht's already excellent collision detection is a winning combination for me.
I hope this helps,
Kind Regards
Celtic
I am loading a terrain height map from a grayscale BMP, and so there are lots of cliffs and what not about, and I had a massive problem in that my camera had to be pointed in the *correct* direction of movement in order for my collision detection to not stop movement.
If you look at some facts about player movement :
1. You know where your player is in the world.
2. Based on input, you know where your player *wants* to go.
3. You know your player's movement speed.
Using this information, you can calculate the point at which your character wants to be. Once you have this point, you can then perform additional checks such as the gradient at that point (If the slope is to great, your character cant go there) and other relevant checks. If your calculations determine that the point where your character WISHES to move to is a legal point for your character to exist, then simply move your character to that point.
In my situation, in terms of movement a character can only move along the X and Z axis, where Y is height. So if your character moves at 3 units per second, and he is trying to move along the X axis the only way in which height comes into play is to determine the gradient between the two points. If this gradient is within your predetermined acceptable range, then simply move your character to his new X and Z location, and his Y location will be the height at that point. This means that no matter what angle your camera is relative to the terrain, your character movement is only based on the X and Z axis, so he wont stick all over the show.
I know this is a very round about way to do things, but I have not noticed a FPS knock and combining this method with Irrlicht's already excellent collision detection is a winning combination for me.
I hope this helps,
Kind Regards
Celtic