Skip to main content
ShowbizDonkey
ShowbizDonkey
Inspiring
November 20, 2020

v24 PTC PC Software Release Notes

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.

    51 replies

    Show previous replies
    Anonymous
    November 21, 2020

    @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.

    TomCgcmfc
    Honored Contributor
    November 22, 2020
    @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.
    i9 13900K water cooled, RTX4090, Z790 MB w/wifi6e, 64Gb 6400 ram, 2x2TB SSD, 1000W PSU, Win 11, QPro, Q3, w/Link and Air Link, Vive Pro1 with 2x2.0 base stations, Etsy lens mod and Index Controllers
    Xarstealth
    Up and Coming
    November 22, 2020
    is this still rift forum section? LOL
    TomCgcmfc
    Honored Contributor
    November 23, 2020

    Xarstealth said:

    is this still rift forum section? LOL


    Sharing the luv, that's all, lol!
    i9 13900K water cooled, RTX4090, Z790 MB w/wifi6e, 64Gb 6400 ram, 2x2TB SSD, 1000W PSU, Win 11, QPro, Q3, w/Link and Air Link, Vive Pro1 with 2x2.0 base stations, Etsy lens mod and Index Controllers
    Anonymous
    November 23, 2020

    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
    DawsITA
    Inspiring
    November 23, 2020

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

    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)
    Quest 2:
    • 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".


    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 (@nalex66 no 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.
    Anonymous
    November 23, 2020
    @daws72 - Great... that's the point (or "the points") to talk about!
    And yes, with Q2@v21 and Desktop@v23PTC the device behaved different.
    This is the exact reason, why Q1@v20 behave like before and Q2@v23 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!

    PattyGar1965
    Up and Coming
    November 28, 2020
    I was having a lot of problems with v23. This update fix a lot of problems for me
    TomCgcmfc
    Honored Contributor
    November 28, 2020

    PattyGar1965 said:

    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?
    i9 13900K water cooled, RTX4090, Z790 MB w/wifi6e, 64Gb 6400 ram, 2x2TB SSD, 1000W PSU, Win 11, QPro, Q3, w/Link and Air Link, Vive Pro1 with 2x2.0 base stations, Etsy lens mod and Index Controllers
    PattyGar1965
    Up and Coming
    November 29, 2020
    I did run repair. I don't have the same computer as you. Maybe that's why I see an improvement. 
    Show more replies
    Terms & ConditionsAccessibility statement