Quest Pro - VirtualDesktopXR and Quadviews

[VR Flight Guy in PJ Pants]

12 hours ago, gonvise said:

Regarding VD local dimming, it is better than the one activated in the quest pro? Because despite what you say, the one activated in the developer options of the quest pro works for me in DCS. The blacks when loading are "almost" black, and the cursor does not shine like before v51, which is when they added local dimming. The night missions aren't perfect, but much better than with local dimming option disabled. Or I am missing something (which could be the case), because as I said, I have never stopped "noticing" that I have local dimming in DCS, or you have not tried the local dimming that is in the developer options. Could it be?

May be it was me!

I have enabled local dimming (LD) in the headset, I can only find this in the non-Link, experimental features section. If what I got was correct, this has no effect in PCVR, and my video may prove that. I checked the PC Oculus application (or Meta if one prefers), I have Developer mode turned on, but, iirc, there was no LD option there. Please kindly let us know where to turn on LD for PCVR under Airlink/Link.

(And below is about QVFR)

I find the “sharpening” setting in VD may have something to do with the lack of distinction between “sweet spot” and what not. My video was in 0.5 so the “sweet spot” was quite blurry, the HUD reading demonstrated this issue as blurry + blurry = blurry. I changed the sharpening to full, and the distinction was clearer, no pun intended. But I still has to look for it.

i think I better remake the comparison video, probably into 2, one for LD without any QVFR and the other is for QVFR only. The current one is not very up-to-date.

Edited July 27, 2024 by VR Flight Guy in PJ Pants

[Qcumber]

5 hours ago, gonvise said:

If "godlike" is not enough and you want more quality, it would be a matter of increasing the DCS PD or the central part multiplier of QVFR. But in my opinion, the problem with this is that in the end you are burdened by the 150Mbs of Hvec-10, or if you put h264+ then 400Mbs, but it is still far from the 900Mbs that you can put via cable link.
In short, I think that no matter how much you increase the scaling from the "god like" via DCS PD or QVFR, the encoding bitrate will not allow you to perceive the improvement in clarity as you should.
I insist, the quest pro "shine" with a 2.0 scaling, encode resolution 3905 and encode bitrate 960 via cable link (OTT), so the first thing I would do is test this to have a reference, then each one has his own eyes and expectations  

 

I agree that meta still has the edge with the encoding. However, the issue is that meta keeps breaking for DCS. V68 does not work with QVFR. With each version if VD the quality gets closer to meta cable.

To compare VD and meta cable you need to do a like for like comparison. I have previously spent a lot of time comparing each at the same resolution and with the same QVFR settings. The image quality difference is very subtle but in favour of meta. However, there are other factors to consider. VD is better optimised for QVFR and this is likely to get better still. Meta used to have better motion reproduction but on my last test (2 days ago) VD is now about equal. VD works with turbo mode but this causes meta to crash (at least for me and others on this forum). 

If meta worked consistently and there was evidence of continued support and development for pc games, then I would be happy. Unfortunately this does not appear to be on their agenda. Once the v68 issue is resolved I will do another like for like comparison but until then I will stick with VD. 

For a long term solution I think VD will be the only sensible option. I just wish meta would allow access to cable link so that VD could have this option. 

[Qcumber]

2 hours ago, VR Flight Guy in PJ Pants said:

I find the “sharpening” setting in VD may have something to do with the lack of distinction between “sweet spot” and what not. My video was in 0.5 so the “sweet spot” was quite blurry, the HUD reading demonstrated this issue as blurry + blurry = blurry. I changed the sharpening to full, and the distinction was clearer, no pun intended. But I still has to look for it.

Good point. Another thing to consider is link sharpening. Set at the default settings it is way too sharp. I find that off or quality setting works best. This might make meta look artificially "better" than VD. This also depends on AA method. MSAA needs less sharpening, DLAA/DLSS needs more, a lot more. 

For the best comparison turn off meta sharpening and apply the same sharpening for both meta and VD. For example in game at 0.5. 

Edited July 27, 2024 by Qcumber

[VR Flight Guy in PJ Pants]

I have a bit -ve view on DLSS since it makes the office less sharp (see I am a kind person), also ghosting and images trail. I use MSAA in actual play but DLSS for benchmarks, so compensate performance issues

[Phantom711]

vor 2 Stunden schrieb Qcumber:

VD works with turbo mode but this causes meta to crash (at least for me and others on this forum). 

For me it is the other way around. Had some severe rubber banding with VD and Turbo mode, whereas it works without issues for me on QuestLink and even ASW on.

One can enable local dimming in ODT and probably also OTT (haven‘t checked though).

Edited July 27, 2024 by Phantom711

[Qcumber]

29 minutes ago, Phantom711 said:

For me it is the other way around. Had some severe rubber banding with VD and Turbo mode, whereas it works without issues for me on QuestLink and even ASW on.

LOL. And that's why it is so difficult to share settings.

[gonvise]

8 hours ago, sze5003 said:

Those are the exact settings I use with oculus link except 500 bitrate because 900 gives me audio stutter and I don’t want to wear extra headphones. I figured a 13900k and 4090 would be ok to drive that bitrate but I suppose it also depends on the encoding chip you get in the headset. If quad views is working as it was before on link cable without the hourglass pauses or stutter then i will be happy with how it looks.

I used to have the same audio stutters problem with that bitrate, but it was fixed starting with v62. Now I don't have any audio stutters. Considering I have a 10900K (worse than yours) and a 4090 (same), give it a try  

7 hours ago, VR Flight Guy in PJ Pants said:

May be it was me!

I have enabled local dimming (LD) in the headset, I can only find this in the non-Link, experimental features section. If what I got was correct, this has no effect in PCVR, and my video may prove that. I checked the PC Oculus application (or Meta if one prefers), I have Developer mode turned on, but, iirc, there was no LD option there. Please kindly let us know where to turn on LD for PCVR under Airlink/Link.

(And below is about QVFR)

I find the “sharpening” setting in VD may have something to do with the lack of distinction between “sweet spot” and what not. My video was in 0.5 so the “sweet spot” was quite blurry, the HUD reading demonstrated this issue as blurry + blurry = blurry. I changed the sharpening to full, and the distinction was clearer, no pun intended. But I still has to look for it.

i think I better remake the comparison video, probably into 2, one for LD without any QVFR and the other is for QVFR only. The current one is not very up-to-date.

 

No, I think it's just me . I've tried with and without local dimming, enabling and disabling it from both the experimental menu and the OTT, and testing the F18 Carrier Case III's night mission, but I can't tell the difference. However, I put ASW fluidity and link cable scaling first, I've tried the VD's local dimming and I wouldn't change the other things to have local dimming, although maybe it's because I have the gamma at 1.7, otherwise the nights would seem like a party

5 hours ago, Qcumber said:

I agree that meta still has the edge with the encoding. However, the issue is that meta keeps breaking for DCS. V68 does not work with QVFR. With each version if VD the quality gets closer to meta cable.

To compare VD and meta cable you need to do a like for like comparison. I have previously spent a lot of time comparing each at the same resolution and with the same QVFR settings. The image quality difference is very subtle but in favour of meta. However, there are other factors to consider. VD is better optimised for QVFR and this is likely to get better still. Meta used to have better motion reproduction but on my last test (2 days ago) VD is now about equal. VD works with turbo mode but this causes meta to crash (at least for me and others on this forum). 

If meta worked consistently and there was evidence of continued support and development for pc games, then I would be happy. Unfortunately this does not appear to be on their agenda. Once the v68 issue is resolved I will do another like for like comparison but until then I will stick with VD. 

For a long term solution I think VD will be the only sensible option. I just wish meta would allow access to cable link so that VD could have this option. 

I agree that with each update of [x], where x is [quest pro, quest app, DCS], we may stop having one thing or another, but in the case of v68, the first thing is that it is PTC, we will see when the stable version comes out, and according to what I have read in several posts, what stops working is mbucchia's toolkit, not QVFR.
On the other hand, I think I read in this same thread that mbucchia himself answers that VD has problems implementing QVFR and currently they do not know if they will be able to or not.
And as for the difference between ASW and SSW, please tell me what to do! with ASW and 45FPS relaxed, the head turn is a delight, practically like in real life, totally fluid, but with the same conditions in VD with SSW, in said turns the sky/terrain jumps more than a frog

Edited July 27, 2024 by gonvise

[sze5003]

From what I understand, v68 has issues with DCS if you have openXR/toolkit installed and enabled. I don’t use it so I should uninstall it. I’m on v64 still on my quest pro. I turned off automatic updates in settings when last time it was broken for a while in DCS. 

I am going to try the 960 bitrate again to see if I get audio stutters. I usually run super sampling 2.0 via oculus debug tool with quad views, DLAA and DLSS Quality with the latest nvidia DLSS dll toggled via OVGME.

I am still waiting for a company to make a headset of similar size to the Pro, decent FOV, decent resolution and eye tracking but with Display port. Seems like pimax missed the opportunity not including eye tracking in the Crystal light but I feel like they would be shooting themselves in the foot if they did that.

[Qcumber]

2 hours ago, gonvise said:

in the case of v68, the first thing is that it is PTC, we will see when the stable version comes out

That's a good point. Maybe I should just roll back and wait. 

2 hours ago, gonvise said:

And as for the difference between ASW and SSW, please tell me what to do! with ASW and 45FPS relaxed, the head turn is a delight, practically like in real life, totally fluid, but with the same conditions in VD with SSW, in said turns the sky/terrain jumps more than a frog

I would agree that SSW has had the issue that when rolling there was a horrible jumping and ghosting. However, when I tried again earlier this week I did not see this so I had presumed SSW had been updates. I can't see anything in the logs though, a maybe it's something has changed in DCS or something I've done!?

I run at 72Hz and SSW set to auto. This is a nice balance so that most situations I have a steady 72 FPS and it only drops when I am low over a city or similar. In high altitude combat I get a fluid 72 FPS with none of the movement artefacts of motion reproduction. Low over a city I have smooth ground movement. It's not perfect as there are some jitters in the transition. 

ASW is great until your FPS drops below 36 fps (or 45 if you are running at 90), then it is a stutterfest. VD is better at this.

ASW also allows you to keyboard toggle through the different modes (via OTT) but VD only allows this via the menu.

ASW kicks in as soon as the fps drops below 36/45 but SSW appears to have a more dynamic process so is not constantly switching. 

I would love to see some significant improvements in both ASW and SSW but not sure what priority is being given by meta or VD. 

19 minutes ago, sze5003 said:

From what I understand, v68 has issues with DCS if you have openXR/toolkit installed and enabled

QVFR also appears to break v68.

20 minutes ago, sze5003 said:

I am still waiting for a company to make a headset of similar size to the Pro, decent FOV, decent resolution and eye tracking but with Display port

You are not the only one. However, I don't think this is part of Meta's agenda. They want standalone headsets.

We really do need an affordable DP headset with eye tracking. 

[Qcumber]

2 hours ago, gonvise said:

On the other hand, I think I read in this same thread that mbucchia himself answers that VD has problems implementing QVFR and currently they do not know if they will be able to or not.

Yes. But I understand that this is more a case of integrating QVFR into VD rather than VD being able to utilize QVFR as a separate tool. Please could I ask @mbucchia to comment to make sure I have this right? 

[Phantom711]

vor 3 Stunden schrieb gonvise:

but with the same conditions in VD with SSW, in said turns the sky/terrain jumps more than a frog

Try turning Turbo mode off if you have it selected in either OXRTK or QVFR.

 

vor 16 Minuten schrieb Qcumber:

Yes. But I understand that this is more a case of integrating QVFR into VD rather than VD being able to utilize QVFR as a separate tool.

Yes, I think you got this right. What mbucchia said was about NATIVELY implementing QVFR into VD.

[mbucchia]

48 minutes ago, Qcumber said:

QVFR also appears to break v68.

It's the same reason, QVFR, OpenXR-Toolkit and even a few mods not developed by me (OXRMC, HTCC) will break on v68 due to Meta's bug. Meta is breaking something fundamental that many OpenXR API layers use.

I've reported the issue 1 week ago directly to the devs on the OpenXR chat. They haven't acknowledged my message 

24 minutes ago, Phantom711 said:

Yes, I think you got this right. What mbucchia said was about NATIVELY implementing QVFR into VD.

Correct. I'll be checking on the status of this soon, and otherwise try a workaround. 

[gonvise]

Disabling Quest pro automatic updates in 3-2-1...

[slughead]

9 minutes ago, gonvise said:

Disabling Quest pro automatic updates in 3-2-1...

The only way to prevent automatic updates of the meta link software is to rename the staging and temp folders and then create a staging and temp file in their place. The disable auto updates switch only applies to the apps and games that get installed in the headset.

[sze5003]

Should I be on v67 for best results? If not I will stay on v64. I shut down all oculus services in task manager if I am not flying. Leaving them running in the background I noticed causes my other full screen games to get minimized or go out of full screen. It was driving me crazy trying to figure out why that was happening and it all stopped when I shut down OVR and Oculus server, and other Oculus services running in the background when the pc boots up.

[slughead]

V67 was ok for me.

[gonvise]

v67 without problem, with toolkit eye tracking and last DCS update the best experience for me until now. 

[sze5003]

Thanks. Glad to be back to the same performance I had months ago. I'm sticking with link cable 500 bit rate as 960 still caused audio cutouts.

[gonvise]

22 hours ago, slughead said:

The only way to prevent automatic updates of the meta link software is to rename the staging and temp folders and then create a staging and temp file in their place. The disable auto updates switch only applies to the apps and games that get installed in the headset.

Hi, you're right about that the disable auto updates switches inside helmet only applies to the apps and games that get installed in the headset. But I don't know what you mean by renaming the directories, I have the SO updates disabled via Sidequest -> File explorer+ -> Oculus OS Updated Disable. It works because when I go to the updates screen the icon searching for updates appears indefinitely.

 

[slughead]

Under C:\Program Files\Oculus there is a Staging and sometimes a tmp folder.

1. Rename the Staging folder to Staging.bak
2. Rename the tmp folder to tmp.bak
3. Create a new file called Staging (you can create a new txt file called Staging.txt then rename it to Staging)
4. Create a new file called tmp.

By creating files to replace the folders, the Oculus updater can no longer copy the download file to the staging folder because it's now a file. Hence, this blocks your Oculus / Meta Link application from being updated.

Reverse the changes to allow updates again.

This only stops the app on the PC from being updated. It doesn't stop the headset OS update from happening (which "could" be incompatible with the PC app should the versions not match).

I also make a copy of a good working Oculus folder, e.g. Oculus to Oculus.v67 so I can quickly revert if I need to.

[gonvise]

4 minutes ago, slughead said:

Under C:\Program Files\Oculus there is a Staging and sometimes a tmp folder.

1. Rename the Staging folder to Staging.bak
2. Rename the tmp folder to tmp.bak
3. Create a new file called Staging (you can create a new txt file called Staging.txt then rename it to Staging)
4. Create a new file called tmp.

By creating files to replace the folders, the Oculus updater can no longer copy the download file to the staging folder because it's now a file. Hence, this blocks your Oculus / Meta Link application from being updated.

Reverse the changes to allow updates again.

This only stops the app on the PC from being updated. It doesn't stop the headset OS update from happening (which "could" be incompatible with the PC app should the versions not match).

I also make a copy of a good working Oculus folder, e.g. Oculus to Oculus.v67 so I can quickly revert if I need to.

I've always thought the windows app was backwards compatible with the different Quest firmware versions, but who knows, I'll do that too, thanks.

[slughead]

12 minutes ago, gonvise said:

I've always thought the windows app was backwards compatible with the different Quest firmware versions, but who knows, I'll do that too, thanks.

Maybe backwards... but not necessarily forwards. So, if your headset updates and not the PC app, they may not work together.

[gonvise]

55 minutes ago, slughead said:

Maybe backwards... but not necessarily forwards. So, if your headset updates and not the PC app, they may not work together.

For me the important now is quest pro is not updated to v68 after stable release, since toolkit/eye tracking works like a dream for me in this momment. However, I hope they fix the current toolkit bug with v68 PTC.

Firmware/SO quest pro disable update -> https://www.youtube.com/watch?v=1qAGmqXrOG0&t=1s

Windows quest link app disable update -> 

 

Edited July 28, 2024 by gonvise

[slughead]

Yeah I did the same. But I’m also in the process of switching to virtual desktop as this has happened a number of times now (meta breaking dcs).

[gonvise]

15 minutes ago, slughead said:

Yeah I did the same. But I’m also in the process of switching to virtual desktop as this has happened a number of times now (meta breaking dcs).

Unfortunately, at the moment I cannot achieve the quality and fluidity of the cable link with VD.