I hate to say it, but John Carmack was right when he recommended against using UE4 for Gear VR. While I couldn’t have done what I did for my Gear VR app with Unity in the same time frame, I can never get it to perform well in all circumstances. Now I see why Gear VR apps/games are mostly done using Unity.
I narrowed down performance issue I had with 4.11.2 and it finally ran at stable fps no matter what. Now with 4.12.5 I am in the same pickle, except now there isn’t any way to fix performance issues (at least I don’t see how).
I don’t have HISMCs or foliage in my level. The entire game logic is as simple as it can be - just doing 1 trace and revealing / hiding 1 actor base on trace hit results. Shader complexity is nowhere near to be complex (checked it with viewmode shadercomplexity when in ES2 preview), low number of drawcalls, low number of tris in the view.
When I look around and up in the sky, fps is stable. As soon as I look down to my “feet”, fps drops significantly. There is absolutely no reason for it to do so!!!
Here is a video with profiling results:
I am that close to throwing in the towel either going back to Unity or abandoning mobile VR development altogether.
During development my mobile game CHASERS I came across a lot of problems. Most of them was mobile performance. UE4 is not customized to mobile development in default. You should do this on your own. After release my game I will setup my own blog with advices for UE4 mobile developers. It might be helpful for you. But for now I see this is a problem with landscape. What I discovered during development my game is that setting in DefaultDeviceProfiles.ini:
r.MaxAnisotropy=0
significantly increases mobile performance. Without this setting my game was ~20 FPS on Nexus 4 and with this settings currently is ~60 FPS.
Have you enabled it already?
Moreover, static mesh is better on mobile than UE4 landscape.
What have you done to isolate what the problem is?
Is there some particular mesh that’s the problem? Try deleting one mesh at a time and see if the problem goes away.
Once you know what causes the problem, try figuring out what the problem is.
Are you using landscape materials? Try a simple gray material, and see if the problem goes away.
Is it using large textures without MIP maps? Try turning on MIP maps.
Etc.
You’re not going to know what it is, without systematically eliminating possible culprits.
That’s the only way to have decent quality terrain in VR. Mobile tiled renderer can’t cull meshes like desktop renderer. It cull per bounding box. So if I have solid, unsplit terrain mesh, it will be rendered whole, as long as any part of the mesh is in the view frustum.
By having split terrain you only get pieces, that are in the view frustum, rendered. In other words, terrain split into pieces will render faster than continuous terrain.
Of course there are drawcalls to worry about too. So splitting terrain into 100 pieces would do more harm than good. My terrain is split into 16 pieces, so it’s all good when it comes to draw calls.
Also worth noting that even if I stand at the edge of my terrain so all of the chunks are in the view + all the other actors are in the view, I still get 58+ fps. When I look straight down, theoretically the only thing that should be rendered is that chunk of the terrain I am standing on (since it’s the only thing that is in my view frustum). So performance should not change at all.
Easier said that done. The only thing I can try is to tick my terrain meshes not to be rendered and place a box under player’s location. If that removes the issue, then terrain meshes is what I need to look at (maybe making all chunks but the one player spawns on not renderable and then see what happens).
No landscape or landscape material. Just static meshes with material that isn’t expensive (I used viewmode shadercomplexity to see it in ES2 preview).
1024 x 1024 with mips (Level 4 sharpen or something like that).
Epic could probably have a good guess by looking at the video which shows profiling results. It’s showing CPU stalls. But Paragon stream is tomorrow, so I am guessing no time for Gear VR stuff :o
Ooh, this gets even better I did what I said I’d do - I marked piece of the terrain on which player teleports after spawn as not to be rendered and placed BSP cube under teleport destination. Player spawned, teleported as usual and landed on that BSP cube. Looking down did not drop fps at all. So logically something is wrong with the piece of the terrain, right?
Next thing I did was marking terrain as to be rendered, as by default, but I also left BSP cube in place. It happened that cube was raised above the terrain a bit. So when played got teleported on top of the BSP cube, it ended up being above the terrain. Yet again, looking down did not drop fps !!! However, as soon as I jumped off the cube and onto the terrain, while looking down, fps dropped.
So if I am standing right on top of the terrain, and looking down - I experience fps drop. If I am standing on something above the terrain (and least half of player’s height, but the higher the better) and looking down - there is no performance drop.
Could it be collision of the terrain?
If you turn off terrain collision, and use a flat plane, does it run faster?
Also, if you use 4 levels of sharpening … that’s a lot. Getting closer to the terrain will force the top MIP maps at that point.
Try no sharpening to start with, and see if that helps.
Nah, I don’t think collisions have to do anything with fps drop - I can stand on another (simple) surface but not too far from the terrain and experience fps drop.
What’s the best mip map settings for mobile platform? (there are a way too many options for my taste )
I guess we can conclude that “shader complexity” view is only useful for PC targets, and will not be sensitive enough to tell you about problems on mobile targets?
No, the docs specifically refer to ES2 renderer when using cmd to check shader complexity.
Also, material for terrain remained untouched. I simply disconnected my normal map contraption from it. I can use plain normal map and get no performance drop, but then I will have artifacts produced by the normal map. To avoid artifacts, I have to use this setup. This was not the issue with 4.11.2 and [MENTION=4894]Tim Hobson[/MENTION] was looking into that issue with artifacts. Maybe it’s some obscure case I have going on that Epic didn’t test or didn’t account for. I just don’t see why having plain normal map yields artifacts, but multiplying the same normal map by flat normal map removed said artifacts (also causing performance drop along the way).
That depends on the specifics of the GPU. Many GPUs have a “magic limit” where if you go over it, everything suddenly runs half speed (and if you go over twice that, they run at 1/3 speed, etc.)
Note that, when you unlink the normal map from the material normal input, all the work that feeds into the normal map (texture coordinates, etc) also no longer executes, as well as all the shading work that goes into the normal “slot” in the output material.
This is why I think that, if “material complexity” said you didn’t have a problem, then “material complexity” isn’t sensitive enough for whatever use case you’re running into.
I did what I said I’d do - I marked piece of the terrain on which player teleports after spawn as not to be rendered and placed BSP cube under teleport destination. Player spawned, teleported as usual and landed on that BSP cube. Looking down did not drop fps at all. So logically something is wrong with the piece of the terrain, right?
)
