In this chapter, you will learn how to optimize your game or application during development with Unity3D. There are several factors that need to be kept in mind to run the app or game smoothly. We will handle optimization using Physics best practices. Although, this chapter will cover Physics tricks primary to handle the performance optimization, you will learn other Unity3D tricks for performance handling as bonus topics.
We will cover the following topics:
- Developing an optimized application and game
- Checking performance
- Moving the static collider
- Mesh Colliders
- The complex collider shape
- Rigidbodies
- Joints
- The Cloth component
- Optimized graphics
- Low timestep
- Pros of performance optimization
Performance is a critical factor for games and applications, and for a fast-paced action game, it becomes the key point. For those features where fast Physics combined with fully animated characters and a 3D world are required, performance optimization is the most important factor. Any game or application needs 60 frames per seconds of performance, and so we will need to optimize our game for target devices to achieve that.
Unity Profiler is the first thing that we should use to check the performance of a game or application. Profiler is a great tool that comes with Unity Pro, using which we determine where any frame rate issues are coming from.
Profiler uses a graph to show the CPU usage while we play the game. Profiler is divided in categorizes such as Rendering, Scripts, Physics, Garbage Collector, VSync, and others. This is how it looks:
Now, let's see how we handle optimization during the Physics implementation.
To make less expensive performance, we should avoid moving static colliders. You learned in previous chapters that a static collider is a game object with a collider component on it; however, it does not have a Rigidbody component. Moving static colliders is one of the top causes of performance issues in Unity games and it is expensive. If we need to create them with codes, we should add the collider and Physic Materials after its positioning.
Mesh Colliders are slow compared to the primitive Box/Sphere Collider. A sphere has many more vertices than a cube but the uniform distance from the center makes the calculation much easier in comparison to the many individual triangles. Mesh colliders have a much higher performance overhead than primitive colliders.
To get better performance for more complex shapes, we should combine primitive colliders. Let's have a look at an example. If we have a parent object with a Box Collider and Rigidbody component, we should add child objects with just a Box Collider. The collision for an entire object will have one multipart object. Rather than having several objects linked together, we can add more child objects with Rigidbodies and colliders and use joints to connect them to the parent object. As shown in the following screenshot, we used a Capsule Collider for the complex object:
Less use of Rigidbodies and materials saves performance. Again, the use of interpolation and extrapolation on Rigidbodies is discouraged all together. The total amount of Physics calculation depends on the number of nonsleeping Rigidbodies and colliders in the scene and the complexity of the colliders. We should handle performance by reducing calculation as much as possible.
We cannot use multiple basic joints on one game object as it is not supported, but we can use multiple configurable joints, which helps a lot in performance optimization. Rather than having a network of joint objects, we should use configurable joints wherever possible to avoid unnecessary memory consumption.
The use of multiple Cloth components in one game is very expensive so should minimize the use of multiple Cloth components.
A lower frame rate gives breathing room and helps in memory optimization. I personally find a 0.03 fixed timestep with a maximum of about 0.05 to be good for better performance. We can reduce the time spent on Physics updates by adjusting the fixed timestep setting. Increasing the timestep will reduce the CPU overhead but sometimes, the accuracy of Physics gets affected.
Precalculation during development can be very important to achieve high performance and make certain effects possible. Taking the approach of calculating as much as possible at the start of execution can have a great impact on performance.
Apart from Physics-based performance optimizations, there are other factors too that we should use to optimize our game or app. Let's have a few examples.
Performance optimization depends upon how fast we can render by GPU, which is mostly limited by the number of pixels rendered and by the memory bandwidth. The CPU performance is also limited by the amount of draw calls processed. We can use GPU Profiler to find out how much time and how many draw calls are in the scene. To save rendering time, we should remove as many draw calls as possible.
As shown in the following screenshot, by clicking on Stats, we can see the Statistics window:
To improve CPU performance, we should take into account the following points:
- For high performance, don't use more than a few hundred draw calls per frame while draw call counts vary for older devices
- By combining nearby objects into single meshes, we can reduce draw calls
- By using automatically Unity's draw call batching, we can reduce draw calls
- Using fewer different materials enables better batching of meshes
- By using a textures atlas where possible, we can reduce draw calls
To improve GPU performance, we should note the following points:
To make a big impact on project completion, from the initial phase of project, we should use slow but safe option of Script Call Optimization. Using this unhandled exception will crash the Unity build but if handled, we can get a higher performance at the end of the project. To apply this, navigate to the Player setting and select iOS as shown in the following screenshot:
There are some simple rules for handling performance such as:
- Pixel lights are too expensive, so we should avoid them to get high performance
- Keep your draw call count low because graphics rendering is CPU expensive
- We should mark the objects that don't move as static
- For moving objects, try to keep the vertex count below 300
- We should avoid instantiating or destroying objects in runtime as the memory is slow
- Avoid alpha because it rejects pixels on iOS devices and it is slow; use alpha blend instead