Balancing fidelity and performance with the limitations of mobile hardware can be challenging. The sections below detail settings and tools Unreal Engine (UE) provides to adjust your performance, including console variables you can set in your device profiles, and tips for how to use them.
Preview Platforms
Your Preview Platform is the target platform that you want Unreal Editor to imitate in its viewports. The in-editor preview platform is an approximation of what your application will look like on a target platform. It is important that you test on the actual device, the Android emulator in Android Studio, or the iOS emulator in Xcode for more accurate testing. However, the preview platform will give you the quickest idea of what your visuals should look like directly from the editor.
To set your Preview Platform, follow these steps:
Click the Settings button in the editor's main toolbar.
Highlight the Preview Platform sub-menu.
Select the platform that you want the editor to emulate.
Unreal Editor will take some time to re-compile shaders for the new platform, but once it's done, your visuals should reflect the device profile for the selected preview platform. You can also load a .json file from your test device to get an even more fine-tuned preview with that device's specific device profile and settings.
For more information about setting up your Preview Platform, see the Mobile Previewer documentation.
For Android and HMI developers, UE supports Vulkan rendering feature levels. See the Android Vulkan Mobile Renderer page for more information about Vulkan compatibility in UE.
Rendering Settings
This section details rendering settings you can use to adjust your application's balance between performance and fidelity. These incur large-scale trade-offs of your rendering quality, but can result in big improvements to your framerate and stability due to how much they can lower rendering overhead.
Screen Percentage
Screen percentage controls how much of your viewport's native resolution you are using to render frames.
For example, say your viewport is rendering in a 3840x2160 window:
If you set your screen percentage to 100, it will use the full 3840x2160 resolution of the viewport.
If you set your screen percentage to 50, it will use only 50% of that, which comes out to 1920x1080
Screen percentage at 15%, 50%, and 100%.
Reducing your screen percentage will make your application render faster, but it will look noticeably less detailed compared with when you use the full resolution.
You can't set the screen percentage in Editor mode when running Unreal Editor. However, you can set it when using Play In Editor or when running a packaged build.
To change the screen percentage in the editor, open the scalability menu while playing, then use the Screen Percentage slider to change it. To set it in real time with the console, use the r.ScreenPercentage variable. A value of 100 for this variable equates to 100%.
Each scalability setting has a default screen percentage. You can override it at runtime as needed to improve rendering performance or fidelity.
Maximum Framerate
You can set a maximum framerate by changing the CVar t.MaxFPS. Your application will only render frames per second up to the value you set. For example, t.MaxFPS 30 will make 30 frames per second the fastest framerate you allow your application to run.
You can change this value at runtime to vary your rendering speed. For example, if your application is idling and the screen is off, you can set t.MaxFPS to 5 until the user starts to interact with the screen, then set it back to a higher framerate. If your application is mainly displaying information that comes in slowly, such as GPS data, you can limit your MaxFPS to 30 or less without impacting the user's experience much. We encourage you to think critically about how and when your application requires a higher framerate versus when you can strategically lower it.
Scalability Settings
Scalability Settings provide presets for rendering features in UE and offer the simplest way to tune your project's performance while in the editor. Each scalability setting can be changed to a preset that changes a subset of graphics settings to favor higher or lower fidelity. UE comes with these already configured based on the hardware that exists at the time of each release.
To view your current scalability settings in Unreal Editor:
Click the Settings button in the editor's main toolbar.
Highlight the Engine Scalability Settings sub-menu. Choose your preferred Scalability Group; Low, Medium, High, Epic, or Cinematic.
Scalability settings adjusted in the editor only affect your local editor behavior, not final builds.
You can learn more about scalability settings in Introduction to Performance Profiling and Configuration and the Scalability Reference.
Lighting and Shading
Mobile devices have especially limited resources for processing lighting and shadows, therefore it is important to choose the shading mode best suited for the environments in your project. Your key consideration is how much your project relies on static lighting or dynamic lighting.
Mobile Shading Modes
The mobile shading modes provide alternate implementations for a variety of lighting and shading effects, optimized specifically to take advantage of tile memory on mobile hardware.
Mobile Deferred: Computes lighting information in its own pass after handling geometry.
This provides superior lighting features and improved performance in projects that use dynamic lights, as it greatly reduces the number of material instructions the renderer handles.
Mobile Forward: Computes lighting information at the same time as geometry.
This provides less flexibility with lighting, but in projects that use precomputed lights, it provides faster performance and less overhead.
For a more detailed breakdown of the Mobile shading modes, refer to Rendering and Shading Modes. We recommend Mobile Forward for most projects, as it offers the best performance and most of the render features of Deferred. You should investigate which shading mode will give you the best performance and how it will impact your technical art.
Lumen and Static Lighting
The Lumen lighting system provides high-performance global illumination intended for game consoles and gaming PCs. When activated, it uses a combination of ray tracing and screen space lighting effects to simulate light in real time.
Lumen is available for mobile devices, but is considered experimental due to its high resource demands on mobile hardware. You can experiment with it, but we recommend against shipping with Lumen in any context where performance is a priority.
For more information about Lumen, see Lumen Global Illumination and Reflections. See Lumen on Mobile for information specifically about using Lumen in a mobile environment.
Materials and Shaders
The amount of materials IDs and their complexity can affect the number of draw calls in your project. Draw calls are lookups for assets that occur every frame. A high number of draw calls is the biggest contributor to low graphical performance.
In HMI, 100 draw calls is a good target on a Galaxy Tab S6, and less than 50 is preferable. You can output your draw call count with the console command Stat RHI.
Keep in mind that draw call count will change based on whether you are in PIE or on a device.
The following sections describe factors that affect draw calls and how to mitigate them.
Reducing Material ID Count
You can reduce material ID count in the following ways:
Using an external program, like Photoshop, Substance Painter, or Substance Designer, you can combine multiple physically-based rendering maps (roughness, specular, metallic, and more) into a single texture. This is often referred to as packing a texture.
Using masks to designate which parts of a mesh’s UVs receive different settings. Masking can be done using alpha textures or vertex color. Vertex color is often more efficient but only offers control at the vertex level.
For more information on the different methods for applying multiple material types to a single asset, see Materials.
Reducing Material Complexity
Material complexity can increase the pixel cost of a render. The more instructions there are for each pixel, the more render time is needed.
You can reduce material complexity in the following ways:
Reduce the number of math functions within the material.
Reduce the number of high-cost nodes.
Selective use of high-cost settings such as Fogging, Fog Per Pixel, Surface Forward Shading, Two Sides, Screen Space Reflections (SSRs), shadows, and more.
Selective use of high-cost Material Properties, Material Domains, and Blend Modes such as translucency.
You can check on the complexity of your materials by clicking the Stats tab in the Material Graph:
For more information on Material Properties, see Material Properties.
Reducing Texture Size
High-resolution textures require a lot of space to store on a device and in a device's texture memory. They also require more pixels to render and process. For example, depending on the platform, high-resolution normal maps can have a higher performance cost than a high-polygon model. Ideally, you compress high quality textures in the engine to reduce overhead while still achieving the desired fidelity.
To compress textures using Max Texture Size, follow these steps:
Open your texture in the Texture Editor.
In the Details panel, under the Compression heading, expand Advanced.
Set Maximum Texture Size to the desired number.
A method for mitigating this issue is by using a special debug texture to determine what resolution is necessary for different components of an asset.
For more information on this method, see Rendering Optimization for Mobile
Using Half and Full-Precision Shaders
By default, mobile devices process mathematical operations in materials with half the precision that desktop devices do. This means that there are fewer decimal places to work with when doing calculations. This saves memory and processing, resulting in faster rendering, but it also can result in visual artifacts like banding.
To get around these issues, open your material, and in the Material Properties panel, enable the Use Full Precision setting.
This will force the material to use the highest level of precision available on the mobile device. To ensure that your application does not sacrifice too much performance, you should only use this setting for important materials where the effects will noticeably impact the user's experience.
PSO Caching
PSO Caching caches the pipeline state of objects rendered in your world so that users don't have to rebuild their shaders during runtime. This reduces hitches during play.
For more information on PSO caching for Android, see PSO Caches.
Post-Processing
Unreal Engine supports a wide variety of Post-Processing Effects that can enhance the look and feel of your application. However, you should evaluate and balance these carefully in a mobile context. This section provides guidelines about post-processes that commonly result in performance bottlenecks.
Ambient Occlusion and Baked Ambient Occlusion
Ambient Occlusion (AO) is a technique that simulates how ambient lighting creates indirect shadows on an object. While it yields more realistic and visually-appealing rendering results, it can be an expensive operation.
A less expensive alternative is using baked ambient occlusion. Modeling tools like Maya, 3DS Max, and Blender have the option to produce ambient occlusion maps. You can import an ambient occlusion map into UE and factor it into your materials to add ambient occlusion shadows to an object without having to process it live.
Configuring Mobile Ambient Occlusion
Whatever method you use for ambient occlusion, you can adjust mobile-specific ambient occlusion settings with the following console variables. These can be set in your config files or your device profiles as needed.
| Console Variable | Description | Values |
|---|---|---|
| When enabled, uses an extra sampler in the base pass pixel shader for ambient occlusion. | 0: Disabled (default) 1: Enabled |
| When enabled, mobile AO will use depth bounds to cull distant pixels during the AO pass. This option is only valid when the pixel shader path is used (see | 0: Disabled (default) 1: Enabled |
| The quality level for screen-space ambient occlusion on mobile platforms. | 0: Disabled 1: Low 2: Medium 3: High |
| Chooses the shader type used by mobile ambient occlusion. | 0: Compute Shader 1: Separate Compute Shader 2: Pixel shader (default) |
| Chooses between Ground Truth Ambient Occlusion (GTAO) or Screen Space Ambient Occlusion (SSAO). GTAO is computationally more expensive, but provides higher-quality results, while SSAO is simpler and performs faster. | 0: GTAO (default) 1: SSAO |
Anti-Aliasing
Without any post-processing, rasterized images have hard edges due to the way pixels display on the screen. This results in a "jaggy" appearance, called aliasing. Anti-aliasing smooths pixels together, softening the hard edges of objects rendered. This adjustment can make images read as more realistic.
UE supports multiple anti-aliasing methods, each with its own benefits, tradeoffs, and configuration settings. For more information about UE's anti-aliasing options, see Anti-Aliasing and Upscaling.
The following sections are summaries of the anti-aliasing types available for the mobile rendering pipelines.
Temporal Anti-Aliasing
Temporal Anti-Aliasing (TAA) smooths edges by using information from the previous rendered frames. This approach uses less processing than multi-sample anti-aliasing (see below), but requires some memory to store prior frames. This is similar to how a motion blur post-processing effect works, so it can add a slight blur to images (called ghosting) especially if your framerate is low. The more change that happens onscreen, the more likely you will see ghosting. UE's implementation of TAA can use anti-ghosting algorithms to clean this up, albeit for an additional processing cost. You can also use a variety of settings to adjust the frame history.
You can use the following console variables to configure TAA:
| Temporal AA Console Variable | DescriptionDescription | Values |
|---|---|---|
| Quality of the main temporal AA pass. | 0: Disable input filtering. 1: Enable input filtering. 2: Enable more input filtering as well as motion-based anti-ghosting. (Default) 3: Quality level 1 input filtering, but with anti-ghosting enabled. |
| Forces the temporal AA to only use one of the frames it sampled. | Values greater or equal to 0 pick which sampled frame index to use. Default value is -1. |
| Screen percentage size of temporal AA's history. | 0-100, as |
| If enabled, temporal AA uses a compute shader for higher quality. If disabled, uses pixel shader to save bandwidth for FBC on tile-based GPUs. | 0: (disabled) 1: (enabled) |
| Whether to do primary screen percentage with temporal AA or not. | 0: Use spatial upscale pass independently of AA. 1: Temporal AA performs spatial and temporal upscale as screen percentage method. (Default) |
| Chooses the upscaling algorithm to use with temporal AA. | 0: Forces the default temporal upscaler of the renderer. 1: Uses |
| Chooses whether to use the mobile Temporal AA configuration. This disables groupshared caching of the color and depth buffers. | 0: Disabled (Default) 1: Enabled |
| If enabled, uses a catmull-rom filter kernel, which should be sharper than the default gaussian filter kernel. | 0: Disabled (Default) 1: Enabled |
| Weight of the current frame's contribution to history. Lower values cause blurriness and ghosting, high values fail to hide jittering. | 0-1. Default value is 0.04. |
| Size of the filter kernel. | Floating point between 0 and 1. A value of 1 is smoother but blurrier, 0 is sharper but more aliased. Floating point between 0 and 1. A value of 1 is smoother but blurrier, 0 is sharper but more aliased. |
| Number of jittered positions to use for temporal AA. | Integer values that are powers of two, between 4 and 64. Default value is 8. |
| Whether or not to scale the number of jittered positions for temporal AA when upsampling. This helps maintain a consistent density. | 0: Disabled 1: Enabled (Default) |
Multisample Anti-Aliasing
Multisample Anti-Aliasing (MSAA) smooths edges by sampling the image multiple times, then averaging all the samples together. This is more expensive, but produces high-quality results. You can configure the number of MSAA passes with the console variable r.MSAACount, which takes values between 0 and 8. The higher the number of MSAA passes, the greater the amount of GPU memory it will use.
| r.MSAACount Value | Description |
|---|---|
0 | MSAA Disabled (Temporal AA enabled) |
1 | MSAA Disabled |
2 | Use 2x MSAA |
4 | Use 4x MSAA |
8 | Use 8x MSAA |
Multisample anti-aliasing is only supported when using mobile forward rendering, not mobile deferred.
Fast Approximate Anti-Aliasing
Fast Approximate Anti-Aliasing (FXAA) is a spatial-only anti-aliasing technique and post-processing effect. It uses a high contrast filter to find edges and smooth them by blending (dithering) between the pixel edges. As the name suggests for this technique, it is fast to render and well-suited for low-end devices and desktops. While this technique is fast to render, the final image can lose fidelity when compared to other anti-aliasing techniques.
| r.FXAA.Quality | Description |
|---|---|
0 | Console |
1 | PC Medium dithering using 3 samples |
2 | PC Medium dithering using 5 samples |
3 | PC Medium dithering using 8 samples |
4 | PC Low dithering using 12 samples (Default) |
5 | PC Extreme dithering using 12 samples |