QUESTION Good workflow for area extraction by DEM?

Hi, as I am working on turning the old airport race in my hometown into a racetrack and would love to incorporate another track nearby, as well as some mountain roads, (...), I started to play around in my head if a proper regional approach would make sense. As I believe I can't be the only person do ever have considered such a thing (I know some large freeroam maps exist for AC, even though I rarely use them), I'd love to ask how well this would work from experience users' perspective - my area of knowledge is mostly geodata, so perhaps what I'm going on about is not well-known in all aspects, but perhaps there are things that I'm totally overlooking.
My approach for creating a huge driveable map would be:

a) Find a vector file for driveable roads. In my case, the "Hochrangiges Straßennetz" (high ranking road-network)-Layer as published by the local government seems perfect, it includes regional roads such as mountain passes, and nothing else, not suburban streets etc.

Now for my area, 1m-resolution aerial lidar scans (DSM and DEM - surface and elevation/terrain models, as in with/without trees and buildings) are available for free, as well as 0.25m resolution orthophotos -which seem to be both better resolution and more consistant in terms of color/season of recording (=how far up does the snow start) than the google ones, but they are after all only 2.5D by nature, meaning no overhangs or actual vertical walls. There are a few artifacts, but with 1-m resolution, I believe an automatic road generation is feasible and usable for the track based on this data - for comparison, please note how the airfield looks in this data, with high surface gloss applied to make (un)evenness visible. I think just by that representation of the full-res mesh from the 1m-DSM via cloudcompare that the runway and taxiways+parking areas would be quite driveable, the grassy regions on the right not so much.:

So the approach I'd take would be the following:
===Terrain===
- Create an even grid to split up the entire region in three LODs (max, medium, min): 1m, 4m, 10m - each with 250 pixel, so 250x250m, 1000x1000m, 2500x2500m in size - makes it quite understandable which grid you're looking at from the coordinates alone.
- Find out which grids are within 500 (max LOD) or 2000m (medium LOD) of the track - as in, buffer the track lines with 500 and 2000m width and find intersecting grids, meaning "it will be very/medium close to the track since it's within the buffer zone"-> these get generated.
[Optional: I think some slight decimation might give good results, after all we're not after scientific precision for these non-driveable areas]
- Generate DEM and DSM + Orthophoto (I think at that scale, 1024x1024px will suffice-> that's 2.5m resolution for stuff that's further than 2km away, I think that's more than high quality.. perhaps I should actually introduce a fourth "ultra-far" LOD) for the entire region in question; that minimum should at any rate be available for the entire region.
- Where available, this can be aided by Google 3d buildings via blosm (works well for Innsbruck, not so much for villages in valleys around), and then of course receive all the trackmodding care one could give it.

==Road and nearby surfaces===
For this, we can use our grids but sample only those parts that are within a 25m buffer of the road path (that is plenty wide even for the Autobahn):

These can then be further smoothed and analyzed, perhaps classified by "smooth dark road", "rough medium road" "road shoulder unpaved" etc. according to roughness and visual appearance (semi-automatic classification plugin might work very well), and can be used to generate the physical road meshes with a matching color texture. Smarter ways may exist to separate this into distinct parts, but splitting it by those same max-LOD 250x250 meshes will be enough for starters, and will leave plenty of room for manual smoothing and subdivision.

So that's what I've been thinking about trying for a small-ish region, would go about it by py-scripts, using only free data and software and share that here - any hints or comments on that process?

 

First try of pumping absolutely buttnaked public data into AC: Doesn't feel terrible to drive. A tiny bit of bumpiness, but certainly ok. The landscape looks comical though, but that can always be fixed.

 

So as a rule of thumb, you dont just shove the data on to the game (for a variety of reasons); instead you use the data as the reference to build a track on top of. Personally i havent found a good way to do automatic road generation, you still have to deal with the "deformations" at the edges of the track.

Here's a link to lilskis tutorials, not the only approach but it shold give you an idea of what the process is like:
(the relevant stuff starts at 19:30)

 

Haha yes I know this won't generate beautiful track sections without further work - a handcrafted approach is what I'm using for the airport at the moment, and I know how much time it takes just to get the shape of kerbs right for driving feel, let alone make objects look nice - but what I'm talking about here is not so much about having a plug-and-play automatic track generation, but to have a) good efficient terrain generation, which I need for every track idea in the region anyways and would therefore like to be repeatable, and b) generate a first-version drivable surface. With 1m spatial resolution and a well-cleaned input file, this seems not too impossible in general, yes a mountain road will be on average 1m narrower in terms of flat surface than real life due to the sampling resolution, but it's absolutely no comparison to what google generates at that region - for starters, the road is actually sort of horizontal .
Here's the unchanged road mesh on a mountain road, just as it comes out of this workflow, that's about the quality this generates everywhere I checked. Yes there is some unevenness, but I'd consider this workable even like that, and automatic smoothing + reworking in selected places (BEFORE turning into a mesh - this may be done very efficiently in 2.5D) will take this to a smooth-as-silk road surface, or am I completely off there?

And the semi-automatic classification I have in mind (based on visible, infrared, and topographical information such as slope, curvature and roughness indices etc.) can actually recognize, for example, areas with broken-up surface, tarmac patches or features like the little makeshift parking-bay in the middle of the screenshot above, and of course recognize overgrown/rocky areas as such - and with such classification, I suppose from my limited blender knowledge that there must exist a way to apply different high-res materials to such different classes of surface. Additionally, knowing the basic orientation of the road from the vector format, it should be possible to match the center-line markers and generate a basic road texture there. That is the area I would need most help though, working with textures is sort of alien for me .

At any rate, again, this should give a basic visual representation of transit sections between handcrafted parts (in my case: historic airport race, historic hillclimb, and fictional circuit - all within like 5min of driving from each other IRL) that has a few advantages over using google terrain (better resolution overall, and more consistant in terms of terrain color and detailling), is entirely scriptable and hopefully results in performant-enough output, by generating the LOD descriptors for the literally thousands of little tiles this will generate over a larger area.

I cobbled together a script for the first steps (generating DEM and orthophoto tiles in various LODs from single-file input rasters and a shp of the required roads) yesterday, am overworking it to grab it's data directly from the governmental WCS server instead of downloading it first (had to wait 2 hours to download the full-res orthophoto data yesterday and then noticed that the selected extent was slightly off, am not too keen to repeat just in order to split it into several parts and download them all at reduced resolution), but am glad to share if someone's interested.

 

looks good! personally i like to snip out the sections of the road i want to drive, then make my road mesh and smooth that out, not the data itself. This is partially because blender sucks at handling large meshes but more importantly because this way i dont smooth out important features unknowingly. If your classification can deal with that then you're good.

This was hard to wrap my head around at first but there are many useful tutorials around here and elsewhere on how to do materials for AC...

These two cover some more advanced shaders but are good to keep around while you get used to the workflow:
( https://assettocorsamods.net/threads/photo-quality-road-surface.834/ )
( https://assettocorsamods.net/threads/kyalami-2016.1477/page-6#post-10562 )

The main job in blender regarding this is assigning materials to meshes and uv mapping said meshes, the rest will be only for visualization purposes. For assetto corsa, shaders and textures will be assigned via the ac editor; any textures you've assigned inside blender wont be carried over so you'll have to reassign them.
Another thing to note is that ac only does one material per object, so you'll want to split objects by their relevant materials. It is possible, but trickier, to fake having multiple materials per object using the multylayer shaders discussed in the links above, though...

This is the bit that sounds worrying but only because I dont think you mentioned what your plan regarding visual/phisical surfaces is. My bad if you did but just in case, i'll mention here that ideally you'll split the surfaces youre driving on into visual low poly meshes and physical high detail ones. This is because object count is the biggest performance killer in assetto, and it gets even worse when those objects also have physical properties (collision or driveability).

So the visual meshes are meant to cover as much ground as possible. In some mid size (4km-ish) tracks you can even have a single object acting as the visual road surface; 10 to 20k triangles with enough detail for curves to look smooth and cars to not look like they're dipping into the ground or floating above it too much. Of course the lods will come in handy too.

On the other end, having physical surfaces made out of those thousand of tiles from your elevation data can actually work because physical meshes are not meant to be rendered and work better when they're around 10k triangles and no longer than... some radius that i cant remember right now. You can also try with denser meshes but at some point they will start to glitch out and your cars can start falling off the floor or flying of suddenly and violently.

speaking of kerbs, are you aware of the "kerb of dead" problem that these games (ac and rf2 at least) suffer from? don't know what kind of kerb your track will use but it might be relevant.
Basically sharp edges dont drive as they should, so to get proper feedback out of a sawtooth kerb for example, you would need to make the physicall kerb much smoother than the visual counterpart.

 

Thanks for the reply, that is indeed helpful - even though I've already gotten quite a few things done with the primary project (ported the Innsbruck airport over from neteye's Race07 track and got it halfway driveable, and out of the initial phase of "everything looks wrong", including moving trees and grass fx)- but there's a long way to go to just get it up to the standard of the original race07 track, including animations, blinking lights and so on - not to mention generating good AI lines. Even after a couple weeks of doing this, I'm still missing out on a lot of basics, such as "what shader to use to make this fence see-through, but also show the other see-through object behind it" (I made it work but have no idea why it works) and "what is a good way to see how the material actually looks in blender, before exporting it and then noticing it's completely wrong" - yes there are loads of tutorials and those asphalt shader effects you linked I'll definitely try to incorporate, but there isn't by any chance a good actual documentation file or wiki for the ks_editor detailling the effects of all settings that I just click randomly, is there?

I wasn't explicitly, but I noticed that the original kerb shapes that absolutely worked for the Race07 track (including some smaller portable kerb-circle objects used for makeshift chicanes, so it's not just an alignment issue) send my car into low-earth orbit So I started the work separating each kerb into vertex groups (inside, mid, outside) and shrinkwrapping them to different offsets to the ground plane.. and for some reasons, some kerbs still feel a lot smoother than others, at seemingly the same steepness and height... Think I'll have to redo them completely, and at the same time learn proper 3d modelling procedures for tracked objects...


For this script, yesterday I coded it so far that it takes just a line shapefile as input, separates the landscape into manageable-for-AC grid cells, downloads the terrain+orthophoto data from governmental WCS (which is also available for many other local administrations, so this script might be useful to others who're not all that interested in Tirol ), and derives the road terrain model (so far, simply "all terrain within 25m of the road centerline"), and then a second script imports each terrain and road tile into a mesh via blendergis, names it accordingly (1ROAD_xxx for the road tiles and dem_xxx for the ) with the orthophotos applied as texture (looking good in blender at least).. It also applies some slight gaussian smoothing on the road terrain models before generating the road mesh - the result is now indeed silky-smooth to drive (as soon as I figured that my experiments with additional subdividing/decimating these meshes caused fall-through glitches as you describe - they're best left 'as out of the box', so far). Just for reference: These are 250m by 250m tiles, so for my testcase of about 1km of winding road this generates 7 separate physical road tiles, most containing about 20-30k vertices, and some that were barely touched which contain only <10k. I think that's about right, isn't it?

In general, I think I can reduce the smoothing to retain more detail; the testcase is my favorite corner sequence on the after-work motorbike road, which I know is quite smooth, but actually not THAT smooth in all places IRL. I also experimented with ways to do auto-segmentation, the idea there is to split both visible and physical meshes into road/non-road first to apply HQ textures and grass fx for the visual meshes (maybe including the detection confidence etc. to introduce naturalistic variation), and split the physicals into different surfaces meshes (ROAD, GRASS..). I think such an approach might work out quite well for a basic ground representation. Then there's the problems of trees, houses, and road barriers, but that'll be left for later. Generating a treeless, humanless mountain-desert with suicide roads suits me well right now, when reality in the roads in the area look a whole lot more like this :


The biggest problem so far, even though the materials are named in blender according to the orthophoto (object "dem_17" gets material "ortho_17", which corresponds to texture file "ortho_17.png" in the texture folder"), when I open the fbx in ks_editor, all the textures are missing and I need to tell them where to find the texture files by hand... for all 128 tiles . Even writing the filenames with/without the texture directory into the persistance file didn't work...
Does one have to live with that and manually select hundreds of textures at least once when generating a new track, or did I simply miss a big "duh!" yesterday before going to bed?

Yes, that's the plan - basically I'll retain the full-res (1m) physical meshes only within 25m of the designated track, switched to non-renderable, and add visible meshes with decreasing sampling resolution, corresponding to their distance to the track .

On the issue of performance, in this testcase, the hundreds to thousands of visual tiles for the further-away terrain (mountains at >2.5km distance) just contain like 4k vertices each natively (even sampling), and I could easily decimate them further in an additional step, so it's hopefully not overkill in terms of processing demands...Trying this out (as far as I got with the manual texture-assignment yesterday, so using probably like 30 tiles) it seemed fine - even though my machine has probably more RAM/VRAM than average and I shouldn't take for granted that "if it works for me, it will work for everyone"...

 

If I got you correctly there, it might also make sense to actually re-combine these strictly visual terrain meshes into larger ones to reduce object count - is that also a good solution in terms of how AC handles LOD?? Have to say I didn't quite get it, and my experiments with setting LOD within ks editor were a bit hard to interpret either - with some objects such as 50m cubes it worked as intended, with large terrain meshes it was unpredictable whether the LOD-in and -out did anything at all..

The basic question I couldn't get the answer to: Is the LOD handling for large objects triggered by distance to origin or distance to mesh, and is it possible to load/unload parts of an object by that mechanic? For example, if I position a line of 100 high-quality cones along my 2km main straight as one "cones" object, will they all get displayed as high quality a) once I'm close to the first cone, b) once I'm close to the middle/origin of the whole line, or is there a way to c) let AC decide if specific cones should be visible as high- or low?
And is the overall object count in fact more important than the visible poly count (I think it shouldn't, theoretically the render engine probably shouldn't care whether it's rendering 1000 cube objects containing 8 vertices each or an object containing 1000 such cubes with 8000 vertices in total - but it could very well be, there are all kinds of weirdnesses going on with game engines I suppose)?
I mean, the mountainous landscape here presents it's own visibility filter that isn't quite so much distance-related, after each corner there is a different part of the landscape visibile and another one moves out of sight - so I hope that can also take care of the visible-right-now-polygon-count to some extent.


Otherwise, I could come up with a rather straightforward algorithm for all my basic terrain needs, if LOD doesn't matter or doesn't properly work anyways:
- Create 250x250m grid within, say, 50km radius of track ->more than 125k cells, that's a bit much obviously
- calculate mean distance to track for each grid cell
- determine if grid cell is possibly visible (function of elevation difference and distance to track, based simply on earth curvature, with no regards to sightline) -> remove if impossible to see, that'll take care of about half the grid cells I suppose;
[- optionally: determine "probable sightline" between track and grid using really crude sightline analysis based on whole cells - if improbable that the cell is visible, reduce resolution by half, or delete altogether]
- download or downsample to the corresponding resolution/detail level (if we say 1m resolution is fine at 1km distance, a mountain peak at 50km away might just as well get sampled at 50m resolution for the same angular resolution, so that's a 25-vertex mesh for that 250x250m grid size);
- iterate over the available grids starting from the lowest-res ones, to combine them with their next-lowest-poly neighbours into larger objects as much as possible (naturally resulting into some mountain-peak islands, a lot of coherent, large terrain regions at high distance, and lots of small terrain objects close to the track)
-take care of boundaries, deletion of double vertices etc. within the meshes
-done.

 

The "combination of lower-poly meshes into one" script basically works now, and the problem about the ks_editor export was caused by me importing the orthophotos via blendergis as .tifs (georeferenced), and of course KS_editor would prefer them in a different format. So a quick script to replace all material file references in blender before export from .tif to .jpg fixed that. But I won't deal with piping it into AC right now, it's sleep-o-clock.
Looking forward to driving this again (both for real and in-sim)

 

Did some additional work yesterday. I think it's time to post the feature-set on that script, or rather, group of scripts. If anyone wants to try, I'll PM them, or upload it here soon once I have the minimum feature set worked out - am posting this mostly to keep myself somewhat organized by later editing what I achieved, but sure am happy to get feedback and ideas.

What it does so far:

Generate overview:
- uses only a correctly georeferenced road SHP for track-specific input (which the user draws/copies from external sources in a tool like QGIS), and needs to know where to find other data, primarily terrain model and orthophoto.
- generate a constant-size cell grid around this shape (default: 250x250m cells, within 30km of track-> 120x120=14400 cells, which gets reduced a lot in the following steps; for a small test-track I yesterday arrived at <200 terrain cell-groups)
- configurable Level of detail settings (resolution of physical mesh and of visual orthophoto per level, applicability of levels generally determined by each cells' distance to track. Full resolution - in my case, 1m/px DEM, 0.2m/px orthophoto- goes out to 1km away from track, and gets way downsampled further away)
- checks visibility (line of sight from track) of area in a rather quick way (working on a very-low-res terrain raster: 1 elevation value per cell) and only works on cells that are in fact visible; upgrades level of detail for cells that are most often visible and decreases level for cells that are rarely visible.
- combines neighbourhoods of cells of the same LOD into groups, if their combined amount of vertices stays below a set threshold, to reduce region count -> from thousands to hundreds of terrain objects, all speaking for mountainous regions.
- allows manual modification to include/exclude/change LOD of specific cells, before further processing

Retrieve and split 2.5D data:
- download terrain and orthophoto for all cell-groups; configurable to use different sources, if maybe the area is covered by different local authorities, or if user wants to use a different source for some detail-level or region - maybe orthophoto A was taken in summer, except for one part which was taken in fall, and orthophotoB was taken in summer but has generally worse resolution so it should only be used to fill "discolored parts".
- downloads the data for the physical mesh at full resolution; this area-of-interest is defined as within a certain distance (default: 25m) from the road-defining input shape
- smooth the track data the physical mesh gets based on [not yet: in a way that nicely deals with the "outter part of the road gets undrivably invaded by the hill-side bank" effect from the sampling resolution]
[not yet : - segment this data using AI/image recognition into road/nonroad; further segmentation could make sense for further modelling, such as road: (smooth, mediocre, rough, gravel, dirtpath); nonroad: (grass, dirt, woodland, rock)]
- generate normal maps from DEM and .jpgs from Orthophotos for use in blender

Import and process 3D data:
- blendergis: import DEMs and apply orthophotos (from .tif for correct geo-referencing)
- rename materials and set image to .jpg version, which gets carried over to KS-Editor (no more manual setting of hundreds of orthophotos!)
- rename physical meshes to 1[SURFACE]
- apply all modifiers to physical meshes, to work with actual vertices
- remove all vertices with z below threshold (=no-data values, artifacts/unwanted sideeffect of road mesh generation )
[not yes: Application of high-res materials to visual meshes - probably best to base these on the physical meshes, and cut away the terrain meshes where these exist]
[not yet: automatic decimation of objects according to their point content and other criteria, while leaving the boundaries to other meshes intact and pretty-looking]
[not yet: further reduction of points within the cells that are clearly invisible from the track, as in with normals definitely pointing away from all track positions]
[not yet: sorting different LODs into separate collections - for some reason I couldn't come up with a working way to do this yet, even after trying for 1.5h with the "help" of chatGPT (can't that thing just say so if it has absolutely no clue?)

=> Add the basic AC_-objects, there you go - ready to start manual modding on, or export it to KS-Editor as distant terrain.

Stuff that would be nice in the future:

- Generate the AC required objects (AC_Start_0, AC_HOTLAP_START_0) in adequate positions (longest straight, if circuit? Start/end of line in A-to-B road?)
- Use detected surfaces and other layers such as forest coverage to spawn scenery objects like trees, road markings and road barriers (on mountain roads, that's basically the biggest hindrance to enjoyment - it's suddenly become really hard to even just survive a 1km hillclimb sprint )

 

Quick update: This now splits up the terrain into 7 levels of detail, selects the cells to display according to visibility for each point on the track, and imports them into blender. Which of course would be pretty much impossible to do by hand for this terrain.

 

So yes, this works a whole lot better now - some artifacts between the close terrain, which doesn't use 3d-"trees" (simply the elevation profile, as if one draped a green canvas over the treetops, not a real 3d tree object) as part of the landscape and the far-away terrain which does - but that's solvable I'm sure, either in blender or in the 2.5D geotiffs.
Gone to 2.7 million vertices on terrain only by now, which I guess is less than ideal, but it's, well, an interesting situation in terms of how far you can see on this track (the far east and far west last visible points are about 100km apart from each other).

 

thanks! yes I was a bit surprised how well it looks in that light myself... I think it's starting to get worthwhile to publish as scripts with at least minimal documentation, as it could be maybe a useful addition in some places - for example, Switzerland and South Tyrol (both not known for having permanent race tracks, but definitely some of the best driving roads in the world) offer to the public 0.5m resolution terrain models and 10cm orthophoto for free, which I suppose is really really usable out of the box.

Here's perhaps a basic explanation of what use I actually have in mind for this:
If you just wanted to recreate, for example, Nufenenpass or Penserjoch, which are some of my favorite driving roads, in RacetrackBuilder (a tool which I never tried but I take it uses Google data to provide a global dataset?), then I'd guess that the resulting terrain model in these remote locations must be just as crude and will result in similarly undriveable roads, as Google provides in my homeregion Tirol (tried that through blosm->blender); simply looking at the foreground in the following screenshots out of Google Earth - the road is of course visible in the orthophoto, this one looks quite nice in terms of texture detail, but the terrain model just doesn't have the resolution to show the road as near-horizontal, one doesn't have to start up a sim to know the white car on the right of this image would slide off the road:

This lack of detail most visibly and consistantly affects the side-to-side angle, but if you look at this screenshot showing Nufenenpass, this waviness along the road behind the big white bus is simply not there, in reality this section is cut into the rock and widened towards the valley-side, giving it a very comfortable width and even a bit of run-off-area:


for comparison, starting around 23:50:


Such details (can one even call this a "detail", it seems more like a "central aspect" of how that road is to drive) may get mangled up completely in the Google terrain.

And obviously, if you want to keep the beautiful background data alive there, by applying a very large radius using one common resolution (again, one can quite distinctly see stuff that is 30, 50, in some cases even 100km away when on a >2000m alpine pass), probably decimating the remote meshes by hand to somehow get all the landscape stuffed into the model, then I can only foresee this becoming a terrible compromise between detail and performance - and very importantly, the creator's time and effort, going through square kilometers of landscape by hand trying to see which parts can be deleted as they are never visible, or kept less detailled etc., and having to potentially redo all parts of their actual road layout, if they are based on such mangled terrain as this Nufenenpass example.

Which is what my script is about, creating a couple hundred meshes with orthophotos and normal maps applied so we get around the limitations of the AC engine, all detailled and decimated according to their distance to the track and their actual visibility.

 

Hey there I just started a project of a test-center and kart-track in South-Tirol and didn't know about the free 10cm ortho, so thanks already.
Just wanted to ask if its smart to use the DEM as a reference to make the track and then use Blender-GIS/OSM for the landscape?

 

Hello Romeo, have to admit, I was a bit quick to call it a 10cm free orthophoto for South Tyrol - the region-wide ortho is "just" a 20cm one, they offer better resolution only in some places and obviously they have better material available not for public eyes (yet) in some regions with "interesting" geotechnical/natural hazard activity. If this kart track you're talking about is the one south of Bozen, near Pfatten/Vadena, then I think the resolution (not specified) might even be better than 10cm according to this quick test, measuring the width of the center marker which is surely more than one pixel wide in this very zoomed-in image:

That's the WMS layer "Orthofoto Gemeinden 2017 - Ortofoto comunale 2017"
from server http://geoservices.buergernetz.bz.it/mapproxy/ows (link for GIS)


I don't know if it's the smartest to use a DEM to base the track on, perhaps someone else with more experience than me in track-building want to chime in (which is pretty much everyone on this forum), for me it's the more natural way to say "I want to recreate a real place accurately, let's start it using the most accurate real-world terrain data available and smooth it out(=remove detail) where it doesn't feel good or becomes too demanding in the game". I think the other way around (starting with an abstract terrain and adding detail in places from different sources such as personal driving observation, videos, artistic intuition...) is probably way more efficient, and can also result in a very convincing track - and if one doesn't know how to get such data or if it's not available whatsoever, then it's the only way.

If you like and want to try out my way to generate the terrain for the surroundings, I can of course pass you my code so you can be my first vict... umm, test user .

 

Chiming in on this topic...

To build a proper race track environment, its always best to use the most accurate data available.

But there are confusing types of data out there... and its important to know the difference when looking them up.

DEM for example is bare earth. and it does not include intensity data, which is sort of a satellite image baked in to the data. Which is fine to use, but you'll need to overlay your own satellite image, requiring some distortion correction. DEM is a good option sometimes since there will be no trees or objects, its really just earth.

LAS / LAZ: common and preferred aerial lidar data, includes intensity data. Easiest to use. Sometimes will need a bit of cleaning up - like removing trees and such.

Blender GIS: Uses SRTM data, which is not good enough to build on, but does serve a good purpose for a distant lanscape mesh.

Google 3D: Certain areas of google maps are photographed by plane, not satellite, resulting in a very cool 3D look. Process called photogrammetry. Its accuracy is close to lidar methods and can be imported into blender by using RenderDoc and a plugin.


At the end of the day, none of these are good enough to import and drive directly on. They only serve the purpose of a reference to build on top of.

 

Exactly im rebuilding the SafetyPark south of Bozen.

What Johnr777 said is pretty much my plan. I'll use the DEM just as a reference to get the basic elevation to build my own roads and terrain on top and the GIS/OSM for the mountains around.

Also I believe the ortho is already a corrected satellite image, correct me if I'm wrong.

 

Just an addition to what Johnr777 said:
There are often (as in the case of all named localities) two version of DEM provided (which is the generic term for any raster holding elevation information) - a DTM ("digital terrain model", german "Geländemodell"), which is exactly what he describes, basically a regular raster with ground elevation, cleaned of vegetation and buildings; and usually also a DSM ("digital surface model", german "Oberflächenmodell"), which does actually contain the peak heights of trees and buildings - in some instances, it may be "cleaned up" a bit, around meadows and agriculatural fields for example, or around objects such as power lines, but generally it depicts the terrain including the objects on it. If one turns it into a 3d mesh, this may look funny close-up (as it's 2.5D data, meaning no overhangs - trees are therefore rendered basically a cylinders or cones, see my earlier experiment with the silver Porsche 718), but I found that it works really well to depict trees and houses on a mountain several kilometers away, i.e. generating a realistic-enough rough silhouette again the sky without the need to spray 100000 tree objects all over your map (see the later experiment with the yellow Cayman GT4).Here to the right is the difference between using the surface model (left) and the terrain model (right), which I use closer to my track to have the room to put more realistic models there. Also visible are the gaps in the meshes, in those regions which the script calculated as impossible to see from the track.

The advantage of such 2.5D objects is that you can VERY easily and quickly apply operations to a huge area, as long as this can be treated this as one coherent surface with no overhangs- as a road would indeed be, excluding bridges.


The DEM and orthophoto data the local administrations provide are actually usually derived from aerial (=plane) LIDAR and photographic surveys, meaning they often reach far better accuracy than continental-scale satellite surveys.

And one other addition to Johns overview: BlenderGIS doesn't only work with SRTM, it can import any DEM and orthophoto one wants, that's exactly how I pipe mine into blender - it does it not particularly elegant though (for example, nodata-handling is very incomplete, so I have to use a separate script to remove all nodata points from these meshes).

 

Interesting info regarding blenderGIS, but again, I only use it for far scenery, so 15m-30m accuracy is fine

 

Lots to catch up on :O

alpha is transparency, you will be using the alpha-test flag way more than alpha-blend.
Also, really annoying, the ks editor has a bug that doesn't allow it to save the alpha transparency flags so you'll have to set them in the persistence files manually or turn them on every time you use the editor...

make a material and set your textures in the shader editor, you can tweak the params in the bsdf node but remember the only mapping that the game uses is the uv map; any edit you make through vector math or other way is meaningless.

There's the pipeline document inside the game's sdk folder, but i dont remeber that going into much detail. Part of the problem is that generally the shaders and their parameters are not ac specific, but common gfx terms of the "old" diffuse workflow, so it's kinda common knowledge in most games what some if not most of these would mean. Then there's that one param (boh?) that literally means nothing
This is kinda why these forums exist, but you should also look at the values other content uses for their materials and maybe look up more info on the difuse workflow, tho it's harder to find now that that has been mosty replaced by pbr. (and I personally cant trust chatgpt)