MSFS20 Custom aerial texture below the default one

[GaryGB]

I have not seen this issue in MSFS 2020, but here is some info found via Google:

https://www.google.com/search?q=MSF...jyHCBwczLjI4LjE3yAdkgAgA&sclient=gws-wiz-serp


Possibly Dick has read something about this issue in MSFS 2020 on the MSFS DevSupport forum system ?

GaryGB

 

[lumat]

Reading through these different threads, I get the impression that this is a known but unresolved problem.
Apparently, the problem is old, but I'd never encountered it before, which seems strange to me.

Thee is the solution given by Dick. It works prefectly, but it's still a problem to have to disable photogrammetry to display custom aerial textures.
I still don't understand why on my two CGL, the aerial texture of the airport area is displayed in all cases and not the one covering the surrounding areas (Made exactly by the same way) !

 

[GaryGB]

Perhaps a review of making and using (2) superimposed custom photo-real aerial imagery areas made by FS2Kx SDK Resample may help ?

IIUC, the smaller area should be displayed by FS as the higher local zoom level imagery if the user aircraft is physically closer to it.

The smaller field of view of the FS camera causes higher LODs and MIPMAPs of aerial imagery to display.


Rather than attempting to make (2) CGLs, consider making (1) CGL covering the extents of both the small and large areas.

When the user aircraft camera is farther away from the smaller local area, lower LODs and MIPMAPs of aerial imagery will display.

GaryGB

 

[lumat]

one cgl only instead Two for all the area ?
Yes but the area is about 10km by 10km. And the size of 1 cgl will be too big
That's why I wanted to create two CGLs : one LOD21 for the airport and divide the surrounding area into a few LOD20 CGLs (to keep each CGL under 1GB).

I didn't quite understand : FS2Kx is a FSX tool ?

 

[GaryGB]

FS2Kx = FS 2000 series: FS2000, FS2002, FS2004, FSX, Prepar3D.


Certainly there might be no need to use ultra-high resolution source aerial imagery to create huge CGLs for off-airport areas.

Unless, of course, your target end user base may wish to explore the areas surrounding the airport low-and-slow (like I do).


With a only personal use- or special interest group- purpose for this scenery, you could use a 'capped' resolution 2-CGL method.

AFAIK, for aerial imagery, that requires blending and control over display priority of layering at runtime by the rendering engine.


In FS2Kx SDK Resample (whether FS8 / FS9 / FSX / P3D we would put multi-LOD imagery data into (1) BGL via a multi-source INF.

Do we have that option in MSFS SDK, or has Asobo not yet restored the granularity of control we had in FS2Kx SDK resample ?


If you are concerned over MSFS compiled package footprint size on disk, you 'may' want to use the OP's 2-CGL method.

But, remembering MSFS has higher quality compression than FS2Kx SDK Resample, a (1) CGL output 'may' still be OK to use.

That way MSFS' LOD switching can render higher LODs / MIPMAPs at / near ground, and lower LODs / MIPMAPs in flight AGL.


Otherwise we must (literally) sort out control of layering for aerial imagery 'draped' onto variable elevation terrain surfaces.

This process seems to be competing with Asobo's use of photogrammetry ...which also uses 'draped' aerial imagery.


How do we assign a higher display priority to our custom BGL aerial imagery relative to 'competing' Asobo photogrammetry ?

That is why I thought it might be useful to to better understand how we worked around this with FS2Kx SDK Resample.


Perhaps if I get some time free, I can find and link some threads on FS2Kx methods for superimposed multi-LOD aerial imagery.


FS2Kx uses aerial imagery 'draped' onto variable elevation terrain mesh as TMF grid-ed quads and triangulated TINs.

IIUC, Asobo has restored part of that legacy infrastructure to MSFS' SDK to allow more adaptability in MSFS scenery creation.


Like MSFS SDK, FS2Kx SDK Resample did not allow us to assign a "Priority" Layer number to 'draped' aerial imagery.

To some extent, we can do this by making 3D models as G-Polys, but that uses fixed ground shapes and UV-mapped textures.


We are wanting to control how 'draped' aerial imagery display relative to Asobo's internal display priority for photogrammetry,.

My suggestion was to review what we do in FS2Kx order to control display of (2) superimposed aerial imagery areas.


I believe this task compels identifying at what LOD / zoom level the ground will display after the user aircraft has taken off.

That is a function of distance, and conservative design principles make sense in planning what resolutions will be seen AGL.

In MSFS, distance determines vertical size of a sphere in the scene viewport to trigger LOD / MIPMAP switching.


So we should be able to compute the aerial imagery source resolution required for the visual display radius surrounding airports.

Since aerial imagery is not limited to display within the "Test Radius" of airport XML code, this calculation will be for TMF coding.


Dick shared hints on how a 3D model "Visual Display Radius" is computed for LODs / lights as a function of size / distance ...here:

https://www.fsdeveloper.com/forum/threads/msfs-scenery-lights.455868/

https://www.fsdeveloper.com/forum/threads/msfs-2024-lods.459913/post-933096


One might wonder if a comparable relationship exists for TMF mesh / draped aerial imagery as it does for 3D model LODs ?

Let us recall that FS2Kx has a LOD Display Radius:

https://www.google.com/search?q=FSX...fjD8IHBjAuMTQuOcgHNoAIAA&sclient=gws-wiz-serp


Scott Smart described the relationship of factors determining run time rendering in aerly FS2Kx:

https://groups.google.com/g/alt.games.microsoft.flight-sim/c/NtVv7emR_H8

"

scott s.​

unread,
May 3, 2009, 8:07:05 PM

to
Gregory <flights...@bkwds.comcast.net> wrote in
news:bfbsv4l70s7l7us0k...@4ax.com:


I'm not sure how it works in FSX, but in FS9 it is like this:

The world is defined as a set of tiles approx 1.3 km on a side (the actual size varies with latitude). each tile exists as a
4.8m resolution textures (256x256) with lower resolution mipmaps included. The LOD radius determines how many tiles are drawn for each mip level (and what mesh resolution is used) extending out from the point under the viewpoint. 4.5 gives 4 tiles at each mip level (this was the max for FS9). It's said (don't know if it's been proven) that FSX can go higher - 6 or more. The terrain draw system seems to be biased in that when the aircraft is moving, tiles in front of the aircraft get redrawn at next higher mip than tiles to the side.

scott s."


There was also a very large discussion years ago on the same subject at AVSIM (most of the valuable images are deleted now).


In MSFS:

"Level of Detail (LOD) settings in Microsoft Flight Simulator (MSFS) control the distance at which terrain and objects are rendered in high definition. The display radius is primarily managed through two main sliders in the graphics settings—Terrain Level of Detail (TLOD) and Object Level of Detail (OLOD)"

https://www.google.com/search?q=MSF...uAewBcIHBTAuMy42yAcigAgA&sclient=gws-wiz-serp

It merits testing whether our computers hardware can handle maxed out:

* Terrain Level of Detail (TLOD)

...and:

* Object Level of Detail (OLOD)

...if that allows us to still use photogrammetry with our own custom high and low resolution aerial imagery.


Also, if a comparable / compute-able relationship exists between distance / size / LOD display, we can plan our CGL resolution.

GaryGB

 

[lumat]

Thank you for this detailled post. Some things are beyond my skills and understanding, regarding the application to my files cgl ups :.But I'll reread it and the links tomorrow.
I'll try changing the level of details also.

For now, the area, even divided in smaller areas (approximately 7x5 kms), don't display at LOD/Zoom 19, 20, 21 I've tried. Except quite far away.
However, the "airport" area (3.5Kms x 1.6 Kms) is displayed perfectly, both up close and from a distance. This is not very clear to me.

 

[GaryGB]

It does indeed raise questions about how Asobo's MSFS default Photogrammetry is granted a higher level of display priority than custom aerial imagery CGL textures draped onto local terrain mesh.

IIRC, in MSFS 2020 RTM, all ground surfaces- and even grass objects- displayed a draped texture from MSFS default aerial imagery.

It seems now we may best regard MSFS default aerial imagery as a type of "vector Land Class", with both multiple layers of superimposed local mapped textures and terrain surface mesh, seen for example as fields with seasonal attributes and furrows when plowed, that impact user aircraft GroundRoll physics.

At first glance, it looks as though Asobo has begun to implement "Seasonal Photogrammetry".

Yet again I ask this question of "MSFS Insider Uber-Geeks":

Where is the FS2Kx "Terrain.Cfg" equivalent in MSFS, that we can study to allow 3rd party FS Developers to exclude- and/or use- such newer MSFS scenery content ?

Alternatively, how do we determine the display priority of such MSFS scenery content, so we can ensure display of our own custom scenery ?


I am not going to continue investing time and money in MSFS if it does not allow- / disclose how to perform- "total" customization by end users.


BTW: It would have been much more appropriate, IMHO, for MS-Asobo to re-code existing software for "MS Store XBOX Gamerz" retail package 'ingestion', rather than requiring the MSFS aviation world to not use upper case characters for ICAO's.

This is getting to be ridiculous watching major things be changed in MSFS without advance notice because Asobo is constantly trying to catch up on its compulsory task of (finally) getting the 3D world covered with scenery by delegating tasks to sub-contractors.

Then Asobo does not explain to the FS Development community how to access / use / customize / exclude the new scenery content originating from sub-contractors.

One might wonder if this is either because they do not own the rights to the content and it is licensed for use under an NDA, or Asobo is trying to maintain an advantage over 3rd parties when selling their own addons in the MSFS Marketplace.

Let us hope we can sort out some more of the undocumented issues with scenery content creation and display with cooperative efforts by FSDev forum participants.

GaryGB

 

[lumat]

Can we contact Asobo to ask them these questions and submit the problem ?
Maybe on MSFS DevsSupport ? MSFS Forum ?
By mail directly ?
Which is the most effective In your opinion ?

 

[lumat]

To try tomake some progress, I just ran a new test with Lod Terrain/Objects : max
Photogrammetry : On

I created a new CGL zone covering the airport and a surrounding area.
In MSFS 2020, In the menu, all is good. In flight, only the part of the image on the airport appears, the rest still under the default texture ! (Except far away)
I don't know if this might offer any insights. But for me, the more I search, the least I understand !
How MSFS can display only the part of the image in the airport area and hide the rest under his texture..... Maybe because I've a Terraforming polygon at this location ?

 

[GaryGB]

I believe you should post a link to your project with source files so that someone like Dick can see what your workflow is.

It is reasonable to do this before tugging on Asobo's sleeve, although it is your option to post at MSFS Dev Support forum.


If there is Terraforming local to the aerial imagery area, that 'may' impact the elevation at which the aerial imagery displays.

This may result in draped aerial imagery ending up at a different elevation AGL or Altitude AMSL ...than default photogrammetry.


What Terraforming did you do in this project at the area in question ?


If it were documented, I would speculate that MSFS default photogrammetry is placed via Altitude AMSL.

We can end up at a different Altitude by using AGL and by Terraforming, changing Terrain mesh source / run time settings etc..


If you flatten the entire area between the 2 airports of interest in your project, you 'could' test a projected mesh 'G-Poly'.


Do you want to exceed the available resolution of the ArcGIS.Clarity aerial imagery source from SASPlanet via oversampling ?

If not, MSFS projected mesh resolution is 'capped' at 4cm/pixel (which exceeds the approximately zoom level 18 of Google July 7, 2022).


That is not a problem if you want to simply sharpen that imagery in a graphics application before used in projected mesh.

If you do not want projected mesh resolution 'capping', then you would stay with the current goal of 'draping' aerial imagery.

GaryGB

 

[lumat]

I created a poly "Terraforming" on the airport's footprint, as always (pretty much like the area on the second screenshot).
The large area (purplish) does not have significant variations in altitude, but it's not completely flat

 

[GaryGB]

I am flying the MSFS 2020 default LFME now after having just flown the same ICAO with the Aeroclub president's MSFS 2020 Vol-1 package.

https://forums.flightsimulator.com/t/nimes-courbessac-lfme/500073

https://www.simvol.org/en/downloads/airports/nimes-courbessac


Be right back.


UPDATE: Yes, there is rather good photogrammetry in MSFS 2020 default that would be a shame to not use.

The Google imagery July 7, 2022 might be useful in the immediate vicinity of the aerodrome.

But at in-flight altitudes, one might find the default aerial imagery with photogrammetry in MSFS 2020 acceptable.

Is this for a personal project, or is it intended for public release ?


I am now going to check what this looks like in MSFS 2024 again (flew it yesterday).


UPDATE - again...

OK, MSFS 2024 has AFAIK, the same default photogrammetry, but different aerial imagery.

Asobo has biased the aerial imagery color palette for the "South of France" region.

That color palette it is probably too warm for Nimes, so I see a basis for new imagery.


And, it would be a crime to display this airport without the default photogrammetry... Asobo did a good job here.

I love the rail yard and auto parts yard at / near the LFME South approach.

(Even Google Earth did not have the nerve to put the junk auto parts into their LIDAR 3D photogrammetry).


I am not sure if there is an easy way to apply masks to shift color palette, but IIUC, it can be done (Bijan and another developer have done this).

So unless you make such color shift masks, you may have a large area to cover with aerial imagery.

Now you just need to get aerial imagery displayed along-side the MSFS default photogrammetry.

GaryGB

 

[lumat]

LFME ! It's not far ! It's in the area I want to correct You must have the same problem in MSFS2020

I'd love to be able to use the default photogrammetry, but as you can see in the screenshot, This area is awful in MSFS 2020 (In MSFS 2024 also but my CGL Works in 2024).
It's for a public release ! That's why I'm desperately trying to correct it. I do that for another airports. But it worked back then.

Just a side note: on Bing Maps, this area seem perfect now. Isn't the photogrammetry data downloaded directly from Bing to MSFS ? Or perhaps AOSOBO could update the Bing data in MSFS (I don't know, maybe it's too much work).

 

[GaryGB]

Indeed, there is a warm color palette and SW area of greenish mis-matched aerial imagery in MSFS 2020 that was only partially changed in 2024.

Not being personally familiar with the area, I would not know what else is objectionable to a local citizen.

It is true the BING imagery has a proper color balance compared to Google and ArcGIS imagery, but Google's July 7, 2022 seems sharpest.


It is possible to create a color mask on Polygons, and Mamu has a great tutorial on this I'll link to momentarily.

I wonder if we can create a Polygon with a transparent texture, and then apply a color mask or tint to it's "transparent texture" layer ?


You may wish to try an alternative to editing the color palette for aerial imagery all the way down South to the other airport in your scenery:


Mamu (aka Federico Pinotti) has a very nice video on using Polygons to fix a cloud in MSFS' default imagery in his video here:

The tutorial above by Federico Pinotti (aka "mamu") on YouTube shows how to create a Grass replacement Polygon via a Material 'close' in color / texture pattern, which can be further edited to match its color to that of underlying default MSFS MSVE (aka "BING") PR imagery:

The segment on that method is at 22:40 elapsed time.


PS: Be aware that MSFS apparently is increasing its run time 'realism' by superimposing content on top of the base photo-real aerial imagery layer, which IIUC, makes rendered terrain behave like PBR-enabled texture maps that IMHO generally look more 'accurate', with lighting and 'virtual' ambient occlusion shadowing that seems congruent to local 3D world environment context and time-of-day / season.

I have not yet seen documentation in the SDK as to whether this is added via BlackShark AI, or if this is new content added to terrain BGLs.

There may be some limitations as to how much of this newer "synthesized PBR land class" appearance may be achieved by end users / developers that utilize the aerial imagery tile method versus the Polygon / vector method for terrain textures ...both now, and in the future.

I'd love to be able to use the default photogrammetry, but as you can see in the screenshot, This area is awful in MSFS 2020 (In MSFS 2024 also but my CGL Works in 2024).
It's for a public release ! That's why I'm desperately trying to correct it. I do that for another airports. But it worked back then.

Just a side note: on Bing Maps, this area seem perfect now. Isn't the photogrammetry data downloaded directly from Bing to MSFS ? Or perhaps ASOBO could update the Bing data in MSFS (I don't know, maybe it's too much work).

AFAIK, some of the photogrammetry is reportedly rendered live in MSFS at run time based on processing of terrain textures and imagery.

Other aspects seem to be pre-rendered (BlackShark AI or its intended replacement by Asobo ?) and downloaded from MS Azure servers.


If Asobo refrains from fixing- and documenting- what it does with its photogrammetry, there may be ways to work around this via GEDOT.

We may be able to place custom aerial imagery photogrammetric-type layers as 3D G-Polys to replace the ground in MSFS photogrammetry.


If worst comes to worst, we can replace MSFS photogrammetry with custom photogrammetry made from the local (detailed) LIDAR data.

Again, this may be done via GEDOT, which utilizes the FS SDK TMF grid-ed quad scheme to segment 3D models into "faux "photogrammetry".


We can place a flatten under MSFS default photogrammetry / other scenery to hide it far 'below' a replacement layer - both @ AMSL Altitudes.

GaryGB

 

[GaryGB]

Hi again:

I am in 2024 now, getting an anomaly at the 'Garons Navy' airport with intermittent display of either green grass colored imagery or the default.

It is the classic 'diamond' shape of rectangles surrounding the aircraft, best seen in external view.

This is seen with 2 superimposed layers of imagery, and with a different layer of imagery seen inside and outside the diamond of rectangles.

I have not seen this yet at Courbessac, but will test some more.

GaryGB

 

[lumat]

Hello

In 2024, there is the same problem, I can correct the texture with CGL, as my two screenhot show (Same CGL file, Photogrammetry "ON"). My CGL is displayed correctly above the default one.
I don't understand why isn't it working anymore in MSFS2020

 

[rhumbaflappy]

This linked thread was dated March 2022: https://devsupport.flightsimulator....gery-wont-display-with-photogrammetry-on/3939 So the problem has been with MSFS 2020 forever.

 

[GaryGB]

In MSFS 2020 - Photogrammetry "ON"

I do not see a 2020 "diamond" LOD quad anomaly at Nimes-Courbessac LFMH, but I do at LFTW Garons after long flights on PG


I do not see a 2020 aerial imagery anomaly at Nimes-Courbessac LFMH ...when this cited aerial imagery is loaded:

https://www.fsdeveloper.com/forum/t...ture-below-the-default-one.460828/post-939982


However, when the above cited scenery is loaded, the Photogrammetry (aka "PG") ...vegetation disappears.


LFMH Nimes in TopDown view: when Mouse Wheel scrolls the camera up away from the ground, I see aerial / PG swapping

LFTW Garons in TopDown view: when Mouse Wheel scrolls the camera up away from the ground, I see aerial / PG swapping


In MSFS 2020 - Photogrammetry "OFF"

LFTW Garons in TopDown view: when Mouse Wheel scrolls the camera up away from the ground, I see NO aerial / PG flickering


Searching on this a bit more, I tried this query at Google, and got these replies regarding the anomalies with MSFS 2020:

https://www.google.com/search?q=MSFS+DevSupport+bugs+with+CGL+imagery+MSFS+"2020"+site:+devsupport.flightsimulator.com&client=firefox-b-1-d&hs=4flp&sca_esv=33d040cb389eca3f&biw=792&bih=387&ei=p4_raYDPDPSjptQPycDhuA8&ved=0ahUKEwjAvuSF6oaUAxX0kYkEHUlgGPcQ4dUDCBE&oq=MSFS+DevSupport+bugs+with+CGL+imagery+MSFS+"2020"+site:+devsupport.flightsimulator.com&gs_lp=Egxnd3Mtd2l6LXNlcnAiVk1TRlMgRGV2U3VwcG9ydCBidWdzIHdpdGggQ0dMIGltYWdlcnkgTVNGUyAiMjAyMCIgc2l0ZTogZGV2c3VwcG9ydC5mbGlnaHRzaW11bGF0b3IuY29tSABQAFgAcAB4AJABAJgBAKABAKoBALgBDMgBAPgBAZgCAKACAJgDAJIHAKAHALIHALgHAMIHAMgHAIAIAQ&sclient=gws-wiz-serp


Of particular note is this interesting post series by Dick regarding another aspect of this scenario:

https://devsupport.flightsimulator.com/t/fake-brown-fields/10321


An earlier post by Sasa in that thread states the anomaly occurs if AFD-type Airport infrastructure surface types are not selected:

https://devsupport.flightsimulator.com/t/fake-brown-fields/10321/11


Historically FS2Kx AFD-type Airport infrastructure surfaces had unique display priority values; have these changed in MSFS ?


[EDITED]

Another potentially relevant incidental discovery found chasing links on the above query, is this thread:

https://devsupport.flightsimulator....photogrammetry-buildings-in-msfs-2024/16892/5


https://devsupport.flightsimulator....photogrammetry-buildings-in-msfs-2024/16892/6

"projected meshes are applied on TIN but do not change the elevation"

"check if you have the Apply Flatten property checked in your airport object properties"

"Although very practical, this option is not very appropriate when the airport is surrounded by TINs, and you should probably disable it and replace it with your own custom terraformers."


https://devsupport.flightsimulator....photogrammetry-buildings-in-msfs-2024/16892/9

"The “apply flatten” is indeed interpreted differently between MSFS 2020 and 2024. In 2020 only the aprons is used to compute the rectangle that is flattening the airport.

In 2024 we also take into account runways. Your airport have almost no apron, so in 2020 it is not flattening anything.

A fix for this backward compatibility issue should be available in the next SU5."



I am not yet certain how to deal with this as it involves multiple run time rendering and LOD display visibility distance issues.

[RANT_MODE_ON]

OMG, when is this nonsense with airport flattens for AI Taxi Traffic going to stop ?

Performance hits from other scenery indulgences is likely far worse than 'inching' AI aircraft over uneven (IRL) ground surfaces.


ASOBO, PLEASE STOP ACCOMMODATING ANCIENT, UNREALISTIC-TO-IRL, MSFS AI TAXI METHODS.


AFAIK, MSFS has so much 'optimized' performance potential, we can now start moving AI Traffic like IRL: over uneven ground.

[/RANT_MODE_OFF]

[END_EDIT]

GaryGB

 

[lumat]

Yes, I see, Dick. But I never had this problems on my sceneries. I sometimes made some CGL to correct some areas around my airports. Of course, this is only my experience, on my sceneries.

Here, for this scenery, I have no problem anyway with the texture on the airport area itself , which displays correctly. On the screenshot, we can see my texture displayed correctly at this location (No reworked for now ).
The problème appears only in the surrounding area. It's that I search to understand.

I see 2 differences between the 2 areas, The size of the area, and the flatten I created on the airport, I don't know if that explains the problem

Gary, please, if you have the opportunity, can you confirm you have the same view as in my capture "Area to correct" on MSFS2020 ?

Finally , I'm starting to think that perhaps, there is no way to fix this kind of aerial texture problem in MSFS2020 ...

 

[GaryGB]

I think that there may be a possibility to fix this.

However, we have gone rather far, without the benefit to those attempting to help you ...having your project files to examine.

I do understand if you prefer to keep such files out of the public forums as you may plan a payware release when finished.


But Dick and I (and many other reputable long time members of FSDEV Community) are committed to discrete confidentiality.


I believe both Dick and me would be better able to help, if you send us a direct message with a link to the project under discussion.

It is also possible insights might be gained in this troubleshooting scenario, that may help you- and Asobo- produce a fix ASAP.

GaryGB