Posts by qwerty42

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.

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

Quote from Cs12aad

Hi there, thank you both so much for your responses!

This is quite a difficult one to explain however the best way to describe it is that I can visualise every tiny movement. Even moving my headset within extremely small ranges the visual output feels a little excessive.

PC Specs:

RTX 3070 8GB

i7 9700k unlocked/ no OC

32GB RAM DDR4 @ 2666

All stored on a 1TB SSD.

I’ll explore the methods you have shared and get back to you with some results!

Many thanks.

Craig

Display More

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.

Quote from PjotR22

Not the fastest PC here, see signature, but Aerofly FS2 runs smooth with every scenery in high settings, shadows medium with the Quest 2 at 100% resolution in Open GL...

Yes, it works fine in OpenGL. Drivers newer than 446.14 (I think, off the top of my head) all have this problem with Quest2 + Link + Vulkan in AeroFly.

Quote from Micropig

Thanks for all the replies ,but as qwerty42 said I'm pretty sure it's a bug. In my case if I go back to older drivers it works fine but with the latest drivers even the menu is a mess.

100%. It definitely is. I don't know if it's Nvidia's bug, Oculus' bug, or IPACS' bug, but it's definitely a bug.

Folks, the specific problem that the OP is referring to is a bug. I really want to emphasize this. The behavior it exhibits is nothing like a lack of performance or settings too high. I've been using VR in general for 4 years, AeroFly& X-Plane for 3. I know what is normal and what isn't; I know how things behave when settings need to be dialed back. I've used DDU a zillion times; I've updated and downgraded drivers numerous times as well. Nvidia control panel settings don't have any effect on it.

When you load into the aircraft, and move your head back and forth, the view "sticks" to it, and drags around with your head movements in a stuttery, fragmented fashion. It's completely different than the kind of behavior that you see when things are choking from lack of CPU/GPU. As I said, it's as if the view is connected to you head by rubber bands, and as you move your head, instead of the view staying fixed in space, it drags along with your view in a slightly delayed fashion.

Unfortunately I think the only way it's gonna get fixed is if IPACS has a Quest 2 to test with, because as I said, I can't even screencap it. This behavior only shows up in the headset. The screencap I recorded looked totally normal. It only happens with Oculus Link, with the Vulkan option enabled, running the native Oculus build of AeroFly.

Quote from TomC RLG

If you want better VR performance with any sims get a dedicated PCVR headset with DP or HDMI. Expecting to get the same, or better results over usb3 is a bit unrealistic. Not exactly rocket science, lol!

Actually, if I match the render resolution (pixel dimensions) of my Quest 2 to what my CV1 was running at, performance and headroom is *very* similar (except for apps where some kind of buggy interaction exists with Link, which just so happens to be flight sims: X-Plane, MSFS, and AeroFly in Vulkan). Apples-to-apples there's not much difference between Quest2+Link vs. Rift, except that Quest2 can be *much* sharper and clearer if your hardware can drive it. It works well enough in other apps that I've stopped using my Rift CV1 altogether.

Quote from Micropig

Yeah this is exactly it although I get poor performance still when I launch it through SteamVR

Check the SteamVR settings for Render Resolution. There is a setting for it under "General" and then there is also a per-app override setting. In the General menu, make sure it's set to "Custom" and set it to 100%. In the per-app override for AeroFly, also make sure it's set to 100% there.

For me the SteamVR performance is not all that different than native Oculus running OpenGL, so if you're seeing problems there, the above could be the reason.

Regarding the topic that started this post though, the behavior in the Oculus runtime is definitely, without a doubt some kind of bug. It's not just 'poor performance,' it's 'world moving with your head movements to such an extent that it's unplayable.' I just tried making a screencap of this so everyone else could see, but unfortunately it only shows up in the headset, not on the mirrored desktop image. If anyone wants to reproduce it, though, I think all it takes is an Oculus Quest connected via Link, and then launching the sim via the Oculus build with Vulkan enabled.

Yeah, I know what you're referring to. It's something specific to Oculus Link (the USB wired connection that Quest and Quest 2 use). I mentioned it here in this post a while back: RE: ISSUE FIXED in Version 2.05.03.19 - Vulkan doesn't work with Oculus SDK in VR (black screen)

I don't see the issue in my old CV1 Rift, so it's definitely something specific to the USB Link connection for Quest devices. If you force the app to launch in SteamVR, it works fine. But if you launch the native Oculus runtime, *and* have Vulkan enabled, the view "sticks" to your head movements. It's almost like your head is connected to everything around you by a bunch of rubber bands, and any small movement of your head pulls the world with it, but at a slightly slower, stretched-out, stuttery rate.

If you revert to much older versions of the Nvidia driver (446.14 or older) the problem is lessened significantly, but it still doesn't go away completely. It's not a graphics demand problem -- even with low settings it still does it, and running via OpenGL works perfectly. It's just Vulkan. Link works fine in most other games, although there are some weird frame sync issues with it and X-Plane and MSFS.

FWIW my system is an i7 8700K CPU, 1080Ti GPU, SSD installation drive, 32GB x 4000MHz RAM.

Quote from whitav8

Jan or admin,

Is there a chance that you could help us new Quest2 users get back to the FS2 user menus - see the above from querty42 for details. Thanks for your effort. This new wireless VR concept that allows us to fly FS2 away from our keyboard or HOTAS is really amazing - from the comfort of my easy chair - and also staying in the family den (no local PC) for when socially distanced friends come over. Hopefully the code change isn't too significant.

Thanks

Dave W.

Display More

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.

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.

Yep, working well for me with my CV1 Rift now too. Thanks for the fix!!!

That said, there is some kind of weirdness with Vulkan using my Oculus Quest 2 and Oculus Link -- but I don't think this is AeroFly's fault. The latest versions of NVidia's drivers are having all kinds of frame drop and compatibility issues with some VR apps, and I think this is just another example of it.

So, if anyone is using Aerofly with Oculus Link and wants to run Vulkan now that this has been fixed, if you're seeing a bunch of frame drops or a weird effect where the view kind of 'sticks' to your head movements each time you move, roll back your NVidia driver to 446.14 and that should hopefully fix it. It did for me, at least.

There's a thread about this on NVidia's forums regarding the Index, but it seems to be affecting other VR devices too: https://www.nvidia.com/en-us/g…ed-frames-since-nvidia-d/

Quote from admin

We are currently investigating this issue. It probably hasn't anything to do with the settings inside Aerofly FS. It seems like it also happens with the latest NVIDIA drivers and not all customers are affected. We are still unable to reproduce the issue on our side, so we need to do some tests to see what the issue might be.

Let me know if you need any more help from users. I'm not a software dev but am quite computer-literate and can help dig into anything you'd like to troubleshoot. Thanks for trying to solve this!

Since you can't reproduce it, but it is affecting others, and I have it happening both with a CV1 Rift and a Quest 2, I wonder if it's some kind of hardware configuration thing. (e.g., attached monitor resolution; number of external monitors connected, or some other weird thing like that?)

I had another VR game about 2 years ago that used to work and suddenly stopped launching -- it also would go straight to a black screen. It was a game that only ran in SteamVR, but it turned out to be a conflict with the Oculus Dash virtual desktop panels, which were new at the time. Back then, if you had the option enabled to pull out and pin panels (so they'd stay up even when Dash was closed), Oculus created a second 'virtual monitor' in the system devices to do so. Turns out something about that and that specific game broke the game so that video wasn't rendered in the headset.

Anyway, that was a long time ago and not Vulkan/OpenGL related, but it has me thinking this might be a similar config issue. That game also only had some of its users affected, because the option to pin those panels was an 'experimental' feature and not everyone had enabled it.

Quote from TomSimMuc

This parameter does not switch the 2D screen off, but switches to two screens instead to one.

It also can be change via the UI.

In both cases the oculus stays black.

Yep, same. Using that option, I was able to either have windowed mode with the L/R eye VR view shown on the 2D monitor, or I could run 1920x1080 full-screen on the 2D monitor if I had the native view option chosen.

With the L/R eye VR view, it won't let me set it to anything other than windowed. If I choose a different option, it just immediately reverts to windowed.

In both cases, everything works and responds correctly on the 2D monitor. But everything in the headset is still black -- no image.

As YoLolo69 mentioned, the Oculus Dash overlay and virtual desktop display inside of Dash all work fine, too. You can open up the virtual desktop panel from Dash and see the sim on your 2D monitor in VR. It's just the direct 3D, virtual-reality projection of the sim into the headset which does not work, like it's getting no video stream.

I'm sure this is some very simple bug somewhere, which just isn't simple to find. Everything is working, with the single exception that the video stream isn't showing in the headset.

Quote from Jet-Pack (IPACS)

Quick question:

Are you running the application in window mode or in full screen mode? Does this change anything?

Did you experiment with different VR settings like resetting the render scale to 1.0?

I also tried all of these like YoLolo69. No combination of settings made any difference, and I tried them all. In the SteamVR build, it works fine. In the native Oculus build, you just get a black screen in headset. Both builds work totally fine on the 2D computer monitor, even with VR active. It seems to be entirely an issue of just getting the image to display in the headset when Vulkan is enabled.

I'm seeing exactly what YoLolo69 has described. I don't think it will help much, but here are logs after launching the sim with Vulkan mode active: main.mcf and logs.zip

FWIW, here are some other observations which may/may not matter:

• If I launch the sim from my Oculus library, it never runs the native Oculus build anymore (it used to, as I recall). Now if I launch it from Oculus Dash or the Oculus software, it always loads SteamVR first and then the SteamVR build.
  • TomSimMuc described this same thing above too. I don't have any command line switches in the launch options, nor any compatibility settings on the .exe. Nothing is modified that would have affected this.
  • The only way to launch the native Oculus build is to do it directly from Steam and choosing the Oculus version in the selection window that pops up, as TomSimMuc's picture above shows.
• When the Vulkan version of the app launches, it works fine in the SteamVR build. It's only broken for the native Oculus runtime.
• When you get the black screen in the headset with Vulkan enabled, *everything* works correctly on my 2D computer monitor. The image just isn't being displayed in the VR headset. Controls work, the sim works, the VR views will even load up on the desktop screen and respond to head movements. In fact, when you start your flight, you even get the little hourglass in the headset when it's loading the environment. But other than the loading hourglass, the headset only shows blackness.
• I'm using NVidia driver 446.14, but have tried newer ones as well. Same behavior.
• I also have an Oculus Quest 2. Using Oculus Link to connect it to my PC, it does the exact same thing as the Rift CV1 in Vulkan mode.
• I had Steam verify my file integrity, and I also temporarily renamed my entire Aerofly folder in "My Documents" so that it wouldn't be using any of my customizations. This made no difference whatsoever.
  
  I'm using a Core i7 8700K CPU and a Zotac 1080Ti GPU. I really doubt that matters, but just in case it's common between all of us with issues. Everything about the sim is working fine with Vulkan -- it's just not displaying in the headset. Weird.

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.

Quote from admin

Thank you all for your input here. We are a little puzzled. We just tested Aerofly FS with the Oculus Rift CV1 and the Oculus Rift S under Vulkan and OpenGL and it runs just fine. We just can't reproduce the issue on our side?!

Our test system has Windows 10, Nvidia driver 457.51 and a Geforce GTX 2060.

We have really no idea what is causing this problem.

If possible could you post a main.mcf configuration file here as well, maybe it's a setting within Aerofly FS that is causing issues?

Display More

This just reminded me... I think at one point I did discover that Vulkan started working again with a certain combination of graphics settings in the graphics quality options, which were less than maximums. If I have some time this evening I'll poke around and see if I can find it again, and post my log and main files.

Just chiming in here to say that I have seen the exact same thing for months with the Rift CV1, i7 8700K CPU, and 1080Ti graphics card. Does it with all recent versions of NVidia drivers as far as I'm aware. I haven't tried rolling back to older ones to fix it, but they'd have to be quite old given how long ago this first started happening on my system.

Like the OP said, it only affects the Oculus build. Game launches, shows up on 2D monitor with the message about being in VR mode, but inside the VR HMD everything is black. Switching over to the SteamVR build works fine in Vulkan. OpenGL works fine in both.

Also I should add, this might only be affecting the CV1 Rift. I think every post I've seen in this thread and previous ones with this issue, it's been the CV1, not the Rift S. So if the AeroFly devs are using the Rift S to say 'it works fine,' that's probably the problem.

I'm going to tell you something that will change your life: you need a taller desk. Just wait til you find out how much better everything you do sitting works!

Quote from Trespassers

As counter-intuitive as it may read, a very high resolution mesh for mountainous ground like the Alps may lead to poor results.

...

This was an awesome post! Great contribution and thanks for the time you spent making those example gifs!