Cultivation Not Linked To An Airport

  • I remember reading that it's now possible (as of the most recent big update) to add cultivation without it being linked to an airport.


    Is that correct? If so how is this done, are all .toc files detected and picked up?

  • it no show up in AFS map ;)


    here is my cultivation.tsc:

    for better readability, I have removed all block for each .toc file. And for information my cultivation folder contain only this .tsc file & declared .toc files


    thanks to Trespassers for the tip ;)

  • Shame that you potentially have to create "dummy" airports that (presumably) show up in the AFS map.

    Hi Nickhod,


    Are you talking about cultivation or airport?

    They're not linked anymore.


    Cultivation must be declared to AFS2 within a TSC file, deciding the visibility radius around a center-point defined by its coordinates.


    Previously, a dummy object at least had to be declared in the objects section of the TSC file for your cultivation to show up, but it's not anymore the case.

    What you need in your TSC file is the coordinates of the center of the cultivation tile and the name of the cultivation tile the TSC file is calling.

    I use 0.1°x0.1° cultivation tiles, and 1 tsc file per tile.


    Below is an example of TSC file for a cultivation tile in Corsica.

    The tiles corner coordinates are N4118 E00912 N4124 E00918 (in degmin format), so the LonLat coordinates for the tile center are 9.25 41.35 in decimal format.

    I give a tile-specific name for sname, lname and icao to prevent conflicts.


    So far I used 5000 for size, but it may be reduced.

    The rest of the file is just calling the cultivation tiles.

    In this example I haven't set regional textures, otherwise I'd have declared here their folder path.



    Cheers

    Antoine

    Config : i7 6900K - 20MB currently set at 4.00GHz, Cooling Noctua NH-U14S, Motherboard ASUS Rampage V Extreme U3.1, RAM HyperX Savage Black Edition 16GB DDR4 3000 MHz, Graphic Card Gigabyte GeForce GTX 1080 8GB, Power supply Corsair RM Series 850W, Windows 10 64 bit.

    Edited 6 times, last by Trespassers ().

  • Hi Nickhod,


    Are you talking about cultivation or airport?

    They're not linked anymore.

    Thanks for the example. I had TSC file = airport definition in my mind.


    I was planning out cultivation support in AeroScenery. I previously thought about working on level 9 sized squares for cultivation, but I now think that might be too big.


    Maybe it should be level 10 or level 11 size.


    My idea is that by working on fixed sized squares, people could share their cultivation work easily.

  • I think FS2 can handle level 9 sized cultivation ...


    Quote

    Aerofly in general can handle quite a lot of cultivation data, however, it's best to still spread out cultivation between sectors using airport TSC files. However, we have just rebuilt the graphics engine to handle much larger cultivation files from only one airport TSC.

    If you opt to make one large TOC file make sure that you remember to edit the size of the 'size' parameter located in the TSC file as that it the distance in which Aerofly loads that airport and its data into memory. For example; 'size=5000' allows for Aerofly to load that data from an area 5000 meters from each direction of that airport.


    from Jeff


    I've used the level 9 cultivation approach for several tiles in Texas, I just pick an airport in each tile and add the toc file to that tsc file. You may need a cultivation size option like you have for scenery tiles.


    I am curious about cultivation layers. Is it okay to have level 9 cultivation and then add a 2nd cultivation file inside that area like what happens with scenery tiles where you can add higher resolution scenery around an airport? If the overlap is 2 buildings in the same spot, or 2 trees, or 2 street lights, do both items get displayed? I know some people are using exclude polygons around FSCloudPort airports so their FSCP buildings & static planes won't get polluted by generic cultivation so you'll need an exclude option.

  • ...

    Maybe it should be level 10 or level 11 size.


    My idea is that by working on fixed sized squares, people could share their cultivation work easily.

    In my Martinique Scenery I use Level13 square for vegetation ;)


    if the drill is dense, it already makes a lot of trees per .toc file. many of us had .toc file saturation problems resulting in the appearance of empty strip in forests, probably linked to a limit of the allowed number of trees per .toc file (if I remember well something between 100,000 and 150,000) ... this empty strip effect is linked to the tree detection algorithm organized classically by starting at the top left of the image to finish at the bottom right (so the .toc line are sorted like that). The solution I used to avoid these empty strips is random sorting of my trees before applying a tree number limitation at each toc file in order to lower the density.

  • I was planning out cultivation support in AeroScenery. I previously thought about working on level 9 sized squares for cultivation, but I now think that might be too big.

    Definitely way too big

    Quote

    Maybe it should be level 10 or level 11 size.


    My idea is that by working on fixed sized squares, people could share their cultivation work easily.


    Cultivation tiles are called by TSC files and loaded in block.

    Tile loading causes micro stutters, so the ideal size is the size minimizing the stutter.


    The bigger the file, the longer the stutter, but less frequent. Technically, you could imagine covering a whole country as a single, huge tile, and defining a huge visibility radius, then you can fly quietly over your scenery without stutter (you will have other issues, of course), until you come flying from another place far enough away - then you'll have quite a pause in the simulation while your gigantic toc file loads.


    The smaller the file, the shorter the stutter until access time starts becoming prominent, levelling tile load times.

    And the smaller the tile, the more frequently AFS2 will have to load further tiles when flying.


    So there's an optimum to find and it also depends on how dense your cultivation tiles are getting populated.


    ScenProc allow splitting a region into FS AGN tiles (LOD13), or use degrees.

    I tried several tile sizes and got the best results so far with 0.1° x 0.1° (represents approx. 8 x 11km for the Corsica example).


    Dividing TOC files into AFS2 tiles isn't optimal IMO since :

    - it makes tile identification very difficult when sharing material or reworking a zone

    - it makes new tiles generation very difficult since you have to compute equivalent mercator projections to define the corners and center of your tile.

    - ScenProc has no output for AFS2 tile size (this may be however implemented in the future if it makes sense)


    Anyway, it looks like IPACS divided their toc files into Level 10 tiles


    Cheers

    Antoine

    For comparison, FS autogen tiles are LOD13, i.e. 1.2 x 1.2 km squares. Thus, as the case may be, my 0.1°x 0.1° TOC tiles might still be too big for optimal


    If I set them too small, I'm afraid AFS2 will constantly seek on the disk, making load times longer, so there's an optimum to find...


    For information, as far as I understood, the default load distance is 30km from center position (it's actually a load radius).


    The size parameter in the TSC file is a mark-up in [m] for this load radius.


    For instance, size [5000] makes objects load in a radius of 35km, but I think IPACS talked about changing this, I don't know if this is still valid.


    Cheers

    Antoine

    Config : i7 6900K - 20MB currently set at 4.00GHz, Cooling Noctua NH-U14S, Motherboard ASUS Rampage V Extreme U3.1, RAM HyperX Savage Black Edition 16GB DDR4 3000 MHz, Graphic Card Gigabyte GeForce GTX 1080 8GB, Power supply Corsair RM Series 850W, Windows 10 64 bit.

    Edited 2 times, last by Trespassers ().

  • Anyway, it looks like IPACS divided their toc files into Level 10 tiles, but they cover with ..

    Yeah, I poked around in the Florida DLC and saw that they seemed to be level 10 sized.


    I might test things out at that size. It's a little larger than 0.1° but IPACS must have considered it optimal.


    To be clear, my end goal is a Google Maps view with a level 10 grid (when you zoom in). For each square you can see if someone has uploaded a cultivation file or add your own. Everyone duplicating effort on this seems crazy.


    We can ignore what ScenProc does since I'll be developing AeroScenery Cultivation independently of that. (Shame it's not open source and I could reuse chunks).

  • I am curious about cultivation layers. Is it okay to have level 9 cultivation and then add a 2nd cultivation file inside that area like what happens with scenery tiles where you can add higher resolution scenery around an airport? If the overlap is 2 buildings in the same spot, or 2 trees, or 2 street lights, do both items get displayed?

    Yes, I think they do. I've heard people complain about flicker of cultivation objects where they have a TOC file imported twice.


    I don't think there's any "de-duping" happening. (Understandable for a performance point of view).

  • I also used 0.1x0.1 degree tiles for cultivation.

    This was primarily for tree cultivation in the Alps.

    I used a combination of OSM data and tree detection filter depending on the character of the tile area.

    Tree detection gives a much more realistic distribution for sparse vegetation at higher altitudes, but yields a lot of false positives for mixed agriculture areas.

    For the valley floor I switched to OSM.


    This tile size made for easier to cultivate tiled strips along major valleys and for cultivation verification and regeneration if there is a problem.

    I created a utility app and some batch files to make it pretty much "enter tile center coords and press go"


    Stu

    i7-6700K CPU @ 4.00GHz | ASUS Z170-A | 16Gb DDR4 | Samsung SSD 950 PRO NVME M.2 256GB | Samsung SSD 850 EVO 1TB | GeForce GTX 1080 Ti on GP102-A GPU | Oculus CV1 | Windows 10

  • We can ignore what ScenProc does since I'll be developing AeroScenery Cultivation independently of that. (Shame it's not open source and I could reuse chunks).

    You may need years of development to reach what ScenProc does, I'm afraid... you should rather make Aeroscenery complementary in the meantime...


    Regarding duplicates, everthing gets loaded and displayed, resulting in Z fights between duplicates...

    But it really makes sense defining different layers for vegetation, buildings, light, xrefs or whatever you can include in a TOC file...


    Cheers

    Antoine

    Config : i7 6900K - 20MB currently set at 4.00GHz, Cooling Noctua NH-U14S, Motherboard ASUS Rampage V Extreme U3.1, RAM HyperX Savage Black Edition 16GB DDR4 3000 MHz, Graphic Card Gigabyte GeForce GTX 1080 8GB, Power supply Corsair RM Series 850W, Windows 10 64 bit.

  • if the drill is dense, it already makes a lot of trees per .toc file. many of us had .toc file saturation problems resulting in the appearance of empty strip in forests, probably linked to a limit of the allowed number of trees per .toc file (if I remember well something between 100,000 and 150,000) ... this empty strip effect is linked to the tree detection algorithm organized classically by starting at the top left of the image to finish at the bottom right (so the .toc line are sorted like that). The solution I used to avoid these empty strips is random sorting of my trees before applying a tree number limitation at each toc file in order to lower the density.

    I don't run into the empty strip problem until the tree count gets close to 1M. When I use the photo-detect approach, I shoot for less than 800K trees in a ~10nm x ~10nm area. I am using the POINT DetectionMode, not the Polygon DetectionMode because POINT seems to do a better job with trees around golf courses, houses, streets, etc. - like the difference between 2m resolution and 0.5m .

    Regarding duplicates, everthing gets loaded and displayed, resulting in Z fights between duplicates...

    But it really makes sense defining different layers for vegetation, buildings, light, xrefs or whatever you can include in a TOC file...

    I've started using this toc layered approach - map.toc for houses, low buildings, and lights + trees.toc + skyscrapers.toc from a small osm file of the downtown area. There is some risk of duplicate objects where the skyscrapers get planted.


    It also speeds up the refining process with isolated layers because you are only re-running one part of the cultivation.

  • I decided to go with 0.1 x 0.1 degree tiles in the end, it does seem to be a good compromise.

    Also splitting it up into layers is a nice tip.


    I have a couple of remaining questions though...


    - Is [size] the distance from the [tmsimulator_scenery_place] rather than each cultivation object position?


    - If so, then I guess one tsc file per square is needed.

    If not, what spacing of tsc files is optimal (let's assume this is cultivation further away from an airport)

  • Nick, my current theory is that:


    1) [size] only applies to objects listed in the tsc and does not apply to any cultivation because ...

    2) only the cultivation within a 5-6km radius of your aircraft is loaded & displayed on your screen to minimize the GPU load


    Maybe someone from IPACS will confirm or we can run some tests to prove / disprove this theory.

  • Good thinking. I have the feeling the way TOC files are loaded and displayed in AFS2 changed with the latest big update, it doesn't behave exactly as it used to.

    In other words, what I wrote previously might be wrong now...


    It would be nice if IPACS could give some hint how it is now implemented and how we should best do our cultivation.


    Cheers

    Antoine

    Config : i7 6900K - 20MB currently set at 4.00GHz, Cooling Noctua NH-U14S, Motherboard ASUS Rampage V Extreme U3.1, RAM HyperX Savage Black Edition 16GB DDR4 3000 MHz, Graphic Card Gigabyte GeForce GTX 1080 8GB, Power supply Corsair RM Series 850W, Windows 10 64 bit.

    Edited once, last by Trespassers ().

  • My observations showed that the displaying radius mentioned above (5 -6km) is maybe correct for buildings and trees but lights are displayed in a wider radius (more than 50km).

    Best regards,

    Thomas


    i7-6700K @ 4.0 GHz, Geforce GTX 1080, 32MB RAM, 500 GB SSD, 1 TB SSD, 1TB HD, 32" Monitor 4K, Oculus Rift