Control drawcils to improve performance

First, let's take a look at the requirements of the mobile phone scenario and clarify the requirements, so there will be problems targeted.

Drawcils, Control in100The same screen cannot exceed2 WTriangle.

Need to see the use of visionLevels, With a bird's eye view.

Roaming means1,2Layer refined points and other rough points.

The map area is large and must be loaded by branch.

 

Drawcils: The smaller the value, the better the game performance.

Introduction:Each stand-alone part of the game is placed in a special package, which we call a draw call ), the package is then transmitted to the 3D part and displayed on the screen. This is just as different as you want your friends and family to get the Christmas gift they have prepared to pack and put it in the place where they should appear on time. Your CPU is used to package and transfer their jobs, which consumes a lot of bandwidth. Therefore, it is important to allocate these critical resources. At present, the really terrible thing is that starting from the vision of "plotting commands, each Independent splash of blood on the floor consumes the same amount of bytes as a role or zombie. They all consume the same descriptive commands. There are no more differences.

 

LowerDrawcils:

So how can we reduce the draw call ?? Then we will use the culling technology. If you do not use this technology, no matter how many computers make rendering of everything in the scenario. Visible and rendered, as well as rendered. That's silly, right. You have to tell the computer that you can see the rendering. So there is

1. The unity system frustum culling comes with it, so you don't have to worry about it.

2. Occlusion Culling)

CullingImplementation

For realtime interactive 3D environment, the speed of reality is very important. Although the current hardware capabilities are very fast, but to maintain 30 FPS while processing hundreds of thousands of triangles, it is still very difficult for mainstream machines.

In order to solve this problem, people have proposed many methods, including the level of detail (SLS) and the level of detail (culling). For the level of detail (SLS), it can be increased from 2 FPS to 10 FPS, but it is difficult to increase from 4 FPS to 20 FPS. These two methods are not in conflict, and we often need to use the level of detail (SLS) on the basis of the culling to further solve the burden of pipeline.

Here I mainly want to discuss the culling technology: culling means that select from a flock is to "select a part from a group". For a 3D engine, a small part of the triangle is selected from the triangle of hundreds of thousands to be sent to the pipeline for rendering.

In general, there are several ways to select a method:

The simplest thing is backface culling. This is very common and I will not talk nonsense.

Then, view frustum culling is used to send the visible part of view frustum to pipeline. Generally, the hierarchy data structure is used to effectively perform view frustum culling, hierarchical structures are widely used in various graphics algorithms, such as collision detection, ray tracing, and radiosity. I have tried a view frustum culling Based on the AABB tree, and I think the efficiency is very high after the optimization methods such as frame coherency and plane masking.

However, viewfrustum culling is far from enough for current game scenarios, because view frustum is very large and the current scenarios are very complex, view frustum culling allows you to delete about 60% of data in a scenario on average during scenario roaming. For a 100,000 triangle scenario, the remaining data will also contain tens of thousands of polygon, it is still a heavy burden for pipeline.

However, view frustum culling is the easiest algorithm to implement. It is very convenient and effective. For some 3D RPG games, I think it is a good choice, because you can ask camera to be in a high position and always observe down, so that you can use view frustum culling to filter a small part of the scenario data at a very low cost, it is enough for grantiya, stars and things, and the latest winter city night. They have strict restrictions on the camera, suitable for viewfrustum culling. if you want to make 3D games, you should start with these games, because you can concentrate on rendering technology and other interesting parts.

However, for most first-person shooting games, view frustum culling is far from enough. In fact, in the actual environment, our vision is always blocked by various items, therefore, we can only see a small part of the entire scenario, which is far smaller than our view frustum. These items are called occluder, so there are many ways to consider how to use occlusion culling to improve the display performance. However, occlusion culling is much more complex than view frustum culling, and it is difficult to find a perfect solution for its diameter. Below I will briefly introduce some existing approaches:

All of these methods need to be divided into cells by using BSP Tree and KD-tree. Visibility usually reaches the cell level. You can determine the cell granularity to balance the efficiency based on your needs.

First, we will introduce some methods of Run-Time:

1. Portal-Based Occlusion Culling,
This is a run-time method based on object space. This method is especially suitable for fully enclosed architecture scenarios and cave scenarios. Because these scenarios have a unique feature, the blocks are very obvious, such as a building, most of the cells in each room are blocked by walls and can only be seen through a few doors. For this scenario, we can use the following method for effective culling:
First, identify the portal (door, window) of each cell in the scene. When rendering, find the cell where the view point is located, and then view frustum starts from the current cell, the portal of the cell is used to traverse the scenario at a time. Each time a portal passes through, the view frustum is corrected because these portals and viewpoint form more restrictions until no portal location is visible. The cell that has been traversed is the visible cell.

This method is very effective for such scenarios, because we usually stop traversing through several doors and windows. The portal must be manually set in advance or automatically identified by algorithms. However, for many outdoor scenarios, it is difficult to have such cells and portals, so this method is not applicable to those scenarios.

2. Single occluder culling
Based on the portal algorithm, this is a run-time method based on object space. This method can be used in scenarios with many tall blocks, such as large cities and mountains. These scenarios are characterized by the existence of many tall and effective blocks, such as mountains and buildings, which can often block many parts of viewfrustum. Of course, this method also applies to indoor scenarios corresponding to the portal algorithm. The algorithm process is as follows:

Maintains an occluder list, uses hierarchical structures to access each cell from the perspective of view in the order from the past to the future, and determines whether it is blocked by an occluder in the occluder list, if there is no object in the cell, determine whether it is a good occluder (based on its projected area on the plane and other factors). If so, add the occluder list and continue traversing.

This method sometimes uses some processing and processing processes to mark some objects as a good occluder, or generate some virtual occluder (simpler shape, almost replacing some occluder ), these are designed to reduce the time for selecting occluder during running and make the choice of occluder more effective.

The disadvantage of this method is that the effects of several occluder roles cannot be considered. Many things may not be blocked by occluder a or occluder B, but with occluder a and B, you can't see it. Therefore, this method is useless for scenes that do not have very large occluder but are still blocked by very dense scenes, such as the jungle. However, to consider the impact of multiple occluder in the run-time (in object-space), it is very difficult to ensure the speed (the computing cost is too high ).
3. From the above two examples, we can see that if you can consider the impact of multiple occluder, then the part of viewfrustum can be limited a lot, and it can also deal with more complex scenarios. However, processing in object-space is difficult to obtain at a very low computing cost. Therefore, some image-space-based methods are born. The most common example is Z-buffer. the advantage of image-space processing is that the visibility of image-space is determined by a limited number of elements (the number of pixels on the screen), which has a great advantage over object-space. However, it is not enough to rely on Z-buffer to reach the rendering stage. There is a hierarchy Z-buffer method, also known as Z-pyramid, because it generates a series of Z-buffer with different fineness, for example, the maximum Z-buffer is a 32*32 suface, so it generates 16*16, 4*4, 2*2, 4 level Z-buffer of 1*1, each level of Z-buffer corresponds to four pixels in the upper level, and takes the farthest depth. Therefore, we can use hierarchical structures to render scenes from the past to the future, in addition, you can first compare the bounding box of nodes in the hierarchy (starting from the first level of Z-buffer), so that you can effectively draw scenes with complicated occlusion relationships. I feel very hopeful about this method, but the only drawback is that without hardware support, the software method is very slow to implement this Z-Pyramid and the corresponding detection.
Therefore, I think that if the hardware will support Z-pyramid in the future, this will be a very good method and may become a standard method, just like the current Z-buffer.

4. Image-space is indeed a good way to solve the problem that multiple occluder affect the visibility together, but it does not have hardware support, reducing its efficiency. However, some special methods can be used in some special environments, so that we can combine the objec-space and image-space methods to get a better trade off. this is the 2.5D scenario. The most common scenario is the urban environment. Basically, most games in urban scenarios can be viewed as a 2.5D environment, and the visibility judgment only needs to consider the high factor on the basis of 2D.
Therefore, there is an effective way to deal with the city environment. The algorithm is as follows: first, the cell division is strictly restricted on the plane (such as the horizontal ground), such as the square of 256*256 cells, the size and granularity can be determined based on specific scenarios. Each cell record belongs to the objects (to be drawn) of the cell and the height of the highest object in the cell. To improve efficiency, you also need to mark some good occluder in advance, such as the front of each building, but here there is a restriction that the occluder must be a rectangle perpendicular to the horizontal plane.
There is a surface buffer. For example, we have a 256*256 surface that corresponds to each cell. At the beginning, the Z-buffer corresponding to this surface is 0, then we can select several nearby occluder based on the viewpoint and select hundreds of them (this is better than the object-space method, and the general object-space algorithm can only use a small number of occluder ), the Shadow volume formed by the viewpoint and occluder is rendered on our surface with a positive projection angle (from the sky to the ground, in this way, the height of the Shadow volume is left on the Z-buffer corresponding to the surface. The effects of multiple shadow volume can be obtained by rendering them to the suface, in addition, this rendering can use hardware acceleration, so many occluder can be used. finally, we can determine the visibility of each cell as long as we compare the height of the cell and the height of the Z-buffer of the point corresponding to the surface. It can be determined.
Another thing to be improved here is that it is very slow to directly read Z-buffer, so we must use a better method to convert this information to the surface buffer, copying data from the surface buffer to the system memory is much lower.
The specific method is as follows: at the beginning, all surface buffers are cleared by 0, and the corresponding Z-buffer is set to the height of each cell. Disable Z-buffer check and write. Now the view frustum is rendered to the surface buffer with color 1. Enable Z-buffer check and render the shadow volume with color 0, finally, copy the surface buffer to the system memory, where the data is 1 is the visible cell.

This method is indeed a good method for 2.5D cities, but it also has many restrictions, such as occluder restrictions, you may have to write a dedicated editor for this. This method does not work for other complex scenarios in full 3D mode.

After introducing these run-time methods, we can take a look at many preprocess methods to calculate visibility during run-time. For a very complex scenario, the cost is indeed very high. However, some methods that calculate visibility in advance can achieve very good results. This method discards the visibility of the computing point to cell and then calculates the visibility of the cell to cell. Although this increases the visibility of the visible part, some invisible cells are also sent to the pipeline for processing, however, preprocess does not take up the run-time, which greatly improves the efficiency, because in many worst cases, especially when dealing with complex scenarios, it is more advantageous than run-time. The basic practice is to calculate the set of other cells that may be seen at any point of view in each cell, also known as PVS. During running, you only need to draw the cells in PVS and in view frustum at the same time. However, how to calculate a good PVS is a very complicated task.

Each person has different methods. Some simple examples are as follows:
1. In the applicable environment of the portal engine, the full shadow between portals is used to calculate PVS.
2. in the vicinity of the cell, select some occluder, and then constantly form some virtual occluder with some of the surrounding occluder (which can block some relatively large scope ), then use these virtual occluder to calculate the visibility into other cells.
3. there is a PVS Algorithm for the 2.5D urban environment. The occluder is also limited to the rectangle perpendicular to the ground. The basic calculation is based on the visibility calculation of 2D space, height detection is performed only when necessary. There are other algorithms that are very complicated and I haven't fully figured out, so I won't talk about them here.

 

LevelsTechnology

With the levels of detail (multi-level details) technology, you can gradually simplify the surface details of a scene without affecting the visual effect, this improves the rendering algorithm efficiency. This technique usually creates several geometric models with different approximation precision for each primitive polygon model. Compared with the original model, each model retains a certain level of details. During painting, select an appropriate hierarchy model based on different tables to represent objects. Deep Learning has a wide range of application fields. Currently, it has been applied in real-time image communication, interactive visualization, virtual reality, Terrain Representation, flight simulation, collision detection, and time-limited graphics rendering, and has become a key technology. Many modeling software and VR development systems have begun to support the representation of the dump model.

 

The following are some of my previous experiences on web games that I have shared with other netizens:

1. Disable gameobject one by one to determine the gameobject that affects performance.

2. The number of draw CILS & triangles in stats should be minimized. It is said that the upper limit is 35.

3. Merge mesh objects and merge material sheets

4. Do not use mesh collision

5. Unity consumes a lot of time to render a model with an action. If it is a static model without an action file, it will not cause efficiency problems, but make sure to only draw things on the screen.

6. The higher the batched, the better. Integrated Rendering

7. No need to use lights. Shadows are replaced by planes. Shadows and real-time lamps are simply framekller.

8. Try to reduce the surface of the model. this is complementary to drawcall. my last game has a full screen of only 400 faces, and drawcils is almost 90. It can also run to 30 frames on a real machine. of course there is no complex movement, which is another aspect.

9. Try not to separate models. For example, in my current tank game, the car bodies and tracks are separated, each of which is a drawcils.

10. In the final output-
In edit-Project setting-player
Change settings-script call optimization to fast, but there is no exception. fast but no exception

Low Mode and high Mode

The general saying of the masses is that the high-mode model refers to a model with many faces and looks fine. The low mode refers to the low number of faces. Of course, there is no high-mode detail. As for why games generally use low-Mode Models, gaming manufacturers need to consider the public's computer configuration (generally the general shape of the model is expressed with the least surface ). When you are playing a game, every aspect of the model has to be computed by your computer. When there are more faces, it will undoubtedly increase the burden on the computer and make the game smoother. In Max, you add a grid smooth command to an object, and then adjust the number of iterations to 10 to see if your computer can afford it. If you rotate it, you can see it is stuck.

In daily work Communication, the most common definition method is "definition by number of faces ".

For example:

The top 3000 is the high-Mode

The top 4000 is the high-Mode

The top 4500 is the high-Mode

The top 10000 is the high-Mode

It is not accurate to distinguish between "high mode" and "Low Mode" simply by the number of faces.

Baidu's statement:

The high mode is generally processed by smooth-this is based on practice.

High-mode is generally used for film and television and advertising. Low models are generally used in games. -- This is for purpose.

High mode is generally used for baking and pasted on the low mode. -- This is from creating a normal map.

I personally think that there is a reasonable way to define it.

Model with control over the opposite number-Low Mode

Uncontrolled model of the opposite number-high Mode

This reflects both the production method and the purpose of the model.

Generally speaking, the number of faces is not controlled in the rendering model. Basically, all the functions of model editing can be used to achieve the effect. Used for, video and animation, 2D games (the model turns into an image), normal baking ......

The model used for instant display needs to control the number of faces and basically uses editablepoly. It is generally used only for 3D games.

Maybe a table model used in architectural decoration is 100 faces, and a 3D Game role is 3000 faces. But the table is still a high model.

Because no one specifies how many sides your table should be controlled. You can freely rotate the corners and smooth the scenes. If your computer can hold it, you are happy. You can even model the texture on the table and make the 100-sided Table 1 million.

The 3D Game Model limits the number of faces. You must be in the upper or lower range of 3000.

In short, it is absolutely wrong to define "high mode" and "Low Mode" from the number of faces.

The definition of personal recommendation is: a model with control of the opposite number -- a model with no control of the opposite number of low-mode -- a high-Mode

 

 

Rendering call (Drawcils)

A different material of each object will cause a separate drawcall call. Each drawcall will cause an additional engine overhead. Therefore, you must avoid more than 2000 drawcils during observation at any point in the level.

Use as little as possible for different materials

Merge some textures (for example, if you use two different 512x256 textures for the same object, merge them into a texture of 512x512)

The square texture will be better applied to the texture stream

Each object uses as few different materials as possible. Each material of the object will cause drwacall at least twice. If the shadow is enabled, it will be three times.

Delayed rendering is used. The CPU overhead of delayed rendering is much lower than that of foreground rendering, and the main overhead is only for GPU rendering. The front-end drawcall can be replaced by a uniform screen drawcall for delayed rendering.

 

Scenario complexity

Leave the room through closed

Use Transition Region

Apply fog effects to non-masked Environments

Use visblocking/occluders for large objects

Adjust and reduce the visible area in the area of a special multi-object

Delete a type not visible to the player

Smooth the surface to reduce vertex Density

Adjust the visible range for each object

Set the maximum drawcils alert value to 2000 or smaller.

Use less textures as much as possible.

Avoid overlap of Multiple Materials

Do not overwrite multiple very large transparent layers or add layers (additive)

Set a proper distance for the fine arts resources to the level of granularity.

CPUPerformance

Use as few complex materials as possible (low performance cost)

Minimize the number of triangles in the cbuffer (save drawcils and reduce drawcils conflicts)

Area of cbuffer

Reduce the number of bones of an animation role

Do not use role animation blur (skin requires more bones)

Exercise caution when using texture streaming (requires decompression)

Use as few transparent objects as possible in the weather effect (CPU calculates the approximate value of fog effect)

Use triangles as much as possible for the physical proxy (for collision detection)

Exercise caution when using destructible objects

GPUPerformance

 Resolution-independent:

Use as few vertices as possible for rendering (each vertex is a unique position and coordinate point of the texture)

Use a less complex vertex format

Use as few lights as possible with shadows

Use decals with caution

Resolution-related:

Render objects use as few pixels as possible on the screen

Use low-cost pixel shader (small lighting, less shader features such as reflection, simple shader ).

Use as few textures as possible for each material in the scenario

Use inexpensive texture formats (use compressed dxt1, dxt3, 3dc/dxt5 as much as possible)

Use mipmap

Alphablend is slower than alphatest, and alphatest is slower than an object that is not transparent.

Delayed rendering is cheaper than normal lighting, and the radius of all light effects should be as small as possible.

If you need some lights in some areas (such as the box area), this will lead to a large number of overlapping lights. It is necessary to use irradiancevolumes.

As few as possible to enable multiple postprocessing effects at the same time, another strategy is to reduce the time for enabling the postprocessing effects.

Do not use or use full-screen anti-aliasing (msaa/fsaa) with low overhead)

Weather effects with less effort

Use as few terrain materials as possible.

Memory usage:

Use as few textures as possible

Use a low-resolution texture resolution

Use the texture compression format (dxt1 is the best, dxt5 and 3dc are also good choices)

Use as few vertices as possible

Use the simplest physical substitution body as possible

Use as few animations as possible

Use as few models as possible or with a level

Use as few materials and particle transmitters as possible

Use as few roads as possible

Exercise caution when using the sticker

Use a light source with as few shadows as possible

Texture stream: (related to texture transfer bandwidth)

Streamability textures should be square-sized (same width and height, for example, 1X1 256x256 ).

Use as few different arts and sciences formats as possible for better unified management of texture pools

Use as few unique large textures as possible for each region to reduce I/O bandwidth consumption

Strictly abide by the texels per square meter (distance streaming is based on it), and use r_texelspermetter 1 to check it

Do not try to use a texture larger than 512x512 (split some large textures into small textures)

Try to avoid using smaller than X texture units (which will cause memory fragments) and splice small textures in the same region into a large texture.

If you still stick to using a large texture set (not recommended), make sure you do not use these physical to different areas of the scenario (such as vegetation)

General Program Performance Criteria:

The simpler the material, the more streamlined the texture.

Attachments should be adjustable and should not be displayed when the screen is too small

The eyes are closed based on distance to reduce the consumption of eye rendering (if the eyes are rendered)

We should try our best to prevent the destruction of destructible objects from spreading out too quickly (in my understanding, it is slow to scatter damaged objects as much as possible, and do not set them to too small damaged objects ?)

The smaller the number of vertices should be used for texture expansion (expanding into large blocks)

Exercise caution when using the sticker.

Determine the texture resolution (set appropriate proportions based on different ranges)

Set block area to reduce the number of rendering objects

Using protals in static scenarios can bring better efficiency.

Blocky
Geometry helps to get more for the same vertex count)

Reuse ry and texture to reduce memory usage

Avoid using unique details in the scenario (especially in complex scenarios)

The material layer that needs to be rendered multiple times is slower than normal, so use it with caution.

Manually perform the reset xfrom and reset transformations operations before export. If not, these values are checked by the engine to generate assertions. For example, the physical model does not match the rendered ry.

The origin point should be inside the object's Package Box to avoid rendering results that are unexpected.

Track and solve all levels error levels displayed in the console input window.

Rendering call (Drawcils)

A different material of each object will cause a separate drawcall call. Each drawcall will cause an additional engine overhead. Therefore, you must avoid more than 2000 drawcils during observation at any point in the level.

Use as little as possible for different materials

Merge some textures (for example, if you use two different 512x256 textures for the same object, merge them into a texture of 512x512)

The square texture will be better applied to the texture stream

Each object uses as few different materials as possible. Each material of the object will cause drwacall at least twice. If the shadow is enabled, it will be three times.

Delayed rendering is used. The CPU overhead of delayed rendering is much lower than that of foreground rendering, and the main overhead is only for GPU rendering. The front-end drawcall can be replaced by a uniform screen drawcall for delayed rendering.

Number of vertices

In the engine, the UV boundary will increase the number of vertices and use as few UV boundary as possible.

Vertex normal vectors are separated on some hard edges to ensure smooth polygon and reduce the number of hard edges.

Physical proxy

A good physical proxy is very important in reducing the CPU physical computing time. If there is no physical proxy, the performance will slow down.

Use a simple physical proxy to replace the rendering model to process physical computing and reduce the CPU physical computing time.

The physical computation of rendering ry should only be applied to some destructible 3D bodies, such as the destructible trunk.

Use primitives as much as possible for physical proxy replacement

Try to use the rough object proxy to handle the collision of roles and the collision detection of rendering aggregates and bullets.

Use a set of smoothing bodies for each physical proxy (only soft edges)

Set the physical type (set the proper physics type in) in the 3D package of the material editor
The material edtior of the 3D package)

Block proxy

For a large object, set the role's visual occlusion, use the block proxy instead, and use a single-side blocking proxy (because the default multi-side type is regarded as double-sided). It is as simple as possible. The smaller the number of triangles, the better.

ObjectLevels

Set the level of detail in each art resource. The number of vertices in each level must be reduced by at least p. Use the instancing and adjustment modifier of 3dmaxd

Reduce the number of materials with low levels of level of detail to save drawcils.

A good level of detail is the key to good performance and good resource appearance.

Material settings

Use as few materials as possible

Combine textures to reduce the number of materials and texture extraction

Keep all textures in crytif format

Use 128/128/128 as the default diffuse color

Use a simple gray 128/128/128 or quick color texture for early texture size experiments to get a suitable memory overhead Solution

Make sure all textures have been tested for performance

Vegetation

In an outdoor game, vegetation is an extremely high overhead for a vegetation coverage scenario, ensuring that the number of drawcils per region does not exceed 1 or 2

Reduce the material size of vegetation objects and save drawcils

Use only the optimal shader on vegetation objects

Reduce the number of sides because these objects are drawn many times on the screen.

Combine the arts and sciences to reduce the number of materials and the least texture extraction (texture
Fetches)

Add multiple edges to the leaves to match and reduce overdraw (occlusion rendering), and use patches on the trunk.

Particle

Make particle effects as effective as possible, because they bring great overhead and have a great impact on performance. In addition, try to replace standard particles with simple particles without affecting vision to reduce performance overhead.

Frametime:

If your frametime target is 30 frames per second, the consumption of each frame should not exceed 33 seconds.

You can use r_displayinfo 2 to check the frame time or enable the profile
= 1 ).

Frame Rate = frame time in 1.0/1 s. For example, 1.0/0.033 (3) = 30.

The GPU time is very dependent on the screen resolution if the fsaa and render target formats are used, such as 720 p (1280x720) and HDR is disabled. The higher the setting, the worse the performance.

Specifically, this means that for xbox360, if you spend 5 ms for ZPass, 6 ms for General pass, and 10 ms for shadow processing (if this function is enabled ), this takes about 21 milliseconds. Theoretically, the frame rate on the GPU will not exceed 47 frames.

Overhead of non-delayed rendering illumination

Using a simple pass for sunlight Rendering

A single pass is used for the rendering of the point light source, which can be merged. Up to one pass can process four lights.

Spotlight rendering always uses a separate pass

This means that if your scene has sunshine, you can add a light source, which will bring additional drawcils light source effects to each object. The additional drawcall overhead means that more data needs to be processed on the CPU. Each drawcall will bring more filling overhead.

Limit the number of textures

Shaders reading textures is very expensive for host classes and old PC hardware.

Use the gloss option in the shader of diffusealpha to replace the glossmap ). This saves a lot of time for reading the texture of a shader. You can use it safely without worrying about any quality loss. If you use this feature and your luster is only in a single tone, you can adjust it by using the color material parameter in the highlighted color.

For the shader of vegetation, use the merged textures option. For the leaves, this means that the RGB channel of the glossmap texture contains your transparency RGB channel, and glossmap Alpha will contain your grayscale gloss information. For the trunk, it means that diffusealpha contains your grayscale gloss information. Do not ignore this because it is good for both GPU (reduced read overhead) and CPU (less overhead for setting texture sampling.

Correct useShaderColoring er options

Use grass
The shader generation option is a very cheap rendering method when you perform grass rendering. It generates all shadows and reads with the least texture, correct use of this option is very important, especially for host games.

Use the decal shader generation option when you use a material as a sticker. This is important to ensure proper rendering. For example, you need to avoid Z-fighting (Z competition) in some hardware and some rendering conditions. In addition, deferred
Rendering) will only be able to normally render opaque ry/ground surface/decimal. If this option is not enabled, you need to re-read the normal
Map and re-render and calculate the fog effect.

Water/rivers
Volumes

When using water
When volumes and underwater fog effect are used, if it is shallow water, the density should be set to 0. In this way, the fog effect processing can be skipped.

Use water volumes in a small visible area. If you want to cover a large area, use small blocks as much as possible.