Rotornut44
Resource contributor
- Messages
- 635
- Country
[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 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... ).
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.