Posts by crispy136

    I am wondering if we can direct our cpu allocation to favor ScenPro processing

    .Using the SplitGrid command already allows scenProc to process the multiple grids simultaneously. This is already enabled in my template. I also noticed a low CPU and memory usage with scenProc even when it is working hard, unlike GeoConvert. This is probably something you should ask Arno the creator of scenProc.

    I am missing most of the residential houses in the cultivation here.

    The lines you have indicated are only for large residential buildings, which usually means residential high rise. Further up your screen shot I see that you have created 2364 single level houses and 918 double level houses. So it seems to be working as expected.

    Thanks again to Chris for publishing your reply from Bing.

    I contacted the same chap and have had a very positive response too.

    That's a great result Michael, But don't forget to post screenshots of your full email request and Bing's full response in your "Bing Satellite Imagery" thread for other forum members. Without proof, it is just hearsay.

    One thing we need to work on is large individual trees are being placed in these lakes or sinkholes and this looks rather odd and out of place.

    Hi Ray,

    My next template has additional coding that uses polygons within the source file to exclude objects from areas. So it will no longer be necessary to manually create an exclude for airport areas. The script will identify the airport area, then exclude any buildings it was going to create within that area. I did a quick check around the globe (Australia, USA, UK, South Africa, Germany, Havana) and they all (but only some airports in Havana) use the same logic for airports in OpenStreetMaps. So this change should work for almost everywhere.

    I also used similar logic to solve a tree problem. The problem caused by sporting fields being located within the boundaries of parks, which is common in Australia, USA and the UK. As the script adds trees to parks, the trees were appearing in the middle of baseball diamonds, hockey fields, cricket fields etc. So I used the same logic as used for airport areas to get scenProc to automatically exclude those trees for me, using the areas of the sporting fields as defined by OSM. If you look at the larger image of the screenshot below you'll see the park on the left where the sporting fields are covered with trees. Then with the new coding, the sporting fields are visible in the image at the right while the trees in the rest of the park area are unaffected. The tree density was turned way up to allow me to test the scenario, so the final tree density for parks is much lower and more realistic. Europe doesn't seem to classify areas containing sporting fields as parks so wasn't a problem for them.

    The only downside of this process to exclude trees is that there is a time penalty that increases proportionally with higher tree densities. I have parks set at 0.00025 and get only a 2 minute penalty. However using the same area with parks set to 0.0001, as in the screen shot, the time penalty was 10 minutes. Automatically excluding buildings from airport areas has a negligible time penalty.

    Perhaps we could use a variation of this same coding to automatically exclude your trees from the sinkholes or lakes. It would just depend on how the area containing the trees is recorded in OSM. Send me a screenshot of OSM for an area with this problem and I'll investigate. Just make sure you are in an export screen with an area selected so I can use the coordinates to find the area.

    This topic is all very interesting but all the comments I have seen in relation to Bing usage in various threads are just hearsay. No-one other than myself has actually produced any evidence that shows the details of what was asked and the full response from Bing, including who made the response. I'm not suggesting anyone is making anything up, but unless you know the actual details of the full request, the full response and the respondent's identity, how would you know if the response is relevant? You could say my email screen shots are not real evidence either, but I am too busy creating scenery and cultivation to have time to forge emails.

    I also think it matters who asks Bing the question. A hobbyist wanting to share with other hobbyists for free is different to a software developer wanting to share stuff for free with hobbyists who use the software they sell. The is no profit in the 1st but indirect profit in the 2nd. I think Bing recognises this difference which may explain the differences in responses to myself and IPACS.

    It also matters that your question gets to the right area. As anyone who has ever rung their bank for advice can attest, it who you talk to that matters. If your question only makes it to the customer support area or the junior in the licensing department who started last week, then they are more likely to say no to your request because they are not qualified to answer your question. However I think just by pure luck my request made it to someone who was qualified to answer the question, the Business Development Manager of Bing Licensing. Unless of course he only started last week. :)

    But the best advice is "If in doubt, don't", and do you really want to spend hours uploading your scenery anyway? I think the real solution to scenery sharing are programs like AeroScenery and scenProc, and tutorials and source files that let you get the best out of them easily. Once you have a handle on these you can pump out scenery very quickly, AND pick the level of detail that best suits YOU.

    OK Thanks. I am in the middle of doing a smaller area in Florida right now but, I will try the New Orleans. Do you think the .0001 vs .0025 may be a factor in the long crunch time?

    Yes, increased tree density does increase processing time, but in my testing only from 1 minute to 3 minutes, for a city and suburban area with some forested areas around. But it will be longer for areas with more plants areas. Ver 5 of the template runs a little quicker but pulls in more data than before, so it is swings and roundabouts for processing time.

    It may have something to do with your computer specs perhaps. When you try New Orleans, compare it with my results which was a total running time of 580 seconds and of that 471 seconds was for plants. The New Orleans area seems to have a lot of wetland areas which are a new inclusion in the latest template, and I notice scenProc spends some time on these areas for New Orleans, creating 650,000 wetland plants. Areas designated as wetlands in my neck of the woods are full of Mangrove forests, so I use a high density here. Wetlands in different parts of the world may require a lesser density. As I used the shrub tree type, they are only visible at low altitudes, so you could reduce the density for wetlands without much impact. Wetland areas may be the same with Florida.

    I'll experiment with plant densities and see if I can find a sweet spot for density vs processing time, and include that in a later release. At present the values are set to give the best visual effect.

    Since we are downloading your newest versions, if we add documentation to a given version, it will have to be added again

    Thanks for your comments Dave. Unfortunately any end user added detail will always be lost and replaced with mine after you download a new template. Not sure I could get around that with my limited knowledge. My comments are limited to areas I have learned and tested. Haven't had much to do with lights yet so no comments and they seem to work pretty well without me changing them.

    I usually test my script in Australia (City, suburban & rural), UK (near Heathrow) and US (New Orleans & Hawaii) but I may be missing features that you have found and tested. Perhaps you might like to share the comments and updates you are adding in each time, and I'll see if they could be included in a future release. No promises though as too much detail can be counter productive.

    I had also thought of offering users varying levels of detail so they could either pick high detail (longer processing time) or lower detail (quicker processing time). Combined with my plans for temperate and tropical plants, they then just need to uncomment the lines with the level of detail and zone they require before running scenProc. Similar to what I have done for European houses in the current script.

    I would encourage anyone to share scripts of there own (or just individual lines of code) as mine are not the definitive answer to cultivation, just a reflection of what I have managed to learn and test so far. There are forum members with far greater knowledge and skills than mine.

    That is probably correct - my selected area is most likely too large.

    Some users have reported that cultivation can go missing if the source area is too large and other threads indicate that IPACS use level 10 sized area themselves.

    Its pretty easy to select a level 10 size area using a spreadsheet utility created by Qwerty42 for the FSET process of scenery creation.

    Image tile coordinates

    The screen shots below show how to use this spreadsheet for cultivation source extracts. I used the New Orleans area you were interested in as an example. Why don't you give it a go for New Orleans.

    1. Get the co-ordinates to use in OpenStreetMap. Note - you have to tab off the field after you have entered the values to get the spreadsheet to update the coordinates.

    2. Extract the data in OpenStreetMap, just use 4 decimal places of the 6 available from the spreadsheet.

    I went out for an early lunch, then went shopping and just got home - the green bar is still moving at 3 1/2 + hours so this might be an overnighter edition.

    What size area is in your source file? It may be too big if it is running that long. Some users have reported missing cultivation when the source area is too big. I use a level 10 sized area and use the "Image tile co-ordinates" utility created by Qwerty42 to give me the area for the OpenStreetMap co-ordinates.…gridcoords_v1.6.xlsm?dl=1

    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.