There are a few threads floating around with suggestions to overhaul terrain.
In Particular
http://www.jmonkeyengine.com/jmeforum/index.php?topic=3098.msg33354#msg33354
http://www.jmonkeyengine.com/jmeforum/index.php?topic=5071.0
http://www.jmonkeyengine.com/jmeforum/index.php?topic=4146.30;topicseen
http://www.jmonkeyengine.com/jmeforum/index.php?topic=4637.0
Llama's terrain is really nice, and would like to have a stab at putting some of the features in that Llama hasnt time to do.
Would hate to start doing something that someone else has started, so please say if you have started on anything.
What are your thoughts on what is needed for Terrain.
Of course I wuold like to see a fine tuned DLOD Terrain. llama Terrain engine and Terra seem to be quite good about this point.
But what I really like to see would be Terrain capable to load a terrain block geometry from a raw text file or a raw binary file, where heightmaps are stored as list of heights or vertices, as an alternative to bitmap heightmaps or procedural generated heightmaps.
I am also interested in Terrain Engines. I and one of the developers of the project, I am working on, could try to help you someway, if you agree.
But the fact is that we do not know so many things about DLOD algorithms.
Good to hear Ender, happy to work together.
Agree that the texturing should be separate.
I like what BlackBlueGL and hevee produced for texturing, not sure which method we should go for. Renanse was also mentioning that he has been working on a system too, using an alpha and an opaque layer.
The hightmap can be stored very efficiently if it is stored as a byte array, simply put, why use 4 bytes for an int if the max height is 128, thats a waste of 3 bytes. Likewise if the maximum height were 256 then it is a waste of 2 bytes and 7 bits. Helps to keep the file size down. It can also be wrapped with compression. Not sure if this satisfies what you wanted in a raw binary file.
It's very easy to write a different loader (eg one that reads bytes instead of ints) for my terrain. If you want use compression you could also handle this in the compression layer.
Personally I don't think it's worth it to use anything other than int for internal handeling though (keeps things consistent for everyone).
Happy to know that, llama. I had ever had the time to deep explore your TE, so I was not able to say if a raw loader was possible.
About the use of int or float or byte (or anything else) I just have to say that my aim is to be able to draw terrains in Blender (or any other 3D modeling tool) and export them as raw data (or any other interesting format) to be loaded in jME. Considering that modeling tools export vertices values as float values, I think that a Terrain Block constructor based on a raw data loader should support float height maps. In alternative we should create a conversion code to translate float values from the loaded file into int values that keep same proportionality.
Speaking on behalf of Llama ( no animal noises intended )
the Te is LGPL licensed, which means you don't really need permission to change, as long as you release the code changes you make under the same license
Lllama has expressed that it would be nice to integrate in using shaders to avoid "popping" when a block changes to another LOD level.
a list of what is needed can be found here
http://www.jmonkeyengine.com/jmeforum/index.php?topic=3098.0
Although im not usre how up to date this is.
If anyone wants to do any work, best to mention here to avoid duplication
I don't think a thread in the "feature request" forum is the best place, so I made a new one:
http://www.jmonkeyengine.com/jmeforum/index.php?topic=5170
[OT] Ah, ah, ah, ah! 
So, jME Terra and llama terrain engine are exactly the same thing!
I believed that they were 2 different engines.
I never noticed that the links wich point to the posts in jME forum point to the llama terrain engine posts. I just downloaded the source from the jME Terra site… XD XD XD XD :// :// :// :// ://
theprism said:
The hightmap can be stored very efficiently if it is stored as a byte array, simply put, why use 4 bytes for an int if the max height is 128, thats a waste of 3 bytes.
I'm curious about why people are not using floating point numbers for representing terrain heights. With even a bit more varied and larger terrain, bytes (and to a lesser degree integers) are terribly restrictive. That's one reason why I started writing an own terrain renderer instead of using the built in JME one.
I can see that if greyscale bitmaps are used to represent data, then that data is in byte format. However, other kinds of data sources could be used too, that don't have this restriction.
-- zzorn