wraparound terrains
Blitz3D Forums/Blitz3D Programming/wraparound terrains
| ||
| I am trying to create a wrap-around terrain. I have my main terrain which has been scaled by 256x256 in the x/z dimensions. then I CopyEntity 8 times to place copies around the main terrain in a 3x3 grid. Is there a default scale for the initial terrain, because I need to know where to place the other terrains to align with the original. If the original is at 0,0, the X=0, Z=0 corner is at 0,0 so the other terrains should be placed at... -256+XX,-(256+XX) 0,-(256+XX) 256+XX,-(256+XX) -256+XX,0 256+XX,0 -256+XX,256+XX 0,256+XX 256+XX,256+XX The value I am after is XX (hope you can understand this!) The other terrains dont show up :((( |
| ||
| Blitz terrains? You can not copy a blitz terrain. You need to create them separately. From memory the default size is the grid size which is then multiplied by the scale. I'm not sure the idea of using multiple blitz terrains like that is a good one performance wise though I suppose it may be OK on a fast PC. |
| ||
| Perhaps TerrainSize(terrain) , is what you're looking for? |
| ||
| The idea is to have a 3x3 grid of identical terrains so that even though the view appears to be wrap-around, the camera will actually shift to the opposite end each time it reaches the boundaries of the central (original) terrain. So the player can traverse what appears to be a planet's surface infinitely in any direction. I couldn't think of better ways to approach this... From memory the default size is the grid size What is the grid size? Is this relative at all to the pixel size of the heightmap? |
| ||
| Yes, it's the same, if you load a 64x64 heightmap the terrainsize will be 64x64. This is in the docs. |
| ||
| Ahh, so in fact my terrain is 256x256 X 256x256 I think it would be okay to have so many, because I am using lots of fogging - I hope so any way) Otherwise...does anyone know of an alternative to this method? |
| ||
| Malice, Why don't you create a 512 x 512 heightmap but keep the original 256 x 256 in the middle and copy sections of it to pad out the bigger one. Then you only need one terrain. Basically then you can use something like this (haven't tested as at work) ... If player_x < 128 player_x = 384 + ( player_x - 128 ) if player_x > 384 player_x = 128 + ( player_x - 384 ) Not sure if this makes sense but I have an code example of this if you want and it works quite well. Stevie |
| ||
| Yeah that's what I was going to do, but didnt't think of re-sizing the heightmap! Thanks Stevie - was wondering actually because you would have needed to do something similar for your Zarch remake! |
| ||
| I did try it this way initially but it didn't work too well for me as it looked too realistic when textured?! I just used my own custom terrain so that I could use individual vertex colors to get the retro shading. Anyhoo, I wrote a function that enlarges a 256x256 heightmap is you have any trouble with it. Stevie |
| ||
| Great! Thanks loads, could you provide that function for me? It's just the theory seems straightforward enough, but we all know what that means when it comes to practice :) |
| ||
| At work and out on the piss later but will send you this tomorrow at some stage if you can wait? |
| ||
| Sure - I got similar plans for today and this evening! have a good'n! |
| ||
This should do what you want ..Function wrap_image(image$,wrap$) i = LoadImage(image$) n = CreateImage(512,512) CopyRect 0,0,256,256,128,128,ImageBuffer(i),ImageBuffer(n) CopyRect 0,128,256,128,128,0,ImageBuffer(i),ImageBuffer(n) CopyRect 0,0,256,128,128,384,ImageBuffer(i),ImageBuffer(n) CopyRect 128,0,128,512,384,0,ImageBuffer(n),ImageBuffer(n) CopyRect 256,0,128,512,0,0,ImageBuffer(n),ImageBuffer(n) FreeImage i SaveImage (n,wrap$) Return n End Function |
| ||
| BEWARE: Infinate terrains will make numbers VERY VERY big very quickly. ! |
| ||
| I've been trying to figure out how to do this efficiently as well. I read in other posts that when using multiple terrains or Mesh's there are serious issues with the edges of the terrains and mesh's not lining up properly and a large crack showing. It would seem as though Blitz already uses the height map information to set the height of the vertex's on the terrain rather then as they come into visible range. If that is correct than one should(in theory) be able to access the heigh map memory and rewrite the values so that the height map memory space is treated as a window of the height map information. You would then shift the existing data and add new data at the approaching edge. This is the basic speed versus amount of memory used trade off. I have not found a way to access the heigh map memory so I havn't tested weather this would be faster than having multiple terrains or mesh's and loading the new mesh data as the player approaches the edge of the old mesh. Has anyone done a complete testing of the code possibilitys for Infinate or Very Large terraigns? |
| ||
| do a search for "infinate terrain" in code archives |
| ||
| "I read in other posts that when using multiple terrains or Mesh's there are serious issues with the edges of the terrains and mesh's not lining up properly and a large crack showing" ModifyTerrain might help : http://www.blitzbasic.com/b3ddocs/command.php?name=ModifyTerrain&ref=goto |
   |