• 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 photogrammetry - alternatives to google earth decoder?

Messages
18
Country
germany
since the "google earth decoder" is not working anymore are there any alternatives to download and use custom photogrammetry data for msfs projects?
 
Hi again:

You may wish to do a Google search using your own statement as a query string:

<CODE>

"google earth decoder" is not working anymore

</CODE>


You may be able to find updated info on imagery tile server source version numbers in the QGIS community forums. ;)


As you may know, it is possible to make photogrammetry for MSFS via either 3D "tile" sets, TINs or a derivative of both, output as 3D models.


QGIS and/or other GIS applications can use LIDAR DSM-type elevation data sets to make TINs.


QGIS and/or other GIS applications can use LIDAR DTM-type elevation data sets to make 'gridded' terrain elevation source data.


MSFS TIN-only photogrammetry is compiled into CGLs and draped with default or custom aerial imagery.


3D models may be mapped with default or custom aerial imagery and/or texture Materials as glTF's compiled to BGLs in MSFS packages.


AFAIK, the best tool set for making 3D model photogrammetry is GEDOT (aka "Google Earth Decoder Optimization Tools").


You may wish to review the info on GEDOT I posted here at FSDEV, that is linked from a Google search using this query string:

<CODE>

site: www.fsdeveloper.com GaryGB GEDOT

</CODE>


GaryGB
 
Last edited:
Hello GaryGB,

Thank you for the in-depth information. I'm really impressed! This is one of the few online forums where members not only have a wealth of hands-on experience with proof-of-work corresponding knowledge, not only willing to share it, but also take the time to answer every question in detail. That's rare and truly outstanding!

Thanks to your tip, I found a version of the Google Earth Decoder on "flightsim.to" that's up to date and still works. For privacy reasons, I use "Startpage," but unfortunately, the search result didn't show up there but it's listed on Google.

I have one more question regarding this topic. Maybe you'll have time to answer it.

Right now, for my hobby projects, I'm using the following workflow for my own aerial images: "Download XYZ tiles with QGIS -> Convert with Tiles2Bing -> Compile with the fspackagetool on the command line" to ultimately create packages that can be directly used with MSFS. It’s actually straightforward and pretty simple; it just takes a little time to compile.

Of course, the photogrammetry data is missing in this process.

Now here’s the question: Do you know of—or can you imagine—a similar, simple, and straightforward workflow for the photogrammetry data? Specifically, downloading the data via QGIS and compiling it directly with the FS Package Tool (without having to make any further changes in the SDK) and being able to use the photogrammetry data directly for the scenery for which I’ve already created aerial CGLs?

kind regards
 
3D model photogrammetry is made via the GEDOT process, with UVW mapped textures on the Faces of those glTF 3D models.


TIN photogrammetry is made via the GIS process, with 'draped' textures on the Faces of those TIN terrain surfaces.

MSFS can 'drape' textures onto the top and sloped sides of TIN terrain surfaces.


3D model photogrammetry made via the GEDOT process, with UVW mapped textures on all Faces of glTF 3D models may be required prior to output as TIN format source data for CGL compiler features accessed via FSPackageTool (which likely can also be done via CMD line routines).


Underlying MSFS default BING aerial imagery can be transposed on the top Faces of those TIN terrain surfaces like a "bleed-through".

Alternatively, custom aerial imagery can be draped on the Faces of those terrain vector TIN surfaces like a "bleed-through".


Reportedly, MSFS aerial imagery transposed as a drape onto Faces of custom terrain vector TIN surfaces is a W.I.P..

Reportedly that MSFS run time rendering process does not yield all higher LODs for custom aerial imagery on top of contiguous photogrammetry vector terrain TIN surfaces.

There are assertions Asobo is not committed to fixing this in MSFS 2020, but may do so for MSFS 2024; others say both versions will be fixed.

In addition, some MSFS terrain textured areas such as agricultural fields, are beginning to be configured with a top layer of higher resolution photogrammetry vector terrain TIN surfaces which impact GroundRoll of the user aircraft, as well as providing seasonal (synthetic ?) ground texture Materials.

It is not clear to me yet, whether / how these " terrain topper" ground cover areas may be acessed / utilized by end users for custom development purposes.

These MSFS areas appear to be like FS2Kx "Land Class on Steroids"; IMHO, they look good where I see them used thus far, but I do not know yet how they interact with custom aerial imagery and / or photogrammetry.


What is your personal output format preference for custom photogrammetry: 3D glTF models, or terrain vector TIN surfaces ? :scratchch


GaryGB
 
Last edited:
hey GaryGB,

cool - you have some pretty accurate insights into the future development of MSFS. i have to admit that i'm impressed by your background knowledge.

since I'm only using the 2020 version, i'd prefer the simplest way to add photogrammetry data to custom scenery. i was using the 3D gITF data workflow via Google Earth Decoder but i am really short on time for these projects and the tweaking of the data with Blender is too time consuming. in your opinion, what would be the best option for a simple and quick solution? is it possible to add (BING) photogrammetry data to custom scenery that is downloaded and made available locally via QGIS without any further conversion?

best regards
 
AFAIK, it is likely any- and all- BING 'photogrammetry data' available has already been implemented in MSFS via MS' AZURE content servers.


What specifically do you want to enhance for photogrammetry ...beyond existing content already available in MSFS ?


Where specifically in the FS world do you want / need to enhance for photogrammetry ...beyond existing content already available in MSFS ?

GaryGB
 
hey GaryGB,

first of all i was thinking about downloading BING photogrammetry data because of backward-engeneering the data structure since any documentation about this is not avaiable. secondly i wanted to provide BING data for my offline scenery understanding how it is implemented and placed when it is served offline. and then finally i was aiming towards integrating photogrammetry data from other sources like google or cesium to my scenery if possible matching the BING data coordinates and preferences exactly without any time consuming editing.

The most common—and apparently the most widely used—option right now is to use gITF: data from Google via Earth Decoder, which you can then adjust in Blender beforehand. I’ve also wondered if there’s an easier, more precise way to use this data without editing it with Blender.

but apparently this is not the case. thank you for your informations!
 
If you have texture-mapped 3D tiles to use for photogrammetry from non-Google sources, GEDOT 'may' still work.

The output will be segmented 3D model glTF's; these are more difficult to edit for certain things in MSFS.


Otherwise, GIS can process texture-mapped 3D models merged / welded into TIN surfaces to use for photogrammetry.

MSFS TIN photogrammetry objects are easier to edit for certain things.

GaryGB
 
Hello GaryGB,

I’ve already noticed that the gTIF method comes with some issues that I’d also like to avoid, since troubleshooting and implementation are very time-consuming.

In that regard, your mention of using TIN data from GIS sources (Cesium?) is interesting. Of course, I understand that you might not necessarily want to share your edge in knowledge, since this is an advanced, professional approach that could potentially give you a competitive advantage when creating commercial third-party add-ons. So far, most authors—presumably mainly hobbyists—seem to be using the gTIF method.

However, since I don't create commercial add-ons, could you give me an idea of what the workflow (using QGIS?) for your method might look like? Feel free to send me a private message - and of course, in that case, I wouldn't publish any information about your workflow and would only use it for my own personal scenery projects.

Thanks and best regards
 
Creating custom photogrammetry any better than MSFS default can be rather complex, and results depend on many factors.

I suggest first conducting an extensive study of MSFS' default photogrammetry before attempting to make / use custom content.


I suggest next to conduct an extensive study of the topic online before attempting to make custom photogrammetry.


I would caution that this type of custom content creation may be costly in terms of data access licensing and production time.


Additionally, one may find expensive commercial software proves most efficient to use in making custom photogrammetry.

However, that expenditure may prove nearly useless if the local area of interest does not have quality source data available.


Simply stated, this type of undertaking for MSFS content is not a "turn-key" operation; rather it is one of the most complex.

It would also prove to be beyond the scope of available free time I would personally have for an interactive tutorial process.

You may wish to start your inquiry with a Google search using this simple query string:

Code:
 QGIS Photogrammetry


If you are in the cockpit most of the time, you may find MSFS' default scenery acceptable to use at in-flight Altitudes.

If you undertake creation of custom scenery content, you may find you spend more time NOT flying and enjoying the scenery.

GaryGB
 
Back
Top