MSFS24 Packing Google Maps tiles textures in Blender?

[Keinowaara]

Hello all! This is my first post here and my knowledge is very limited on all developer stuff so bear with me.

I've done some Google Maps tiles import based sceneries, either as straight imports without going to Blender and then some Blender imports, where I've e.g. removed trees and unnecessary ground (basically aiming for only the buildings). When I import and then export through Blender I understand that the textures get compressed (baked?) way more. With "straight imports" I only get to do the conversion in MSFS2KTX2 app and the file sizes are bigger. Right?

My problem is this: (1) I would of course love to compress the textures in any case but (2) there are also sceneries where I can't use the straight import because the sim terraforming is so wrong that I can't cut away the ground in Blender (nor take away the GM trees for the same reason). So far I've been doing this if that's the case. I import the scenery, convert the textures, open the scenery in SDK, place it, exclude buildings, then make a terraforming polygon with 100–200 m falloff, lower the sim ground level so that only GM mesh is visible throughout. It looks great with a bit of fiddling and the sim somehow makes the LOD level transitions smoothly and it always looks crisp an clean. But the file size of the scenery is unnecessarily big and at least my RX 6800 XT suffers quite some popping and especially blocky GM trees. Whereas I'm having problems with the LOD transition smoothness and quality of textures when use the other route: import the GM data, convert the Albedo textures, open the scenery project in SDK, remove initial ModelLib, create new asset --> ModelLib, open the GLTFs in Blender, group in collections according to LOD, merge mesh, make all edits and removals, clean up, export as collections, open project again in SDK, build all, place scenery object, make exclusion for buildings and finally build.

Whether I join the certain LOD level tiles all together or leave them as separate, try LOD values according to SDK suggestion tables or follow the advise to just leave as "0" for the sim to decide (which I understand it will do anyway?), it's still popping, but in addition, it's also too aggressive with the switching (especially close to area edges, even if you're still flying above the scenery). And it's the same project, essentially, but you'd think the way heavier "straight import" would act worse. Why is this?

Could a compromise solution work? I would take the "straight import" approach and even build the package, then import the textures, open the project GLTFs and textures in Blender, do nothing else but immediately export them — they would have been compressed / baked in the process? Then I'd sneakily replace the original project textures with these ones, open the project in SDK, use build all. Could this work or would I break some dependency or stuff?

Excuse me for a probably stupid question, and I know I could simply just try. But I'd also love to hear your thoughts on these points. Thanks in advance!

 

[GaryGB]

Hello:

I believe your inquiry, when an answer is received for all its questions, will be helpful to others here.


Because there are (still) some differences in MSFS 2020 and 2024, it is important to distinguish the requirements for each.

To distinguish those requirements, I recommend in the future to always identify which version of MSFS your posts pertain to.


To help FSDev index, and forum participants to follow / contribute posts to- your thread(s), it will be important for you to:


* Please state which version of FS this thread pertains to; edit your first post (aka "Opening Post" aka "OP") to insert this info.


Choose a FS version that is subject of a thread by clicking the 'down arrow' next to "(No prefix)" ...when starting new threads.


It is a good idea to go back and edit your posts to add the MSFS version prefix while you only have a few posts here thus far.

Thanks.


I do not have time to reply to the full extent of your post above until later, but I may have some practical observations to offer.

Are you familiar with Google Earth Decoder Optimization Tools (aka"GEDOT") ?

GEDOT

thalixte.github.io

Most of what you seem to have learned through extensive self-study is able to be done for you semi-automatically via GEDOT.

But you show insight into alternate options for producing these types of 3D models that others here may wish to learn.


MSFS developers may find your methods useful, along with those of GEDOT, to make custom photogrammetry replacements.

We may find that use of 3D models derived from multiple data sources other than Google may prove useful as another option.


Flightsim.to has allowed upload of Packages using Google derived content, so I will not comment on the legal issues here.

At this point we are just seeking a better understanding of how to optimize MSFS scenery development.


FYI Some threads here at FSDEV where I have discussed GEDOT:

https://www.fsdeveloper.com/forum/search/2425960/?q=GEDOT&c[users]=GaryGB&o=date

GaryGB

 

[Keinowaara]

Hello:

I believe your inquiry, when an answer is received for all its questions, will be helpful to others here.


Because there are (still) some differences in MSFS 2020 and 2024, it is important to distinguish the requirements for each.

To distinguish those requirements, I recommend in the future to always identify which version of MSFS your posts pertain to.


To help FSDev index, and forum participants to follow or contribute posts to- your thread(s), it will be important for you to:


* Please state which version of FS this thread pertains to; edit your first post (aka "Opening Post" aka "OP") to insert this info.


Choose a FS version that is subject of a thread by clicking the 'down arrow' next to "(No prefix)" ...when starting new threads.


It is a good idea to go back and edit your posts to add the MSFS version prefix while you only have a few posts here thus far.

Thanks.


I do not have time to reply to the full extent of your post above until later, but I may have some practical observations to offer.

Are you familiar with Google Earth Decoder Optimization Tools (aka"GEDOT") ?

GEDOT

thalixte.github.io

Most of what you seem to have learned through extensive self-study is able to be done for you semi-automatically via GEDOT.

But you show insight into alternate options for producing these types of 3D models that other here may wish to learn about.

MSFS developers may find your methods useful along with those of GEDOT to make custom photogrammetry replacements.

Flightsim.to has allowed upload of Packages using Google derived content, so I will not comment on the legal issues here.

At this point we are just seeking a better understanding of how to optimize MSFS scenery development.


FYI Some threads here at FSDEV where I have discussed GEDOT:

https://www.fsdeveloper.com/forum/search/2425960/?q=GEDOT&c[users]=GaryGB&o=date

GaryGB

Thank you Gary, for a quick and useful reply! And sorry, of course I should have stated the version which is MSFS 2024.

I do know Thalixte's ingenious tool and I've been desperately trying to get it to work for me but I keep running to some missing Python components and misconfigurations. There aren't many Blender versions that I haven't already tried with it. Some have worked partially but what I'm most interested in, the removal of trees, and sometimes the scenery optimization are where the tool breaks for me.

To further clarify, the MSFS 2024 latest SDK introduced a new Blender plugin which works at least with Blender 4.5 like a charm. Still it's a frustrating process to manually cut away all the tree vertices, and most of them you can't anyway because they are connected to the buildings. And the removed trees do leave a hole into the mesh which forces you to place the GM ground below the sim's mesh and that isn't often ideal.

But this weekend I might take a shot trying to import / export the scenery with no other modifications just for the texture packing. I'll report back what happened.

And yep, I've been wondering too about flightsim.to allowing GM derivatives... The latest uploads I have made there I've received a flag about that from the AI but I've left it for closer review — which they have approved anyway. We'll see if that changes at some point.

 

[GaryGB]

Hi again:

I just downloaded / installed your MSFS 2024 Tikkurila- Vantaa - Helsinki area add-on "Tikkurila Area, Finland":

https://flightsim.to/addon/103599/tikkurila-area-finland


When I import [install_path]\vomitairlines-tikkurila-area\scenery\vomitairlines\modelLib.BGL

...into MCX v1.9.2026.0612-devrel, I see this:


Complex Shader ON:

https://www.fsdeveloper.com/forum/a...100116/?hash=8e13b3469e518981882d2147ec234b74


Complex Shader OFF:

https://www.fsdeveloper.com/forum/a...100115/?hash=8e13b3469e518981882d2147ec234b74

Additionally, one can see that the 3D ModelParts are very low fidelity (due to decimation ?) with distorted textures.

Perhaps Arno may wish to load this same scenario and tell us if MCX can help with your workflow methods ?

GaryGB

 

[Keinowaara]

Thank you again, for taking time to look into this! Really appreciated.

That's interesting, first of all that you can look at it like that. I think I've downloaded MCX but haven't yet had the time to learn and use it. Clearly I should. And interesting in that respect, too, that this scenery is as straight import as any, one of the first ones I made. It behaves quite well in the sim and — as can be seen from the screenshots — looks good as far as buildings go. (The trees are another matter...) When I did this scenery I didn't yet know how to eliminate ground elevation discrepancies and there are areas where a strange, almost sand-like texture lies above the proper ground mesh. Also, I didn't know how to use Blender and remove trees.

Actually this got me to writing my thread. If you fly almost anywhere in Vantaa area (in the vicinity of Helsinki airport) without any add-ons of that area the ground levels and textures are a mess. Hard to tell where they've got their mesh from there, particularly when you take a look at Bing maps in which they look quite correct. At some places you can see large rectangular areas with that strange "muddy" texture overlaying something that looks like the proper mesh. As a consequence the roads get obscured, trees are poking through half-height and buildings are drowning in that ugliness. So there is a nice scenery somewhere below but someone has laid a terrible slab on it. There are also some knife-edge-like 10 m high "ridges" visible at places. I guess this area is not the only one in the world with these anomalies.

I've managed to correct this with the method described above: importing scenery from GM, converting the Albedo textures, placing the scenery in SDK (nowadays it nicely assigns the correct ground level), excluding buildings, making an exclusion polygon with suitable falloff and lowering the sim ground mesh so that only GM textures are visible. This removes all the height discrepancies. The problem (with my setup at least) comes when I fly over the large area. It covers at least 15 x 15 km and is made up of several packages with LOD levels 17–19. The buildings look really nice and load in "good sync" depending on flight levels but there is a noticeable popping in over time, and the trees start becoming blockier the longer I fly over the area. So it clearly stresses the system too much.

I'm guessing this happens because the textures are not properly packed with this "straight import" method, only converted. This, however, is only a guess. But I'll test whether it's possible to take a round-trip in Blender just to compress the textures without something breaking in the process. Fingers crossed.

 

[Keinowaara]

My supposition was wrong. MSFS 2024 Blender import/export plugin doesn't change the texture sizes in any way, either importing or exporting, even though there's the option "Keep the originals" in export. I tried with one pre-existing package's project and the end-result were the same textures. Not sure what the "bake textures" option means when you import the files... From other instances I'd come to expect it meant compression but little do I understand.

I did not bother to try and replace the original project texture files with these ones and "build all" to find out whether some problems would arise, it felt pointless.

 

[GaryGB]

I may get some time today to fly your scenery: MSFS 2024 Tikkurila- Vantaa - Helsinki area add-on "Tikkurila Area, Finland":

In 2024 scenery areas when I first install default or add-on highly detailed photogrammetry (aka "PG"), I CTD or crash Windows.

After I re-start MSFS 2024, I typically can fly OK after allowing all background loading to finish before clicking [Start Flight] button.

Something in Windows 10 has changed again that impacts my ASUS Fan managment app, so CPU & especially GPU ...heat up.

I may have some feedback later today (Chicago - USA Central time zone).

I hope to get some impressions to distinguish performance issues due to DrawCalls, LOD switching, and overall geometry load.

I suggest importing the above cited:

[install_path]\vomitairlines-tikkurila-area\scenery\vomitairlines\modelLib.BGL

...into MCX v1.9.2026.0612-devrel to explore it with complex shader OFF and BoundingBoxes ON, in Material Editor.


Be aware that MCX can also do all your chosen texture Material processing before export of your data to a MSFS Project.

https://www.scenerydesign.org/development-releases/

GaryGB

 

[Keinowaara]

Thank you Gary, you've been so helpful! Sorry to hear about the annoyance with your computer — on the other hand, very familiar to many. I made the switch to Win 11 and I'm pondering all the time if it might have been better to try and stick with 10 as long as possible... Hope you get that sorted. A good method anyway to allow the system some time to load before flying!

You are right, I should take the time and read the thorough PDF of MCX. It looks like a very powerful tool and all props to its creator, what a feat! Pressure time-wise has prevented a better look but now that it's vacation I won't have that as excuse.