jMonkeyEngine.org

Hello everyone
I've been thinking about a Terrain system for JME 3. Currently the TerrainPage system in JME2 isn't quite enough.
It needs to be more scalable and handle LOD (Level Of Detail), and probably stream from disk.

There are a few systems out there implemented in the open source world that we might be able to borrow or convert to java/JME3. But before that, it would be a good idea to get some requirements or capabilities that the community would like to have in this terrain system.
One thing that goes hand-in-hand with a terrain system is an editor. Being able to paint onto terrain and modify the height on-the-fly is key, and I know many people have had to implement this on their own; lacking one built right into JME. I have a simple map editor that does this, but it severely lacks optimization that is greatly needed when the terrain and textures (alpha splatting) get quite large. So editing terrain is one thing to keep in mind when thinking of the terrain system.
It also brings into the arena the idea of an embedded JME3 map editor. Erlend_sh has been kind enough to throw a few ideas and projects my way to look at, and one of those that caught my eye was SceneWorker. I've only just glanced at at so far.

Here are a list of a few requirements for a Terrain System that I think are important. Please supply any other requirements you think should be there too:
- LOD: something along the lines of Geo MipMapping.
- Streaming terrain: load large areas of terrain off the disk on the fly, allowing for very, very large terrains.
- Texture splatting: scalable to very large terrains and maintaining a fair level of detail and speed for modification
- Height modification in real time
- Sub-section Frustum culling, similar to TerrainPages

I just want to get the conversation started here. I am by no means an expert in this area, but I hope that a few of you are and can help on this. I plan to rewrite my existing terrain system into something better and might as well include it directly into JME3. So if you have any ideas, or have worked on this sort of thing before, lets get talking.

cheers,
Sploreg

sepending on difficulty it would be nice to allow not only horizontal, but also vertical terrain block (or whatever we use then)

Possible uses are larger mountains that are otherwise impossible  or real planets (Flight simulator)

@sploreg: I suggest you look at the beginnings of momokos terrain system and see how you could improve it with your existing knowledge/code. About in-game editing.. Plans are emerging to add a graphical development environment based on the NetBeans Platform to jme3, so some kind of editor for the terrain-maps in that would be nice, but I also think that most of the time it should not be necessary to be able to modify the terrain at runtime..

How about borrowing some ideas from here: http://www-evasion.imag.fr/Membres/Eric.Bruneton/

Yes I kinda think taht hughe montains or larger citys can benfeit quite from it , aka set the internal of each hause over ground floot in the enxt box, and when used in lod mode, only the outside is loaded.

Or a huge Mountain area, I just think that implementing it is (hopefully) only a bit more complicated, but several users might benefit from it.

jME3 might support geometry shader but it isn't recommended since it will require a high-end card. You'll need a fallback approach. jME3's minimum requirements are Pixel Shader 2.0, GLSL100, or OpenGL2 (all the same thing basically).

zathras said:
Continuous Terrain – An array of 9 terrainblocks arranged in a square. The outer ones are "dormant". The player is always on the middle, active one. If the player ever steps over from the middle terrainblock to one of the other 8, the three terrainblocks behind him detach, and re-attach to the array in front of him — and the player is, again, on the middle one of the 9. This way you can walk forever and never fall off the edge, or hit a wall.

Sure thing. But remember, if you don't want to use this feature, you shouldn't have to.

zathras said:
Cave entrances! I'm a sucker for adventures with secret entrances and hidden passages… X-D But of course traditional heightmap based terrains cannot have any holes… I tried many crazy things, such as arranging several 4 or 9 terrains with gaps inbetween, and then filling the gaps with custom 3-d models of a floor with a cave entrance to the cave model below… Didn't look all that convincing, but maybe you guys have a better solution? Am I the only one who likes terrains with caves?

I think simply placing models on top is enough, or at least, that's how most people do it. Consider that more advanced solutions (e.g using metaballs style editing) is much harder to implement.

zathras said:
Procedural Detail Textures: When I use procedural textures, I never get around the blurriness. If I add a detailtexture, it's the same detail for the whole terrain (e.g., my snow covered mountain tops suddenly have a rock pattern…) Am I using wrong parameters? Is there a better way?

I think what you want is texture splatting. It gives much better results than the default jme terrain texturing. Here's a screenshot.

zathras said:
Float Arrays: When I create a custom terrain from a float array, I have no heightmap object… If I had one, I could give the custom terrain a procedural texture. Can you let the ProceduralTextureGenerator accepts raw float arrays?

jME3 does not have this class But there might be some that will generate an alphamap for splatting, in that case I suppose supporting float arrays should be possible.