Oculus Quest OVR Metrics Tool FPS Cap?

Does anyone have any advice for acquiring accurate FPS information above 72 fps on the Oculus Quest? It seems the OVR Metrics Tool has a cap of 72fps which may also be on the hardware side. But it seems to be very simple to crash down from 72 fps to 50-60 fps with a simple unity scene with one camera, a directional light and a cube (on LWRP).

I'd be interested to hear other people's experiences with developing for the Quest in Unity as it doesn't seem to be very performant currently testing from 2019.1 using the built in renderer and also 2019.2b9 with LWRP 6.7.1

 

Hi, we have a similar problem with LWRP and Quest. It just seems impossible to maintain 72 fps. We are just starting to experiment with the graphics, so I can't really help, but I'll reply here when we discover something useful.

 

I'm glad it's not just me, currently benchmarking what is possible for a current project to run on the Quest but the current engine performance is dire - I will be submitting a bug report for both the mentioned renderers and I hope that I can get a Unity developer or QA response or explanation on what is going on. I was hearing a lot about LWRP being optimised for VR but neither LWRP or Built in seem to be very performant on the Quest!?

Please please do keep me posted on any findings you have

 

I have a scene that has simply 14 batches, hitting a fantastic 1000FPS on the development laptop, however on the Quest it tanks to 52 fps and it only has 5 mobile Speedtree assets, 3 unity cubes, baked lighting and a directional light with no shadows.

I have submitted as a bug report as the fact it can't hit 72fps on the Quest astounds me.

 

We're also getting to grips with quest performance, I'm glad to find others to swap ideas with

We're working in LWRP, so I haven't tried the default renderer, but we've found that the render pipeline settings are absolutely critical to performance. You should have a couple of default LWRP-<detailname> objects in your project. Selecting the one you have active (assigned in Edit->ProjectSettings->Graphics) in the project will show you the properties in the inspector.

For reference, we're using the LWRP-MediumQuality profile, with some changes. By default, HDR is enabled and 8xAA is set which seems to hammer performance (even a simple cube in a scene like you said), but drop those down and you should see a huge improvement. Also, take a look at the lighting settings in the same place.

I've got an object that's way higher poly than we should be using in a test scene and I get a solid 72fps on the quest with it. This is in a scene with a single directional light, pipeline set to no HDR, 2xAA, 1024 shadow res, soft shadows. The object's material has the LWRP lit shader, set to opaque. Note it is colour only, no texture, but that shouldn't matter too much.:




Some helpful things I've found around LWRP that initially had us scratching our heads:
-Light culling by layer is broken in pre-2019.1: https://issuetracker.unity3d.com/issues/lwrp-light-layer-culling-not-working
-You can only use a single directional realtime light in a scene in LWRP: https://issuetracker.unity3d.com/issues/only-one-directional-light-can-emit-light-when-using-lwrp
-Baked point and spotlights require per-pixel to be set for additional lights in your lwrp lighting settings to work (so switch to point, bake, switch back to vert? Haven't tested this theory yet)
-Any kind of large, overlapping alpha objects absolutely destroy performance. As in nothing else seems to matter at all by comparison. Particle system putting out a few overlapping alpha quads? Bye-bye frames. This includes opaque alpha clipped stuff. This is actually mentioned in this article about best practices: https://developer.oculus.com/blog/d...lus-quest-developer-best-practices-the-store/

I hope this helped, and I'd really appreciate you sharing anything else useful you find on quest performance

 

##Quick update: Did a build with the same settings as you by going to medium preset, set AA to 2x instead of 4x and switched off HDR, we now have a stable 72fps in our test scene with the trees and cubes! Thankyou!

Thanks for replying here with your findings! I'll be sure to test out a few different presets, to be honest with my first test we used the high quality but I brought MSAA back down to 4x from 8x but having the HDR option set to 'on' may be reducing performance especially when Quest doesn't support HDR (as far as I know)

The overlapping alpha objects is definitely a performance consideration for me as I am working on outdoors, nature-focused environments where this could be a huge issue. I may just have to reduce amounts of foliage on screen that uses opacity for leaves etc.

I will report back my findings of performance in due time, it's only really worth using LWRP for this project if it actually provides a boost in performance.

In the meantime I have reported an issue with the newly implemented Speedtree shaders for LWRP looking very incorrect compared to the built-in render versions - Case 1171489. This is even more of an issue! There are portions of leaves that are completely black and turning off all shadow casting didn't fix it either :/

 

Funny you should mention trees.. I've spent a fair amount of time today testing shaders on a tree because it's killing performance in a scene for us. We're on 2018 LTS, so any new built-in shaders aren't available to us. Out of sheer curiosity, I set the leaf material to use the fresnel shader we use for outlines, and while the perf still isn't ideal and it obviously looks way wrong, it's way better than lit transparent or even alpha clipped opaque. I would think it's still an alpha shader though so this seems strange to me. I don't really know shader dev at all, though I see it in my future to try and figure out what this shader is doing right:

Lit transparent:


Lit opaque alpha clip:


LWRP particle shader:


Fresnel (WTAF?):

 

With our trees we are lighting them only with light probes in the scene, they are allowed to cast shadows on the scene but not receive shadows (I think this is a speedtree limitation as stated here https://docs.unity3d.com/Packages/c...iversal@7.0/manual/speedtree.html?q=speedtree)

On that engine version you will struggle to find an appropriate optimised foliage shader unless you create one in shader-graph by hand? Using particle shaders for trees may not be ideal unless it suits the art style!

I would also disable any realtime shadow casting while testing as that Oculus deep dive tutorial has a video where at 16minutes mark they explain why realtime shadows are not good!

We are going to bake as much lighting as possible and light the trees with Light probes

Using the latest 2019.2 beta or 2019.3 alpha you can get the latest LWRP/URP which has speedtree shaders built in, tested a scene earlier with the Broadleaf_Mobile tree from this free store pack for benchmarking, kept a steady 72 fps even with 5-8 of them in the scene all in front of each other. I'd recommend doing a local copy or backup of your project and trying it on the newest 2019.2 beta or 2019.3 alpha with the speedtree shader to see if you get that performance bump.

I found on built-in renderer on 2019.1 using the Nature/Tree Creator shaders built into Unity, performance was not good with a scene using 15~ trees (with LOD) and terrain with small amounts of grass. I'm currently using those scenes as a test-bed for the performance of a scene with grass and trees.

 

We are using Speedtree trees as they are giving us a huge performance boost in framerate, but we can't seem to bake the shadows from them to the terrain like we were with the built in Unity tree creator trees before or other tree models we made, have you had any experience with this issue?
https://forum.unity.com/threads/baking-shadows-from-speedtrees-to-terrain-lightmap.716879/

 

We don't use speedtree, our trees are created with the build in Unity tree system. But i see you mention in your post that it's a problem with the GPU Lightmapper. We use Bakery so perhaps that would have prevented us seeing the issue anyway.

"I would also disable any realtime shadow casting while testing "

Yeah we only have realtime lighting on a single skinned mesh, and we're probably just going to use a blob shadow for that object anyway.

 

I solved my speedtree baking issue however yeah, blob shadows are probably best as shadows seem to be a huge performance hit with trees around in VR!

 

Going to give this a try today, performance constraints are too step for the intended environments we are making

Also, the latest Quest update broke the control inputs on our sideloaded development apps so this is the fix for that
https://www.reddit.com/r/OculusQues...with/?utm_medium=android_app&utm_source=share

 

Yesterday I started a test to bring our Unity version up to 2019.1 but after a stupidly long build that seemed even worse than 2018 (I still need to find time to look into shader variant stripping), I ran into a build error I haven't been able to solve yet. Another thing I still need to find time for is to try a non-LWRP version of our app and compare performance.

Seurat looks like a really interesting solution, if your gameplay allows for it. It seems like it would need to be pretty limited mobility.

 

I find that sometimes after one build, consequent builds are much faster. Unity 2019.2 is probably almost production ready so keep an eye on that as I found build times with it to be much speedier so far.

I have a dozen copies of projects with built-in renderer and LWRP but still really not sure which is preferable as LWRP things are hit/miss or still in the works

Will report back on Seurat, even if it's used for the background areas provided the player is within a zone.. very excited to try it

 

Thank you all for replying here. We've been profiling GPU usage and is seems that ~6ms(max 13ms for ok performance) is already used on empty scene in Unity 2019.1.10f1. That left us with 42-56 fps in our game. After upgrading to Unity 2019.2.0f1 GPU usage on empty scene dropped, we achieved 70-72 fps in the game (we still haven't been optimizing the geometry and we still mostly use lit materials on the scene).

 

@EmpyreanDeveloper in response to both of you - we had to import Oculus Integration into our project, then activate Fixed Foveated rendering through it to boost the performance, we went from 35-45 to a stable 72fps with Foveated Rendering on.. everything is now achievable!

 

How did you activate Fixed Foveated Rendering?

Still stubbornly determined to get LWRP working, I created a new project from scratch, Unity 2019.2.3 and Oculus Integration 1.4. The sample local avatar scene (once I replace the default material) "strobes" because of poor performance (I'm guessing - I would also love to know how you guys get the performance screens in the Quest)

Any advice for getting the framerate up? Unity is killing me this week.

 

I mentioned some lighting AA settings above that were basically complete game changers for us.

I'm using the OVR metrics tool for framerate on device (https://developer.oculus.com/downloads/package/ovr-metrics-tool/). I use a commandline script to capture a shot from the device to PC for referring back to later:

Code (CSharp):

1. adb shell screencap -p /sdcard/screen.png
2. adb pull /sdcard/screen.png
3. adb shell rm /sdcard/screen.png

[Edit] I see I'm a filthy liar Those particular metrics shots above are crops from scrcpy, another super useful tool for capturing your device's view to your desktop (in realtime): https://github.com/Genymobile/scrcpy[/Edit]

This article discusses performance monitoring using OVR and other options:
https://developer.oculus.com/documentation/quest/latest/concepts/unreal-debug-quest/

 

Thanks for the info!

 

@darryl_wright just out of curiosity I deployed the Local Avatar scene to the quest in our project (so using our current settings), and there's definitely something happening in that scene that isn't great for performance. We normally get a solid 72 fps in our project, but with this scene the fps hovers around 50-60 fps. There's no way I can spend the time profiling and figuring out the problem there, but just know if you're getting a lousy framerate there it's not just your project settings.

As for FFV, check out this thread: https://forum.unity.com/threads/fixed-foveated-rendering-on-oculus-quest-not-working.686662/

 

You pretty much need this in a script, adjust the level as appropriate for your application, also may need to include 'Using OVRPlugin' or similar at the top of the script

Code (CSharp):

1.  OVRPlugin.fixedFoveatedRenderingLevel = OVRPlugin.FixedFoveatedRenderingLevel.HighTop;

 

Thanks again for your help!