The Frame Debugger

Before we dive into how batching can save us draw calls, let's explore a useful tool that can help us to determine how batching is affecting our scene—the Frame Debugger.

We can open Frame Debugger by selecting Window | Analysis | Frame Debugger from the main window or clicking on the Frame Debugger button in Breakdown View Options in the rendering area of the Profiler. Either approach will open the Frame Debug window.

Clicking on the Enable button in the Frame Debug window will allow us to observe how our scene is being constructed, one draw call at a time. The following screenshot shows the user interface of the Frame Debugger, with a list of GPU instructions in the left-hand panel and more detailed information in the right-hand panel:

There is a lot of information in this window that can provide us with useful information if we want to debug the behavior of a single draw call, but the most useful area to look at is the Drawing section in the left-hand panel, which lists all of the draw calls in our scene.

Each item in this section represents a unique draw call and what was rendered by it. An amazingly useful feature of this tool is the ability to click on any one of these items and immediately observe only the draw calls needed to render the scene up to that point in the Game window. This lets us see visually the differences between two sequential draw calls. This can make it easy to spot exactly which object(s) were rendered by a given draw call. This can help determine whether or not a set of objects were batched together by looking at how many of them appear during that draw call.

A weird bug with the Frame Debugger (which still exists in early builds of Unity 2019) is that if we are observing a scene that is making use of a skybox and click on various items under the Drawing section, then only the final scene presentation can be observed in the Game window. We would need to temporarily disable the skybox via the camera's Clear Flags setting to look at how the draw call progression appears in the Game window by setting it to Solid Color instead.

As we can see in the preceding Frame Debugger screenshot, one draw call is being consumed to clear the screen (the item labeled Clear), and then our eight meshes are being rendered in eight separate draw calls (the item labeled RenderForward.RenderLoopJob).

Note that the number next to each item in the left-hand panel actually represents a graphics API call, of which a draw call is but one type of API call. These can be seen in the Camera.Render, Camera.ImageEffects, and RenderTexture.ResolveAA items. Any API call can be just as costly as a draw call, but the overwhelming majority of API calls we will make in a complex scene will be in the form of draw calls, so it is often best to focus on minimizing draw calls before worrying about the API communication overhead of things such as post processing effects.