I took the “first person shooter” sample project, turned off mobile HDR and deleted the postprocess object from the scene, and was still getting <10fps on a 2012 Nexus 7.
After minimizing the scene even further, I’m “up to” 20fps most of the time, but still dropping to <12fps on this ridiculously simple and empty scene:
The internet claims this is running a Tegra 3 with 12 cores at ~400MHz / core, which seems like it should be plenty of computing power for this ‘almost empty’ scene. What am I doing wrong? Is UE4 just not ready to run on tablets? Is there a plan to get to reasonable performance, and if so, what tablet should we be using for development in the meantime?
Tegra 3 is untested I believe, UE4 is much newer than that and has been developed around the later line of Tegra chips I believe. While Epic are always trying to improve the engines’ performance, it is a next-gen engine and as such you’re likely to find issues developing even on relatively new hardware.
After posting on Friday I created my own materials for everything, set them to Unlit, removed the skybox, and implemented a simple N dot L directional light in the material editor, which got me to 60fps (but no more shadows, sadly):
Using any of the ‘lit’ materials kills the performance. I’ll investigate further when I have time to see if I can narrow down the cause, but this is good enough to start working on gameplay.
My earlier question is still relevant: are there any Android tablets Epic recommends for development in the meantime while Android performance matures?
The default UE4 lighting is targeted at the latest high end devices. For 2013 and older devices, shading performance is often very poor and you need to adjust your materials accordingly. First, enable the “show mobile stats” in the material editor so you can view the number of shader instructions for mobile. You should target your materials to be under 30 shader instructions and 3 samplers.
Don’t use any of the existing UE4 materials, they are way too complex. The “no material” material, for example, has over 80 instructions.
Avoid dynamic and stationary lights. Use static ones, they generate the least amount of shader instructions.
Don’t use normal maps or specular on surfaces that cover large amounts of pixels like walls, floors and other large architecture.
If you’re not using specular, set the material to “fully rough” and disable “use lightmap directionality”. This will generate a shader with only 23 instructions for static geometry.
Yes, you won’t get shadows for dynamic objects from static lights, so you’ll need to work on blob shadows or something like that. Stationary lights have fantastic quality and merge shadows from static objects and dynamic ones, but they are quite GPU intensive for older mobile devices.
I have the same tablet, if you just have a fully unlit scene it performs very well. However a scene with 1 static light and < 1000 polygons brings the FPS down to 35. No shadows or anything fancy. It’s amazing that a single precomputed light can kill the performance so badly… I don’t know what’s going on in the background. And if you make the light stationary or movable, the FPS will make you cry!
The number of polygons isn’t the problem, it’s the shader instruction count. That’s the #1 bottleneck on low-end mobile devices: shading performance is often terrible. To make sure your static lights generate the simplest materials as possible, make sure to enable “Fully Rough” and disable “Use Lightmap directionality” in the “mobile” section of your materials. Also plug a “0” constant to the specular output pin. This means you won’t be using normal maps either. I’m getting solid 30fps with 50k polygons on a ****** Android tablet we bought for testing.
I already had fully rough checked, but disabling lightmap directionality did help a bit as well. I’m curious, how many objects do you have that make up the 50k polys? With 15 objects I am getting about 35 FPS, but with just one it can reach 50+. So I’m thinking a good strategy for performance might be to have larger meshes with larger textures so that fewer lightmaps have to be drawn. Although performance with the lightmap also might be fillrate dependent, guess I’ve got something to test at least.
Why I am disappointed overall at least (aside from so many small tweaks you have to hunt for to gain performance) is that UDK 3 Android games run very performant with much more complex scenes. I’ve mentioned this elsewhere, but for example Epic Citadel with lightmaps, many different meshes and materials, reflections, moving trees, animated water… running the benchmark for quality nets an average of 54 FPS, where with such a simple scene in UE4 on the same hardware I cannot. It just feels like they’ve abandoned support for older hardware in their quest ever forward. And that might not be a bad thing, but it certainly is a reason to reconsider UE4 for mobile depending on your desired minimum spec. But I do not have the desire to do engine level performance profiling, even with the engine source.
The large rocks are static meshes (as seen on the inspector), the ground is a terrain (only two texture layers) and the small props were placed using the vegetation tool: they don’t receive lightmaps, but cast shadows and seem to be very lightweight. They also move around when I modify the terrain or move the static meshes they are sitting on, which helps a lot.
If you want to show the FPS on a device, the easiest way I’ve found is to edit the level blueprint, add a Begin Play node, and attach a Console Command “stat fps”.
pedro_clericuzzi
I’ve found the performance of static lighting greatly depends on the type of light… point is much slower than directional, for instance. Also I’m sure because most of your objects do not have lightmaps greatly increases performance. It is certainly interesting to think about designing levels where many objects do not need lightmaps to look decent.
That is how many milliseconds it takes to draw 1 frame. There are 1000 milliseconds in a second. In your case you have ~32ms per frame. If you divide 1000 by 32, you will get your frames per second (~31).
I’ve only used directional lights so far, so that might explain it. However, static point lights shouldn’t have any additional cost. I just tested on my scene and when set to static and after building the lighting, the point light does not seem to affect movable objects directly.
You may be right about the non-lightmapped materials for “props”. The lightmapped materials have less ALU operations, but have one extra sampler and also won’t batch as nicely due to each object getting a different lightmap. So it might be worth looking into saving lightmaps only for large structures and keep smaller props as vegetation/movables.
If you want more info about where your bottlenecks are in addition to the STATS FPS command use the STATS UNITS command. This one will give you the time for your game/render/draw threads and GPU time.
But if you come back to mobile, you can have great game ready in 2020 when tablets have power of 2010s PCs, and “Doom the flashlight simulator” will be possible.
Btw. very bad performance on my old samsung tablet made me thinking about getting new nvidia shield one. Developing serious game takes about 2 years, and in 2 years even mid range devices will have such power.
