Posts by crispy136

    I have compiled a scenProc script that allows creation of Trees, Lights and Buildings (including high rise) in the one script. The script allows for the creation of suburban houses, suburban apartment buildings, industrial areas and city high rise areas all at once. This negates the need to have separate TOCs for tall buildings, other buildings and trees. I found this script gave a pretty accurate representation of my own city when combined with photo realistic scenery from FSET or AeroScenery. I have added some additional comments in the script to explain some values used and a few options.

    The script has a working airport area exclusion, but only excludes buildings. I found that creating buildings, trees and lighting all from the OpenStreetMap source, negated the need to exclude plants and lights from airport areas. The original exclusion lines for lights and tress are just commented out so add them back in if you need to, and you will need to use more than just the 2 lines to exclude all light and plant types

    As all vegetation information is sourced from OpenSteetMap data, the vegetation coverage is not as detailed as the source bitmap method kindly documented by kenventions. But OpenStreetMap data seems to have a lot of forests, parks etc, so coverage is still pretty good (in Australia at least). Using the OpenStreetMap data for trees also does away with the problem of trees appearing in odd areas like cultivated fields, waterways etc that I was experiencing when using the bitmap method.

    The script is designed for areas that have a suburban areas with higher proportion of single level houses as we have here is Australia. However I have included details of how to get more 2 and 3 story houses common in European suburban areas, in the script. Thanks to kenventions and Rodeo and other forum members for their source data and information that allowed development of this script.

    I assume you already have looked at the various tutorials about cultivation creation and know how to use scenProc, so to try this script for yourself, just:-

    . download Template_ver7.txt

    . rename it to Template_ver7.spc

    . edit Template_ver7.scp with your input folder and file from OpenStreetMaps, your exclude folder and filename and your output file folder and filename.

    . Should be then right to run it through scenProc and into FS2.

    Note - Version of scenProc DEV 2/09/2019 or higher is required to enable all features of Ver 7 of this script, so you may need to update if on an older version. Theis version of scenProc is not backwards compatible with older scripts, unless you update the CreateAF2Building lines in those older scripts.

    See post on page 6 for full details of the Version 7 update.

    Is there any advantage to separate out houses, trees and tall buildings? I find one extract can give me everything from 1 and 2 story houses to 100 story skyscrapers, and trees and lights as well. Do more TOCs give more stutters?

    I found the method to use an FSET images to generate trees gave great coverage, but often resulted in trees in cultivated fields. Mucking with the selections could remove trees from the cultivated fields but also removed them elsewhere where they are wanted. Using the land class category seemed to give me a good coverage of trees but left cultivated fields alone. The disadvantage is undocumented green areas are not cultivated as they are in the FSET method. However, a lot of green areas and forests seem to be documented in OpenStreetMap and flow through to scenProc .

    Thanks to kenventions for the tutorials or I wouldn't even be able to ask these questions.

    added the following (' <[string8][extra_user_folder][H:\Documents\Aerofly FS 2\addons\]> ') in the main.mcf file located in: C:\Users\XXX\Documents\Aerofly FS 2.

    Thanks Kloot

    That worked once I created a sub folder of "scenery" called "images" and placed all my ttx files there.

    Having been busy creating scenery I currently have 17GB of ttc files in "->Documents->Aerofly FS 2-> scenery-> images" folder. This is the folder recommended by the scenery tutorial to store any user created scenery that Aerofly can access. While this works just fine for Aerofly it is causing havoc with Microsoft's Onedrive backups. As the "Aerofly FS 2" folder is under "Documents" Onedrive backs all content up to the Microsoft cloud which only has 5GB available for free. While you can just disable Onedrive, other files you want available across PCs are then not being backed up. You can go into Onedrive settings and exclude the "Aerofly FS 2" folder from the Onedrive process, but this just deletes it from your hard drive. The next time you start Aerofly it goes and creates the folder again minus all your settings and scenery. Then Onedrive chimes in with an error as it can't back up the new "Aerofly FS 2" folder until you delete the old "Aerofly FS 2" folder already stored in the Microsoft cloud.

    So can the ttx files for scenery be stored elsewhere, say in the Aerofly drive folders?

    Hi Nick,

    I have discarded Google as a source due to the watermark, so only use Bing now which would explain the shadows etc. I checked my source files and the aero files and stitched images were generated yesterday and done using 0.6, although the source files were downloaded some time ago using version 0.5. I am pretty sure I regenerated all the stitch files using ver 0.6, as I save storage space by deleting the stitch files after the ttcs are created. I had modified the colour on the stitch images to try and match FSET using GIMP. I'll try a bit of trial and error and see if I can eliminate anything I did to get a different result.

    Found the problem source. In settings I had increased the "max tiles per stitched image" from 32 to 65. This was sufficient to give me just 1 stitched image for a zoom 15 level 9 tile or 4 images for a zoom 16, making it easier to edit the source images to correct colour variations. When I reset it back from 65 to 32 the AeroScenery level 13 tile generated exactly matched the same FSET tile and your result.

    The problem now is that I have 9 stitched files instead of 1 for a zoom 15 level 9 map area (25 instead of 4 for a zoom 16), which makes any colour corrections a very long process. Unfortunately a lot of the imagery outside towns in Australia is much older and very yellow. This is a quick and easy fix in GIMP but only if you don't have lots of small stitched images to edit.

    This is an example of the before and after result using the larger stitched images. A worthwhile improvement for very little effort, as long as your don't have too many source images.

    Hi Nick,

    The google map reference is "-27.978969, 153.422172", which is at the base of the bridge.

    I can confirm the tile difference is a constant shift, as both the top and bottom look to be off by a similar amount. The left and right of both are aligned the same. The raw file at 6.8mb is over the 1mb forum limit, and even converted to a JPG is 1.7mb so can't attach it for you. Have attached another screenshot of the bottom of the same two raw files, this is zoomed in by 20%. Don't pay too much attention to the right side of the screenshots as I think the viewer is truncating both differently. The right side of the raw files is just sea, but luckily there was a tiny spec in the ocean near the right edge so I am pretty sure the right side matches on both too.

    There still appears to be a tile alignment problem. When flying North I noticed a slight texture shift to the West in the near distance. I tracked it down to an area where a level 14 tile (created at zoom 18) overlays a level 13 tile (created at zoom 16). The screen shot shows the area where this occurs, viewed at 1,000ft heading North. Note the misalignment of the bridge. The texture shift to the west was caused by the level 14 tile being loaded and overlaying the level 13 tile as I approached.

    When I substituted FSET produced level 14 tiles for the same area, nothing changed, so the more detailed level 14 tiles generated by AeroScenery are correctly placed. It seems the problem is the level 9 map tile extract is generating textures slightly to the east of where they should be. This then causes a small but noticeable texture movement to the west as the more detailed level 14 tile loads.

    In AeroScenery I used a map size 9 and generated levels 9, 11, 12 & 13 output using zoom level 16. I then used a level 13 sized map area and generated level 14 output using zoom level 18 for my detailed areas.

    EDIT - Ran comparison FSET and AeroScenery for the same level 9 map area and extracted both level 13 tiles. If you compare the two raw files (FSET on left and AS on right) for the same level 13 tile, you will see the AeroScenery tile starts too low. This shifted the bridge North, causing the apparent misalignment east in FS2 due to the angle of the bridge.

    I do often notice that GeoConvert lightens or reduces contrast in the images.

    It would be great if AeroScenery could resample the stitched image files. FSET did by automatically with the default setting adjusting brightness by -6 and contrast by +12. This combination gave enough extra lift to make the textures look vibrant in FS2 without going over the top.

    I think the shore line feature you mention only works if you are using Google, as Bing gives you the attached image if you request one it doesn't have. As Google comes with watermarks that are very noticeable on water, will many people use it for shoreline areas?


    • b_15_30398_18981.jpg

    Had a look in the download folder and surprisingly both folders had the same number of files, but slightly different disk size used. I tracked it down to one jpg. AeroScenery seems to have downloaded something, but when I try to look at it, it is not a valid jpg. I assume it created the name but then had nothing to put in it

    FSET used a queue system for any images it wasn't able to get straight away, although it used to end up with quite a few in the queue not just one. So I don't think it did any retries on the first run. Once it finishes all the other images, it returned to the images in the queue and did a second attempt. I never had an instance where it failed to get all images, so it seems to just be a timing issue.

    Hi Nick, I noticed I am getting a few masked tiles in 0.6 I wasn't expecting. Tracked it down to missing source imagery in the stitched image. Rerunning the stitch process didn't make any difference, so I am guessing that the source image wasn't downloaded. When I reran the AeroScenery process again in full on the same map tile, same zoom level, all source images were downloaded and no mask ttc's produced. Have had it happen on Bing and Google and on level 9, 13 and 14 map size selections. While it is quick an easy to rerun a level 14 or 15 map tile, not so quick on a level 9 sized map tile.

    I've been having a poor experience with GeoConvert with AeroScenery

    These are the following AeroScenery combinations I have found work reliably on my PC and produce good quality results when viewed in FS2. Times are only indicative of running time based on my PC's specs.

    1. For map areas with no airport - gives VFR quality above 6,000ft

    - Select map tile 9 & zoom level 15 & output levels 9, 11 & 12 (approx. 13mins & 1.1gb disk space per map tile selected)

    2. For map areas with an airport - gives VFR quality above 3,000ft

    - Select map tile 9 & zoom level 16 & output levels 9, 11, 12 & 13 (approx. 60mins & 4.4gb disk space per map tile selected)

    3. For town areas near an airport plus anywhere under the aircraft flightpath - gives VFR quality below 3,000ft

    - select map tile 13 & zoom level 18 & output level 14 (approx. 9mins & 790mb disk space per map tile selected)

    4. For airport inner boundary (optional) - sharpens textures at ground level

    - Select map tile size 14 & zoom level 19 & output level 15 (approx. 3mins & 151mb HD per map tile selected)

    For a level 9 size map tile with an airport, I run 3 AeroScenery sessions (2, 3 and 4 above). I never run more than one instance of AeroScenery at a time, but this will produce as many GeoConvert sessions as map tile selected. Both CPU and RAM get maxed out with multiple GeoConvert sessions, but leaving the PC alone until its finished works just fine. I usually run AeroScenery with download, stitch, TMC & AID and GeoConvert all selected.

    I also found that there is a limit to the number of GeoConvert sessions you can run at one time. For my system I can run 8 of 1 above and 10 of 3 above. No 2 above is quite labour intensive for GeoConvert, so I usually run these with just 1 or 2 map tiles selected at a time. As 4 above is just for the airport inner boundary I never need to run more than 4 map tiles together anyway. You could test just one or each above to see how your PC specs perform.

    You haven't indicated what AeroScenery values you had selected. If going for the quality everywhere approach, with a selection of map tile 9, Zoom 18, and output levels 9, 11, 12, 13 & 14 selected, you may be asking your PC for too much. My testing indicates that this combination of values in AeroScenery would result in a processing time of > 12 hours and HD space required of > 100GB on my PC. So I stay away from this combination and only target quality where it is needed.

    There are 3 scenarios I encountered that failed to produce any output:-

    1. using zoom 18 or below with output level 15.

    2. running with masks off with a stitched image with a transparency. Unfortunately AeroScenery doesn't indicate if it created a stitched image with a transparency.

    3. Having too many GeoConvert sessions running at once. I was running 9 of 1 above and it didn't produce any data for the 9th map tile, but no errors reported.

    Interesting result and needs some debugging by any willing volunteers!

    Have attached the results of the map 13 sized tile extracted @ zoom 18 (0.597 m/pixel) in AeroScenery and download res 0 (listed as 0.5 m/pixel) in FSET. Have attached everything except the image files. AeroScenery image file was 8192w x 8704h png, while FSET image file was 6146w x 7258h bmp. TMC files used by both processes had the same values.

    In the FSET zip you'll find a couple of extra files.

    1. txt file (not used, but produced by FSET)

    2. inf file (produced by FSET but only used only to create the tfw file)

    3. tfw file (created from the inf file)

    Looking at the scenery tutorial the tfw file has the pixel steps in it. FSET doesn't produce the tfw file and that has to be done manually or by using a little exe someone developed, before GeoConvert is run. The tutorial gives no details of the purpose of the tfw file, only that it is part of the process.

    I also noticed that AeroScenery generated the aid file, but in the FSET process, the aid file is generated by GeoConvert. So it would appear the aid file is an byproduct of the GeoConvert process, not an input. Perhaps this is the problem, and AeroScenery needs to produce a tfw file not an aid file. Only guessing.

    AeroScenery top, FSET bottom. Note misalignment with Fscloudport runway.

    FSET - both top and bottom



      (1.32 kB, downloaded 13 times, last: )

      (2.98 kB, downloaded 12 times, last: )

    Found this while doing some source image quality comparisons. I think this may have been mentioned before, but couldn't find the post. Looks like the higher the zoom the more accurate the placement of the tiles. Looking at the airport runway, zoom 19 gave the best match but was still a little out. I repeated the test using map size 13 tiles and got a similar result using either level 14 output or level 13 output. In case there was some issue with GeoConvert I also did an extract using FSET, but encountered no problems. I used Google for the AeroScenery extract but the tiles I had from FSET were Bing, but I don't think this was an issue.

    AeroScenery - map size 14 with GeoConvert output size 14

    AeroScenery - map size 13 with GeoConvert output size 13

    FSET - map size 14 with GeoConvert output size 14

    I found that 2 or more simultaneous GeoConvert sessions running maxed the CPU, rendering the PC unresponsive until it had finished. However left alone it finished without causing any problems for Win10. Also that when I was running 9 tiles, GeoConvert didn't produce any output for the 9th tile, although when I reran the GeoConvert step for just that tile it worked. I didn't have any crashes with 20gb RAM, but never exceeded 9 at once. I also noted that I could run more level 14 tiles at once than level 9 tiles at once. I don't think GeoConvert was ever designed to have many instances running at once.

    We have received legal opinion on the sharing of ortho imagery and, with the exception of using USGS data, it is illegal to use Bing or any other source to share such files on a public medium for download.

    So was that opinion sought from Bing themselves or from a 3rd party like a lawyer who then looked at Bing and Google's EULA's. The response I got was by asking Bing themselves, I just contacted Bing's email address for map licensing, so their response is most likely from the US. However if there is any doubt, then the best advice is always not to distribute anything.

    In my case Its probably all a bit academic now, as I have found that reasonable quality scenery would result in data that is too large to share. But with new tools like AeroScenery, users will soon be able to easily create their own scenery. To that end I have done a bit of testing an come up with 3 different combinations of settings using AeroScenery, that would give different "effort/size vs quality" scenarios that would allow users to pick the best option that suits their FS2 needs and computer resources available.