Fixed foveated rendering on Oculus Quest not working

That’s interesting!

 

In other words, does this mean no switching render targets even after the fix? What If one needed to do something like that in a render feature and still use FFR?
If I've understood the problem correctly, it's that OVR swiches to a new render target internally without Unity's knowledge, so setting the render target to anything else on the Unity side will break FFR. There was a post over a year ago by daves saying you're working with Oculus on this, is that still going on?

 

Agree with your point. For our use case, it's enough to control that blit since in this case we're just drawing renderers to the current target.

 

I am shook this is still an ongoing issue

 

Wait, just to clarify, I can have EITHER fixed foveated or a different render scale with URP, but not both? And this bug is a year old? More than? Come on Unity what is this?!

 

The amount of URP features that you can't use just to have FFR is insane. No post processing, no camera stacking, no renderer features at all, anything that calls the final blit prevents FFR, and therefore tanks your performance, absurd.

 

That's very unfortunate because post-processing is one of the areas that would benefit most from FFR. Less pixels makes a major difference for most post-processing effects.

 

Any update on this ?
Not having FFR prevents me from publishing my game since it heavily relies on complex shaders and post-processing..

 

Thank you!

 

I suggest starting from Low until everything is running smoothly. For me it is set at Medium.
OVRPlugin.fixedFoveatedRenderingLevel = OVRPlugin.FixedFoveatedRenderingLevel.Low;
OVRPlugin.fixedFoveatedRenderingLevel = OVRPlugin.FixedFoveatedRenderingLevel.Medium;
OVRPlugin.fixedFoveatedRenderingLevel = OVRPlugin.FixedFoveatedRenderingLevel.High;
OVRPlugin.fixedFoveatedRenderingLevel = OVRPlugin.FixedFoveatedRenderingLevel.HighTop;

 

A simple suggestion.

Wouldn't it be so much better if Unity could offer a SIR, Single Image Rendering (or what it may be called) option for all VR headsets using the XR System?

Think it is much simpler to implement and would probably give a better experience for the players to drop the costly stereo rendering, to save the frame rate in some heavy situations in the game, instead of blurring everything but the center of the image.

 

No. VR without stereo rendering is extremely disorienting.

The cool thing about fixed foveated rendering is that it's barely noticeable because in VR, people usually "look forward", i.e. they usually rather turn their head instead of just rolling their eyes. Losing spatial vision, on the other hand ... that's just weird.

Interestingly, even reducing the resolution based on performance is less disorienting than the framerate dropping. Valve successfully implemented this e.g. in "The Lab" and it's also an option in Unity (or it least it was). Yes, things do get a little more blurry that way, even in the center of view - but that's less annoying than the framerate dropping.

 

I haven't noticed any decreased quality in main view. But I am using mostly UI and rendering the scale to 1.5 for better clarity on low quality setting.

 

Oh, no, no, disabled stereo is hardly noticeable by anyone having all other depth clues from the perspective, different sizes, and speeds of the scene objects depending on the distance. The Cardboard guys even "forgot" to implement it in some of the versions for the new XR System. No one even noticed it for a long time. Would say unnatural turning of the head is probably the number one puke trigger, for those ranting on about so called "VR sickness".

 

Any news about when and in what version this will be? It's surreal that this issue is still unresolved. Can the community help accelerate its resolution in any way?

 

Monthly checkin hoping a resolution for this is coming soon.

 

Just stumbled upon this issue. I have tried many options offered here, but with no luck even with the latest URP version available in Unity 2019.4 LTS. I hope it gets solved.

 

F***ing hell Unity, we back at it again.

Another day lost to clicking through settings in multiple different places, to now realize MSAA doesn't work when Opaque texture is on...

URP: 10.5.0
Unity 2020.3.11f1 LTS

This is ridiculous... Stop treating your PAYING customers as QA...

 

Is this fixed now? Thanks for any update.

 

Whats up with this issue? Still seeing this in 2020.3 LTS and latest URP / OVR Integration plugin.

 

Bump. Still no fix for this. If I understand correctly, the FFR will not work in URP if you have a custom renderer feature, opaque texture or antialiasing 4x active. Unity 2020.3.5f1 URP 10.5

 

This still happening on 2020.3.01.

 

I just found out that the problem is from the last unity Oculus integration update, I downgrade the update, and now all is working right.

 

This whole FFR thing has driven me crazy. At "some point" in the past, FFR worked fine on Quest 2 with Unity 2019.1/Standard RP/Forward Rendering.
I tried it again for a new project yesterday, using 2019.4/Standard RP/Forward Rendering/Oculus Integration 0.28, just a simple camera in the scene with a few cubes, a single script with OVRPlugin.fixedFoveatedRenderingLevel = OVRPlugin.FixedFoveatedRenderingLevel.High;

No FFR...

I spent the afternoon trying to figure it out without success.
Does anyone have a simple test project that shows FFR working on Quest2 with Standard RP on Unity 2019.4 ?

 

Wanting the same thing!

You could download a previous .dll and roll back your version.

 

Unity seriously need to do some thinking. First the OpenXR "integration" and now this. The alternatives start to look better and better by each day...

 

I think Oculus broke it in an update on the headset itself.

I can't see a difference running just this adb command:

Code (CSharp):

1. adb shell setprop debug.oculus.foveation.level 4

 

It looks like the Quest 2, or newer versions of the OS, default to dynamic fixed foveated rendering enabled. If you want to be able to see different ffr levels in your app you need to disable that first:

adb shell setprop debug.oculus.foveation.dynamic 0

I just tried this in a basic URP app, and it was working. I believe there's also an OVRPlugin property in the Oculus Integration to do the same.

 

Speaking of Oculus,

My game is building perfectly using Oculus's runtime, yet using OpenXR there are problems like some kind of visual effect at the bottom of the view, etc... and yet Facebook wants everyone to use the OpenXR runtime for some reason. Don't really understand why when it works perfectly with the Oculus runtime.

 

I was just going through the change log for various versions of URP (as one does) and found this in the log for URP version 13.0.0 (for 2022 alpha, I believe):



I believe this is the fix proposed in the above post (https://forum.unity.com/threads/fix...-quest-not-working.686662/page-4#post-6717991) from @TreyK-47. Hopefully this means you can now use (most?) render features with URP on Quest without breaking FFR and MSAA. Unfortunately it appears to only be available in this alpha version of Unity.

Edit: This fix appears to also be in 2021.2+

 

Any news on the state of FFR with Unity? I'm confused as to what the standard is now? Is it using OVRPlugin, hence: OVRPlugin.fixedFoveatedRenderingLevel = OVRPlugin.FixedFoveatedRenderingLevel.HighTop;

or is it using Unity.XR.Oculus.Utils.EnableDynamicFFR(true); and Utils.SetFoveationLevel(3);

I've tried the latter and it's not doing anything even with opaque textures disabled. I believe my quest is rendering directly to eye texture, but my RenderDoc gets stuck during frame capture so I can't verify. Either way, what's the state of FFR?

 

FFR is definitely working (as long as you're not doing any of the stuff that breaks it listed in the above thread), but if you enable DynamicFFR then you won't see the FoveationLevel you selected unless the GPU is under heavy load. Dynamic FFR will pick the best FFR level for you _up to_ the level you selected. And on Quest 2 I believe Dynamic FFR is on by default, so you have to explicitly disable it if you want to test.

Also, I believe the Unity.XR.Oculus.Utils calls here are just wrappers around the OVRPlugin calls, so they should be equivalent.

 

Right now neither works on Unity 2021.3.3f, URP 12.1.6, Oculus SDK v40 either with OpenXR or Legacy backend, OpenGL. The old "AAFix.cs" script that I posted early on in this thread doesn't help apparently. Weird thing is that I can see the correct FFR number when using the OVR Metrics Tool, but then the pixel density doesn't seem to change at all, resolution looks like FFR is Off entirely.

EDIT: I ended up downgrading my project to Unity 2020 LTS and now everything is working again as intended.
2021 LTS is clearly still not fully production ready for Quest, quite a bummer because it's the only version fully supporting Apple Silicon and it was noticeably faster.

 

Here's the PR to fix the issue https://github.com/Unity-Technologies/Graphics/pull/5297
It was also backported to Unity 2021 compatible URP.
If you need it in URP 10.10 you need to add these changes manually to your local copy of URP.

 

Late reply but I just went back to try Unity 20201 again. Even when forcing an Intermediate Texture in the URP asset, FFR is not working with OpenGL on Unity 2021.3.x, but only with Vulkan.

 

Btw working on regular renderer FFR only works for Medium and High Top, Low and High don't do anything. Done from inside the app from code and even from adb. Really weird

2020 LTS