Varjo Aero HMD does not work with Lumen + Solution + Please fix this asap

While there are lots of HMDs that do show Lumen (when activated of course), the Varjo Aero, which I use, never worked, what is really annoying. Even 5.2 preview does not work atm. I asked the Varjo support for what that could be and they showed me a single line of code that has to be changed in the UE to get it working. They also contacted Epic to communicate that problem, but guess what? Nothing changed so far. Since then I use UE source to be able to change that line by myself. Now I got a piece of hardware that does work with UE ‘standard’ but not with UE ‘from source’ version (bad plugin design I guess). Of course the functionality of that thing is not your concern, but for that reason I am now forced to return to UE standard, or leave the hardware unused.
The line of code that I change in each new version is located in the OpenXRHMD.cpp:

static TSet<XrViewConfigurationType> SupportedViewConfigurations{ XR_VIEW_CONFIGURATION_TYPE_PRIMARY_STEREO, XR_VIEW_CONFIGURATION_TYPE_PRIMARY_QUAD_VARJO };

Removing XR_VIEW_CONFIGURATION_TYPE_PRIMARY_QUAD_VARJO does the trick in my case. Maybe removing this is not the (entire) solution needed to get UE working for the whole Varjo spectrum, but take this as a starting point. Please fix this issue asap, the amount of time I have to spend each new version + tracking plugin compatibility issues between ‘standard’ and ‘from source’ are driving me nuts.

3 Likes

We added a console variable to 5.3 that allow you to disable it (GitHub CL).

xr.OpenXRPreferredViewConfiguration

If you set it to “2” it will force all runtimes to use Stereo.

1 Like

Awesome! :+1:

For those who struggle with this like I did and do not want to wait until 5.3: Today I found a workaround that enables me to use the UE standard version again, no need to use UE source anymore and the related plugin incompatibilities are history. I don’t know if I’m allowed to paste a link to that git repo here and I have no time to read the board rules, so simply search the web for ‘OpenXR InstanceExtensionsWrapper’, it’s a little wrapper done by mbucchia, creator of the OpenXR-Toolkit, for Varjo devices, which disables quadview directly in the OpenXR runtime of the Varjo installation. First tests look quite promising.

As I said, that’s just a workaround, I prefer the UE solution that will come with 5.3 later.

Nice find.

There are no issues with posting links to GitHub on the Forums, share away!

hi,VictorLerp
this command is able to use ? when runtime(.exePackage)

some news for this console command in Shipping eXE PACKAGE ? i really need this to work

HeHi VictorLerp, I have the same problem. When i start my project in editor it works fine but when i package my project no Lumen ect. works. If i start the package project eith the G2 Reverb for example it works with all graphical features like in the editor. But with the Varjo it doesnt. It is so frustrating. I need help really… I work for a big Automotive company and we need this to work! Thanks in Advance

follow the steps describe in the first post with github repo , it is working well

1 Like

Thank you! I got it to work. But now i have another problem and i can´t seem to find a solution online. The scalability settings which i used for the Project work fine in Editor but are finetuned like that. When i create a packaged build it uses epic on everything and the performance is not finetuned anymore. How can i have the same settings which i use in editor like in package build? I saw a suggestion to set everything in an DefaultScalability.ini in the projects config folder. But my packaged project won´t use it at all. To create a Packaged buidl i have to start the editor as my admin user otherwise i can´t create a build. Is this whats causing the Problem? Isn´t there a setting or something to just create a build with the exact same settings i used in the editor? I really need it to be the same because i finetuned everything to make it even work in the first place. thanks in advance

Is it possible to change this CVAR on runtime?
It seems like this is not the case, even when restarting the level, while assuming that the CVAR value is saved, a change of the CVAR does not come into effect without closing the VR preview entirely