Posts by qwerty42

  • Missing Tiles in Photo Scenery

    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.

  • Ordered the Ocolus Rift

    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.

  • Ordered the Ocolus Rift

    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.

  • AeroScenery Beta - Help With Testing Required

    Quote from crispy136

    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.

  • AeroScenery Beta - Help With Testing Required

    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:

  • AeroScenery Beta - Help With Testing Required

    Quote from Trespassers

    I agree with you qwerty42 on this.

    And once again, after lengthy download and processing, you may want to first geoconvert levels 9 and 11 only to inspect and check that everything is ok before to launch geoconverting up to levels 14 or 15.

    By the way the levels system is quite similar to the mipmap system in FS. The graphic engine is just faster. If you move fast on a scenery with the dev cam you see blurries getting sharp exactly like in FS...

    Cheers

    Antoine

    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.

  • AeroScenery Beta - Help With Testing Required

    Quote from crispy136

    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!

  • AeroScenery Beta - Help With Testing Required

    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.

  • AeroScenery Beta - Help With Testing Required

    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.

  • Quick Progress Report

    Quote from drhotwing1

    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.'

  • Help for a Geoconvert beginner

    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.

  • Comment or notification on posts silently edited or deleted by mods

    Quote from J van E

    That's not so. Last week a new topic of mine was removed (again), including at least one reply, and there was no notification, no personal message, no trace, no nothing. It was simply gone.

    In that case I retract my attempt to be more fair... maybe they can ninja-edit a redaction into my post above for me :D In all seriousness though, I understand it's a company tool and promotional forum for them. And in general I think it's moderated well by a small team that already has better things to be doing. But, it's also by far the most active and best resource right now for this sim and any user development happening around it. Few things can sour an online community faster than iron-fist modding or not being transparent about it, and this one needs to thrive until other alternatives grow big enough to be useful. I don't think transparency via mod-comments on any deleted or edited posts is too much to ask, and every other good forum out there does this already.

  • Comment or notification on posts silently edited or deleted by mods

    To revise my post above and be more fair: I think there are visible notifications given when an entire thread or a post within the thread has been deleted. However, I don't recall ever seeing anything on those indicating why it was done, when done by a mod. Showing something was removed is good, but it sure would be nice if a few seconds were taken to at least say why it was done with a short comment line.

    However, when posts are ninja-edited by mods, it shows nothing... except that the post has been locked for further editing by you if you were the original author.

  • Sad day today

    I couldn't bring myself to click a 'thumbs-up' on a post like this, so I'll just say: I'm so sorry for the pilot, crew, passengers, and their friends and families; and also that you had to witness such a tragic and emotionally devastating event. Fortunately I've never been witness to something like this, but my heart goes out to you all who have.

  • Comment or notification on posts silently edited or deleted by mods

    I'm sorry to bring negativity in here, and maybe I just get overreactive with these kinds of things, but can the mods here please consider making it a policy to at least add a comment line or notification when they go editing or deleting users' posts? I have had several of my posts silently edited by mods, or outright deleted, and when my words are redacted with no notification to me or reason given for why it was done, it's honestly pretty irritating. One of these was the thread on creating terrain heightmaps which clearly turned out to be quite popular. The most recent case was a Dropbox link I gave out with the FSET source code to help the crew who is working on new tools for scenery geoconversion, which also got ninja-edited.

    If I had at least been notified or knew who the mod was that did this, then I could ask them why they edited the post, and I'd probably find out they thought I was giving out something I wasn't supposed to--in which case I could explain that the code was given freely and unconditionally by the original author for this very purpose. But since posts get edited here and nothing even shows it was done, I can't do anything about it.

    Also, there is something that really bothers me on a visceral level about having a post with my name on it, with my words, and then having those words partially deleted or changed, again without so much as a note on the post visible to other users that it was edited by a mod.

    I understand having rules in place and wanting to keep certain things out of your forums, but silent ninja-edits to our posts or outright deletions without any indication that it has happened starts to feel like blatant censorship. At the very least, this forum should have a visible notice that appears on posts that have been mod-edited like pretty much every other forum on the web.

  • Help for a Geoconvert beginner

    Well, I posted a link to it here earlier and it looks like it got silently mod-nuked. This is the third or fourth time I've had posts wiped like this with no notification or explanation and it's really starting to grate my gears, honestly. They did the same thing with my post on how to create terrain heightmaps and I had to plead to have it restored.

  • Help for a Geoconvert beginner

    nickhod If it would help, I have the source code for the first version of FSET. It was posted on the web a long time ago when the developer abandoned it. Somebody else fixed some bugs with it later on and released a couple more versions, but I don't have the source for those updates unfortunately. You might be able to re-use pieces of it to manage the imagery downloads: