• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

MSFS20 Custom aerial texture below the default one

I believe the "problem" can likely be worked around.

However, I also believe that the requirements to create a project structure in advance that MS-Asobo imposed before one can even get the SDK working live within MSFS ...is effectively a deterrent to both development and troubleshooting.

In prior years, "BBS" use for communications / downloads, required earning prior credits in advance by contribution of uploads.

Unfortunately an increasing number of FSDEV forum users apparently have come to expect that they can get something of presumed benefit without also contributing something to facilitate that which they may assume... they are somehow entitled to receive.

I am less inclined to offer assistance to FSDEV Community participants when they are not willing to provide even rudimentary prototypes of projects, or even accurate sets of Geographic coordinates, to enable prompt analysis of their scenery by would-be helpers.

This process has become entirely too one-sided at FSDEV; people want help, but expect to do little- or nothing- to facilitate the process.

It was bad enough before MS-Asobo dangled a 'carrot-on-a-string' implied benefit of being a package retailer in the MSFS marketplace.

Now that we also have flightsim.to selling packages, it seems people are overly concerned with perceived competition and a need to be secretive.

In some cases newcomers may have a fascination with the idea of becoming a "FS Developer", but assume they are able to receive custom tailored one-on-one tutorials as a substitute for putting in time doing the work of reading, retaining, testing, and understanding in order to achieve the genuine skills they may wish to have.

The increasing refusal to disclose info to would-be helpers here at FSDEV is likely to diminish- or end- the willingness to help people at FSDEV (by me, at least).

Part of this is due to an influx of newcomers with a perceived assumption of attainable fame and fortune in the FS addon market


Others seem to be Seniors who hope to get help from others as they endeavor to stay active with a hobby while attempting to cope with declining functional capacity due to age and medical infirmity.

Most of us would prefer to be generous and helpful to others at every opportunity.

But the simple fact IMHO, is that FSDEV has become viewed as a preferred website for getting authoritative info and free help, without having to contribute to the helping process.

This is a mistaken assumption, and one which would ultimately lead to an eventual end of anyone being ready / willing / able to help others.

Only an AI Chatbot would tolerate that type of imposition by people who want something without acknowledging they may need to be forthcoming in order to 'help others to help them'.

I suggest that in troubleshooting threads here at FSDEV, people seeking help should plan on contributing to the helping process at the request of the would-be helpers, and provide info requested, or be prepared to be refused help ...due to lack of necessary info required to proceed.

We all want to believe there may be help available when we are striving to accomplish something, and we may subsequently, in our sense of urgency, place unfair expectations and demands on others that we assume might be best able to help with a particular challenge.

I have the impression that Dick- in this thread- was not ready / willing / able to accept this particular challenge, at this particular time.

And since I imposed an unfair supposition on him, I shall offer my apology to him here.

But I do hope he can in the future, restore his sense of optimism about the possibility that Asobo will eventually fix this thread's troubleshooting issue.

I shall consider exploring possible ways to resolve his type of display anomaly in the future, and do not plan to leave it up to Asobo to fix.

However, I shall look into this on a time schedule more convenient to me.

GaryGB
 
Last edited:
Gary, I understand your position.

As far as I’m concerned, I don’t refuse to send my aerial textures if it can help to find a solution.
I'm not asking anyone to do the work for me either. I simply shared a problem hoping to find help from people knowledgeable in this specific case or who have already encountered and solved it.

Finally, I think it's only fair to offer the final scenery to those who have agreed to dedicate time to finding a solution.


Dick, I can see that this is an old problem.

Actually, I just wanted to understand:

- why my CGL texture works on the airport but not on the surrounding area (Perhaps it's related to the flatten polygon only covering the airport, or the size and terrain of the surrounding area...).

And possibly find out:

- If there's a solution I might have missed.

- If it's simply an ASOBO problem that can't be solved.
 
Hi Luc:

This is just (1) of the threads I plan to review as I watch my Direct Message mailbox status for a new message (none yet today ;) ):

https://devsupport.flightsimulator....-weird-low-res-when-photogrammetry-is-on/4642


BTW: It was comparatively easy (for me) to find this, and then not only post a link, but also quote a significant part of replies by Asobo:

"FlyingRaccoon

August 31, 2022, 9:12am 4

Hello @Verticalsim

Regarding the low resolution, we have potentially identified an issue with not exploiting all the secondary aerial LODs when TIN is enabled. This will be investigated and fixed by our engine team.

Regarding abrupt transitions with TIN area, we have no solution for this at the moment.

You’ll notice we don’t have a smooth transition at the edge of TIN areas in general and tend to choose the border so that it’s less noticeable.

You either want to do like us and set up your TIN exclusion shape so that its border is less noticeable or use projected meshes instead.

Regards,
Sylvain"


https://devsupport.flightsimulator.com/t/su1-beta-graphic-bugs-with-cgl-imagery/13257

"April 7, 2025, 8:26am 6

Hi,
The issue occurs when there is a secondary aerial on TIN. A shader try to get color details from the TIN and apply it on the custom aerial.
We have found a fix but it will probably not be ready for SU2.

However there is a workaround, a polygon with “exclude TIN” will allow to only display the secondary aerials. But it will cause discontinuity on the border of the polygon (you can see that on your second screenshot, there is a exclude TIN on the left side causing these white blocks).

So be sure to make it larger than the second aerial zone.

Regards,
Xavier / Asobo"


The above threads are in hits found using Google, since MS-Asobo decided use the P.I.T.A. 'Discord' for MSFS support forums:

https://www.google.com/search?q=site:+https://devsupport.flightsimulator.com/+photogrammetry+aerial+imagery&sca_esv=71797cf33852cfd3&source=hp&ei=n_vtaey1C9KNmLQPlqLLgQQ&iflsig=AFdpzrgAAAAAae4Jr-OqQK4H3sZi0w5C6x84S0iXqYun&ved=0ahUKEwisgceluYuUAxXSBoYAHRbRMkAQ4dUDCBw&uact=5&oq=site:+https://devsupport.flightsimulator.com/+photogrammetry+aerial+imagery&gs_lp=Egdnd3Mtd2l6IktzaXRlOiBodHRwczovL2RldnN1cHBvcnQuZmxpZ2h0c2ltdWxhdG9yLmNvbS8gcGhvdG9ncmFtbWV0cnkgYWVyaWFsIGltYWdlcnlIn64CUJ8MWNGVAnABeACQAQCYAXigAfQZqgEEMzIuNbgBA8gBAPgBAfgBApgCF6ACvBOoAgrCAgoQABgDGI8BGOoCwgIKEC4YAxiPARjqAsICERAuGIAEGLEDGIMBGMcBGNEDwgILEC4YxwEY0QMYgATCAg4QLhiABBixAxjHARjRA8ICBRAuGIAEwgILEAAYgAQYsQMYgwHCAgsQLhiABBjHARjRA8ICFBAuGIAEGLEDGIMBGMcBGK8BGI4FwgIIEC4YsQMYgATCAggQABiABBixA8ICDhAuGMcBGLEDGNEDGIAEwgILEC4YgAQYsQMYgwHCAgUQABiABMICCBAuGIAEGLEDwgIEEAAYA8ICCxAuGK8BGMcBGIAEwgILEC4YgAQYxwEYrwHCAgcQIRgKGKABwgIFECEYqwLCAgUQIRigAZgDGPEF0Ysrx2pvjaeSBwQ1LjE4oAeOlAGyBwQ0LjE4uAekE8IHCDItMTAuOS40yAf_AYAIAQ&sclient=gws-wiz


Now to test my memory as to whether projected mesh drapes imagery on uneven ground, or if it only works on a level (airport ?) flatten.


PS: Info already cited points to a short-term solution (...yes, Asobo is aware of this and likely to resolve how to fix it eventually).

A short term solution IIUC, is to either forfeit (local quad ?) photogrammetry versus all photogrammetry throughout MSFS via settings.


Hmmm... local... vector... TIN mesh... what size "clip" is used for vector data in MSFS compared to FSX / P3D ? :scratchch

Perhaps QMID-11 ?


FYI: QMID-11 quads are 19.5681 kilometers in extent on ground; it is subdivided as 256x256 Area Points of 76.4 Meters extent each.


FS SDK TMF Grid Quad / Area Point Table:

https://www.fsdeveloper.com/forum/threads/flattens.425495/post-633002


CAVEAT: Sean Isom cited odd CGL coding for quad borders versus placed objects when they extend over CGL quad borders.


We are able to intercept vector objects and exclude them throughout a defined extent for poly-lines and IIRC for polygons.

A TIN is a vector object made of multiple triangular polygon Faces with aligned adjacent sides / vertices that form a "mesh".


Can we not exclude a TIN with a tiny triangle (or surrounding polygon) and only impact a quad extent of a defined TIN "clip" size ?


In pre-FSX FS2Kx, "clip" extents for LWM vector objects is LOD-5 / QMID-7

In FSX "clip" extents for (most) CVX vector objects is LOD-9 / QMID-11 (LOD-13 / QMID-15 for Freeway Traffic)


A "Exclude And Replace" mandatory rule applies to all contiguous object parts intercepted by discrete vector excludes.


AFAIK, we exclude vector objects via a small triangle within a quad "clip" extent, and replace it ...VOILA. (aka "Bob's Your Uncle") ?

IIUC, the same may apply with TIN photogrammetry mesh; we used to do this in FS2Kx before; why should we not do it now ?


Let us test if granularity of 'exclude TIN' is separate from 'exclude PG 3D models' and 'exclude 2D legacy type terrain vectors'. :pushpin:


So, how to 'replace' photogrammetry ?

Perhaps "GEDOT" ...which makes 3D model-based photogrammetry, rather than (currently) problematic CGL vector photogrammetry. :idea:

https://thalixte.github.io/Google-Earth-Decoder-Optimization-Tools/


IIRC, GEDOT does not require Google ripped 3D content, to process Blender 3D models into optimized MSFS SDK compatible output.


One may wonder if MCX can be a tool to make optimized 3D models without Blender, for use as 3D G-Poly "combined scene" faux-PG.


Now to see if "clip" extent for TIN mesh is quad-based / what LOD it is, within FS' SDK TMF scheme of quads ...grid willing. :p


If we know TIN clip extents we must replace, we can use GIS apps to make replacement photogrammetry from LIDAR DSM data.


"Qgis2threejs is a QGIS plugin that visualizes Digital Elevation Models (DEM) and vector data in 3D within web browsers, allowing for interactive 3D scene creation, web export, and model exporting in glTF formats. It supports extruding 2D shapes, draping satellite imagery over terrain, and exporting interactive scenes."

https://www.google.com/search?q=Qgi...MwLjG4B5EBwgcFMy0xLjHIByOACAE&sclient=gws-wiz




https://www.sigterritoires.fr/index.php/en/loading-ign-france-hd-lidar-data/


https://www.google.com/search?q=QGI...HsxjCBwkwLjEuMy44LjXIB-8BgAgB&sclient=gws-wiz


https://www.google.com/search?q=Fra...6IbwgcJMi0xNC4xMC44yAf1AoAIAQ&sclient=gws-wiz

GaryGB
 
Last edited:
Hi Juc:

I do have the download; it's transferring over my network to my MSFS 2020 installation and \Community folder for inspection.

I may be able to offer some feedback within an hour or so. :coffee:


Thanks for providing a worked example to explore options for troubleshooting and potential work-arounds. :)

GaryGB
 
Hi Luc:

Your package does show nearly all of the anomalies Asobo alluded to in posts at MSDevSupport forum.

I plan to derive Geographic coordinates for the aerial imagery areas involved, and do some tests to verify what factors impact rendering in the project area, to see what may be done with the raster component.

I also plan to test vector excludes and replacements to verify what factors impact rendering in the project area.

I hope to have more info to report tomorrow (Tuesday) later in the day (USA Central / Chicago Time Zone)


GaryGB
 
Last edited:
Yes Gary, Normal, I followed the SDK and the samples :)
I wonder if the aerial textures need a terraforming poly. That would explain why only the airport zone is displayed.
 
Hi Luc:

To be clear, the description I gave above was only intended to identify the fact that your scenery was rendering in ways Asobo already cited.

It was of course, not intended as a reflection on anything you may have done / not done while following MSFS SDK methods (that have 'issues').


[EDITED]

Part of what may be tested is a Terraforming polygon that creates a ground surface, to slightly raise / lower the placement of aerial imagery. :idea:

[END_EDIT]


However, IIUC, if a collision attribute and ground altitude is applied to photogrammetry, it may compete to be FS' local ground Altitude AMSL.

So, AFAIK, one might wish to test placing a projected mesh as a G-Poly at the airport using Altitude AGL.


If you test this, please post your results here so we can see if MSFS attempts to control actual rendered Altitude of the G-Poly at run time. :)

GaryGB
 
Last edited:
Tomorrow (Wednesday) I plan to test CGLDEC on the CGL file to see if I can extract Geographic coordinates.

We'll compare notes then. :)


PS: I can confirm France's LIDAR HD elevation data is immediately available for download in tiles via their web portal.

I have not yet looked at what imagery they have available in the event you wish to drape it onto DSM-derived replacement photogrammetry for MSFS.

GaryGB
 
Last edited:
Back
Top