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?
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.
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)
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.
Thanks.
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.
