X-Wing Alliance VR mod
Re: X-Wing Alliance VR mod
- blue_max
- Posts: 2296
- Joined: Wed Mar 20, 2019 5:12 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.
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.
-
- Posts: 11
- Joined: Fri Jun 14, 2019 12:58 pm
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.
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.
- blue_max
- Posts: 2296
- Joined: Wed Mar 20, 2019 5:12 am
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.
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.
-
- Posts: 11
- Joined: Fri Jun 14, 2019 12:58 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.
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.
-
- Posts: 11
- Joined: Fri Jun 14, 2019 12:58 pm
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.
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.
- blue_max
- Posts: 2296
- Joined: Wed Mar 20, 2019 5:12 am
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.
-
- Posts: 12
- Joined: Sat Jun 20, 2020 4:44 pm
Me-sa thinks, you-se did another great job in improving the VR performance
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...![grübel :?](./images/smilies/icon_confused.gif)
![daumen rauf :thumbs:](./images/smilies/icon_thumbs1.gif)
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...
![grübel :?](./images/smilies/icon_confused.gif)
- blue_max
- Posts: 2296
- Joined: Wed Mar 20, 2019 5:12 am
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.
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.
-
- Posts: 11
- Joined: Fri Jun 14, 2019 12:58 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.blue_max wrote: ↑Mon May 24, 2021 5:31 pmI 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.
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.
- blue_max
- Posts: 2296
- Joined: Wed Mar 20, 2019 5:12 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:BatSpoggy wrote: ↑Mon May 24, 2021 11:07 pmThat'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.
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.
-
- Posts: 12
- Joined: Sat Jun 20, 2020 4:44 pm
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 ![lachen :)](./images/smilies/icon_smile.gif)
![lachen :)](./images/smilies/icon_smile.gif)
-
- Posts: 11
- Joined: Fri Jun 14, 2019 12:58 pm
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.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.
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.
- blue_max
- Posts: 2296
- Joined: Wed Mar 20, 2019 5:12 am
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?BatSpoggy wrote: ↑Tue May 25, 2021 7:54 amThat 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.
You do not have the required permissions to view the files attached to this post.
-
- Posts: 11
- Joined: Fri Jun 14, 2019 12:58 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.
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.
- blue_max
- Posts: 2296
- Joined: Wed Mar 20, 2019 5:12 am
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?
-
- Posts: 11
- Joined: Fri Jun 14, 2019 12:58 pm
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?blue_max wrote: ↑Tue May 25, 2021 9:12 pmHold 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?
- m0rgg
- Posts: 268
- Joined: Wed Apr 01, 2020 10:33 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.
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.
- m0rgg
- Posts: 268
- Joined: Wed Apr 01, 2020 10:33 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]:
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
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
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
- blue_max
- Posts: 2296
- Joined: Wed Mar 20, 2019 5:12 am
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.
-
- Posts: 4
- Joined: Sat Aug 15, 2009 10:08 pm
Am I overlooking something? I downloaded the VR mod from the downloads section but it's a zip file and not an installer. Is there an installer anymore?
- m0rgg
- Posts: 268
- Joined: Wed Apr 01, 2020 10:33 pm
The mod is included in XWAU, it's part of the effects ddraw.
You can enable it with Babu Frik configurator.
You can enable it with Babu Frik configurator.
-
- Posts: 4
- Joined: Sat Aug 15, 2009 10:08 pm
For whatever reason the mouse loading circle comes up and then Steam shows the "Play" button green again. I guess the vr settings don't like PiMax headsets
- m0rgg
- Posts: 268
- Joined: Wed Apr 01, 2020 10:33 pm
Don't use Steam to launch the game. In fact, copy the files from the base game over to a different folder and install XWAU there. Once XWAU is installed and VR enabled with babu frik:
1. open SteamVR and wait for it to launch and detect your headset
2. Use alliance.exe launcher
1. open SteamVR and wait for it to launch and detect your headset
2. Use alliance.exe launcher