Menu
▾
▴
#2945 Hide or clarify "View > VR Options" menu item on 2024.1 release builds
On current 2024.1 release builds (ie. 2024.1-rc2), under the View Menu, there is a menu option called "VR Options" pertaining to the experimental VR support added to FlightGear, why is greyed out and un-clickable.
Presumably this is greyed out because VR support isn't enabled on release builds (i.e not compiled with osgXR). If that's the case, we probably shouldn't show the menu option at all - it's just going to confuse users and lead to a loop of people asking why VR is disabled or 'broken', and someone explaining that in reality its simply not enabled to begin with.
If "VR Options" is greyed out for another reason (i.e release builds are in fact compiled with osgXR support but there's some other reason why the option is greyed out, like a headset not being detected), there should be some feedback to the user to avoid confusion.
In either case, a rename to "VR Options (Experimental)" might go far enough to at least not give users the impression that 2024.1 now has production-ready VR support or anything.
As I understand it James (@amalon), you've been working on the VR support to FlightGear (a huge thank you by the way, it is an awesome idea), so I wanted to get your feedback on this as well.
Hi. Currently the menu option depends on /sim/vr/built (see ftdata:Nasal/gui.nas). This is similar to how various other options are disabled when unavailable. What platform are you using? VR should be enabled in linux and windows builds (I don't think OpenXR is a thing on Mac), though it does have a few build time dependencies. We bundle osgXR in with flightgear, so the main requirement that could be missing at build time is the OpenXR loader.
In the event that the OpenXR runtime isn't active or some other failure, the VR Options dialog displays an error when VR is enabled, e.g.:
VR State: disabled (attaching actions)
Failed to create OpenXR instance (-2)
(and that shows better error messages once the instance can be created, since it needs an instance to show the error codes as text).
As for the state of VR in this release. It should be usable, but its not a full VR experience. You can see the splash screen in VR, and the aircraft cockpit, but the GUI (including visual notification messages) can't be seen from VR, VR controllers can't currently be used (but I imagine many fg users will have joysticks etc, so that isn't necessarily a problem for some users), and lighting/shadows are a little weird (lights move with your headset orientation).
I have work in progress to improve this stuff (HDR and lighting fixes, hand tracking interaction with controls etc), but need to get back into getting it ready for next. I do have non-HDR fixes for lighting, but they're non-trivial, so possibly unsuitable for stable branch. Maybe once those changes are incorporated into next, the relevant commits can be backported.
In principle the CI builds for 2024.1 and next should have working VR, but I think we might be missing some SDK pieces which allow osgXR to build.
We can maybe consider enabling VR support on 2024.1 in a patch release, since yeah it does work but it's an experimental feature?
Whats the main concern with enabling it now? Managing user expectations? Known issues?
Yes, basically. If you say it's good enough to go out the door, we can do it.
Ubuntu 22.04 LTS + 2024.1.1 rc2.
This is the build output for flightgear/flightgear for the commit that I created the v2024.1.1-rc2 tag (and then the release) from. Looks like it can't find osgXR:
https://gitlab.com/flightgear/flightgear/-/jobs/8453467975#L86
Its the OpenXR loader that it can't find, I'm guessing it needs the libopenxr-loader1 or libopenxr-dev package installed.
Can you make a patch to add those to our Docker files, and I'll re-generate?
Also, what about WIndows?
I can look into that, sure. Presumably I need to start by figuring out how to build the docker thing in fgmeta on gitlab?
As for windows, I added openxr-loader to windows-3rd-party a while ago apparently. I don't believe there's any reason that version wouldn't work, though it may make sense to update it to a newer SDK if/when we start using newer OpenXR features later on. Picking a random build log:
https://gitlab.com/flightgear/flightgear/-/jobs/8514149856
It appears to have VR enabled, so unless anything has broken I'd hope it'd still work. Probably worth finding somebody with a VR headset & windows to give it a try.
I'll be doing some testing on Windows VR .. soonish. There's instructions in the DOckerfiels on how to rebuild them, but actually if you tell em the packages (and they exist on the correct base images), I can trivially rebuild them here, probably easier than you doing it.
Adding something like the following to the Dockerfile appears to get cmake to detect openxr. It appears that the openxr packages are in Monado's PPA:
https://launchpad.net/~monado-xr/+archive/ubuntu/monado
+RUN apt-get install --yes software-properties-common \
I haven't tried ubuntu in decades so I have no idea if there's a more official way to get OpenXR packages installed, or how it would interact with ubuntu systems without that PPA. Also not tested a build yet (nor do I really know whether openxr plays nice with appimage)...
OpenXR is available through the official Ubuntu repositories as
libopenxr-dev. After I installed it CMake picked it up and FG built with VR support. Unfortunately trying to setup a Quest 3 to work with Linux is a bit clunky so I can't speak to whether it works with the version of libopenxr provided by apt , but it certainly builds.Okay thats good to hear, when I tried with the docker image in fgmeta (based on ubuntu:focal), it couldn't be found until I added that PPA. @jmturner if you're happy to tweak the dockerfile however you see fit to get libopenxr-dev then I'm happy to test the resulting appimages (and ofc native builds) on Arch here with Valve Index to make sure they do work. I checked VR on the release branch (native build) not long after it was split and it seemed to work fine. Happy to tweak GUI if you still feel its necessary to manage expectations.
FYI A quick sanity check of VR on Linux can also be done without a headset using Monado, something like this to start monado:
QWERTY_ENABLE=1 XRT_DEBUG_GUI=1 monado-service
and either enable VR in GUI or with --enable-vr to see the splash in VR. Maybe set mirror to left_right to sanity check stereo rendering.
Then using WSAD in the monado debug window to move virtual headset and arrows to look around. Its not exactly like a real headset, but certain proves its not obviously broken.
Okay, for Jammy there's official openxr packages, unfortunately we need to use Focal for our AppImage builds until we switch from using 'linuxdeployqt' to 'linuxdeploy'. So I'll add the packages to our Jammy image, and use the PPA in our Focal Dockerfile.. please hold :)