I have not had any luck getting OVRManager.tiledMultiResLevel working on Quest. With an older Oculus SDK I got the error “Tiled-based Multi-resolution feature is not supported” but now nothing shows up and seemingly there is no resolution change around the edge of the screen. It’s as if there’s no effect. This is on 2019.1.4f1
Seems like it does enable in the script, but I agree nothing changes on screen. I printed the value of OVRManager.tiledMultiResLevel onto a text mesh in my game to check it’s value. It does return that it’s enabled, but definitely no pixel change.
Maybe they haven’t officially released this on Quest? Though it’s clear it exists as can see it on published games like Vader Immortal.
Odd!
So Oculus just published the Quest documentation:
https://developer.oculus.com/documentation/quest/latest/concepts/unity-advanced-quest/
Its the same as Go, so no different to what we were already trying. Need to contact support.
Hi! Did you manage to make it work?
Same issue here.
Using Unity 2018.4.1f1
FWIW no probs for me to have it to work using the latest Oculus mobile SDK, Unity 2019.1.2f1, standard render pipeline. Obviously this won’t work on the Rift, only on Quest. Also, it didn’t worked in LWRP.
Trying with Unity 2019.1.4, Oculus SDK 1.36, using LWRP.
Changing FFR settings won’t do anything, also the Render Scale option in the LWRP settings doesn’t affect the final resolution (both with FFR enabled and disabled). Might definitely be a problem with LWRP then…
EDIT: switched back to Standard Pipeline, and FFR works fine now.
As a side question, how much does the LWRP help with Quest compared to Standard Pipeline?
@DanjelRicci I didn’t took much time experimenting with, at first tries results were bad (I mean worst than standard RP).
But once again i didn’t investigated it further.
@Gruguir “good” to know then. I was reading more or less the same feedback in other non-VR related threads…
On a side note: I’m not trying complex scenes actually but it’s been really hard for me to understand what makes the game stutter and what not, because it stutters regardless if there’s a cube or some characters ( thread here ). I ended up here when trying to enable FFR to save on performance.
@DanjelRicci for us performance improvements are huge with LWRP. 10 fps to 50fps with a scene with two lights with shadows. Performance is about the same for simple unlit scenes though.
Has anyone from this thread reported a bug to Unity with it? If yes, please post the case number here.
@LeonhardP @phil_lira any information about this? Is the FFR implementation something on Unity’s end or on Oculus’ end?
Edit: reported as (Case 1162746) [LWRP] Quest FFR (Fixed Foveated Rendering) not working on LWRP
@phil_lira and everyone here, I just spent half a day just debugging FFR on LWRP and found a fix.
My assumption was that FFR only works if graphics are directly put on screen without inbetween resolving into a temporary render texture, and turns out this is true.
I added in a couple dozen debug logs into the LWRP itself to track it down, found that “requiresIntermediateColorTex” was always true and that the only reason for it is that Display.main.requiresBlitToBackbuffer was always returning true for the Quest. Knowing that the Built-in pipeline renders directly to the backbuffer I assumed that this is incorrect and just overwrote it with “false”.
Now FFR works, and since I didn’t do any other change to the LWRP I think everything else should still be working as well.
For anyone who needs this as desperately as I did: change “Display.main.requiresBlitToBackbuffer” in “RequiresIntermediateColorTexture” in ForwardRenderer.cs in the LWRP package to “false”. Done. Double that performance.
@fherbst tried that but the RequiresIntermediateColorTexture returned true anyway. Didn’t have time to investigate so i put a glorious “return false” on that method AND IT WORKS LIKE A CHARME
Frame rate is now fixed at 72 (before it was oscillating between 70 and 52).
Thank you very much!
Hope that a fix will arrive from Unity or Oculus.
I was also getting “isTargetTexture2DArray” and “renderingData.killAlphaInFinalBlit” as true, so I went with the nuclear “return false;” option. One thing to note is that I believe this workaround will disable the ability to cast the content to a mobile device or Chromecast, though I can’t verify this.
@fherbst I tried out your fix and it looks like it enables FFR, but breaks MSAA. Fiddlesticks.
I double-checked that again and it doesn’t seem to break MSAA for me (or it doesn’t work in either mode). Weird.
I made a quality switcher that can cycle from MSAA off to MSAA 8x, and when using the “return false” work-around, I see no difference in aliasing, but when using the unchanged file, I can see it shift, so it breaks MSAA for me.
Hi,
I’ve resolved by switching off the option “Force Into RT” in the camera component, it appears if you switch to Debug mode:
@NickZan What does this setting fix? I’m using the OVRCameraRig and this setting is off by default on all the cameras in the scene and I still have either broken FFR or broken MSAA.
The simplest way to test this is use a shell command to turn on FFR across all apps:
adb shell setprop debug.oculus.foveation.level 4
You’ll be able to see that FFR is running even in Oculus Home.
In Oculus Home you can see FFR on the window beams, but you can also see the rest of the scene is using MSAA (no jaggies).
Then go to your LWRP app and see if FFR and/or MSAA are running.
Without FFR Hack:
With FFR Hack:
Even though the plank near the center of the screen is outside of the area affected by FFR you can see the aliasing on it when the hack is applied.
Has anyone from Unity commented on this issue yet?
No, my bug report from June 13 ((Case 1162746) [LWRP] Quest FFR (Fixed Foveated Rendering) not working on LWRP) is still unanswered. Over different channels (success team) I got the vague reply that it’s “discussed internally”, but that’s 2 weeks ago now.
@phil_lira any news?
I’m also getting this: confirmed that FFR is being set to different levels with the OVR Metrics Tool, it’s working in Oculus Home but not in app. Adding “return false;” as the first line of RequiresIntermediateColorTexture did not fix the issue. Unity 2019.2.0b7, LWRP 6.7.1.
Edit: turns out since I’m using >0 Renderer Features (using a Render Objects pass) I had to go a level up and override bool createColorTexture in Setup() to false. Confirmed using Frame Debugger that opaques were now rendering to a target instead of _CameraColorTexture. FFR is working again and we saw nearly 2x performance increase even without FFR compared to having to blit the intermediate color texture at the end of the frame.
Edit 2: Yeah, it breaks MSAA on Quest. Hoping not too much of that performance boost was going from 4x to 0x MSAA…