Make the Best Out of Your Varjo Experience: Update on Varjo Quad View, Eye Tracked Foveation and Varjo Base Settings
When it comes to Varjo headsets, they have always been associated with super high-resolution displays and with foveated rendering enabling the ability to render efficiently to those displays with high pixel count.
The main topic of this blog post is to share a few new settings that can be used for OpenXR applications, but before that we are getting there, let’s cover some background. The topic of foveated rendering does itself require some explanation, as it’s not likely widely known information for everyone, so let’s start there.
Understanding Foveated Rendering
The basic idea with foveated rendering goes back to the human vision system and the anatomy of the eye. One key thing to understand is that human eyes don’t have the ability to see everything with highest acuity across the whole field of view, or even perceive colour throughout the full field of view. The areas where the eyes have the ability to perceive the highest acuity is called the fovea and the areas outside we informally call the periphery. The technique of rendering graphics with the desired resolution that ideally matches the level of detail that the eye perceives is called foveated rendering. Foveated rendering focuses high-resolution rendering on the fovea and reduces detail in peripheral areas. When combined with eye tracking, this becomes eye-tracked foveated rendering.
We do support many techniques to help game engines to implement foveated rendering, but the one that has gained most is based on a scheme that divides the display into two different views, also known as QuadViews, which we then would composite together. It comes in two flavours, a static version which does not follow your eyes and an eye controlled version. They are quite similar, and you will see the importance of that later in this post.
The benefits for foveation are clear
The advantages with foveated rendering are manifold:
- Enhanced immersion. With high-resolution rendering focused where the user is looking, the level of detail and realism is increased, thus boosting immersion in XR experiences.
- Performance boost. Rendering fewer pixels where it’s less needed helps maintain a high frame rate.
- Hardware efficiency. Reducing the demand on hardware allows lower GPU specifications.
These benefits are universal, but particularly significant for high-end graphics where the increased immersion and having a solid performance boost are most appreciated.
Quad view, foveated rendering and OpenXR — a perfect match
Going back into the history of OpenXR, we added the first extension for fixed foveation to the OpenXR 1.0 specification XR_VARJO_quad_views already back in 2019, and since then we have worked with several partners on implementing support for this into game engines. This is essentially static foveated rendering where the high-resolution inset does not follow the eye movement.
Later, we introduced the XR_VARJO_foveated_rendering extension to add eye movements to the extension, and it’s been incorporated in our engine plugins.
Fast forward a few years, there is more content that do support both of these extensions. But we have seen that the static foveation has seen wider adoption in applications. However, it has turned out that some of the applications that have done the work on integrating the basic XR_VARJO_quad_view, would actually work fine with the additional behaviour specified in the XR_VARJO_foveated_rendering.
Realizing this, and listening to feedback from some of the user community that we have out there, we have decided to expose a few settings to our OpenXR runtime to help power users to opportunistically change the behaviour if an application is using any of the foveated view configurations. See the available configurations in the figure pictured here.
New OpenXR runtime settings in Varjo Base 4.3
What’s interesting here is that it’s possible from our runtime to essentially move between the different view configuration as long as the game or game engine picks the one that our runtime prefers.
In particular this is interesting for recent applications developed with Unreal Engine, for instance Vail VR. It’s also very interesting for the flight simulator DCS that also has support for Quad View (but not foveated rendering).
It turns out that if we force on foveated rendering for these applications through a system setting in Varjo Base, the foveated part of the screen will start to follow the eye movements, and the application actually handles that well. This is by no means a new discovery, as for instance there are open source projects that have injected code on our runtime to achieve this, but now it’s possible to do it without addons.
On the flip side, there are a few applications that have been developed and do not handle the foveation or quad view correctly and have not been tested with our runtime and HMDs.
For them we are also adding a compatibility setting that would instead communicate to those applications where regular non-foveated stereo rendering should be used. This was discovered in EA WRC VR beta recently.
So we have added Windows registry settings in Varjo Base 4.3 to experimentally enable more end user control of this through creating the following Windows registry settings under key.
HKEY_LOCAL_MACHINE\SOFTWARE\Varjo\OpenXR
| Value name | Data Type | Value |
| DisableQuadViewsExt | DWORD | 0 (default) – Suggest to game engine to use quad view and fallback to stereo rendering if support for quad view is not implemented in game engine.
1 – Force game engine to use stereo rendering. |
| ForceFoveatedRendering | DWORD | 0 (default) – Do not force on foveation.
1 – Force on foveation when quad view is used and application did not enable XR_VARJO_foveated_rendering
|
These registry settings do essentially allow the end user to move between all configurations in the table, as long as Stereo Rendering with Foveated Inset (previously called Varjo Quad View) is supported in application.
Registry keys can be created with the regedit.exe tool built into Windows. Please be aware that this is a Windows power tool, and can have devastating effects if used incorrectly, so please be careful if creating these keys, and take care to only change items under the specified path above.
What do you think?
With OpenXR 1.1 and the inclusion of Stereo Rendering with Foveated Inset, our hope is that it will be more mainstream to support this view configuration in applications and game engines, and hopefully more headset vendors will also support this functionality.
One of the few interesting thoughts that we do have right now is:
Does customisation like this bring value for you?
Does it make sense to have games support this configuration by default and essentially opportunistically get support for foveated rendering with a risk that some games might break because it’s an untested configuration?
Let us know.
Some things to note:
A common misunderstanding is that XR_VARJO_quad_views and XR_VARJO_foveated_rednering only benefit devices that have four physical displays like our XR-3 and VR-3, but that’s not accurate. It does have benefits on Varjo Aero and XR-4 which have one physical display per eye as the quad view and foveated rendering is a general software technique implemented in our OpenXR runtime that logically partitions the physical displays regardless if they are two or four (see our high performance rendering page here.)
There are also open source projects which enables Quad View rendering for other than Varjo HMDs, which also helps with showing the value for this specific way of implementing foveated rendering for general VR headsets.
The settings that we have listed earlier in the blog are experimental, which means that they will be reset to default values each time Varjo Base updates. The applications we tested with, and are known to work with the settings, are DCS, Pavlov VR, Vail VR and The 7th Guest VR.