Have started looking at stuff inside the airport boundary. Have added taxiway centreline and side lighting. I have yet to integrate it with other cultivation. I can add other lighting as long as it exists in OSM. Let me know if there is anything you want, as well as an OSM ref.
there is a syntax error in the floor selection of alternative european houses which is causin zero floors.
Thanks Thomas. I've added the change to version 8.
A few challenges I ran into when using the OSM data for radio towers:
Inconsistent OSM data will always be a problem and historical information is also an issue.
I wasn't able to get towers in close proximity to each other to flash together. As TV towers are often close to each other I used less flash timing variation for those towers.
I reinstalled your v7 then redid some of my local area cultivations hoping to see the new towers, but, I guess you have not added the new realistic tall towers to the file. The towers are properly located but still the stacked buildings.
Yep that is right. The 3d objects will only be delivered with version 8 of the template. I was just showing some screen shots to see what people thought about the longer loading times vs result.
If you completely exit out of AF2, and start from a location outside of this 31 mile radius, you won't see the downtown skyline until you fly inside this radius.
That fits in with what iPacs said, and also seems logical. And iPacs insisted that they had tested this with their scenery. And you say you have confirmed this, with their scenery. I don't have Florida so can't make any comment on how it might perform. But this is definitely not the case with Fscloudport airports, or TSC files I have created with 3d objects using scenProc.
YBSU (Sunshine Coast) is a Fscloudport airport with a size value of 5000 in the TSC, and has no cultivation. In the screenshot below you can just make out the buildings of the airport from 20nm, then runway and buildings are clearer at 14nm. The last screenshot is the 14nm view with the airport TSC deleted, to show it is not the underlying textures that are rendering the airport and its buildings. I had started my journey some 200km distant.
20nm and the airport is just starting to be large enough to reach a couple of pixels on my screen.
14nm and you can clearly see the runway and airport buildings
And lastly the same 14nm with the airport TSC deleted. Airport is not visible so the underlying textures are no giving the appearance the airport is visible.
please try to use as many xref objects a possible (instead of regular 3D models).
Thanks Thomas, Was planning to do this when if they become available in scenProc. But the majority of XREF objects are airport related rather than general scenery related. I haven't looked at OSM data for airports yet, but thought I might be able to do something to enhance airports without the need for a lot of work in Fscloudport. The VOR you suggested will be easy I think. Other than airport objects, you are limited to vehicles, houses, factories and storage tanks and 1 weather tower. A pretty limited list. I may be able to use XREF factories to mix them in with cultivation buildings to give us a bit of building variety. XREF houses are much better than any houses cultivation can produce, so that's another possibility. The storage tanks are limited in size, and mixing them with larger cultivation generated tanks will look a bit odd. Not sure what to do with cars, as I didn't like them placed on roads, but perhaps there is scope for using them in parking lots, although getting the alignment right will be difficult.
Here is the TSC spacing IPACS used in the South Florida DLC.
Thanks, great information. I never purchased South Florida. The only issue is that in my testing the size value has no impact on the 3d objects. iPacs insists that it does, but the reality is it doesn't.
The spacing seems to indicate we are on the right track with cultivation though. But I'm sure we are doing something not quite right due to the problems encountered with 3d objects, and draw distances.
That's why I asked IPACS to document how to merge generic objects into an XREF library. This is no rocket science, we just need the IPACS-specific process flow and syntax, but IPACS never replied, not even stating they don't want to share that information...
I asked a similar thing and got no response. I think that not helping the community with creating extra content is a missed opportunity.
Your problem may be caused by existing installed textures. AeroScenery doesn't check for existing textures when you install new ones. It just overwrites any existing files, but does not remove any not required. The problem occurs when the new textures are slightly different and have fewer texture files. When his occurs you have some old files along with some new ones, when you only want new ones.
When generating new scenery for any area I have done before, I always manually locate the install level 9 Aerofly folder created by AeroScenery, and delete everything. It is then a simple matter to reinstall anything from that area after you have generated anything new. ie Install the level 9 tile, then install any level 10 tiles within that level 9, and so on until all your areas are installed.
Have successfully added 3d communication towers, power towers and water towers to the unreleased version 8 of my template. There is no performance penalty in scenProc processing time. They add a significant amount of realism, but this comes at the price of increased loading time. Currently the loading time using my template with the new 3d objects saw the loading time increase to about 1 minute 30 seconds before Aerofly plopped you into the cockpit. I would be reluctant to add more 3d objects as I think it would result in an unacceptable loading time.
Antoine has said indicated he is hoping iPacs can come up with a solution for this problem. But if not, then are you be willing to accept longer loading Aerofly loading times in exchange for greater realism like this?
The large tower on the right is something you always see flying into Brisbane, and is now very realistic in Aerofly. VFR pilots often get clearance to track via the Bald Hills radio mast.
Tests with 1 TSC calling all 13k TMB objects causes extremely long load time at startup
I noticed increased loading time as soon as I incorporated 3d objects. I had replaced all communication towers with 3d objects, which resulted in 84 3d objects in the TSC. But there only 5 tower types, so my guess is that Aerofly is loading each 3d object every time for every instance which is not very efficient. It would work better if a 3d object is loaded once then the same information used wherever it is needed.
I had heard the XREF objects have a lower load on Aerofly. I wonder if they are just loaded more efficiently, rather that being less detailed 3d objects? I also noticed that XREF objects have one TMB file for multiple 3d objects. I wonder if that is what Torsten is suggesting.
Perhaps a better method of creating separate TSC files would be to have scenProc spit out a new one, once a specific number of objects have been placed in the TSC file. I have found that the same split grid value does not give a consistent number of splits for each different OSM file. It is different with each source OSM file, even though all my test areas use the same level 10 sized grid for OSM extraction.
If you have a look at the amount of objects loaded at JFK looking towards Manhattan, Aerofly is capable of handling a lot of objects. While the New York initial load time was longer than other parts of the world is was still quite short, and nothing like the 10 minutes you experienced. All we need do is work out why user created 3d objects result in such long load times compared to Aerofly 3d objects. Lets hope the merged TMB files are the answer.
Hi Antoine
How large areas have you tried yet covering with single TOC files? How does it load and show up in AFS2 when flying from abroad, i.e. not starting from within the scenery?
I have found that 3d objects contained inside a TSC appear as soon as they can be rendered as a single pixel on your monitor. This is experience from flights some considerable distance away from the objects.
Like you I found some time ago that level 10 grid size for the OSM source data gave the best results. Any bigger and things start disappearing.
Of course, calling all TMB objects (approx 13k) from 1 single TSC file was no good either.
I also found there is a limit to the level of detail a TSC can provide before things start disappearing. When designing a complex airport for my home town I ran into this limit somewhere north of 280 objects. So I had to keep the objects under this limit. Whether this just a finite number of objects, or is also impacted by the complexity of those objects is anyone's guess. I found that this limit only applies to a single TSC, as multiple TSC files covering neighbouring areas can comfortably exceed this limit even though all objects from both TSCs are visible at the same time.
I am just starting to integrate 3d objects into my template, so I guess I will bump into that as I get further along.
I ask this because earlier tests showed in such a case cultivation would definitely not load before you're close enough from the tile center
My experience is that buildings and trees fade in at about 4nm distance. And this still happens even if the centre point in the TSC has no value. On the other hand lights (TOC) and 3d objects (TSC) are visible from the moon (OK a slight exaggeration). This disagrees with what iPacs have said about object draw distances. My Dad had a great quote "Don't believe anything you hear, and only half of what you see."
If it proves out AFS2 Level 10 tile size to be a reasonable optimum for TOC tile coverage, then I would ask Arno if there's a chance to add a CULT argument to SplitGrid, similar to AGN but for AFS2 Level 10 tiles...
This will cause problems for complicated scripts like my template. I understood that the main purpose of the split grid command is to allow scenProc to multi-task effectively, not for file output. Hence the merge grid to put it all back together. Making the split grid value too big, increases processing times significantly. The split gird value I use was the result of a trial and error testing to find the minimum processing time. This is why your CPU will hit 100% during various parts of Step 1 section.
One thing I would like to see is cultivation integrated with AeroScenery. With the depth of structures being created by the latest template, I think that time is getting closer. I saw a post by nickhod saying he would like to see the same thing. It all depends on whether AeroScenery can access OSM in the same manner as it does Google, Bing and ArcGIS. Then it would just need to remotely run scenProc with an appropriate script. scenProc already has a batch mode but I've never looked at it. If it could do this then installing the resulting files into Aerofly should also be possible. Using AeroScenery to kick off cultivation would also allow easy access to the level 10 sized grid that seems best optimised for cultivation.
Lastly looking at the comments you posted from iPacs I think he may have been talking about initial load time in the 1st quote. ie from when you click start, until you can gain control of an aircraft. While in the second quote he was talking about loading scenery when flying. I've notice Aerofly takes much longer to get me into the aircraft than it did with just textures. Whether this also impacts performance once you are flying I do not know.
have one or two remaining oversized building along the river in the city center - do you have that in your New Orleans test?
Yep. This is the Ernest M Morial Convention Centre.
This was never going to render well as:-
1. It is a very large building with lots of very small odd shaped bits
2. It is slightly boomerang shaped, hence the 2 large buildings not quite aligned.
3. Two freeways go over it. So any building that is actually under a roadway is a problem for Aerofly, as the roads are rendered as textures, and buildings are structures that always sit on top of textures.
4. scenProc has no way of splitting the building based on the freeways that pass over it.
Chris just a couple of pictures flying over the power station and oil refinery near my old home town of Milford Haven in West Wales and to say THANK YOU again for all your hard work.
Glad it is all working out for you. I thought the storage tanks added a new dimension of realism. And they are often near airports.
Otherwise I noticed a strange behavior: the swimming pools in OSM generate buildings ! The pools have nothing to do with the buildings (there is just leisure = swimming_pool, no building tag) so it really looks like a bug.
It could be that the scenProc script you are using isn't specific enough to exclude it. Any polygon can generate a building if you let it, and this can often be an advantage. As you mentioned this doesn't happen for all pools then it could be that the OSM data is inconsistent or incorrect, which always causes problems.
Its very easy to filter out known objects if they are causing a problem, as long as they aren't required for other purposes. I'll use your problem of pools as an example, and the 2 lines below will get rid of them.
AddAttribute|leisure="swimming_pool"|String;skip|yes
UnloadFeatures|skip="yes"
I also ran small test area around this object (https://www.openstreetmap.org/way/69789322) through my old ver 6 template it generated no buildings for the pool.
If you are trying to work out why one particular object generated a building when it shouldn't (or vice versa) then this scenProc command can be a real help. It just creates a txt file that lists all the values scenProc is playing with. I use it all the time to troubleshoot things that aren't working as expected.
ExportOGR|osm_way_id="69789322"|KML|D:\CrispyStuff\Aerofly\Cultivation\details.txt|layerName|ADDSPECIALATTR
Place it just after the ImportOGR line and you get to see only values loaded from OSM. Place just before the ExportTOC (or new ExportTSC) lines and you'll see all the values generated by scenProc. Use different file names for each line placement (ie details2.txt in the 2nd line). If this doesn't trap any information then use osm_id="69789322" in place of osm_way_id="69789322" as some objects don't have "way" in their ID tag.
If a building has been created then you should see 1 object in the first file out and 2 objects (the pool polygon and the building created by scenProc) in the second file. Looking at the values of the objects common to both files usually lets you work out what happened.
Sometimes this doesn't give you an answer so you can get scenProc to isolate the object, by removing everything else. This then allows you to trace a single object through each line of your script to see what lines area are generating something. This is placed just after the ImportOPGR line.
UnloadFeatures|NOT osm_way_id="69789322"
Working out why things don't work is half the fun.
Thanks Michael. Next project - some 3d objects integrated into the template.
Version 7 of my cultivation template is now available for use, and you can find it on page 1 of this thread. Don't forget to update the input file name and folder in the ImportOGR line at the start and the output file name and folder in the ExportTSC line near the end.
Latest scenProc version is required – You will need to have a version of scenProc build date of 2/09/2019 or higher. Earlier scenProc versions will not work with this template. Also the newer version of scenProc will not work with your existing scripts, so best keep a copy of your existing version of scenProc. Alternately you just need to add additional values to your CreateAF2Building command lines to allow them to run with the new scenProc version. Download the latest scenProc here https://www.scenerydesign.org/development-releases/
Testing - The template was tested using 3 areas, Birmingham in the UK, New Orleans in the USA and Brisbane in Australia. So any script combinations were designed to function for buildings in these 3 fairly diverse locations. Hopefully this is sufficient to allow it to work effectively for other parts of the world.
CPU usage - The template is separated into 2 sections or steps. Lines in Step 1 will generally result in high CPU usage, while those in Step 2 result in low CPU usage.
Complexity - The template is quite complex. As a result I have documented each section's purpose and identified any user changeable areas as a “TIP” with an appropriate explanation of the changes possible. Just search for TIP to locate these areas. You are welcome to change values outside these TIP areas, but you do so at your own risk.
Output files - Recent changes by Arno allows scenProc to create a linked TSC and TOC file. Copy both of these over to your Aerofly scenery folder. scenProc will use the name specified in the ExportTSC line for the TSC file name and generate a new filename for the linked TOC file. Make sure you also copy the “building_textures” folder from a FSCloudport airport folder to the same location as your new TSC/TOC files, or else buildings well not appear in Aerofly.
As scenProc automatically creates its own TSC now, don’t forget to disable any TOC reference in any existing airport TSC for the cultivation area you are recreating. Otherwise you might end up with duplications.
Visibility distance – I did see a comment by iPacs once that indicated that building draw distances are controlled by the size value used in a TSC file. However my experience is this is not the case (at least with user created cultivation and airports). Buildings and plants will start to fade in at about 4 nm. This is only usually noticeable for very tall buildings as the others blend in with the ground textures as they fade in as you approach them and fade out as you move away. Lights and FSCloudport structures (or any 3d object referenced in a TSC file) are usually visible from a very great distance, only disappearing when they are too small for your screen to draw. Whether this causes a performance problem is hard to tell.
TSC files – You may note that the TSC file sometimes has no master position on line 6 and a distance value of infinity on line 7. This is a result of the way scenProc compiles the data for the TSC and TOC files. Oddly enough this doesn’t prevent buildings, plants or lights appearing in the correct places in Aerofly, or affect visibility distances. It may be corrected later, but as it has no obvious impact isn’t a high priority.
Arno has made some changes to the CreateAF2Building command, to allow a fallback value when buildings levels and or height are not present in OSM data. The only issue is that this new command (and the old one as well) doesn't work well with buildings generated by the ReplacePolygonByBuildingRectangle command This command splits an individual larger building up into smaller rectangular buildings to better represent the overall building shape. But if you use the CreateAF2Building command to assign random heights for your buildings, the various smaller rectangle that make up the bigger building will have differing heights instead of a consistent height. The only solution is to set the building height before the ReplacePolygonByBuildingRectangle command, so that all the smaller rectangles generated by this command use the original building height for every piece of the larger building. Once this is done the CreateAF2Building shouldn't be allowed to vary the building height, or you defeat the purpose of using the ReplacePolygonByBuildingRectangle command.
If not using ReplacePolygonByBuildingRectangle command then setting a range of heights in the new CreateAF2Building command will work fine by itself.
My latest template handles building heights by default and works with Arno's latest change. But if you want to implement this solution into your own scripts, I have pasted sample code below. The ReplacePolygonByBuildingRectangle lines would sit somewhere between the 2 blocks of code below. You can create more lines like the one shown with <<<--- , to assign different building height ranges to different building types. The example just uses building="*" for simplicity.
# - Identify buildings with height/level recorded in OSM
AddAttribute|building="*" And building_levels="*"|String;levelid|level
AddAttribute|building="*" And NOT building_levels="*" And height="*"|String;levelid|height
# - Indentify buildings with height/level NOT recorded in OSM.
AddAttribute|building="*" And levelid="height" And height="*m*"|String;levelid|unknown
AddAttribute|building="*" And NOT building_levels="*" And NOT height="*"|String;levelid|unknown
AddAttribute|building="*" And building_levels="0"|String;levelid|unknown
# - Set Height/Level for Buildings (where no OSM height/level is available)
AddAttribute|building="*" And levelid="unknown"|String;building_levels|RND(5,10) <<<------
# - Create Buildings (updated command)
CreateAF2Building|building="*"|building_levels|height|0.3|1;1|flat|residential|0
I wonder if something could done to populate large parking lots using ScenProc by adding some sort of organized rows of parked cars for large commercial centers. Tom’s 3D parked cars in the Turkey Creek and Apollo50 packs are absolutely outstanding additions.
This may be possible. But the textures of the real cars gives a good result if you are not too low. Will have to see what impact other 3d models have on performance.
Maybe you can make this depending from the type of road. (Similar to the lights generation at the roads).
The higher the class, the wider the no-trees area.
Done. Will be included in version 7. I just used the same width vs road size I used in my Autogen Buildings Template to remove surplus houses from the edges of roads. You can fine tune values if you want.
Is it also possible to remove trees from the highways?
I should be able to remove them. While roads look wide in OSM they are only stored as a line, so I'll need to do something different to that used to remove trees from water. I can get the script to look for trees within a set distance of any road and remove them. I used this sort of command successfully in the filler template I created to create houses without OSM data. I'll add it to the to do list.
Incredibly work, thank you, pity about the delay but worth waiting for.
Thanks IZOJUB. Hopefully just a short wait. Am testing the change now.
