Posts by qwerty42

  • congratulations!!!

    Quote from FlyAgi

    I'd like to join here. I was on the fence of stopping flight simming completely because of different situations I have with other simulators but AFS4 does it right for me exactly in the fields where others fail.


    • Clouds look great. They are crisp and beautiful and overall a joy to looak at. The so called volumetric clouds others offer did not impress me at all because they are blurry and don't look right, I think the computing power is just not there yet to make so called volumetric clouds look right which would require to render them in much higher resolution grids. So far, I prefer well done billboard clouds because they just look better.
    • Overall image quality is excellent, no blurry rendering at all, everything is crisp and clear and looks just right (obviously I don't like blurry stuff in any aspect)
    • High resolution ortho imagery looks stunning in this sim, other sims using the same or even higher resolution imagery don't render the imagery this good.
    • Helicopter flying is excellent, feels slightly better than in X-Plane for me.
    • Aircraft sounds are good, partially amazing (X-Plane's fmod just sounds dull to me, there is just no fidelity in the sounds and I tried a lot of aicraft there).
    • Performance is great.
    • Forests look great, billboard trees never looked so good in any simulator, the way how the engine handles the transparency is excellent (X-Plane is very weak in handling this kind of transparent textures, it can't really fade them out so you see hard edges).
    • The High Quality Antialias is phenomenal, removes flickering almost completely on my 1080p screen.


    :)

    I definitely agree with all the positives you listed. There are a number of things AeroFly does *extremely* well compared to the competition, especially in VR which is the only way I use flight sims. The crispness of visuals and whatever anti-aliasing magic they use is way ahead of the competition. I think that's one of the reasons I wish the sim was more fully-featured, though. It feels like it's right on the verge of being truly excellent, but it needs a few more things to get there, and I really want to see this sim reach its full potential.

  • Oculus Quest 2 for AFS2

    Quote from TomC RLG

    Windows Mixed Reality OpenXR does nothing with the Oculus Quest 2. That's only applicable to WMR headsets like the HP G2. with msfs2020. I agree that starting up in SteamVR mode is still the way to go if you want to use Vulkan rendering.

    This is correct.


    The Oculus OpenXR runtime files are already installed with the Oculus software, and AeroFly doesn’t even use OpenXR.


    As for the registry key, that is just a pointer to the Oculus OpenXR files too. Note that they’re in the same folder where the rest of the Oculus software is installed.


    You can create this registry key easily yourself by going to the Beta tab of the Oculus software and clicking the button that says to set Oculus as the OpenXR runtime. But again, this makes no difference for AeroFly because it doesn’t even use OpenXR.


    There really is nothing special you need to do to use AeroFly with the Quest 2, except be aware that Vulkan has a bug with the native Oculus build, so if you want to use the Vulkan renderer, launch it with SteamVR as the runtime.


    Lastly, the “fast” frame sync setting was a workaround for a bug that used to cause frame timing issues with Oculus Link and certain apps (XPlane and MSFS being two of them, but not AeroFly). It was finally fixed many months ago, and that setting no longer matters either, but it never mattered for AeroFly regardless.

  • VR head movement wobble ONLY with direct Oculus - SteamVR OK

    Quote from K9NSP

    Native Oculus is choppy, at best. Tethered, or wireless. It doesn't matter. In fact, the native wired experience is miserable in every app that I have tried.

    I do believe your experience for your own system, but this hasn’t been my experience nor many others. The built-in wired and wireless Oculus Link connections for Quest/Quest2 are now very stable and working well for most users and apps. Virtual Desktop is a good app, but it’s an extra $20 purchase that isn’t really necessary if people don’t want to buy it.


    To prevent straying into tangents, I just want to re-emphasize that this is some kind of bug specific to AeroFly FS2 when using Oculus Link/AirLink (wired or wireless):

    • It only happens with the Vulkan renderer and the native Oculus build
    • If you run the native Oculus build with OpenGL instead of Vulkan, it works well
    • If you run the SteamVR build instead of the native Oculus build, that also works well, even with the Vulkan renderer
    • The bug behavior happens identically with wireless AirLink and cabled USB Link
    • The bug is a very odd behavior in headtracking that causes the environment to move with your head movements, but at a slower rate, as if the world is connected to your view by rubber bands that are dragging the scene around with your head motion instead of staying fixed.
    • It only shows up inside the headset. I tried capturing it via the desktop mirror, but everything there is rendered perfectly smooth and fluid.

    For what it’s worth, the Quest 2 is now *by far* the most widely-used VR headset, not just for standalone use but also for PCVR. Since AeroFly runs with the Oculus runtime by default for the Quest, and because most people will want to use the latest and greatest Vulkan settings, this bug might be making a pretty bad impression on a lot of new users who have no idea what is causing it, or if it’s “normal.” If so, that’s a shame, because the incredible performance of AeroFly is one of its biggest selling points and is clearly something that IPACS have put a lot of effort into. This bug risks tarnishing that reputation, because new VR users seem to be frequently overwhelmed and impatient, and quick to dismiss apps if they don’t work well with default settings and minimal troubleshooting.

  • Video showing helicopter sling load in Aerofly

    Deleting posts, but more specifically, editing the wording of them without any indication that it had been done, is why I left a couple years ago. I only drop in now to report bugs. I don't think they realize just how annoying that actually is to users, *especially* ones that have donated a lot of their own time to make contributions to this sim like larrylynx.


    Add to that, the huge amount of enthusiasm people have had to volunteer countless hours of their time and efforts and try to make tools and aircraft to grow the sim, and the near lack of support from IPACS to do so (I know larrylynx in particular encountered this for a good long while with his heli and nearly stopped development on it altogether). It's just a shame. We've had people like nickhod who are professional coders, trying to build all sorts of cool tools for people to expand and customize the sim, and ultimately giving up and leaving because of roadblocks they hit that they got no dev support with. I'm not even referring to major feature requests; I'm talking very basic functionality tweaks of SDK tools that would have enabled his stuff to work better.


    When I first figured out how to use the geoconvert tool to refine terrain meshes, my post on how to do so was first deleted until I complained. I had to convince the forum admins to allow it, and agree to put a disclaimer about how it might break regions in the sim before they put it back up. It ended up being very popular with a lot of people using it, and building further on it to refine their own sceneries. It added a lot of value to the sim for many users, and like most of the user developments, we essentially had to reverse-engineer things to make it happen and work around unknown limitations and bugs in the SDK tools.


    I do respect people like Jet-Pack a lot. He's a good guy who does try to be helpful. It's just the closed-wall culture of this sim itself which has caused a lot of great people with huge enthusiasm to eventually have their excitement damped and move on to other things. Also, it's clear that dev focus is largely going into the mobile version and niche customers. I don't mind that -- I just wish things would be more straightforward about realistic expectations for future features and additions. I think it was 2017 when I first bought AeroFly FS2, and I can say firsthand that while they've added a few nice new aircraft and great VR support, many of the things that have been implied as "planned" aren't here yet. This is a sim best taken as what it is, right now, and consider any future additions as bonus gravy, because the future roadmap is uncertain to users and the dev team is too small to do things at a pace competing with other packages. I don't mean that negatively -- it's just a realistic statement of observation based on history.

  • Wireless VR with Quest 2 and Air Link

    Quote from qwerty42

    This is the same bug I've mentioned several times in this forum and tagged the devs. To repeat it again:

    • The Vulkan renderer is broken over Oculus Link (and AirLink) when running the native Oculus build. It causes massive head-tracking lag, making things extremely choppy and dragging the world around with your head movements.
    • If you change to OpenGL, it works fine.
    • If you force it to run through steamVR instead of the native Oculus runtime, it also works fine with both renderers.

    Just tested this again a few minutes ago to be sure, and yep -- still the same behavior, even with the latest AeroFly beta. Graphics driver version makes no difference.

  • Wireless VR with Quest 2 and Air Link

    This is the same bug I've mentioned several times in this forum and tagged the devs. To repeat it again:

    • The Vulkan renderer is broken over Oculus Link (and AirLink) when running the native Oculus build. It causes massive head-tracking lag, making things extremely choppy and dragging the world around with your head movements.
    • If you change to OpenGL, it works fine.
    • If you force it to run through steamVR instead of the native Oculus runtime, it also works fine with both renderers.

  • VR Responsiveness

    admin  Jet-Pack (IPACS) Hi, just want to bring to your attention that there is still a bug with Vulkan when using Oculus Quest devices with their pc-link cable. It's what the user in this thread was having an issue with, and it has been commented on in several other posts here with people not knowing what the real issue is.


    The effect is this: if you are running with Vulkan enabled, launched into the native Oculus VR build (*not* steamVR), then the rendered scene is VERY laggy with head movements. Any normal-speed head movements cause an effect where the world rendering is extremely delayed, and as a result the outside view gets dragged along with your head motion. Instead of the cockpit and scenery remaining fixed while you move your head, they move with your head at a variable rate.


    I tried to record this on the 2D mirror, but it only shows up in the headset. The mirrored desktop view looks completely normal.


    If you change back to openGL rendering, the issue goes away completely, and the app is its normal extremely-fluid performance at 90fps.


    I was one of the users who used to have the problem of the Vulkan Oculus build going straight to a black screen, until your update a few months ago fixed that issue. However I'm wondering if this is still somehow related.


    My system is a 1080Ti GPU, i7 8700k CPU, and MSI Z370 Gaming Pro Carbon AC motherboard. I wondered if this was an Nvidia driver bug with my older 1080Ti card, but the user above has an RTX3070, so it's affecting newer cards as well.

  • VR Responsiveness

    Quote from Cs12aad

    This solved the problem! Thank you very much - do we have an idea of when Vulkan will work with Q2 with Link?


    Many thanks!

    Glad that fixed it! I'm not sure if this bug is even on IPACS' radar. It only seems to affect Oculus Quest headsets running via Link. I've mentioned it in a couple of threads here now, but ultimately they're going to need to test it with an Oculus Quest headset too in order to replicate it and fix it.


    There's another thread about the same problem here: RE: Vulkan not working with Nvidia drivers 461.40

  • VR Responsiveness

    Do you have Vulkan enabled in the sim, or are you using OpenGL? If you're using Vulkan, try changing it to OpenGL and restart the sim. Let us know if it improves things. There is a bug with Quest2 + Link when running Vulkan in AeroFly which makes head movements very ...weird.

  • FS2 and Wireless Oculus Quest2 VR

    Sorry! I just checked this and it turns out it works totally fine. When AeroFly is running in the SteamVR runtime, it maps the back button to a click of the left thumbstick inward, rather than the Oculus menu button on that controller. So, there's no conflict--you can access the AeroFly menus with the stick-click; you can access the steamVR menu with a quick click of the menu button; and you can access the Virtual Desktop menus with a long-press of the menu button.

  • FS2 and Wireless Oculus Quest2 VR

    Quote from whitav8

    1) With wireless Virtual Desktop ( and not near the PC ) how do you assign a Quest2 controller button to the key "ESC" so you can get to the setting pages?

    2) Is there any future ability to get ASW / Motion Reprojection for wireless VD

    3) If you use the Link Cable, can you get some ASW?

    Hi there,

    (1) If you mean the button that lets you get back to the AeroFly menu screens... yeah, that's a little weird with wireless and VD, for a few reasons. First, since VD has to run AeroFly in SteamVR, the left menu button on the controllers becomes SteamVR's menu button. Second, VD also uses that same button to access the VD menu and environment, via a long-press. Third, AeroFly uses that SAME button to access its menus, also via a long-press. I think you can see the issue here, lol. I use a HOTAS almost always so I haven't bothered to see if it can be fixed, but if AeroFly lets you remap that button to one of the others on the left controller it'd work just fine.


    (2) I hope so, but I don't know. The VD dev is a really smart guy, so hopefully he'll figure out how to make it happen someday, but as it stands his streamer/capture system doesn't have any way to access the lower level ASW and motion smoothing funcionality. Apparently they operate on some layer that is related to rendering the image in the hardware that his code can't grab, yet. If he can get it working, I'm not sure I'd ever bother plugging the link cable in again, because other than that drawback it's just as good or better than Link, IMO. Even the motion-to-photon latency is lower with VD than the wired Link cable, which is hard to believe but it's true.


    (3) Yep, if you use the Link cable, you get all the same functionality as a hard-wired Rift or Rift S. There's a drawback, though -- the compression to run Link eats up a significant amount of GPU overhead, compared to a Rift or Rift S. So to get visuals as good or better than the old headsets, it takes a fair bit more processing power. With everything running at maximums though, it does look quite good, and is a definite improvement in most ways vs. my CV1 Rift.

  • FS2 and Wireless Oculus Quest2 VR

    Yes, it works very well, but just a few things for others to know:


    (1) Only the SteamVR build will run through Virtual Desktop wirelessly. The native Oculus build doesn't appear in the headset, even if you force it to launch. Not a big deal, still works just fine, just something to be aware of.


    (2) Wireless VR through Virtual Desktop does not support Oculus ASW or SteamVR's motion smoothing, so you will want to make sure you've got AeroFly's graphics settings configured so that you can hold a stable 90fps (or whichever framerate you've selected in Virtual desktop's options -- you can choose 72 or 80Hz too. Just make sure your system can comfortably hold the chosen framerate or things will get choppy.)


    Other than those two minor things, it works very well. Visuals through Virtual Desktop over wireless are great--very crisp. Also I'm getting ~30-35ms latency on my setup which is on-par with a hardwired Rift S. Compared to the Oculus Link cabled solution for Quest1/2, somehow Virtual Desktop manages better visual quality for a given amount of processing overhead. Link works fine too, but it uses more system resources to get an image on-par with what Virtual Desktop delivers. I know that sounds crazy but it's true, at least for now.

  • Ortho creation issues (Geoconvert extremely slow) [SOLVED]

    Another thought: I don't know if this is true of the most recent geoconvert version, but in the past, if you're converting large areas, having a computer with an SSD vs. a HDD can make a huge difference too. When I was converting a large area in the past, geoconvert used up all my system RAM and started writing to disk for everything else it needed. My PC was hung for 12 hours, making almost no progress. I re-started the process on a laptop with a slower processor, same amount of RAM, but with a very fast SSD, and the whole thing was done in a few hours.

  • Creating terrain heightmaps

    Quote from flightxtreme

    "Also, here are the detailed values of that resolution limit, for each level and varying with latitude, in meters per pixel: resolution vs level vs latitude link"


    Thank you @querty42 . I was always a bit curious about people giving the meter per pixel value without the latitude in mind. The consequence is also, in a 2024x2024 tile the lat resolution is different to the lon resolution. :)

    Yep, that's correct! In those plots and the table at that link, the numbers I've shown are the most detailed resolutions for the entire tile, meaning the lowest value in units of meters/pixel for each. This takes into account the different lat and lon resolutions in a given tile. I presented it that way because it lets you know what imagery resolution you need in order to fully take advantage of a certain AeroFly level.

  • Creating terrain heightmaps

    Quote from ozhomeroz

    So making meshs for levels higher than level 11 is kind of redundant.

    Please anyone correct me if Im wrong in this assumption

    It's only useful to convert beyond level 11 if your starting mesh data is higher in resolution than an AeroFly level 11 tile.


    In AeroFly & geoconvert, the 'levels' are really resolution levels. As you get closer to the ground, you need a higher resolution (level) to keep things looking good. As you get closer to the terrain, you'll see level 9 data, then level 10 data, then level 11 data and so on. If you're right on the ground or very close to it, you'll see level 15 data, assuming you actually have level 15 tiles converted.


    Each 'level' in AeroFly has a certain resolution associated with it (this resolution actually varies a bit with latitude because of how the tiles are mapped to the spherical Earth). Your downloaded geotiff source data also has a certain resolution. If your source data isn't at least as high in resolution as the AeroFly level you're converting to, then it is indeed a waste of time because it won't gain you anything by converting it. It's like zooming in further on a photo when you're already seeing the individual pixels in it. It will still convert just fine, it's just that each successive level beyond the resolution maximum of your source geotiff won't have any more detail than the one before it. Hope that makes sense.


    Also, here are the detailed values of that resolution limit, for each level and varying with latitude, in meters per pixel: resolution vs level vs latitude link