Blending airports into custom terrain

I am a few weeks into creating 10-meter mesh scenery for the United States (free and available at the link in my signature) and before I get too much further into the massive project, I would like to see if there is a way to get rid of the massive grade differences between the new scenery and the airport flatten polygon. It's not nearly as noticeable in flat areas, but some airports sit 100 feet or so above the surrounding terrain. It's especially an eyesore at larger airports like Lambert International in St. Louis, Mo.

I don't mind making a few custom airports here and there, but a million or so airports would take me about 15 lifetimes before users would have something that looks as good during takeoff/landing as it does from the air. Is there a certain program or series of steps I could take that would marry the edges somehow seamlessly? Any help would be tremendously appreciated!
 
Hi Chris:

Sometimes if a OP does not receive replies to a thread on a timely basis, it is because others do care, but are not quite yet ready to address a task they know is going to be complex and time consuming to explain.

There are a number of ways to do what you need- and want- to do, but all are rather involved.


Changing terrain in the vicinity of airports also requires changing airport infrastructure, approach code, and AFAIK, AI and Ground Vehicle Traffic code.

The learning curve for achieving those tasks semi-automatically via custom coded utility functions would itself be rather time consuming.


A CVX vector-based "Airport Elevation Correction" consisting of sloped flattens to blend existing default CVX vector flat / level 'central' airport boundary / background flattens into the surrounding terrain would only be the beginning of the task, and IMHO, if all the other parts of the entire task were not also completed, it would be the beginning of a "world of hurt" in negative feedback from FS end users.

This is the dilemma terrain mesh developers face, and user reviews make / break product popularity.

My available free time is necessarily committed to a number of personal matters for the next week or so, but perhaps later I may get a chance to explain a bit more what the above options might involve. :)

GaryGB
 
Last edited:
... if a OP does not receive replies to a thread on a timely basis, it is because others do care ...
No doubt. The folks here (you especially) have been so tremendously helpful and I am in no rush whatsoever. Plus almost everything I am asking about is on a gargantuan scale. Everyone has a million other things to do and I mostly wanted the peace of mind of knowing that after making significant progress in my high resolution terrain project that I wouldn't have to start completely over.

Boy, Gary, things look so good that I don't even mind the plateau airports. Except when your taildragger catches the dropoff of a taxiway and then you accidentally plummet to the bottom of an inescapable hole during your test run.
 
The past few days I've been playing with some 1/3 arc second tiles for the state of Colorado and on approach to KRIL yesterday AM I noticed I'd created a plateau that wasn't there before. I bought some payware mesh from FSGenesis years ago and one thing I remembered about it was that there were "holes" in the mesh where all the airports were located. I decided to give it a try and sure enough it fixed the plateau problem at KRIL. The "hole" lets the default mesh show through immediately around the airport so any problems with plateaus and crevices had to be problems prior to the mesh.

Workflow went something like this:

-extract all the airport bounds from the default CVXxxxx.bgls in the local area with CvxExtractor, import them into SBuilderX (I can't imagine how FSGenesis did this without CvxExtractor, there was no such thing in those days!)
-click out a larger circular polygon around one of the larger ones (I did "add map > from background" then made a 16-sided star on it in PhotoShop, then added it back into SBX to use the star as a template)
-in polygon mode ctrl+c the poly, then do ctrl+v... - the cursor turns into "place" and you can click anywhere to place as many copies as you want
-"place" a copy of the poly on (or near) each airport background, come back afterwards, center it over the airport, and delete the actual airport background
-export all the circles from SBX as .shp
-do the gdal_rasterize thing to burn all the circles onto a .tif (I made a macro in TextPad BTW that gets pixel sizes and coords from the gdal_info.txt and inserts them into the gdal_rasterize command in a blink, I'll share if you're interested)
-get ie "airport_holes_n40w108. tif" in PhotoShop along with USGS_13_n40w108_WGS84.tif, select the black hole areas with the magic wand tool, drag the selection onto the actual dem, hold the shift key down while you release and it will position the selection exactly where it needs to be. Fill the selected areas with black, save.
-add NullValue=0,0,0 to each source in the .inf and resample again

Here's what it looks like in TMFViewer, lol:

airport_holes_n41w109.jpg

I've inspected the perimeter of a couple of these "holes" around KRIL, KGWS, and KHDN and they're nearly undetectable, naturally you can see where the LOD12 mesh gives way to the LOD10 default mesh but I've found nothing garish yet and from a thousand feet up I can't see them at all. Kind of a cop-out but hey, it beats making dozens and dozens of airport elevation adjustments. :)
 
Hi Jim:

Although I have conducted a few tests of my own to blend airports into surrounding terrain mesh using GIS applications and vector data to modify raster elevation data,
your work-flow posted above is a brilliant idea to address "the dilemma terrain mesh developers face" ...when compelled to blend airports into surrounding terrain mesh. :wizard:


Would you be willing to share more info on your test of concept above as a 'worked example', and link to a SBuilderX *. SBX Exchange Data format file, the PhotoShop *.TIF "work" files, the TextPad macro, the gdal_rasterize / CMD Mode batch routines, and the SDK Resample multi-source *.INF file(s) you used ...so we can study this in details ? :scratchch

Thanks in advance for any further clarification you might be willing to share with us on this interesting approach to blending airports into surrounding terrain mesh. :)

GaryGB
 
It's still evolving at the moment Gary. :)

I downloaded the remaining DEMs to finish out Colorado this AM during the off-peak. Then I decided I didn't like my "airport_holes.shp" because the holes were all the same size, there were a lot of overlaps, and for some of the smaller airports they voided out a lot more mesh than necessary. So I went back and re-did the holes with holes of two different sizes plus a few custom sizes (like KDEN, which required a relatively large hole), just finished that and now I'm getting ready to reproject all my sources a 2nd time for the new holes. I'm working off a standard mechanical HDD because I don't have enough space on either of my SSDs, last night I had enough stuff going on fast enough I was up against the read/write capabilities of the HDD (poor thing was clattering and buzzing, sounded like it may have been painful, lol) so I need to ditch some Orbx stuff that I haven't been using and move the project back onto an SSD before I continue. I'll report back.

Jim
 
Many thanks again, Jim, for sharing with us, your exploration of this fascinating work-flow. :)


BTW: I lost (another) older 2-TB mechanical HDD recently after ignoring a tell-tale "buzzing" sound for a few days. :eek:

I have several newer 3-TB 7200 RPM mechanical HDDs I could have been streaming a backup onto, but I was "too busy" to re-activate my backup routine which had been 'temporarily' disabled a few months ago ...which I 'forgot' to turn back on. :banghead:


I now plan to set up SSDs in an external NAS housing that is turned on 1x a day by an external electronic timer, to allow scheduled backups while preventing the drives' BIOS-controlled MTBF deadline from expiring prematurely because a small amount of USB / SATA power is still being supplied to controller cards in the high performance NAS device.

I hope a driver "Hot Swap" allows SSDs to dynamically re-initialze in Windows when the power is turned back on daily.


I use ReadyBoost caching with a dynamic array of (16) 32-GB USB-3 150 mbps flash drives on (4) separate USB-3 hubs and ports to PreFetch / SuperFetch mechanical HDDs; IIUC, the result is almost as fast as RAID-0 hybrid HDD / SSD access speeds.

https://www.google.com/search?ei=33ogX9XtDsT0tAbcm5qQBw&q=site:www.fsdeveloper.com+GaryGB+"ReadyBoost"&oq=site:www.fsdeveloper.com+GaryGB+"ReadyBoost"&gs_lcp=CgZwc3ktYWIQA1DOlgFYwrkBYJTGAWgBcAB4AIABPogBtAGSAQEzmAEAoAEBqgEHZ3dzLXdpesABAQ&sclient=psy-ab&ved=0ahUKEwiV2YPX1fDqAhVEOs0KHdyNBnIQ4dUDCAs&uact=5


This gives me a maximum 256 GB PreFetch / SuperFetch caching supported by the Windows 7 Professional 64-Bit OS.

AFAIK, the ReadyBoost infrastructure is a Windows 'dynamic drive' volume equivalent to a software RAID-0 array which is distinct from a separately-configured option of a multiple physical drive, multi-component ...Windows Paging File.

My next test will be using cheap small SSDs in a "real" RAID-0 array for PreFetch / SuperFetch and Temp / TMP folders. :laughing:

I'm not sure whether ReadyBoost is disabled on mechanical drives in Windows if (1) or more SSDs are also installed. :scratchch


GaryGB
 
Last edited:
OK, Colorado's done. Not even beer-thirty yet. :)

colorado_mesh01.jpg

I compiled all the airport backgrounds to a CVX to check and make sure I didn't mess anything up. Here's what it looks like around KDEN

colorado_mesh02.jpg

Reminds me of that song "Tiny Bubbles", lol.

Below are the commands I came up with. All the gdal_rasterize commands originated from the "macro template" line. After running the gdalinfo commands I'd get the cursor bilnking at the begining of the gdal_rasterize command template and open ie USGS_13_n41w109_WGS84_gdalinfo.txt as a separate document in TextPad so I could ctrl+tab back & forth between them. Beginning with the gdalinfo.txt document the macro finds Pixel Size = ( , moves the cursor, selects and copies 0.000092592592593, then it ctrl+tabs to the other document and finds -tr , selects the first set of xxxxxxxxxxxxxxxxx, and pastes 0.000092592592593 that it copied from gdalinfo.txt overtop of it. Then it ctrl+tabs back to gdalinfo.txt and copies the 2nd value -0.000092592592593, returns to process.txt and pastes it over the second set of xxxxxxxxxxxxxxxxxx. It continues to ctrl+tab back & forth between the two documents, it finds Upper Left and get's the values for west and north, back to process.txt it finds WEST and pastes the value overtop of it etc. etc. until it's filled in all the info the command needs. Trust me it's a lot easier to record the macro than it is to explain the steps. After testing it I saved it and then all I need to do is get the cursor blinking at the beginning of the gdal_rasterize command template, open the gdalinfo.txt, and run the macro. It walks through the process so fast you see nothing but a blip on the screen and it's done.

I have the saved macro Chris if you want to try it, it should be able to do what you've been doing by hand with your watermask .shp turning it into watermask.tif but it's for an ancient version of TextPad rather than Notepad++. I'm not sure if it will run in newer versions of TextPad and I'm sure it wouldn't work in Notepad++. I do have the installer still for my version of TextPad but I'm not sure it'll run on Win10 (I'm using Win7 64), you can certainly try it. I mean it's old man, IIRC I got it off an AOL disk I picked up out of a bin at Wal-Mart probably in 2002 or so, lol. I have problems with macros in NotePad++ whenever I try to record one that ctrl+tabs back & forth between two documents, they work fine if they only involve one document though. That's why I've always kept TextPad around (plus I think it's a better text editor).

Code:
set remote=D:\Projects\Colorado_Mesh_Project

for %f in ("%remote%\sources\*.tif") do gdalwarp -of GTiff -co "INTERLEAVE=PIXEL" -t_srs "+proj=latlong +datum=WGS84" -r cubic %f "%remote%\%~nf_WGS84.tif"


::macro template:
gdal_rasterize -burn 255 -burn 255 -burn 255 -tr xxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxx -te WEST SOUTH EAST NORTH -ot BYTE "%remote%\shapes\airport_holes_colorado_v2.shp" "%remote%\airport_holes_n41w109.tif"



::CO_mesh_LOD12_n41w109.bgl
gdalinfo "%remote%\USGS_13_n41w109_WGS84.tif" > "%remote%\USGS_13_n41w109_WGS84_gdalinfo.txt"
gdalinfo "%remote%\USGS_13_n41w108_WGS84.tif" > "%remote%\USGS_13_n41w108_WGS84_gdalinfo.txt"
gdalinfo "%remote%\USGS_13_n40w109_WGS84.tif" > "%remote%\USGS_13_n40w109_WGS84_gdalinfo.txt"
gdalinfo "%remote%\USGS_13_n40w108_WGS84.tif" > "%remote%\USGS_13_n40w108_WGS84_gdalinfo.txt"

gdal_rasterize -burn 255 -burn 255 -burn 255 -tr 0.000092592592593 -0.000092592592593 -te -109.0005556 39.9994444 -107.9994444 41.0005556 -ot BYTE "%remote%\shapes\airport_holes_colorado_v2.shp" "%remote%\airport_holes_n41w109.tif"
gdal_rasterize -burn 255 -burn 255 -burn 255 -tr 0.000092592592526 -0.000092592592526 -te -108.0005556 39.9994444 -106.9994444 41.0005556 -ot BYTE "%remote%\shapes\airport_holes_colorado_v2.shp" "%remote%\airport_holes_n41w108.tif"
gdal_rasterize -burn 255 -burn 255 -burn 255 -tr 0.000092592592526 -0.000092592592526 -te -109.0005556 38.9994444 -107.9994444 40.0005556 -ot BYTE "%remote%\shapes\airport_holes_colorado_v2.shp" "%remote%\airport_holes_n40w109.tif"
gdal_rasterize -burn 255 -burn 255 -burn 255 -tr 0.000092592592526 -0.000092592592526 -te -108.0005556 38.9994444 -106.9994444 40.0005556 -ot BYTE "%remote%\shapes\airport_holes_colorado_v2.shp" "%remote%\airport_holes_n40w108.tif"


::CO_mesh_LOD12_n41w107.bgl
gdalinfo "%remote%\USGS_13_n41w107_WGS84.tif" > "%remote%\USGS_13_n41w107_WGS84_gdalinfo.txt"
gdalinfo "%remote%\USGS_13_n41w106_WGS84.tif" > "%remote%\USGS_13_n41w106_WGS84_gdalinfo.txt"
gdalinfo "%remote%\USGS_13_n40w107_WGS84.tif" > "%remote%\USGS_13_n40w107_WGS84_gdalinfo.txt"
gdalinfo "%remote%\USGS_13_n40w106_WGS84.tif" > "%remote%\USGS_13_n40w106_WGS84_gdalinfo.txt"

gdal_rasterize -burn 255 -burn 255 -burn 255 -tr 0.000092592592593 -0.000092592592593 -te -107.0005556 39.9994444 -105.9994444 41.0005556 -ot BYTE "%remote%\shapes\airport_holes_colorado_v2.shp" "%remote%\airport_holes_n41w107.tif"
gdal_rasterize -burn 255 -burn 255 -burn 255 -tr 0.000092592592567 -0.000092592592567 -te -106.0005556 39.9994444 -104.9994444 41.0005556 -ot BYTE "%remote%\shapes\airport_holes_colorado_v2.shp" "%remote%\airport_holes_n41w106.tif"
gdal_rasterize -burn 255 -burn 255 -burn 255 -tr 0.000092592592526 -0.000092592592526 -te -107.0005556 38.9994444 -105.9994444 40.0005556 -ot BYTE "%remote%\shapes\airport_holes_colorado_v2.shp" "%remote%\airport_holes_n40w107.tif"
gdal_rasterize -burn 255 -burn 255 -burn 255 -tr 0.000092592592567 -0.000092592592567 -te -106.0005556 38.9994444 -104.9994444 40.0005556 -ot BYTE "%remote%\shapes\airport_holes_colorado_v2.shp" "%remote%\airport_holes_n40w106.tif"


::CO_mesh_LOD12_n39w109.bgl
gdalinfo "%remote%\USGS_13_n39w109_WGS84.tif" > "%remote%\USGS_13_n39w109_WGS84_gdalinfo.txt"
gdalinfo "%remote%\USGS_13_n39w108_WGS84.tif" > "%remote%\USGS_13_n39w108_WGS84_gdalinfo.txt"
gdalinfo "%remote%\USGS_13_n38w109_WGS84.tif" > "%remote%\USGS_13_n38w109_WGS84_gdalinfo.txt"
gdalinfo "%remote%\USGS_13_n38w108_WGS84.tif" > "%remote%\USGS_13_n38w108_WGS84_gdalinfo.txt"

gdal_rasterize -burn 255 -burn 255 -burn 255 -tr 0.000092592592567 -0.000092592592567 -te -109.0005556 37.9994444 -107.9994444 39.0005556 -ot BYTE "%remote%\shapes\airport_holes_colorado_v2.shp" "%remote%\airport_holes_n39w109.tif"
gdal_rasterize -burn 255 -burn 255 -burn 255 -tr 0.000092592592593 -0.000092592592593 -te -108.0005556 37.9994444 -106.9994444 39.0005556 -ot BYTE "%remote%\shapes\airport_holes_colorado_v2.shp" "%remote%\airport_holes_n39w108.tif"
gdal_rasterize -burn 255 -burn 255 -burn 255 -tr 0.000092592592526 -0.000092592592526 -te -109.0005556 36.9994444 -107.9994444 38.0005556 -ot BYTE "%remote%\shapes\airport_holes_colorado_v2.shp" "%remote%\airport_holes_n38w109.tif"
gdal_rasterize -burn 255 -burn 255 -burn 255 -tr 0.000092592592526 -0.000092592592526 -te -108.0005556 36.9994444 -106.9994444 38.0005556 -ot BYTE "%remote%\shapes\airport_holes_colorado_v2.shp" "%remote%\airport_holes_n38w108.tif"


::CO_mesh_LOD12_n39w107.bgl
gdalinfo "%remote%\USGS_13_n39w107_WGS84.tif" > "%remote%\USGS_13_n39w107_WGS84_gdalinfo.txt"
gdalinfo "%remote%\USGS_13_n39w106_WGS84.tif" > "%remote%\USGS_13_n39w106_WGS84_gdalinfo.txt"
gdalinfo "%remote%\USGS_13_n38w107_WGS84.tif" > "%remote%\USGS_13_n38w107_WGS84_gdalinfo.txt"
gdalinfo "%remote%\USGS_13_n38w106_WGS84.tif" > "%remote%\USGS_13_n38w106_WGS84_gdalinfo.txt"

gdal_rasterize -burn 255 -burn 255 -burn 255 -tr 0.000092592592593 -0.000092592592593 -te -107.0005556 37.9994444 -105.9994444 39.0005556 -ot BYTE "%remote%\shapes\airport_holes_colorado_v2.shp" "%remote%\airport_holes_n39w107.tif"
gdal_rasterize -burn 255 -burn 255 -burn 255 -tr 0.000092592592593 -0.000092592592593 -te -106.0005556 37.9994444 -104.9994444 39.0005556 -ot BYTE "%remote%\shapes\airport_holes_colorado_v2.shp" "%remote%\airport_holes_n39w106.tif"
gdal_rasterize -burn 255 -burn 255 -burn 255 -tr 0.000092592592593 -0.000092592592593 -te -107.0005556 36.9994444 -105.9994444 38.0005556 -ot BYTE "%remote%\shapes\airport_holes_colorado_v2.shp" "%remote%\airport_holes_n38w107.tif"
gdal_rasterize -burn 255 -burn 255 -burn 255 -tr 0.000092592593000 -0.000092592593000 -te -106.0005556 36.9994444 -104.9994444 38.0005556 -ot BYTE "%remote%\shapes\airport_holes_colorado_v2.shp" "%remote%\airport_holes_n38w106.tif"




::CO_mesh_LOD12_n41w105.bgl
gdalinfo "%remote%\USGS_13_n41w105_WGS84.tif" > "%remote%\USGS_13_n41w105_WGS84_gdalinfo.txt"
gdalinfo "%remote%\USGS_13_n41w104_WGS84.tif" > "%remote%\USGS_13_n41w104_WGS84_gdalinfo.txt"
gdalinfo "%remote%\USGS_13_n40w105_WGS84.tif" > "%remote%\USGS_13_n40w105_WGS84_gdalinfo.txt"
gdalinfo "%remote%\USGS_13_n40w104_WGS84.tif" > "%remote%\USGS_13_n40w104_WGS84_gdalinfo.txt"

gdal_rasterize -burn 255 -burn 255 -burn 255 -tr 0.000092592592526 -0.000092592592526 -te -105.0005556 39.9994444 -103.9994444 41.0005556 -ot BYTE "%remote%\shapes\airport_holes_colorado_v2.shp" "%remote%\airport_holes_n41w105.tif"
gdal_rasterize -burn 255 -burn 255 -burn 255 -tr 0.000092592592526 -0.000092592592526 -te -104.0005556 39.9994444 -102.9994444 41.0005556 -ot BYTE "%remote%\shapes\airport_holes_colorado_v2.shp" "%remote%\airport_holes_n41w104.tif"
gdal_rasterize -burn 255 -burn 255 -burn 255 -tr 0.000092592592526 -0.000092592592526 -te -105.0005556 38.9994444 -103.9994444 40.0005556 -ot BYTE "%remote%\shapes\airport_holes_colorado_v2.shp" "%remote%\airport_holes_n40w105.tif"
gdal_rasterize -burn 255 -burn 255 -burn 255 -tr 0.000092592592593 -0.000092592592593 -te -104.0005556 38.9994444 -102.9994444 40.0005556 -ot BYTE "%remote%\shapes\airport_holes_colorado_v2.shp" "%remote%\airport_holes_n40w104.tif"


::CO_mesh_LOD12_n39w105.bgl
gdalinfo "%remote%\USGS_13_n39w105_WGS84.tif" > "%remote%\USGS_13_n39w105_WGS84_gdalinfo.txt"
gdalinfo "%remote%\USGS_13_n39w104_WGS84.tif" > "%remote%\USGS_13_n39w104_WGS84_gdalinfo.txt"
gdalinfo "%remote%\USGS_13_n38w105_WGS84.tif" > "%remote%\USGS_13_n38w105_WGS84_gdalinfo.txt"
gdalinfo "%remote%\USGS_13_n38w104_WGS84.tif" > "%remote%\USGS_13_n38w104_WGS84_gdalinfo.txt"


gdal_rasterize -burn 255 -burn 255 -burn 255 -tr 0.000092592592593 -0.000092592592593 -te -105.0005556 37.9994444 -103.9994444 39.0005556 -ot BYTE "%remote%\shapes\airport_holes_colorado_v2.shp" "%remote%\airport_holes_n39w105.tif"
gdal_rasterize -burn 255 -burn 255 -burn 255 -tr 0.000092592592593 -0.000092592592593 -te -104.0005556 37.9994444 -102.9994444 39.0005556 -ot BYTE "%remote%\shapes\airport_holes_colorado_v2.shp" "%remote%\airport_holes_n39w104.tif"
gdal_rasterize -burn 255 -burn 255 -burn 255 -tr 0.000092592592593 -0.000092592592593 -te -105.0005556 36.9994444 -103.9994444 38.0005556 -ot BYTE "%remote%\shapes\airport_holes_colorado_v2.shp" "%remote%\airport_holes_n38w105.tif"
gdal_rasterize -burn 255 -burn 255 -burn 255 -tr 0.000092592592593 -0.000092592592593 -te -104.0005556 36.9994444 -102.9994444 38.0005556 -ot BYTE "%remote%\shapes\airport_holes_colorado_v2.shp" "%remote%\airport_holes_n38w104.tif"


::CO_mesh_LOD12_n41w103
gdalinfo "%remote%\USGS_13_n41w103_WGS84.tif" > "%remote%\USGS_13_n41w103_WGS84_gdalinfo.txt"
gdalinfo "%remote%\USGS_13_n40w103_WGS84.tif" > "%remote%\USGS_13_n40w103_WGS84_gdalinfo.txt"


gdal_rasterize -burn 255 -burn 255 -burn 255 -tr 0.000092592592526 -0.000092592592526 -te -103.0005556 39.9994444 -101.9994444 41.0005556 -ot BYTE "%remote%\shapes\airport_holes_colorado_v2.shp" "%remote%\airport_holes_n41w103.tif"
gdal_rasterize -burn 255 -burn 255 -burn 255 -tr 0.000092592592526 -0.000092592592526 -te -103.0005556 38.9994444 -101.9994444 40.0005556 -ot BYTE "%remote%\shapes\airport_holes_colorado_v2.shp" "%remote%\airport_holes_n40w103.tif"



::CO_mesh_LOD12_n38w103
gdalinfo "%remote%\USGS_13_n38w103_WGS84.tif" > "%remote%\USGS_13_n38w103_WGS84_gdalinfo.txt"
gdalinfo "%remote%\USGS_13_n39w103_WGS84.tif" > "%remote%\USGS_13_n39w103_WGS84_gdalinfo.txt"

gdal_rasterize -burn 255 -burn 255 -burn 255 -tr 0.000092592592526 -0.000092592592526 -te -103.0005556 36.9994444 -101.9994444 38.0005556 -ot BYTE "%remote%\shapes\airport_holes_colorado_v2.shp" "%remote%\airport_holes_n38w103.tif"
gdal_rasterize -burn 255 -burn 255 -burn 255 -tr 0.000092592592567 -0.000092592592567 -te -103.0005556 37.9994444 -101.9994444 39.0005556 -ot BYTE "%remote%\shapes\airport_holes_colorado_v2.shp" "%remote%\airport_holes_n39w103.tif"
 
After completing a flight over the new mesh I have to say the improvement is pretty lackluster. I paused at a multitude of locations and switched the mesh off and on in the scenery library, took a few screenshots, compared them and yes, there is a slight difference but it's subtle at best. I did a couple comparisons between default LOD10 and the 1/3 arc second/LOD12 mesh in FSX mostly because that's the sim I had running when I decided to do comparisons, here are a couple animated .gifs that show the difference via the "blink comparator" approach:

mesh_comparison02.gif


mesh_comparison01.gif


If the lackluster difference in mesh wasn't bad enough I crashed on approach to KGCU, total CFIT, in retrospect (and according to the chart that I didn't look at) I guess a person should do a right hand pattern for rwy 06 and I went left which proved to be a pretty bad idea, lol.


On the other hand here's a couple shots I snapped on the way by of that photoreal I color-corrected with nConvert, pretty happy with it, and I've finally sorted scenproc to put some autogen buildings on it, still working on the trees though. Amazing, really puts the "auto" in autogen which was a complete misnomer in the past. :)

KBJC_KGUC_01.jpg


KBJC_KGUC_02.jpg


EDIT: Still haven't found a plateau or crevasse around an airport with the exception of 27CO which I somehow missed making the holes in the mesh. Not worth reprojecting the source again though, lol.
 
Last edited:
Hi Jim:

While we await a reply from Chris (who may have been compelled to take a break after his intensive ongoing efforts ?), I would again like to say thanks for posting this outstanding worked example for your test area ...which IMHO, should prove quite helpful to those of us seeking to further enhance our FS terrain. :)

BTW: Would it be possible for you to attach the TextPad macro file to this thread so we can test whether it is actually compatible with current versions of that application ?


FYI: I did find earlier versions (circa year 2002) of TextPad were still downloadable via the Internet Archive - WayBack Machine website just in case they are needed. ;)


I find that increased terrain shadow details seen when flying 'low and slow' make this LOD-12 / 10 Meters resolution terrain mesh a nice enhancement in mountainous areas.


PS: Indeed, it looks like approaches are challenging at GUNNISON-CRESTED BUTTE RGNL (ICAO: KGCU) in addition to the lesser altitude density at 7,680 ft / 2,341 m. o_O



One might wonder whether pilots otherwise doing a 'straight-in" KGUC RWY-06 approach have sheared the 'crest' off this butte to the South-West ! :laughing:






"COFIT" is of course, not to be confused with "Confit" (..although 'preserving' ones virtual life in FS is at least an indirectly related concept that may apply here ! ) :D


GaryGB
 

Attachments

Last edited:
While we await a reply from Chris (who may have been compelled to take a break after his intensive ongoing efforts ?), I would again like to say thanks
Goodness gracious, I didn't know that fixing the mesh around the airports was possible and now I have a spectacular "how-to" that will let me plow forward! Thank you very much Jim!

P.S.: I was searching for something else the other day and came across some posts at AVSim I believe from about 20 years ago where I saw Jim ask a "noobie" question. And other posters in the same thread were Gary, Dick, and Arno. Small world, huh?

:)
 
On the other hand here's a couple shots I snapped on the way by of that photoreal I color-corrected with nConvert, pretty happy with it, and I've finally sorted scenproc to put some autogen buildings on it, still working on the trees though. Amazing, really puts the "auto" in autogen which was a complete misnomer in the past. :)
Does "nConvert" let you adjust color saturation, brightness, contrast, etc.? That's something I had been doing in PaintShopPro, then GIMP (when the larger file sizes needed a 64-bit program), and that process leaves much to be desired. I would much rather correct the workflow now than have a thousand tiles to re-do down the road.

I'm cautious about downloading new software, as an internet search usually provides numerous websites of questionable integrity offering something with the same name as what I am looking for. Is this it? https://www.xnview.com/en/nconvert/
 
Last edited:
Hi Chris:

While we await a reply from Jim (who may have been compelled to take a break after his intensive ongoing efforts ?) ;),
I can say that the link you posted above is correct, and can also assure you that the author of nConvert and XnView is both brilliant and reliable. :pushpin:



PS: I hope to always have the perspective of a "noobie", so that I may stay open-minded to learning new things. :)

You can see from old posts at AVSIM how the FS Development Community has worked hard to gain new insights and methods to enhance the FS experience over many years. :coffee:

GaryGB
 
Last edited:
I find that increased terrain shadow details seen when flying 'low and slow' make this LOD-12 / 10 Meters resolution terrain mesh a nice enhancement in mountainous areas.
I have to agree Gary, I actually noticed this shadow/shading thing myself, I think it subliminally adds a bit to the immersion factor even though the difference in the actual mesh might not be blatantly obvious between a quick glance with and without the mesh active.

I've attached the TextPad macro, I installed the latest version of TextPad this afternoon and confirmed that my macro (from version 4.5.0) worked in the latest version. ...but then I recorded a new one because the one I did previously didn't do anything with the output filename and the new one gets it from the gdalinfo.txt and inserts it into the command. I typed some brief instruction and included them in the .zip file. Also included are a couple example files (the template and an example gdalinfo.txt so you can try it out).

TextPad is payware, but the evaluation copy is fully functional. My 4.5.0 version has worked indefinitely but with a nag screen on every startup and again every hour thereafter when you save. I'm not sure if the latest version works the same way, maybe it stops working altogether after a certain period of time. I've gotten so used to the nag screen in 4.5.0 I don't even see it anymore, it still lets you save after the hour has passed but you have to click the "OK" button which I do with right arrow > Enter without even thinking about it. All this recent discussion about TextPad made me start thinking about it however, and if there's one evaluation program I should pay for it has to be TextPad, I've used it every day it seems for nearly 20 years. It was a bit steep IMO at $27 USD but I've certainly gotten $27 worth of value out of it over the years so I shamed myself into purchasing it this afternoon. I am now the proud owner of a registered copy of TextPad. :)

On nConvert, yes, it's perfectly safe as Gary stated, I've been using it for years. Here are some shots of the color correction it's done on my "keystone" (Breckenridge) photoreal, first this is what it looked like straight from SBuilderX (it's google satellite imagery BTW):

nconvert_01.jpg


Here it is with the blendmask added:

nconvert_02.jpg


And finally here it is with the blendmask and the nConvert color corrections:

nconvert_03.jpg


I'm not in any way trying to say nConvert is the end-all in color correcting photoreal, for one thing, in PhotoShop, Gimp, or PSP it's possible to apply different corrections to different parts of the imagery where with nConvert you get an across-the-board correction that applies equally to the entire image. I am however saying for mass-processing of images it seems to do a respectable job and you can run it from a command line making the corrections in the blink of an eye as opposed to opening each .tif in your image editing program an spending half an hour on it.

From my post in the "Scenproc script suggestions" thread this is the process I worked through to get the above color corrections:

You do gdal_warp generating a .tif, then you extract the geo data out of it (because nconvert will strip it), run the nconvert command, and finally put the geo data back in. Something like this:

Code:
gdalwarp -of GTiff -co "INTERLEAVE=PIXEL" -t_srs "+proj=latlong +datum=WGS84" -r cubic "%remote%\keystone_NAD83.tif" "%remote%\SE_keystone_WGS84.tif"
::
::extract the geo data to be put back in after the nconvert step
listgeo -d "%remote%\NW_keystone_WGS84.tif" > "%remote%\NW_keystone_WGS84.gtf"
::
::the nconvert command, to see all the nconvert options type: nconvert -help > nchelp.txt
"%nconvertpath%\nconvert.exe" -overwrite -balance 1 5 -10 -brightness -5 -contrast 40 -sharpen 20 -replace 0 0 0 2 2 2 "%remote%\NW_keystone_WGS84.tif"
::
::finally put the geo data back in so GeoTiffToInf can read it
geotifcp -g "%remote%\NW_keystone_WGS84.gtf" "%remote%\NW_keystone_WGS84.tif" "%remote%\NW_keystone_WGS84a.tif"
Since I posted that however I modified the nConvert command to include a hue & saturation adjustment, desaturating the image just slightly:

Code:
"%nconvertpath%\nconvert.exe" -overwrite -balance 6 5 -10 -hls 0 0 -1 -brightness -5 -contrast 40 -sharpen 20 -replace 0 0 0 2 2 2 "%remote%\NW_keystone_WGS84.tif"
The nConvert command arguments are as follows:

Code:
-overwrite           : Overwrite existing file (without this, nconvert creates a new file, "NW_keystone_WGS84.tif" is saved as "NW_keystone_WGS84_1.tif" for example)
-balance r g b       : Color balance
-hls h l s           : Adjust Hue Lightness Saturation
-brightness value    : Modify brightness (-100...100)
-contrast value      : Modify contrast (-100...100)
-sharpen percent     : Sharpen (1...100)
-replace r g b r g b : Replace color (first RGB are original values, second RGB are "replace" values)
Jim
 

Attachments

Jim, you've given me a LOT to work with, and I started small to get the flow down. I can already tell that the nConvert settings are right on target... and once I get your streamlined method down, I'll be pumping out spectacular scenery pretty darn fast.

Can't wait to show off my progress!

Thanks a million,
 
What are you working on Chris? Mesh? Photoreal? Water masks? Airport holes?

I found a glitch in the textpad macro so if you can't get it to work, post up your gdalinfo.txt and your template and maybe we can figure out what's wrong. They're a bit temperamental, lol.
 
What are you working on Chris? Mesh? Photoreal? Water masks? Airport holes?
All of that.

Right now, I am trying to get a few tiles of photoreal done by using your approach, then I'll go back and add the watermasks, and then the airport holes to the mesh. Then I'm hoping a fairy will show up and grant me my wish of a wonderful ScenProc script for buildings and trees.
 
I was able to scenproc some buildings onto the photoreal above using your script from the other thread and some building data from MS or Bing, but I haven't been able to sort out the trees either. I almost fell off my chair when I finally saw scenproc populate my texture folder with nearly 100 .agn files containing the buildings though!

I downloaded the OSM data for Colorado from geofabrik and I'm trying to follow the tutorial in the wiki but I can't find "column: type" or "forest" in QGIS anywhere within the data I downloaded as the wiki shows, for that matter if I put my blendmask in QGIS alongside the OSM data I can't see where there are even any points, polygons or anything else that fall within it. I guess I need to attempt the feature detection but the video tutorial is like trying to learn gmax from a photoshop tutorial because nothing in the video looks remotely like what I actually see in scenproc. I really don't understand if scenproc wants points or polygons for the trees, if polygons I'm thinking about doing my own "feature detection" in PhotoShop with the magic wand tool and turning the result into a .shp with gdal_polygonize from the command line. I think I'll be able to sort the tree and roof types as I've been into the autogendescriptions before. If I find the magic bullet I'll let you know. :)
 
I downloaded the OSM data for Colorado from geofabrik
OSM data in the Midwest isn't very useful so I use building footprints from Microsoft: https://github.com/Microsoft/USBuildingFootprints -- state files are about three-fourths of the way down the page. I tried using USGS woodland/wetland shapefiles to make vegetation polygons in ScenProc, and that does ok in rural areas (despite some polygons disappearing and reappearing, depending on where I am looking), but populated areas won't have any vegetation.
 
I also think I saw that you can program street lights in ScenProc, so when I run into another stumbling block in scenery design, I will figure out how to disable street lights on the default FSX roads and then tell ScenProc to install lights for primary and secondary roads within polygons from USGS (or maybe Census Bureau) urban shapefiles. Looks good, but I haven't ever noticed streetlights up and down highways and interstates in real life.
 
Top