OpenXR VR Template | Feedback and Discussion

Development Platform & Builds XR Development
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
128

I only noted settings that was different in your DefaultEngine.ini, compared to a newly created VR Template. So the settings that you’re not aware of (such as bDomStorage, r.Mobile.FloatPrecisionMode=2, etc) are settings that are different in your project from a default one. I’m not sure if you manually changed those, or if they were left over from an old project, but they don’t exist in the default UE5 VR Template.

129

Some of those are definitely UE5 settings and can be enabled/disabled from the project settings, like r.Mobile.FloatPrecisionMode (UE4 simply didn’t have that at all in the Project Settings)

130

Sure, but what I’m clarifying here is that you added them to the .ini. They’re not in the VR Template Project’s DefaultEngine.ini by default.

131

Oh, ok. Fair 'nuff.

132

Keep running into this error trying to preview my scene through steam vr onto my Index:
Assertion failed: Mesh.IsValid() [File:D:\build++UE5\Sync\Engine\Plugins\Runtime\Steam\SteamVR\Source\SteamVR\Private\SteamVRRender.cpp] [Line: 76]

Also, does anyone know of a good current from scratch vr integration tutorial? So many recent tuts are already out of date.

133

That seems to indicate that the SteamVR plugin is failing to generate the hidden area mesh. The SteamVR plugin doesn’t seem to be maintained anymore, and there might be changes to procedural mesh generation in UE5 that break it.

The best option would likely be to switch to OpenXR, since that is actively supported by Epic. Otherwise you would either have debug and fix the mesh generation, or disable the feature with the
vr.HiddenAreaMask 0 command (this will cause the entire screen outside of the visible area to render).

134

I’ll try those suggestions. I wasn’t aware that the steam VR plugin wasn’t supported anymore.

135

hi, Its a Nope at the moment for me, i cannot pin down where the behavior from the vr camera starts to wooble, when i open a new clean vr project it works fine, but if i try to include some new functions like half life alyx hands, using some youtube tutorials, it will start to fail, when using vr blueprints from previous versions (especially where the controllers are attached afterwards to the vr pawn, works normal) its the new xr that im guessing, not using every tick update in the vrpawn blueprint when gets the thing wrong, but i don´t now for sure. A specific moment when the camera starts to wooble happens when the vrPawn blueprint is changed in class from actor to character. im still in 4.27 for clarification i wil try with 5.

136

Just to confirm indeed it works well in unreal 5, movement in pawn also changing the type class the hmd its stable, but its not the same case on 4.27 the hmd always starts to wooble.

137

Thanks!

138

I hope it gets improved soon but until a few days ago - still the same problem in last weeks main build (github). 35fps in UE5 vs smooth 72 fps in 4.27. :confused:

139

@VictorLerp
5.0.2 issue ??

PIE VR Preview, then take off your headset (I’m using Quest2), then put HMD back on, the game will freeze and the editor will crash rather than continuing tracking, as it did prior to patch…

I noticed this in my own project and then did a build of the template to see if it also happens. It does.

Crash Log Summary:
Assertion failed: PipelineState.FrameState.predictedDisplayTime [File:D:\build++UE5\Sync\Engine\Plugins\Runtime\OpenXR\Source\OpenXRHMD\Private\OpenXRHMD.cpp] [Line: 1950]
UnrealEditor_OpenXRHMD
UnrealEditor_Engine
UnrealEditor_UnrealEd
UnrealEditor
kernel32
ntdll

140

Nice.
I am trying to use my Quest2 for the first time with Unreal Engine, and I don’t even know where to start, searched for a couple hours now on how to PIE to no avail.
There’s a page on docs about v.4.26 that shows a button to run in VR, which is missing in 5.0, and I’m completely stuck.
Anyway, could you enlighten me on how to PIE VR?