Posts by crispy136

    Have updated the template to version 5 with the following enhancements:-

    . Reduced running time with correct use of SplitGrid & MergeGrid commands.
    . Added new plant area for wetlands.
    . Added new plant area for golf courses.
    . Added new building type for hotels.
    . Added new building type for retail.
    . Modified building creation to use building area instead of building length for greater realism for row houses and smaller apartments.
    . Removed shopping centre parking shade sail structures that were appearing as residential buildings.
    . Corrected plant areas not appearing in FS2. This occurred where the area was in 2 or more extraction categories (ie any 2 or 3 combinations of landuse, natural & leisure). So an area with values natural="wood" & leisure="nature_reserve" were in 2 polygon areas, caused the plants to disappear in FS2. This was fixed with a few exclusions in the "PlacePointsInPolygon" lines.
    . Updated tree density defaults for greater realism. Correct use of the SplitGrid/MergeGrid commands now sees little time penalty for denser trees.

    Future development:-

    . plant sets for tropical and temperate areas

    . more work on plant areas and building types

    yep. Hardly recognizable as the Big Easy. Thanks for the special look.

    Yes, the Superdome was a little disappointing. Cultivation has its limitations and I don't think any mass scenery creation tool will ever handle unique buildings like the Superdome. But, this process did allow me to create 99,000 buildings, 180,000 plants and night lighting over a 320 sq mile area of New Orleans and view the result in FS2 in under 10 minutes. That's a pretty impressive result, and all thanks to the designer of scenProc Arno Gerretsen. I am not familiar with New Orleans to know how close it came, but a similar process on my home town was pretty accurate, unique buildings aside, when combined with photo realistic ground textures. There were some areas with no building cultivation, but that is a limitation of the information available in OpenStreetMap sources.

    Same shot from higher up at night, Superdome at middle right, Convention centre at bottom right

    If someone would like to try their hand at building a city center cultivation file for the masses I purpose New Orleans, Louisiana with the original Superdome, now Mercedes Superdome.

    Some cultivation for the area, no ground textures though. Superdome is rendered as a square building in the middle, Loews New Orleans Hotel on the right, convention centre bottom right, and the airport lighting faintly visible in the background top left.

    MERGEGRID would be added at the end before the EXPORT command that creates the toc file. I think using SPLIT & MERGE will result in quicker processing but still output 1 toc file.

    Thanks Ken. I tried it as you suggested and got 1 output file and no running time penalty, great!

    Running times for level 10 sized area with city and suburban environment

    . no SplitGrid or MergeGrid - 1 file - 13mins

    . SplitGrid only - 6 files - 2mins.

    . both SplitGrid and MergeGrid - 1 file - 2¼ mins

    New version of the template with the following enhancements:-

    . Modified industrial building height for greater realism as industrial building floor heights are generally greater than other building types.
    . Modified apartments, residential, office, commercial and retail to use building_level only where that value exists in the source file.
    . Added additional code lines for apartments, residential, office, commercial and retail to create random floor levels for larger buildings with no building_level value. This change had a big impact on the city and suburban realism.
    . Modified visuals for larger residential buildings to provide some variety to residential & apartment high rises overall.
    . Set default to comment out SplitGrid command as running time penalty is smaller than I thought.

    Chrispy, I think your multiple toc files was the result of you adding a SPLITGRID operation without the matching MERGEGRID operation (see example below). SPLITGRID isn't needed for FS2 (was required for FSX) but if you always want 1 toc file, add the MERGEGRID or remove the SPLITGRID.

    Thanks Ken. I tried removing just the SPLITGRID line but scenProc seemed to hang. I'll try the adding MERGEGRID instead. Is it important where this is located? Is it just anywhere after the SPLITGRID line or should it be placed after the CreateAF2Building lines?

    Please provide some more detail to where you are seeing that this isn't working the way that it should be in your project so that we can look into it more carefully.

    I wanted to check if any addons I have created and installed impacted this problem. So I did some testing and brought my FS2 back to zero addons by removing all user installed airports and all user created and installed photo scenery. I then added back in just one cultivation. First with an airport and then as just a cultivation file by itself with no airport. So the only customisation was the one cultivation area. Unfortunately the buildings behaved in the same manner as before, only fading in as you approach. Removing all the photo textures made the cultivation behaviour easy to spot and I noted a couple of things:-

    1. The trees appear at a difference distance to the buildings. Trees were visible in the distance behind the area where buildings were yet to appear.

    2. The fading in of the buildings occurred in the same manner when using an airport TSC with the centre point at the airport, as they did when the cultivation was in the cultivation TSC with the centre point in the middle of the high rise buildings and no airport TSC used. These 2 centre points are approx. 6km apart. So neither the centre point of the TSC nor the airport environment itself were influencing factors.

    3. I tried a TSC size setting of 1,000, 5,000 and 50,000 separately in both the airport TSC and the cultivation TSC and this made no difference to either the trees or buildings.

    Unfortunately the map.osm was too large to attach to allow you to replicate the cultivation but have attached the airport TSC and cultivation TSC which both contain the same cultivation reference, in case this is of some help.


    Perhaps it's how you are doing your scenery. The way that we make scenery is how I explained it.

    You could be right as I am just a novice. But others are reporting the same problem so it is not an isolated issue. Do you know of any area in the IPACS generated FS2 environment that has large objects generated by cultivation rather than scenery design using CAD? I could then see if the same problem persists and if not it might help myself and others isolate the issue in our files.

    I had to use the Development release of scenProc

    Thanks, have updated the original post with the version of scenProc used.

    Do your tall buildings remain visible from distances beyond 5-6km from your aircraft?

    Unfortunately the disappearing buildings is still in issue. This appears to be problem with Fs2 rather than any values in the cultivation files.

    Have updated the template with the following enhancements:-

    . Can load and process single or multiple exclude files by default (assumes that all .kml files in the source folder are to be used). Substitute .shp if you are using those.

    . Will now exclude marine parks by default that usually result in "Trees in the Sea". Also handles Marine parks in Australia that don't have the word "Marine" in their name but are very conveniently consistently named. Any other Marine park without "Marine" in the name will have to be excluded using an exclude polygon. I didn't use any complicated OR statements, just stuck the 2 filters in different sections. Luckily both sections seem to work.

    . Added comments about the effect of the SplitGrid command on scenProc running time and output files.

    . Added comments and options for excluding plants.

    . Added comments about increasing plant density and the effect of increased density on scenProc running time.

    The enhancements have been tested on my local cultivation areas.

    Size=xxxx in your airport TSC defines the read distance in meters that cultivation is read. So, if you want to see the cultivation tied to that airport from 20 miles radius around that airport then you set the parameter size=32187

    Unfortunately this is not working, as I have found the size value in the airport TSC has no impact on visibility for objects referenced by that TSC.

    I have cultivation city high rise 6nm from my airport and they are not visible from the airport as they are in the real world. They gradually become visible as transparent objects at about 4 nm from them (2nm from airport) and are fully visible about 2nm from them (4nm from airport). As you fly past them they disappear at the same intervals of distance as they appeared. Fscloudport objects in the same TSC are still visible at 40nm and beyond, if they are big enough.

    I tried 5000, 32187 and 100000 values and there was no change in the visibility of cultivated or Fscloudport objects.

    This problem is really only a issue for larger cultivated objects, like very tall buildings, which are usually visible from large distances. Other smaller objects disappear into the ground clutter in the real world and are not noticeable until you get closer to them. In FS2 only need to become visible at much shorter distances anyway and the current issue is not a problem for them.

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

    . rename it to template.spc

    . edit template.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 was used to test this script, so you may need to update if on an older version.

    I found that using an airport exclusion area resulted in 6 "toc" output files, while commenting out the exclusion sections resulted in only one "toc" file. The 6 files all work together so just add them all to your airport or area "tsc" as separate files.

    The only thing I am not sure of is what happens when an OpenStreetMap area with more detail is used. OpenStreetMap had only about 20% coverage of buildings over the whole area, although the city centre and surrounding suburbs were quite well detailed. I also found I have to use "map.osm|*|*|NOREPROJ" in place of the original "map.osm|*|highway;landuse;building|NOREPROJ" for the source file as the trees wouldn't output using just "highway;landuse;building", but this involves loading more source data which may impact some users. So you may need to use an area smaller than level 10, not sure.

    The screen shots below show cultivation created using the one scenProc script for an area the size of a level 10 FS2 tile.

    Airport area with exclusion area for Fscloudport buildings on the left, then cultivation trees behind and to the right of these buildings, then cultivation industrial buildings to the right and below.

    City high rise in the background, residential apartments and light commercial at the bottom, mixed residential apartments and some industrial at bottom right, and suburban houses in the top left with trees scattered about. This pretty accurately portrays the real world area.

    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