HP's Reverb VR Pro Headset

This might be obvious, but do you have Vsync enabled in DCS settings? It causes weird stuttering and issues in VR at least for me.

No vsync as i have a gsync enabled monitor

No vsync as i have a gsync enabled monitor

Pro tip. Put VR to the side until the 3080 TI lands, and you don’t have to spend more time playing the option screen than you do flying the simulator. That’s what I did and I’m loving DCS more than ever.

Exactly...that is driving me mad.

Maybe i need to lower the vr pre rendered frames?

I mean, you could try that, but, as we’ve said, it’s really strange that you are seeing pretty decent frame times that are not always reflected in the fps.

I feel for you! Personally, I am really happy with VR in DCS with high settings and SS of 150% giving a rock solid 45fps with frame times hardly ever over 20ms. I don’t really spend time tinkering with settings any more which is a good thing!

I hope you work it out soon.

Something dont add up.

Having for example 20ms frametime on the slowest of CPU/GPU vill render 50 frames per second.

Each frames takes 20ms, 50 of this sums up to 1000ms, one second.

Is it possible that VirusAM doesnt see the hickups in frame time on fpsVR ?

The continous drawing graph over frame times, green is max 11ms, amber/yellow is max 22ms and red is above.

I made this for another thread to show, by risning settings and provoke by flying low over a city.

(My normal settings will keep at 45 or above almost all the time.

I'm just going to copy paste my response on reddit to the youtube video a couple pages back, since I own a reverb and I touched on driver enabled MSAA (doesn't work) and the effect of virtual reality pre-rendered frames (less means less ghosting but more min frame times).

"

I immediately doubt your credibility when you still somehow have not grasped the PD vs Steam SS difference, that LITERALLY gets repeated as nauseam across the internet. PD setting of 1.5 means make the resolution 1.5 times wider and 1.5 longer, for 225% more pixels. Steam SS 150% means 150% more pixels. PD 2.0 is the same as Steam 400%. This gets spammed so much by people on the forums; I get the various boomers not grasping it but I really don’t get how you missed it.

Anyways, you also most likely don’t understand the full impact of upping pre-rendered frames, but that is more understandable. When you queue up 3 frames on the cpu, you now are making your headset software predict 3 x 1000/FPS milliseconds in the future as opposed to 1 x (single frame gpu render time). This is a huge difference and will make late stage rotational reprojection super shit (tons of ghosting on fast moving distant objects). Now, obviously this is a per user subjective thing as many will be bothered by low frame stutters vs ghosting and vice versa, so I certainly agree with trying 4 and seeing if zooming in on far away targets or rolling over trees bothers you.

I personally suggest using Nvidia low latency ultra, as this will use average frame time data to schedule the cpu frame completion to coincide with gpu frame render. This gives you the GPU throughput of 2 pre-rendered frames (the gpu is never waiting on the cpu like in 1 pre-rendered frame), with the latency (equal to just the gpu render time of one frame) of 1 pre-rendered frame.

Finally, I don’t think you understand the implications of implying that you can enable driver level MSAA in this D3D11-powered deferred rendering pipeline game. You flat out can’t enable driver MSAA in D3D11, and you flat out can’t design a driver level multi sample implementation in a deferred rendering engine.

After re-watching your video, I am confident all you are observing is the transparency super sampling. While the setting does in fact work, it is pointless to enable, as NVCP transparency super sampling merely ordered grid super-samples pixels that pass alpha test, i.e it costs just a much as full-scene super sampling per pixel. So, by enabling you end up spending more gpu power per pixel on alpha textures than the non-alpha texture pixels, which is the opposite of efficient behavior. MSAA is generally so efficient vs full scene supersampling in part because it culls the alpha texture pixels from sampling as opposed to prioritizing them.

Also, to elaborate, AA override or enhance does absolutely nothing, as it will in most deferred rendering engines, and ANYTHING D3D11+ or Vulkan. However, post process FXAA works, and interestingly enough MFAA (maxwell-gen aa interleaving) works with DCS 2x or 4x MSAA. This is the real driver trick if you require DCS MSAA; as long as you maintain decent frames rates MFAA will interpolate 2x or 4x samples with motion vectors every other frame to essentially create a 4x or 8x sample at half the cost.

"

Something dont add up.

 

Having for example 20ms frametime on the slowest of CPU/GPU vill render 50 frames per second.

Each frames takes 20ms, 50 of this sums up to 1000ms, one second.

 

Is it possible that VirusAM doesnt see the hickups in frame time on fpsVR ?

That’s what has been talked about for a while here! He is seeing less than 20ms yet not seeing 45fps.

That is what doesn’t add up.

That’s what has been talked about for a while here! He is seeing less than 20ms yet not seeing 45fps.

 

That is what doesn’t add up.

Yes, I followed the thread and and I made some post earlier.

The VSYNC setting in DCS as someone aksed about is a valid question, to confirm its really is off.

(It would make a frame wait longer than needed to be projected most of the times, and this would add ms between each produced frame. Just emphraising, due to the actuall problem.

Another thing, fpsVR iinfo on Steam:

WMR headsets, with limitations:

- SteamVR doesn't report about reprojected and dropped frames for WMR.

- frametimes not include part of the work of the native frame compositor.

The latter part; I dont really get it, but anyway it should mean that frametime actually can be longer than the reported. I havent seen this, Im quite sure that I keep 45ps all the way to 22ms or 90 to 11ms.

https://steamcommunity.com/app/908520/discussions/0/1735462352484917218/

V-sync/triple buffer/gsync etc settings are completely ignored by WMR/OpenVR/Oculus pipeline. VR screens, both software and hardware, function wholly different from traditional monitor screens - this is why Oculus and OpenVr currently run the screens in exclusive "Direct" mode, completely segregated from the traditional desktop rendering pipeline. VR screens run at extremely low persistence (the screen flashes on for far less than 11 ms, and then turns black), so the display must ALWAYS stay locked to refresh rate for this low persistence flicker to be perceived as uniform imagery by our brains. It is then the VR framework's job to ensure a rock solid set of frames is delivered by dynamically re-projecting, duplicating, and dropping application-rendered frames to exactly produce an even 90fps to the headset compositor.

This leads into WMR and the WMR native frame compositor with regards to FPSVR frametimes. WMR->StreamVr is an awkward situation where two separate fully capable VR frameworks are running at the same time, and so a number of framework compositing duties are split between the two. Notably, WMR handles all distortion correction, and most importantly all of the aforementioned frame operations to maintain stable 90 fps. This easily can consume 1+ms per rendered frame, and indeed is the reason FPSVR cannot be used for precise frame time cutoff analysis. It is actually possible to get detailed frame time information from the WMR compositor itself, by using https://docs.microsoft.com/en-us/windows/mixed-reality/using-the-windows-device-portal, but it is somewhat technical and completely useless in game.

V-sync/triple buffer/gsync etc settings are completely ignored by WMR/OpenVR/Oculus pipeline. VR screens, both software and hardware, function wholly different from traditional monitor screens - this is why Oculus and OpenVr currently run the screens in exclusive "Direct" mode, completely segregated from the traditional desktop rendering pipeline. VR screens run at extremely low persistence (the screen flashes on for far less than 11 ms, and then turns black), so the display must ALWAYS stay locked to refresh rate for this low persistence flicker to be perceived as uniform imagery by our brains. It is then the VR framework's job to ensure a rock solid set of frames is delivered by dynamically re-projecting, duplicating, and dropping application-rendered frames to exactly produce an even 90fps to the headset compositor.

 

 

 

This leads into WMR and the WMR native frame compositor with regards to FPSVR frametimes. WMR->StreamVr is an awkward situation where two separate fully capable VR frameworks are running at the same time, and so a number of framework compositing duties are split between the two. Notably, WMR handles all distortion correction, and most importantly all of the aforementioned frame operations to maintain stable 90 fps. This easily can consume 1+ms per rendered frame, and indeed is the reason FPSVR cannot be used for precise frame time cutoff analysis. It is actually possible to get detailed frame time information from the WMR compositor itself, by using https://docs.microsoft.com/en-us/windows/mixed-reality/using-the-windows-device-portal, but it is somewhat technical and completely useless in game.

Maybe we just wait for the promised dcs wmr native implementation. That should let us gain some precious ms....

Anyway i could understand if i was on the lit (20/21 ms) but a part from occasional red spikes I never surpass 19ms but low level over dubai I cannot mantain 45fps minimum...this remains a mistery

Something dont add up.

 

Having for example 20ms frametime on the slowest of CPU/GPU vill render 50 frames per second.

Each frames takes 20ms, 50 of this sums up to 1000ms, one second.

 

Is it possible that VirusAM doesnt see the hickups in frame time on fpsVR ?

 

The continous drawing graph over frame times, green is max 11ms, amber/yellow is max 22ms and red is above.

I made this for another thread to show, by risning settings and provoke by flying low over a city.

(My normal settings will keep at 45 or above almost all the time.

 

 

Almost always orange for the gpu with some green in less complex scenes.

Pro tip. Put VR to the side until the 3080 TI lands, and you don’t have to spend more time playing the option screen than you do flying the simulator. That’s what I did and I’m loving DCS more than ever.

I tried....but i was not able to stay away from vr for more then some weeks.

V-sync/triple buffer/gsync etc settings are completely ignored by WMR/OpenVR/Oculus pipeline.

This is not my experience with WMR. If I have VSYNC setting enabled in DCS, it will break 45fps motionvector ASW. Therefore I must always disable it when playing in VR.

This is not my experience with WMR. If I have VSYNC setting enabled in DCS, it will break 45fps motionvector ASW. Therefore I must always disable it when playing in VR.

Why would it do that? It sets a max frame rate, not minimum.

Why would it do that? It sets a max frame rate, not minimum.

That is a good question. I am just reporting what I have been experiencing. This has been the case with Odyssey+ WMR and most likely also Reverb (I will double check this).

I see very rare instances of a reported 46 fps, even though I have both motion vector and vsync enabled... It never creates a problem and if I'm honest I suspect it's artefact generated by pre-rendering frames...

That is a good question. I am just reporting what I have been experiencing. This has been the case with Odyssey+ WMR and most likely also Reverb (I will double check this).

You are absolutely right! I tried with DCS VSYNC on, and sure enough, the frame rates were varying all over the place between 45 and 60.

Now this is interesting as it should be allowing up to 90. I always use NCP VYSNC on, but it happily alows up to 90, so I really don't know what's going on with DCS VSYNC. Never used it before!

This may help some people.

 

I'm just going to copy paste my response on reddit to the youtube video a couple pages back, since I own a reverb and I touched on driver enabled MSAA (doesn't work) and the effect of virtual reality pre-rendered frames (less means less ghosting but more min frame times).

 

 

"

I immediately doubt your credibility when you still somehow have not grasped the PD vs Steam SS difference, that LITERALLY gets repeated as nauseam across the internet. PD setting of 1.5 means make the resolution 1.5 times wider and 1.5 longer, for 225% more pixels. Steam SS 150% means 150% more pixels. PD 2.0 is the same as Steam 400%. This gets spammed so much by people on the forums; I get the various boomers not grasping it but I really don’t get how you missed it.

 

Anyways, you also most likely don’t understand the full impact of upping pre-rendered frames, but that is more understandable. When you queue up 3 frames on the cpu, you now are making your headset software predict 3 x 1000/FPS milliseconds in the future as opposed to 1 x (single frame gpu render time). This is a huge difference and will make late stage rotational reprojection super shit (tons of ghosting on fast moving distant objects). Now, obviously this is a per user subjective thing as many will be bothered by low frame stutters vs ghosting and vice versa, so I certainly agree with trying 4 and seeing if zooming in on far away targets or rolling over trees bothers you.

 

I personally suggest using Nvidia low latency ultra, as this will use average frame time data to schedule the cpu frame completion to coincide with gpu frame render. This gives you the GPU throughput of 2 pre-rendered frames (the gpu is never waiting on the cpu like in 1 pre-rendered frame), with the latency (equal to just the gpu render time of one frame) of 1 pre-rendered frame.

 

Finally, I don’t think you understand the implications of implying that you can enable driver level MSAA in this D3D11-powered deferred rendering pipeline game. You flat out can’t enable driver MSAA in D3D11, and you flat out can’t design a driver level multi sample implementation in a deferred rendering engine.

 

After re-watching your video, I am confident all you are observing is the transparency super sampling. While the setting does in fact work, it is pointless to enable, as NVCP transparency super sampling merely ordered grid super-samples pixels that pass alpha test, i.e it costs just a much as full-scene super sampling per pixel. So, by enabling you end up spending more gpu power per pixel on alpha textures than the non-alpha texture pixels, which is the opposite of efficient behavior. MSAA is generally so efficient vs full scene supersampling in part because it culls the alpha texture pixels from sampling as opposed to prioritizing them.

 

Also, to elaborate, AA override or enhance does absolutely nothing, as it will in most deferred rendering engines, and ANYTHING D3D11+ or Vulkan. However, post process FXAA works, and interestingly enough MFAA (maxwell-gen aa interleaving) works with DCS 2x or 4x MSAA. This is the real driver trick if you require DCS MSAA; as long as you maintain decent frames rates MFAA will interpolate 2x or 4x samples with motion vectors every other frame to essentially create a 4x or 8x sample at half the cost.

"

:book::book::book:

Oh my... All this different and conflicting info, in so many posts and video's.. It's getting might complicated for Reverb newcomers like me :helpsmilie:

I assume I should still start with vr4dcs.com, or is there nonsense on this site as well that I should definitely avoid?

:book::book::book:

 

 

 

Oh my... All this different and conflicting info, in so many posts and video's.. It's getting might complicated for Reverb newcomers like me :helpsmilie:

 

 

 

I assume I should still start with http://vr4dcs.com, or is there nonsense on this site as well that I should definitely avoid?

:book::book::book:

 

Oh my... All this different and conflicting info, in so many posts and video's.. It's getting might complicated for Reverb newcomers like me :helpsmilie:

 

I assume I should still start with vr4dcs.com, or is there nonsense on this site as well that I should definitely avoid?

Yes, the advice on vr4dcs is - on the whole - pretty good. One thing I would certainly disagree with, and that is it recommends using the non-beta version of SteamVR. I would say, always use the beta version. It gets updated every other day, and features options and improvements that sometimes take weeks to get to the 'release' version. If there is something not working OK, it takes literally a minute to go back to the release version.

In my opinion, 60Hz is horrible! Too much flickering. 45fps at 90 is preferable to 60fps at 60Hz all day long.

What flickering at 60Hz are you talking about imacken?

An overall image in the game? was one eye predominantly more flickery?

Or are the menu's more flickery?

I found 60 Hz to be absolutely perfect but the last update about 1 or 2 weeks ago sporadically dropped my fps below 60Hz so I have reset the system to 90hz and locked it down to 45hz.

For the chopper pilot flying low at 4 or 5 metres above the ground this creates weird image abnormalities along straight edges when looking down through the nose blister or when looking at buildings towering above you through the fast rotating blades. it is as if the 45hz frame rate cannot keep up with fast rendered images.

What flickering at 60Hz are you talking about imacken?

An overall image in the game? was one eye predominantly more flickery?

Or are the menu's more flickery?

Just the typical flickering of lower refresh rates really.

how does that look, like a low or high frequency line that drops across the total image in both eyes?

or a pulsing effect of the whole image?

Is it eye ball related, right eye more?

I want to look for it when I go back to 60 Hz.

I think the reverb crowd needs to sound off about their specific needs... their weaknesses and their strengths, this may help us come to an understanding of our situation in the 3 dimensional virtual world.

We need to set a automated thingy that always shows at the bottom of each of our posts.... like the thing some high end spec system posers always have.... how do you do that?

The post note should have everything relating to VR, system spec (basic), ipd, glasses, and current settings in DCS and VR.... everything that may be relevant to the VR experience only.

It is better if we move as a heard.

I think the reverb crowd needs to sound off about their specific needs... their weaknesses and their strengths, this may help us come to an understanding of our situation in the 3 dimensional virtual world.

 

We need to set a automated thingy that always shows at the bottom of each of our posts.... like the thing some high end spec system posers always have.... how do you do that?

The post note should have everything relating to VR, system spec (basic), ipd, glasses, and current settings in DCS and VR.... everything that may be relevant to the VR experience.

 

It is better if we move as a heard.

Click User CP at the top left of this page , under settings at left , click "edit signature" .Posers ? See below .

how does that look, like a low or high frequency line that drops across the total image in both eyes?

or a pulsing effect of the whole image?

Is it eye ball related, right eye more?

I want to look for it when I go back to 60 Hz.

From my perspective when I tried 60Hz, it was the same feeling as walking into a room that was lit by a bad fluorescent tube. Dimmer than 90Hz, and strobing so badly that it made my eyes feel like they were being pulled out of my skull and I almost instantly got a headache. 90Hz doesn't create those problems for me. I guess it doesn't affect everybody the same way, but for me 60Hz was a non-starter.