Unity performance Optimization (4)-Official tutorial optimizing graphics Rendering in Unity games translation

This article is the official Unity tutorial, the Fourth of the Performance optimization series, "Optimizing Graphics Renderingin the Unity Games" translation.

Related articles:

Unity Performance Optimization (1)-Official tutorial the Profiler window translator

Unity Performance Optimization (2)-Official tutorial diagnosing performance problems using the Profiler window translator

Unity performance Optimization (3)-Official tutorial optimizing garbage collection in Unity games translator

Unity performance Optimization (4)-Official tutorial optimizing graphics Rendering in Unity games translation

Brief introduction

In this article, we'll learn what happens behind the scenes in unity rendering, what kind of performance issues occur when rendering, and how to solve and render related performance issues.

Before reading this article, it is important to understand that there is no one-size-fits-all approach to improving rendering performance. Rendering performance is influenced by many factors in our game and is highly dependent on the hardware and operating system our game is running. Most importantly, we solve performance problems by investigating, experimenting, and accurately analyzing the results of performance tests.

This article includes information on some of the most common rendering performance issues, as well as workarounds and links to some extended reading resources. It is possible that there are some problems with our game This article is not covered. Nonetheless, this article will still help us understand our problems and give us some basic knowledge to make it more efficient to find solutions.

A brief introduction to rendering

Before we get started, let's quickly briefly look at what happens when unity renders a frame. Understanding the flow of events and the right time for things to happen will help us understand, research, and work to solve our performance problems.

Note: In this article, we will use "object" to refer to the object being rendered in our game. Any gameobject with a rendering component is called an object.

Basically, the rendering process is as follows:

-CPU calculates what needs to be drawn and how it is drawn.

The-CPU sends instructions to the GPU.

The-GPU is drawn according to the instructions of the CPU.

Now let's take a closer look at what's going on. Later in this article, we'll cover the details of each step above. But for now, let's familiarize ourselves with some of the nouns that will be used, and understand the different roles that the CPU and GPU play in rendering.

The process of rendering is often referred to as a rendering pipeline, which is very helpful for memory. Efficient rendering is about keeping information flowing.

At the time of rendering each frame, the CPU will do the following:

-CPU checks each object on the screen to determine whether they should be rendered. An object is rendered only if it satisfies a certain condition. For example, a part of the collision box must be inside the camera's cone of view. An object that is not rendered is called a culling. For more information on cones and cones culling, please read this page.

-CPU collects information about each object that will be rendered and classifies the data as instructions called draw calls. A draw call contains the grid data and how the grid should be rendered. For example, which texture should be used. Under certain circumstances, some objects of the shared settings may be merged into a draw call. Merging data from different objects to the same draw call is called batching.

-CPU creates a packet for each draw call, called batch. Batch sometimes contains some data other than draw call, but these situations do not usually affect performance, so we will not consider this data in this article.

Each batch must contain a draw call,cpu now will do the following:

-CPU may issue instructions that make the GPU change some of the rendering state variables. This command is called Setpass call. Setpass notifies the GPU what settings to use to render the next grid. Setpass call is called only when the next mesh is rendered, when the render state and the previous mesh are rendered with a change.

-CPU sends the draw call to the GPU. Draw call instructs the GPU to render the specified mesh using the settings defined by the most recent setpass call.

-In certain cases, batch may require more than one pass. Pass is a shader code, and the new pass needs to change the rendering state. For each pass,cpu in batch, you must send a new setpass call and then you must send draw call again.

At the same time, the GPU does the following:

The-GPU processes these instructions in the order in which they are sent by the CPU.

-If the current task is setpass call, then the GPU updates the render state.

-If the current task is draw call, then the GPU renders the mesh. The render mesh occurs in many stages, and the shader code at different stages can define the rendering. This part of the rendering process is very complex, we will not explain in detail, but it is useful to understand the following knowledge: Vertex shader vertex shader tells the GPU how to handle the vertices of the mesh. The slice shader fragment shader tells the GPU how to draw individual pixels.

-This process is repeated, knowing that all CPU-sent tasks are done by the GPU.

Now that we understand what happens when unity renders a frame, let's consider some of the problems that might occur when rendering.

Types of rendering problems

The most important thing to understand about rendering: in order to render a frame, the CPU and GPU must both complete their tasks. Any one of them takes too long to complete a task, which can cause a rendering delay. There are two basic reasons for rendering a problem. The first type of problem is caused by inefficient rendering pipelines. Rendering pipelines can be inefficient when one or more steps in the rendering pipeline take too long to break the smooth flow of data. The inefficient rendering pipeline is called a bottleneck. The second type of problem is because the rendering pipeline is plugged into too much data. Even the most efficient rendering pipeline, there is a limit to the amount of data that can be processed in a frame.

When our game took too long to render a frame, it was because the CPU took too long to complete the rendering task, our game was called CPU bound. When our game takes too long to render a frame, it is because the GPU takes too long to complete the rendering task, our game is called the GPU constraint.

Understanding Rendering Issues

Before we make any changes, it is important to use the profiler to understand the cause of the problem. Different problems require different solutions. It is also important to measure the effect of the changes we make. Fixing performance issues is a balanced effort that improves performance on one side and is likely to have a negative impact on others.

We will use two tools to help us understand and resolve rendering performance issues. Profiler and Frame debugger. They are all built-in tools for unity.

Profiler

The profiler window allows us to see the performance of the game in real time, and we can see many aspects of the game's data, including memory usage, rendering pipeline, scripting performance and so on.

If you are not familiar with using Profiler, see the Unity User's manual This page of the Unity Manual, as well as this tutorial Unity Performance Optimization (1)-Official tutorial the Profiler window translator .

Frame Debugger

Frame debugger allows us to step-by-step to see how a frame is rendered. We can use it to view detailed rendering information, such as what is drawn in each draw call, the shader property of each draw call, and the order of events sent to the GPU. This information helps us understand how our games are rendered and where we can improve performance.

If you are not familiar with frame debugger use, please refer to this page of the Unity Manual as well as this video tutorial this tutorialvideos.

Find the cause of the performance problem

Before we can improve the rendering performance of our games, we must first make sure that our game runs slowly due to rendering problems. If the real problem is caused by overly complex user scripts, then it's pointless to optimize rendering performance. If you are not sure if the performance issue is caused by rendering, refer to Unity Performance Optimization (2)-The official tutorial diagnosing performance problems using the Profiler window translator .

Once we confirm that the rendering is a problem, we must also confirm whether the CPU limit or the GPU limit. There are different solutions to different problems, so it is critical to understand the cause of the problem before attempting to fix it. If you're not sure if your game is CPU-bound or GPU-constrained, refer to Unity Performance Optimization (2)-Official tutorial diagnosing performance problems using the Profiler window translator .

If the CPU is limited

Basically, in a render frame, the CPU's work is divided into three categories:

-Decide what must be drawn

-Prepare the command for the GPU.

-Send command to GPU

These three types of work involve many separate tasks, which may be done through multithreading. Multithreading allows different tasks to execute simultaneously, while one thread executes a task, while another thread can perform a completely different task at the same time. This means that the work can be done faster. When the rendering task is distributed to different threads, it is called multi-threaded rendering.

The unity rendering process is related to three types of threads: the main thread, the render thread, and the worker thread (the main threaded, the render thread and worker threads). The main thread is used for the primary CPU tasks of our game, including some rendering tasks. The rendering process is dedicated to sending commands to the GPU. Each worker thread performs a separate task, such as culling and mesh skinning. Which tasks are executed on which thread depends on the hardware and game settings that our game runs on. For example, the more cores the CPU has, the more worker threads will be generated. For this reason, it is important to perform performance analysis on our target hardware. On different devices, the performance of our game may vary a lot.

Because multithreaded rendering is complex and hardware-dependent, when we try to improve performance, we must first understand which tasks are causing CPU throttling. If our game is running slowly because it takes too long to cull on one thread, it will not help us to reduce the time we send to the GPU command on another thread.

Note: Not all platforms support multi-threaded rendering at this point, WebGL does not support this feature. On a platform that does not support multithreaded rendering, all tasks are performed in the same thread. If CPU throttling is on such a platform, any CPU-optimized work will improve CPU performance. If this is the case for our game, we should read all the chapters below and consider which optimizations are best for our game.

Graphic work Graphics jobs

The graphics Jobs option in Player settings determines whether unity uses worker threads to perform tasks that would otherwise need to be performed on the main thread or the render thread, which provides a significant performance boost on the platform that supports this feature. If we want to use this feature, we should perform a performance analysis on or off the function separately to see how this function improves performance.

Find out which tasks have an impact on performance issues

We can use the profiler to check which tasks are causing CPU throttling. Please refer to ...

Now that we understand what tasks are causing our game CPU limitations, let's look at common problems and solutions.

Send command to GPU

Sending commands to the GPU takes too long to be the most common cause of CPU throttling. On most platforms, this task is performed by the render thread, and individual platforms are executed on worker threads (such as PS4).

Sending commands to the GPU, where the most time-consuming operation is setpass call. If the CPU limit is caused by sending commands to the GPU, then reducing the number of setpass is often the best way to improve performance.

In Unity's render profiler, we can see how many setpass call and batches are being sent. How many setpass call is sent can cause performance problems, and the game's target hardware is very much in the relationship. The number of Setpass call that can be sent on a high-end PC is much larger than the mobile platform.

SetPass call and the number of related batches depend on several factors. This is explained in detail later in this article. In simple terms, it usually looks like this:

-Reduce the number of batches or allow more objects to share the same rendering state, typically reducing the number of setpass call.

-Reduces the number of setpass call, typically improving CPU performance.

If reducing the number of batches does not reduce the number of setpass call, he itself can lead to performance improvements. This is because the CPU is able to process a single batch more efficiently, even if it and several batches contain the same amount of grid data.

Basically, there are three ways to reduce the number of setpass call and batches, and we'll look at each of the following methods:

-Reduce the number of objects to render, which can often reduce the number of Setpass call and batches at the same time.

-Reduces the number of render times for each object to be rendered, typically reducing setpass call

-Reduce the number of batches by merging data from objects to be rendered to fewer batches

Different technologies apply to different games, we will consider all of the above choices, decide which ones are right for our games and make experiments.

Reduce the number of objects to render

Reducing the number of objects to render is the simplest way to reduce batches and SetPass calls. There are several techniques that can reduce the number of objects to render:

-Simply reducing the number of visible objects in our scene is an effective solution. For example, we would like to render a crowd with many characters, we can try to reduce the number of people, if it seems that the effect of the crowd is still good, then this is a faster than other complex methods of optimization method.

-we can reduce the drawing range of the camera by setting the far end of the camera's clipping plane. This property indicates how far away from the camera the object will no longer be rendered. If we want to hide the fact that distant objects are not being rendered, we can try to cover the distance with fog.

-If you need a finer-grained hidden object based on distance, we can use the camera's layer cull distances property, which sets a separate clipping distance for different layers. This method is useful if we have a lot of foreground decoration details. We can hide the details with a very small distance.

-We can use the occlusion culling function to turn off rendering of objects that are obscured by other objects. For example, we have a large building in our scene, and we can use the occlusion culling function to turn off rendering of objects behind it. Unity's occlusion culling does not work for all scenarios, it causes additional CPU consumption, and the settings are complex, but in some scenarios it can greatly improve performance. Best practices for using occlusion culling, thisUnity blog post on occlusion culling good practices.

In addition, we can implement our own occlusion culling by manually closing the object rendering, we can manually turn off the rendering of objects we know the player cannot see. For example, if our scene contains some cut-off objects, we should manually turn off their rendering before they appear or move out. For our game, using our knowledge, manual culling is often more effective than unity's dynamic occlusion culling.

Reduce the number of renders per object to render

Real-time lighting, shadows and reflections can greatly improve the realism of our games, but these operations can be very expensive. Using these features can cause objects to be rendered multiple times, which has a significant impact on performance.

The precise impact of these features depends on the rendering path chosen by our game. The rendering path, which indicates the order in which the calculations are rendered when we draw the scene. The main difference between the different rendering paths is how they handle real-time lighting, shadows, and Reflections. In general, deferred rendering is a good choice if our game is running on a relatively high-end device and many real-time lighting, shadows and reflections are applied. Forward rendering is suitable for low-end devices and does not use the above features. However, if we need to better use real-time lighting, shading and reflection functions, the situation is very complex, it is best to study related topics and experiments. Please refer to this page of the Unity Manua which is a very useful starting point. Please refer to this tutorial , which contains topics related to lighting in unity.

Regardless of which render path you choose, using real-time lighting, shadows and reflections can affect the performance of our games, so it's important to understand how to optimize them.

Dynamic lighting in-unity is a very complex topic, and it is discussed that he is beyond the scope of this article, please refer to this tutorial and this page of the Unity Manual.

-Dynamic lighting is expensive. When our scene contains static objects, such as landscapes, we can use baking techniques to predict the lighting of the scene so that we do not need to calculate the illumination at run time. Please refer to this tutorial and this section of the Unity Manualfor details.

-If we want to use real-time shading in the game, we may be able to improve this performance. This page of the Unity Manual The shadow settings described in this article, and how these settings affect performance. For example, we can set the shadow distance to ensure that only nearby objects cast shadows.

-The reflective probe creates a realistic reflection, but it can greatly affect the number of batches. It is best to use it minimized in performance-sensitive situations and optimize it wherever it is used. For the optimization of the reflective probe, refer to this page of the Unity Manual.

Merging objects for less batches

In some cases, a batch can contain data for multiple objects. In order to be suitable for merging, the object must meet the following conditions:

-Share the same instance of the same material

-Have the same settings (for example, textures, shader,shader parameters, etc.)

Merging the right objects can improve performance, however, all optimization techniques must be carefully analyzed, and the combined consumption does not exceed the performance improvements achieved.

There are several different techniques for merging the right objects:

-Static batching technology that allows unity to merge adjacent, non-moving, suitable objects. A good example is that a bunch of similar objects, such as boulders, can benefit a lot from static batch. To set up static batch in the game, please refer to this page of the Unity Manual.

Static batch results in higher memory consumption, so we measure this cost when optimizing.

-Dynamic batching technology is another technique for unity to incorporate the right object, whether it is motion or stationary. There are restrictions on objects that can be combined using this technique. These restrictions refer to this page of the Unity Manual dynamic batching will affect CPU usage and may cause the CPU to consume more time than is saved. We should measure its cost through practice and pay attention to it when it is used.

-Merging Unity UI elements is a bit more complicated because he is influenced by the layout of our interface. For details, please refer to the This video from Unite Bangkok and this guides to optimizing Unity UI.

-gpu instancing Technology allows a large number of identical objects to be efficiently combined. It is limited in use and not supported by all hardware, but we can benefit from this technique if our game has a large number of identical objects in the scene at the same time. Please refer to this page of the Unity Manual Here for the technical details of GPU instancing in unity and how to use it, which platforms to support, and in which environment our games will benefit from.

-Texture Atlas is the technique of merging large quantities of small textures into a large texture map. It is commonly used in 2d games and UI systems, but it can also be used in 3d games. When we use this technique to create art resources for games, we can make sure that objects share the same atlas and are therefore suitable for merging. Unity has a built-in Atlas tool sprite Packer.

-We can manually merge meshes that share the same material and textures, whether it's in the Unity editor or at run time. When we merge meshes manually, we must realize that shadows, lighting and culling still operate at each individual object level. This means that the performance gains from merging meshes are likely to be eliminated by the objects that could have been removed, and the impact of the merger is offset. If we want to delve into this technology, we should look at the mesh.combinemeshes function, an example of the Combinechildren script in the Unity's standard Assets package.

-In the script, we must use renderer.material carefully, which duplicates the material and returns a reference to a new copy. Doing so will destroy batching if this is part of the merge. Because renderer no longer holds the same material reference. If we need to access the material of an object in the merge, we should use renderer.sharedmaterial.

Culling, sorting, and merging

Culling, collecting data for objects to be drawn, sorting the data, and generating GPU commands, all of which contribute to CPU throttling. These tasks run in the main thread or on a separate worker thread, depending on the settings of our game and the target hardware.

-culling itself consumes little, but reducing unnecessary culling operations can be useful for performance. Culling is the calculation of each object in the scene for each active object, each camera, or even the level of objects that are not rendered. To reduce this, we should turn off the camera and deactivate or disable renderer for objects that are not currently in use.

-batching can greatly increase the speed at which commands are sent to the GPU, but he may sometimes bring consumption elsewhere. If the batching operation results in CPU throttling, we can limit the number of manual or automatic batching operations.

Skin

Skinnedmeshrenderers is used when we use a mesh animation warp (technically known as skeletal animation). It is most used in animated characters. The task of rendering the skin is usually on the main thread or on a separate worker thread, depending on the game settings and the target hardware.

Rendering the skin can be expensive operation. If we are in the render profiler and see that the rendering skins have a significant effect on CPU throttling, here are a few ways we can try to improve its performance.

-we should consider whether the object that is currently using the Skinnedmeshrenderers component is necessary to use. Maybe this is the case, the model we imported contains the Skinnedmeshrenderers component, but we don't really need it to move. In this case, replacing it with the Meshrenderer component will help improve performance. When we import the model in unity, if we choose not to export the animation in the model's import settings, this model will contain a Meshrenderer component to replace the Skinnedmeshrenderers component.

-If we are only moving objects at some point (for example, when the game starts, or only within a certain distance from the camera), we should switch to a less detailed grid, or replace the skinnedmeshrenderers with Meshrenderer. The Skinnedmeshrenderers component has a function Bakemesh, which can be used to create a mesh with a matching action, which is useful for objects that are not visible when switching between grids or renderers.

-These articles have recommendations for optimization using skinning, please refer to this page of the Unity Manual and the Unity Manual page on the Skinnedmeshrenderer Componen T, it should also be remembered that skinning is consumed at each vertex, so using a model with fewer vertices can effectively reduce the effort.

-On some platforms, skins can be processed more efficiently by the GPU than the CPU. If our GPU is strong, this is worth trying. We can turn on GPU skinning for the current platform, in player settings.

Main thread operation and rendering Independent

It is important to understand that many of the main thread's tasks are irrelevant to rendering. This means that if the CPU limit occurs in the main thread, we should put the effort to optimize CPU time to improve performance on and render unrelated tasks.

For example, at a certain point in time, our game needs to do very expensive rendering operations and our script operations on the main thread are very expensive, making CPU throttling. If we have optimized rendering as much as possible without losing visual fidelity, we may improve performance by reducing the CPU consumption of user scripts.

If the game is GPU Limited

If the game is GPU-constrained, the first thing to do is to find the GPU bottleneck. GPU performance is most often limited by the fill rate, especially on mobile platforms, but memory bandwidth and vertex processing can also be affected. Let's examine these problems and learn the cause of the problem, how to diagnose and how to fix it.

Fill Rate

The fill rate refers to the number of pixels that the GPU can render per second on the screen. If our game receives a fill rate limit, it means that our game attempts to draw more pixels per frame than the GPU has the ability to handle.

Checking if the fill rate is causing the game GPU limit is simple:

-Using profiler analysis, note GPU time

-Reduce display resolution in player settings

-Analyze the game again, if performance improves, it is probably the problem of filling rate

If you confirm that the fill rate is causing the problem, there are several ways to resolve the problem:

-Element shader is a piece of shader code that tells the GPU how to draw a pixel. This code GPU needs to be executed for every pixel that needs to be drawn, so if this code is inefficient, then it's easy to have performance problems. Complex element shader is a common cause of filling rate problems.

-If our game uses unity built-in shader, we should use the simplest and most optimized shader in order to achieve the visual efficiency we want. For example, the mobile shaders is Unity's highly optimized shader for mobile platforms, and we should experiment with whether they can improve performance without compromising visual effects. These shader are designed for mobile platforms, but they also apply to any project. If they can be used to achieve the visual effects of the project, then using them on a non-mobile platform can also be a good performance improvement.

-If the objects in the game use Unity's standard Shader, it is important to understand that unity compiles these Shader based on the current material settings. Only those features that are currently in use will be compiled. This means that removing the detail maps, for example, can reduce the complexity of the chip shader, which has great benefits for performance gains. If this is the case in our game, we should practice whether it is possible to improve performance without compromising visual quality.

-If our game is using custom shader, we should optimize it as much as possible. Optimization shader is a very complex subject, please refer to this page of the Unity Manual and this page of the unity Manual.

-overdraw refers to the same pixel that was drawn multiple times. This occurs when objects are drawn on top of other objects, and also to a large extent caused by the filling rate problem. To understand overdraw, we must first understand the order in which unity paints objects in the scene. The shader of an object determines the order in which objects are drawn, usually determined by the render queue property. Unity uses this information to draw objects in strict order, for details please refer to page of the Unity Manual In addition to different render queue objects will be sorted in different order before they are drawn. For example, unity in the geometry queue minimizes overdraw to sort objects from the front to the back, but in the transparent queue, the object is sorted from the back to the front in order to achieve the desired visual effect. In the transparent queue, sorting objects from back to forward actually maximizes the overdraw. Overdraw is a very complex subject, and there is no one-size-fits-all solution, but reducing the number of overlapping objects makes unity impossible to sort automatically is the key. The best starting point for investigating overdraw problems is Unity's scene view, where DrawMode allows us to see the overdraw in the scene, and we can start by reducing Overdraw's work. The most common factors that cause overdraw are transparent materials, non-optimized particles, and overlapping UI elements. So we should try to optimize these. Please refer to this article article on the Unity learn site which focuses on the UI, but also contains a good guide to Overdraw.

-The use of screen post-processing technology also greatly affects the fill rate, especially when we use more than one kind of screen post-processing. If we're having a fill rate problem with screen post processing, we should try different settings or use a more optimized screen post-processing version. For example, replace Bloom with Bloom (Optimized). If we use multiple screen post processing under the same camera, this will result in multiplying the shader pass. In this case, we should merge shader to a separate pass, such as Unity's postprocessing Stack. If there is still a fill rate problem after we optimize the screen post-processing effect, then we might want to consider turning off screen post-processing, especially on low-end devices.

Memory bandwidth

The memory bandwidth refers to the speed at which the GPU reads and writes its dedicated memory. If our game is limited to memory bandwidth, it usually means that the textures we use are too big to be processed quickly by the GPU.

We can check if the memory bandwidth problem is as follows:

-Analyze the game with Profiler and focus on GPU time

-Reduce the texture quality of the current platform in the quality setting

-Continue to analyze the game, if the performance is improved, then the memory bandwidth is usually a problem.

If this is an issue with memory bandwidth, we need to reduce the memory footprint of the textures. There are often different best solutions for different games, and here are a few ways to optimize textures:

-Texture compression technology can greatly reduce the size of textures in disk and memory at the same time. If this is an issue with memory bandwidth, then using texture compression to reduce the size of the texture in memory can help improve performance. There are many formats and settings available for texture compression in unity. In general, some texture compression formats should be used as long as they are available, although it is best to practice finding the most appropriate setting for each texture. Please refer to this page in the Unity Manual For detailed information on the format of texture compression and various settings.

-Multilevel gradient texture, which is a low-resolution version of Unity's use of objects far away. If our scene contains objects that are far away from the camera, we can alleviate the problem of memory bandwidth by using a multistage gradient texture. The Mipmaps Draw mode in the Unity Scene view allows us to see which objects benefit from the multi-level gradient texture, please refer to this page of the Unity Manual contains detailed information on using a multistage gradient texture.

Vertex processing

Vertex processing means that the GPU must render the work of each vertex in the mesh. The consumption of vertex processing is affected by two things: the number of vertices that must be rendered, and the number of operations to be performed on each vertex.

If our game is GPU-bound and has confirmed that it is not a problem caused by the fill rate and memory bandwidth, it is most likely caused by vertex processing. If this is the case, then trying to reduce the number of GPU vertex processing is likely to get a performance boost.

There are ways to reduce the number of vertices or the number of operations performed on each vertex:

-First, we should reduce the complexity of unnecessary meshes. If we use a grid that contains LOD that cannot be seen in the game, or if the inefficient mesh contains too many vertices when the error is created, this will waste the GPU's effort. The most straightforward way to reduce the consumption of vertex processing is to use a smaller number of vertices when creating models in 3d modeling software.

-We can try using the normal mapping technique, which we use to simulate a mesh with a higher degree of geometric complexity. Although using this technique has some GPU load, in most cases it gains performance. Please refer to this page of the Unity Manual describes the use of normal mapping techniques to simulate more complex meshes.

-If our game does not use normal mapping technology, in the grid's import settings, we can turn off the vertex tangent. This reduces the amount of data that the GPU processes vertices.

-lod (level of detail), which is the technique of reducing the complexity of an object's mesh when the object is away from the camera. This effectively reduces the number of vertices the GPU needs to render and does not affect visual performance. Please refer to the specific usage details. The LOD Group page of the Unity Manual .

-Vertex shader, a shader code that tells the GPU how to draw each vertex. If our game is limited by the impact of vertex processing, then reducing the complexity of vertex shader may help improve performance.

-If our game uses unity built-in shader, we should use the simplest and most optimized shader in order to achieve the visual efficiency we want. For example, the mobile shaders is Unity's highly optimized shader for mobile platforms, and we should experiment with whether they can improve performance without compromising visual effects.

-If our game is using custom shader, we should optimize it as much as possible. Optimization shader is a very complex subject, please refer to this page of the Unity Manual and this page of the unity Manual.

Conclusion

We've learned how to render in unity, what might happen when rendering, and how to improve the performance of rendering in our games. Using this knowledge and profiling tool Profiler, we can fix rendering-related performance issues, and build our games to make them a smooth and efficient rendering pipeline.

Below is a list of resources related to this topic

Extended Reading

Unity Learn:a Guide to optimizing Unity UI

Unity knowledge base:why is my static batching breaking or otherwise not working as expected?

Fabian giesen:a trip through the graphics pipeline

Simon Schreibt:render Hell

Gamasutra:how to choose between Forward or Deferred rendering paths in Unity

gamasutra:batching independently moving gameobjects into a single mesh to reduce draw calls

Flamebait games:optimizing skinnedmeshrenderers for Unity 5

Pencil Square games:reducing Draw calls (also named SetPass calls) in Unity 5

Unity performance Optimization (4)-Official tutorial optimizing graphics Rendering in Unity games translation