X-Wing Alliance VR mod

Here you can find help for how to best run and setup your XWA VR experience.
Post Reply

Re: X-Wing Alliance VR mod

User avatar
blue_max
XWAU Member
Posts: 1801
Joined: Wed Mar 20, 2019 5:12 am

Post by blue_max » Sat May 15, 2021 3:37 am

What desktop resolution are you using in SteamVR, BatSpoggy? What is your per-eye resolution? Are you running SteamVR on its own before running XWA?

What's your performance when you run without SteamVR?

Your headset should be set at 90Hz or more. I recall that some people have reported bad performance when the *monitor's* refresh rate is above 60Hz, so try setting it to 60Hz if that's the case.

There's one more thing we can try to troubleshoot this. Open your VRParams.cfg file and find the line that says:

"concourse_animations_at_25fps = 1"

Change it to:

"concourse_animations_at_25fps = 0"

That should allow the Concourse to run as fast as possible. Try and see what performance you get in the Concourse when you use this setting.

BatSpoggy
Cadet 4th Class
Posts: 11
Joined: Fri Jun 14, 2019 12:58 pm

Post by BatSpoggy » Sat May 15, 2021 10:13 am

Ok, so I've tested several things. Setting SteamVR_Interleaved_Reprojection = 0 doubled the framerate to 22.5, and this is the same at 20% or 500% resolution, as before. Turning motion smoothing on and off in SteamVR affects nothing, SteamVR legacy reprojection changes nothing, changing Nvidia vsync settings changes nothing, and changing vsync in vrparams also changes nothing.
Setting concourse_animations_at_25fps = 0 game me 45fps in the concourse with SteamVR_Interleaved_Reprojection = 0 and 90fps with SteamVR_Interleaved_Reprojection = 1.
22.5 is exactly 1/4 of the headset refresh rate, I'm more convinced that something is limiting it, especially as it's exactly steady at 22.5 and never dips below.

User avatar
blue_max
XWAU Member
Posts: 1801
Joined: Wed Mar 20, 2019 5:12 am

Post by blue_max » Tue May 18, 2021 6:18 pm

The SteamVR system forces a VSync with the headset, so that always limits the FPS you can get. However, the limit is usually either 90fps or 45fps, which is why I'm so confused that you're reporting 22.5 -- regardless of resolution.

Also, I meant to say "what's your resolution in pixels". So 20% doesn't mean much to me, unless you attach how many pixels that is. As a reference, I tend to play at 960x1080 pixels per eye in SteamVR and that gives a reasonable performance.

Let's try one more thing @BatSpoggy: go to VRParams.cfg and find the line that says:

VR_Mode = SteamVR

and change it for:

VR_Mode = DirectSBS

Don't wear your headset after this! Just look at your screen and check your framerate. The DirectSBS mode uses the same code as the SteamVR mode, but it doesn't do the SteamVR VSync. So, I just want to see where the problem is. If you keep seeing bad performance, then we would need to check your monitor's refresh rate.

BatSpoggy
Cadet 4th Class
Posts: 11
Joined: Fri Jun 14, 2019 12:58 pm

Post by BatSpoggy » Thu May 20, 2021 10:16 pm

I've been away for a few days, so I didn't get chance to try this until now.
I can't see a framerate readout, but running in SBS mode the image on the monitor is perfectly smooth, so I'd guess the framerate is at least 45. Moving the headset around did work with the head tracking, and even while moving it around the two images on the monitor remained perfectly smooth at all times. If the image in the headset were like that the game would be running very nicely, so I think the problem lies in whatever is running in SteamVR that isn't running in SBS, my computer is having no difficulty drawing the two images at a decent rate.

BatSpoggy
Cadet 4th Class
Posts: 11
Joined: Fri Jun 14, 2019 12:58 pm

Post by BatSpoggy » Fri May 21, 2021 11:59 am

To add to that as well, the characteristic juddering of the view when the viewpoint is moving wasn't there in SBS mode either.
That juddering is something strange of its own, I think. Running DCS at far too high a level of supersampling will give you low frame rates, but even in the region of 5fps the juddering isn't there. You'll see the viewpoint struggling to keep up, but it only lags in the direction your head is moving, if that makes sense. The juddering is more like a vibration effect, instead of only the axis that your head is moving in being affected it seems that all the headset axes are affected at the same time, translational and rotational.

User avatar
blue_max
XWAU Member
Posts: 1801
Joined: Wed Mar 20, 2019 5:12 am

Post by blue_max » Sat May 22, 2021 5:21 pm

Let me take a look again at the code. This is going to be a problem that is specific to SteamVR and maybe there are some parameters that affect how it syncs with the display and the headset.

HanSolo77
Cadet 4th Class
Posts: 12
Joined: Sat Jun 20, 2020 4:44 pm

Post by HanSolo77 » Mon May 24, 2021 11:38 am

Me-sa thinks, you-se did another great job in improving the VR performance :thumbs:
It's now a couple of months since I played XWAU last in VR, but I think, I'm getting some more FPS especially in "hot" situations.

However, it seems as if there still is no solution for the headtracking jitter, right...?
It is okay and playable as long as I am in "deep" space - but as soon as I approach more complex structures such as the Twin Suns Station in the Azzameen prologue, I still get terrible jitter when moving my head.
As mentioned in January already, it even gets much worse when enabling "low latency mode" in NVidia control panel.

So, I think, as long as there are deep space and battle missions, it is well playable now. But how to play any mission with stations and lots of ships involved, not talking about the Death Star, ... no idea... :?

User avatar
blue_max
XWAU Member
Posts: 1801
Joined: Wed Mar 20, 2019 5:12 am

Post by blue_max » Mon May 24, 2021 5:31 pm

I did find a spot that may be causing this problem, but I'm not sure. Part of the difficulty here is that I don't have a "proper" headset. That is: I can't see this problem on my end, so I'm basically "flying blind". I'll try to do something about this, though.

Also: expect to have a lower framerate when the screen is busy. What I find confusing is that even in lower framerates, I don't get this shaking you guys are describing.

BatSpoggy
Cadet 4th Class
Posts: 11
Joined: Fri Jun 14, 2019 12:58 pm

Post by BatSpoggy » Mon May 24, 2021 11:07 pm

blue_max wrote:
Mon May 24, 2021 5:31 pm
I did find a spot that may be causing this problem, but I'm not sure. Part of the difficulty here is that I don't have a "proper" headset. That is: I can't see this problem on my end, so I'm basically "flying blind". I'll try to do something about this, though.

Also: expect to have a lower framerate when the screen is busy. What I find confusing is that even in lower framerates, I don't get this shaking you guys are describing.
That's good news. I've been getting this problem very consistently, so if I see something that fixes or at least improves it I'd expect that the same will be true for a decent number of other people too.
Let me know if you want me to test anything, I can see if I can supersample it enough to get a bad framerate and then see if the shaking comes back or not.

User avatar
blue_max
XWAU Member
Posts: 1801
Joined: Wed Mar 20, 2019 5:12 am

Post by blue_max » Tue May 25, 2021 12:34 am

BatSpoggy wrote:
Mon May 24, 2021 11:07 pm
That's good news. I've been getting this problem very consistently, so if I see something that fixes or at least improves it I'd expect that the same will be true for a decent number of other people too.
Let me know if you want me to test anything, I can see if I can supersample it enough to get a bad framerate and then see if the shaking comes back or not.
Thanks! I'm definitely going to need some help testing this. For the record (and also, lest I forget), I think this is the line that needs to be updated:

https://github.com/Prof-Butts/Hook_XWAC ... R.cpp#L150

Briefly speaking, and glossing over the details, the 0.042f is the time (in seconds) for the next VSync. This number shouldn't be hard-coded: it should be computed dynamically after each frame is rendered. So, getting the right formula might be a little tricky.

HanSolo77
Cadet 4th Class
Posts: 12
Joined: Sat Jun 20, 2020 4:44 pm

Post by HanSolo77 » Tue May 25, 2021 6:32 am

I've got a decent PC (5600X, RTX 3080, Pimax 8K-X), so if I can assist in testing any built, please let me know. Best by sending a short PM - I am not looking every day into the forums :)

BatSpoggy
Cadet 4th Class
Posts: 11
Joined: Fri Jun 14, 2019 12:58 pm

Post by BatSpoggy » Tue May 25, 2021 7:54 am

Thanks! I'm definitely going to need some help testing this. For the record (and also, lest I forget), I think this is the line that needs to be updated:

https://github.com/Prof-Butts/Hook_XWAC ... R.cpp#L150

Briefly speaking, and glossing over the details, the 0.042f is the time (in seconds) for the next VSync. This number shouldn't be hard-coded: it should be computed dynamically after each frame is rendered. So, getting the right formula might be a little tricky.
That gives an update rate of 23.8Hz (assuming that time is in seconds) and that does look to be about what I'm getting. If that's concerning tracking only then you could try it hard-coded to 0.0111111111111111 (for 90Hz) on mine for a quick test. As far as I know the tracking rate of the headset isn't affected by low FPS so that should illustrate the difference.
If it's concerning the visuals as well then it might still have a useful effect, as reprojection does appear to be working fine if turned on in the config (it halved my framerate) so we can try it with that on to see if it produces a disconnect.

User avatar
blue_max
XWAU Member
Posts: 1801
Joined: Wed Mar 20, 2019 5:12 am

Post by blue_max » Tue May 25, 2021 5:43 pm

BatSpoggy wrote:
Tue May 25, 2021 7:54 am
That gives an update rate of 23.8Hz (assuming that time is in seconds) and that does look to be about what I'm getting. If that's concerning tracking only then you could try it hard-coded to 0.0111111111111111 (for 90Hz) on mine for a quick test. As far as I know the tracking rate of the headset isn't affected by low FPS so that should illustrate the difference.
If it's concerning the visuals as well then it might still have a useful effect, as reprojection does appear to be working fine if turned on in the config (it halved my framerate) so we can try it with that on to see if it produces a disconnect.
Interesting! OK, I just hard-coded 0.011 as you suggested to see if that helps. Can you try this DLL to see if that makes any difference?
Hook_CockpitLook.zip
You do not have the required permissions to view the files attached to this post.

BatSpoggy
Cadet 4th Class
Posts: 11
Joined: Fri Jun 14, 2019 12:58 pm

Post by BatSpoggy » Tue May 25, 2021 7:33 pm

The only difference that made is that I now only get 11.2fps. I used to get that with SteamVR_Interleaved_Reprojection = 1 and with it at 0 I got 22.5. Now I'm getting 11.2 always in flight. In the concourse I get either 90 or 45 depending on whether that setting is on.
That was the same at 20% resolution as it was at 500%, 11.2fps all the time. This is in a deep space skirmish with only my X/W and one inactive T/F
Strangely with the old dll I'm now getting 11.2 all the time as well.
I also have no translational movement tracking on the headset, only rotation. That's probably not related though.

User avatar
blue_max
XWAU Member
Posts: 1801
Joined: Wed Mar 20, 2019 5:12 am

Post by blue_max » Tue May 25, 2021 9:12 pm

BatSpoggy wrote:
Tue May 25, 2021 7:33 pm
I also have no translational movement tracking on the headset, only rotation. That's probably not related though.
Hold on, if you have two DLL files on the same directory they will both get loaded and they will cause conflicts. I forgot to mention this, but you have to rename the old DLL to Hook_CockpitLook.dl_ (or something that doesn't end in "DLL"), before using the new one. The lack of translational movement is an indication that there might be a conflict. Would you mind trying again?

BatSpoggy
Cadet 4th Class
Posts: 11
Joined: Fri Jun 14, 2019 12:58 pm

Post by BatSpoggy » Tue May 25, 2021 10:52 pm

blue_max wrote:
Tue May 25, 2021 9:12 pm
Hold on, if you have two DLL files on the same directory they will both get loaded and they will cause conflicts. I forgot to mention this, but you have to rename the old DLL to Hook_CockpitLook.dl_ (or something that doesn't end in "DLL"), before using the new one. The lack of translational movement is an indication that there might be a conflict. Would you mind trying again?
I'd moved the old one to another folder, and I never had translational movement with the original DLL either. I've looked through the config and can't see any problems. Translational movement worked on the version I had a few months ago, I wonder what has changed that'd affect that?

HanSolo77
Cadet 4th Class
Posts: 12
Joined: Sat Jun 20, 2020 4:44 pm

Post by HanSolo77 » Wed May 26, 2021 9:42 am

blue_max wrote:
Tue May 25, 2021 5:43 pm
Interesting! OK, I just hard-coded 0.011 as you suggested to see if that helps. Can you try this DLL to see if that makes any difference?

Hook_CockpitLook.zip
I did a test, too, renamed the old .dll before, of course:
No change, same jitter as before.

User avatar
m0rgg
Cadet 2nd Class
Posts: 80
Joined: Wed Apr 01, 2020 10:33 pm

Post by m0rgg » Fri May 28, 2021 11:27 pm

Indeed, the value shouldn't be hard coded, it should be provided by OpenVR based on the frametime/FPS, which determines the motion-to-photon latency. And that's how it works if you use the poses from WaitGetPoses() directly.
However, this proved to be bad for performance, and this alternative allows to decouple getting poses from the frame sync.

The 42ms value was taken experimentally, using the motion-to-photon latency reported by Oculus debug tool.
In any case, it should be around 2 vsync periods, as the frame wil take around 1 for rendering, an another full one for "scanning" into the display.

At 90Hz 1 vsync is 11.1ms, so the 42ms is optimized for 45Hz (when reprojection is kicking in).

You can put 0 and the jitter should disappear if it is indeed caused by the prediction, but then you will have more perceived latency between head motion and the view.

User avatar
m0rgg
Cadet 2nd Class
Posts: 80
Joined: Wed Apr 01, 2020 10:33 pm

Post by m0rgg » Sat May 29, 2021 5:29 pm

It would be interesting that you report the VR driver you use (Oculus, Valve/Vive, WMR), as they may behave slightly differently in implementing the OpenVR API and it can help isolate different problems that have the same symptoms.

Working backwards from the time that the image is effectively displayed in the HMD, to get the right value for prediction we need:

- The time it takes from the scan out starting on vsync, to the photons being displayed (vr::Prop_SecondsFromVsyncToPhotons_Float)

- The HMD display Hz/VSync period (vr::Prop_DisplayFrequency_Float), which is the maximum frame time allowed for rendering and the number of times (vsync intervals) the frame will be reprojected, if the next frame does not meet the frametime (FPS drop). This cannot be known at the time of getting the poses, but it can be assumed that it will be the same as the previous frame (IVRCompositor::GetFrameTiming() -> Compositor_FrameTiming::m_nNumMisPresented [1]).

- The time remaining until the vsync when the frame should be submitted (IVRCompositor::GetFrameTimingRemaining())

In theory the right prediction time should be [2]:

Code: Select all

fPredictedSecondsFromNow = GetFrameTimingRemaining + (m_nNumMisPresented/Prop_DisplayFrequency_Float) + Prop_SecondsFromVsyncToPhotons_Float
But then, when async reprojection is used (or ASW in Oculus), it seems the pose assumed by the reprojection warping algorithms is the one returned by WaitGetPoses, so you need to submit the Pose effectively used for rendering to the VR compositor [3].

This is the best explanation I have found with comments from SteamVR developers:
https://github.com/ValveSoftware/openvr/issues/518

I was hoping to solve this problems with OpenXR as everything is lower level and with less "magic" from the SDK, but never got to finish it... I will try to find some time and get into it again...

[1] https://developer.valvesoftware.com/wik ... ame_Timing
[2] https://github.com/ValveSoftware/openvr ... -302201270
[3] https://github.com/ValveSoftware/openvr ... -322575196

User avatar
blue_max
XWAU Member
Posts: 1801
Joined: Wed Mar 20, 2019 5:12 am

Post by blue_max » Fri Jun 18, 2021 6:17 pm

I'm currently working on another OPTing project for XWA, but once I'm done with that (soon), I'll go back to this problem. Hopefully SteamVR will support OpenXR by then.

Post Reply