• 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.

MSFS Secondary Aerial Image - Optimizations & Improvements

Rotornut44

Resource contributor
Messages
635
Country
us-florida
[Edit] To the admins: I originally thought to post this in the MSFS terrain section, however maybe it's better posted in one of the general discussion threads? Feel free to move it if it doesn't fit.

I just created this post over at the official MSFS forums. Unfortunately, the 3rd Party Developer forum is hidden for standard users, which is both good and bad, I guess. So, with that said, it's likely many here will not have access to this url:

However, for those who can access it, any feedback over on the MSFS forums, continuing the discussion would be great. I'm curious on others thoughts about this subject. This has been addressed in the past, but didn't get much of a response from Asobo.

For those curious, here is a copy of my post:

I'm creating this topic as an expansion and reiteration of some of the points made in this discussion started by @Umberto67 months back: https://forums.flightsimulator.com/t/aerial-images-problems-and-questions/217607

Although I am sure there are some bigger issues at hand that take priority, when it comes to scenery design, I feel that it's once again time to bring up the ginormous Elephant in the room.

1. Requiring LOD20 Aerials can be a huge waste!
In some cases, where LOD20 imagery is available, this isn't a major issue, however not all data sources available are LOD20 (15cm). Many are 60-30cm. Upscaling these lower resolutions so that they match the LOD20 requirement is a huge waste of space, usually resulting in gigs of extra data with no visual benefit. Some sort of primary or persistent aerial type/mode would be incredible, and could save on tons of unnecessary data that both developers and consumers currently have to deal with.

The key term here is "persistent", as it needs to always override the Bing tiles, for ensured compatibility to the addon.

2. Optimizing PNG Tiles.
As I have previously pointed out in the topic linked above, there are a handful of ways that PNG files can be optimized. PNGOUT, OptiPNG, and DeflOpt are a few that I know of. These are usually used when optimizing PNGs for use on the web.

Though, developers can do this now for the LOD20 tiles (Although it has been hit or miss for me, sometimes running into display issues), cutting down on the file size a decent bit, this is something that really should be implemented on the SDK side. This ensures that everyone will take advantage of it.

3. Allowing the SDK to handle tile creation.
I put this one at the bottom of this list, as I don't consider it as high of a priority as the above two points, however that does not mean I'm demoting it in any way.

The current process of feeding thousands of pre-made tiles to the SDK can be quite cumbersome. Not only is a lot of data being wrote to and read from our drives, but transferring the files from work directories to the compile directory can take a long time (Unless you were smart like I am 20% of the time and remember to create the tiles in the CGL directory in the first place... o_O).

Moving forward, I feel like it would be more beneficial to provide the SDK with a single PNG (or TIFF) image, allowing it to create & optimize all tiles, and neatly pack them into a CGL file. Even if it means taking a bit longer to compile, I would think the process would still be faster than the current method.
4. Prevent CGL from recompiling if there are no changes.
Currently, when working on an airport that uses a secondary aerial, I break my project up into 2 files. 1 for the main project and a second for just the aerial. I do this because each time you rebuild your project, the aerials are also rebuilt, even if no changes have been made to the files. Of course, at some point I will combine the two projects into one, but this wastes time if no changes have been made to the imagery, as I'll have to wait for the aerials to be rebuilt and packed.

Much like with every other file in a package, could the tiles also be verified for a change? Then if no change is detected, compilation could be skipped.

In Closing..
Considering the above would drastically improve the experience for developers, distributers, and customers, alike. There is absolutely no reason why just a small airport should consume many gigs of data.

Before I get too involved in projects for MSFS, I am hoping something can be done here. I simply can't afford to burn terabytes of bandwidth month to month, especially when it comes to freeware releases. The time commitment, for now, I can put up with...

I know I'm not the only one who has thought of the above. Hopefully getting this out there again will get some attention, allowing us all to eventually come to a solution. :)
 
Messages
111
Country
france
For the moment the 'simple aerial' project compiles up to LOD20 whatever your source resolution, and it's not yet possible to change that setting.
This ensures that your aerial takes priority over default one when zooming in enough (if you'd compile an aerial at LOD18 and the default bing is at LOD19, the default one would appear when closing in enough to trigger LOD19).

About optimizing pngs, I use that trick:
1. First full version, used during airport design phase (aerial used as blueprint):
RrPWuAt.jpg


2. Final version for upload: remove everything that is covered by something else (aprons, buildings...):
T6Ktg9L.jpg
 

rhumbaflappy

Administrator
Staff member
Resource contributor
Messages
5,932
Country
us-wisconsin
Compiling from a single geotiff would be nice. And optimizing the resulting PNG files would be good.
 

Rotornut44

Resource contributor
Messages
635
Country
us-florida
I forgot to change it on this thread, but #1 no longer applies. It is not required to use a LOD20 aerial as an input (Which is what I meant by that). You can now use a lower LOD, but it just gets upscaled.
 

Rotornut44

Resource contributor
Messages
635
Country
us-florida
Compiling from a single geotiff would be nice. And optimizing the resulting PNG files would be good.
I have been playing with that on my source tiles, however it's stripping out something that MSFS requires, as (after compiling a cgl) my imagery always has a hard green or red tint to it. Almost as if a channel is being ignored..
 
Top