You copied the Doc URL to your clipboard.

Specify the rendering order

In a scene, the object rendering order is very important for performance.

If objects were rendered in random order, an object might be rendered and subsequently occluded by another object in front of it. This means all the computations required to render the occluded object are wasted.

Various software and hardware techniques exist to reduce the amount of wasted computation because of occluded objects, but you can guide this process because you have knowledge of how the scene is explored by a player.

One of the hardware techniques for reducing wasted computation that is available on the Arm Mali™ GPUs from the Mali-T600 series onwards, is Early-Z. Early-Z is a completely transparent system from your point of view that performs a Z-test before the fragment shader is actually processed. If the GPU cannot enable Early-Z optimization, the depth test is executed after the fragment shader. This can be computationally expensive and the computations can be wasted if the fragment is occluded. The Early-Z system checks that the depth of the pixel being processed is not already occupied by a nearer pixel. If it is occupied, it does not execute the fragment shader. This system provides performance benefits but it is automatically disabled in some cases, such as if the fragment shader modifies the depth by writing into the gl_FragDepth variable, the fragment shader calls discard, or if blending or alpha testing is enabled for objects such as transparent objects. To assist this system to achieve maximum efficiency, ensure that opaque objects are rendered from front to back. This helps to reduce the overdraw factor in scenes with only opaque objects.

Ordering the rendering of each frame front-to-back can be expensive and also incorrect if you render transparent objects in the same pass. Arm Mali GPUs from T620 onwards provide a mechanism called Pixel Forward Kill (PFK). Mali GPUs are pipelined so multiple threads can be concurrently executing for the same pixel. If a thread completes its execution, the PFK system stops all other threads for that pixel if the current one covers them. The effect is a reduction of wasted computations.

Unity provides you with Queue options inside the shaders, or in the material to specify the order of rendering. This can be set in the shader, so objects that have a material that uses that shader are rendered together. Inside this rendering group, the order of rendering is random except in some cases such as transparency.

By default, Unity provides some standard groups that are rendered from first to last in the following order:

Table 4-2 Queue values for specifying rendering order

Name Value Notes
Background 1000 -
Geometry 2000 Default, used for opaque geometry.
AlphaTest 3000 This is drawn after all opaque objects. For example, foliage.
Transparent 4000 This group is also rendered in back to front order to provide the correct results.
Overlay 5000 Overlay effects such as user interface, lens flares, dirty lens.

The integer values can be used instead of their string names. These are not the only values available. You can specify other queues using an integer value between those shown. The higher the number, the later it is rendered.

For example, you can use one of the following instructions to render a shader after the Geometry queue, but before the AlphaTest queue:

Tags { "Queue" = "Geometry+1" }

Tags { "Queue" = "2001" }

Using the rendering order to increase performance

In the Ice Cave demo, the cave covers large part of the screen and its shaders are expensive. Avoiding rendering parts of it when possible can increase performance.

Rendering order optimization was included after looking at the composition of the framebuffers using the Unity Frame Debugger and other tools such as the Graphics Analyzer. These enable you to see the rendering order.

To open the Unity Frame Debugger, select the menu option Window > Frame Debugger. This is useful because there might be things that appear to be correct in editor mode, but might not work correctly when you execute them. This can be the case if for example, you have run time only settings, or if you are rendering to a texture from another camera. After starting the demo in play mode and positioning the camera, you can enable the Frame Debugger and get the sequence of drawings executed by Unity.

In the Ice Cave demo, scrolling down the draw calls shows that the cave is rendered first. The objects are then rendered into the scene occluding parts of the cave that are already rendered. Another example is the reflective crystals that in some scenes are occluded by the cave. In these cases, setting a higher rendering order results in a reduction in computations because fragment shaders are not executed for the occluded crystals.

Was this page helpful? Yes No