Fixed foveated rendering on Oculus Quest not working

So for us FFR + MSAA works on Quest (on device) with the following conditions (not saying others don't work, this is just what we're using in the app):
1) Fog on, no postfx, two spotlights with shadows, no dir light, no baked light
2) Fog off, no postfx, single dir light without shadows, no baked light

 

From my own tests, the Canvas UI rendering and Shader Graph materials (only some) don't render once the hack fix is implemented. I have passed the information about this onto the team working on URP.

Also, MSAA works only on the Quest itself, it is broken for Editor and all other VR platforms running OpenVR that we have tested, that can be fixed with a platform specific #if UNITY_ANDROID wrapped around the fix though

 

Is this with 2019.3, URP 7.0.1? Were you enabling depth texture?

 

I was seeing this on the Quest when I used a shader that tried to sample LWRP's opaque texture. It seemed like everything that was supposed to render after that shader was missing (Including UI elements). In my case it was a glass refraction shader. In your case it might be that water?

Edit: I should mention this bug is present even without the FFR hack. I tried to submit a bug to Unity, but the sample project was almost a gigabyte and I haven't gotten a response from them, so I'm not positive the submission succeeded.

 

I have reported that bug also, as it seemed to be present in more recent versions of the URP repo still

 

p.s. @ROBYER1 did you know they (Unity and Oculus) recommend not using Unity's skybox on Quest? I think it's because the spherical one is a lot of triangles and the cubic one is a lot of texture passes (And the procedural skybox shader is expensive).

https://unity3d.com/how-to/optimize-mobile-VR-games

https://developer.oculus.com/docume.../unity-mobile-performance-intro/?locale=en_US

• Avoid Unity’s Default-Skybox, which is computationally expensive for standalone. We recommend setting Skybox to None (Material), and Ambient Source to Color in Window > Lighting. You may also wish to set Camera.clearFlags to SolidColor (never Skybox).

I found a nice skydome in the GoogleVR daydream elements repo. It uses a vertex color shader and is only 760 triangles.
https://github.com/googlevr/daydrea...ts/Elements/Teleport/Demo/Art/Environment/Sky

 

Thanks for the tips, I am still chasing after a response to the fix for FFR and also my question about activating it without importing the OVRPlugin.dll that comes with the Oculus Integration Assets pack (which also conveniently clashes with the new Oculus Loader integrated into XR Subsystems).

 

I have my complaints about the Oculus Integration, but I will say OVRManager and OVRCameraRig are well written and you shouldn't necessarily avoid them. I know it complicates cross-platform development, but the Quest does that just by existing. If you're worried about code bloat from the Oculus Integration, you can delete every folder except "VR" from the integration and still have a working OVRManager/OVRCameraRig implementation.

And if you already have a separate transform hierarchy for your app's head and hands you could remotely puppet those transforms by subscribing to the OVRCameraRig.UpdatedAnchors event.

But I digress. I (still) wish Fixed Foveated Rendering in the Lightweight or Universal Render Pipelines worked as advertised.

 

@daves thanks a lot. I need that! What month would be a good guesstimate for it?
Also hows vulkan coming along?

 

Obviously it's not coming along. Klingons blew it up or some such.

 

Is the problem fixed? (FFR on URP)

 

Any updates on this topic?

 

FFR hookups coming with Vulkan support in the 2020 version of Unity, seemingly only with the new XR Subsystems Manager Oculus Loader plugin

https://docs.unity3d.com/Packages/com.unity.xr.oculus@1.1/changelog/CHANGELOG.html

 

Heres my quick reference guide for production ready VR in Unity:

use 2018 LTS until Unity 2019.3

Seems like a lot of good things are coming our way in the pipe from the boffins at Unity, but for now MSAA, Post Processing, FFR, LWRP, Vulcan in 2019 are at mixed levels of compatibility.

 

Is there any update on FFR for UniversalRP? I saw that XR Management Oculus XR Plugin has some references to Vulkan FFR hookups which is a different method (but great as it's cross platform). However Vulkan isn't ready for the Quest yet it seems?

I saw the unnecessary blit is fixed here in 8.0~ https://github.com/Unity-Technologies/ScriptableRenderPipeline/pull/5197

 

Hi, all, I imagine there haven't been any updates to this, but if anyone knows of some miracle fix I haven't found, I'd sure like to hear it.

 

Unfortunately still waiting for a fix or update on this in UniversalRP

 

A fix has been found and it's the same we use in this other thread to get back antialiasing to work with URP. Basically, antialiasing and FFR work only after you resize the eye texture. Tested on Unity 2019.3.0f3.
Add this script somewhere as soon as you start the game:

Code (CSharp):

1. using System.Collections;
2. using UnityEngine;
3.  
4. public class AAFix : MonoBehaviour{
5.  
6.     void Start() {
7.         StartCoroutine("Fix");
8.     }
9.  
10.     IEnumerator Fix() {
11.         OVRPlugin.fixedFoveatedRenderingLevel = OVRPlugin.FixedFoveatedRenderingLevel.Medium; // Whatever intensity you need
12.         UnityEngine.XR.XRSettings.eyeTextureResolutionScale = 0.5f; // Any value, just to trigger the refresh
13.         yield return new WaitForEndOfFrame(); // Needed to apply the changes
14.         UnityEngine.XR.XRSettings.eyeTextureResolutionScale = 1f; // Use your target resolution here
15.         Destroy(this);
16.     }
17. }
18.  

 

Interestingly, Oculus Integration's newest release notes mention this also: "Using the Unity Universal Render Pipeline may break Fixed Foveated Rendering on Oculus Quest and Oculus Go when using the linear color space or modifying the eye texture resolution scale"

https://developer.oculus.com/downloads/package/unity-integration/

 

Unfortunately, if you have anything in the scene that uses Depth/Opaque pass, it breaks MSAA and also FFR was not working either despite me adding your script into the scene. The reproducible scene is here if you want to see for yourself (it's just the project without your script in it)

https://drive.google.com/open?id=1nctZLAGQj_BqpVSRbJvOSv_vCYoNmZD8

 

Thanks for the insight. I don't believe I'm using any specific shader with Depth/Opaque pass, this explains why it works for me (this is the last screenshot I took of the game directly from Quest, you can see both 4x MSAA and FFR). I mostly use builtin URP shader except for simple unlit transparent I made with Shader Graph.
On the other hand, I'm using soft particles with the builtin URP particles shader, I might be wrong but they seem to work correctly ingame. Don't they use Depth pass?

EDIT: replying to what you asked in the other thread, I have no performance impact with both FFR and MSAA, my game is still running at 72 fps (with 1.0 eye resolution). Let's continue in this thread maybe!

 

What happens if you add a worldspace UI canvas, does it render?

 

Yes, it does. In the screenshot I linked in my previous reply, all the text in the car dashboard is made with a standard worldpace UI canvas. In any case I'm using 2019.3.0f3, if I remember correctly you are using 2020, right?

 

Could indeed be a 2020 issue, however the scene I sent was from around when I was testing 2019.3 and sending QA (Specifically Dominykas) the reproducible issue, I'm also using the SRP git repo latest commits and changes not the public release so it is likely something they are fixing in it which is causing your fix to not work for me..

I've already reported the UI and Shader graph not rendering so QA know and have told me the devs are on it, I would advise to not use 2020 for now unless you want to test it out separately!

 

Are you able to share the render pipeline asset settings for your project? I'd be interested to see why it's working for you and not for me!

 

I tried the AAFix.cs script with Unity 2019.3.0f3.
Antialiasing seems to work, but not the Foveated Rendering.
I am using The Oculus Integration 12.0 and the URP 7.1.7.

 

Is there any update on FFR for intermediate renderings, and FFR working with MSAA including Depth/Opaque passes in UniversalRP?

 

Update here, both should be tackled in the next dev sprint/when Oculus get back to them about a driver issue
https://forum.unity.com/threads/urp-not-rendering-right-eye-in-vr-2019-3-0b7.762032/#post-5376954

 

Thanks, that update brings hopes up again.
To bring up that older issue - how can FFR be enabled on the new XR Management System with Vulkan on Quest? Would love to test-run it on our Quest app that is currently stuck on a pretty old SRP commit that's the only I know where "most of everthing plus MSAA plus FFR" works (with some hacks).

 

@daves sounds like terrific work, thanks for the update.

As well as the question from fherbst, will Vulkan URP FFR use the Foveation on renderpasses mentioned here?
https://developer.oculus.com/blog/vulkan-for-mobile-vr-rendering/

 

Thanks for the thorough update @daves

For clarification, even in Vulkan using intermediate Render Targets and then Blitting to the eye textures / backbuffer will still result in no FFR?

Cheers

 

hey @daves, is SRP batching expected to work with quest? I posted on the forum here with more details: https://forum.unity.com/threads/srp-batching-and-oculus-quest.809505/

 

Building to Quest from 2019.3.0f5, URP 7.1.7, using the new XR Management System, Multiview results in the right eye being completely black and the left eye being completely grey.

I built this out of the URP template project where I am using an unchanged UniversalRP-HighQuality.asset as the active RenderPipeline Asset.

Edit: Disabling all Post-Processing slightly improves the result in the left eye. Both eye projections seem to be rendering to the first slice of the Multiview RTArray. The right eye is still completely black.

 

I am facing the same issue when using "Stereo Rendering" as "Multipass". The left eye works but right eye is completely black. Did you find any solution?

 

Does this mean we will have access to the preview versions of some of this in 2019.3? Any idea on when that might be coming?

 

It is absurd that this post goes unanswered while that blogpost goes up.

Does URP multiview work with Vulkan on Quest? Don't need any Shadergraph, texture arrays, no PP - does the simplest configuration currently work?

 

As best as I can ascertain, no. At least not with URP 7 / 2019.3.

 

I tested all the possible ways yesterday -

Current 2019.3.0f5 with 7.1.8 and XR Plugin Management does not work on Quest (neither with Vulkan - left eye is grey, right eye is black - nor OpenGLES3 - right eye is always black).
With "legacy VR" at least the rendering looks correct but no FFR and seemingly also no AA.
(case 1214827, case 1214807)

I also tested this with latest master URP branch and latest 2019.3 URP branch.

This is with the Unity URP sample scene but all PP turned off.

 

From the Platform Updates page of 2019.3 here https://unity.com/releases/2019-3/p...8.1620892044.1580219335-1489156165.1559741659

"
Vulkan Support for Oculus Quest and Oculus Go
We now support Vulkan for Oculus Quest and Oculus Go, using multiview Fixed Foveated Rendering (FFR). This enables developers to deliver higher quality experiences with more control over the GPU and lower CPU usage.
"

I am pushing for an update on how to activate it using the new XR Plugin Systems in Unity 2019.3 here
https://forum.unity.com/threads/unity-2019-3-is-now-available.817029/#post-5416197

 

Please try to check if multi-view has no problems in Oculus Quest (such as lag issue) and multi-pass has no problem rendering in both eyes which was the case. Thank you.

 

Thanks for the update on this, that is much clearer for the developer community !

Is there any update on how to activate the FFR (Fixed Foveated Rendering) with it using the Oculus XR Plugin in the new XR Plugin architecture? We have noticed that the logcat logs mention the following line on the Vulkan FFR density map when using Oculus XR Plugin on its own (without any Oculus Integration Assets from the asset store)

Vulkan FFR is supported, with density map size 32x32

There is also no documentation on FFR here at all: https://docs.unity3d.com/Packages/com.unity.xr.oculus@1.1/manual/index.html

My reason for asking about using it with the Oculus XR Plugin is to ensure we do not end up using any deprecated plugin assets from the asset store and purely make use of the Unity.XR.Oculus utils from here instead to set it via code:
https://docs.unity3d.com/Packages/com.unity.xr.oculus@1.0/api/Unity.XR.Oculus.Utils.html

I have reported the following bugs with Vulkan on built-in renderer and URP 8.0 off the current master branch - if it is broken on the latest master branch then it will be broken in the next release:
(Case 1215378) [XR][Vulkan][URP][Multiview] Left eye is rendered grey while the right eye is black
(Case 1215369) Vulkan on Oculus Quest using Built-In Renderer shows both eyes on left eye and distorted. Right eye renders black

 

@mfuad Thanks for the clarification. I'm sure you're aware of that, please note that Multipass is totally inefficient on Quest - no FFR speed improvement can offset the performance degradation when using Multipass instead of Singlepass/Multiview...

I also reported multiple bugs since Quest + FFR + Vulkan don't work in URP on 7.2.0 (neither with current master with URP 8.0 nor release/2019.3 branches with URP 7.2).

Also, I second @ROBYER1 above – where is the documentation on how to enable/disable/configure FFR?

(would be great if you could also follow-up with https://forum.unity.com/threads/fol...ious-systems-supposed-to-work-together.817086).

 

Terrains only render in one eye while all else is fine etc etc, I think probably some fair amount of work needs doing...

 

Also my simple test scene renders like this, using the latest master branch of URP and Shader Graph.

 

Yeah probably need to just give it a year. I wasn't really kidding when I said to you in PM that I think it'll take Unity way longer to make this alpha ready for production. I guess we could warm up the old bug reports.

Beta would mean it works all the time but some behaviour is strange. This is clearly alpha.

 

Any idea if 7.2 will require any Core Engine changes (e.g a 2019.3.1) or is the support purely in the package? Because if it's all in Managed code that means it can be mitigated by the community now or implemented in a custom SRP.