Having troubles with Airport Mesh

#1
Hello,

I am trying to place my mesh in my scenery. I figured out how to compile my BGL and it shows up in TMFViewer but the difference vs the default mesh is very subtle. (I have my P3D settings all cranked up to max)



I am also trying to create the "extruded" slope where the airport it situated this is how it looks in real life.




But this is how it is looking inside P3D



This is my INF File:
[Source]
Type = GeoTIFF
Layer = Elevation
SampleType=FLOAT32
SourceDir ="."
SourceFile = "Vigo_Mesh_08242019.tif"
nCols = 5773
nRows = 4095
PixelIsPoint=1

[Destination]
DestDir = "."
DestBaseFileName = "RWY37_Vigo_5MDT"
DestFileType = BGL
CompressionQuality = 97
FractionBits = 3
LOD = Auto,13

and this is how my 5M DEM Mesh Data looks when reprojected to WGS84 and converted to GeoTiff:


And my Source .ASC DEM file:


The circle represents where the airport is supposedly located. Any clue or way to make that part of the mesh flat and give it that kind of slope?

Thanks
 
#2
Hi Tony:

Assuming your source data is 5 Meters between elevation data points and is reprojected to (EPSG:4326) GIS format:

I suggest that in your *.INF, try instead::pushpin:

CompressionQuality = 100
FractionBits = 3
LOD = 6,Auto

...and in P3D GUI, set:

* Tessellation Factor (aka "Terrain Mesh Complexity" in MSFS) at 100 %

* Mesh Resolution at 2 Meters

I am downloading that data near Vigo airport to offer additional feedback on your other terrain scenery query. :)

GaryGB
 
#3
Hello Garry,

I did modify my INF as you suggested as well as in the P3D Settings I have my Tesselation Factor set to 100% and Mesh Resolution I tried in 5m, 2m, and 1m. I must say the slope itself it did a very small change but not much more than that. But is still far from what it looks in real life.
 
#4
Hi Tony:

WYSIWYG (What You See Is What You Get) based on source data fidelity to the real world if GIS projection is "correct".

There may be an issue with Height Units, Vertical Datum, or Scale ...as interpreted / assigned in QGIS for the *.ASC file. :scratchch


In Google Earth Desktop Edition:

Normally only 90 Meters SRTM terrain mesh view is apparently substituted by terrain mesh closer to real life in 3D view

Verify that: GE Menu > Tools > Options > {3D View} Tab > Elevation Exaggeration > ...is set at [1.0]


FYI: I am examining above *.ASC LiDAR files in Global Mapper (aka "GM") prior to data export for a test FSX terrain mesh.



BTW: P3D default scenery is FSX default scenery, aside from a few example airports with Hi-Res terrain mesh / textures.

GaryGB
 

Attachments

Last edited:
#5
I see, the problem is that when exported into P3D the terrain becomes much more like a smooth cliff instead of how it is in real life and the DEM data in GM looks correct. Where the airport is on its elevated slope and then blends well with the rest. But if you manage to export and tried it out it you will see how this isn't been accurate represented inside the sim. Hopefully you have more luck than me or can find out why is this.
 
#6
Hi Tony:

I have some more tests to do, but I suspect an error in Geo-referencing / GIS projection of the LiDAR *.ASC source file used in my FSX test terrain mesh (...causing the mesh to load over the sea offshore in FSX). :laughing:

[EDITED]

When I originally downloaded the data, I missed this detail on this Digital Elevation Models web page::eek:

http://centrodedescargas.cnig.es/CentroDescargas/locale?request_locale=en

"Digital Terrain Model - DTM05

Description: Digital Terrain Model with 5 m grid spacing.

GRS: ETRS89 for the Iberian Peninsula, Balearic Islands, Ceuta and Melilla, and REGCAN95 for the Canary Islands (both systems are compatible with WGS84). UTM projection in the corresponding zone. Also zone 30 extended for sheets into zones 29 and 31. Orthometric heights.

Download Units: MTN50 sheets

Format: ASCII (.asc) ESRI array

See +

"It has has been obtained by interpolation of the land class obtained from LIDAR flights of the National Plan for Aerial Orthophotography (PNOA). Not for sheets of Ceuta, Melilla and Alborán Island (1110, 1111, 1078B), which have been obtained by automatic stereo-correlation of PNOA flights with a 25 to 50 cm/pixel resolution, revised and interpolated with break lines where feasible.

"Metadata
Auxiliary Information"


Having missed the detail on the web page above, I had initially chosen: :oops:

PROJ_DESC=UTM Zone 29 / ETRS89 / meters
PROJ_DATUM=ETRS89
PROJ_UNITS=meters
EPSG_CODE=EPSG:3041

...based on the real world location of Vigo at between 12 W - 6 W Northern Hemisphere.

I then mistakenly assumed this would be correct, and had not inspected the GM Metadata to see how GM inferred and assigned the Westerly Longitude coordinates at 14 degrees- instead of a proper 8 degrees- of UTM Zone 30. o_O

The correct Metadata in GM is:

GM Metadata:
"
FILENAME=\\M4a78t-e\ASUS-2XP5_R\Downloads\PNOA_MDT05_ETRS89_HU30_0223_LID.asc
DESCRIPTION=PNOA_MDT05_ETRS89_HU30_0223_LID.asc
UPPER LEFT X=16300.000
UPPER LEFT Y=4703470.000
LOWER RIGHT X=45160.000
LOWER RIGHT Y=4683000.000
WEST LONGITUDE=8.87067238° W
NORTH LATITUDE=42.35131932° N
EAST LONGITUDE=8.50420174° W
SOUTH LATITUDE=42.14865593° N
UL CORNER LONGITUDE=8.87029688° W
UL CORNER LATITUDE=42.33301933° N
UR CORNER LONGITUDE=8.52167291° W
UR CORNER LATITUDE=42.35039499° N
LR CORNER LONGITUDE=8.50563709° W
LR CORNER LATITUDE=42.16689152° N
LL CORNER LONGITUDE=8.85326232° W
LL CORNER LATITUDE=42.14962655° N
PROJ_DESC=UTM Zone 30 / ETRS89 / meters
PROJ_DATUM=ETRS89
PROJ_UNITS=meters
EPSG_CODE=EPSG:3042
COVERED AREA=590.76 sq km
NUM COLUMNS=5773
NUM ROWS=4095
PIXEL WIDTH=5 meters
PIXEL HEIGHT=5 meters
MIN ELEVATION=-1.986 meters
MAX ELEVATION=742.872 meters
ELEVATION UNITS=meters
BIT DEPTH=24
"

This subsequently is re-projected to (EPSG: 4326) aka "Geographic Projection / WGS84 Datum" for SDK Resample. :pushpin:

UPDATE: A Quick-and-Dirty data set with a corrected set of GIS values compiled to BGL / displayed in FSX:



I shall post info on methods used after I complete more tests. ;)

[END_EDIT]

GaryGB
 

Attachments

Last edited:
#7
Oh wow, this is getting close to what it looks in real-life. I appreciate your discovery. So basically it is because of the projection settings? Also Why they are some weird spikes in the background?
 
#8
Hi Tony:

https://www.fsdeveloper.com/forum/threads/having-troubles-with-airport-mesh.445990/post-828710

Oh wow, this is getting close to what it looks in real-life. I appreciate your discovery.
Glad I finally found the info on the IGN website that was missing from the "official" Metadata (which by GIS industry standard, is 'supposed' to contain all details on how data is sourced / processed, including Horizontal / Vertical Projection and Datum, with any / all modifications from existing 'Well Known' CRS / SRS / EPSG GIS formats / types.) :banghead:

My worked example thus far shows that one seeking data directly from the download FTP or Map Viewer / download portal may NOT always be getting all the info required ...without first browsing the sequence of web pages that start at the 'front end' of a GIS web portal system. :alert:

A lesson for us all: never 'assume' a government agency or 3rd party data set ...is free from errors / omissions. :duck:


Interestingly, GIS data sourced by IGN is noted in a reference (commentary ?) on a European Commission website:

https://inspire.ec.europa.eu/forum/pages/view/175587/experi



GIS 'Projection' settings and Elevation Units both required correction when the *.ASC source data was processed

I will explain more when I post a work-flow for processing the *.ASC into source data for SDK Resample later (today ?)


That is seen with Hi-Res terrain mesh displayed at a higher resolution Terrain Mesh 'slider' setting in the FS / P3D GUI, and apparently is a ground surface anomaly seen when gridded elevation data is not aligned precisely with the internal FS / P3D terrain quad grid vertices, allowing spikes and/or pits to form in the 3D terrain surface at run time.

Preventing this may require an overlap of source data extents with that of nearby FS / P3D terrain quad grid vertices, and involves some additional calculations to determine what that extent of overlap must be when submitting source data to SDK Resample.

I will explain more when I post a work-flow for processing the *.ASC into source data for SDK Resample later (today ?) :coffee:

GaryGB
 
Last edited:
#9
Oh wow, who would have thought that. Usually, from what I have seen from other devs they have their files ready to go because of the most are from US sources and at least they seem to have their data well. Anyways, thanks a lot for your discovery. I appreciate your help a ton and I am looking forward to reading your workflow breakdown for *.ASC
 
#10
Hi Tony:

I have now downloaded your (large) *.RAR file linked via PM, and will take a look at it in GM.

I shall post some info on how to proceed tomorrow (Thursday) :)

[EDITED]

UPDATE:

PS: If you have GM available to test with until I get more time available tomorrow, "Open" both files: :idea:

"PNOA_MDT05_ETRS89_HU30_0223_LID.asc"

...and:

"PNOA_MA_OF_ETRS89_HU29_h50_0223.ecw"

...with these same GIS 'projection' format values:

PROJ_DESC=UTM Zone 30 / ETRS89 / meters
PROJ_DATUM=ETRS89
PROJ_UNITS=meters
EPSG_CODE=EPSG:3042

...More tomorrow... ;)

[END_EDIT]

GaryGB
 
Last edited:
#15
But is getting there. I wonder if with your method is it going to be able to use the IGN orthoimagery instead of the Sbuilder X one, as I prefer sticking up with the orthoimagery from IGN but you managed to make the mesh works almost flawlessly . Can't wait to read how you did and what is your workflow for *.ASC files. Though I don't still get the spikes on the background.
 
#16
https://www.fsdeveloper.com/forum/threads/having-troubles-with-airport-mesh.445990/post-828775

Oh, cool just like real life. I have been trying changing the coordinates. It has somehow improved but it is still not looking like yours.
Fraction Bits 14: (Images not included in quote)

No Fraction Bits at all: (Images not included in quote)
Fraction bits is apparently not required for your particular *.ASC elevation data set at Vigo airport altitude AMSL.

https://www.fsdeveloper.com/forum/threads/having-troubles-with-airport-mesh.445990/post-828776

But is getting there. I wonder if with your method is it going to be able to use the IGN orthoimagery instead of the Sbuilder X one, as I prefer sticking up with the orthoimagery from IGN but you managed to make the mesh works almost flawlessly.
Yes, you will be able to "use the IGN orthoimagery instead of the Sbuilder X one". :)

However, you may wish to color match the palette of the IGN orthoimagery area closer to that of FSX / P3D. :idea:

https://www.fsdeveloper.com/forum/threads/having-troubles-with-airport-mesh.445990/post-828776

Can't wait to read how you did and what is your workflow for *.ASC files. Though I don't still get the spikes on the background.
Determining a SDK terrain grid compatible Geographic extent for elevation data used in the *.INF is on today's list of things to do.

Once that is determined, the terrain mesh will not be at risk for display of anomalous "spikes/ pits" if an end user sets their terrain mesh slider at 1 Meter resolution (...like I do on my FSX configuration). ;)

GaryGB
 
Last edited:
#17
Fraction bits is apparently not required for your particular *.ASC elevation data set at Vigo airport altitude AMSL.



Yes, you will be able to "use the IGN orthoimagery instead of the Sbuilder X one". :)

However, you may wish to color match the palette of the IGN orthoimagery area closer to that of FSX / P3D. :idea:



Determining a SDK terrain grid compatible Geographic extent for elevation data used in the *.INF is on today's list of things to do.

Once that is determined, the terrain mesh will not be at risk for display of anomalous "spikes/ pits" if an end user sets their terrain mesh slider at 1 Meter resolution (...like I do on my FSX configuration). ;)

GaryGB
I see, thanks a lot for your foundings. I wouldn't have found out this on my own. So I appreciate it a lot your help. I will color match the imagery, tho is a bit hard as I can't get real-time feedback or don't have any guide to follow but I will do my best.
 
#18
https://www.fsdeveloper.com/forum/threads/having-troubles-with-airport-mesh.445990/post-828818

I see, thanks a lot for your foundings. I wouldn't have found out this on my own. So I appreciate it a lot your help. I will color match the imagery, tho is a bit hard as I can't get real-time feedback or don't have any guide to follow but I will do my best.

Hi Tony:

You may wish to review these threads:

https://www.google.com/search?source=hp&ei=YTNoXb-PN4vStAXj5oqgAQ&q=site:www.fsdeveloper.com+GaryGB+color+match+Metrix&oq=site:www.fsdeveloper.com+GaryGB+color+match+Metrix&gs_l=psy-ab.3...9462.51496..51937...4.0..0.224.2952.37j0j2......0....1j2..gws-wiz.....6..0i308i154i357j0j0i131j0i3j0i131i10.gMQ1Pv6Xfg8&ved=0ahUKEwj_w6LQ86jkAhULKa0KHWOzAhQQ4dUDCAs&uact=5#spf=1567110033216


Others have had greater success with more precise results using Metrix plugin for Photoshop (and a few other graphics applications), although reportedly it may require some additional manual labor to configure the source and target areas

IMHO, since most photo-real in that area is likely to be largely obscured by Autogen, you might only need to adjust the color palette to match that of FSX / P3D, rather than to be as detailed as Metrix allows (...but at a cost in manual labor).


This could likely be done via a semi-automated procedure using Photoshop's batch processing feature: :idea:

https://www.google.com/search?ei=Um...0..0.93.93.1......0....1..gws-wiz.taq9TxLn_DY



BTW: If you have imagery that needs 'some' color matching, you could set up a batch routines to apply certain presets that may be required based on visual inspection in a preview mode as you view adjacent imagery tiles.


Also of particular note is a thread at OrbX forums in which John Venema describes general color settings in ex: Photoshop which may correct the color balance in imagery to be closer to the color palette used by FSX / P3D in making Seasonal Texture variations (if any are even needed for Vigo area). :idea:

https://orbxsystems.com/forum/topic...nity-question/?do=findComment&comment=1459536


I hope this info might also prove helpful as you consider ways to reduce some of the work-load for your project. :)


PS: Unfortunately, I may not be able to post the 'work-flow' info for you today because I lost time to resolving a FireFox Profile crash caused by a Zero-Day malware exploit incurred by a link to a scenery object library update on an infrequently administered commercial FS scenery web site.

Interestingly, it was willing to allow web connectivity to a page about "Chrome Store De-Foxified" FireFox extension plugin, but no other web pages. :banghead:

Suffice it say, I have been busy running anti-malware / anti-adware security software scans and transferring user info to a new FireFox profile. :coffee:

I shall renew my efforts to post the 'work-flow' info for you by tomorrow at latest. ;)

GaryGB
 
Top