AeroScenery Beta - Help With Testing Required

  • Thanks Tom. Yes, the map issue is definitely the decimal comma again.


    In SQLite browser you can go to the "Browse Data" data, select the table in the drop down and see what's in there.


    I would guess that the airports issue is related somehow.

  • Could this be the issue? Just a thought.

    It's possible, yeah.


    One thing to bear in mind is that my stitch files don't match AFS grid tiles. They're just multiples of Google or Bing tiles stuck together (always larger than the AFS grid tile). They probably wont match what FSET is doing at all.


    For each stitch tile, when I last checked the NW lat / lon, SE lat / lon and calculated pixels per step it all checked out, but I will go over it again.


    My guess is still that GeoConvert wants slightly different coordinates in the tmc file. I'm going to try changing them by hand to see if I can get it to snap to a whole grid square and go from there.


    It's a shame that IPACS don't publish a list of gird square coordinates boundaries to avoid the ambiguity.

  • I must admit I don't quite understand the reason for the rather confusing Levels naming in Aeroscenery.


    Level images in Aeroscenery obviously correspond to LOD levels in FS with an offest of 2 :

    Aeroscenery Level 15 = LOD13 = 4.77 m/pixel

    Aeroscenery Level 16 = LOD14 = 2.39 m/pixel

    Aeroscenery Level 17 = LOD15 = 1.19 m/pixel

    etc.

    In a similar way :

    LOD 11 is 19m/pixel

    LOD 10 is 38m/pixel

    etc.


    In FSET you try getting a better image resolution than the Level you'll compile => if you can get a 0.5 m/pixel source to compile in 1m/pixel it's optimal.


    As far as I understood, Geoconverter Levels in AFS2 seem to be quite similar to LOD levels with an offset of 1:

    AFS2 Level 10 = more or less FS LOD11

    AFS2 Level 11 = more or less FS LOD12

    AFS2 Level 14 = more or less FS LOD15



    Hence, Level 17 images in aeroscenery seem to correspond to Level 14 in AFS2, i.e. an offset of 3. But both being named Level, that's pretty much confusing.


    Since there's little chance anybody will use Low level values <7 and Aeroscenery is dedicated to AFS2, I'd suggest using the same Levels scale for both


    My 2 cents

    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.

  • I must admit I don't quite understand the reason for the rather confusing Levels naming in Aeroscenery.

    Fair point, but it's just what they're called on the actual Google and Bing map APIs (and on Ortho4XP). I used to use Ortho4XP and so I was used to that terminology.


    In 0.5 you'll see that's it's now called "Image Detail Level" to avoid some confusion.


    Unfortunately too late to change it as everyone's folder names would be wrong.

  • Nick,

    the table itself seems to be OK for me:

    Thanks.


    No there's something very wrong with the coordinates! See LIPQ for example.


    I think what's happening is that isn't not parsing decimals from strings correctly in your locale (it's expecting a comma).


    I'll do a 5.1 release soon to hopefully sweep up some of these bugs.

  • Fair point, but it's just what they're called on the actual Google and Bing map APIs (and on Ortho4XP). I used to use Ortho4XP and so I was used to that terminology.


    In 0.5 you'll see that's it's now called "Image Detail Level" to avoid some confusion.


    Unfortunately too late to change it as everyone's folder names would be wrong.

    Got it, thank you for that clarification !


    Cheers and keep up the good work

    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.

  • There may be a mistake in my grid calculation class... Chris what tool do you use to note the coordinates in FSET?

    It might be interesting to see how qwerty42 calculates its grid in its small Excel utility: https://flight-sim.org/filebas…rid-calculator-for-excel/


    I use qwerty42's Excel utility to give me the coordinates for FSET. It matches the grid coordinates used in FSET with the tile size in FS2, depending on the level you are creating. It then is a simple process to flip backwards and forwards between Excel and FSET until you get the right grid layout to match adjoining areas you have already created. Any time I do an extract I take a screen shot of the FSET screen. I can then review this screenshot when doing my next area so I can calculate a lat long for the starting point for the Excel utility. Creating adjoining scenery areas is a lot easier this way and ensures that the areas you are selecting in FSET match those used by FS2 grid tiles. I also use a web page utility created by Spit40 (I think) that then takes the information from FSET and creates the output to past into the TMC file GeoConvert uses. Getting the computer to calculate these two conversions makes the likelihood a mistake much less likely, and speeds up the process. Using this process I almost never get scenery issues in FS2 using the FSET scenery process. This process is repeated to create detailed imagery around airports, again using the Excel utility with a different FS2 level setting. If you were doing tiles for levels 12 and 13 in FS2 then you would set the Excel utility to level 12 and that would ensure that any level 12 & 13 imagery created by FSET matches the tile sizes for level 12 ands 13 in FS2.

    Thanks, Chris

    Win 10 64-bit, 20GB RAM, i7-3820 @ 4.2, 4GB Nvidia GTX 970

  • I use qwerty42's Excel utility to give me the coordinates for FSET.

    I ported that Excel file's formulae to C# so I'm using the same coordinates. To save anyone else time looking at this...


    I took my random Level 13 size square that was producing an extra "band" with masks at the bottom.


    AeroScenery generated the following coords in the TMC file for that square


    <[vector2_float64] [lonlat_min] [2.15 46.77]>

    <[vector2_float64] [lonlat_max] [2.20 46.74]>


    When I hand tweaked the coords to this


    <[vector2_float64] [lonlat_min] [2.15 46.77]>

    <[vector2_float64] [lonlat_max] [2.20 46.*75*]>


    It worked as expected and just output one ttc file with no masks.


    So, it's a rounding error.


    Question is, if I fix that does it break it for other scenarios? (Pessimistically I'm guessing yes). It'll need some testing.


    The ideal here would just be to be able to lookup "map_13_8188_a608" from a predefined list and get the coords GeoConvert expects.

  • Unfortunately too late to change it as everyone's folder names would be wrong.

    Hi Nick


    I think it is a little early in the beta process to be locked into legacy.


    For the long term ease of use, intuitive name conventions are worth their weight in gold.

    After building software for 20 years I can't count the number of times we said "I wish we had cleaned that up before it got cast in stone"


    Stu


    PS AeroScenery looks very promising so far.

    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

  • I think it is a little early in the beta process to be locked into legacy.

    For the long term ease of use, intuitive name conventions are worth their weight in gold.

    On reflection, I don't think it is legacy or a bad decision. AFS grid squares define a specific area, Google and Bing zoom levels are a standardised thing and describe a meters per pixel value. They're totally independent of each other and trying to name them the same might lead to more confusion.


    Currently been building commercial software for 15 years and also know that feeling though!


    Thanks for the words of encouragement.

  • Hi Nick,


    On the other hand nobody knows (and cares to much of) Bing specific tile naming convention and, as you said, the resolution you seek is not the level you're going to geoconvert.


    I think the GUI should simply be clear enough. The rest is detail.

    Hence the naming 'zoom' level in FSET with indication of the corresponding resolution: there's no confusion with the level you're expecting to geoconvert, and you are sure you're not trying to geoconvert in level 14 raw images downloaded in 5m/pixel...


    Don't take it bad, I know I'm acting as the one sitting outside at the café and criticising.

    I'm really enthusiast and we're only talking about details.


    Keep up the good work

    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.

  • Hey Nick, I don't think it's actually a rounding error (I tried with 10 decimal places and same results--you don't need to use just 2 decimal places in the tmc file), and I did some tests myself just now to see if it's a truncation issue instead (i.e. maybe geoconvert just drops all digits beyond a certain number vs. rounding). It appears to be neither.

    But maybe this will still fix it: back when I made that Excel tool, I noticed a discrepancy between my calc'd coordinates vs. what another tool, GeoConvertHelper, writes into the .tmc file after I'd given it my exact coordinates. I originally thought it was a bug in GeoConvertHelper. However after emailing the author Uwe, it turns out he adjusts the input coordinates in order to work around this issue. I haven't tested it extensively, but at least in all the cases I've tried so far his workaround fixes it.


    His workaround is this: he shifts the calc'd coordinates of the bounding box inward by 0.01 when he writes them to the .tmc file. So as an example using your same level 13 tile, the 'exact' calculated coordinates are:



    <[vector2_float64] [lonlat_min] [2.153320312500 46.774106625082]>

    <[vector2_float64] [lonlat_max] [2.197265625000 46.744400395091]>


    Then, when he writes them to the .tmc file, they become:


    <[vector2_float64] [lonlat_min] [2.163320312500 46.764106625082]>

    <[vector2_float64] [lonlat_max] [2.187265625000 46.754400395091]>


    Notice the 2nd decimal in each of these has been shifted by 0.01 to shrink the bounding box 'inward' on all sides.

    Again, I can't guarantee this works in all cases, but I did some limited checks here and it seems like it may. FWIW, the math that calculates those coordinates in my Excel sheet came from IPACS code that Rodeo provided to us in another thread a long time ago, so I don't think it's anything we're doing wrong with the math.


    If you ported *all* of the math from my Excel sheet into C#, and you included that field I called "Coord padding for rounding error", you could set that value to a constant of -0.01 and it would do this adjustment for you.


    Also, great work on this awesome tool. IPACS owes you a serious debt of gratitude for making their sim more accessible to others with a tool like this, and I hope they really take this to heart and do what they can to help you further in your efforts.

  • When geoconvert runs with Masks Off, the Level 9 tile doesn't generate, Levels 11 and 12 have gaps. Does anyone have this problem?

    Missing tiles with masks off is systematic of scenery areas being generated not aligning with FS2 grids. When this happens GeoConvert just skips tiles that would only be partially textured. Turning masks on instructs GeoConvert to generate these partially textured tiles and a matching mask tile which I assume allows FS2 to correctly render these types of tiles.


    Similar thing happens if your source images have transparencies. With masks off any tile that would have included an area with a transparency is skipped by GeoConvert. With masks on everything is generated, but this does create more tiles for FS2 to read. According to another thread, mask tiles can cause other issues.


    There is some work being done with aligning AeroScenery selections with FS2 tile grids more closely.


    This problem also exists when generating scenery using the older method using FSET.

    Thanks, Chris

    Win 10 64-bit, 20GB RAM, i7-3820 @ 4.2, 4GB Nvidia GTX 970

    Edited 2 times, last by crispy136 ().

  • Hey Nick

    Hi qwerty42


    Thanks for the input. Funny you should post that because I revisited your spreadsheet last night and came to the same conclusion; I need to bring all the coordinates 0.01 degrees closer to the centre point of the square. I should have of course realised that simple rounding up or down doesn't work because this is lat / lon.


    I'm pleased you and another author have come to the same conclusion because I was concerned what else this would break, or whether that would mean in some cases that no tiles are generated.


    Also good to know that the origin of the spreadsheet maths is IPACS, so it's kind of as official as we'll get :)


    I tested it by manually altering TMC files with a few squares last night and it always worked.

    It seems like GeoConvert is more forgiving at snapping "outwards" to the nearest square boundary rather than snapping "inwards".


    I'll keep the existing calculation for drawing grid squares in the software, and use the "inwards" adjusted option for writing TMC files. That way the "on screen" grid squares will be contiguous.


    crispy136   moxeetwo Look out for version v0.5.1 coming before the weekend, maybe, hopefully. This bug should be fixed.