Terrains - non-walkable areas (slopes)
Blitz3D Forums/Blitz3D Programming/Terrains - non-walkable areas (slopes)
| ||
| Hi, Sorry for the amount of questions I'm asking here :) I was wondering, what is the best way to prevent my player from walking on specific areas in a terrain? For instance, I don't want him to walk up or down some mountains... The solution I thought of was creating a second terrain, (possibly a lower resolution image but then scale the terrain to save polygons), with white (very high) pixels where you can't walk, and set the alpha to 0 so you can't see it. Would this be a good solution, or would it be overkill? Any other things I could consider? Thanks. |
| ||
| Create a unvisible Barrier with Cube or other unvisible objects. Alpha 0.0 |
| ||
| Well, what I suggested above (a second terrain) is kind of the same, except that it allows for more detail... and it has LOD. Still, it might be too slow because it uses more polygons (I would use a very small heightmap and scale it over the larger terrain to keep this to a minimum though). So I'm not sure which method is best. |
| ||
| I guess the size of the area required for 'Invisible barriers' would be the main factor on how to approach this. If it's a large, complicated area, perhaps your 2nd mesh may work. Otherwise, if it's just a couple of mountain bits here and there, use some primitives. |
| ||
| Keep in mind blitz terrains are a bit slow due to the constant rebuilding of the terrain mesh every renderworld. You could make the areas you don't want the player to walk on, a steep slope, and check the collision normals. If the collision normal is too large, then stop the player from walking and slide him down a bit. |
| ||
| How do you check the 'collision Normals'? I assume this check will give you an answer in vertices? This could really help me with something quite different... |
| ||
| http://www.blitzbasic.com/b3ddocs/command.php?name=CollisionNX&ref=3d_cat |
| ||
| The problem is you cannot tell Blitz the max slope angle that is allowed for walking, this would make things much easier. I suggest to use invisible things to limit zones. Invisible means, set up all collision settings, but EntityAlpha them to zero (don't use HideEntity), so they won't be rendered, but nevertheless act as collision factors. Probably you will be able to write a function that will automaticly generate a ring of vertical quads around terrain-zones that have steep angles. At least that's what I would try to do to save myself a lot of work. |
| ||
| Personally I would just stick another collision sphere infront of your player if it gets +/- on the y axis whatever your limit is by comparison to your standard collision sphere then you can't move. The downside of this is that you could probably tack accross a cliff face. |
| ||
| Pehaps you could increase the 'steepness' of the slope so that it can not be climbed. |
| ||
| Thanks for the ideas. Suppose I do go for my initial idea, with the extra terrain mesh - what would be best (performance-wise)? Making the image very small in resolution and scaling it, or just changing the terrain detail to a very low value in blitz? Or should I do both? Thanks. |
| ||
| Are you creating the terrain using a heightmap? If so create another bitmap the same same size and simply paint a particular colour for where you can walk and other colour for where you can't. You can read that bitmap into an image and read pixels depending on where your character is? You could use any number of key colours to indicate different terrain - water, sand, swamp, forest etc. |
| ||
| The problem is you cannot tell Blitz the max slope angle that is allowed for walking, this would make things much easier. Sure you could! Create a pivot parented to you that is a little in front of you - or rather a little away from you in the direction you're trying to walk; Use this to check the gradient (TerrainY of the pivot minus TerrainY of you) If gradient > maximum, don't allow the player to move forward. You can get more subtle - in my demo you slow down as you climb steeper gradients and run quicker downhill - you could add fatigue etc. |
| ||
| Johns method is the one I'd use. Very light on CPU, and easy to implement. |
| ||
| The only problem with that method is that you run into kind of square force fields and it can feel a bit strange, but I agree it can be efficient. |
| ||
| "The only problem with that method is that you run into kind of square force fields and it can feel a bit strange, but I agree it can be efficient. " The higher the resolution of the image, the more subtle it will get, so this wouldn't be a problem. I think I'll use this method, thanks John! |
| ||
| I got it working, but the player stops very abruptly (I keep track of his previous position, if his current position after the updateworld is in a spot that has a white color in the image then he goes back to his previous position), and I don't know how to program the "image-collision" so that it's sliding collision... So for now I'm going for a second terrain with a detail of only 20, and it works great. |
| ||
| >> player stops very abruptly<< that's the problem with all "then don't walk" solutions. Additionally it will complicate the handling of other character controls or combinations, eg. jumping, underwatermode etc. Using invisible fences would allow sliding collision allong them. If you watch some pro engines, like say lithtech, they all use invisible fences. Especially in outdoor scenes with steep terrain slopes. |
   |