Core performance

Mobile performance optimization with Adaptive Performance 4.0

Boat Attack starts off with plenty of scalers engaged by the menu scene, which was stabilized before the capture was done. In this example, the temperature rises quickly and the device goes into throttling. Adaptive Performance tries to stabilize the situation and reduce effects on the GPU, as this is clearly the bottleneck. The shadow scalers thereby reduce quality rapidly – but because that’s not enough, both the view distance and resolution decrease as well. The frame rate then stabilizes and the temperature drops. The game is rescued from throttling and its frame rate raises to 60 fps. Layer culling scaler With the layer culling scaler, you can dynamically adjust layer cull distances at runtime. This feature uses the indexer system to make certain decisions, like when and how much to increase or decrease layer cull distances for optimal performance and thermal stability. The sample we ship with Adaptive Performance loops in medium CPU load until it reaches critical frame rates and then decreases the cull distance of layers. The result of this is that the cull distance for layers changes depending on the CPU and GPU load. You can set a different value for the culling distance of each layer so that they scale proportionally. This helps you determine which objects to cull earlier to save performance. For details on how to do this, see the following code sample. Adaptive decals Adaptive decals target visual effects. In Amazing Adventures of Dr. Arm, there is a boss fight scenario that uses many particles and decal projectors. When the mobile device gets hot and throttling is imminent (or already occurring), the number of particles emitted scales down. In this case, less visually important emitters, things like the leaves blowing in the wind, tiny sparks, and other such elements, turn off completely. The scaler also reduces decal distances.

Read More

Profiling in Unity 2021 LTS: What, when, and how

Profiling is like detective work, unraveling the mysteries of why performance in your application is lagging, or why code is allocating excess memory. Profiling tools ultimately help you understand what’s going on “under the hood” of your Unity project. But don’t wait for significant performance problems to start showing before digging into your detective toolbox. The best gains from profiling are made when you plan early on in your project’s development lifecycle, rather than just before you are about to ship your game. It’s an ongoing, proactive, and iterative process. By profiling early and often, you and your team can understand and establish a “performance signature” for the project. If performance takes a nosedive, for instance, you’ll be able to easily spot when things go wrong, and quickly remedy the issue. You can also make before-and-after performance comparisons in smaller chunks by using a simple three-point procedure: First, establish a baseline by profiling before you make major changes. Next, profile during the development to track performance and budgeting, and finally, profile after the changes have been implemented to verify whether they had the desired effect. You should aim to profile a development build of your game, rather than profiling it from within the Unity Editor. There are two reasons for this: The data on performance and memory usage from standalone development builds is much more accurate compared to results from profiling a game in-Editor. This is due to the Profiler window recording data from the Editor itself, which can skew the results. Some performance problems will only appear when the game is running on its target hardware or operating systems, which you’ll miss if you profile exclusively in-Editor.

Read More