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.
The requirements are reasonable. I don't see why this would be difficult to implement. There's already a somewhat functional terrain API in SVN.
To me, runtime terrain modification isn't as important, I think it should be exposed from the API, but a full-blown in-game editor to me is at low priority right now.
@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…
Empire Phoenix: By vertical terrain block, do you mean having things like caves and cliffs?
SomethingNew: That HLSL terrain LOD system looks interesting. I'm definitely going to read up on it. I'm guessing it won't work with collision, since there are still gaps in the terrain, but maybe something can be done about that.
stoge: Thanks for the link. The terrain and effects there definitely look impressive! I've already started to dig into the code there.
As for real time editing. I think it is important if anyone wants to get a good looking terrain map out in a reasonable amount of time. Since I need real time editing anyways, I plan to work on it along side the static terrain code. I will dig into momoko's terrain system and see what I can do there to get started.
Keep any ideas or requirements coming, and thanks for the input thus far.
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.
Empire Phoenix: By vertical terrain block, do you mean having things like caves and cliffs?
If you want to do vertical terrain blocks this article by Nvidia is good too: http://http.developer.nvidia.com/GPUGems3/gpugems3_ch01.html But since JME3 won't be supporting OpenGL's version of a Geometry Shader (I assume), it won't be of much use.
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).
A new terrain system would really be valuable! A few features that come to mind:
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.
Cave entrances! I'm a sucker for adventures with secret entrances and hidden passages... XD 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?
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?
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?
Just brainstorming, maybe some of my ideas overlap with the aforementioned streaming and LOD ideas.
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... XD 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.
Hi, I'm new to this MonkeyEngine But I like the idea of a terrain supporting holes, one solution could be implementing holes through edges that do not line up and instead of a simple 9x9 grid have a 9x9 grid with 9x9 chunks within with 9x9 subchunks, this way you would get incredible detail and to make holes simply omit a chunk or subchunk, lets imagine eache subchunk is 1 metre square thats 81metres square per subchunk, 6,561 metres per chunk and 531,441 metres per grid of 9x9 map tiles.
