Meta Quest Pro Settings

[Flyingfish]

36 minutes ago, kevman said:

Thanks - is this a limitation in dcs software, meta software or the openxr toolkit?

 

In theory this should be something that could work on the qp no?

 

Not with the OpenXR toolkit I don't think. This is the response on discord from the person who programmes OpenXR toolkit when asked if eye tracking foveated rendering will come to DCS

 

Meta runtime does not support "fovMutable", which would be a lot of work to implement.
I will add support for Pimax most likely, but only because they have this "fovMutable". Doing this "fovMutable" on Oculus is a lot of work I don't have intention to do.

[kevman]

Thanks for the update - v useful.

Just trying to decide if should get qp or wait for the quest 3.

I the qp could do DFR then it might be worth not waiting

25 minutes ago, Flyingfish said:

Not with the OpenXR toolkit I don't think. This is the response on discord from the person who programmes OpenXR toolkit when asked if eye tracking foveated rendering will come to DCS

 

Meta runtime does not support "fovMutable", which would be a lot of work to implement.
I will add support for Pimax most likely, but only because they have this "fovMutable". Doing this "fovMutable" on Oculus is a lot of work I don't have intention to do.

 

[Blue73]

2 hours ago, Flyingfish said:

Not with the OpenXR toolkit I don't think. This is the response on discord from the person who programmes OpenXR toolkit when asked if eye tracking foveated rendering will come to DCS

 

Meta runtime does not support "fovMutable", which would be a lot of work to implement.
I will add support for Pimax most likely, but only because they have this "fovMutable". Doing this "fovMutable" on Oculus is a lot of work I don't have intention to do.

I see the DFR option in FS2020 when launching the OpenXR headset menu, and when enabled appears to be working. But I don't see it in DCS.

[Flyingfish]

36 minutes ago, Hoirtel said:

Where does the quest 2 have eye tracking then?

The quest 2 doesn't have eye tracking, the quest pro does

[jparker36]

5 hours ago, Blue73 said:

I see the DFR option in FS2020 when launching the OpenXR headset menu, and when enabled appears to be working. But I don't see it in DCS.

DFR works on the quest pro in a few games, MSFS, iracing, and ACC being the biggest ones

[ironhard]

I'm considering a Quest Pro. What do you owners think, wait for Quest 3, or bite the price for a Quest Pro now?

I'd be running on 5800X3D and RTX3080.

 

Edited April 5, 2023 by ironhard

[Tepnox]

12 hours ago, Blue73 said:

I see the DFR option in FS2020 when launching the OpenXR headset menu, and when enabled appears to be working. But I don't see it in DCS.

Foveated Rendering only works as "fixed" as a fallback in DCS (so no real eye tracking like in MSFS) - so you define the overall mask. That is all for the moment. I really hope OpenXR can support DCS with eye tracking in the future, but the developers said it would be a heavy development - so unlikely.

You can still save some GPU-headroom with the fixed foveated rendering - works better than the pseudo DCS HMD Mask. If you are willing to compromise some edge-clarity you can save some more headroom.

But the results in MSFS with DFR are really nice, you can save 20 - 25 % GPU-Load when correctly configured. Really impressive. This feature combined with Multi-Threading and possibly DLSS would be really awesome for many VR-users.

20 minutes ago, ironhard said:

I'm considering a Quest Pro. What do you owners think, wait for Quest 3, or bite the price for a Quest Pro now?

I'd be running on 5800X3D and RTX3080.

 

 

Well you can always wait, nothing wrong with that ;D I would say, if you are more price sensitive just wait for the Quest 3. Otherwise the Quest Pro is a nice deal right now if you want to spend that money.

Edited April 5, 2023 by Tepnox

[ironhard]

Regading its wifi capability, I read somewhere about Intel DCT compatibility with the Quest, specifically the article mentioned the AX1690 laptop wifi chip and its low latency (<5ms) single hop routing capability.

How about normal wifi chips we find on normal motherboards? Can you connect them directly to the Quest for single hop routing?

[Blue73]

For me the QP has been a worthwhile upgrade over my G2. The clarity and fov of the lenses are the biggest plus, and now with local dimming. I find the headset more comfortable and the ability to see the keyboard useful. Controllers are allot better, audio is surprisingly good. I don't get eye strain like I used to with the G2. 

My criticism's are the lenses are so sharp I can sometime see screendoor and I get weird compression artifacts when ASW is enabled over water. 

Edited April 5, 2023 by Blue73

[Tepnox]

8 hours ago, Blue73 said:

For me the QP has been a worthwhile upgrade over my G2. The clarity and fov of the lenses are the biggest plus, and now with local dimming. I find the headset more comfortable and the ability to see the keyboard useful. Controllers are allot better, audio is surprisingly good. I don't get eye strain like I used to the G2. 

My criticism's are the lenses are so sharp I can sometime see screendoor and I get weird compression artifacts when ASW is enabled over water. 

Thats true. The ASW algorithm has some problems with clear blue colors (solid blue sky, calm sea) and results in wrong motion vectors and distortion under certain circumstances it seems. Happens to me too.

[ODBU_Mongoose]

Hi Tepnox thanks so much! This is one of the few good guides out there for the QuestPro.

Having switched from G2 to Quest Pro meant a huge improvement for me. Just this tweaking for DCS with the USB-C cable is a bif of a hassle. Few questions I have that I was just wondering (sorry no tech guy here)

• So with the OpenXR embedded in the beta of DCS youre saying keep the default super sampling in OTT at 1.0 right? 
• You mention encode resolution 3905. Other forums say for the QP needs 3600 max as this is the max horizontal resolution. Can you explain?
• So OTT is more fore tuning and ODT for checking the settings? Both seem to do kind of the same

But fair to say, its a hugely underappreciated headset. For me its just so much better than the G2. Not losing sight anymore in a dogfigt because of the great contrast and great sweet spot is just awesome. Again, thanks for the settings and Ill keep on following this thread!

Specs to be sure: 13600K, 4080, MSI Z690a, 64GB 3200, Quest Pro connected via USB-C cable 

Keep up the good work!

Edited April 6, 2023 by ODBU_Mongoose

[Blue73]

1 hour ago, ODBU_Mongoose said:

But fair to say, its a hugely underappreciated headset. For me its just so much better than the G2. Not losing sight anymore in a dogfigt because of the great contrast and great sweet spot is just awesome. Again, thanks for the settings and Ill keep on following this thread!

 

 

I agree, it's under-appreciated, this hmd has brought back the thrill of virtual reality that I had lost with the G2.

[slughead]

On 3/19/2023 at 12:48 AM, Tepnox said:

If you want some exact pixel tables per eye on super sampling, I did some testing:

1.00  (BASELINE)	2816x2896 (Oculus Home Settings = 5408x2736)
1.05	2960*3040 Blurry Instruments
1.10	3088*3184 Slightly Blurry Instruments
1.15	3232*3328 OK
1.20	3376*3472
1.25	3520*3616 Perfect Clarity
1.30	3664*3760
1.35	3792*3904
1.40	3936*4048
1.45	4080*4192
1.50	4224*4336

 

And for the encode resolution you should always go for the maximum possible resolution - the higher the better the compressed image quality. Settings too high can lead to artefacts on the lower image - there seems to be a maximum.

Enc 3680 (3680x2080)

Enc 3780 (3808x2080)

Enc 3880 (3904x2080)

Enc 3900 (3904x2080)

Enc 3905 (3936x2080) Optimum

Enc 3906 (3936x2080)

Enc 3907 (3936x2080)

Enc 3908 (3936x2080)

Enc 3909 (3936x2080)

Enc 3910 (3936x2240) Artefacts

Enc 3960 (3968x2240) Artefacts

Enc 4040 (4064x2240) Artefacts

Hey there. I just got a Quest Pro yesterday and I've been looking into its configuration of it. With regard to the encoding rate, I would say that anything above the application resolution is probably a waste. So in your example above, if you are running at PD 1.25 (3520 x 3616) then an encoding rate of 3680 is probably more efficient. I may have this completely wrong of course.

With my setup, PD 1.25 at the moment as that helps to sharpen up the cockpit, the Oculus Debug Tool is indicating an app resolution of 3424 x 1760. So I am using an encoding resolution of 3648 x 2240.

With the latest Oculus Tray Tool, I'm not seeing the same resolutions as in your table. Could you tell me how you got the resolutions from the PD?

Edited April 10, 2023 by slughead

[Tepnox]

21 hours ago, slughead said:

Hey there. I just got a Quest Pro yesterday and I've been looking into its configuration of it. With regard to the encoding rate, I would say that anything above the application resolution is probably a waste. So in your example above, if you are running at PD 1.25 (3520 x 3616) then an encoding rate of 3680 is probably more efficient. I may have this completely wrong of course.

With my setup, PD 1.25 at the moment as that helps to sharpen up the cockpit, the Oculus Debug Tool is indicating an app resolution of 3424 x 1760. So I am using an encoding resolution of 3648 x 2240.

With the latest Oculus Tray Tool, I'm not seeing the same resolutions as in your table. Could you tell me how you got the resolutions from the PD?

 

I think you are mixing some things up here. The encode resolution describes the capturing resolution the data stream gets before encoding and sending it to the headset via cable. The higher the encoder resolution the better the overall image at the end when displayed on the headset lenses.

The Quest Pro does not use uncompressed data like with Display-Port (sadly) and so the video signal needs to be compressed as a data stream. You could compare it to a Youtube video that is 1080p or 4K resolution. Of course the 4K YT-Video looks always better even on a device, that has a resolution less than 4K.

So for the encoding resolution you should always aim for the maximum in resolution and bitrate to have the best possible output on your lenses after decompressing.

The second thing is the Pixel density, this describes the overall image in pixels. This depends on your baseline set in the Oculus Home Settings.

You can check out the currently set real pixel density with OTT and the visual HUD for Pixel Density: 

The Pixel Density HUD only works when you have a VR application running (does not work on the Oculus Rift Home Center).

If you would like to check the current pixel resolution or Density ("App Res") and encoder resolution ("Enc Res"), you have to use the OculusDebugTool.exe of Oculus (C:\Program Files\Oculus\Support\oculus-diagnostics) and use the "Performance" HUD with Mode "Oculus Link".

I know in the Oculus Home App with 1.5x the Render resolution says 5408*2736. But if you check out the pixel density with the diagnostics tools (having 1.0 with OTT), you see the actual pixel rendering is higher than that. I think Oculus made a mistake here and just used the settings you set with a Quest 2 but the settings internallly have a higher setting on Quest Pro. This translates to 5.632*2896 (or 2816*2896 per eye - I always use the per Eye resolution in my list because this is better to understand than a combined resolution for width+height which Oculus uses).

I hope this clears something up. I know this is very technical but that is the way of VR ;D

So in short: you have a VR picture that gets video compressed to 3936*2080 pixels (this is combined width + height - so 1968*2080 per eye) and inside the headset this compressed signal gets supersampled to the desired final resolution you set with Oculus Home App (Baseline) and OTT as a multiplier.

I do not know how exactly this gets managed in the software and headset itself but you still get better image quality the higher the final Pixel count is.

Believe me I tested all possible solutions (higher / lower encode resolution & higher / lower pixel resolution) and these are my best results after testing hours of settings.

Edited April 11, 2023 by Tepnox

[Tepnox]

On 4/6/2023 at 3:30 PM, ODBU_Mongoose said:

Hi Tepnox thanks so much! This is one of the few good guides out there for the QuestPro.

Having switched from G2 to Quest Pro meant a huge improvement for me. Just this tweaking for DCS with the USB-C cable is a bif of a hassle. Few questions I have that I was just wondering (sorry no tech guy here)

• So with the OpenXR embedded in the beta of DCS youre saying keep the default super sampling in OTT at 1.0 right? 
• You mention encode resolution 3905. Other forums say for the QP needs 3600 max as this is the max horizontal resolution. Can you explain?
• So OTT is more fore tuning and ODT for checking the settings? Both seem to do kind of the same

But fair to say, its a hugely underappreciated headset. For me its just so much better than the G2. Not losing sight anymore in a dogfigt because of the great contrast and great sweet spot is just awesome. Again, thanks for the settings and Ill keep on following this thread!

Specs to be sure: 13600K, 4080, MSI Z690a, 64GB 3200, Quest Pro connected via USB-C cable 

Keep up the good work!

 

Since OpenXR the DCS VR Supersampling Value is something like a multiplier. Prior to OpenXR with the Oculus Runtime, the DCS VR value would be completeley overwritten with OTT - that is no longer the case.

So: set 1.5x in the Oculus Home Graphics Preferences (this is your baseline resolution) and set 1.0 supersampling inside DCS. Finetune with OTT from 1.0 and upwards to your desired resolution.

I can not recommend lower settings for the encoding resolution. This will have a degrading visual impact on the overall clarity because the encoded image is smaller on lower settings. 3936*2080 pixels encoder resolution: this is combined width + height - so it is 1968*2080 per eye.

ODT just has some more visual hud options (Oculus Link Status for example) that OTT does not have. But in general OTT just overwrites the ODT-settings.

But ODT has also some limitations: for example it is not possible to write more than 500 MBit for the encode bitrate inside of ODT. With OTT you can go up to 960 MBit and this will get accepted by Oculus.

Some people say they don't see a difference between the recommended default 300 Mbit and 500 Mbit. I highly disagree. I can clearly see more blockage and compression artefacts especially with more muddy colors like green and dark grey. We have those colors alot in DCS. So especially on the green grass or grey airfield textures you can see it clearly. I can also still see differences between 500 MBit and 960 Mbit, but much more distinct with darker and muddier colors. This can get subjective from human to human because we all see different and some people are not that prone to compression artefacts.

[slughead]

46 minutes ago, Tepnox said:

The encode resolution describes the capturing resolution the data stream gets before encoding and sending it to the headset via cable.

The higher the encoder resolution the better the overall image at the end when displayed on the headset lenses.

 

 

The encoder width resolution is the width that the source/app (DCS) image is encoded to and sent over the link. It does not set the app (DCS) render resolution. The app image width is set by the graphics preferences in the Oculus app - the "rendering resolution" setting.

Using your analogy, if you have a 480p video signal and encode it to 1080p, you won't get a better-quality image. The encoder may have some upsampling to remove blocks created by multiplying pixels up, but you won't get any more detail than that provided in the original signal. So it's a waste of processing power and bandwidth. You could take a 1080p signal and encode it to 480p. You will lose detail in this case but you will also gain bandwidth in the pipe. Gaining bandwidth is not important unless you are at the limit of the pipe - in which case you could be losing frames. What's more, if your screen is only 480p and you try to display a 1080p image on it, you're still going to see a 480 image. You cannot get more detail from fewer pixels. As the headset resolution is 1800x1920 per eye (3600x1920 approx), encoding to a higher resolution is pointless. It doesn't add detail.

Hence setting the encoding width greater than the render resolution is a waste and will result in encoder fps reduction, audio dropouts, and anything that is sent over the link. Setting the encoding width too high will cause the encoded fps to drop.

The reason you are seeing a better-quality image with a PD of 1.25 is as follows. The Quest Pro native resolution is 1800x1920 per eye. That's a 3600x1920 full image (although that might be an oversimplification). Without changing the PD in ODT, and leaving the Oculus graphics settings at 1.0x / 72Hz, the image is 3616x1840. That's less than the native resolution and hence you are not getting the best out of the headset. The reason this is set lower is so that you achieve 72Hz in the encoding pipe. Note that at 80Hz/1.0x the render resolution is 3456x1744 and at 90Hz/1.0x the recommended resolution is 3264x1648. This is to ensure a margin of headroom to prevent dropped frames. Increasing the PD (pixels per display pixel) multiplies the render resolution. Increasing it to 1.25 at 72Hz (3616x1840) increases the render resolution to 3776x1952 which is now just over the native height of the HMD. So now you are matching the render resolution to the HMD resolution and therefore not losing any detail (as far as can be physically displayed). You can get the same result just by increasing the render resolution in the graphics settings of the Oculus app and not using the ODT.

If you increase PD or render resolution too much, you may start to get audio glitches and frame drops unless you increase the Encode Bitrate. But again, increasing this beyond what is necessary is a waste of processing power once again and there may be a limit based on your USB-C bandwidth and the ability of the headset itself to decode at a higher rate.

If you experience compression artefacts, you may need to increase the bitrate of the encoder. Currently, I find leaving the encoder to default settings is working - currently. It's set to 200mbps/3616x1920 is adequate and the encoder is not dropping below 72Hz. This means I have some headroom to increase the bitrate "should" I need to.

[Tepnox]

1 hour ago, slughead said:

The encoder width resolution is the width that the source/app (DCS) image is encoded to and sent over the link. It does not set the app (DCS) render resolution. The app image width is set by the graphics preferences in the Oculus app - the "rendering resolution" setting.

Using your analogy, if you have a 480p video signal and encode it to 1080p, you won't get a better-quality image. The encoder may have some upsampling to remove blocks created by multiplying pixels up, but you won't get any more detail than that provided in the original signal. So it's a waste of processing power and bandwidth. You could take a 1080p signal and encode it to 480p. You will lose detail in this case but you will also gain bandwidth in the pipe. Gaining bandwidth is not important unless you are at the limit of the pipe - in which case you could be losing frames. What's more, if your screen is only 480p and you try to display a 1080p image on it, you're still going to see a 480 image. You cannot get more detail from fewer pixels. As the headset resolution is 1800x1920 per eye (3600x1920 approx), encoding to a higher resolution is pointless. It doesn't add detail.

Hence setting the encoding width greater than the render resolution is a waste and will result in encoder fps reduction, audio dropouts, and anything that is sent over the link. Setting the encoding width too high will cause the encoded fps to drop.

The reason you are seeing a better-quality image with a PD of 1.25 is as follows. The Quest Pro native resolution is 1800x1920 per eye. That's a 3600x1920 full image (although that might be an oversimplification). Without changing the PD in ODT, and leaving the Oculus graphics settings at 1.0x / 72Hz, the image is 3616x1840. That's less than the native resolution and hence you are not getting the best out of the headset. The reason this is set lower is so that you achieve 72Hz in the encoding pipe. Note that at 80Hz/1.0x the render resolution is 3456x1744 and at 90Hz/1.0x the recommended resolution is 3264x1648. This is to ensure a margin of headroom to prevent dropped frames. Increasing the PD (pixels per display pixel) multiplies the render resolution. Increasing it to 1.25 at 72Hz (3616x1840) increases the render resolution to 3776x1952 which is now just over the native height of the HMD. So now you are matching the render resolution to the HMD resolution and therefore not losing any detail (as far as can be physically displayed). You can get the same result just by increasing the render resolution in the graphics settings of the Oculus app and not using the ODT.

If you increase PD or render resolution too much, you may start to get audio glitches and frame drops unless you increase the Encode Bitrate. But again, increasing this beyond what is necessary is a waste of processing power once again and there may be a limit based on your USB-C bandwidth and the ability of the headset itself to decode at a higher rate.

If you experience compression artefacts, you may need to increase the bitrate of the encoder. Currently, I find leaving the encoder to default settings is working - currently. It's set to 200mbps/3616x1920 is adequate and the encoder is not dropping below 72Hz. This means I have some headroom to increase the bitrate "should" I need to.

Well the point is you can not go higher inside of the Oculus Home App than 5408*2736 (which is 2816x2896 per eye in real). To get a higher pixel count for supersampling you have to use ODT or OTT and set the Supersampling value there. This acts as a multiplier whereas 1.0 would be the baseline (2816x2896 per eye) and gets overridden with the ODT/OTT value. If you set 1.10 in ODT or OTT you will get 2816 times 1.10 and 2896 times 1.10. The mathematical end result in Supersampling resolution is: 3.097,6 * 3.185,6 per eye. The real value inside the headset is 3088*3184 - so there are some round up errors but you can test this for yourself the mathematical way and prove this with the Oculus Performance Pixel Overlay.

Your points for the encoder resolution and native resolution sound reasonable in theory but don't prove in reality. If you say the visual clarity of the image with a pre-set 1800*1920 resolution is the same for you as with a pre-set 3232*3328 resolution via OTT/ODT, I would question your eyesight. Small elements like MFD-text in the F-16 are still blurry with values below 3232*3328 for me - of course this is quite individual but I prefer very crisp readable text. In case of getting higher fps this could be seen as "wasted" performance but I can live perfectly fine with crisp text/cockpit readability and ASW 45 fps than blurry text and the possibility for 90 fps.

I think this also depends on the things you do in DCS. If I would fly in WW2 warplanes and do visual dogfighting all the time I would prefer a lower resolution and target 90 fps at the cost of a less crisp cockpit readability. But I normally fly the F-16 in high altitude with BVR-engagements so instruments and readability are a high focus for me. Also flying the Apache won't get you anything near 90fps with target MFPD and PNVS on - so here I also prefer a stable 45 fps ASW and perfect readability for the MFDs.

Bandwith should also not be a problem - start the performance check with your cable inside the Oculus Home App - you should get around 2.0 Gbit or higher. If you set the encode bandwith to 960 Mbit as I do, you only use 0,96 Gbit of the available 2.0+ Gbit bandwith that is possible with the link cable. So there is more than enough performance headroom left that is still not used. Also the GPU needs to deal with the encoding and this can vary of course for everyone. While having had a RTX3090 I truly got frame-/sound-drops when I would set more than 500 Mbit as encoder bandwith, with the RTX4090 not a problem anymore. 960Mbit encoder bitrate is possible without any drops. So this setting depends on the user hardware of course.

I don't think the bandwith changes with the fps / Hz setting (72/80/90). The encoder setting sets the overall bandwith and thats it. So maybe it is possible that there are more artefacts with 90 Hz than with 72 Hz because if the encoder bandwith is still the same, the image quality should be overall better with lower Hz-settings. I did not test this at all because I simply get headaches/nauseating with 72 or 80 Hz. So another personal matter for everyone ;D

[slughead]

4 minutes ago, Tepnox said:

If you say the visual clarity of the image with a pre-set 1800*1920 resolution is the same for you as with a pre-set 3232*3328 resolution via OTT/ODT

I didn't say that. I said that the default render resolution is below that of the headset. I said anything below the default resolution is going to be lower quality - so that's anything below 3600x1920.

I also said that running the encoder at a resolution width higher than that of the HMD is pointless. Render resolution higher - yes, but not the encoder resolution.

 

11 minutes ago, Tepnox said:

I don't think the bandwith changes with the fps / Hz setting (72/80/90).

I don't believe I said or implied that either.

 

15 minutes ago, Tepnox said:

the image quality should be overall better with lower Hz-settings

The image quality won't change with a lower refresh rate. If you want to include flicker in that then ok. I don't see flicker at 72/80Hz so no headaches for me, but I appreciate that you do. I do at 60Hz in the Reverb G2 though.

 

If you are having no problems with your settings you carry on. I am merely pointing out that it's overkill and that processing power is better spent elsewhere.

[Tepnox]

10 hours ago, slughead said:

I didn't say that. I said that the default render resolution is below that of the headset. I said anything below the default resolution is going to be lower quality - so that's anything below 3600x1920.

I also said that running the encoder at a resolution width higher than that of the HMD is pointless. Render resolution higher - yes, but not the encoder resolution.

 

I don't believe I said or implied that either.

 

The image quality won't change with a lower refresh rate. If you want to include flicker in that then ok. I don't see flicker at 72/80Hz so no headaches for me, but I appreciate that you do. I do at 60Hz in the Reverb G2 though.

 

If you are having no problems with your settings you carry on. I am merely pointing out that it's overkill and that processing power is better spent elsewhere.

I appreciate your feedback but what is the point of your theoretical discussion if you don't even own a Quest 2 / Quest Pro and try to discuss the settings of Oculus Home / OTT itself? I still get a better picture clarity when the encoder resolution is higher than the lenses pixel width itself - I tested it myself. Period. I technically don't know why that is the case but I see no point in arguing with a G2-user who can not test this for hisself.

Good for you if you can live with 72Hz or even 60Hz on the G2 - arguing where the processing power is better spent is highly individual for sure.

[slughead]

17 minutes ago, Tepnox said:

I appreciate your feedback but what is the point of your theoretical discussion if you don't even own a Quest 2 / Quest Pro

Here we go again. Why do you keep misreading or reading what isn't said? I have both a Quest Pro and a Reverb G2. When did I ever say or imply that I don't have a Quest Pro?

18 minutes ago, Tepnox said:

I still get a better picture clarity when the encoder resolution is higher than the lenses pixel width itself - I tested it myself. Period

Oh boy. For the third time.... setting it higher than the HMD resolution won't give you better quality. Setting it lower will reduce quality. It's the render resolution that gives you a better-quality image provided that you don't reduce the encoder resolution to lower than the headset's native resolution.

The point of this discussion stems way back to when you stated what are the "optimum" settings. They're not as I have shown. Optimum is only what is needed to achieve a desired goal, not more, or less.

We are now going around in circles because you misread what I write and imagine what isn't said. I've said enough for other people to have a balanced view of what "optimum" is and how they can improve their headroom for the game and/or improve battery performance in their headset.

I bid you good-day.

[DirtyMike0330]

9 hours ago, slughead said:

Here we go again. Why do you keep misreading or reading what isn't said? I have both a Quest Pro and a Reverb G2. When did I ever say or imply that I don't have a Quest Pro?

Oh boy. For the third time.... setting it higher than the HMD resolution won't give you better quality. Setting it lower will reduce quality. It's the render resolution that gives you a better-quality image provided that you don't reduce the encoder resolution to lower than the headset's native resolution.

The point of this discussion stems way back to when you stated what are the "optimum" settings. They're not as I have shown. Optimum is only what is needed to achieve a desired goal, not more, or less.

We are now going around in circles because you misread what I write and imagine what isn't said. I've said enough for other people to have a balanced view of what "optimum" is and how they can improve their headroom for the game and/or improve battery performance in their headset.

I bid you good-day.

So just to clarify, what are *you* saying would be the ideal encode selection for the attached settings? null

[slughead]

6 minutes ago, DirtyMike0330 said:

So just to clarify, what are *you* saying would be the ideal encode selection for the attached settings? null

For the encoder resolution width.... leave it at default. That will give you 3616x1920 which is just over the HMD native resolution. I would also leave the bitrate at default which for me turns out to be 200Mbps when you use the Performance/Oculus Link "visible HUD" from the Oculus Debug Tool. You could turn the bitrate up if you see artefacts, but you should only adjust it up until they are no longer visible or tolerable. Going higher just uses up processing power both in the PC and the headset.

Regarding your other settings, either set the render resolution to 1.0 and then adjust the PD or set PD to 1.0 and then set the render resolution as needed to balance image quality vs frame rate. They both do the same thing, i.e. increase the render resolution. There is no need to change both.

Personally, I wouldn't set my render resolution to the maximum as you won't see any difference as @Tepnox said earlier. You're just wasting app frame time by setting it too high and losing fps for no good reason.

I have tested this at max render resolution and PD of 1.0. The clarity is perfect, but you will always be in ASW so at 45Hz or lower so always get ghosting. If you can use a lower refresh rate, you are going to stand a better chance of being out of ASW with no ghosting providing you set your render resolution or PD to achieve the optimum image quality.

[DirtyMike0330]

1 hour ago, slughead said:

For the encoder resolution width.... leave it at default. That will give you 3616x1920 which is just over the HMD native resolution. I would also leave the bitrate at default which for me turns out to be 200Mbps when you use the Performance/Oculus Link "visible HUD" from the Oculus Debug Tool. You could turn the bitrate up if you see artefacts, but you should only adjust it up until they are no longer visible or tolerable. Going higher just uses up processing power both in the PC and the headset.

Regarding your other settings, either set the render resolution to 1.0 and then adjust the PD or set PD to 1.0 and then set the render resolution as needed to balance image quality vs frame rate. They both do the same thing, i.e. increase the render resolution. There is no need to change both.

Personally, I wouldn't set my render resolution to the maximum as you won't see any difference as @Tepnox said earlier. You're just wasting app frame time by setting it too high and losing fps for no good reason.

I have tested this at max render resolution and PD of 1.0. The clarity is perfect, but you will always be in ASW so at 45Hz or lower so always get ghosting. If you can use a lower refresh rate, you are going to stand a better chance of being out of ASW with no ghosting providing you set your render resolution or PD to achieve the optimum image quality.

Thanks, I will tinker a little! And just to confirm, when you say PD, you are referring to the super sampling rate in the oculus tools? 

[slughead]

Just now, DirtyMike0330 said:

Thanks, I will tinker a little! And just to confirm, when you say PD, you are referring to the super sampling rate in the oculus tools? 

PD is similar to, if not the same as, supersampling. In the Oculus app when you set render resolution, it's 1.0x, 1.1x, 1.2x etc. That's similar if not the same as a PD of 1.0, 1.1, 1.2 etc. By PD I mean "Pixels Per Display Pixel Override" in the Oculus Debug Tool. So if you set the render resolution greater than 1.0 and set a PD greater than 1.0 you are in essence multiplying the resolution by both values. That's why I suggest only changing one or the other. You can do both, but it is pointless and you have less control over the actual render resolution of the app (DCS).

[minimi66]

I've just invested in a brand new rig, see specs below. Cost the best part of £3500+  Also picked up a Quest Pro having previously had Quest 2, HP Reverb G1, Rift S and Rift CV1.

So far i've been completely unable to achieve anything close to the performance and quality i expected from this new PC and the Quest Pro?  Don't get me wrong, the QP is a massive step up from the Q2 and as a headset upgrade i couldn't be happier.  I have tried pretty much every possible solution and combination of settings but the main issue i am seeing is constant stuttering in game.  Frame rate is always pretty stable at whatever i've set it at, 72, 90 etc.

Tried with and without Virtual Desktop, tried Open XR via the shortcut provided by BIGNEWY recently on the dedicated OpenXR compatibility thread. 

I also have DCS Steam version and all the above applies to that too, in fact performance/quality is much worse on Steam version although i am not at all familiar with optimising SteamVR having mostly used Oculus app for most titles i've run.

In terms of in game settings i've tried all the standard DCS pre-sets and dozens of my own variations.  I've also tried enabling/disabling Windows Game Mode, HAGS, Hyper-Threading, Windows Power service in msconfig etc etc etc....

Using Windows High Performance Power Plan.

Still a complete stutter fest 99% of the time.

With this rig DCS non-VR will run at 150-200 FPS (more on the Multi-thread build) with everything maxed out even in a busy SP mission.  I don't do MP so no idea how that would go?  

I purchased the new rig and Quest Pro specifically to enjoy better DCS VR.

Any help or advice would be greatly appreciated.

Thanks. 

Windows 10 Pro 64-bit

- Intel Core i9-13900K

- 64GB Corsair Vengeance RAM @ 3600 MHz

- ASUS TUF GAMING B660-PLUS WIFI D4

- Zotac NVIDIA GeForce RTX 4090 24GB (using Fasgear USB-C to USB-C Link cable from USB 3.2 Gen 2x2 Type C (up to 20Gbps) port on motherboard)

- 2TB  INTEL NVMe SSD (Windows 10)

- Samsung SSD 970 EVO Plus 1TB (DCS)

- Crucial CT1000 1TB NVMe SSD

- WinWing F-16EX Stick

- WinWing Orion Throttle Base with both F-18 & F-16C TQS Throttle Grips

- Saitek Pro Rudder Pedals

- Logitech G-910 Keyboard

- Logitech G-502 Lightspeed Mouse

- Logitech G-533 Headset

- Occulus Quest Pro VR

- TrackIR 5 with Track Clip Pro

Edited April 14, 2023 by minimi66