Announcement

Collapse
No announcement yet.

Significant Changes Coming To VR Resolution Settings in 4.19

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

    Significant Changes Coming To VR Resolution Settings in 4.19

    In the upcoming 4.19 release of Unreal Engine(UE4), the cvar used to set the resolution at which your UE4 Virtual Reality(VR) project will be rendered has been changed. While this new change streamlines adjusting the resolution of your VR project across all of the VR platforms UE4 supports, it will, unfortunately, break backward compatibility with all previous UE4 VR projects. Here’s how this will affect your VR projects and what you can do to fix any performance regressions that this change will cause when upgrading to 4.19.

    Determining HMD Resolution in 4.18 and Previous Versions

    In previous versions of UE4, the Screen Percentage cvar (r.ScreenPercentage) was used to determine the resolution that the engine should render your VR project at for a given HMD screen. While this was a valid way to control the resolution of your VR project it took some guesswork to figure out which number you needed to use as each HMD required a different Screen Percentage amount. The reason for this is because the r.ScreenPercentage cvar was controlling the rendering resolution using a percentage according to the display panel resolution and not the ideal resolution for the HMD. For more information on why we chose this method, see this presentation from VR and AR Technical Director Nick Whiting.

    Since each supported HMD has a slightly different panel resolution and distortion function, settings for r.ScreenPercentage would need to vary device by device. This means that while one value would work for one HMD, the same value used on other HMDs would not look as good.

    Setting HMD Resolution in 4.19 and Beyond

    To make things easier, we’ve added a new cvar to 4.19 called vr.PixelDensity that can be controlled with a normalized value where 1 is the ideal resolution for the HMD that is currently being used. Lower values will perform faster but will be undersampled (more blurry) while values over 1 will perform slower and will supersample (extra sharp). Going forward, you should always use vr.PixelDensity to adjust the resolution given to the HMD compositor for your VR project and always set your r.ScreenPercentage to 100. The following table shows examples of what the previous r.ScreenPercentage values to run the various HMD at it's ideal resolution would be when converted into the new vr.PixelDensity cvar.





    Notice that all the HMD's have their vr.PixelDensity value set to a value of 1, telling each HMD to run at its ideal resolution. Another added benefit to using vr.PixelDensity is that you can also easily increase or decrease the resolution of your VR project using values that make logical sense.

    Number of pixel drawn = 2 x HMD's ideal width x HMD's ideal height x (vr.PixelDensity)²




    For example, if you wanted to reduce the number of pixels to render of your VR project by about 20% you would set vr.PixelDensity=sqrt(1-0.2). If you wanted to increase the number of pixels to render of your VR project by about 20%, you would input vr.PixelDensity=sqrt(1+0.2).

    Moving from r.ScreenPercentage to vr.PixelDensity

    If you have developed any code that adjusts the r.ScreenPercentage cvar, make sure that it instead uses vr.PixelDensity and that the r.ScreenPercentage cvar is set back to its default value of 100 to avoid any potential performance issues when upgrading to 4.19 or subsequent versions. Failing to replace any reference to the r.ScreenPercentage cvar with the vr.PixelDensity cvar will result in a severe performance drop in your project since you could end up rendering more pixels than needed (and nobody wants that!)

    When making this change, keep in mind that defaulted vr.PixelDensity=1 specifies a resolution that is larger than 4.18's r.ScreenPercentage=100, so make sure to do extensive performance testing. Below you will find a few examples of the various ways to make this change in your UE4 projects.

    Blueprint Setup:



    INI Setup:



    Questions about the change? Let us know!
    Last edited by Chance Ivey; 12-20-2017, 03:48 PM.
    Let's Connect [Twitter]

    #2
    How is this intended to be used with the upcoming temporal AA upsampling? (r.TemporalAA.Upsampling).

    That looks to be potentially very useful for VR, but may reintroduce confusion - say running vr.PixelDensity of 1.2 but with r.ScreenPercentage at 80 with r.TemporalAA.Upsampling on to upsample to that Vr pixel density from a lower resolution render.

    Comment


      #3
      How will this support the current Windows Mixed Reality devices? I feel that they should be included as they work with SteamVR. I would be happy to find the ideal resolution in my Samsung HMD Odyssey if you could give me the steps on how to do this. Its resolution is a massive 1440x1600 per eye with other WMR devices being 1440x1440 per eye.

      Comment


        #4
        Originally posted by TurtleSimos View Post
        How is this intended to be used with the upcoming temporal AA upsampling? (r.TemporalAA.Upsampling).

        That looks to be potentially very useful for VR, but may reintroduce confusion - say running vr.PixelDensity of 1.2 but with r.ScreenPercentage at 80 with r.TemporalAA.Upsampling on to upsample to that Vr pixel density from a lower resolution render.
        I don't know what you are talking about.

        The fact is we had to break VR backward compatibility specifically for that use case, to keep the renderer consistent between VR and non-VR rendering. From this we took the opportunity to do this change to no longer have to manually set the res settings with per VR platform magic number to match the non upscaling case.

        In short to answer your question, the vr.PixelDensity is going to define the resolution of TAAU output/history. From this the screen percentage when doing temporal upsampling, will actually control the input resolution of TAAU according to output resolution. It also means if you are not doing TAAU, then having screen percentage != 100 would cause a spatial upscale/downscale pass at the end of the renderer before handing the eyes output to the HMD's compositor, that only make your final output technically more blurry. There will be more information coming about that in the 4.19 timeframe, whereas this message is more intended to be cautionary for VR devs because of the perf regression it will cause.

        Comment


          #5
          Originally posted by J_Paul View Post
          How will this support the current Windows Mixed Reality devices? I feel that they should be included as they work with SteamVR. I would be happy to find the ideal resolution in my Samsung HMD Odyssey if you could give me the steps on how to do this. Its resolution is a massive 1440x1600 per eye with other WMR devices being 1440x1440 per eye.
          The WMR devices are supported via the SteamVR plugin as you've pointed out. You'd follow the rules above for those devices as well - r.ScreenPercentage at 100 and vr.PixelDensity at 1 to target native resolution.
          Let's Connect [Twitter]

          Comment


            #6
            Originally posted by Chance Ivey View Post

            The WMR devices are supported via the SteamVR plugin as you've pointed out. You'd follow the rules above for those devices as well - r.ScreenPercentage at 100 and vr.PixelDensity at 1 to target native resolution.

            WMR and Oculus Rift via Steam VR were both broken in 4.18, but they are fixed in master with this change. Here's a couple threads on the issue:

            https://answers.unrealengine.com/que...n-instead.html
            https://forums.unrealengine.com/deve...ession-in-4-18


            I've tracked it down to the aspect of the native screen res on the HMD differing from the aspect of the ideal rendertarget (GetRecommendedRenderTargetSize).

            Rift just legitimately gives a different aspect ratio, which should be handled (and is in master and 4.17).

            WindowsMR doesn't try to give a different aspect ratio, but the way UE4 is querying native screen res (VRExtDisplay->GetWindowBounds) breaks and returns the screen res of the Rift and Vive (2160x1200) even on Windows MR, which differs from the actual aspect of most Windows MR devices (1440x1440 or 1440x1600) and their recommended render targets.

            4.17 didn't care if the aspect ratios were different, but 4.18 does. 4.18 seems to have inadvertantly done this while adding adaptive pixel density, but adaptive pixel density doesn't actually work for me on Vive in 4.18 and the interface changes in 4.19. I think 4.18 should just be reverted to the 4.17 behavior in a hot fix.


            Edit: Added a pull request here that hopefully should fix things: https://github.com/EpicGames/UnrealEngine/pull/4354
            Last edited by muchcharles; 12-19-2017, 04:15 PM.

            Comment


              #7
              So if an HMD uses a 4K display and I want the game to be in FullHD to have better performance I just set vr.PixelDensity to 0.5?
              ProBoon, Old-School FPS, Open Source & Tutorials
              Support Project Boon on Patreon

              On Steam Soon, Click Below

              Comment


                #8
                Originally posted by muchcharles View Post


                WMR and Oculus Rift via Steam VR were both broken in 4.18, but they are fixed in master with this change. Here's a couple threads on the issue:

                https://answers.unrealengine.com/que...n-instead.html
                https://forums.unrealengine.com/deve...ession-in-4-18


                I've tracked it down to the aspect of the native screen res on the HMD differing from the aspect of the ideal rendertarget (GetRecommendedRenderTargetSize).

                Rift just legitimately gives a different aspect ratio, which should be handled (and is in master and 4.17).

                WindowsMR doesn't try to give a different aspect ratio, but the way UE4 is querying native screen res (VRExtDisplay->GetWindowBounds) breaks and returns the screen res of the Rift and Vive (2160x1200) even on Windows MR, which differs from the actual aspect of most Windows MR devices (1440x1440 or 1440x1600) and their recommended render targets.

                4.17 didn't care if the aspect ratios were different, but 4.18 does. 4.18 seems to have inadvertantly done this while adding adaptive pixel density, but adaptive pixel density doesn't actually work for me on Vive in 4.18 and the interface changes in 4.19. I think 4.18 should just be reverted to the 4.17 behavior in a hot fix.


                Edit: Added a pull request here that hopefully should fix things: https://github.com/EpicGames/UnrealEngine/pull/4354
                Thanks for the feedback on the current implementation and the suggestions on what we could change to fix!
                Let's Connect [Twitter]

                Comment


                  #9
                  Originally posted by masterneme View Post
                  So if an HMD uses a 4K display and I want the game to be in FullHD to have better performance I just set vr.PixelDensity to 0.5?
                  That should do the trick.
                  Let's Connect [Twitter]

                  Comment


                    #10
                    Nice to see this being unified, as using PixelDensity on Oculus and r.ScreenPercentage on SteamVR was ... confusing Any chance we're seeing crossplatform adaptive pixel density soon?
                    Proud member of iNFINITE Production - VR and hi-tech development studio (sometimes) available for hire.

                    Comment


                      #11
                      Originally posted by masterneme View Post
                      So if an HMD uses a 4K display and I want the game to be in FullHD to have better performance I just set vr.PixelDensity to 0.5?
                      If you want the game to be in FullHD, vr.PixelDensity 0.5 won't give you FullHD unless the HMD has a recommended render target of 4K. Usually the recommended target is a good bit higher than the native panel res.

                      Comment


                        #12
                        OK, thanks for the answers guys!
                        ProBoon, Old-School FPS, Open Source & Tutorials
                        Support Project Boon on Patreon

                        On Steam Soon, Click Below

                        Comment


                          #13
                          Is it possible to use PixelDensity for on the fly adjustments? I mean, by analyzing current scene complexity and decreasing pixel density if necessary?
                          Marketplace: Vive Mocap Kit / Fingers Solver / VR IK Body Solver / Subtitles to LipSync / Dialogue System with Character Animation
                          And random stuff at Youtube

                          Comment


                            #14
                            So if an HMD uses a 4K display and I want the game to be in FullHD to have better performance I just set vr.PixelDensity to 0.5?
                            Note that there's more to it than the display resolution. The display may be '4K', but the ideal resolution is probably higher to account for the compositor barrel distortion.

                            Is it possible to use PixelDensity for on the fly adjustments? I mean, by analyzing current scene complexity and decreasing pixel density if necessary?
                            This is what adaptive pixel density does. This is currently supported on the Rift and..

                            Any chance we're seeing crossplatform adaptive pixel density soon?
                            Soon

                            Comment


                              #15
                              what is the maximum vr.PixelDensity ? tks
                              _____________
                              Zahir3d
                              PIXARCHI.COM
                              FACEBOOK PAGE

                              Comment

                              Working...
                              X