I think you'll see a lot more scenery when the new scenery tool becomes available.
I checked with Microsoft's legal area and surprisingly they responded. I assumed they'd just ignore it. They advised they had no issue with sharing anything created using their map data.
There may be a mistake in my grid calculation class... Chris what tool do you use to note the coordinates in FSET?
It might be interesting to see how qwerty42 calculates its grid in its small Excel utility: https://flight-sim.org/filebas…rid-calculator-for-excel/
I use qwerty42's Excel utility to give me the coordinates for FSET. It matches the grid coordinates used in FSET with the tile size in FS2, depending on the level you are creating. It then is a simple process to flip backwards and forwards between Excel and FSET until you get the right grid layout to match adjoining areas you have already created. Any time I do an extract I take a screen shot of the FSET screen. I can then review this screenshot when doing my next area so I can calculate a lat long for the starting point for the Excel utility. Creating adjoining scenery areas is a lot easier this way and ensures that the areas you are selecting in FSET match those used by FS2 grid tiles. I also use a web page utility created by Spit40 (I think) that then takes the information from FSET and creates the output to past into the TMC file GeoConvert uses. Getting the computer to calculate these two conversions makes the likelihood a mistake much less likely, and speeds up the process. Using this process I almost never get scenery issues in FS2 using the FSET scenery process. This process is repeated to create detailed imagery around airports, again using the Excel utility with a different FS2 level setting. If you were doing tiles for levels 12 and 13 in FS2 then you would set the Excel utility to level 12 and that would ensure that any level 12 & 13 imagery created by FSET matches the tile sizes for level 12 ands 13 in FS2.
Yep, it was a steep learning curve to run all the steps with all the correct values and get a decent result in FS2. The tutorials don't contain all the info you need, so I had to troll the forums to get enough information to be proficient. Luckily IPACS forum members love sharing.
There is a tool being developed that will allow you to easily download your own photorealistic scenery yourself. It is not ready for release yet but will be a quick and easy way to get the images on your computer and up and running in FS2. You'll be able to select what areas you want and what quality of images you require for individual areas. The only limitation is the amount of hard disk space you have. So no point in creating high resolution images of Wop Wop if you are only going to sail over them at 35,000 feet, lower resolution images will do. My happy medium between scenery size and scenery quality was to have lower imagery in areas without an airport, then add progressively more detailed imagery as you get closer to an airport. So in an area where you would normally be getting closer to the ground, the imagery quality is increased. This seems to work well in FS2.
There are 2 sets of photorealistic map data you can use. One from Google Maps and another from Microsoft's Bing maps. Which looks better often depends on what area you are downloading. Unfortunately Google's map data comes with a "copyright Google 2018" watermark in all the images, and these are faintly visible in FS2. Bing maps doesn't currently have a watermark.
Its not clear from the legal fluff on both Google and Microsoft's map sites whether you can distribute scenery you have created from their source maps for FS2, although Microsoft seems to indicate it OK if its not for profit. Its just not clear in relation to FS2.
Because of this and also as the scenery tool is being developed, I won't be releasing any photorealistic scenery I have extracted. However once the tool is available, and you can easily create the photo realistic scenery yourself, the airport building, runways and static planes I have created to enhance the airport areas can be easily downloaded from Fscloudport and installed in FS2. In fact you can download them now, but they look a bit odd in FS2 if you don't have the supporting photorealistic scenery.
What I noticed is that as you give GeoConvert more resolution (by increasing the image zoom / detail level) the "overspill" gets less and less for a level 13 size tile.
For a random level 13 size tile in France:
At image detail level 17 I get six(!) masks
At image detail level 19 I just get a small strip at the bottom.
At image detail level 20 an even smaller strip
Maybe by limiting size 13 & 14 to image detail level 18+ and tweaking the decimal rounding in the TMC file we can fix this.
Hi Nick, I was wondering if there might need to be a link between the zoom level and the grid level size. In FSET this makes no difference to the outputted image other than the quality, but it uses a different method of extracting the data.
One other random thought I had was perhaps there is an small inaccuracy in the information in the TFW file created by AeroScenery. The way I understand it the TFW files gives the coordinates of the top left point of the source image as it is represented on the planet. It then reports pixel step information to allow Geoconvert correctly map the rest of the image on the planet. The TMC file then comes along and gives GeoConvert top left and bottom right coordinates of the section to be extracted for the FS2 tile. If either the top left position or pixel step detail aren't accurate in the TFW file, then Geoconvert gets the wrong placement of the source image on the planet. It then extracts the section of the image it needs based on information in the TMC file. GeoConvert is then selecting the wrong section of the source image to create the FS2 tile. This would explain both the image overlap produced by the masks setting and the missing right hand section of the output image.
Antoine pointed out that the pixel steps in the FSET extracts I produced didn't match (or even come close) to that used by AeroScenery (see my reply to Antoine above). Yet each of these pixel steps use in FSET allowed Geoconvert to correctly create data from the source image to the FS2 tile. Could this be the issue? Just a thought.
Note that you have different pixel sizes in X and Y between FSET and Aeroscenery sources. The coordinates will vary depending on the settings in each tool, but the pixel size should be the same if both use the same raw image resolution
Hi Antoine, I had to try a couple of extracts from FSET as the zoom level are differently described. I didn't understand the pixel size density and ignored it. All 3 produced a correctly imaged output file regardless of the input resolution, so this may not be an issue for the purposes of the comparison. The image resolutions available in FSET and AeroScenery don't match so any direct pixel comparison may not work.
FSET has the following resolutions. There are more lower res level (higher numerically) but I never go higher than 3 or the image quality to too low to use.
0 -> 0.5m/pix
1 -> 1 m/pix
2 -> 2 m/pix
3 -> 4 m/pix
AeroScenery has the following resolutions
15 - 4.77 m/pix
16 - 2.39 m/pix
17 - 1.194 m/pix
18 - 0.597 m/pix
19 - 0.299 m/pix
20 - 0.149
I tried levels 3, 2 and 1 in FSET on the same level 13 grid area and got the following pixel steps:-
. lvl 3 - [steps_per_pixel][7.15255737304688e-06 -5.36441802978516e-06]>
. lvl 2 - [steps_per_pixel][2.86102294921875e-05 -2.14576721191406e-05]>
. lvl 1 - [steps_per_pixel][1.43051147460938e-05 -1.07288360595703e-05]>
I only run AeroScenery at one level for the same level 13 grid and got:-
. lvl 17 - [steps_per_pixel][0.0000113993883132935 -0.0000100093409463844]>
I find the airports from Fscloudport load in AeroScenery without a problem. I did notice that the first time I tried to activate this, that the airport flag was nearly off the side of the screen and not correctly placed. As soon as I moved the map around a bit, the airport flag jumped to the right spot. Since then they have reliably appeared in the correct locations. The further you zoom in the more accurate is the placement of the flag. Click on the flag to display the Fscloudport details.
Thanks Antoine. Had missed that, but had been working on it for 3 hours, so my skills of observation had started to wane.
When I finally extracted a 3 x 4 set of adjoining grids and loaded them into FS2 I found the tiles are not matching up. The reason would most likely be the missing textures on the right side of the tile. Tried files produced both with masks on and off with the same result. So appears to be a different but related issue to the one I described above. The screenshot below more obviously displays the problem just off the left wingtip. The plane was facing north so would fit with missing texture strip on the right
Nick, Forgot to mention that I used Microsoft's Bing images for all my tests as FSET can't access Google data any more.
I did some testing and comparison with the various files created by the manual FSET and automatic AeroScenery processes and after a few false starts I think I have an answer.
I used the same FS2 level 13 grid in FSET and Aeroscenery and set about to produce the output, then compared the results. Both TMCs were run through Geoconvert with Mask enabled.
Output files created- FSET = 1, AeroScenery 3 =3. Note all images below show FSET on the left and AeroScenery on the right.
The extra ttc (70a0) created by AerScenery was a strip across the bottom of the tile, hence the additional mask file needed. Looking at the source stitch file, the texture is from the top of the stitch image, so it in effect fits on the top of full tile created. Look at the enlarged image below to see the strip as the thumbnail process chops it off. Running the extract with masks off would have seen the mask tiles not created. I had found in my earlier scenery creation attempts that when a source image spanned multiple grids in FS2, and you are running GeoConvert for that grid level with masks off, then Geoconvert discards those tiles that would have resulted in a partial tile (mask tile). Same thing occurs with transparencies.
TMC comparision - no difference here
AID files - difference in lat of the top left coordinate, the first clue I think.
Lastly I compared the source graphic files created from the image data that is read by GeoConvert. What I found was the AeroScenery stitch file was taller than the compiled BMP created by FSET. The AeroScenery stitch image has a horizontal strip of image at both the top and bottom compared to the FSET file. In the AeroScenery stitch image the extra strip at the bottom is roughly double the size of the extra strip at the top. In the image comparison below note the small creek at the bottom right of the AeroScenery image, and the small oval at the top. Both these are missing from the FSET extracted image. The width is the same in both.
Source image comparison - note extra height in the right image created by AeroScenery
When running GeoConvert (using an identical TMC file for both remember) the extra strip at the bottom of the AeroScenery image appears to be ignored by Geoconvert. But the extra strip at the top of the AeroScenery stitch image appears in the additional files created by the mask option. I am assuming that as the FSET source image file more closely matches the FS2 tile's width to height ratio, no mask files are created as there is no additional image area to be cut off.
Raw file comparison of the same output file produced by both processes - both are identical except for some colour variation. The top and bottom of the AeroScenery image is discarded by GeoConvert resulting in the same output image as from FSET.
So there appear to be 3 courses of action.
1. Do nothing in AeroScenery and just run with masks off. This will discard the extra portion of the taller AeroScenery image. The top section of the image used in the mask file has a distinctive oval in it, so I was able to confirm that this strip also appeared as the bottom section of the full image of the tile above when that grid was extracted. So using masks off and discarding the additional image data will not compromise the scenery output accuracy. But using masks off will cause problems where transparencies are used.
2. Do nothing in AeroScenery and run with masks on. This would mean that FS2 has 2 image tiles created for the same data for the same level. So the images in the strip across the mask tile will also appear as part of another full tile. Not sure if that has any impact, but I did read in another thread that mask file sometimes cause visual issues in FS2. Can't remember the issue though.
3. Modify AeroScenery to reduce the overscan in the stitch file. Masks can be left on to allow for transparencies and this will not impact the output file creation as it does now.
The image below shows the size and coordinates used by FSET that produced the FSET equivalent of the stitch file. Perhaps you could compare these details with that used by AeroScenery.
Just as a side point, but I had to run the FSET process a couple of times to try and get a good match of the respective output file resolution. I had to try different download sizes in FSET to match the zoom level in AeroScenery, since they describe the image quality differently. I ran 3 extracts in total at different image quality levels and in just one of those, the FSET data produced mask files. However when I looked at the mask file it was just a single line of pixels across the bottom. So FSET occasionally has some very small variations that produce mask files, but they are rare.
I have been looking at this so long my eyes are starting to bleed. Time for a break.
Frustratingly, it is some very slight discrepancy between the way GeoConvert is calculating grid square coordinates and the way I'm calculating grid square coordinates.
I tried increasing precision to 8 decimal places and it made worse, there were more masks.
I tried rounding down in all cases, but there was still the mask you got
My calculation seems to be correct, some / most of the time because I haven't noticed this before.
Without porting the exact code that IPACS uses, or having their list of coords for each grid square, it's hard to know how to improve this one.
Is the FSET conversion tool you use an IPACS tool, or from someone on here?
In the meantime, remember that in the settings you can turn off the use of masks, which will do the job apart from shore line regions.
I'll try using the old FSET process for the same grid square, with masks on and see if I get the same results as AeroScenery. If I get the same problem, then it might just be a Geoconvert limitation caused by using masks. In that case the solution would just be to disable masks unless you really need them for transparencies. If I don't get the problem using FSET, then comparing images created and TMC files uses might point to a solution.
I don't think the FSET tool was developed by IPACS, as it can also be used for FSX. My guess is that IPACS built Geoconvert around using FSET as the data source.
Couldn't find the disable masks option you mentioned. I thought it was in the settings screen in 0.4, but is missing from that screen in 0.5.
The google link is https://www.google.com/maps/@-…3603,60000m/data=!3m1!1e3.
I don't think the decimal points are causing the mask issues. I have been extracting image data using FSET and using a little utility to align the images extracted co-ordinates in FSET with the FS2 tile sizes. FSET would no doubt have to trim downloaded images to fit the FS2 tile size when it stitched together the images for Geoconvert to use. The TMC file was generated using another utility using the same co-ordinates as the FSET extract and only used 2 decimal places. When I used this method everything always lined up and no mask files were produced. I usually run Geoconvert with masks off, and the tiles always line up in FS2. I only ever use the mask option if i have a file with a transperancy.
I see the mask option has disappeared from the setup screen, so I assume it is on all the time. Perhaps I could manually edit the TMC file, then run Geoconvert and see if the issue goes away.
I have rerun the first 2 grids individually and still got file name conflicts, so the problem is not multiple Geoconverts running at once. Have attached some screen shots of the output so you might get a better idea of the problem.
Thanks for the updated program. No problems running it now.
Gave it a go for a level 14 tile selected, level 14 also selected to be generated by Geoconvert and zoom level 18. The output had some mask files, which Geoconvert usually only produces when your source image selection size doesn't match the FS2 tile size or transparency is used. Looking at the PNG files produced I see that there is a small strip across the top which has spilled over to another tile. It looks like the level 14 tile in AeroScenery and FS2 might be a slightly different size. Re-ran this using zoom level 19 with similar results, although I got less mask files. Used both Bing and Google with the same results.
Also tried running download, stitch, generate aid/tmc and geocovert all as part of the one selection. This combination of selections failed in ver 0.4, but ran perfectly in ver 0.5.
Ran AeroScenery for 12 level 13 tiles, zoom 17, Geoconvert level 13. Mask issues occurred again with level 13 tiles with a proportionally larger strip spilling across to the tile above, resulting is extra files and mask files. With 12 grids selected AeroScenery kicks off 12 Geoconvert sessions at the same time. This maxed out the CPU and stopped all other activity. All sessions finished without issue though. If a batch session could be implemented in a future update, it would allow the PC to function normally while the process is running. When copying the result ttc files across to FS2 I notice that were some duplicate files created. For instance grid 1 and grid 2 both had a file with the same name, although the content was different. The grid 1 naming convention was used for one of the tiles in the grid 2 folder. The grid 2 file with the grid one name was one of those files with just a strip across the bottom, so seems to be a mask issue.
Loved the ability to select the different map view types. I did get myself confused when I was able to display google on the maps but had Bing selected on the extract.
The shoreline water is a problem unrelated to AeroScenery as it also occurs using the more labour intensive FSET process. Editing the source graphic files is the way to go, done just before you run Geoconvert. Had a similar problem for some coastal areas using Microsoft's Bing data with areas of white and differing tile overlaps.
There are 2 ways to deal with this. Options 1 is to do as suggested by Jetjockey10 and overwrite the problem areas. I used a simple cut and paste in GIMP to accomplish this, and used this when creating level 9 and 11 tiles. Options 2 is to get rid of the problem areas altogether as a transparency, also using GIMP. I used this method when created more detailed images for level 14. Note that when using transparencies, you mast have masks enabled or Geoconvert just skips any tile that would have contained the transparent section.
One other issue I have noticed is when using Google maps in AeroScenery as the data source, you get google logos appearing in your scenery in FS2. They are most noticeable on water but they are present on the land as well. This was extracting the images at zoom level 16 (4m/pix). Higher zoom levels used to create a level 13 or 14 tile would no doubt make this more noticeable. Bing doesn't seem to use logos. The same area extracted using Bing had better colours and no logos.
Decided to give Aeroscenery v.04 a go.
Ran AeroScenery with Google & zoom level 16, level 9 & 11 AFS levels, with "download imag tiles", "stitch image tiles" and "generate aid tmc" selected.
1. Really loved the GUI and ease of use, saved heaps of time. Thanks for developing this program.
2. Once you set the geotools folder in the settings and then exit the program, Aeroscenery will not start again. Deleting the AeroScenery registery line allowed the program to run again, but you have the set up the geotools folder again. However after a successful processing run, this problem does not reoccur, and AeropScenery starts every time.
3. Hitting stop after the program has been running doesn't clean up any files it created.
4. Found the program errors if you leave the default setting that includes "Run Geoconvert" selected.
6. I ran the program 2nd time with Run Geoconvert deselected. It downloaded all the tiles again, overwriting identical files, but finished successfully.
7 Log from file download is overwritten with stitch details once that process runs.
7. Ran with just "Run geoconvert" selected, but Geoconvert only created level 11 files while I had selected 9 and 11. Tried again with just level 9 selected but Geoconvert only generated level 11 filesagain.
8. Grid appeared in FS2 OK, but Google textures are a bit washed out compared to the textures created with "Virtual Earth" & FSET.
9. Tried it a second time with Bing instead of Google (all other values the same) and interestingly this generated both level 9 and level 11 files. Images below show tiles from the FSET & Virtual Earth on the left and the adjoining tile on the right was generated using AeroScenery & Google/Bing. Might just be season/time of image. Bing is closer to Virtual Earth, but both are less vibrant that Virtual Earth.
The file list looks OK from what I can see. I deleted YBBN from my PC and downloaded it again from Fscloudport just to be sure and it all worked OK in FS2.
During development I encountered disappearing buildings after I had added some extra detail. I edited the airport in Fscloudport and deleted a few things and the scenery was OK again. So it appears FS2 has a limit to what it will show and I had initially exceeded that with YBBN using Fscloudport.
So it might be a memory thing. On my system with 4GB video and 20GB ram it works OK in its current build. And that is with all my development programs open as well on Windows.
When I had too much detail in Fscloudport all the buildings disappeared, leaving only the runway and tower. Is this what you are getting?
I also notice you are using a different folder location to that recommended by Fscloudport. If my other airports worked in the same location then the folder isn't an issue.
Yep. Available now.