OpenXR VR Template | Feedback and Discussion

Unreal Engine Platform & Builds XR Development
#108

Install KDiff and diff it :wink:

1 Like
#109

So to stop DX12 crashes in the VR Template solution for now is DX11 and wait for hotfix ?

1 Like
#110

Has the DX12 problem been resolved with 5.0.1?

#111

No but the fix has been submitted to the repo and will be shipped in 5.0.2.

4 Likes
#112

Any word on performance improvements for Quest 2 ? UE5 project converted from 4.27.2 runs on Quest 2 at less than half fps than the original one (solid 72 fps for UE4 vs spotty 24 fps for UE5.0 ) :frowning:

#113

Hey Victor any idea if/when the new features UE5 has shown off will render correctly in stereo for vr? We’re grateful for your work on the vr template but it’s disappointing how vr seems to be neglected for so long when it comes to new features and engine improvements.

#114

New features like Nanite/Lumen ? I doubt that as those requires deferred renderer and computational power to run well (although still below required for VR fps)

Does Niagara work for you in 4.27.2 in VR (both PC VR and Quest 2)?

#115

Check the thread i linked. As far as im aware it’s not working, though i haven’t tested recently all features listed there. This has gone on for years now since niagara was first introduced.

Im sure epic could fix many things if they wanted and honestly basic stuff like water, clouds and niagara should have been by now. Just because vr has some performance issues doesn’t make it a reasonable excuse for not at least rendering correctly in vr.

The deferred renderer has many features you might want in vr projects and there are ways of getting enough performance out of it like nvidia dlss for example. Though i would be curious to try epics own upscaler and see how it compares, presuming it works of course…

1 Like
#116

PC VR isn’t where money is and while it’s possible to get deferred running well in PC VR, it will require more beefy hardware than many people have. As for mobile VR (which is where money is and will be), forget about deferred rendering on that hardware.

1 Like
#117

Niagara and Volumetric clouds both work in Stereo as of 4.27 and haven’t regressed in 5. I responded in more detail on that thread, but if you can reproduce it please provide the steps for us to do so.

Lumen and Nanite are a different beast entirely, and while we’re working on making them functional in Stereo, to hit 90 fps on the average gaming PC, let alone mobile which doesn’t have the hardware to support it yet, will take some time.

3 Likes
#118

Thanks Victor that’s great to hear. I didn’t see any mention but i guess everyone kind of doubted any improvement after so long. The last time i checked anything was just lumen and nanite in 5ea. I think niagara getting fixed is a good sign epic do still care about vr even if it’s low on the list.

While lumen and nanite would be great to see as well it was mainly the features you’d most expect to work i was hoping for like niagara, water, clouds and virtual building tools.

#119

I am not sure if it’s OpenXR issue or Oculus issue, but I figured I’d ask here since Oculus is no rush to look into this: UE4 OpenXR capacitive touch input issues (bug repo... - Oculus Community - 958598

By chance, would you happen to know @VictorLerp ? It’s the same in UE5 I believe.

#120

I’m getting freezing in VR Template (4.27) after running the project in VR Preview mode a few times. The freeze happens after exiting the project the third of forth time. The editor then becomes completely unresponsive and I have to quit out using the task manager.

My VR setup is Windows Mixed Reality (Lenovo Explorer). Am testing just the default VR Template.

Wondering if anyone else is experiencing same?

#121

Any update on Enhanced Input for VR?

As I understand, it works but standard input mappings must also be added in addition to the Enhanced Input system for input to be properly registered. Is this still the case (appears to be on my end with 5.0.1) and is this going to change anytime soon?

**Thanks Enhanced Input and Motion Controllers - #7 by VictorLerp

#122

Re: Default Input Mappings

Currently, Oculus Touch (R) A Press is a default axis mapping under the MovementAxisRight_Y group

While nice to know that an axis input can trigger a button action, it’s not an intuitive place to look when your A button is being fired every time you move your Thumbstick. I’ve sunk over an hour into debugging an issue, only to find it’s this default input setting.

For the sake of others, you might want to remove this from the default template.

@VictorLerp

#123

I would love for the VR template to automatically have Smooth Locomotion/Turning like EVERY VR game out there. If not as default then to have a menu option on preview to turn it on.

Oh and HANDS.

1 Like
#124

I already submitted that change! Shipping with 5.0.2. It was meant to demonstrate that you can use binary inputs for axis mappings, but it’s causing issues with other OpenXR bindings. This will be addressed with Enhanced Input, which will also solve the current issue with using Vive Trackpad Up/Down/Left/Right input as Axis mappings. They now work w. OpenXR in SteamVR, but you currently have to assign one of them to a “dummy”-Action Mapping for them to work when assigned to an Axis Mapping… not very intuitive.

1 Like
#125

The old non OpenXR cap-touch actions are still around. I haven’t had time to verify which ones work and which ones doesn’t, but know that there’s a set of old inputs (OVR), and a set of new (OpenXR).

1 Like
#126

I’ve compared your .ini to the default one and I’ve listed your changes, reasonings for keeping or changing them, but also linked information about them for those of you who are interested in learning about what these settings do:

r.Mobile.DisableVertexFog=false (default = True)

  • Performance optimization. If fog is used, an error message will let the user know that it’s disabled.

r.NormalMapsForStaticLighting=true (default = False)

  • Situational, user should be aware before opting in.

r.EarlyZPass=2 (default = 3)
r.EarlyZPassOnlyMaterialMasking=True (default = False)

  • Useful in scenes with heavy foliage, situational.

bDefaultParticleCutouts=True (default = false)

  • Can reduce overdraw cost. However, user should be aware before opting in.
  • More information

vr.RoundRobinOcclusion=True (default = false)

  • Can lead to meshes being culled in the periphery, and only provides a noticeable performance boost if the scene is draw call bound. User should be aware before opting in.

r.Mobile.EnableMovableSpotlights=True (default = false)
r.Mobile.EnableMovableSpotlightsShadow=True (default = false)

  • Adds shader permutations, and as such, cost. Situational, user should be aware before opting in.

vr.VRS.HMDFixedFoveationLevel=2
vr.VRS.HMDFixedFoveationDynamic=True

  • Experimental. We don’t enable experimental features in templates, but worth testing in your own projects.
  • More information

bForceCompressNativeLibs=False
bEnableAdvancedBinaryCompression=False

  • Not sure why you’d want these disabled? From docs: “In addition to reducing binary size, these can make your code slightly more efficient.”

bBuildForArm64=True (default = false)

  • This was a fun one. It’s actually enabled in the project that is the reference project for the VR Template, but when you create a new VR Template, the setting didn’t apply! I managed to fix it for 5.0.2 but we’ll never know why it was broken in the first place…

r.Mobile.FloatPrecisionMode=2
RedChromaticityCoordinate=(X=0.708000,Y=0.292000)
GreenChromaticityCoordinate=(X=0.170000,Y=0.797000)
BlueChromaticityCoordinate=(X=0.131000,Y=0.046000)
WhiteChromaticityCoordinate=(X=0.312700,Y=0.329000)
WorkingColorSpaceChoice=Rec2020
r.Mobile.SupportsGen4TAA=False

  • Not sure about these, can you elaborate?

bMultiTargetFormat_ETC2=False
bMultiTargetFormat_DXT=False

  • These can indeed be false to save shader compilation time

bEnableDomStorage

  • I found some information about it, but what do you use it for?

OculusVR Plugin specific settings

More information: https://developer.oculus.com/documentation/unreal/unreal-plugin-settings/

Uncertain whether any or all of these work w. OpenXR yet:

ColorSpace=Rec_2020 (default = Rift CV1)

  • This should indeed default to Rec_2020 as Quest 2 is in majority of Oculus devices in the world, and Rec_2020 is the recommended color space to master your . However, I’m not sure if the setting is supported by Oculus’ OpenXR extension yet. More information about the setting can be found here: https://developer.oculus.com/documentation/unreal/unreal-color-functions/

CPULevel=3 (default = 2)

bLateLatching=True

bPhaseSync=True

3 Likes
#127

@VictorLerp Great breakdown, thanks! Going to comment on some of these (since I dev for Quest 2 everything is here based on tests on Quest 2 and correspondence with Meta’s UE mobile VR engineer).

Foliage is a real performance killer on Quest 2 due to how UE handles transparency on mobile (just a guess, since Unity performs a ton better with transparency), so these settings is mostly if one has masked materials in the project, not necessarily foliage.

This is odd, because from what I understand Round Robin Occlusion were specifically implemented for VR :slightly_frowning_face:

I am guessing it’s experimental because it’s VRS and not Oculus/Meta’s implementation of FFR (specific to Q2), correct ?

I really have no idea about those. It’s something new for UE5 (I don’t recall seeing those in UE4’s .ini) I don’t even know where those settings are in the Project Settings :frowning: I’ll enable it for sure.

Those are generated by UE5 - I have not seen those in UE4. Worth noting that Rec2020 is color space of Quest 2.

Also generated by UE5 - I’ve never seen this setting and have no idea what it’s for.

These are actually recommended by Oculus/Meta for Quest 2. Perhaps not suitable for generic VR Template.

1 Like