Blog Post
51 Comments
- I've been leaving mine on beta v23 for the last 5 days expecting it to go v23 final (although everything was working fine with my Q1 and Link and my PTC v23 showed up the graphics setting fine). So, I was pretty surprised to see it update to PTC v24.0.0.22.393 today. Anyway, I tested a few Oculus, Steam, and independent (X Plane 11) apps with my Q1/Link and all seems to work fine.
- Things I wish for:
- Less power consumption when Oculus Software is open but headset is idle or Quest in standby
- Quest2 Audio and Microphone stays on when Link is enabled but headset in standby
- Paththrough on Quest while on links should not mute audio and microphone!
All of those are equally important and would improve the experience (and electrical bill) temendously.
CactusCowboy said:
Things I wish for:- Less power consumption when Oculus Software is open but headset is idle or Quest in standby
- Quest2 Audio and Microphone stays on when Link is enabled but headset in standby
- Paththrough on Quest while on links should not mute audio and microphone!
All of those are equally important and would improve the experience (and electrical bill) temendously.
None seem to effect the Q1 so maybe it just needs a Q2 fix.- I'm still seeing black screen issues with Link with a Quest 2 - anyone else also having troubles?
- Same issues here... I plug in the link cable and try to enable Oculus Link it just kept crashing saying “Link available in settings”. Seems to try to start Link then crashes. I'm using the official link cable and have v23 on quest 2 right now
- I'll post this here also, because the problem persist with PTC v24
---
Don't know if this is "by design" or a failure in v23 Desktop-App: static resolution for Link with Quest2!
(the changes in Hz are working flawless, but eye buffer is fixed to 1832x1920)
On wendsday I've received the v23 desktop-app (retail channel)... I've thought, the problem may vanish with it, also existed in v23 PTC. So with the Quest1 everything is fine... resolution change results in a consistant change of the "eye buffer" in the headset (see OVRMetricsTool v1.5.1). Also seen with the great wireless tool VirtualDesktopMobile low/medium/high changes the eye buffer in the HMD and 1:1 in SteamVR. Never seen such a sharp/clean image in SteamVR with the original Quest!
But not so with the Quest 2... OK, VirtualDesktopMobile does the same... with higher resultions compared to Q1 and the additional 60Hz compared to link for Q1/2. Works like a charme, also with 80Hz or 90Hz. But Link doesn't... the eye buffer is fixed to 1832x1920 which itself is nice, because it's the native resolution of the headset. But regardless of what you set in the Desktop App... it stays at that eye buffer and you see only marginal differences. But workload of the graphics card and also latency rising... don't misunderstand: the quality of link is much improved compared to v21 Desktop-App (eye buffer and Link fixed to 1440x1520@72Hz and 2064x2272@72Hz with Quest1), but it could be much better, if you look at the visual results with the original Quest.
On the application side (games etc.), everthing seems right...
On the headset everything seems right (look at VirtualDesktopMobile or SKYBOX for expl.)...
But Link with Desktop-App v23 does "strange things" with the eye buffer on Quest 2 only!
Thank's in advance!
And sorry for my bad english...
:blush:
P.S.: also tried all tests with newly installed os, desktop app and factory resetted quest2... with same results.
Just tried the Oculus-App-Version 24.0.0.22.393 (PTC) - same results.
P.P.S.: switching between PTC and retail (v23 to v24 an back) are much faster now... thx@oculus!
Buetigame said:
I'll post this here also, because the problem persist with PTC v24
---
Don't know if this is "by design" or a failure in v23 Desktop-App: static resolution for Link with Quest2!
(the changes in Hz are working flawless, but eye buffer is fixed to 1832x1920)
On wendsday I've received the v23 desktop-app (retail channel)... I've thought, the problem may vanish with it, also existed in v23 PTC. So with the Quest1 everything is fine... resolution change results in a consistant change of the "eye buffer" in the headset (see OVRMetricsTool v1.5.1). Also seen with the great wireless tool VirtualDesktopMobile low/medium/high changes the eye buffer in the HMD and 1:1 in SteamVR. Never seen such a sharp/clean image in SteamVR with the original Quest!
But not so with the Quest 2... OK, VirtualDesktopMobile does the same... with higher resultions compared to Q1 and the additional 60Hz compared to link for Q1/2. Works like a charme, also with 80Hz or 90Hz. But Link doesn't... the eye buffer is fixed to 1832x1920 which itself is nice, because it's the native resolution of the headset. But regardless of what you set in the Desktop App... it stays at that eye buffer and you see only marginal differences. But workload of the graphics card and also latency rising... don't misunderstand: the quality of link is much improved compared to v21 Desktop-App (eye buffer and Link fixed to 1440x1520@72Hz and 2064x2272@72Hz with Quest1), but it could be much better, if you look at the visual results with the original Quest.
On the application side (games etc.), everthing seems right...
On the headset everything seems right (look at VirtualDesktopMobile or SKYBOX for expl.)...
But Link with Desktop-App v23 does "strange things" with the eye buffer on Quest 2 only!
Thank's in advance!
And sorry for my bad english...
:blush:
P.S.: also tried all tests with newly installed os, desktop app and factory resetted quest2... with same results.
Just tried the Oculus-App-Version 24.0.0.22.393 (PTC) - same results.
P.P.S.: switching between PTC and retail (v23 to v24 an back) are much faster now... thx@oculus!
I think what's happening there is, you're perhaps seeing the encode resolution after compression being reported as the eyebox size on OVRMetricsTool. The image from the game is rendered at the resolution set in the Devices/Quest 2 panel in the PC app, but then during the encoding process, the peripheral parts of the image are compressed to bring the image size to 3664x1920 (3664 is the default encode resolution width for Quest 2). It seems like they're doing all the barrel distortion and image reduction prior to encoding and sending the image to the headset, so the headset just has to decode and display an image sized for the screen resolution.You could verify that by changing the encode resolution width in the debug tool and see if that changes the eyebox size that OVRMetricsTool reports.- @nalex66 Thanks for your always useful tech knowledge. I gotta be honest and say that much of this is beyond what I can understand, lol!
All I can do is monitor a few performance graphs using OTT hud options and of course see if I can visually see any differences. One thing I'd like to know is whether or not the Quest 1 is actually limited to 150mbps bitrate. I have read that this was the case due to its mobile chip limitations. However, when I play around with bitrate I seem to notice a nice improvement visually (clearer with fewer artifacts) when I increase it from 150 to 250, and a little better at 350. It does not seem to effect performance (fps) so for now I've just left it at max = 500mbps. I'm starting to wonder if the bitrate limitation with Link is more dependent on your GPU (1080ti in my case). Are there any simple to use tools to actually verify this or not? Thanks mate.
nalex66 said:
Buetigame said:
I think what's happening there is, you're perhaps seeing the encode resolution after compression being reported as the eyebox size on OVRMetricsTool. The image from the game is rendered at the resolution set in the Devices/Quest 2 panel in the PC app, but then during the encoding process, the peripheral parts of the image are compressed to bring the image size to 3664x1920 (3664 is the default encode resolution width for Quest 2). It seems like they're doing all the barrel distortion and image reduction prior to encoding and sending the image to the headset, so the headset just has to decode and display an image sized for the screen resolution.You could verify that by changing the encode resolution width in the debug tool and see if that changes the eyebox size that OVRMetricsTool reports.
@nalex66 Nice to see that there is someone out there who understands the circumstances...
Your are totally right... a change to encode resolution witdh with ODT, changes the eye buffer 1:1.
But the behaviour, you've noted makes no sense to the fact, that with the the Quest1 everyting works like it shoud. Also VirtualDesktopMobile does this "right"... sending the rendering resoultion direktly to the Quest 1&2, so the only thing to do on the device is a downsampling... beside the decoding of course. And both, XR1.5 and XR2, doing this very good!
Look at these examples for Quest 2:- native Home 1440x1584@90Hz (i.e. 2880x1584 of course ;-)
- SKYBOX VR 2160x2376@72Hz
- Amazon Prime VR: 2116x2218@72Hz - 1728x1901@72Hz (lights off)
- YouTube SKYBOX VR: 2116x2218@60Hz
Quest 1:- 3104x1712@72Hz > 1568x1728@72Hz > 1568x1728@72Hz (0.9)
- 3616x2000@72Hz > 1808x2000@72Hz > 1808x2000@72Hz (1.0)
- 4128x2272@72Hz > 2064x2272@72Hz > 2064x2272@72Hz (1.1)
- 3696x1872@90Hz > 1832x1920@90Hz > 1856x1872@90Hz (1.0 for 90Hz)
- 3920x1984@80Hz > 1832x1920@80Hz > 1968x1984@80Hz (1.0 for 80Hz)
- 4128x2096@72Hz > 1832x1920@72Hz > 2064x2096@72Hz (1.0 for 72Hz)
Do you know, what I mean?
The higher the frequency, the lower the resolution.
This only makes sense, if you try to adjust the amount of tranferred data to the device...
Keeping the redering load on the PC on the same level if you change the frequency? No... makes no sense.
Reducing the amount of data when lowering the frequency? Maybe... but why with Q2 and not with Q1?
And keep in mind: Virtual Desktop Mobile does everything right - you'll see it with your eyes.
(designed to be used wireless in battery mode only)With all this in mind, the circumstances speak for themselves... this must be a bug.
Why shoul I reduce the workload on the much more powerful device?
(while it's wired and charged when in use!)
The most bad thing about this: it reduces visual quality!
Very strange and hopefully can be "fixed".
