JME3 Terrain system

I’ve posted this to the private mailing list but I should post it here too so everyone knows what I have in the plans for a terrain system.

The main thing to note is that I will try to build up an API for terrain that other projects can use to supply their own terrain system, in case this one doesn’t work for their needs. Then that way they can swap out the underlying terrain system and not have to re-write their app around it.



So here is the doc:

http://docs.google.com/View?id=df9w3xb6_50cw7h3mgg

Any and all feedback is much appreciated.

Dont want to teach you how to suck eggs etc…







The LLama terra system should be adaptable for this.



possibly Mapspiner or the other one done from the island dweller with a basketball



From http://www.skapeworld.com the real issue is textures - number of polygons is a tiny issue… didnt worry about collapsing polys in a mesh for LOD as it made such a teeny difference in performance, the LOD also presented challenges in the complexities and side effects of popping etc.

Yeh I would really like to have the system able to support, with a little effort, other terrain systems underneath.

Textures are definitely the most difficult part. There are several solutions out there that solve one problem but raise another. So having it as pluggable as possible will give people choice.

It will have a default method of doing textures for terrain so the majority of people can just get something going quick that works decently.

Hi there,



any news here?

How is it going?

Been on holidays the last two weeks. But there will be a release of it this August. yay!

It will just be an initial cut, definitely not the whole system.

I'm definitely looking forward to it!

Cannot wait - this looks to be one brilliant tool!

In designing the terrain system keep in mind not everyone uses an x-y heightmap with terrain splatting.  The project I work on uses very large – and detailed – geocentric triangular irregular networks.



The scale of the data breaks the boundary of floats, so I'm already forced to make compromises in jME by translating geocentric to a local coordinate system.



The terrain system I've implemented in jME 1.0 is quadtree based with mesh/batch size optimization.

Hi Sploreg


Sploreg said:

Been on holidays the last two weeks. But there will be a release of it this August. yay!

Yeah! ^^

So august nears the end... any progress?
Any screenshots?

Sploreg said:

It will just be an initial cut, definitely not the whole system.

Of course thats ok. ^^

I thought I would give a quick update on Terrain now that I am back from PAX, which was lots of fun. Gotta see some JME games there some day :slight_smile:


  • I fixed the last remaining bug I had in the geo mipmapping algorithm and that is ready to go.
  • I have refactored and cleaned up a bunch of the code so it will be usable by others and fairly customizable.
  • I ported over some of the jme2 heightmap generator classes: hill height map, fault fractal heightmap, etc.
  • There is an easy to use test case that people can follow as an example on how to use the terrain
  • Multi texture layer support added in on the shader. Right now it just supports 4 textures but I will bump it up to 16 after the first release.



    To finish it up for a release I have a couple remaining items (and bugs I just found) that I will fix in the next few days:
  • Fixing a bug with the texture coordinates
  • the test case needs its controls cleaned up
  • creating a little documentation for the wiki, and then later on full documentation on the whole algorithm and architecture



    Performance on it so far has been great, especially from any terrain I have made on jme2. I have a 1024x1024 terrain map (aprox 2.1 million polygons) and I'm getting a good 300FPS on my geForce 9600gt, core 2 duo. So the LOD system is working really well. It's also rendering 4 texture to it and only doing that in one pass (as opposed to the old texture splatting system in jme2 that used multiple passes)



    I will release the code/link to my repository and make a jar available for download, and if people like it, then it can go into the jme3 codebase.

Very nice, it's cool to see that things are going towards to release.

What algorithm do you use to seamlessly wield terrain borders that have different LoD?

It's a bit of a custom algorithm. I will be making a tutorial lesson today that will describe in full detail how it works.

Essentially it renders the center of the terrain patch with its normal LOD, and then it will go around the outside of that center piece and draw the edges according to what the neighbour's LOD levels are.

Hi everyone,



I am really looking forward to to get my handy on it, since it was one of the points for me to wait for jME3 with my project.

Does the system allows the creation of holes?

Do you use any algorithm based on voxels? http://www.thermite3d.org/joomla/index.php?option=com_content&view=article&id=7&Itemid=33

ivanpg said:
Does the system allows the creation of holes?
Do you use any algorithm based on voxels? http://www.thermite3d.org/joomla/index.php?option=com_content&view=article&id=7&Itemid=33


It will allow you to swap out pieces of the terrain for more complex models, so you can make things like caves and cliffs. This isn't in yet but it is in the planning phase.
It does not use a voxel system. However you will be able to modify the terrain in real time, say if you had an explosion and it created a crater. Hmm, I should put that into the test example...

Regards the coordiante system.

Floating points get rather inacurate the larger they are. If you are on tile 24, 32 you reallly dont want your local translation to be 24000, 32000.

Are you able to reset the ccordinates to 0,0 after walking over …n tiles ?

Sploreg said:
It will allow you to swap out pieces of the terrain for more complex models, so you can make things like caves and cliffs. This isn't in yet but it is in the planning phase.
It does not use a voxel system. However you will be able to modify the terrain in real time, say if you had an explosion and it created a crater. Hmm, I should put that into the test example...

Oh, great!!! It will be fantastic.
When do you think will be available?
theprism said:
Regards the coordiante system.
Floating points get rather inacurate the larger they are. If you are on tile 24, 32 you reallly dont want your local translation to be 24000, 32000.
Are you able to reset the ccordinates to 0,0 after walking over ..n tiles ?

In short, no. But most of JME would have to change to support that, unless you completely centered the world on (0,0,0) and moved the world when the player moved. You would also need incredibly gigantic terrain to see issues with fpn's.
What we can do, which is what I was leaning towards with terrain tile streaming, is have large tiles of terrain where each one is a terrain quad tree, then load in the tile you are on and all the nearby neighbours as well, similar to how google maps works. Then that way it could re-center the terrain at (0,0,0). But the rest of your models would have to be in relative coordinates too. It would be quite a major task and would have to encompass your whole app.
ivanpg said:
Oh, great!!! It will be fantastic.
When do you think will be available?

errr, tonight I think. I was hoping for last night to get it into the code base but I found some patches I made and I have to apply them first to the existing jme3 code before I can merge it in. I tried to get it all ready this morning but started getting late for work :)
Sploreg said:
In short, no. But most of JME would have to change to support that, unless you completely centered the world on (0,0,0) and moved the world when the player moved. You would also need incredibly gigantic terrain to see issues with fpn's.
What we can do, which is what I was leaning towards with terrain tile streaming, is have large tiles of terrain where each one is a terrain quad tree, then load in the tile you are on and all the nearby neighbours as well, similar to how google maps works. Then that way it could re-center the terrain at (0,0,0). But the rest of your models would have to be in relative coordinates too. It would be quite a major task and would have to encompass your whole app.

Jme 2 was fine - see skapeworld.com
Dont know how you refernce your tile ( terrain blocks ) but presume they are on some sort of grid system, this is all you need to relate your coordiantes to. Its a fail for MMO's without