Game rendering performance optimization and rendering performance optimization

Game rendering performance optimization and rendering performance optimization

I forgot whether I have written similar articles before. No matter what, I 'd like to sum up my experience in recent years.

Start with the core part. If you are familiar with the graphic API, you can understand that to render a model, we need to do at least two operations, set various States, and call the drawing function. Both operations will cause performance loss. Let's talk about it separately

Set various statuses first. What is the status, such as what texture is used, what coloring tool is used, whether Alpha testing is enabled, whether it is displayed on both sides, whether it is mixed, and how it is mixed, etc. We can refer to these statuses as materials. This information is set to the video card by calling the graphic API and then using the driver. This takes time, and some status changes are time-consuming.

So how can we optimize it? Where can we solve the problem? Simply put, we can minimize the changes in the status!

For games, the first reason for changing the status is the difference in texture, Which is why texture packaging is required. For example, if three models correspond to three textures respectively, the three textures are set for each model during rendering, which changes the texture state. If you place the textures of these three models on a single texture, you only need to set one texture and then render them separately. This saves two texture switching times. The same principle applies to Shader.

If it is a self-developed engine, more things can be done

1. Abstract A graphic API layer, in which the status is cached. When the same API is called multiple times and the content is consistent, the graphic API will be called only for the first time.

2. Sort the materials and render them. In simple terms, there are many models in the scenario. If a considerable number of models share the same material, the models that use the same material are collected, the materials are set once, and then rendered one by one.

3. it should be clear that not all changes in the State have the same cost, and the same materials will be relatively limited. The so-called material sorting is just sorting those statuses with a relatively high switching cost, such as textures, for example, Shader.

Next let's call the drawing function itself. A single call is a DrawCall.

This function is needless to say. It starts rendering after various internal settings. To optimize it, you need to understand some features of modern GPUs.

Modern GPUs can render a large number of polygon at a time, but they are sensitive to the number of drawcalls. More than 3000 pcs will significantly affect performance. It is better to have no more than 200 mobile phones. At the same time, although a large number of polygon can be rendered at a time, it is also limited, not the bigger the better. It is critical to sum up the number of drawcall and the number of single-rendering polygon. The basic method is to merge models according to specific scenarios.

If it is a self-developed engine, more things can be done

1. More effective Scenario Management and filtering methods to minimize the number of polygon sent to the rendering engine

2. Use instances (only GLES3 and above are supported on mobile platforms)

To sum up the above two points, we should try to minimize the number of status changes and minimize the number of drawcalls!

Others

At present, the polygon sent to the graphic API on the mobile phone for rendering should be controlled below the 10 W triangle surface as much as possible. If you want to adapt to models a few years ago, this quantity will be even lower!

If you can use LightMap, you don't need to use real time. At present, it is difficult to use large areas of high performance!

Shader should make the algorithm as simple as possible. If it can be computed in the VS stage, it should not be computed on FS. Do not use functions such as pow.

Ultimate Optimization

Sometimes the technical staff may not be able to optimize their heads. Maybe they have done it in max three or two times.

Sometimes the technical staff and the art staff may not be able to optimize their heads. Maybe they can solve the problem by slightly changing the requirements on the planning side.

In the end, there is more communication between people in all aspects of game development!