Terrain size

I am still new to JME3 and am trying to create a first game. Right now I want to add terrain to my BasicGame. For this I follow jMonkeyEngine SDK: Terrain Editor :: jMonkeyEngine Docs

In there it says
Make sure you decide now how large you want your terrain to be and how detailed you want the textures to be as you cannot change it later on!

Thank you for the hint. But what considerations should I do for a reasonable terrain size? Do I need to know the complete extent of my scene? (in my case a lot will come from OpenStreetMap and thus is variable). Or will I be designing a tile that gets repeated over in the X-Z plane? How big is big? How big is small? What is the impact of my design choice?

Generating Terrain Entropies for LOD
What is LOD?

LOD stands for “levels of detail”. In practice this refers to a performance optimization that causes a Geometry to use more mesh indices when it’s close to the camera and fewer mesh indices when it’s further away.

1 Like

The sizing is all relative, so it does take some adjusting depending on your specific scene. In my case, players are about 5-8 units tall, and each terrain is size 512 with a 256 patch size ( so 4 patches per terrain ) and 512 size alpha map, and this seems to work well. But obviously this could differ for your specific scenario.

It looks like you’re currently using the SDK to generate a terrain, although you are likely better off creating a new Terrain with code and then procedurally set the height of each point in the terrain based off of data from OpenStreetMaps. This way it would also be really easy for you to play around with the different sizes and scales since you’ll be generating it instantly, rather than sculpting it by hand.

The warning for being careful about choosing sizing because it cannot change is aimed at people who sculpt a terrain by hand, in which case its best to play around with sizing and make a good final selection before you start work on the final draft. But even then it is not too difficult to write a utility to adjust a terrain’s size if you spent a lot of time on it and can’t recreate it easily.

Oh that one. Thank you for the explanation.
I meanwhile found something in the docs - might be nice if there were hyperlinks or a dictionary. For LOD it could point towards

Generating the terrain somehow sounds better since I was thinking hard about the total size I need (which depends on the exported OSM data). Currently I have no clue on that - is there a tutorial or sample that I could inspect?

I don’t know of any examples that do specifically what you want with OSM data, but this is a good example for creating a basic terrain with code

It sounds like you will want to create a new terrain for every square mile (or half mile, might take adjusting) of OSM data, and then you could also loop through every point in the terrain to use the setHeight() or adjustHeight() methods to set each point’s height based on the OSM data (assuming the OSM data contains altitude)


My code also created terrain geometry but just didn’t use JME’s built in stuff. You might be able to learn something from that, too.

I’m not a fan of JME’s terrain library at all so I personally avoid it whenever possible.

Having had a closer look at the OSM format there is a tag ‘ele’ that would indicate elevation above sea level. Unfortunately it is not filled in, at least for the snippet of our planet I am interested in. I also checked other sources of elevation but their granularity is not detailed enough to render terrain around bridges or tunnels.

For the really small snippet meaningful to me an almost flat surface can be assumed, and I may have to manually elevate roads going over a bridge. That’s when I thought going for a flat terrain would be a step ahead.

Having slept over it I now see it may be better to not automatically generate the scene based on OSM data but do a one-time-import, then add missing bits and pieces until it looks nice. A lot of work, not transferrable/scalable to other places but maybe easier for me at least as a beginner.

Yeah, even in the game prototype I was writing, the plan was always to use OSM just as a starter. (Eventually I’d have generated all of my own random terrain + morphology.)

I unfortunately never did a racing video once I added solid buildings but here is one with stuff just plastered to the ground:

You can see that even with real terrain elevation data that most things are pretty flat anyway. (I did raise the bridges over the road… we pass under one at 1:28… but I didn’t really meld them into the roadways or anything.)


True, it looks a bit odd. Especially crossings on the highway.
But your word is not entirely flat. I was surprised that at 1:28 you are going underneath something. Plus at 1:45 there is something like a bridge?

It is impressive how you added an authentic behaviour of other traffic on the roads. And I liked the end - really unexpected.

They are both bridges. I detect the bridges and just project them above the roadway but there is no intelligence to make nice slopes back to the road. Just steep hills.


I struggle a lot with scale and finding the right width for the roads and stuff. Seeing other cars on the road helped a lot and made driving around more interesting. OSM data doesn’t tell you much about the roads other than type and number of lanes. You have to do some interpretation to figure out how wide to make them.

Not sure what this means. The roads are plotted directly on the terrain but the terrain sometimes has better resolution than the road… so there is one point in the video where we briefly drive under the road. But mostly it works out.

In the real version I was going to use all of the data as a source for the IsoSurface stuff:

That’s based on a field function and then renders a continuous surface. So roads would have been projected into that and influenced the surface in both geometry and texture… instead of just being polygons on the ground.

But I end up with too many side projects and needed to get back to my main one.

1 Like