So I've been doing some studying on how JME handles terrains and I was wondering which was more efficient, making hieghtmaps by hand or using the gray scale? It looks like using the gray scale would be easier but would it look as good?
Another question I have is do I make the terrain as one solid bitmap or do I make several and connect them some how? If I have to connect them some how, how would I do it?
For your first question I would looks at a program like Terragen http://www.planetside.co.uk/content/view/16/28/ to make a heightmap, that way you can visually sculpt it and export it as a grayscale image.
For your second question have a look at TestIsland.java it has uses texture splatting to draw textures onto the terrain.
SomethingNew said:
For your first question I would looks at a program like Terragen http://www.planetside.co.uk/content/view/16/28/ to make a heightmap, that way you can visually sculpt it and export it as a grayscale image.
For your second question have a look at TestIsland.java it has uses texture splatting to draw textures onto the terrain.
Thank you :) I've been looking into that but now I've run into another small issue. I'm working on making a very small MMORPG for testing purposes. About a medium sized island. I've been running it through my head and I was wondering, wouldn't it take a while for it to load a decently sized terrain? How do I handle this? Do I cut it up and then put a boundingbox around each piece? But if I did that, then how would it assemble it correctly each time? Do you or anyone else know the process for loading a decent sized terrain for an MMORPG?
I've been working on a similar problem for the past couple days, and my solution has been to implement a terrain tile system, with a moving 'viewport.' The general idea is that your world's terrain becomes a grid of tiles, which allows you to only load the terrain that the player can see (which is the viewport). I've found that a viewport of size 3*3 works pretty well. Just update the position of the viewport as the camera leaves each tile.
Hola,…there are some ways to create a heightmap in jME. As you think
about using grayscale-images yours would be ImageBaseHeightMap. Once
you loaded your heightmap you can use two options. TerrainBlock or TerrainPage
TerrainBlock would be one huge terrain-mesh like you had in mind. This would blow
your performance quite fast.
But if you decide using TerrainPage your heightmap data will split into smaller parts (you can
tweak size in one of the paramteres) which will be culled if out of sight…
Only trouble with grayscale image based height maps is you lose precision as you only have one byte to work with.
It can cause visible lack of smoothness with any decent height range. 16 bit raw gives you smoother terrains.
Fiarr said:
I've been working on a similar problem for the past couple days, and my solution has been to implement a terrain tile system, with a moving 'viewport.' The general idea is that your world's terrain becomes a grid of tiles, which allows you to only load the terrain that the player can see (which is the viewport). I've found that a viewport of size 3*3 works pretty well. Just update the position of the viewport as the camera leaves each tile.
Kind of like how runescape is set up? Could you show me the code or a simple step by step procedure of how to do that? Thank you :)
ttrocha said:
Hola,...there are some ways to create a heightmap in jME. As you think
about using grayscale-images yours would be ImageBaseHeightMap. Once
you loaded your heightmap you can use two options. TerrainBlock or TerrainPage
TerrainBlock would be one huge terrain-mesh like you had in mind. This would blow
your performance quite fast.
But if you decide using TerrainPage your heightmap data will split into smaller parts (you can
tweak size in one of the paramteres) which will be culled if out of sight....
So your saying if I use TerrainPage and just change the size of a perimeter to a certain size then it will only load that certain size that's viewable by the camera?
It will load the whole heightmap but splits the whole map into smaller geometry.
Every geometry with its own boundingvolume which let it cull when out of the cameraview.
durenir said:
Kind of like how runescape is set up? Could you show me the code or a simple step by step procedure of how to do that? Thank you :)
I'd give you straight code, but my implementation includes a custom terrain loader (that you won't want... trust me).
Here are the basic steps I went through:
Pre-game stuff:
1. Decide on a tile size in world units.
2. Create heightmaps of a size that can be built to fit that size
Update method:
1. Determine what tile the player is in
2. Is the player in the same tile they were in last check? If not, rebuild the terrain.
Build terrain method:
1. Build a 3*3 array of heightmaps - terrain[3][3]
2. Iterate through each heightmap and create your terrain
3. (Fun part) Place the terrain in a 3*3 grid pattern based on what tile the player is in. My approach relied on the images themselves, since I found a GIMP plugin that would split a large image into smaller images (google 'gimp split image'). Each image was named heightmap.pngROW COL.png, so I was able to simply have the program look for images for the tiles adjacent to the new location, and render each as terrain.
The tricky bit here is getting the terrain lined up, so I'll give you an approximation of what this should look like:
//Two for loop iterators, tX and tY, being the tiles of the visible viewport.
//TILESIZE is the square dimension of your tile images - ex: 64*64 Image -> TILESIZE = 64
//(tX*TILESIZE) - Places the current terrain in the correct position of the 3*3 viewport.
//(tileX*TILESIZE) - Puts the viewport in the correct position with respect to the camera.
float blockX = (tX*TILESIZE)+(tileX*TILESIZE);
float blockY = (tY*TILESIZE)+(tileY*TILESIZE);
//You may have to tweak this to convert from image size to your world size. My world was made up of Blocks, and each Block was twice the size of a single unit, so I had to multiply by 2 whenever TILESIZE appeared to convert.
Hopefully this points you in the right direction!
Thanks guys! 
I have another question now. Lol. I noticed JME handles textures by using elevations of the terrain or you can use texture splatting. What exactly is texture splatting? I've looked it up everywhere and didn't really understand it that well. Thanks again!
durenir said:
Thanks guys! :) I have another question now. Lol. I noticed JME handles textures by using elevations of the terrain or you can use texture splatting. What exactly is texture splatting? I've looked it up everywhere and didn't really understand it that well. Thanks again! :)
Bump!