So I finally receive a template project from one of the good fellas from this forum and gave it a try. He said it hits 60 fps stable. All I did was opening the project with 4.10.4, setting up Android deployment and adding fps counter.
So it’s either engine’s bug, or I have something enabled on my phone that kills performance.
Here is a screenshot taken on the device showing 58 fps:
Ok, I think I see where the issue potentially is - render scale.
I had render scale slider at less than 100% all this time, hoping for performance boost. Yesterday I set it to 100%, and in some instances I got 61 fps in my scene.
Okay. So after banging my hand against the wall, adding LODs, removed a ton of polygons and what not, tweaked UVs and textures and what not, without ANY improvement, I finally just switched the project to use a locked frame rate of 60 and now it’s stellar even in situations that made the performance drop quite a lot before. There are some minor fluctuations of the numbers, but I believe this is expected. If nothing else it never goes down bellow 58, and I see 60 quite often.
By “atmosphere” I guess MrScratch meant that skybox we can all see in your screenshot (It is a really heavy material - check it’s complexity in the material editor too much for the gearvr). Try doing a dead simple project - no skybox - just a floor with an ‘unlit’ material and see what FPS you get there.
It’s not complex - it’s a basic sky sphere, static, with no alpha, only one cubemap. If I delete it, fps doesn’t change at all.
Like I said many times, empty scene runs for me at 58 fps / 17 ms render time. What 17 ms is being spent at in empty scene is beyond my understanding. Likewise, why does it take 17 ms to also render 231k static tris, with 6 skeletal animated characters ~1200k tris each. With standard materials.
While this might be the case, the same is happening in a much simpler and lightweight scenarios. Look here
It’s an “empty” scene, easily meets all the recomendations, etc. And still, not getting the expected speed from it.
Only when I locked the framerate to 60 it started to act kinda appropriately, showing 59.45-60fps constantly, but there’s no mention of this being necessary or recommended anywhere, so maybe there’s something else going on that isn’t covered by either Epic’s or Oculuse’s docs that is affecting the performance.
Wow, this thread is already on page 5 (read: forgotten) and there is no feedback from Epic on why on Earth counter shows 17-18 ms in empty scene. Not to mention less than 60 fps in either empty or maxed out scene.
I mean, I get it, Gear VR is not a market to be after right now (and Paragon takes 99.99% of dev time), but if neither Epic nor Oculus step up their efforts to make sure UE4 runs nicely on Gear VR, it will never be a market to cash on
Part of what keeps the high load on the GPU is vsync, as someone mentioned on Answer hub. However, there may be more to it, as u can see here.
Even though that specific post is unity related, and they use locked framerate by default, u can see that vsync actually takes quite some time even when it is working properly.
I don’t know whether the problem in that case is in Unity or Marshmallow… or on the user side of things, but if u lock ur framerate to 60 and test it as a PC preview, u’ll see that the frame still takes around 16ms to show up. For reference, my desktop monitor is also refreshing at 60Hz.
I see. I am guessing it’s necessary for VR? (vsync that is)
Still doesn’t explain 58 fps in empty scene, and 58 fps in maxed out scene. I mean, I wouldn’t complain if there was no requirement to run at 60 fps. It feels perfectly fine to me at 58 fps
How did you manage to output game/frame/draw/GPU timers under fps counter? I’ve been trying to find cmd for that :o
To be honest constant 58fps will be fine for submission - Many apps have occasional drops and they obviously they let it through
If you don’t mention it, it would definitely feel like 60FPS so it would not even be noticed
There are good reasons why vsync is used. It’s not limited to mobile or specific to VR.
The thing with GearVR, it seems, is that the refresh rate of the Galaxy (or the GPU) isn’t faster. I think the reason why we don’t actually see tearing as explained in the video is because of timewarp (ATW) or other VR specific Oculus magic. I tried turning vsync off trough the console but on the device I didn’t see any benefit, since I assume it hits the limits as it is. I don’t have complete understanding of the whole ordeal myself, but this is how it seems to work.
It actually does. It takes 16 ms between frames since the display can’t display stuff faster. If the scene is empty then it simply hangs in there, waiting. If u r withing the requirements (draw calls, poly counts and such) instead of just waiting it uses most of this time to actually do stuff. When u start throwing at it more than it can handle in 16 ms, and u add to this the time it still needs for vsync is when the framerate starts to drop and we see stuttering and all that.
There’s one more thing. Displaying the info overlays actually takes time as well. When I use “stat SceneRendering” for example I get a 2-3ms overhead for this alone, and noticeable drop in FPS. So it could be easy to conclude that “stat FPS/UNIT” aren’t for free, as well.
I’m not an expert on the matter so anyone could jump in and correct me, but this is what I’ve picked up while digging for it this last month.
too much for the gearvr). Try doing a dead simple project - no skybox - just a floor with an ‘unlit’ material and see what FPS you get there.
