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?
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?
Yes I use this way in my Martinique scenery... look at it if you can or when i will back home, i will try to give you an example 😉
As I remember you have to write a tsc file like for airport but very basic one
Thanks both.
Shame that you potentially have to create "dummy" airports that (presumably) show up in the AFS map.
it no show up in AFS map
here is my cultivation.tsc:
<[file][][]
<[tmsimulator_scenery_place][][]
<[string8][type][object]>
<[string8][sname][cult_Martinique]>
<[string8][lname][cult_Martinique]>
<[string8][icao][cult_Martinique]>
<[string8][country][France]>
<[string8][coordinate_system][lonlat]>
<[vector2_float64][position][-61.0043615 14.5942353]>
<[float64][height][0]>
<[float64][size][5000]>
<[bool][autoheight][true]>
<[list_tmsimulator_scenery_object][objects][]
>
<[list_tmsimulator_scenery_cultivation][cultivation_files][]
...
>
>
>
Display More
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.
<[file][][]
<[tmsimulator_scenery_place][][]
<[string8][type][object]>
<[string8][sname][cult_N4118_E00912]>
<[string8][lname][cult_N4118_E00912]>
<[string8][icao][cult_N4118_E00912]>
<[string8][country][France]>
<[string8][coordinate_system][lonlat]>
<[vector2_float64][position][9.25 41.35]>
<[float64][height][0]>
<[float64][size][5000]>
<[bool][autoheight][true]>
<[list_tmsimulator_scenery_object][objects][]
>
<[list_tmsimulator_scenery_cultivation][cultivation_files][]
<[tmsimulator_scenery_cultivation][element][0]
<[string8][filename][corse_buildings_N4118_E00912_N4124_E00918]>
<[bool][auto_height][true]>
>
<[tmsimulator_scenery_cultivation][element][1]
<[string8][filename][corse_vegetation_N4118_E00912_N4124_E00918]>
<[bool][auto_height][true]>
>
>
>
>
Display More
Cheers
Antoine
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 ...
QuoteAerofly 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
QuoteMaybe 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
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
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
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.
...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).
yep...
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.
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
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).