New to the forums? Click here to read the "How To" Guide.

Developer? Click here to go to the Developer Forums.

v24 PTC PC Software Release Notes

ShowbizDonkeyShowbizDonkey Posts: 306 Oculus Staff
Oculus Link
  • Fixed numerous black screen issues that could prevent you from being able to use Oculus Link.
  • Fixed an issue where the new graphics settings in the Oculus desktop app weren’t showing for some people.

Comments

  • TomCgcmfcTomCgcmfc Posts: 3,100 Valuable Player
    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.

    Custom built gaming desktop; i9 9900k (water cooled) oc to 5ghz, gtx 1080 ti, 32 gb 3000hz ram, 1 tb ssd, 4 tb hdd.  Asus  ROG Maximus xi hero wifi mb, StarTech 4 port/4 controller sata powered usb3.0 pcie card, PCI-E PCI Express to USB 3.1 Gen 2 card, Asus VG248QE 1080p 144hz gaming monitor, Oculus Rift cv1 w/2x sensors, Vive Pro w/2.0 base stations/controllers, Quest 1 w/Link and VD wireless (good/close 5Ghz wifi and PC with Ethernet cable to my Router).

  • CactusCowboyCactusCowboy Posts: 5
    Brain Burst
    edited November 20
    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.

  • TomCgcmfcTomCgcmfc Posts: 3,100 Valuable Player
    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.

    Custom built gaming desktop; i9 9900k (water cooled) oc to 5ghz, gtx 1080 ti, 32 gb 3000hz ram, 1 tb ssd, 4 tb hdd.  Asus  ROG Maximus xi hero wifi mb, StarTech 4 port/4 controller sata powered usb3.0 pcie card, PCI-E PCI Express to USB 3.1 Gen 2 card, Asus VG248QE 1080p 144hz gaming monitor, Oculus Rift cv1 w/2x sensors, Vive Pro w/2.0 base stations/controllers, Quest 1 w/Link and VD wireless (good/close 5Ghz wifi and PC with Ethernet cable to my Router).

  • Mr_JohnMr_John Posts: 1
    NerveGear
    I'm still seeing black screen issues with Link with a Quest 2 - anyone else also having troubles?
  • rKaiserPrKaiserP Posts: 1
    NerveGear
    please anyone reply and help me i cant use the oculus link because it keeps saying there is a recommended update for the link software and to go to the about section and update but there is no update:((((((((((((((
  • Reaper0fVRReaper0fVR Posts: 1
    NerveGear
    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
  • BuetigameBuetigame Posts: 17
    Brain Burst
    edited November 20
    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 [email protected] and [email protected] 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... [email protected]!
  • nalex66nalex66 Posts: 6,269 Volunteer Moderator
    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 [email protected] and [email protected] 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... [email protected]!
    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.
    i7 5820K @ 4.25GHz | EVGA GTX 1080 SC | Gigabyte GA-X99-UD4 | Corsair DDR4 3000 32GB | Corsair HX 750W
    SSDs: Intel 660p M.2 2TB, Samsung 860 Evo 1TB, 850 Evo 1TB, 840 Evo 1TB | Startech 4 controller PCIe USB 3.0
  • TomCgcmfcTomCgcmfc Posts: 3,100 Valuable Player
    @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.

    Custom built gaming desktop; i9 9900k (water cooled) oc to 5ghz, gtx 1080 ti, 32 gb 3000hz ram, 1 tb ssd, 4 tb hdd.  Asus  ROG Maximus xi hero wifi mb, StarTech 4 port/4 controller sata powered usb3.0 pcie card, PCI-E PCI Express to USB 3.1 Gen 2 card, Asus VG248QE 1080p 144hz gaming monitor, Oculus Rift cv1 w/2x sensors, Vive Pro w/2.0 base stations/controllers, Quest 1 w/Link and VD wireless (good/close 5Ghz wifi and PC with Ethernet cable to my Router).

  • BuetigameBuetigame Posts: 17
    Brain Burst
    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:
    And now look at Link... AppRes vs. EB (eye buffer) vs. SteamVR

    Quest 1:
    Quest 2:
    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".
  • BuetigameBuetigame Posts: 17
    Brain Burst

    @nalex66 Sorry but this makes no sense.
    (writing this again because the original post vanished)

    They try to lower the workload on the device, which is much more powerful than it's predecessor?
    The devices only decode the bitstream and do up-/downsampling to the native resolution.
    No need do any rendering or such...

    In short for the two devices based on XR1.5 and XR2.

    Quest 1 fixed at 72Hz

    • DesktopApp > EyeBuffer/SteamVR
    • 3104 x 1712 > 1568 x 1728 (0.9)
    • 3616 x 2000 > 1808 x 2000 (1.0)
    • 4128 x 2272 > 2064 x 2272 (1.1)
    • 4708 x 2592 > 2368 x 2592 (1.2)
    • 5408 x 2976 > 2704 x 2976 (1.3) 

    Quest 2 with fixed EyeBuffer at 1832x1920

    • DesktopApp > SteamVR
    • 3696 x 1872 > 1856 x 1872 (1.0 @90Hz)
    • 3920 x 1984 > 1968 x 1984 (1.0 @80Hz)
    • 4128 x 2096 > 2064 x 2096 (1.0 @72Hz) 

    The higher the frequency, the lower the resolution.
    In order to keep the workload the same for the PC? Why?
    In order to reduce the transmitted data to the device? Maybe... but why for Q2 and not Q1?

    Most bad about this: It results in a markable loss of visual quality.
    And it doesn't reduce the workoad to the PC which have to do all the work for rendering at (very) high resolutions.

    Now look at Virtual Desktop Mobile.

    Quest 1 with Home at 1216 x 1344 @ 60/72Hz (1:1 for  AppRes/EyeBuffer/SteamVR)

    • 1536 x 1728 = low
    • 1824 x 2016 = medium
    • 2208 x 2400 = high

    Quest 2 with Home at 1880 x 1970 @ 60/72/80/90Hz (1:1 for  AppRes/EyeBuffer/SteamVR)

    • 1728 x 1824 = low
    • 2016 x 2112 = medium
    • 2496 x 2592 = high

    If you put all of this together: this must be a bug!
    Hopefully they'll fix this soon.

  • TomCgcmfcTomCgcmfc Posts: 3,100 Valuable Player
    @Buetigame Nice analysis.  All above my pay grade but it certainly looks like while Oculus is gifting the choice of 72/80/90Hz refresh rates for the Q2 with Link, they appear to force a drop in resolution as the the refresh rate is increased.  Maybe this is to help maintain performance and battery life?  Who knows?  It would be nice if an Oculus tech guy would chime in and explain all this.

    Custom built gaming desktop; i9 9900k (water cooled) oc to 5ghz, gtx 1080 ti, 32 gb 3000hz ram, 1 tb ssd, 4 tb hdd.  Asus  ROG Maximus xi hero wifi mb, StarTech 4 port/4 controller sata powered usb3.0 pcie card, PCI-E PCI Express to USB 3.1 Gen 2 card, Asus VG248QE 1080p 144hz gaming monitor, Oculus Rift cv1 w/2x sensors, Vive Pro w/2.0 base stations/controllers, Quest 1 w/Link and VD wireless (good/close 5Ghz wifi and PC with Ethernet cable to my Router).

  • XarstealthXarstealth Posts: 62
    Hiro Protagonist
    is this still rift forum section? LOL
  • TomCgcmfcTomCgcmfc Posts: 3,100 Valuable Player
    is this still rift forum section? LOL
    Sharing the luv, that's all, lol!

    Custom built gaming desktop; i9 9900k (water cooled) oc to 5ghz, gtx 1080 ti, 32 gb 3000hz ram, 1 tb ssd, 4 tb hdd.  Asus  ROG Maximus xi hero wifi mb, StarTech 4 port/4 controller sata powered usb3.0 pcie card, PCI-E PCI Express to USB 3.1 Gen 2 card, Asus VG248QE 1080p 144hz gaming monitor, Oculus Rift cv1 w/2x sensors, Vive Pro w/2.0 base stations/controllers, Quest 1 w/Link and VD wireless (good/close 5Ghz wifi and PC with Ethernet cable to my Router).

  • BuetigameBuetigame Posts: 17
    Brain Burst
    edited November 22
    TomCgcmfc said:
    @Buetigame Nice analysis.  All above my pay grade but it certainly looks like while Oculus is gifting the choice of 72/80/90Hz refresh rates for the Q2 with Link, they appear to force a drop in resolution as the the refresh rate is increased.  Maybe this is to help maintain performance and battery life?  Who knows?  It would be nice if an Oculus tech guy would chime in and explain all this.
    That would be great... really!

    Yes it seems, there are some performance related implementations to the Quest2.
    Sadly, you can't find any specific information about that.

    P.S.: both Posts are there now... the vanished one and also the last... terrific
  • daws72daws72 Posts: 30
    Brain Burst
    Buetigame said:
    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:
    And now look at Link... AppRes vs. EB (eye buffer) vs. SteamVR

    Quest 1:
    Quest 2:
    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".
    I understand your concern, and I saw what you mean. Indeed when Quest2 was in V21 and desktop was in V23 the eye buffer changes based on what the desktop client slider changes.
    So this suddenly changes in Q2 V23 linked to desktop V23, with the ability to use the 90hz.

    So I can tell: we don't know what actually changed in the internal Q2 v23 rendering process.

    Internally the Q2 do a AADT rectification, apply ATW, apply barrell distortion (@nalex66no way the barrel distortion will be done on PC side, you'll totally loose the benefit of ATW).
    I think due to the need of 90Hz mode they change something in the internal process, I remember something related to sincronizzation of the sx and dx part of the display to avoid flickering, so what probably OVR metrics show now is the end result of this process: the pixel size of the Q2 display, we don't really know.

    The Q1 is different, it still on 72hz so this "extra magic code" is not needed.
    Same for VD, it's actually a Quest app, and it uses different pre-post distortion technique, and internally you can set what you want as Eye Buffer.

    So I think this "missing" OVR metric eye butffer values, is not a bug, as in V23 Q2/PC  the final image quality is really improved, and on par if not better than VD in HIGH.
  • BuetigameBuetigame Posts: 17
    Brain Burst
    edited November 23
    @daws72 - Great... that's the point (or "the points") to talk about!
    And yes, with [email protected] and [email protected] the device behaved different.
    This is the exact reason, why [email protected] behave like before and [email protected] don't.

    So the firmware with "the magic code" within the rendering pipeline is the main problem.
    I'll get in research to AADT, ATW & barrel distortion and come back to this later.

    Really thank you so much for your supply!

  • PattyGar1965PattyGar1965 Posts: 30
    Brain Burst
    I was having a lot of problems with v23. This update fix a lot of problems for me
  • TomCgcmfcTomCgcmfc Posts: 3,100 Valuable Player
    I was having a lot of problems with v23. This update fix a lot of problems for me
    Running a simple Repair with v23 may have done the same.  I personally did not see any improvements with v24 ptc so I unchecked the beta box and rolled back to v23.  For some reason it now works better than ever.  Go figure?

    Custom built gaming desktop; i9 9900k (water cooled) oc to 5ghz, gtx 1080 ti, 32 gb 3000hz ram, 1 tb ssd, 4 tb hdd.  Asus  ROG Maximus xi hero wifi mb, StarTech 4 port/4 controller sata powered usb3.0 pcie card, PCI-E PCI Express to USB 3.1 Gen 2 card, Asus VG248QE 1080p 144hz gaming monitor, Oculus Rift cv1 w/2x sensors, Vive Pro w/2.0 base stations/controllers, Quest 1 w/Link and VD wireless (good/close 5Ghz wifi and PC with Ethernet cable to my Router).

  • PattyGar1965PattyGar1965 Posts: 30
    Brain Burst
    edited November 29
    I did run repair. I don't have the same computer as you. Maybe that's why I see an improvement. 
Sign In or Register to comment.