Floating (and buried) cultivation

  • I know that this has been talked about before but I've read a few different explanations (and possible cures), so I was just wondering what the latest thinking is. I also want to clarify my own undestanding of the issue.

    It's only become an issue for me since I started improving the terrain heightmap in certain areas. It's never a problem where I start from. It only appears after I've flown a few miles from my starting point. If I then restart at that point the problem goes away. Cultivation may be either floating or buried, and the effect seems to be greatest where the discrepancy between the default and high res terrain meshes is greatest (ie steep slopes, valleys etc). Oddly enough I've never noticed it happening with trees - only buildings.

    The first thing I thought to blame was my Ordnance Survey cultivation, which is based on 100 x 100 km areas and often involves TOC files well over 1 GB in size. So I decided to split the cultivation into 0.2 x 0.2 degree areas (roughly 20 x 20 km - a bit less than a level 10 square). Unfortunately, however, this has done nothing to improve the situation.

    My understanding is that it occurs because the buildings load before the higher res mesh, so they are placed on the lower res mesh. Is that correct? If so, it means that either the buildings need to load more slowly, or the mesh more quickly? Any thoughts would be greatly appreciated.

    Edited once, last by Ian C (February 28, 2019 at 2:33 PM).

  • How big are your cultivation regions? Earth curvature is modeled in aerofly, which means big enough models will tend to hover above the terrain.

    Does your situation improve it you split the cultivation into smaller chunks?

    Splitting it into smaller chunks doesn't seem to help. I've gone down from 100 x 100 km to 20 x 20 km and it makes no difference. Also I never had the problem before I introduced higher res terrain mesh, even with 100 x 100 km areas - so I guess it's somehow related to the new terrain mesh. I tried putting the TTH files on the (SSD) C-drive, thinking that that would make them load faster - but that doesn't help either.

    I'm beginning to wonder whether this isn't inevitable if you have an improved terrain mesh. With the default mesh it doesn't make any difference if the higher level TTH tiles load later than the lower level ones (starting at level 7). It doesn't alter the shape of the terrain when they load because the heightmap data is low res (roughly level 7) anyway. However with higher res data it does make a difference to the shape of the terrain when the higher level TTH files load - so if a building "sees" a lower level TTH tile before it "sees" a higher level one it's going to "sit" on the lower level tile so to speak - and therefore be at the wrong height. Perhaps it would help if there was a way of making the buildings "wait" intil the mesh has fully loaded?

    This is pure speculation on my part BTW - and may be completely wrong!

    It's also a mystery why it doesn't affect my trees. Why should buildings behave differently from trees?

    Ian

    Edited 4 times, last by Ian C (February 28, 2019 at 6:02 PM).

  • I don't know about Aerofly but what you describe can be seen in the FSX based Simulators as well, reason being exactly what you guessed - buildings being positioned on a low res mesh before the higher res mesh loads in. I guess the only workaround would be to change the distance at which the high red meshes is loaded, which would probably decrease performance significantly. I think there's a reason why most simulators ship with an average resolution mesh by default, you have to make a compromise between visual quality, performance and susceptibility to artifacts and visual errors.

  • well, the size of the tocs must be smaller than the size off the max resolution elevation tile.

    then you have the size in the tsc file of the toc. This should not be bigger than the distance, the max-resolution-elevation tile gets loaded. Possibly you have not corrected the tsc file after splitting your tocs?

    At least for my comores islands it was the solution. If you don't reduce the size, the tocs possibly gets loaded when only the low res elevation is in memory.

    Wish for Aerofly FS 2/4:

    - Flightpath recording on hard drive and replay in sim from different view points

    - Smoke for aerobatic planes

    - Multiplayer or at least watching other people flying sitting on ground or inside tower

  • I don't know about Aerofly but what you describe can be seen in the FSX based Simulators as well, reason being exactly what you guessed - buildings being positioned on a low res mesh before the higher res mesh loads in. I guess the only workaround would be to change the distance at which the high red meshes is loaded, which would probably decrease performance significantly. I think there's a reason why most simulators ship with an average resolution mesh by default, you have to make a compromise between visual quality, performance and susceptibility to artifacts and visual errors.

    I suspect you may be right. The ORBX Netherlands scenery has a 5 m terrain mesh (I think) but the Netherlands is a very flat country so you probably wouldn't notice anything unless your house was on top of a dyke!

    well, the size of the tocs must be smaller than the size off the max resolution elevation tile.

    then you have the size in the tsc file of the toc. This should not be bigger than the distance, the max-resolution-elevation tile gets loaded. Possibly you have not corrected the tsc file after splitting your tocs?

    At least for my comores islands it was the solution. If you don't reduce the size, the tocs possibly gets loaded when only the low res elevation is in memory.

    That's an interesting point about the relative sizes of the TOCs and high level tiles. I assume that means the total size of the TTH tiles within the circular area covered by the TSC "size" parameter? But I'm confused, because I would have thought the TOC would need to be the larger of the two, so that the buildings would load later? In any case I will experiment with it.

    I did correct my TSC "size" parameter to "5000" after splitting the large TOCS. Previously it was "80000".

  • what I don't know is, when exactly the tth files get loaded, because they do not have a size parameter somewhere.

    This would be the reference for setting the size parameter in the tsc file, containing the toc file. The plane should hit first the boundary that triggers the load of the tth file. After that it should hit the size boundary of the tsc file containing the toc file.

    Of cause, the size parameter should not be to close to the actual border of of the area in the toc file containing the objects.

    If it will be to close, I think the cultivation will suddenly popup if you get close enough.

    I hope, this is the way Aerofly fs 2 handle this. :)

    Wish for Aerofly FS 2/4:

    - Flightpath recording on hard drive and replay in sim from different view points

    - Smoke for aerobatic planes

    - Multiplayer or at least watching other people flying sitting on ground or inside tower

  • what I don't know is, when exactly the tth files get loaded, because they do not have a size parameter somewhere.

    This would be the reference for setting the size parameter in the tsc file, containing the toc file. The plane should hit first the boundary that triggers the load of the tth file. After that it should hit the size boundary of the tsc file containing the toc file.

    Of cause, the size parameter should not be to close to the actual border of of the area in the toc file containing the objects.

    If it will be to close, I think the cultivation will suddenly popup if you get close enough.

    I hope, this is the way Aerofly fs 2 handle this. :)

    Yes - there are some things that are a bit of a mystery. In a situation like this the only way is probably to experiment with various parameters and see what effect it has.

  • what I don't know is, when exactly the tth files get loaded, because they do not have a size parameter somewhere.

    This would be the reference for setting the size parameter in the tsc file, containing the toc file. The plane should hit first the boundary that triggers the load of the tth file. After that it should hit the size boundary of the tsc file containing the toc file.

    (...)

    That's also the way I see it.

    As far as I understood, the size parameter in the TSC file is a markup in meters above the default load radius, which seems to be some 30km...

    Cheers

    Antoine

    Config : i7 6900K - 20MB currently set at 3.20GHz, 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.

  • That's also the way I see it.

    As far as I understood, the size parameter in the TSC file is a markup in meters above the default load radius, which seems to be some 30km...

    Cheers

    Antoine

    oh. This is interesting. In that case the size value of 5000 means 35 km around reference point? I guess we need to make some tests with normalised elevation and cultivation files to get to the truth.

    I normaly put a bit more than the distance from center to one corner into the tsc. The 30 km plus would explain why the cultivation is in place without popup.

    Wish for Aerofly FS 2/4:

    - Flightpath recording on hard drive and replay in sim from different view points

    - Smoke for aerobatic planes

    - Multiplayer or at least watching other people flying sitting on ground or inside tower

  • That's also the way I see it.

    As far as I understood, the size parameter in the TSC file is a markup in meters above the default load radius, which seems to be some 30km...

    Cheers

    Antoine

    There's something I'm confused about here. I've always assumed that the "size" parameter in the TSC file is measured from the longitude and latitude in the TSC file - i.e. from a fixed point on the earth's surface. I thought that it determined how far from that point the cultivation could be seen. In that case the size boundary is a fixed circle on the earth's surface so there would be no way of guaranteeing that you hit it after the load distance of the TTH files, since it's not centred on the aircraft. Maybe I've got the wrong idea?!

  • tth Files are independent from the tsc files.

    This is the reason why I can only guess, that the reference point of tth files would be in the middle. And I can only guess, how near a plane must get so that the tth file will load.

    Wish for Aerofly FS 2/4:

    - Flightpath recording on hard drive and replay in sim from different view points

    - Smoke for aerobatic planes

    - Multiplayer or at least watching other people flying sitting on ground or inside tower

  • The autoheight parameter if set to true typically places all objects at ground level (given your pivot point is centered for each object). This however works mostly only in areas that a user creates. Our scenery autoheight isn't working the way that it should be right now but we do know about this.

    Floating and buried objects are mostly happening because of this issue but not always;, for example; if you have far too many objects iloaded under one TSC file and the poor performance 'breaks' the autoheight and floats your objects (cultivation). The best way to fix this is to make multiple TSC files (and TOC's) to better optimize your project.

    The size parameter is indeed a load point of the TSC. This parameter is measured in meters, but should only be used as a guide as there are many other variables used for when the TSC is loaded, some of these are based on what your graphical settings are set at. As a guide, lets say that your scenery area for any particular TSC is 5 nautical miles x 5 nautical miles, you first want to convert the miles to meters, so 9260 meters, now take half of that (since its your center point that's important here, so 4630 meters. Now you can use this number if you want the scenery to load as soon you are at its edge or you can add some meters to it so that the scenery loads from a ways out, lets say you want your TSC to load 1 nautical mile from the edge your number will be 6482.

    so size=6482 in the referring TSC will load into memory 1 nautical mile from any direction.

    IPACS Development Team Member

    I'm just a cook, I don't own the restaurant.
    On behalf of Torsten, Marc, and the rest of the IPACS team, we would all like to thank you for your continued support.

    Regards,

    Jeff

  • The size parameter is indeed a load point of the TSC. This parameter is measured in meters, but should only be used as a guide as there are many other variables used for when the TSC is loaded, some of these are based on what your graphical settings are set at. As a guide, lets say that your scenery area for any particular TSC is 5 nautical miles x 5 nautical miles, you first want to convert the miles to meters, so 9260 meters, now take half of that (since its your center point that's important here, so 4630 meters. Now you can use this number if you want the scenery to load as soon you are at its edge or you can add some meters to it so that the scenery loads from a ways out, lets say you want your TSC to load 1 nautical mile from the edge your number will be 6482.

    so size=6482 in the referring TSC will load into memory 1 nautical mile from any direction.

    This was my understanding of the "size" parameter - though I usually also multiply by root 2 (1.414) so that the scenery loads at the corners of my cultivation square. I see the point about performance and TOC size, but I never had the floating building problem before I added high res TTH files - so I suspect they must be the culprit. Also the buildings tend to float or sink where the high res mesh makes most difference - i.e. on steep slopes etc. The problem can be cured by restarting the simulator, but it then creeps in again after I've flown a few miles. Even then, 90% of the buildings are OK - and it never affects my trees for some reason.

  • Yours seems like a performance issue rather than any parameters. Yes adding hi-res files is not optimal and is likely your culprit.

    IPACS Development Team Member

    I'm just a cook, I don't own the restaurant.
    On behalf of Torsten, Marc, and the rest of the IPACS team, we would all like to thank you for your continued support.

    Regards,

    Jeff

  • This seems to have changed recently. I went back to look at some power pylons in an area I am familiar with.

    Previously on "level ground" along the valley floor the piers were showing slightly.

    Now there is a random amount (+- 2 or 3 M) of the piers showing (or buried).

    The TOC size and TTH set have not changed from when the objects were placed correctly wrt ground level.

    I am not sure exactly when this behavior changed, but probably within the last week or two.

    I certainly would have noticed this effect while testing PylonGen and osm2AFSobject in that area .

    /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

  • Interesting. Is that happening with the default terrain mesh? I had assumed that my problem was related to my custom mesh. Also I find that it never happens at the point where I start the simulator - it's only after I have flown a few km from my starting point.

  • with the default terrain mesh?

    This was immediately on startup with custom elevation at level 14

    However when I started again to get a screenshot. all towers were fixed with a appropriate exposure of the piers.

    So i don''t know what caused the effect. If it occurs again I will definitely get a screenshot.

    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

  • Hi all,

    Below is a statementI had once from Torsten regarding the size parameter, it doesn't quite fit with Jeff's explanation, thus I don't know what might have changed in the meantime.

    Regarding lenidcamper's issue, it seems to me quite typical when objects height is computed before the highest mesh level is loaded.

    The exact moment when the highest mesh level or photoground texture is loaded depends on the distance and the system perfomances.

    In some occasions it gets slower due to whatever reason (memory usage, disk access, background tasks, etc.), that's what used to cause the infamous blurries in former FS9 and FSX photosceneries, and that you still can see in P3Dv4 when flying very fast or using the slew mode.

    In AFS2 tiles are loaded much faster (much less to load also) therefore only in some seldom startup cases you can see blurries, that immediately disappear as the textures get refreshed.

    But if you set a too high mesh level together with a long range cultivation load distance, you'll get those auotheights issues, and they will also depend on user's computer => some might have more or less of them with the same scenery...

    Cheers

    Antoine

    Config : i7 6900K - 20MB currently set at 3.20GHz, 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 (March 12, 2019 at 8:45 AM).