Mesh creation issues

  • well, no secret, it is in the elevation tutorial:

    https://earthexplorer.usgs.gov/

    Aaah ok you were talking about the USGS portal, but sadly it's for USA only !

    I've tested successfully a mesh creation based on IMG filed exported from that site, I haven't seen a export directly in TIFF was possible, good to know.

    Basically I was very surprised and excited because I understood that there was info on mesh creation in the official AFS wiki because you had talked about "IPACS-wikipages". But unfortunately I think that IPACS has never published official information about mesh creation, except in the forum to say that it could be "dangerous".

  • Aaah ok you were talking about the USGS portal, but sadly it's for USA only !

    Nono... i have my SRTM data for the Czech Republic from there.

    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 looks crazy for me is that you have the spike issue even if you disable the Swiss DLC mesh.. and also your own mesh ?!?

    Not exactly, let's summarize :

    Mesh DLC activated + DEM5m activated = spikes

    Mesh DLC deactivated + DEM5m activated = spikes

    Mesh DLC activated + DEM5m deactivated = no spikes

    Mesh DLC deactivated + DEM5m deactivated = didn't try, but sure no spikes

    Thus, it is this patch of DEM5m that causes the spikes, but I have no clue where it comes from. The data don't seem corrupted...

    Regarding the masks, the boolean switch obviously only works for ground texture tiles, not for mesh.

    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.

  • Thanks for that hint, will look for those no data pixels

    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.

  • Nono... i have my SRTM data for the Czech Republic from there.

    Oh I haven't realized that DEM outside of US were available on USGS ! Not for all dataset of course but it's true it is the case for SRTM 1" so I'll give a try during the WE, thanks for the info.

    I imagine however that the DEM for the Alps from J. de Ferranti are "better" even if they're also based on SRTM 1".

    Not exactly, let's summarize :

    Mesh DLC activated + DEM5m activated = spikes

    Mesh DLC deactivated + DEM5m activated = spikes

    Mesh DLC activated + DEM5m deactivated = no spikes

    Mesh DLC deactivated + DEM5m deactivated = didn't try, but sure no spikes

    Ah ok, it is less crazy like that ;)

    Regarding the masks, the boolean switch obviously only works for ground texture tiles, not for mesh.

    I was thinking the concept of mask could apply also to the elevation images, but it's not the case ?

    Geoconvert automatically generates masks when creating meshes so for me it was exactly the same concept than with orthophotos: it creates mask to "complete" elevation images which don't fill totally AFS tiles.

    When I did my mesh the spikes were from no data pixels.

    Which you cant see on Qgis but can clearly see when opened in GIMP as white dots.

    But from what we can see in QGIS there is no visible void area as in AFS the spikes are "everywhere".

  • As I said you can't see them no data's in QGis as Qgis has the ability to interupt and render them correctly.

    Sadly geoconvert and fortunately GIMP don't.

    Open the geotiff in gimp, if there are lots of white dots/areas thats your problem (Not visible in Qgis)

    If not, the problem is something else.

    I have some thoughts about it but need to check stuff before I say more.

    As I had similar issues when I tried to add a 5m mesh on top of the SRTM 30 metre mesh in selected areas.

    I left that problem for a later time and just haven't got back to it yet. Just been enjoying the 30 metre. :P

  • Oops sorry I haven't read well your second sentence so I'll give a try with Gimp to check it...

    In AFS the spikes are "everywhere" but the void area cannot be "everywhere" in the TIFF because the rendering in QGIS looks very fine (unless it's very very smart and can interpole the whole DEM with only few valid pixels).

    Futhermore I've understood that the SRTM tiles from J. de Ferranti (as well the ones from CGIAR-CSI) had been cleaned and thus without any void area. But maybe it only takes a few void pixels to mess up Geoconvert...

  • Well, cleaned perhaps but not spotless, not for NSW Central Coast of Australia

    I spent a few hours cleaning in GIMP

    In GIMP the geotiff will be much much darker, so you will have to change colour levels, this just makes it brighter on your monitor but it don't change the actual colours in the file (I THINK, I'm a GIMP noob but it worked)).

    Then I used the colour picker and choose neighboring pixel to match colour, aka interpolate by hand lol.

    Then I reverted the colour levels just to be sure and then exported as tiff.

  • If no data isn't the issue it could be the elevation format.

    For example the 30 metre mesh I used was in 16bit format and apart from the fixable no data spikes worked great.

    But when I tried to add a 5 metre mesh using 32bit format on top, it was all spikes.

    So it makes me suspect that it may be a elevation data format thing in my case when adding the 5 mtre mesh on top of 30 metre mesh.

    In Qgis check what elevation format your file uses, 16 or 32bit

  • It is a good point ! A problem of encoding on the height seems to me more credible than a problem of void area. I hope this is the case because I have never used Gimp and I do not see myself correcting these possible empty pixels by the hand ;)

  • oh please, try to get used to gimp. Nothing worse than airport ground not usable because of mesh. You need to flatten areas. I even flatten some of the gras-strips.

    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

  • Well my attempt with a graphical tool like Gimp was disatrous but I find a handfull way to do it with QGIS.

    In QGIS just go to Process > tool box > SAGA > Reclassify values and then in the bottom of the dialog box just uncheck "replace other values", and that's all !

    So now I have a cleaned DEM of J. de Ferranti for my tile and I don't have anymore the Interstellar water wall in AFS :)

    And I forget to say that everything is running well even if I reactivate the base mesh ! I don't have any idea why but I'm happy :)

  • Note that my previous trick works only to fill void pixels over the sea (by setting the value to 0). But I'm pretty sure than QGIS power users (that I'm not) can do also some interpollation in a few clicks to fix void pixels over the ground...

  • Hello Turman

    I been trying to follow your instructions

    "QGIS just go to Process > tool box > SAGA > Reclassify values and then in the bottom of the dialog box just uncheck "replace other values", and that's all !"


    I need help, I tried that but when I run qgis I get an error.

    Do you have to add a no data value, or Min and max height data?

    I tired uncheck "replace other values" and running it by it stops with an error.

    If you can kindly give me more detailed instructions that would be great.

    Other wise if its that simple maybe the error lay else where.

    Just want to be sure Im not making a mistake.

    Some Background, I have a 1metre .asc file with a accompanying .prj file

    Ive contverted it to EPSG4326:WGS84

    Its coverts just fines, but I get the spikes like you did.

    I tried renaming elevation folder to test default mesh conflict, but the game just makes a new one, lol

    So now Im asking for help

    Before I write my next post for help with gimp, small help promise

    Cause I been trying to avoid having to learn gimp

    Fingas crossed

    The Error

    Processing algorithm…

    Algorithm 'Reclassify values' starting…

    Input parameters:

    { 'INPUT' : 'E:/CamdenAirportElevationData/Wollongong201102-LID1-AHD_2866230_56_0002_0002_1m/Wollongong201102-LID1-AHD_2866230_56_0002_0002_1m.asc', 'MAX' : 1, 'METHOD' : 0, 'MIN' : 0, 'NEW' : 1, 'NODATA' : 0, 'NODATAOPT ' : True, 'OLD' : 0, 'OTHEROPT ' : False, 'OTHERS' : 0, 'RESULT' : 'C:/Users/Administrator/AppData/Local/Temp/processing_26d900214dee49f687501e7910988193/5a1cfd29fdcf4f929dad182a5e637354/RESULT.sdat', 'RETAB' : [None], 'RNEW' : 2, 'ROPERATOR' : 0, 'SOPERATOR' : 0, 'TOPERATOR' : 0 }

    Traceback (most recent call last):
    File "C:/PROGRA~1/QGIS3~1.4/apps/qgis-ltr/./python/plugins\processing\algs\saga\SagaAlgorithm.py", line 286, in processAlgorithm
    s = '{}\t{}\t{}\n'.format(values[i], values[i + 1], values[i + 2])
    IndexError: list index out of range

    Execution failed after 0.04 seconds

    Loading resulting layers

    Algorithm 'Reclassify values' finished


    Edit: Currently learning Display colour levels and stencils in Gimp

    Edited once, last by ozhomeroz (October 9, 2019 at 12:16 PM).

  • Hello elevation map devs guys and girls.:*

    I have an idea 8|of what may be causing spikes in user made elevation meshes imported into the game, and would like to share this idea to see what others though about it.:/

    The Idea:

    Aerofly has difficulty (spikes) interpreting higher resolution elevation data mesh because they are encoded using more bits per data pixel. Let me quickly explain.

    First some background.


    The Principal:

    Much like in computer graphics where higher colour resolution/fidelity requires more bits per pixel to represent encoded colour information.

    Aka:

    256 Colours requires 8bits

    65536 Colours requires 16bits

    16.8 million Colours requires, etc

    Same thing applies to height information in elevation maps,

    Higher resolutions require more bits to encode to data.

    I realise that resolution regarding elevation maps refers to Metres per pixel.

    I thought that well, as resolution increased in terms of metre's per pixel perhaps height resolution per pixel did as well.

    To test, I loaded 3 elevation maps into QGIS and checked their properties, and discovered the following:

    30 Metre SRMT mesh uses Data type: Int16 - Sixteen bit signed integer.

    5 Metre Sydney mesh uses Data type: Float32 - Thirty two bit floating point.

    1 Metre Camden Airport mesh uses Data type: Float64 - Sixty four bit floating point

    Ok so now we can confirm that elevation maps can be encoded with 16/32 or 64bits depending on height resolution

    So the game uses a 16 bit height space and the 32 and 64 bit height data is outside this 16 bit space. So spikes IMO.

    About the Spikes:

    I read on the forum (can't link, the forum is fluid) that the default IPACs mesh is based on SRMT data, lets say 16bit/30 metre data, not sure but lets say as the principal still applies.

    The spikes are due to geoconvert being unable to interept non 16bit SRMT height data such as 32 and 64 bit height data found on higher resolution elevation maps.

    This maybe due to IPACS wanting to keep elevation data size smaller, as file size increases as more bits are encoded in each pixel.

    Solution:

    If this indeed true, cant do much till geoconvert is updated with the ability to convert/compress the 32/64 bit height data into the 16 bit height space compatible with the sim.

    Edit: Or maybe this can be done in GIMP prior to geoconverting, Hint Gimp dudes hahaha

    Edit 2: Mmm or use QGIS to do it. Mmm

    What do you guys thinks? :/

    Edited 4 times, last by ozhomeroz (October 20, 2019 at 3:13 PM).