Posts by qwerty42

    Hey Ian, this looks fantastic! Nice job, and glad you were able to figure out how to do it. It makes a huge difference in certain areas. One of the nice side-effects of this is that it also makes the satellite orthos look better, because they get properly stretched over the terrain shapes instead of being distorted over flat ground.

    For those with rudder pedals that have stiction that makes it hard to be precise, I really recommend getting some NyoGel 767a, cleaning the old lubricant off of them, and then using a light coating of this in its place. I have the Thrustmaster pedals and they were terrible before doing this...they would stick a little and then jump large distances when broken free. The nyogel is a damping grease and it prevents that large friction difference between static vs kinetic movement. It also creates a nicely damped resistance, not quite as good as a hydraulic linkage but still far superior to the stock 'feel' of the pedals. It works nicely in throttles too. It's probably a little too resistive for a short joystick, but it'd probably work great with a joystick converted to a long handle too.

    Edit: just be warned, this stuff is extremely sticky and is hard to get off of your fingers or fabric, so be very careful applying it...use gloves and some kind of applicator you can dab it on with, then cycle the controls many times to smooth it out. Start with a tiny amount and add more as doesn't take much.

    Yup. And if you do max out your memory, you will get MUCH better performance from geoconvert if your OS installation is on a fast SSD (preferably two two of them striped in raid) instead of an old spinning HDD because of that page file utilization.

    It sounds like you might have multiple controls mapped to your yaw for the helicopter. Unfortunately it's not obvious when this happens in AeroFly but it can happen. To fix it, click the axis assignment with your mouse (the same way you would if you were assigning a control axis to it) and then press the delete key on your keyboard. Do this several times, because if you have multiple inputs assigned to it, it will only delete one of them each time you do this. Then click on that axis one more time, and move the control you want to use to re-bind it.

    Thanks for the info. I haven't looked at this fully yet, but it's on my list before I release the next version.

    I'm either calculating the just the hex tile name wrong, or the hex tile name and the lat and lon wrong. I'll let you know what I find.

    Thanks, curious to know what you figure out. I won't deny the possibility that there's an error in my spreadsheet, since it's an ugly translation of programming code into spreadsheet logic, but I have previously converted some pretty huge areas from levels 9 thru 15 using it and FSET and never noticed any tile offset problems between the various levels. I've also compared the coordinates my spreadsheet calculates to the level 9 coordinates that GeoConvertHelper calculates, and they've agreed to 12 decimal places (if you account for the .1 degree inward offset that GeoConvertHelper automatically adds in). It's not a guarantee it's right, but if it's not then I'd suspect it may be an issue with the original code snip Rodeo posted...


    The hex numbers are derived from the lat and lon, so those also being incorrect makes sense.


    Hey Nick, I could be wrong and just taking a wild guess here, but if you're calculating the filename hex from the lat and lon decimal degrees values that might be the problem. The size of the tiles in terms of degrees latitude are not uniform as you get further north or further south of the equator. For example (assuming my spreadsheet is correct), a level 9 tile is ~0.70 deg 'tall' at the equator, but only ~0.11 deg 'tall' at the north pole. If you've assumed uniform spacing and are converting from degrees to hex from that, it might explain the issue...?

    If you did port all that code from my excel sheet (ugh!), and this really is the problem, you can get the grid coord numbers directly from rows 26 & 27 and rows 46 & 47 in that spreadsheet on the 'DONT_EDIT' tab. They are the number of the tile before it is converted into lat and long decimal degrees. Note that I split them into NW corner and SE corner (because of the area expansion feature I had in that spreadsheet) so you may need to offset them by 1 before converting to hex.

    Hi Michael,

    This is very likely due to masked tiles being present on the outer perimeter of your converted scenery. It's been explained many times buried in threads all over this forum, but still seems to cause confusion for many.

    To summarize: AeroFly's world is broken into square tiles. At different geonconvert levels (e.g. levels 9,10,11,12,13,14 &15) these tiles are a fixed size. The higher the level number, the smaller the tile in terms of geographic area.

    In order to geoconvert photo scenery into one of these tiles, you should have imagery that *completely* covers each tile. For the lower numbered tiles like level 9, that means having a very large area of photoscenery because the tiles themselves are very large.

    The reason you see issues at the boundaries is because: if you don't have complete imagery coverage for your biggest tiles before running geoconvert, AND if you have the option to use masks enabled, geonconvert will create a partial tile from your partial imagery, and a separate mask file that blocks out the area where you didn't have complete imagery.

    The problem with this is that the mask creates an area that will appear as a permanent gap between scenery if you try to add anything more around it. Because of this, myself and others started encouraging people to *not* use mask tiles at all unless they really understood what they were doing, and instead use a tool that calculates the boundaries of the AeroFly tiles so that complete areas could be converted without needing masks. This ensures that you never have problems with gaps in your scenery.

    Now thanks Nick and his AeroScenery tool, you don't really need to understand these things at all because his tool does what I described above automatically.

    If you want to fix your existing scenery without reconverting all of it, it can be done but requires a significant understanding of the tile structure. You need to go into the folder and find the .ttc files that have been masked. Ones that have been masked will have a corresponding mask file with the same name, except 'mask' will be appended to the filename. For every pair of tile and mask, you need to note the filename of each of these, and then delete the regular .ttc files and their corresponding masks. After that, you can reconvert just those tiles.

    I can't remember if this is necessary, but I think you need to go into settings on the Oculus software and enable the option 'allow unknown sources', since AFS2 isn't from the Oculus store. After the first time you get it to launch in VR mode, it should show up in your library within the Oculus software.

    Were you able to get the software to install successfully? If not, do you have an antivirus other than the built in Windows Defender? If so I'd try temporarily disabling it and running the installer again... might be blocking something or preventing the software from adding necessary firewall exceptions.

    I am currently doing some comparisons of what gives the best image quality in FS2. Looks like image download level 20 need never be used. And it could be we are using download images way too detailed for the various levels in FS2.

    Hi Chris,

    This is part of the reason why I posted those graphs of AeroFly tile resolution vs. latitude yesterday in this same thread. When we create orthoscenery in AeroFly, there are 2 values of spatial resolution that matter: the spatial resolution of your downloaded imagery (aka the 'zoom level' in Nick's tool), and the spatial resolution of the AeroFly tile level you're converting it to (even with a given tile level, this still varies a bit with the latitude of the tile--again, see those plots I posted).

    I'm curious what the actual source imagery resolution was in your experiments above. If there is something of a known size in one of your original downloaded images, you can figure this out yourself by seeing how many pixels it spans, and then divide the real size of the object by the number of pixels. Regardless of how you get to it, every downloaded image you've got has a certain characteristic meter per pixel (m/pixel) spatial resolution.

    If those plots I posted are correct (and I believe they are unless someone from IPACS pipes in and says otherwise), then at the equator a level 15 AeroFly tile has a spatial resolution of 0.6m/pixel, and at +/-45 degrees latitude it has a resolution of 0.42m/pixel. If your downloaded imagery that you converted was a lot better than that --say 0.25 m/pixel, then it's not surprising you saw no difference when compared to converted scenery that started with a lower 'zoom level' (again, zoom level is actually spatial resolution).

    To summarize: if you use downloaded imagery that is a lot better in spatial resolution than the corresponding spatial resolution of the AeroFly tiles you're converting it to, you are wasting your time and drive space.

    Lastly, there is one additional twist here. This twist applied to FSET and probably applies to Nick's tool as well: with certain imagery sources, when you get to the highest 'zoom levels', they don't actually increase in true resolved spatial resolution. They are literally just the same imagery that has been stretched over more pixels, which technically gives them a "better" spatial resolution (since the imagery has less real-world length per pixel), but in terms of actual resolved detail it's no better than the step before it. I know for sure this was true with the Google server imagery in a number of locations -- you could download all the way up to a level of -2 in FSET, and it used up a ton of space, but the actual detail present in the -2 images (which should have been 0.25m/pixel) was no better than the -1 images, because the -2 images were the exact same image as -1 but stretched over twice as many pixels. In other words: a bigger picture, but no more detail, and a lot more download time & size. This is something you have to be careful of when downloading near the maximum quality levels because even though you're getting a bigger picture, that bigger picture might not contain any more detail than the step below it.

    If we can beg/persuade/coerce Nick to consider including the feature I described above, here's one piece that will be needed. It's in Excel again (sorry!) but all the math should be easily ported to C I think. This calculator takes two coordinate pairs as inputs (note: the input coords need to be the corner coordinates of a single AeroFly tile!), and from those determines the required spatial resolution needed for downloaded imagery. The example coordinates I have in the file show that this particular level 14 tile has a minimum spatial resolution of 0.84 m/pixel, if every AeroFly tile is indeed 2048x2048 pixels (still need to confirm that, but I left it as a changeable input field so can easily be modified).

    Editing again so as not to spam Nick's thread with all my posts: here is the range of spatial resolutions for AeroFly tiles at levels 9-15 vs. the latitude of the tile, using that sheet to calculate them. I thought this was pretty interesting because I've never seen it given in an exact way before. Both plots show the same thing, but the second one is zoomed in more to see the range from 0 to 5 meters/pixel more clearly. (If I'm wrong about all of the AeroFly tiles being 2048 x 2048 resolution, then this is no longer correct! ;) )

    Here are the tabulated values from the plots if anyone is interested:

    Yep, exactly. And since Nick's tool makes the downloading so easy, I can see even more advanced scenery builders using this option too. You want a high res area for an airport? Tell it your minimum overfly altitude will be 0, and select your area. Then on its own, it would figure out it needed to go to level 15, determine that it also needed 0.25m/pixel imagery, do the downloading, and convert all the necessary tile levels. The way you answer the 'minimum overfly altitude?' question basically determines how detailed the area will be, both in terms of scenery images and tile levels, and the user doesn't have to think about it.

    The trickiest part of this is that it would have to make some assumptions about the areas it converted for the levels above your maximum detail level. For example, if the user only chose an area around an airport and told it that overfly altitude would be 0, then it would get all the necessary imagery at max resolution and convert all the level 15 tiles contained by that area. But to prevent scenery pop-ups, it would also need tiles 9-14. If you had it use masks, you could build all of these other levels for just that small area without downloading any more scenery (I think this is probably a bad idea, because of the issues you create if you have adjoining scenery with masks--unless the tool could find those also and scrub them from the directory with each successive scenery build). But maybe instead, after finishing the level 15 tiles, it could then figure out which level 14 tiles contain the small area, and download the level 14 surrounding area at the optimal resolution for level 14, and then repeat this by expanding the area up to level 9 with a larger download area at each one, but a lower imagery resolution too, which should still keep it speedy.

    In steps, with an example of a max detail area, it would look like this:

    (1) User inputs their minimum overfly altitude will be 0

    (2) Tool figures out which tile levels will be needed up to and including this overfly altitude. In this case, levels 9-15

    (3) Tool looks at user-defined area for scenery creation, calculates the necessary imagery resolution for level 15 tiles, and downloads the required area at that resolution

    (4) Level 15 area is geoconverted (or written into TMC for converting after)

    (5) Tool then determines which level 14 tiles include the chosen area, calculates the necessary imagery resolution for these level 14 tiles, and downloads the required area for the mininum set of level 14 tiles that include the originally chosen area

    (6) Level 14 area is geoconverted (or written into TMC for converting after)

    (7) This process repeats, finding all of the associated *complete* tiles that include the original user-defined area, downloading the imagery at the optimal resolution (to improve speed), and prepare it for geoconverting

    (8) Everything is then geoconverted

    If you wanted to add new high-detailed areas in the future, it could do this same thing. It would just need an additional check after determining the tiles it needed to see if they already exist in the scenery directory, and if so, it could skip converting them and move on to the next.

    I realize this is a lot of added complication in terms of coding, but... it's all do-able! One can dream, right?! ;)

    Another edit: if I knew C/C# better I would definitely love to help with this functionality :\ That 'Excel tool' I made already has a way to figure out the bounding coordinates of any level of a single geoconvert tile if you give it the coordinates of a point anywhere inside that tile. For the upward expansion through the scenery levels I described above, you could just use the coordinates of the 4 outside corners of the previously converted tiles, and use this same method as that Excel doc to get the boundaries of the next level up. For the example I described above, you'd most likely end up with a single level 9 tile, a single level 10, maybe 1-2 level 11's, and so on. This is more or less the same thing we already do manually when building scenery with varying detail levels, except having the tool do it all on its own would really speed up scenery creation for most users.

    I am not sure this is correct. Wouldn't it be easier for FS2 to display a large level 9 tile on its own, rather than it is for it to display the the multitude of level 9, 11, 12, 13, 14 and 15 tiles it has to pop in and out depending on your distance from the tile. Deciding when to use a level 12 tile in pace of a level 11 tile and so on must have some impact on performance. A level 15 tile area and level 9 tile area look much the same from FL350 so there is no benefit for areas where you don't come down low. The actual altitude at which the a level 15 tile area looks like a level 9 tile area is much lower than FL350. Also once IPACS create additional enhancements such as ATC, AI aircraft and live weather, scenery performance would become more important. Sigh, well I can dream can't I.

    Sorry, I should clarify what I meant by that. Yes, there is probably a performance impact by using levels 9-15 vs just 9-11, for example. (How much though, I'm not sure, it runs so well I've never noticed an issue even with a huge area of level 15 tiles.)

    What I was trying to say was that it's perfectly ok to use downloaded imagery of a very high resolution to create low-resolution tiles from: e.g. use 0.5m/pixel imagery to create level 9 tiles, even though level 9 tiles are *not* 0.5m/pixel, they're more like 16m/pixel IIRC.

    But the opposite is not true: you would not want to use 10m/pixel downloaded imagery to create level 15 tiles, for example. You just need your downloaded imagery to be at least as good as the spatial resolution of the tile level you're converting.

    EDIT: Taking this a step further, I think you could have an option to completely automate all of this with one question in the tool: "Minimum altitude you will be overflying this area?" With that input, you could figure out the range of tile levels that will be needed, and then given their coordinates, calculate what the spatial resolutions will be for those tiles, and then download the scenery at that zoom level. That would make it really simple for basic users and all of the confusion of zoom level, tile levels etc. can operate completely in the background.

    drhotwing1 (IPACS) : can you provide us the distances that tile levels 9-15 appear to the user in the sim? For example, level 9 is shown until we are X meters away, level 10 is shown between Y and Z meters, level 11 between Q and R meters, etc. If we had these numbers for each level, and automated Nick's tool as I suggested above, I think that would be really nice for, heck, everyone!

    The optimal "Download Resolution" (aka zoom level aka spatial resolution aka many other terms) could be determined pretty precisely by some extra lines of code.

    AFAIK, Each AeroFly tile is a constant fixed size in terms of pixels (I think it was 2048x2048?...) These pixels get stretched over larger and larger geographic areas as you go to a lower-number GeoConvert level. We can calculate the size of the area for any given tile with the lat/long coordinates, and then figure out what the GeoConvert resolution is by dividing that area by the pixel dimensions. This will give us a spatial resolution (e.g. X m/pixel).

    Once you have that, you know the optimal imagery download resolution (it just needs to be at least as good as the resolution it gets re-sampled at to create the AeroFly tiles). For example, if your calculated level 9 AeroFly tile over France is ~1.3m/pixel, then you want to download scenery that is at least as good as 1.3m/pixel also to convert that tile level, but not a whole let better to save on download time and file size.

    The reason we can't just easily provide a single spatial resolution for each GeoConvert Tile Level is that the spatial resolution changes with latitude. Since the tiles themselves are square and uniformly-sized, but are stretched over a flattened projection of the globe, the spatial resolution for any given tile size varies as you move north or south of the equator.

    But, this is where some clever coding could do this calculation for us. Based on the area being converted, you could determine the 'best' spatial resolution over that converted area and report it, which could then be matched to the download resolution (zoom level).

    Side note--in an ideal world where we had unlimited storage and infinite download speeds, we'd just download all of the imagery at max resolution and use it to convert every geoconvert level. The only reason we play the games above is to reduce download times and sizes for the base imagery over large areas. There is no penalty for using base imagery at better resolutions than the GeoConvert tiles we convert it into, other than the huge file size and download time.

    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.

    As a member of the IPACS team I promise to work harder at trying to relay as much information as I can to all of you. I will also try to be a little more forgiving here on the forum itself. We looked at this forum as a business marketing tool as well as a place for new users to come onto here to easily get their questions answered rather than a social hangout. This may not be the perfect approach so I'll begin to provide regulars with more freedom here in order to build a stronger core user base. But please understand that we can't allow for certain things like; acting negatively towards another forum member, posting direct links to downloads outside (like Dropbox) as this opens security holes into our domain, being too negatively opinionated towards one of our features upon release as this may shine negative light on potential new buyers.

    But please remember, it's not just the developer that can make a great game, it's also the strong community that backs it up and promotes it. So be a part of our little family and help us make the best flight simulator ever. It's what we all want after all, isn't it?

    Jeff, I think I probably speak for several others here when I say we appreciate this, and you talking openly to us about it. But while we're on this topic and addressing small changes-- part of the issue is that (unless I missed it) there are no forum rules posted anywhere. These things we aren't supposed to be doing are unknown to us. And then when we get our posts deleted or edited because of it, and no comment is left by the moderator as to why, we just sit here getting more annoyed and frustrated trying to understand what we did wrong or why we are being silenced.

    There are some very small changes you guys could make here that would improve things a lot, and I really don't think it's much to ask. 'admin' (I think that's Torsten?) shut down that thread I made really quickly, when all I was asking for was that when you edit our posts, instead of wiping them entirely, you edit what you need to and then leave a very short explanation as to why it was done. A few words would suffice, e.g. 'mod edit: external linking not allowed.' This would prevent a lot of negative feelings and misunderstandings, and I can't imagine it would take more than an extra few seconds to do. It also shows that our words have been edited by someone other than ourselves, which IMO is a standard of transparency for web forums which shouldn't even be up for debate.

    Also, I know you guys have mentioned before that you don't want to make a rigid set of forum rules, but frankly you need something. You can't expect us to follow them even we don't even know what they are. Regarding dropbox links, I had no idea that wasn't allowed until you stated it in your PM to me, and now again here. Plus, it's not even consistently enforced, because I have a post that has not been redacted with a link to my Excel tool to calculate AeroFly grid coordinates (here: Image tile coordinates). I have updated that link *numerous* times; surely one of you saw it by now, yet it's still there. There are some other posts of mine which also contain dropbox links that didn't get edited either.

    I completely understand that moderating these forums is a thankless, time-consuming, and frustrating job, and it has showed occasionally in your tone in some of your responses here. I get it; it would drive me nuts too. I don't envy you guys one bit for having to manage so much with so few people, and we do all really appreciate the good job you do here as well as with the sim. But, being resistant to our feedback about things that would help maintain some of the positive feelings and peace here isn't helping you or us. I had a good long thought about whether or not I wanted to keep helping and posting here at all over the last couple days, after how that whole thing with silently editing/deleting our posts was handled, and the reply that basically said 'This is how it is. Conversation over.'

    I definitely agree with you on that Michael. FSET is quite clunky in a lot of ways like you described. However, it is pretty solid in terms of all its internal routines that download and build the imagery, so my hope was that some of that code might be useful to developers of newer, better tools like Herve's.